From jajcus at jajcus.net Sun Jul 1 10:51:13 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 1 Jul 2012 10:51:13 +0200 Subject: Cluster stuff (cman,dlm,heartbeat,corosync,openais,pacemaker,drbd,lvm) Message-ID: <20120701085113.GA2435@lolek.nigdzie> Hello, At work we use clusters. Currently based on Heartbeat/PaceMaker/DRBD, but I am trying to introduce Corosync and clustered LVM. All based on PLD packages? and I have found a bit of mess in our packages. We have both corosync and openais, but our openais is 0.80, not 1.x which uses corosync as its lower layer. Does anybody still needs openais 0.80? LVM by default build with the clvmd daemon, but the daemon is built only for the cman cluster manager. I guess it is part of some RedHat cluster suite. There is also a 'clvmd3' bcond which seems to enable building with the new version of cluster/cman? but it doesn't seem it would work. Do we need clvmd in the main lvm2 package? It pulls some dependencies irrelevant for non-clustered setups. Do we need to build it with the 'old cman'? Or should we now use only the new packages from 'cluster.spec'? We should probably build LVM2 drivers for other clusters by default - corosync/openais. We have PacePaker 1.0 on HEAD. I am wondering if we could switch to PaceMaker 1.1. 1.0 is 'bugfix release', 1.1 is 'feature release'. None of this is considered 'development', though 1.0 is probably expected to be more stable. 1.1 works well for me. There were mixed versions of heartbeat, pacemaker and related packages and eventually all of them were dropped from th-main. I think they could be restored. Greets, Jacek From qboosh at pld-linux.org Sun Jul 1 11:39:11 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 1 Jul 2012 11:39:11 +0200 Subject: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm) In-Reply-To: <20120701085113.GA2435@lolek.nigdzie> References: <20120701085113.GA2435@lolek.nigdzie> Message-ID: <20120701093911.GA14125@mail> On Sun, Jul 01, 2012 at 10:51:13AM +0200, Jacek Konieczny wrote: > Hello, > > At work we use clusters. Currently based on Heartbeat/PaceMaker/DRBD, > but I am trying to introduce Corosync and clustered LVM. All based on > PLD packages??? and I have found a bit of mess in our packages. > > We have both corosync and openais, but our openais is 0.80, not 1.x > which uses corosync as its lower layer. > > Does anybody still needs openais 0.80? > > LVM by default build with the clvmd daemon, but the daemon is built only > for the cman cluster manager. I guess it is part of some RedHat cluster > suite. There is also a 'clvmd3' bcond which seems to enable building > with the new version of cluster/cman??? but it doesn't seem it would work. > > Do we need clvmd in the main lvm2 package? It pulls some dependencies > irrelevant for non-clustered setups. > Do we need to build it with the 'old cman'? Or should we now use only > the new packages from 'cluster.spec'? IMO we should switch to new corosync/openais and cluster/gfs (replacing its old parts currently existing in separate specs). > We should probably build LVM2 drivers for other clusters by default - > corosync/openais. If they can coexist, then yes. Old cluster (1.x/2.x) components could be dropped. (not using such configurations myself - just thinking about flexibility) -- Jakub Bogusz http://qboosh.pl/ From jajcus at jajcus.net Sun Jul 1 15:36:57 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 1 Jul 2012 15:36:57 +0200 Subject: Cluster stuff (cman,dlm,heartbeat,corosync,openais,pacemaker,drbd,lvm) In-Reply-To: <20120701085113.GA2435@lolek.nigdzie> References: <20120701085113.GA2435@lolek.nigdzie> Message-ID: <20120701133657.GB2435@lolek.nigdzie> On Sun, Jul 01, 2012 at 10:51:13AM +0200, Jacek Konieczny wrote: > Does anybody still needs openais 0.80? Updated question: does anybody still need openais at all? It seems not maintained any more and won't build with corosync 2.0? and other stuff seem to expect corosync 2 now? I guess openais can be dropped if no one was interested in it since the 0.80 release? Greets, Jacek From jajcus at jajcus.net Sun Jul 1 15:41:54 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 1 Jul 2012 15:41:54 +0200 Subject: Cluster stuff (cman,dlm,heartbeat,corosync,openais,pacemaker,drbd,lvm) In-Reply-To: <20120701133657.GB2435@lolek.nigdzie> References: <20120701085113.GA2435@lolek.nigdzie> <20120701133657.GB2435@lolek.nigdzie> Message-ID: <20120701134154.GC2435@lolek.nigdzie> On Sun, Jul 01, 2012 at 03:36:57PM +0200, Jacek Konieczny wrote: > On Sun, Jul 01, 2012 at 10:51:13AM +0200, Jacek Konieczny wrote: > > Does anybody still needs openais 0.80? > > Updated question: does anybody still need openais at all? It seems not > maintained any more and won't build with corosync 2.0? and other stuff > seem to expect corosync 2 now? OK? cluster.spec still needs openais? so it must stay? Greets, Jacek From alucard at nospheratu.net Sun Jul 1 17:36:04 2012 From: alucard at nospheratu.net (Tomasz Rutkowski) Date: Sun, 01 Jul 2012 17:36:04 +0200 Subject: Cluster stuff (cman,dlm,heartbeat,corosync,openais,pacemaker,drbd,lvm) In-Reply-To: <20120701134154.GC2435@lolek.nigdzie> References: <20120701085113.GA2435@lolek.nigdzie> <20120701133657.GB2435@lolek.nigdzie> <20120701134154.GC2435@lolek.nigdzie> Message-ID: <1341156964.5024.13.camel@battleship> Dnia 2012-07-01, nie o godzinie 15:41 +0200, Jacek Konieczny pisze: > On Sun, Jul 01, 2012 at 03:36:57PM +0200, Jacek Konieczny wrote: > > On Sun, Jul 01, 2012 at 10:51:13AM +0200, Jacek Konieczny wrote: > > > Does anybody still needs openais 0.80? > > > > Updated question: does anybody still need openais at all? It seems not > > maintained any more and won't build with corosync 2.0? and other stuff > > seem to expect corosync 2 now? > > OK? cluster.spec still needs openais? so it must stay? > cluster.spec was my work of 3rd generation of redhat cluster suite (dlm+cman+gfs2+rgmanager), there is bcond in lvm2 to complete stack, but it's already outdated (needs polishing :)) openais 1.x is needed some times, but I belive it's not hard requirement corosync 1.4.x is now production used, cluster3 and clvmd won't build with 2.x however on horizon there is dlm4 dedicated to work with corosync 2 and in some short future lvm2 should also get to build/work with it in my work on PLD I'm using cluster3 + clvmd + gfs2 and in another line corosync 1.4.3 with pacemaker 1.1.6 (+clvmd+gfs2) so in summary: if we would like to have pacemaker+cluster3+lvm2 then now we need: cluster3 have to be line 3.0.x (3.1 won't build with pacemaker) corosync 1.4.x pacemaker any tommorow I'll try to put stuff I have in cvs with best regards -- ------------------------------------------------------------------------ Tomasz Rutkowski , +48 604 419 913 , e-mail/xmpp: alucard at nospheratu.net ------------------------------------------------------------------------ From glen at pld-linux.org Sun Jul 1 21:47:19 2012 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Sun, 01 Jul 2012 22:47:19 +0300 Subject: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm) In-Reply-To: <20120701085113.GA2435@lolek.nigdzie> References: <20120701085113.GA2435@lolek.nigdzie> Message-ID: <4FF0A947.7030302@pld-linux.org> On 07/01/2012 11:51 AM, Jacek Konieczny wrote: > Do we need clvmd in the main lvm2 package? It pulls some dependencies > irrelevant for non-clustered setups. i'm in for moving clustered deps to subpackages. if it's doable. personally not using any clustering setups -- glen From jajcus at jajcus.net Sun Jul 1 22:13:35 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 1 Jul 2012 22:13:35 +0200 Subject: Cluster stuff (cman,dlm,heartbeat,corosync,openais,pacemaker,drbd,lvm) In-Reply-To: <1341156964.5024.13.camel@battleship> References: <20120701085113.GA2435@lolek.nigdzie> <20120701133657.GB2435@lolek.nigdzie> <20120701134154.GC2435@lolek.nigdzie> <1341156964.5024.13.camel@battleship> Message-ID: <20120701201335.GA26904@lolek.nigdzie> On Sun, Jul 01, 2012 at 05:36:04PM +0200, Tomasz Rutkowski wrote: > cluster.spec was my work of 3rd generation of redhat cluster suite > (dlm+cman+gfs2+rgmanager), there is bcond in lvm2 to complete stack, but > it's already outdated (needs polishing :)) I have replaced this bcond with something more up to date. Currently '3rd generation redhat cluster suite' is near being outdated. Keeping old cman and dlm as the default backend for lvmd just does not make any sense now. > corosync 1.4.x is now production used, cluster3 and clvmd won't build > with 2.x Yes, I found it out the hard way, so let it be corosync 1.4.x in Th for now. > however on horizon there is dlm4 dedicated to work with corosync 2 and > in some short future lvm2 should also get to build/work with it Yes, but let's not push it into PLD unless all the components are officially 'stable'. Now corosync 2 itself is ok, pacemaker will build with that, but there is no openais for it, so no cluster either (unless we go for the development '4th generation') > in my work on PLD I'm using cluster3 + clvmd + gfs2 and in another line > corosync 1.4.3 with pacemaker 1.1.6 (+clvmd+gfs2) I am going to try corosync 1.4.3 + pacemaker 1.1.7 + clvmd/drbd soon. corosync+pacemaker already installed on a test cluster and seem to work fin. > so in summary: > if we would like to have pacemaker+cluster3+lvm2 then now we need: > cluster3 have to be line 3.0.x (3.1 won't build with pacemaker) What do you mean by '3.1 won't build with pacemaker'? There was no pacemaker dependency in cluster.spec I haven't tried the 3.0.9x versions, though? I don't trust those 'test releases' in the 'stable branch'. > corosync 1.4.x > pacemaker any I have prepared: corosync 1.4.3 openais 1.1.4 cluster 3.1.8 lvm builds with all that. I have also played with pacemaker 1.1 (on branch currently) - after a bit of patching works with corosync 1.4.3 for me, so I think it could go to HEAD, unless there is a reason to keep pacemaker 1.0.x. Though, I don't remember why I use 1.1 and not 1.0 ;) Greets, Jacek From jajcus at jajcus.net Sun Jul 1 22:16:15 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sun, 1 Jul 2012 22:16:15 +0200 Subject: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm) In-Reply-To: <4FF0A947.7030302@pld-linux.org> References: <20120701085113.GA2435@lolek.nigdzie> <4FF0A947.7030302@pld-linux.org> Message-ID: <20120701201615.GB26904@lolek.nigdzie> On Sun, Jul 01, 2012 at 10:47:19PM +0300, Elan Ruusam?e wrote: > On 07/01/2012 11:51 AM, Jacek Konieczny wrote: > > Do we need clvmd in the main lvm2 package? It pulls some dependencies > > irrelevant for non-clustered setups. > i'm in for moving clustered deps to subpackages. if it's doable. Already done. Theoretically this could break a cluster on upgrade, but I don't think it would be a mass problem among PLD users ;) And production clusters are not a thing one upgrades without testing. Greets, Jacek From glen at pld-linux.org Mon Jul 2 07:45:41 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 02 Jul 2012 08:45:41 +0300 Subject: lvm2 and initrd Message-ID: <4FF13585.7070000@pld-linux.org> hi as lvm2 is hot topic today, i thought to write out another problem with it. currently lvm2 on rootfs requires udev on initrd, or it will act buggy, for example (the way i discovered it), is that swap with label won't appear under /dev/disk/by-label # blkid |grep swap /dev/mapper/sys-swap: LABEL="swap" UUID="e6b1a0ff-3693-4241-84bb-07e82dd3ac7d" TYPE="swap" # ls -l /dev/disk/by-label/*swap* ls: cannot access /dev/disk/by-label/*swap*: No such file or directory there are other problems, some warnings that can be ignored with no workload, but probably can cause corruption [1], so it works more or less ok in readonly mode (i.e you can boot, but can not make more changes to system). swap label otherwise works, as it "comes back" if i rename vg from os [2]. actually lvextend "works" too, but output does not look very hopeful [4] upstream (actually systemd, but same dudes) said, if we want lvm2 on rootfs and rootfs is without udev support, "you're on your own", core problem is that lvm does not find it's config in the udev database after initramfs take-over. even it's pretty easy to reproduce, i can provide pld th vm where it's broken. last version i tested is 2.02.94, and i think it was acceptable in 2.02.84-1, i.e before udev support was enabled [3] anyone interested working that out (so that udev can be again optional for rootfs on lvm systems)? [1] https://dl.dropbox.com/u/8879577/ss/systemd-cryptsetup.png [2] http://carme.pld-linux.org/~glen/lvm-swap.log [3] http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/packages/lvm2/lvm2.spec?r1=1.176&r2=1.177& [4] http://sprunge.us/CWge -- glen From jajcus at jajcus.net Mon Jul 2 08:22:33 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 2 Jul 2012 08:22:33 +0200 Subject: lvm2 and initrd In-Reply-To: <4FF13585.7070000@pld-linux.org> References: <4FF13585.7070000@pld-linux.org> Message-ID: <20120702062233.GB30162@jajo.eggsoft> On Mon, Jul 02, 2012 at 08:45:41AM +0300, Elan Ruusam?e wrote: > anyone interested working that out (so that udev can be again optional > for rootfs on lvm systems)? Is udev on initrams that bad, that you just don't want to use it? Are there scenarios where udev just won't work? It may be just easier to agree, that udev is required for early userspace instead of trying to support two different configurations, one of which is already obsolete. Greets, Jacek From glen at pld-linux.org Mon Jul 2 08:53:17 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 02 Jul 2012 09:53:17 +0300 Subject: lvm2 and initrd In-Reply-To: <20120702062233.GB30162@jajo.eggsoft> References: <4FF13585.7070000@pld-linux.org> <20120702062233.GB30162@jajo.eggsoft> Message-ID: <4FF1455D.5010908@pld-linux.org> On 07/02/2012 09:22 AM, Jacek Konieczny wrote: > On Mon, Jul 02, 2012 at 08:45:41AM +0300, Elan Ruusam?e wrote: >> > anyone interested working that out (so that udev can be again optional >> > for rootfs on lvm systems)? > Is udev on initrams that bad, that you just don't want to use it? Are > there scenarios where udev just won't work? well, there's continuous fight getting initrd versions of tools compiled, as new releases tend to get broken with klibc/uclibc/... and even if they compile with some patching, they can crash in some configurations/architectures. this could end up we will be having glibc version of initrd udev, or no initrd version of udev at all, because nobody wants to do the porting to small libc's. and initrd getting bigger and bigger when added more tools into it, so older kernels (for newer compiled in default is increased, so it *could* fit) need ramdisk_size commandline override, thus can't be automated (need manually verified to see that initrd still does fit) so, it's more in to the "liking part" than "udev being bad" -- glen From baggins at pld-linux.org Mon Jul 2 12:07:18 2012 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 2 Jul 2012 12:07:18 +0200 Subject: lvm2 and initrd In-Reply-To: <4FF1455D.5010908@pld-linux.org> References: <4FF13585.7070000@pld-linux.org> <20120702062233.GB30162@jajo.eggsoft> <4FF1455D.5010908@pld-linux.org> Message-ID: <20120702100718.GP2741@sith.mimuw.edu.pl> On Mon, 02 Jul 2012, Elan Ruusam?e wrote: > On 07/02/2012 09:22 AM, Jacek Konieczny wrote: > > On Mon, Jul 02, 2012 at 08:45:41AM +0300, Elan Ruusam?e wrote: > >> > anyone interested working that out (so that udev can be again optional > >> > for rootfs on lvm systems)? > > Is udev on initrams that bad, that you just don't want to use it? Are > > there scenarios where udev just won't work? > well, there's continuous fight getting initrd versions of tools > compiled, as new releases tend to get broken with klibc/uclibc/... and > even if they compile with some patching, they can crash in some > configurations/architectures. AFAIR semaphore messages are harmless. > this could end up we will be having glibc version of initrd udev, or no > initrd version of udev at all, because nobody wants to do the porting to > small libc's. Porting, and lately even just static linking, becomes bigger and bigger RPITA, so we may have no choice than to having dynamic linked programs in initrd. I just don't see a reason to justify the extent of work one have to put into making klibc/uclibc/.../static built tools. > and initrd getting bigger and bigger when added more tools into it, so > older kernels (for newer compiled in default is increased, so it *could* > fit) need ramdisk_size commandline override, thus can't be automated > (need manually verified to see that initrd still does fit) It is not the case with initramfs. I have 40MB uncompressed initramfs made by dracut and it boots with our kernel. > so, it's more in to the "liking part" than "udev being bad" I, personally, would abandon our geninitrd in favor of dracut, yes it's large, but it just works, one initrams to boot any system. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From caleb at pld-linux.org Mon Jul 2 13:41:58 2012 From: caleb at pld-linux.org (Caleb Maclennan) Date: Mon, 2 Jul 2012 14:41:58 +0300 Subject: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm) In-Reply-To: <20120701201615.GB26904@lolek.nigdzie> References: <20120701085113.GA2435@lolek.nigdzie> <4FF0A947.7030302@pld-linux.org> <20120701201615.GB26904@lolek.nigdzie> Message-ID: 2012/7/1 Jacek Konieczny : > On Sun, Jul 01, 2012 at 10:47:19PM +0300, Elan Ruusam?e wrote: >> On 07/01/2012 11:51 AM, Jacek Konieczny wrote: >> > Do we need clvmd in the main lvm2 package? It pulls some dependencies >> > irrelevant for non-clustered setups. >> i'm in for moving clustered deps to subpackages. if it's doable. > > Already done. Theoretically this could break a cluster on upgrade, but > I don't think it would be a mass problem among PLD users ;) And > production clusters are not a thing one upgrades without testing. I have a cluster setup but nobody is going to die if it breaks on an upgrade ;) While I think in a case like this it is probably more important that we have current working packages than that we don't break old ones, I do think this kind of talk happening on the forum highlights the need for some sort of warning channel: If some package upgrade is EXPECTED to break current configurations, poldek should warn and even expect acknowledgement before proceeding with that package. Has the possibility of manually adding some sort of warning flag between certain upgrades been considered? Ideally all upgrades would just work, but with the number of developers and amount of testing we have right now, that is simply not practical. Sometimes we do things that we know will require intervention to work. We need a fool proof way to warn folks before their systems break. Thoughts about where this functionality should be introduced? Caleb From glen at pld-linux.org Mon Jul 2 16:01:05 2012 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 02 Jul 2012 17:01:05 +0300 Subject: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm) In-Reply-To: References: <20120701085113.GA2435@lolek.nigdzie> <4FF0A947.7030302@pld-linux.org> <20120701201615.GB26904@lolek.nigdzie> Message-ID: <4FF1A9A1.4030401@pld-linux.org> On 02.07.2012 14:41, Caleb Maclennan wrote: > Has the possibility of manually adding some sort of warning flag > between certain upgrades been considered? there is warning message that is displayed AFTER upgrade (via %triggerpostun or just %post) :) and if the upgrade breakage is really serious and detectable, package could abort upgrade with exit in %prein scriptlet. rarely used, afaik i saw it somewhere for warning before upgrades: read vcs commits list, pay attention to BIG FAT warnings :) -- glen From mike at osdn.org.ua Mon Jul 2 18:49:35 2012 From: mike at osdn.org.ua (Michael Shigorin) Date: Mon, 2 Jul 2012 19:49:35 +0300 Subject: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm) In-Reply-To: <4FF1A9A1.4030401@pld-linux.org> References: <20120701085113.GA2435@lolek.nigdzie> <4FF0A947.7030302@pld-linux.org> <20120701201615.GB26904@lolek.nigdzie> <4FF1A9A1.4030401@pld-linux.org> Message-ID: <20120702164934.GL14924@osdn.org.ua> On Mon, Jul 02, 2012 at 05:01:05PM +0300, Elan Ruusam??e wrote: > and if the upgrade breakage is really serious and detectable, > package could abort upgrade with exit in %prein scriptlet. > rarely used, afaik i saw it somewhere e.g. glibc-preinstall in ALT Linux :) -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From blues at pld-linux.org Mon Jul 2 23:38:25 2012 From: blues at pld-linux.org (=?ISO-8859-2?Q?Pawe=B3_Go=B3aszewski?=) Date: Mon, 2 Jul 2012 23:38:25 +0200 (CEST) Subject: packages: java-sun/java-sun.spec - up to 1.6.0.33, sources uploaded via dis... In-Reply-To: References: Message-ID: On Mon, 2 Jul 2012, glen wrote: > Author: glen Date: Mon Jul 2 14:39:18 2012 GMT > Module: packages Tag: HEAD > ---- Log message: > - up to 1.6.0.33, sources uploaded via distfiles; > - demos and samples available separately with bsd license, not packaging here as: > a) should update to 1.7, b) spec should be named java-oracle (or oracle-java?) Proposal: leave java-sun as 1.6.x line and make brand new package as oracle-java (or java-oracle). Rationale: there is a lot of places where java 1.6 is still required. And many where 1.7 has to be used... These must live together, at least on ftp. -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. From jajcus at jajcus.net Tue Jul 3 08:25:13 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 3 Jul 2012 08:25:13 +0200 Subject: packages: java-sun/java-sun.spec - up to 1.6.0.33, sources uploaded via dis... In-Reply-To: References: Message-ID: <20120703062512.GA16539@jajo.eggsoft> On Mon, Jul 02, 2012 at 11:38:25PM +0200, Pawe? Go?aszewski wrote: > Proposal: > leave java-sun as 1.6.x line and make brand new package as oracle-java (or > java-oracle). I don't like this ? this would suggest one comes from Sun, the other from Oracle, while both are from Oracle now and both were developed mainly by Sun. > Rationale: > there is a lot of places where java 1.6 is still required. And many where > 1.7 has to be used... These must live together, at least on ftp. Yes, that is a reason to keep 1.6 and 1.7 in different packages. As it is often called "Java 6" an "Java 7", then maybe we should package it as 'oracle-java6' and 'oracle-java7'? BTW. we should probably package IcedTea 7 too. Greets, Jacek From alucard at nospheratu.net Tue Jul 3 10:15:18 2012 From: alucard at nospheratu.net (Tomasz Rutkowski) Date: Tue, 03 Jul 2012 10:15:18 +0200 Subject: Cluster stuff (cman,dlm,heartbeat,corosync,openais,pacemaker,drbd,lvm) In-Reply-To: <20120701201335.GA26904@lolek.nigdzie> References: <20120701085113.GA2435@lolek.nigdzie> <20120701133657.GB2435@lolek.nigdzie> <20120701134154.GC2435@lolek.nigdzie> <1341156964.5024.13.camel@battleship> <20120701201335.GA26904@lolek.nigdzie> Message-ID: <1341303318.2382.7.camel@battleship> Dnia 2012-07-01, nie o godzinie 22:13 +0200, Jacek Konieczny pisze: > On Sun, Jul 01, 2012 at 05:36:04PM +0200, Tomasz Rutkowski wrote: > > cluster.spec was my work of 3rd generation of redhat cluster suite > > (dlm+cman+gfs2+rgmanager), there is bcond in lvm2 to complete stack, but > > it's already outdated (needs polishing :)) > > I have replaced this bcond with something more up to date. Currently > '3rd generation redhat cluster suite' is near being outdated. > > Keeping old cman and dlm as the default backend for lvmd just does not > make any sense now. > sorry, I'm on my vacations right now and family goes first... :) true, cluster2 line is outdated enough > > What do you mean by '3.1 won't build with pacemaker'? There was no > pacemaker dependency in cluster.spec > well, if You would like to control dlm space from within pacemaker You need daemon dlm_controld.pcmk - this one is build from cluster3 suite with pacemaker's files, perhaps You have made it build with 3.1 line, I haven't investigate much [at all I mean] why it's not building... (and You need dlm space for clvmd as far as I'm concerned) > > I have also played with pacemaker 1.1 (on branch currently) - after a > bit of patching works with corosync 1.4.3 for me, so I think it could > go to HEAD, unless there is a reason to keep pacemaker 1.0.x. Though, > I don't remember why I use 1.1 and not 1.0 ;) > me neither :) -- ------------------------------------------------------------------------ Tomasz Rutkowski , +48 604 419 913 , e-mail/xmpp: alucard at nospheratu.net ------------------------------------------------------------------------ From glen at pld-linux.org Tue Jul 3 13:22:29 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 03 Jul 2012 14:22:29 +0300 Subject: lvm2 and initrd In-Reply-To: <4FF1455D.5010908@pld-linux.org> References: <4FF13585.7070000@pld-linux.org> <20120702062233.GB30162@jajo.eggsoft> <4FF1455D.5010908@pld-linux.org> Message-ID: <4FF2D5F5.9050704@pld-linux.org> On 02.07.2012 09:53, Elan Ruusam?e wrote: > and initrd getting bigger and bigger when added more tools into it, so > older kernels (for newer compiled in default is increased, so it > *could* fit) need ramdisk_size commandline override, thus can't be > automated (need manually verified to see that initrd still does fit) also big initrd is problem of existing installations having /boot being small size, i have installations it being 32MB, 64MB, and custom is to have at least two kernel packages installed, current and future kernel. -- glen From mike at osdn.org.ua Tue Jul 3 13:50:26 2012 From: mike at osdn.org.ua (Michael Shigorin) Date: Tue, 3 Jul 2012 14:50:26 +0300 Subject: lvm2 and initrd In-Reply-To: <4FF1455D.5010908@pld-linux.org> References: <4FF13585.7070000@pld-linux.org> <20120702062233.GB30162@jajo.eggsoft> <4FF1455D.5010908@pld-linux.org> Message-ID: <20120703115026.GO14924@osdn.org.ua> On Mon, Jul 02, 2012 at 09:53:17AM +0300, Elan Ruusam?e wrote: > this could end up we will be having glibc version of initrd > udev, or no initrd version of udev at all, because nobody wants > to do the porting to small libc's. A colleague of mine experiments with musl and tells that so far things look pretty good. In the meanwhile ALT has moved to glibc based initrd but there's some hope to move it to musl (and maybe mdev but not sure on this): http://en.altlinux.org/Make-initrd http://www.altlinux.org/Make-initrd [ru] -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From jajcus at jajcus.net Tue Jul 3 13:50:29 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 3 Jul 2012 13:50:29 +0200 Subject: Cluster stuff (cman,dlm,heartbeat,corosync,openais,pacemaker,drbd,lvm) In-Reply-To: <1341303318.2382.7.camel@battleship> References: <20120701085113.GA2435@lolek.nigdzie> <20120701133657.GB2435@lolek.nigdzie> <20120701134154.GC2435@lolek.nigdzie> <1341156964.5024.13.camel@battleship> <20120701201335.GA26904@lolek.nigdzie> <1341303318.2382.7.camel@battleship> Message-ID: <20120703115029.GC16539@jajo.eggsoft> On Tue, Jul 03, 2012 at 10:15:18AM +0200, Tomasz Rutkowski wrote: > > > > What do you mean by '3.1 won't build with pacemaker'? There was no > > pacemaker dependency in cluster.spec > > > > well, if You would like to control dlm space from within pacemaker You > need daemon dlm_controld.pcmk - this one is build from cluster3 suite > with pacemaker's files, perhaps You have made it build with 3.1 line, > I haven't investigate much [at all I mean] why it's not building... > (and You need dlm space for clvmd as far as I'm concerned) I was working from I have found in the cluster.spec? there was not Pacemaker dependency that and nothing failed with my Pacemaker. As far as clvmd is concerned? I was not able to make it work with Pacemaker/corosync - yes that was probably the 'dlm_controld.pcmk' thing, but even Google couldn't help much (documentation for dlm/clvmd that is available is close to nothing). And I don't quite understand how the packages from cluster.spec are split (a dlm_conrold binary is in th group subpackage which pulls cman? but I didn't want cman and it didn't work anyway). Though, I was able to run clvmd with Pacemaker/openais/corosync and it seems that will be a good enough solution for me. openais does not look that scary as the stuff from cluster.spec ;) I can see place for improvement, though. Greets, Jacek From pluto at agmk.net Tue Jul 3 18:36:28 2012 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Tue, 03 Jul 2012 18:36:28 +0200 Subject: lvm2 and initrd In-Reply-To: <20120702100718.GP2741@sith.mimuw.edu.pl> References: <4FF13585.7070000@pld-linux.org> <4FF1455D.5010908@pld-linux.org> <20120702100718.GP2741@sith.mimuw.edu.pl> Message-ID: <2007206.Jz2pAZHX8L@localhost> On Monday 02 of July 2012 12:07:18 Jan R?korajski wrote: > On Mon, 02 Jul 2012, Elan Ruusam?e wrote: > > > On 07/02/2012 09:22 AM, Jacek Konieczny wrote: > > > On Mon, Jul 02, 2012 at 08:45:41AM +0300, Elan Ruusam?e wrote: > > >> > anyone interested working that out (so that udev can be again optional > > >> > for rootfs on lvm systems)? > > > Is udev on initrams that bad, that you just don't want to use it? Are > > > there scenarios where udev just won't work? > > well, there's continuous fight getting initrd versions of tools > > compiled, as new releases tend to get broken with klibc/uclibc/... and > > even if they compile with some patching, they can crash in some > > configurations/architectures. > > AFAIR semaphore messages are harmless. > > > this could end up we will be having glibc version of initrd udev, or no > > initrd version of udev at all, because nobody wants to do the porting to > > small libc's. > > Porting, and lately even just static linking, becomes bigger and bigger > RPITA, so we may have no choice than to having dynamic linked programs > in initrd. I just don't see a reason to justify the extent of work one > have to put into making klibc/uclibc/.../static built tools. we should use shared libc.so (~1.7MB @ x86-64) in initrd and build essential init tools with -Os optimization. -Os e.g. reduces mdadm size from 448kB to 380kB and 'upx -9' reduces binaries about the ~50% (better than gzip -9). i vote for drop any klibc/uclibc/glibc static linking. From glen at pld-linux.org Wed Jul 4 08:57:44 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 04 Jul 2012 09:57:44 +0300 Subject: packages: areca-cli/areca-cli.spec (NEW) - new; seems redistributable In-Reply-To: References: Message-ID: <4FF3E968.3090500@pld-linux.org> On 07/03/2012 11:16 PM, glen wrote: > Author: glen Date: Tue Jul 3 20:16:47 2012 GMT > Module: packages Tag: HEAD > ---- Log message: > - new; seems redistributable > > ---- Files affected: > packages/areca-cli: > areca-cli.spec (NONE -> 1.1) (NEW) > > ---- Diffs: > > ================================================================ > Index: packages/areca-cli/areca-cli.spec > diff -u /dev/null packages/areca-cli/areca-cli.spec:1.1 > --- /dev/null Tue Jul 3 22:16:47 2012 > +++ packages/areca-cli/areca-cli.spec Tue Jul 3 22:16:42 2012 > @@ -0,0 +1,55 @@ > +# $Revision$, $Date$ > +Summary: Utility to control Areca SATA RAID controllers > +Name: areca-cli > +Version: 1.86 > +Release: 1 > +# http://www.areca.us/support/download/RaidCards/Documents/Manual_Spec/Downloadable_Software_Licenses.zip > +# Linux Exception: redistributable if not modified > +License: License for Customer Use of Areca Software can somebody read the license and check whether we can repackage and distribute it? -- glen From draenog at pld-linux.org Wed Jul 4 18:39:56 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Wed, 4 Jul 2012 18:39:56 +0200 Subject: Git migration: beta version Message-ID: <20120704163956.GC17987@camk.edu.pl> I'm sorry but this time only English version. The beta version of git setup is in place. Basic informations: 1. Access: git://git.pld-linux.org/packages/ ssh://git at git.pld-linux.org/packages/ You can try to fetch packages and upload your changes. Don't be afraid to break something. Anny changes you will make will be overwritten during the final migration. 3. Web interface: http://git.pld-linux.org/ Displaying the list of all packages can be a little slow. So probably you want to use http://git.pld-linux.org/packages/ 2. Mailing list with commit notifications: test at lists.pld.linux.org Right now two types of notifications are sent to the list: a. commits relating to single branch are grouped into one email b. every commit go to a single email. For example: http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000052.html and http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000053.html http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000054.html We need to decide which version is preferred. 3. ciabot - switched off for now 4. Updated builder.sh script: git://github.com/draenog/rpm-build-tools 5. Updated version of tool to fetch changed repositories more efficiently: git-core-slug-0.12-1. Please read man slug.py 6. Documentation: http://www.pld-linux.org/dokuwiki/howto-git http://www.pld-linux.org/dokuwiki/cvs2git Any bug reports, comments etc. more then welcome. -- Kacper From pluto at agmk.net Wed Jul 4 19:27:53 2012 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Wed, 04 Jul 2012 19:27:53 +0200 Subject: Git migration: beta version In-Reply-To: <20120704163956.GC17987@camk.edu.pl> References: <20120704163956.GC17987@camk.edu.pl> Message-ID: <2745437.d80T7EKsbO@localhost> On Wednesday 04 of July 2012 18:39:56 Kacper Kornet wrote: > I'm sorry but this time only English version. > > > The beta version of git setup is in place. Basic informations: > > 1. Access: git://git.pld-linux.org/packages/ > ssh://git at git.pld-linux.org/packages/ > > You can try to fetch packages and upload your changes. ssh access doesn't work on port 22. on port 24 it works only for user git. what about access via custom ssh-keys? From draenog at pld-linux.org Wed Jul 4 19:36:39 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Wed, 4 Jul 2012 19:36:39 +0200 Subject: Git migration: beta version In-Reply-To: <2745437.d80T7EKsbO@localhost> References: <20120704163956.GC17987@camk.edu.pl> <2745437.d80T7EKsbO@localhost> Message-ID: <20120704173639.GA18375@camk.edu.pl> On Wed, Jul 04, 2012 at 07:27:53PM +0200, Pawe? Sikora wrote: > On Wednesday 04 of July 2012 18:39:56 Kacper Kornet wrote: > > I'm sorry but this time only English version. > > The beta version of git setup is in place. Basic informations: > > 1. Access: git://git.pld-linux.org/packages/ > > ssh://git at git.pld-linux.org/packages/ > > You can try to fetch packages and upload your changes. > ssh access doesn't work on port 22. fixed > on port 24 it works only for user git. Everybodu shoud use user git. > what about access via custom ssh-keys? Your key should work for user git. -- Kacper From pluto at agmk.net Wed Jul 4 20:28:07 2012 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Wed, 04 Jul 2012 20:28:07 +0200 Subject: Git migration: beta version In-Reply-To: <20120704163956.GC17987@camk.edu.pl> References: <20120704163956.GC17987@camk.edu.pl> Message-ID: <6241433.AsNtMgyAuM@localhost> On Wednesday 04 of July 2012 18:39:56 Kacper Kornet wrote: > Any bug reports, comments etc. more then welcome. 1). do we really need two notifications for single event? http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000062.html http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000063.html 2). "[x/n] naming" for consistency, the short merge description http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000066.html should be called a "[0/n] merge foo branch" and following "[{1..n}/n]" patches should be sent as a reply to the "0/n" (for easier emails threading). or... the [x/n] marking should be dropped at all. moreover, these notifications duplicate information from 'branch master updated' emails. imho, too much redundant notifications around the merge event. From draenog at pld-linux.org Wed Jul 4 20:51:24 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Wed, 4 Jul 2012 20:51:24 +0200 Subject: Git migration: beta version In-Reply-To: <6241433.AsNtMgyAuM@localhost> References: <20120704163956.GC17987@camk.edu.pl> <6241433.AsNtMgyAuM@localhost> Message-ID: <20120704185124.GB18375@camk.edu.pl> On Wed, Jul 04, 2012 at 08:28:07PM +0200, Pawe? Sikora wrote: > On Wednesday 04 of July 2012 18:39:56 Kacper Kornet wrote: > > Any bug reports, comments etc. more then welcome. > 1). do we really need two notifications for single event? > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000062.html > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000063.html We have to choose one of them. All commits per branch per push in one mail (emails without [] brackets in subject), or one commit per email (emails with [] brackets in subjects). Right now there are two to show possible options. > 2). "[x/n] naming" > for consistency, the short merge description > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000066.html > should be called a "[0/n] merge foo branch" and following "[{1..n}/n]" patches should > be sent as a reply to the "0/n" (for easier emails threading). The first mail (without numbers) is a sort of description. It never contains a diff so it has no number. It shows which numbers in sequence (1..n)/n will be missing. I will check what can be done about threading. > or... the [x/n] marking should be dropped at all. > moreover, these notifications duplicate information from 'branch master updated' emails. > imho, too much redundant notifications around the merge event. As I have written above. Right now there is some redundancy to show possible options. Depending on the choice we will make you can ignore emails with or without [] brackets in subjects. -- Kacper From pluto at agmk.net Thu Jul 5 21:03:45 2012 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Thu, 05 Jul 2012 21:03:45 +0200 Subject: Git migration: beta version In-Reply-To: <20120704185124.GB18375@camk.edu.pl> References: <20120704163956.GC17987@camk.edu.pl> <6241433.AsNtMgyAuM@localhost> <20120704185124.GB18375@camk.edu.pl> Message-ID: <1554910.OS0mjm6iGr@localhost> On Wednesday 04 of July 2012 20:51:24 Kacper Kornet wrote: > On Wed, Jul 04, 2012 at 08:28:07PM +0200, Pawe? Sikora wrote: > > On Wednesday 04 of July 2012 18:39:56 Kacper Kornet wrote: > > > > Any bug reports, comments etc. more then welcome. > > > 1). do we really need two notifications for single event? > > > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000062.html > > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000063.html > > We have to choose one of them. All commits per branch per push in one > mail (emails without [] brackets in subject), or one commit per email > (emails with [] brackets in subjects). Right now there are two to show > possible options. i would prefer the "[packages/foo] branch ... created." with attached diff from 000062.html From draenog at pld-linux.org Thu Jul 5 23:13:16 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Thu, 5 Jul 2012 23:13:16 +0200 Subject: Git migration: beta version In-Reply-To: <1554910.OS0mjm6iGr@localhost> References: <20120704163956.GC17987@camk.edu.pl> <6241433.AsNtMgyAuM@localhost> <20120704185124.GB18375@camk.edu.pl> <1554910.OS0mjm6iGr@localhost> Message-ID: <20120705211316.GB24157@camk.edu.pl> On Thu, Jul 05, 2012 at 09:03:45PM +0200, Pawe? Sikora wrote: > On Wednesday 04 of July 2012 20:51:24 Kacper Kornet wrote: > > On Wed, Jul 04, 2012 at 08:28:07PM +0200, Pawe? Sikora wrote: > > > On Wednesday 04 of July 2012 18:39:56 Kacper Kornet wrote: > > > > Any bug reports, comments etc. more then welcome. > > > 1). do we really need two notifications for single event? > > > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000062.html > > > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000063.html > > We have to choose one of them. All commits per branch per push in one > > mail (emails without [] brackets in subject), or one commit per email > > (emails with [] brackets in subjects). Right now there are two to show > > possible options. > i would prefer the "[packages/foo] branch ... created." with attached diff from 000062.html In messages with [] every commit goes to separate mail. So when a new branch is created first the covering mail is sent, and then one email with diff per new commit. What you ask is to combine covering mail with the diff. But what about the case is when the creation of new branch is combined with more then one commits? Which diff should go to the covering mail? In the meantime I have added threading of messages. So now new branch creation looks like in the thread starting with mail: http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000132.html -- Kacper From jajcus at jajcus.net Fri Jul 6 08:22:31 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Fri, 6 Jul 2012 08:22:31 +0200 Subject: Git migration: beta version In-Reply-To: <20120705211316.GB24157@camk.edu.pl> References: <20120704163956.GC17987@camk.edu.pl> <6241433.AsNtMgyAuM@localhost> <20120704185124.GB18375@camk.edu.pl> <1554910.OS0mjm6iGr@localhost> <20120705211316.GB24157@camk.edu.pl> Message-ID: <20120706062231.GA19263@jajo.eggsoft> On Thu, Jul 05, 2012 at 11:13:16PM +0200, Kacper Kornet wrote: > In the meantime I have added threading of messages. So now new branch > creation looks like in the thread starting with mail: > > http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/000132.html All commits in a single 'commit pack' should only reference the leading mail IMHO, not each one the previous one. No need for (n+1)-levels deep thread for n commits sent at once. The leading mail could reference to previous change set, though. Greets, Jacek From caleb at pld-linux.org Fri Jul 6 10:46:36 2012 From: caleb at pld-linux.org (Caleb Maclennan) Date: Fri, 6 Jul 2012 11:46:36 +0300 Subject: cdg: proponowane-glosowania/cdg_membership_caleb - temporarily withdraw my ... In-Reply-To: References: Message-ID: > - temporarily withdraw my second; let's wait a week or two and see how caleb's > current projects with regards to the cdg go; if he succeeds, that means he > might be of use at conflict resolution; if he fails, he fails, and there's > no point in granting him cdg membership at the present time So was my nomination to CDG based sole on my suggestions relevant to a particular problem? With that problem taken care of another way is my participation considered irrelevant? Should I apply through another channel if I'm actually interested for other reasons too? Caleb From glen at pld-linux.org Fri Jul 6 16:03:27 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Fri, 06 Jul 2012 17:03:27 +0300 Subject: gcc-dirs Message-ID: <4FF6F02F.9030106@pld-linux.org> $ rpm -qf /usr/lib64/gcc/ gcc-dirs-1.0-5.x86_64 gcc-4.7.1-4.x86_64 what should be here? i understand the gcc-dirs was added for cross-gcc packages? seems the change itself which added dir to gcc package is old as first gcc4 in HEAD: http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/packages/gcc/gcc.spec?r1=1.283&r2=1.284& -- glen From qboosh at pld-linux.org Fri Jul 6 18:17:35 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 6 Jul 2012 18:17:35 +0200 Subject: packages: cloog-ppl/cloog-ppl.spec - conflict before split In-Reply-To: References: Message-ID: <20120706161735.GA21209@mail> On Fri, Jul 06, 2012 at 10:43:02AM +0200, glen wrote: > Author: glen Date: Fri Jul 6 08:43:01 2012 GMT > Module: packages Tag: HEAD > ---- Log message: > - conflict before split > > ---- Files affected: > packages/cloog-ppl: > cloog-ppl.spec (1.8 -> 1.9) > > ---- Diffs: > @@ -44,6 +44,7 @@ > Summary: Chunky Loop Generator shared library - ppl based version > Summary(pl.UTF-8): Biblioteka wsp??dzielona Chunky Loop Generatora - wersja oparta na ppl > Group: Libraries > +Conflicts: %{name} < 0.16.1-1 No need to: before split (cloog-ppl 0.15.x) shared libs were named libcloog.so*, while in cloog-ppl 0.16+ there are libcloog-ppl.so* -- Jakub Bogusz http://qboosh.pl/ From wolf.pld at gmail.com Fri Jul 6 19:34:50 2012 From: wolf.pld at gmail.com (Bartosz Taudul) Date: Fri, 6 Jul 2012 19:34:50 +0200 Subject: cdg: proponowane-glosowania/cdg_membership_caleb - temporarily withdraw my ... In-Reply-To: References: Message-ID: On Fri, Jul 6, 2012 at 10:46 AM, Caleb Maclennan wrote: >> - temporarily withdraw my second; let's wait a week or two and see how caleb's >> current projects with regards to the cdg go; if he succeeds, that means he >> might be of use at conflict resolution; if he fails, he fails, and there's >> no point in granting him cdg membership at the present time > > So was my nomination to CDG based sole on my suggestions relevant to a > particular problem? With that problem taken care of another way is my > participation considered irrelevant? I told you it's just a stupid kindergarten power play. Some people never learn... wolf From caleb at pld-linux.org Fri Jul 6 22:51:17 2012 From: caleb at pld-linux.org (Caleb Maclennan) Date: Fri, 6 Jul 2012 23:51:17 +0300 Subject: cdg: proponowane-glosowania/cdg_membership_caleb - temporarily withdraw my ... In-Reply-To: References: Message-ID: 2012/7/6 Bartosz Taudul : > I told you it's just a stupid kindergarten power play. Some people > never learn... Look. If all you guys want is to make me part of a power play, please just count me out. Don't vote for me. I'm not interested in joining a pre-school. I skipped that the first time around and don't think I really missed out in life. On the other hand if folks around here (you too wolf) have something else in mind -- a little more mature perhaps -- maybe working together in a professional manner -- step by step moving things forward in a way that is useful to us and keeping things as clean as possible to encourage new participation, then consider a vote. I realize CDG doesn't have the power to command forward motion, but it can help settle internal disagreements as they come up. If this is done effectively we can cultivate an environment where innovation continues. If you don't have reason to believe I would act with good judgement when the time comes for that, don't vote. Caleb From qboosh at pld-linux.org Sun Jul 8 09:54:45 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 8 Jul 2012 09:54:45 +0200 Subject: texlive - files duplicate Message-ID: <20120708075445.GA24742@mail> poldek:/all-avail> desc -ll texlive-fonts-marvosym-20080816-19.i686 [...] -rw-r--r-- 1440 /usr/share/texmf-dist/source/fonts/eurofont/marvosym/tfmfiles/yandy/fmvr8x.tfm -rw-r--r-- 1576 /usr/share/texmf-dist/source/fonts/eurofont/marvosym/tfmfiles/yandy/fmvri8x.tfm drwxr-xr-x 28672 /usr/share/texmf-dist/tex/latex/ drwxr-xr-x 39 /usr/share/texmf-dist/tex/latex/marvosym/ -rw-r--r-- 6578 /usr/share/texmf-dist/tex/latex/marvosym/marvosym.sty -rw-r--r-- 111 /usr/share/texmf-dist/tex/latex/marvosym/umvs.fd poldek:/all-avail> desc -ll texlive-latex-marvosym-20080816-19.i686 Package: texlive-latex-marvosym-20080816-19.i686 mode rozmiar nazwa drwxr-xr-x 39 /usr/share/texmf-dist/tex/latex/marvosym/ -rw-r--r-- 6578 /usr/share/texmf-dist/tex/latex/marvosym/marvosym.sty -rw-r--r-- 111 /usr/share/texmf-dist/tex/latex/marvosym/umvs.fd poldek:/all-avail> desc -r texlive-latex-marvosym-20080816-19.i686 Package: texlive-latex-marvosym-20080816-19.i686 Requires: /bin/sh, /bin/sh, /usr/bin/texhash, texlive-fonts-marvosym = 1:20080816-19, ^^^^^^^^^^^^^^^^^^^^^^ texlive-latex = 1:20080816-19 Requires(rpm): rpmlib(PayloadIsLzma) <= 4.4.6-1 Requires(dir): /usr/share/texmf-dist/tex/latex ...so I suppose %{_datadir}/texmf-dist/tex/latex should be removed from texlive-fonts-marvosym -- Jakub Bogusz http://qboosh.pl/ From udvzsolt at gmail.com Sun Jul 8 14:06:01 2012 From: udvzsolt at gmail.com (Zsolt Udvari) Date: Sun, 8 Jul 2012 14:06:01 +0200 Subject: texlive - files duplicate In-Reply-To: <20120708075445.GA24742@mail> References: <20120708075445.GA24742@mail> Message-ID: > ...so I suppose %{_datadir}/texmf-dist/tex/latex should be removed from > texlive-fonts-marvosym Feel free to do it! Yes, the texlive packages aren't perfect so anybody can change it if (s)he find any bug in spec. Zsolt From draenog at pld-linux.org Sun Jul 8 16:17:09 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Sun, 8 Jul 2012 16:17:09 +0200 Subject: CVS down - git migration Message-ID: <20120708141709.GA8114@camk.edu.pl> Due to git migration, write access to packages in CVS will be disabled in around 45 minutes. -- Kacper From glen at pld-linux.org Sun Jul 8 22:05:58 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sun, 08 Jul 2012 23:05:58 +0300 Subject: CVS down - git migration In-Reply-To: <20120708141709.GA8114@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> Message-ID: <4FF9E826.3030406@pld-linux.org> On 07/08/2012 05:17 PM, Kacper Kornet wrote: > Due to git migration, write access to packages in CVS will be disabled in > around 45 minutes. > shouldn't such big things be at least announced before they are performed? i haven't caught any mail that git migration is performed this weekend and so on -- glen From draenog at pld-linux.org Mon Jul 9 04:19:47 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 9 Jul 2012 04:19:47 +0200 Subject: CVS down - git migration In-Reply-To: <20120708141709.GA8114@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> Message-ID: <20120709021947.GC17298@camk.edu.pl> On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > Due to git migration, write access to packages in CVS will be disabled in > around 45 minutes. So the official repositories of PLD packages are now in git: git://git.pld-linux.org/packages/* ssh://git at pld-linux.org/packages/* The builders, distfiles, commit list and ciabot seem to work. Please let me know if you encounter any problems. -- Kacper From draenog at pld-linux.org Mon Jul 9 05:09:04 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 9 Jul 2012 05:09:04 +0200 Subject: Git in PLD - basic HOWTO Message-ID: <20120709030904.GE17298@camk.edu.pl> * Servers --------- Anonymous access git://git.pld-linux.org Developers have an rw acces by ssh: ssh://git at git.pld-linux.org Note: Every developer should use the same account: git * Builder script ---------------- Version which can work with git repositories you can find in packet rpm-build-tools-4.5-3.noarch on ftp. Probably a good idea is to set up an rpm directory hierarchy from the scratch: $ mv rpm rpm.cv $ builder --init-rpm-dir Most options should have the same syntax and functionality as in version working with CVS * Some documentation -------------------- For some basic introduction to git and how to use it to work with PLD repositories please see: http://www.pld-linux.org/dokuwiki/howto-git http://www.pld-linux.org/dokuwiki/cvs2git * Work with many repositories ----------------------------- Program slug.py from git-core-slug tries to facilitate work with many repositories at once. Please see: man slug.py -- Kacper From baggins at pld-linux.org Mon Jul 9 07:49:43 2012 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 9 Jul 2012 07:49:43 +0200 Subject: CVS down - git migration In-Reply-To: <20120709021947.GC17298@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> Message-ID: <20120709054943.GA22576@sith.mimuw.edu.pl> On Mon, 09 Jul 2012, Kacper Kornet wrote: > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > > Due to git migration, write access to packages in CVS will be disabled in > > around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > ssh://git at pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > me know if you encounter any problems. There were some scripts and other files directly under packages/ : adapter adapter.awk bconds.txt builder check-unused-files.py ci civim clean-distfiles.sh compile.sh COPYING dropin fetchsrc_request get-all-specs.sh kde4brs.sh kde4devel2head.sh kde4diff.sh kde4finddescs.sh kde4qtbrs.sh kdediff.sh md5 mirrors pear-autoup.sh pearize.sh pldnotify.awk relup.sh repackage.sh rpm.groups spec_utf8 What happened to them? -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From baggins at pld-linux.org Mon Jul 9 08:16:17 2012 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 9 Jul 2012 08:16:17 +0200 Subject: CVS down - git migration In-Reply-To: <20120709021947.GC17298@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> Message-ID: <20120709061617.GB22576@sith.mimuw.edu.pl> On Mon, 09 Jul 2012, Kacper Kornet wrote: > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > > Due to git migration, write access to packages in CVS will be disabled in > > around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > ssh://git at pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > me know if you encounter any problems. slug.py doesn't like my '?' in 'name' in .gitconfig. [baggins at sith rpm]$ git pld list Traceback (most recent call last): File "/usr/lib64/git-core/git-pld", line 212, in parser.set_defaults(**readconfig(os.path.expanduser('~/.gitconfig'))) File "/usr/lib64/git-core/git-pld", line 51, in readconfig config.read(path) File "/usr/share/python3.2/configparser.py", line 689, in read self._read(fp, filename) File "/usr/share/python3.2/configparser.py", line 994, in _read for lineno, line in enumerate(fp, start=1): File "/usr/share/python3.2/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 20: ordinal not in range(128) -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From draenog at pld-linux.org Mon Jul 9 10:18:25 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 9 Jul 2012 10:18:25 +0200 Subject: CVS down - git migration In-Reply-To: <20120709061617.GB22576@sith.mimuw.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709061617.GB22576@sith.mimuw.edu.pl> Message-ID: <20120709081825.GA8786@camk.edu.pl> On Mon, Jul 09, 2012 at 08:16:17AM +0200, Jan R?korajski wrote: > On Mon, 09 Jul 2012, Kacper Kornet wrote: > > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > > > Due to git migration, write access to packages in CVS will be disabled in > > > around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > > ssh://git at pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > > me know if you encounter any problems. > slug.py doesn't like my '?' in 'name' in .gitconfig. > [baggins at sith rpm]$ git pld list > Traceback (most recent call last): > File "/usr/lib64/git-core/git-pld", line 212, in > parser.set_defaults(**readconfig(os.path.expanduser('~/.gitconfig'))) > File "/usr/lib64/git-core/git-pld", line 51, in readconfig > config.read(path) > File "/usr/share/python3.2/configparser.py", line 689, in read > self._read(fp, filename) > File "/usr/share/python3.2/configparser.py", line 994, in _read > for lineno, line in enumerate(fp, start=1): > File "/usr/share/python3.2/encodings/ascii.py", line 26, in decode > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 20: > ordinal not in range(128) I am able to reproduce it if I set my locale to inconsisten state with the encoding used in .gitconfig. -- Kacper From baggins at pld-linux.org Mon Jul 9 10:21:11 2012 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 9 Jul 2012 10:21:11 +0200 Subject: CVS down - git migration In-Reply-To: <20120709081825.GA8786@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709061617.GB22576@sith.mimuw.edu.pl> <20120709081825.GA8786@camk.edu.pl> Message-ID: <20120709082111.GE2741@sith.mimuw.edu.pl> On Mon, 09 Jul 2012, Kacper Kornet wrote: > On Mon, Jul 09, 2012 at 08:16:17AM +0200, Jan R?korajski wrote: > > On Mon, 09 Jul 2012, Kacper Kornet wrote: > > > > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > > > > Due to git migration, write access to packages in CVS will be disabled in > > > > around 45 minutes. > > > > So the official repositories of PLD packages are now in git: > > > > git://git.pld-linux.org/packages/* > > > ssh://git at pld-linux.org/packages/* > > > > The builders, distfiles, commit list and ciabot seem to work. Please let > > > me know if you encounter any problems. > > > slug.py doesn't like my '?' in 'name' in .gitconfig. > > > [baggins at sith rpm]$ git pld list > > Traceback (most recent call last): > > File "/usr/lib64/git-core/git-pld", line 212, in > > parser.set_defaults(**readconfig(os.path.expanduser('~/.gitconfig'))) > > File "/usr/lib64/git-core/git-pld", line 51, in readconfig > > config.read(path) > > File "/usr/share/python3.2/configparser.py", line 689, in read > > self._read(fp, filename) > > File "/usr/share/python3.2/configparser.py", line 994, in _read > > for lineno, line in enumerate(fp, start=1): > > File "/usr/share/python3.2/encodings/ascii.py", line 26, in decode > > return codecs.ascii_decode(input, self.errors)[0] > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 20: > > ordinal not in range(128) > > I am able to reproduce it if I set my locale to inconsisten state with > the encoding used in .gitconfig. [baggins at sith rpm]$ locale LANG=en_US.UTF-8 LC_CTYPE=pl_PL.UTF-8 LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= UTF-8 everywhere. Nothing inconsistent here. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From baggins at pld-linux.org Mon Jul 9 12:14:08 2012 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 9 Jul 2012 12:14:08 +0200 Subject: CVS down - git migration In-Reply-To: <20120709061617.GB22576@sith.mimuw.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709061617.GB22576@sith.mimuw.edu.pl> Message-ID: <20120709101408.GG2741@sith.mimuw.edu.pl> On Mon, 09 Jul 2012, Jan R?korajski wrote: > On Mon, 09 Jul 2012, Kacper Kornet wrote: > > > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > > > Due to git migration, write access to packages in CVS will be disabled in > > > around 45 minutes. > > > > So the official repositories of PLD packages are now in git: > > > > git://git.pld-linux.org/packages/* > > ssh://git at pld-linux.org/packages/* > > > > The builders, distfiles, commit list and ciabot seem to work. Please let > > me know if you encounter any problems. > > slug.py doesn't like my '?' in 'name' in .gitconfig. Problem solved, I had python3 for wrong arch (poldek in multilib mode pulled python3 for i686, instead of x66_64). -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From adamg at pld-linux.org Mon Jul 9 13:42:31 2012 From: adamg at pld-linux.org (Adam Golebiowski) Date: Mon, 9 Jul 2012 13:42:31 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120709030904.GE17298@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> Message-ID: <20120709114230.GA4390@adamg.eu> On Mon, Jul 09, 2012 at 05:09:04AM +0200, Kacper Kornet wrote: > * Servers > --------- > Anonymous access > > git://git.pld-linux.org > > Developers have an rw acces by ssh: > > ssh://git at git.pld-linux.org is there away to manipulate list of ssh keys or do you need to add / delete them manually? -- adamg From draenog at pld-linux.org Mon Jul 9 13:56:28 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 9 Jul 2012 13:56:28 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120709114230.GA4390@adamg.eu> References: <20120709030904.GE17298@camk.edu.pl> <20120709114230.GA4390@adamg.eu> Message-ID: <20120709115628.GM8786@camk.edu.pl> On Mon, Jul 09, 2012 at 01:42:31PM +0200, Adam Golebiowski wrote: > On Mon, Jul 09, 2012 at 05:09:04AM +0200, Kacper Kornet wrote: > > * Servers > > --------- > > Anonymous access > > git://git.pld-linux.org > > Developers have an rw acces by ssh: > > ssh://git at git.pld-linux.org > is there away to manipulate list of ssh keys or do you need to > add / delete them manually? Yes, there is. You can use: ssh git at git.pld-linux.org sskm Instrukcja: http://sitaramc.github.com/gitolite/sskm.html -- Kacper From glen at delfi.ee Mon Jul 9 14:21:29 2012 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 09 Jul 2012 15:21:29 +0300 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <20120709054943.GA22576@sith.mimuw.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> Message-ID: <4FFACCC9.4060503@delfi.ee> On 09.07.2012 08:49, Jan R?korajski wrote: > There were some scripts and other files directly under packages/ : > > adapter > adapter.awk > bconds.txt > builder > check-unused-files.py > ci > civim > clean-distfiles.sh > compile.sh > COPYING > dropin > fetchsrc_request > get-all-specs.sh > kde4brs.sh > kde4devel2head.sh > kde4diff.sh > kde4finddescs.sh > kde4qtbrs.sh > kdediff.sh > md5 > mirrors > pear-autoup.sh > pearize.sh > pldnotify.awk > relup.sh > repackage.sh > rpm.groups > spec_utf8 > > What happened to them? > yes, i particularily miss those scripts, so i symlinked them from cvs dir until somebody decides to migrate them somewhere in git: glen at carme-pld packages/phpstorm $ cd .. glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/compile.sh glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/dropin glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/md5 glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/pearize.sh glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/pldnotify.awk glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/relup.sh glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/repackage.sh glen at carme-pld ~/rpm/packages $ those (except pldnotify.awk and pearize.sh) are daily tools used to manage pld packages developing do they all fit to rpm-build-tools git repo? can those be imported with full cvs history? -- glen From kornet at camk.edu.pl Mon Jul 9 14:40:57 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Mon, 9 Jul 2012 14:40:57 +0200 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <4FFACCC9.4060503@delfi.ee> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> Message-ID: <20120709124056.GP8786@camk.edu.pl> On Mon, Jul 09, 2012 at 03:21:29PM +0300, Elan Ruusam?e wrote: > On 09.07.2012 08:49, Jan R?korajski wrote: > >There were some scripts and other files directly under packages/ : > >adapter > >adapter.awk > >bconds.txt > >builder > >check-unused-files.py > >ci > >civim > >clean-distfiles.sh > >compile.sh > >COPYING > >dropin > >fetchsrc_request > >get-all-specs.sh > >kde4brs.sh > >kde4devel2head.sh > >kde4diff.sh > >kde4finddescs.sh > >kde4qtbrs.sh > >kdediff.sh > >md5 > >mirrors > >pear-autoup.sh > >pearize.sh > >pldnotify.awk > >relup.sh > >repackage.sh > >rpm.groups > >spec_utf8 > >What happened to them? > yes, i particularily miss those scripts, so i symlinked them from > cvs dir until somebody decides to migrate them somewhere in git: > glen at carme-pld packages/phpstorm $ cd .. > glen at carme-pld ~/rpm/packages $ ln -s > ../../rpm.cvs/packages/packages/compile.sh > glen at carme-pld ~/rpm/packages $ ln -s > ../../rpm.cvs/packages/packages/dropin > glen at carme-pld ~/rpm/packages $ ln -s ../../rpm.cvs/packages/packages/md5 > glen at carme-pld ~/rpm/packages $ ln -s > ../../rpm.cvs/packages/packages/pearize.sh > glen at carme-pld ~/rpm/packages $ ln -s > ../../rpm.cvs/packages/packages/pldnotify.awk > glen at carme-pld ~/rpm/packages $ ln -s > ../../rpm.cvs/packages/packages/relup.sh > glen at carme-pld ~/rpm/packages $ ln -s > ../../rpm.cvs/packages/packages/repackage.sh > glen at carme-pld ~/rpm/packages $ > those (except pldnotify.awk and pearize.sh) are daily tools used to > manage pld packages developing > do they all fit to rpm-build-tools git repo? can those be imported > with full cvs history? Yes, they can be imported with cvs history if we only agree on the name of a packages to which they should be put. -- Kacper From glen at delfi.ee Mon Jul 9 15:17:27 2012 From: glen at delfi.ee (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=) Date: Mon, 09 Jul 2012 16:17:27 +0300 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <20120709124056.GP8786@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> Message-ID: <4FFAD9E7.9080406@delfi.ee> On 09.07.2012 15:40, Kacper Kornet wrote: >> > those (except pldnotify.awk and pearize.sh) are daily tools used to >> > manage pld packages developing >> > do they all fit to rpm-build-tools git repo? can those be imported >> > with full cvs history? > Yes, they can be imported with cvs history if we only agree on the name > of a packages to which they should be put. my vote: put them into rpm-build-tools with names they already have. if needed to remove, these can be renamed later also when migrated, block their commits in acl (if not already so) -- glen From kiesiu at pld-linux.org Mon Jul 9 17:33:15 2012 From: kiesiu at pld-linux.org (Lukasz Kies) Date: Mon, 9 Jul 2012 17:33:15 +0200 Subject: CVS down - git migration In-Reply-To: <20120709021947.GC17298@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> Message-ID: 2012/7/9 Kacper Kornet : > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: >> Due to git migration, write access to packages in CVS will be disabled in >> around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > ssh://git at pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > me know if you encounter any problems. > What "name" is passed to CIA bot as author? Take a look on an example commit from qboosh: 17:08 <+CIA-121> jakub master * packages/git-core-slug/git-core-slug.spec: It should be qboosh I think. If it's from author's email then after quick look on cvs.authors it will breake some stats on cia or ohloh stats and probably in some other places. -- Regards, Lukasz From kiesiu at pld-linux.org Mon Jul 9 17:37:38 2012 From: kiesiu at pld-linux.org (Lukasz Kies) Date: Mon, 9 Jul 2012 17:37:38 +0200 Subject: CVS down - git migration In-Reply-To: References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> Message-ID: 2012/7/9 Lukasz Kies : > 2012/7/9 Kacper Kornet : >> On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: >>> Due to git migration, write access to packages in CVS will be disabled in >>> around 45 minutes. >> >> So the official repositories of PLD packages are now in git: >> >> git://git.pld-linux.org/packages/* >> ssh://git at pld-linux.org/packages/* >> >> The builders, distfiles, commit list and ciabot seem to work. Please let >> me know if you encounter any problems. >> > What "name" is passed to CIA bot as author? Take a look on an example > commit from qboosh: > 17:08 <+CIA-121> jakub master * packages/git-core-slug/git-core-slug.spec: > It should be qboosh I think. > > If it's from author's email then after quick look on cvs.authors it > will breake some stats on cia or ohloh stats and probably in some > other places. > One more. In plain english following email notification on mail lists means new package? [packages/sblim-cmpi-base] Created branch master Now it's totally confusing. And there is nothing sent to CIA boot at all in such case. -- Regards, Lukasz From qboosh at pld-linux.org Mon Jul 9 17:39:33 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 9 Jul 2012 17:39:33 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120709030904.GE17298@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> Message-ID: <20120709153933.GD1095@stranger.qboosh.pl> Is there any way to change mistaken changelog entry after push? -- Jakub Bogusz http://qboosh.pl/ From kornet at camk.edu.pl Mon Jul 9 17:55:35 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Mon, 9 Jul 2012 17:55:35 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120709153933.GD1095@stranger.qboosh.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120709153933.GD1095@stranger.qboosh.pl> Message-ID: <20120709155535.GE13534@camk.edu.pl> On Mon, Jul 09, 2012 at 05:39:33PM +0200, Jakub Bogusz wrote: > Is there any way to change mistaken changelog entry after push? If you ask about changelog generated during build process and included in rpm, then yes. If the commit is annotated with git-notes in name space refs/notes/commits, then this note is used instead of commitlog. I will write a small howto describing the process. But you can see an example in package dosemu. Please look in gitk at commit 1478030904125f1f0180e144ed4312ae8754f63f Original commit log was "- fixed previous fix." and then it was changed to a one with dot discarded . -- Kacper From draenog at pld-linux.org Mon Jul 9 18:00:16 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 9 Jul 2012 18:00:16 +0200 Subject: CVS down - git migration In-Reply-To: References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> Message-ID: <20120709160016.GF13534@camk.edu.pl> On Mon, Jul 09, 2012 at 05:33:15PM +0200, Lukasz Kies wrote: > 2012/7/9 Kacper Kornet : > > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > >> Due to git migration, write access to packages in CVS will be disabled in > >> around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > > ssh://git at pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > > me know if you encounter any problems. > What "name" is passed to CIA bot as author? Take a look on an example > commit from qboosh: > 17:08 <+CIA-121> jakub master * packages/git-core-slug/git-core-slug.spec: > It should be qboosh I think. The email of the author is parsed and the part before @ is used. > If it's from author's email then after quick look on cvs.authors it > will breake some stats on cia or ohloh stats and probably in some > other places. I am open to better ideas. Please remember that the author, the comitter and the person performing git-push can be three different persons. -- Kacper From qboosh at pld-linux.org Mon Jul 9 19:01:12 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 9 Jul 2012 19:01:12 +0200 Subject: git commit logs [Re: [packages/sblim-cmpi-base] Created branch master] In-Reply-To: <20120709152102.17268.78076@pld-linux.org> References: <20120709152102.17268.78076@pld-linux.org> Message-ID: <20120709170112.GA28980@mail> On Mon, Jul 09, 2012 at 05:21:02PM +0200, qboosh wrote: > The branch 'master' was created pointing to: > > 391e234... - new Two remarks: 1) In case of new specs their content should be included in mail. 2) CVS commit logs have Reply-To: pld-devel-* set; IMO git commit logs should have too. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Mon Jul 9 19:05:40 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 9 Jul 2012 19:05:40 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120709155535.GE13534@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120709153933.GD1095@stranger.qboosh.pl> <20120709155535.GE13534@camk.edu.pl> Message-ID: <20120709170540.GB28980@mail> On Mon, Jul 09, 2012 at 05:55:35PM +0200, Kacper Kornet wrote: > On Mon, Jul 09, 2012 at 05:39:33PM +0200, Jakub Bogusz wrote: > > Is there any way to change mistaken changelog entry after push? > > If you ask about changelog generated during build process and included > in rpm, then yes. If the commit is annotated with git-notes in name > space refs/notes/commits, then this note is used instead of commitlog. > > I will write a small howto describing the process. But you can see an > example in package dosemu. Please look in gitk at commit > 1478030904125f1f0180e144ed4312ae8754f63f Yes, this should suffice. I assume that overwriting original git history is undesirable (we didn't do it in CVS case either). -- Jakub Bogusz http://qboosh.pl/ From kornet at camk.edu.pl Mon Jul 9 19:00:17 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Mon, 9 Jul 2012 19:00:17 +0200 Subject: git commit logs [Re: [packages/sblim-cmpi-base] Created branch master] In-Reply-To: <20120709170112.GA28980@mail> References: <20120709152102.17268.78076@pld-linux.org> <20120709170112.GA28980@mail> Message-ID: <20120709170016.GG13534@camk.edu.pl> On Mon, Jul 09, 2012 at 07:01:12PM +0200, Jakub Bogusz wrote: > On Mon, Jul 09, 2012 at 05:21:02PM +0200, qboosh wrote: > > The branch 'master' was created pointing to: > > 391e234... - new > Two remarks: > 1) In case of new specs their content should be included in mail. I think it is a safeguard that if someone imports git repository from some other source with history, we are not flooded with hundres of emails about every commit. It is an open question whether we want this feature or not. > 2) CVS commit logs have Reply-To: pld-devel-* set; IMO git commit logs > should have too. I will fix it. -- Kacper From jajcus at jajcus.net Mon Jul 9 19:08:02 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 9 Jul 2012 19:08:02 +0200 Subject: git commit logs [Re: [packages/sblim-cmpi-base] Created branch master] In-Reply-To: <20120709170016.GG13534@camk.edu.pl> References: <20120709152102.17268.78076@pld-linux.org> <20120709170112.GA28980@mail> <20120709170016.GG13534@camk.edu.pl> Message-ID: <20120709170802.GB2399@lolek.nigdzie> On Mon, Jul 09, 2012 at 07:00:17PM +0200, Kacper Kornet wrote: > On Mon, Jul 09, 2012 at 07:01:12PM +0200, Jakub Bogusz wrote: > > On Mon, Jul 09, 2012 at 05:21:02PM +0200, qboosh wrote: > > > The branch 'master' was created pointing to: > > > > 391e234... - new > > > Two remarks: > > > 1) In case of new specs their content should be included in mail. > > I think it is a safeguard that if someone imports git repository from > some other source with history, we are not flooded with hundres of > emails about every commit. It is an open question whether we want this > feature or not. Could it be done, that in such case only the last version (from the last commit in the initial push) of the files is included in the mail? Greets, Jacek From kiesiu at pld-linux.org Mon Jul 9 21:26:19 2012 From: kiesiu at pld-linux.org (Lukasz Kies) Date: Mon, 9 Jul 2012 21:26:19 +0200 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: References: Message-ID: 2012/7/9 kiesiu : > Author: kiesiu Date: Mon Jul 9 19:18:52 2012 GMT > Module: pld-builder.new Tag: HEAD > ---- Log message: > - change links from cvsweb to gitweb > - remove some extra parenthesis > > ---- Files affected: > pld-builder.new/PLD_Builder: > request.py (1.96 -> 1.97) > It would be nice to merge "git changes" on pld-builder and add to PLD git. Maybe in projects/pld/pld-builder.new? It's worth to move there (to pld insead to packages) also: - template-specs - buildlogs - pld-ftp-admin - cdg And maybe create a new repo (i.e. repo-tools) with those orphaned scripts from packages root dir from CVS. -- Regards, Lukasz From kornet at camk.edu.pl Mon Jul 9 21:33:04 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Mon, 9 Jul 2012 21:33:04 +0200 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: References: Message-ID: <20120709193304.GH13534@camk.edu.pl> On Mon, Jul 09, 2012 at 09:26:19PM +0200, Lukasz Kies wrote: > 2012/7/9 kiesiu : > > Author: kiesiu Date: Mon Jul 9 19:18:52 2012 GMT > > Module: pld-builder.new Tag: HEAD > > ---- Log message: > > - change links from cvsweb to gitweb > > - remove some extra parenthesis > > ---- Files affected: > > pld-builder.new/PLD_Builder: > > request.py (1.96 -> 1.97) > It would be nice to merge "git changes" on pld-builder and add to PLD > git. Maybe in projects/pld/pld-builder.new? The version that the current builders use is here https://github.com/pld-linux/pld-builder.new In few days I will clone it to out git server. It contains all changes from CVS up till yesterday. Probably I should block the write acces to the version in CVS. -- Kacper From glen at pld-linux.org Mon Jul 9 21:42:25 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 09 Jul 2012 22:42:25 +0300 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: References: Message-ID: <4FFB3421.9070707@pld-linux.org> On 07/09/2012 10:26 PM, Lukasz Kies wrote: > - cdg there is no reason to migrate cdg to git cdg is server side cvs scripting, porting that to git is not worth the effort -- glen From glen at pld-linux.org Mon Jul 9 21:48:54 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 09 Jul 2012 22:48:54 +0300 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: References: Message-ID: <4FFB35A6.4030104@pld-linux.org> On 07/09/2012 10:26 PM, Lukasz Kies wrote: > git. Maybe in projects/pld/pld-builder.new? > It's worth to move there (to pld insead to packages) also: > - template-specs > - buildlogs > - pld-ftp-admin > - cdg > And maybe create a new repo (i.e. repo-tools) with those orphaned > scripts from packages root dir from CVS. in irc questions rise up, including those and i proposed: 1. https://github.com/pld-linux - mirror of git.pld-linux.org/packages 2. https://github.com/pld-linux/rpm-build-tools is same as git.pld/packages/rpm-build-tools due the above 3. https://github.com/pld-linux/pld-builder.new - moved to git.pld/projects/pld-builder altho it could be as well subdir of packages/pld-builder named src - there's no exception why not keep .spec and source code separate, is it? 4. and template-specs goes to git.pld/packages/rpm-build-tools/template-specs alternatively packaged into rpm as well. 5. and remaining scripts from packages/* go as well to git.pld/packages/rpm-build-tools/ all those (4-5) with cvs history import right now i have no opinion on buildlogs and pld-ftp-admin or other admin/* dirs from cvs/svn, so i'd leave them where they are, they are not directly related to "packages development" and thus needed daily and for every developer. and also afaik admin/* files have some automation scripted somewhere. -- glen From draenog at pld-linux.org Mon Jul 9 21:58:30 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 9 Jul 2012 21:58:30 +0200 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: <4FFB35A6.4030104@pld-linux.org> References: <4FFB35A6.4030104@pld-linux.org> Message-ID: <20120709195830.GI13534@camk.edu.pl> On Mon, Jul 09, 2012 at 10:48:54PM +0300, Elan Ruusam?e wrote: > On 07/09/2012 10:26 PM, Lukasz Kies wrote: > 2. https://github.com/pld-linux/rpm-build-tools is same as > git.pld/packages/rpm-build-tools due the above > 3. https://github.com/pld-linux/pld-builder.new - moved to > git.pld/projects/pld-builder I don't think it is a good idea to drop the .new subscript. In few places in the code the path ~/pld-builer.new is hard coded. (I add the possibility to be set this by environment variable, but that requires modification in cron and procmail files. So it is not perfect.). So right now you have to remeber to make git clone git://git.pld-linux.org/packages/pld-builder pld-builder.new And besides I think it is a nice idea to respect name given to it by the author of the code. -- Kacper From kiesiu at pld-linux.org Mon Jul 9 22:05:10 2012 From: kiesiu at pld-linux.org (Lukasz Kies) Date: Mon, 9 Jul 2012 22:05:10 +0200 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: <4FFB35A6.4030104@pld-linux.org> References: <4FFB35A6.4030104@pld-linux.org> Message-ID: 2012/7/9 Elan Ruusam?e : > On 07/09/2012 10:26 PM, Lukasz Kies wrote: >> >> git. Maybe in projects/pld/pld-builder.new? >> It's worth to move there (to pld insead to packages) also: >> - template-specs >> - buildlogs >> - pld-ftp-admin >> - cdg >> And maybe create a new repo (i.e. repo-tools) with those orphaned >> scripts from packages root dir from CVS. > > in irc questions rise up, including those and i proposed: > > 1. https://github.com/pld-linux - mirror of git.pld-linux.org/packages Why we need mirror of our git in external system? And if there is a valid reason, will it be read-only or read write? Which brings another questions like access rights and synchronization... > altho it could be as well subdir of packages/pld-builder named src - there's > no exception why not keep .spec and source code separate, is it? I believe such sources of "PLD only software" should be keep out of packages to hightlight it's not a spec files or additional patches for external maintained software. > 5. and remaining scripts from packages/* go as well to > git.pld/packages/rpm-build-tools/ Good point. > right now i have no opinion on buildlogs and pld-ftp-admin or other admin/* > dirs from cvs/svn, so i'd leave them where they are, they are not directly > related to "packages development" and thus needed daily and for every > developer. and also afaik admin/* files have some automation scripted > somewhere. I see no reason to not move any alive PLD projects to git instead of keeping it in numerous different repost (poldek anyone?). No need to maintain so many repos. If some automation is highly depended on cvs it should be fixed to use git. -- Lukasz From glen at pld-linux.org Mon Jul 9 22:47:21 2012 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 09 Jul 2012 23:47:21 +0300 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: References: <4FFB35A6.4030104@pld-linux.org> Message-ID: <4FFB4359.2030004@pld-linux.org> On 07/09/2012 11:05 PM, Lukasz Kies wrote: >> 1.https://github.com/pld-linux - mirror of git.pld-linux.org/packages > Why we need mirror of our git in external system? And if there is a > valid reason, will it be read-only or read write? Which brings another > questions like access rights and synchronization... > readonly pushes there i guess it's good for backup and also it popularizes pld somewhat :) -- glen From jajcus at jajcus.net Mon Jul 9 22:50:48 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 9 Jul 2012 22:50:48 +0200 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: References: <4FFB35A6.4030104@pld-linux.org> Message-ID: <20120709205048.GC2399@lolek.nigdzie> On Mon, Jul 09, 2012 at 10:05:10PM +0200, Lukasz Kies wrote: > 2012/7/9 Elan Ruusam?e : > > > > in irc questions rise up, including those and i proposed: > > > > 1. https://github.com/pld-linux - mirror of git.pld-linux.org/packages > Why we need mirror of our git in external system? Having the project in github may give us a lot of publicity. And github gives great tools for third parties to work with our repos (fork them, do work based on them). That may introduce some developers or patches. > And if there is a > valid reason, will it be read-only or read write? Which brings another > questions like access rights and synchronization... Read-only, I guess. Commits would be only through our git server, but still github would allow anyone to fork any of our projects and work with it on its github account and then send patches to us (or allow us to fetch them from their repository). > > altho it could be as well subdir of packages/pld-builder named src - there's > > no exception why not keep .spec and source code separate, is it? > I believe such sources of "PLD only software" should be keep out of > packages to hightlight it's not a spec files or additional patches for > external maintained software. +1 I don't think that anything that is not 'spec file plus sources referenced by that spec file' should go to the packages/ name space. That is just misleading and may complicate some automated tasks. > I see no reason to not move any alive PLD projects to git instead of > keeping it in numerous different repost (poldek anyone?). +1 Greets, Jacek From draenog at pld-linux.org Mon Jul 9 23:35:57 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 9 Jul 2012 23:35:57 +0200 Subject: No subject Message-ID: <20120709213556.GK13534@camk.edu.pl> pld-devel-pl Cc: Bcc: Subject: Git HOWTO: change branch name Reply-To: A remark which just came to my mind. If for any reason you decide to change the name of exported branch, you should do this in this order: git branch -m oldname newname git push origin newname git push --delete origin oldname This way you avoid superfluous notification emails. -- Kacper From wrobell at pld-linux.org Tue Jul 10 01:14:05 2012 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Tue, 10 Jul 2012 00:14:05 +0100 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: <20120709205048.GC2399@lolek.nigdzie> References: <4FFB35A6.4030104@pld-linux.org> <20120709205048.GC2399@lolek.nigdzie> Message-ID: On Mon, Jul 9, 2012 at 9:50 PM, Jacek Konieczny wrote: > On Mon, Jul 09, 2012 at 10:05:10PM +0200, Lukasz Kies wrote: >> 2012/7/9 Elan Ruusam?e : >> > >> > in irc questions rise up, including those and i proposed: >> > >> > 1. https://github.com/pld-linux - mirror of git.pld-linux.org/packages >> Why we need mirror of our git in external system? > > Having the project in github may give us a lot of publicity. And github > gives great tools for third parties to work with our repos (fork them, > do work based on them). That may introduce some developers or patches. Can we do the same with bitbucket? [...] Regards, w From draenog at pld-linux.org Tue Jul 10 08:16:58 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 10 Jul 2012 08:16:58 +0200 Subject: git commit logs [Re: [packages/sblim-cmpi-base] Created branch master] In-Reply-To: <20120709170802.GB2399@lolek.nigdzie> References: <20120709152102.17268.78076@pld-linux.org> <20120709170112.GA28980@mail> <20120709170016.GG13534@camk.edu.pl> <20120709170802.GB2399@lolek.nigdzie> Message-ID: <20120710061658.GP13534@camk.edu.pl> On Mon, Jul 09, 2012 at 07:08:02PM +0200, Jacek Konieczny wrote: > On Mon, Jul 09, 2012 at 07:00:17PM +0200, Kacper Kornet wrote: > > On Mon, Jul 09, 2012 at 07:01:12PM +0200, Jakub Bogusz wrote: > > > On Mon, Jul 09, 2012 at 05:21:02PM +0200, qboosh wrote: > > > > The branch 'master' was created pointing to: > > > > 391e234... - new > > > Two remarks: > > > 1) In case of new specs their content should be included in mail. > > I think it is a safeguard that if someone imports git repository from > > some other source with history, we are not flooded with hundres of > > emails about every commit. It is an open question whether we want this > > feature or not. > Could it be done, that in such case only the last version (from the last > commit in the initial push) of the files is included in the mail? I think it should be possible. I will try to code it. -- Kacper From draenog at pld-linux.org Tue Jul 10 08:21:58 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 10 Jul 2012 08:21:58 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120709170540.GB28980@mail> References: <20120709030904.GE17298@camk.edu.pl> <20120709153933.GD1095@stranger.qboosh.pl> <20120709155535.GE13534@camk.edu.pl> <20120709170540.GB28980@mail> Message-ID: <20120710062158.GQ13534@camk.edu.pl> On Mon, Jul 09, 2012 at 07:05:40PM +0200, Jakub Bogusz wrote: > On Mon, Jul 09, 2012 at 05:55:35PM +0200, Kacper Kornet wrote: > > On Mon, Jul 09, 2012 at 05:39:33PM +0200, Jakub Bogusz wrote: > > > Is there any way to change mistaken changelog entry after push? > > If you ask about changelog generated during build process and included > > in rpm, then yes. If the commit is annotated with git-notes in name > > space refs/notes/commits, then this note is used instead of commitlog. > > I will write a small howto describing the process. But you can see an > > example in package dosemu. Please look in gitk at commit > > 1478030904125f1f0180e144ed4312ae8754f63f > Yes, this should suffice. > I assume that overwriting original git history is undesirable > (we didn't do it in CVS case either). For master branches and auto tags it is forbidden by ACLs. For other branches it is allowed. For other branchesz it is possible to allow for rebasing, removing of old branches etc. I think also AC uses this possibility for AC-branch. But it should be done with respect to other developers. -- Kacper From jajcus at jajcus.net Tue Jul 10 08:48:58 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 10 Jul 2012 08:48:58 +0200 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: References: <4FFB35A6.4030104@pld-linux.org> <20120709205048.GC2399@lolek.nigdzie> Message-ID: <20120710064857.GA18657@jajo.eggsoft> On Tue, Jul 10, 2012 at 12:14:05AM +0100, Artur Wroblewski wrote: > On Mon, Jul 9, 2012 at 9:50 PM, Jacek Konieczny wrote: > > Having the project in github may give us a lot of publicity. And github > > gives great tools for third parties to work with our repos (fork them, > > do work based on them). That may introduce some developers or patches. > > Can we do the same with bitbucket? We probably could, but I don't think it is worth it. bitbucket is not that popular. Does any of active PLD developers use bitbucket? We could mirror our stuff to every public GIT server in the world, but then it would be certain that some of those mirrors would be broken and most of them would be unused. Greets, Jacek From kornet at camk.edu.pl Tue Jul 10 08:56:33 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Tue, 10 Jul 2012 08:56:33 +0200 Subject: pld-builder.new: PLD_Builder/request.py - change links from cvsweb to gitwe... In-Reply-To: <20120710064857.GA18657@jajo.eggsoft> References: <4FFB35A6.4030104@pld-linux.org> <20120709205048.GC2399@lolek.nigdzie> <20120710064857.GA18657@jajo.eggsoft> Message-ID: <20120710065633.GR13534@camk.edu.pl> On Tue, Jul 10, 2012 at 08:48:58AM +0200, Jacek Konieczny wrote: > On Tue, Jul 10, 2012 at 12:14:05AM +0100, Artur Wroblewski wrote: > > On Mon, Jul 9, 2012 at 9:50 PM, Jacek Konieczny wrote: > > > Having the project in github may give us a lot of publicity. And github > > > gives great tools for third parties to work with our repos (fork them, > > > do work based on them). That may introduce some developers or patches. > > Can we do the same with bitbucket? > We probably could, but I don't think it is worth it. bitbucket is not > that popular. Does any of active PLD developers use bitbucket? I don't know whether you count me as an active PLD developer, but I have been using it since it started to host git repositories (previously they were mercurial only). For myself it has an advantage that it provides private repositories for free. But that is probably not an important factor for PLD. -- Kacper From caleb at pld-linux.org Tue Jul 10 15:26:00 2012 From: caleb at pld-linux.org (Caleb Maclennan) Date: Tue, 10 Jul 2012 16:26:00 +0300 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120709030904.GE17298@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> Message-ID: 2012/7/9 Kacper Kornet : > * Some documentation > -------------------- > > For some basic introduction to git and how to use it to work with PLD > repositories please see: > > http://www.pld-linux.org/dokuwiki/howto-git Two simple questions: 1) I haven't seen any notes in the docs about comment formatting. Are we still prefixing all changelog entries with "- "? This isn't a very usual thing to do with git and seems like a hack we've dragged in from processing cvs output. 2) Is there a way to set git's user.email config variable without doing it globally? I use git for other things where my pld nick is not my email. However with each package being a separate repository, setting it in the repository config file instead of the global one means having to set it in a couple thousand places. Is there a way to match the git origin server or some other way of marking that everything under rpm/packages gets a certain set of configuration values? Thanks, Caleb From draenog at pld-linux.org Tue Jul 10 15:40:58 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 10 Jul 2012 15:40:58 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: References: <20120709030904.GE17298@camk.edu.pl> Message-ID: <20120710134058.GT13534@camk.edu.pl> On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: > 2) Is there a way to set git's user.email config variable without > doing it globally? I use git for other things where my pld nick is not > my email. However with each package being a separate repository, > setting it in the repository config file instead of the global one > means having to set it in a couple thousand places. Is there a way to > match the git origin server or some other way of marking that > everything under rpm/packages gets a certain set of configuration > values? The solution that I know is to define a wrapper around git, that calls call "git -c user.email=whatever", where whatever depends on the current path. It's cumbersome, but maybe better then nothing. -- Kacper From mmazur at kernel.pl Tue Jul 10 15:47:08 2012 From: mmazur at kernel.pl (Mariusz Mazur) Date: Tue, 10 Jul 2012 15:47:08 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120710134058.GT13534@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120710134058.GT13534@camk.edu.pl> Message-ID: <201207101547.08660.mmazur@kernel.pl> On Tue of July 10 2012, Kacper Kornet wrote: > The solution that I know is to define a wrapper around git, that calls > call "git -c user.email=whatever", where whatever depends on the current > path. It's cumbersome, but maybe better then nothing. Or one can alias the 'git' command to a simple script that checks for .git/config, check if remote origin is git.pld-linux.org and if so, uses a different user.email. Hm, I could use that. Wonder if anyone already wrote it. --mmazur From qboosh at pld-linux.org Tue Jul 10 16:04:01 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 10 Jul 2012 16:04:01 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120710134058.GT13534@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120710134058.GT13534@camk.edu.pl> Message-ID: <20120710140401.GA953@mail> On Tue, Jul 10, 2012 at 03:40:58PM +0200, Kacper Kornet wrote: > On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: > > 2) Is there a way to set git's user.email config variable without > > doing it globally? I use git for other things where my pld nick is not > > my email. However with each package being a separate repository, > > setting it in the repository config file instead of the global one > > means having to set it in a couple thousand places. Is there a way to > > match the git origin server or some other way of marking that > > everything under rpm/packages gets a certain set of configuration > > values? > > The solution that I know is to define a wrapper around git, that calls > call "git -c user.email=whatever", where whatever depends on the current > path. It's cumbersome, but maybe better then nothing. Is it possible to include user.* setting in per-package .git/config? If so, slug.py or builder could set it based on some PLD-specific config file or environment variable. -- Jakub Bogusz http://qboosh.pl/ From draenog at pld-linux.org Tue Jul 10 16:02:34 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 10 Jul 2012 16:02:34 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120710140401.GA953@mail> References: <20120709030904.GE17298@camk.edu.pl> <20120710134058.GT13534@camk.edu.pl> <20120710140401.GA953@mail> Message-ID: <20120710140234.GV13534@camk.edu.pl> On Tue, Jul 10, 2012 at 04:04:01PM +0200, Jakub Bogusz wrote: > On Tue, Jul 10, 2012 at 03:40:58PM +0200, Kacper Kornet wrote: > > On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: > > > 2) Is there a way to set git's user.email config variable without > > > doing it globally? I use git for other things where my pld nick is not > > > my email. However with each package being a separate repository, > > > setting it in the repository config file instead of the global one > > > means having to set it in a couple thousand places. Is there a way to > > > match the git origin server or some other way of marking that > > > everything under rpm/packages gets a certain set of configuration > > > values? > > The solution that I know is to define a wrapper around git, that calls > > call "git -c user.email=whatever", where whatever depends on the current > > path. It's cumbersome, but maybe better then nothing. > Is it possible to include user.* setting in per-package .git/config? Yes there is. > If so, slug.py or builder could set it based on some PLD-specific config > file or environment variable. It is already implemented in git-init, which is used during initialization of repositories. Just set proper GIT_TEMPLATE_DIR. See section "TEMPLATE DIRECTORY" in man git-init. -- Kacper From caleb at pld-linux.org Tue Jul 10 16:05:02 2012 From: caleb at pld-linux.org (Caleb Maclennan) Date: Tue, 10 Jul 2012 17:05:02 +0300 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120710140401.GA953@mail> References: <20120709030904.GE17298@camk.edu.pl> <20120710134058.GT13534@camk.edu.pl> <20120710140401.GA953@mail> Message-ID: 2012/7/10 Jakub Bogusz : > On Tue, Jul 10, 2012 at 03:40:58PM +0200, Kacper Kornet wrote: >> On Tue, Jul 10, 2012 at 04:26:00PM +0300, Caleb Maclennan wrote: >> > 2) Is there a way to set git's user.email config variable without >> > doing it globally? I use git for other things where my pld nick is not >> > my email. However with each package being a separate repository, >> > setting it in the repository config file instead of the global one >> > means having to set it in a couple thousand places. Is there a way to >> > match the git origin server or some other way of marking that >> > everything under rpm/packages gets a certain set of configuration >> > values? >> >> The solution that I know is to define a wrapper around git, that calls >> call "git -c user.email=whatever", where whatever depends on the current >> path. It's cumbersome, but maybe better then nothing. > > Is it possible to include user.* setting in per-package .git/config? > > If so, slug.py or builder could set it based on some PLD-specific config > file or environment variable. Yes it is possible. It would look like this as a separate section: [user] email = caleb at pld-linux.org From caleb at pld-linux.org Tue Jul 10 16:06:57 2012 From: caleb at pld-linux.org (Caleb Maclennan) Date: Tue, 10 Jul 2012 17:06:57 +0300 Subject: Git in PLD - basic HOWTO In-Reply-To: <201207101547.08660.mmazur@kernel.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120710134058.GT13534@camk.edu.pl> <201207101547.08660.mmazur@kernel.pl> Message-ID: 2012/7/10 Mariusz Mazur : > Or one can alias the 'git' command to a simple script that checks for > .git/config, check if remote origin is git.pld-linux.org and if so, uses a > different user.email. > > Hm, I could use that. Wonder if anyone already wrote it. I thought of that too and could code it up, but as I thought about it, it seemed like something somebody else would already have done long ago. I just couldn't figure out what to search for to find a canonical solution. Caleb From kornet at camk.edu.pl Tue Jul 10 16:14:48 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Tue, 10 Jul 2012 16:14:48 +0200 Subject: Git in PLD - basic HOWTO In-Reply-To: References: <20120709030904.GE17298@camk.edu.pl> <20120710134058.GT13534@camk.edu.pl> <201207101547.08660.mmazur@kernel.pl> Message-ID: <20120710141448.GW13534@camk.edu.pl> On Tue, Jul 10, 2012 at 05:06:57PM +0300, Caleb Maclennan wrote: > 2012/7/10 Mariusz Mazur : > > Or one can alias the 'git' command to a simple script that checks for > > .git/config, check if remote origin is git.pld-linux.org and if so, uses a > > different user.email. > > Hm, I could use that. Wonder if anyone already wrote it. > I thought of that too and could code it up, but as I thought about it, > it seemed like something somebody else would already have done long > ago. I just couldn't figure out what to search for to find a canonical > solution. There was a suggestion to add run-time conditional sections to configuration files, but it was rejected because that part of code is heavily used: http://thread.gmane.org/gmane.comp.version-control.git/181998/focus=182204 -- Kacper From caleb at pld-linux.org Tue Jul 10 16:29:27 2012 From: caleb at pld-linux.org (Caleb Maclennan) Date: Tue, 10 Jul 2012 17:29:27 +0300 Subject: Git in PLD - basic HOWTO In-Reply-To: <20120710134058.GT13534@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120710134058.GT13534@camk.edu.pl> Message-ID: 2012/7/10 Kacper Kornet : > The solution that I know is to define a wrapper around git, that calls > call "git -c user.email=whatever", where whatever depends on the current > path. It's cumbersome, but maybe better then nothing. Here's my current hack as function for my zsh shell: function git () { case "$PWD"; in $HOME/rpm/*) command git -c user.email=$USER at pld-linux.org "$@" ;; *) command git "$@" ;; esac } From qboosh at pld-linux.org Tue Jul 10 16:48:57 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 10 Jul 2012 16:48:57 +0200 Subject: [packages/Mesa] - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel (required by newest KDE) In-Reply-To: <20120710105044.15246.69547@pld-linux.org> References: <20120710105044.15246.69547@pld-linux.org> Message-ID: <20120710144857.GA1128@mail> On Tue, Jul 10, 2012 at 12:50:44PM +0200, hawk wrote: > commit 57d6b81de30e78ec0686fd2f684f836f4c59cf84 > Author: Marcin Krol > Date: Tue Jul 10 10:53:10 2012 +0000 > > - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel > (required by newest KDE) OpenGL-GLES, OpenGL-ES or OpenGLES? The standard's name is "OpenGL(R) ES"... (see http://www.khronos.org/opengles/ for more information) Also, these packages provide two libraries conforming to different specifications, OpenGL ES 1.x and OpenGL ES 2.x. So I'd use P: OpenGL-ESv1 = 1.1, OpenGL-ESv2 = 2.0 (or equivalent using OpenGL-GLESvX or OpenGLESvX scheme) -- Jakub Bogusz http://qboosh.pl/ From glen at delfi.ee Tue Jul 10 17:17:10 2012 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 10 Jul 2012 18:17:10 +0300 Subject: Git in PLD - basic HOWTO In-Reply-To: References: <20120709030904.GE17298@camk.edu.pl> Message-ID: <4FFC4776.3020206@delfi.ee> On 10.07.2012 16:26, Caleb Maclennan wrote: > 2) Is there a way to set git's user.email config variable without > doing it globally? I use git for other things where my pld nick is not > my email. However with each package being a separate repository, > setting it in the repository config file instead of the global one > means having to set it in a couple thousand places. assuming you don't clone manually, but either with slug.py or builder why not add to both of them that they configure user based on some default into the new repos? i.e after checkout the tool would do: $ git config user.email=whatever -- glen From hawk at pld-linux.org Tue Jul 10 17:27:35 2012 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 10 Jul 2012 17:27:35 +0200 Subject: [packages/Mesa] - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel (required by newest KDE) In-Reply-To: <20120710144857.GA1128@mail> References: <20120710105044.15246.69547@pld-linux.org> <20120710144857.GA1128@mail> Message-ID: <4FFC49E7.9030009@pld-linux.org> > OpenGL-GLES, OpenGL-ES or OpenGLES? > The standard's name is "OpenGL(R) ES"... > (see http://www.khronos.org/opengles/ for more information) I followed naming scheme already used in other specs, ie. OpenGL-GL instead of just OpenGL. > Also, these packages provide two libraries conforming to different > specifications, OpenGL ES 1.x and OpenGL ES 2.x. > > So I'd use P: OpenGL-ESv1 = 1.1, OpenGL-ESv2 = 2.0 > (or equivalent using OpenGL-GLESvX or OpenGLESvX scheme) Fine by me, but I'd left generic P: OpenGL-GLES as well. M. From qboosh at pld-linux.org Tue Jul 10 18:14:07 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 10 Jul 2012 18:14:07 +0200 Subject: [packages/Mesa] - provide OpenGL-GLES, OpenGL-GLES-devel in libGLES, libGLES-devel (required by newest KDE) In-Reply-To: <4FFC49E7.9030009@pld-linux.org> References: <20120710105044.15246.69547@pld-linux.org> <20120710144857.GA1128@mail> <4FFC49E7.9030009@pld-linux.org> Message-ID: <20120710161407.GA1320@mail> On Tue, Jul 10, 2012 at 05:27:35PM +0200, Marcin Krol wrote: > >OpenGL-GLES, OpenGL-ES or OpenGLES? > >The standard's name is "OpenGL(R) ES"... > >(see http://www.khronos.org/opengles/ for more information) > > I followed naming scheme already used in other specs, ie. OpenGL-GL > instead of just OpenGL. Actually libGL uses just "OpenGL" Provides. There are OpenGL-GLU and OpenGL-GLX, both of which are parts of OpenGL specification (OpenGL Utility Library, OpenGL extension to the X Window System). OpenGL ES is a separate standard, so maybe separate namespace would be better (OpenGLES, OpenGLESv1/OpenGLESv2). > >Also, these packages provide two libraries conforming to different > >specifications, OpenGL ES 1.x and OpenGL ES 2.x. > > > >So I'd use P: OpenGL-ESv1 = 1.1, OpenGL-ESv2 = 2.0 > >(or equivalent using OpenGL-GLESvX or OpenGLESvX scheme) > > Fine by me, but I'd left generic P: OpenGL-GLES as well. -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Tue Jul 10 18:17:53 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 10 Jul 2012 18:17:53 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> Message-ID: <20120710161753.GB1320@mail> On Tue, Jul 10, 2012 at 03:20:52PM +0000, PLD th-src builder wrote: > sblim-cmpi-base.spec (auto/th/sblim-cmpi-base-1.6.1-1): FAILED > > --- sblim-cmpi-base.spec:auto/th/sblim-cmpi-base-1.6.1-1: > Build-Time: user:2.17s sys:0.89s real:4.63s (faults io:0 non-io:118415) > > > > *** buildlog for sblim-cmpi-base.spec > request from: qboosh > started at: Tue Jul 10 17:20:47 2012 > building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps --http -bs -r auto/th/sblim-cmpi-base-1.6.1-1 sblim-cmpi-base.spec 2>&1 > > Cloning into 'sblim-cmpi-base'... [...] > Tagging with prefix: auto/th/ > Version: 1.6.1 > Release: 1 > tag: auto/th/sblim-cmpi-base-1.6.1-1 > fatal: tag 'auto/th/sblim-cmpi-base-1.6.1-1' already exists > On detached HEAD. Use -r BRANCHNAME to override > error: Macro %_builddir has empty body > error: Macro %_builddir has empty body [...] When we were using CVS it was possible to resend tagged package to builders using package:auto-th-... syntax. Something changed or some builder functions were not updated for auto/th/ prefix? -- Jakub Bogusz http://qboosh.pl/ From hawk at pld-linux.org Tue Jul 10 18:31:22 2012 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 10 Jul 2012 18:31:22 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710161753.GB1320@mail> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> Message-ID: <4FFC58DA.1090106@pld-linux.org> > When we were using CVS it was possible to resend tagged package to builders > using package:auto-th-... syntax. > > Something changed or some builder functions were not updated for > auto/th/ prefix? Following change is needed to get it working with git: http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e38074e64d78d0d4e97df0df36045bec M. From arekm at maven.pl Tue Jul 10 18:38:13 2012 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Tue, 10 Jul 2012 18:38:13 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC58DA.1090106@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> Message-ID: <201207101838.13853.arekm@maven.pl> On Tuesday 10 of July 2012, Marcin Krol wrote: > > When we were using CVS it was possible to resend tagged package to > > builders using package:auto-th-... syntax. > > > > Something changed or some builder functions were not updated for > > auto/th/ prefix? > > Following change is needed to get it working with git: > > http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e380 > 74e64d78d0d4e97df0df36045bec Doesn't that make builder do forced retagging (which is not desired here) ? > M. -- Arkadiusz Mi?kiewicz, arekm / maven.pl From hawk at pld-linux.org Tue Jul 10 18:51:29 2012 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 10 Jul 2012 18:51:29 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <201207101838.13853.arekm@maven.pl> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> <201207101838.13853.arekm@maven.pl> Message-ID: <4FFC5D91.8030006@pld-linux.org> > Doesn't that make builder do forced retagging (which is not desired here) ? Yes. It replaces current tag with same name (note: not by delete tag, re-add tag), but otherwise build will fail because git tag command will return failure if given tag already exists while cvs was returning "ok" and just displaying warning AFAIR. Personally I didn't found any drawbacks and I'm using this fix with TLD for over a year now. M. From kornet at camk.edu.pl Tue Jul 10 19:05:14 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Tue, 10 Jul 2012 19:05:14 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710161753.GB1320@mail> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> Message-ID: <20120710170514.GX13534@camk.edu.pl> On Tue, Jul 10, 2012 at 06:17:53PM +0200, Jakub Bogusz wrote: > On Tue, Jul 10, 2012 at 03:20:52PM +0000, PLD th-src builder wrote: > > sblim-cmpi-base.spec (auto/th/sblim-cmpi-base-1.6.1-1): FAILED > > --- sblim-cmpi-base.spec:auto/th/sblim-cmpi-base-1.6.1-1: > > Build-Time: user:2.17s sys:0.89s real:4.63s (faults io:0 non-io:118415) > > *** buildlog for sblim-cmpi-base.spec > > request from: qboosh > > started at: Tue Jul 10 17:20:47 2012 > > building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps --http -bs -r auto/th/sblim-cmpi-base-1.6.1-1 sblim-cmpi-base.spec 2>&1 > > Cloning into 'sblim-cmpi-base'... > [...] > > Tagging with prefix: auto/th/ > > Version: 1.6.1 > > Release: 1 > > tag: auto/th/sblim-cmpi-base-1.6.1-1 > > fatal: tag 'auto/th/sblim-cmpi-base-1.6.1-1' already exists > > On detached HEAD. Use -r BRANCHNAME to override > > error: Macro %_builddir has empty body > > error: Macro %_builddir has empty body > [...] > When we were using CVS it was possible to resend tagged package to builders > using package:auto-th-... syntax. > Something changed or some builder functions were not updated for > auto/th/ prefix? Hawk has given the solution to the problem. But my question is the purpose of resending the build from the same tag? I'm assume that it would a test build, as the ready one would fail due to preexisting tag. -- Kacper From draenog at pld-linux.org Tue Jul 10 19:16:40 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 10 Jul 2012 19:16:40 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC58DA.1090106@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> Message-ID: <20120710171640.GY13534@camk.edu.pl> On Tue, Jul 10, 2012 at 06:31:22PM +0200, Marcin Krol wrote: > >When we were using CVS it was possible to resend tagged package to builders > >using package:auto-th-... syntax. > >Something changed or some builder functions were not updated for > >auto/th/ prefix? > Following change is needed to get it working with git: > http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e38074e64d78d0d4e97df0df36045bec I have the same fix, but I have not pushed it as I am not 100% happy with it. It changes the send request send with "path/spec:tag" -- Kacper From hawk at pld-linux.org Tue Jul 10 19:19:39 2012 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 10 Jul 2012 19:19:39 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710170514.GX13534@camk.edu.pl> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <20120710170514.GX13534@camk.edu.pl> Message-ID: <4FFC642B.5080005@pld-linux.org> > Hawk has given the solution to the problem. But my question is the > purpose of resending the build from the same tag? I'm assume that it > would a test build, as the ready one would fail due to preexisting tag. No. Ready build with auto tag shouldn't fail. Lets say someone sends 10 packages as ready build. They all got auto tagged, but 3rd of them fails to build. So now we have 7 packages tagged wich must be sent again to builder after fixing package number 3. Without possibility to send using auto tag one would have to bump release on those 7 packages. There are few other situations when ready build using auto tag must be performed. Mostly due to human mistakes, wrong/missing BRs/Rs etc. M. From mike at osdn.org.ua Tue Jul 10 19:22:59 2012 From: mike at osdn.org.ua (Michael Shigorin) Date: Tue, 10 Jul 2012 20:22:59 +0300 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710170514.GX13534@camk.edu.pl> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <20120710170514.GX13534@camk.edu.pl> Message-ID: <20120710172258.GR14924@osdn.org.ua> On Tue, Jul 10, 2012 at 07:05:14PM +0200, Kacper Kornet wrote: > Hawk has given the solution to the problem. But my question is > the purpose of resending the build from the same tag? I'm > assume that it would a test build, as the ready one would fail > due to preexisting tag. Just in case, test-only builds proved to be immensely useful at ALT -- especially when the build task is pretty complex (a bunch of packages some of which are popular dependencies). Doing an unmets check in a new combined repo helps it too. Those reading Russian might be interested in this whitepaper: http://ftp.linux.kiev.ua/pub/conference/peers/protva/2008/book-thesis-Protva-2008-5.pdf (p. 47) by Alexey Tourbin. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From hawk at pld-linux.org Tue Jul 10 19:25:45 2012 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 10 Jul 2012 19:25:45 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710171640.GY13534@camk.edu.pl> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> <20120710171640.GY13534@camk.edu.pl> Message-ID: <4FFC6599.9060006@pld-linux.org> > I have the same fix, but I have not pushed it as I am not 100% > happy with it. It changes the send request send with "path/spec:tag" Can you explain? I pretty you mean something different than what I'm thinking about. M. From kornet at camk.edu.pl Tue Jul 10 19:39:15 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Tue, 10 Jul 2012 19:39:15 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC642B.5080005@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <20120710170514.GX13534@camk.edu.pl> <4FFC642B.5080005@pld-linux.org> Message-ID: <20120710173915.GZ13534@camk.edu.pl> On Tue, Jul 10, 2012 at 07:19:39PM +0200, Marcin Krol wrote: > >Hawk has given the solution to the problem. But my question is the > >purpose of resending the build from the same tag? I'm assume that it > >would a test build, as the ready one would fail due to preexisting tag. > No. Ready build with auto tag shouldn't fail. What do you mean by shouldn't fell. Script builder will fail if you run like: builder -bs -Tp auto/th/ -tt ..... and the auto tag generated from required revision already exist. It was the case in CVS, it is the case in git. -- Kacper From draenog at pld-linux.org Tue Jul 10 19:47:43 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 10 Jul 2012 19:47:43 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC6599.9060006@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> <20120710171640.GY13534@camk.edu.pl> <4FFC6599.9060006@pld-linux.org> Message-ID: <20120710174743.GA13534@camk.edu.pl> On Tue, Jul 10, 2012 at 07:25:45PM +0200, Marcin Krol wrote: > >I have the same fix, but I have not pushed it as I am not 100% > >happy with it. It changes the send request send with "path/spec:tag" > Can you explain? I pretty you mean something different than what I'm > thinking about. My assumption is that request looks like: git-core.spec auto/th/cos If I send the old style tag with old version of make_request.sh like: ./make-request.sh -r -d th dir/git-core.spec:auto-th- I will get: git-core.spec auto-th- With new tag style and old script and argument: dir/git-core.spec:auto/th/cos I get: cos cos Wit your patch and argument dir/git-core.spec:auto/th/cos I get dir/git-core.spec auto/th/cos Better, but still not the same as previously. I have an idea for proper fix and I'm working on it right now. -- Kacper From hawk at pld-linux.org Tue Jul 10 19:54:11 2012 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 10 Jul 2012 19:54:11 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710173915.GZ13534@camk.edu.pl> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <20120710170514.GX13534@camk.edu.pl> <4FFC642B.5080005@pld-linux.org> <20120710173915.GZ13534@camk.edu.pl> Message-ID: <4FFC6C43.3010006@pld-linux.org> > What do you mean by shouldn't fell. Script builder will fail if you run > like: builder -bs -Tp auto/th/ -tt ..... > and the auto tag generated from required revision already exist. It was > the case in CVS, it is the case in git. It will fail on git, it wasn't failing on CVS due to difference in return codes I've mentioned before. At least thats how it behave when I was setting up TLD git. On CVS ready builds using auto tags worked fine (without using -cf) and thats how they should work on git as well. Developers must be able to do: ./make-request.sh -d th -r some.spec:auto/th/some-1.2 and get their packages built. M. From hawk at pld-linux.org Tue Jul 10 19:59:30 2012 From: hawk at pld-linux.org (Marcin Krol) Date: Tue, 10 Jul 2012 19:59:30 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710174743.GA13534@camk.edu.pl> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> <20120710171640.GY13534@camk.edu.pl> <4FFC6599.9060006@pld-linux.org> <20120710174743.GA13534@camk.edu.pl> Message-ID: <4FFC6D82.2000604@pld-linux.org> > Better, but still not the same as previously. Thats make-request.sh thing and has nothing to do with change we are talking about right now (added -cf to builder script call to allow ready builds with auto tags to succeed). M. From kornet at camk.edu.pl Tue Jul 10 20:12:50 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Tue, 10 Jul 2012 20:12:50 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC6D82.2000604@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> <20120710171640.GY13534@camk.edu.pl> <4FFC6599.9060006@pld-linux.org> <20120710174743.GA13534@camk.edu.pl> <4FFC6D82.2000604@pld-linux.org> Message-ID: <20120710181250.GB13534@camk.edu.pl> On Tue, Jul 10, 2012 at 07:59:30PM +0200, Marcin Krol wrote: > >Better, but still not the same as previously. > Thats make-request.sh thing and has nothing to do with change we are > talking about right now (added -cf to builder script call to allow > ready builds with auto tags to succeed). I'm sorry. I got confused between differen links to commits in gitweb. My fault. So in our case: @@ -126,7 +126,7 @@ def build_srpm(r, b): if res == 0 and not "test-build" in r.flags: for pref in config.tag_prefixes: util.append_to(b.logfile, "Tagging with prefix: %s" % pref) - res = chroot.run("cd rpm/packages; ./builder -r %s -Tp %s -Tv %s" % \ + res = chroot.run("cd rpm/packages; ./builder -cf -r %s -Tp %s -Tv %s" % \ (b.branch, pref, b.spec), logfile = b.logfile) if res == 0: transfer_file(r, b is not sufficent as option builder -cf does not disable checking if the tag already exists. But I'm still confused about it. So maybe first finish the second subthread. -- Kacper From kornet at camk.edu.pl Tue Jul 10 20:16:59 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Tue, 10 Jul 2012 20:16:59 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC6C43.3010006@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <20120710170514.GX13534@camk.edu.pl> <4FFC642B.5080005@pld-linux.org> <20120710173915.GZ13534@camk.edu.pl> <4FFC6C43.3010006@pld-linux.org> Message-ID: <20120710181659.GC13534@camk.edu.pl> On Tue, Jul 10, 2012 at 07:54:11PM +0200, Marcin Krol wrote: > >What do you mean by shouldn't fell. Script builder will fail if you run > >like: builder -bs -Tp auto/th/ -tt ..... > >and the auto tag generated from required revision already exist. It was > >the case in CVS, it is the case in git. > It will fail on git, it wasn't failing on CVS due to difference in > return codes I've mentioned before. At least thats how it behave > when I was setting up TLD git. On CVS ready builds using auto tags > worked fine (without using -cf) and thats how they should work on > git as well. Developers must be able to do: > ./make-request.sh -d th -r some.spec:auto/th/some-1.2 > and get their packages built. Propably I don't understand something. So sorry for still bothering you but I just tried: ./builder -bs -Tp auto/th/ -tt -r auto/th/git-core-slug-0.13.2-1 \ git-core-slug.spec in using script builder for CVS and it fails with: Searching for tag auto-th-git-core-1_7_11_1-1... Tag auto-th-git-core-1_7_11_1-1 already exists (spec release: 1.283). What am I missing. How did you exactly send the request to rebuild the old tag previously in CVS? -- Kacper From kornet at camk.edu.pl Tue Jul 10 20:24:17 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Tue, 10 Jul 2012 20:24:17 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <20120710181659.GC13534@camk.edu.pl> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <20120710170514.GX13534@camk.edu.pl> <4FFC642B.5080005@pld-linux.org> <20120710173915.GZ13534@camk.edu.pl> <4FFC6C43.3010006@pld-linux.org> <20120710181659.GC13534@camk.edu.pl> Message-ID: <20120710182416.GD13534@camk.edu.pl> On Tue, Jul 10, 2012 at 08:16:59PM +0200, Kacper Kornet wrote: > On Tue, Jul 10, 2012 at 07:54:11PM +0200, Marcin Krol wrote: > > >What do you mean by shouldn't fell. Script builder will fail if you run > > >like: builder -bs -Tp auto/th/ -tt ..... > > >and the auto tag generated from required revision already exist. It was > > >the case in CVS, it is the case in git. > > It will fail on git, it wasn't failing on CVS due to difference in > > return codes I've mentioned before. At least thats how it behave > > when I was setting up TLD git. On CVS ready builds using auto tags > > worked fine (without using -cf) and thats how they should work on > > git as well. Developers must be able to do: > > ./make-request.sh -d th -r some.spec:auto/th/some-1.2 > > and get their packages built. > Propably I don't understand something. So sorry for still bothering you > but I just tried: > ./builder -bs -Tp auto/th/ -tt -r auto/th/git-core-slug-0.13.2-1 \ > git-core-slug.spec > in using script builder for CVS and it fails with: > Searching for tag auto-th-git-core-1_7_11_1-1... > Tag auto-th-git-core-1_7_11_1-1 already exists (spec release: 1.283). > What am I missing. How did you exactly send the request to rebuild the > old tag previously in CVS? Ok. Now I understand. I have missed the second condition in: if ("test-build" in r.flags) or b.branch and b.branch.startswith(config.tag_prefixes[0]): I'm sorry for being slow. -- Kacper From draenog at pld-linux.org Wed Jul 11 03:23:42 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Wed, 11 Jul 2012 03:23:42 +0200 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC58DA.1090106@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <4FFC58DA.1090106@pld-linux.org> Message-ID: <20120711012342.GE13534@camk.edu.pl> On Tue, Jul 10, 2012 at 06:31:22PM +0200, Marcin Krol wrote: > >When we were using CVS it was possible to resend tagged package to builders > >using package:auto-th-... syntax. > >Something changed or some builder functions were not updated for > >auto/th/ prefix? > Following change is needed to get it working with git: > http://git.tld-linux.org/?p=pld-builder.new.git;a=commitdiff;h=023f7f27e38074e64d78d0d4e97df0df36045bec Unfortunately that is not sufficient fix. The problem is that in git setup there is no longer translation of '.' and '@' when name of auto tags are generated. And when -tt option is omitted for ready build it can lead to a problem when old style auto tag exist and new style auto tag is requested for different commit that still represents the same version-release of the package. So I think the proper way is to always use -tt option for ready builds, and builder script shouldn't exit with error when the tag already exists but points to the same commit as the requested one. You can find relevant commits on tag_checking branch in PLD rpm-build-tools packages. -- Kacper From mateusz-lists at ant.gliwice.pl Wed Jul 11 10:03:36 2012 From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak) Date: Wed, 11 Jul 2012 10:03:36 +0200 Subject: Git in PLD - basic HOWTO (ssh keys manipulation) In-Reply-To: <20120709115628.GM8786@camk.edu.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120709114230.GA4390@adamg.eu> <20120709115628.GM8786@camk.edu.pl> Message-ID: <201207111003.37456.mateusz-lists@ant.gliwice.pl> On Monday 09 of July 2012, Kacper Kornet wrote: > On Mon, Jul 09, 2012 at 01:42:31PM +0200, Adam Golebiowski wrote: > > On Mon, Jul 09, 2012 at 05:09:04AM +0200, Kacper Kornet wrote: > > > Developers have an rw acces by ssh: > > > ssh://git at git.pld-linux.org > > > > is there away to manipulate list of ssh keys or do you need to > > add / delete them manually? > > Yes, there is. You can use: ssh git at git.pld-linux.org sskm > Instrukcja: > > http://sitaramc.github.com/gitolite/sskm.html OK. I am for sure pretty far too stupid to do it :(. I am trying to add my key, but even listing my keys requires password: $ ssh git at git.pld-linux.org sskm list Password: Any hints ? TIA I wish to use my existing pld key: [matkor at laptop-hp ~/.ssh]$ ssh-keygen -l -f id_rsa_pld_linux.pub 2048 3e:7d:dc:1b:91:eb:14:9f:c4:95:6c:4b:6d:dd:03:c1 matkor at laptop-hp (RSA) -- Mateusz Korniak From lukaszgl at post.pl Wed Jul 11 10:06:39 2012 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Wed, 11 Jul 2012 10:06:39 +0200 Subject: Chromium-browser - sqllite problem? Message-ID: <8340575.XFfuvFErqQ@inhell> Does anybody noticed SEQV while entering an address ? Look at gdb output at http://pastebin.com/AU7TQ955 I seems that there is something wrong with connection CB - sqllite. Regards, -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From adamg at pld-linux.org Wed Jul 11 10:11:17 2012 From: adamg at pld-linux.org (Adam Golebiowski) Date: Wed, 11 Jul 2012 10:11:17 +0200 Subject: Git in PLD - basic HOWTO (ssh keys manipulation) In-Reply-To: <201207111003.37456.mateusz-lists@ant.gliwice.pl> References: <20120709030904.GE17298@camk.edu.pl> <20120709114230.GA4390@adamg.eu> <20120709115628.GM8786@camk.edu.pl> <201207111003.37456.mateusz-lists@ant.gliwice.pl> Message-ID: <20120711081117.GA26435@adamg.eu> On Wed, Jul 11, 2012 at 10:03:36AM +0200, Mateusz Korniak wrote: > > http://sitaramc.github.com/gitolite/sskm.html > > OK. I am for sure pretty far too stupid to do it :(. > I am trying to add my key, but even listing my keys requires password: > > > $ ssh git at git.pld-linux.org sskm list > Password: > > > Any hints ? TIA > > I wish to use my existing pld key: > > [matkor at laptop-hp ~/.ssh]$ ssh-keygen -l -f id_rsa_pld_linux.pub > 2048 3e:7d:dc:1b:91:eb:14:9f:c4:95:6c:4b:6d:dd:03:c1 matkor at laptop-hp (RSA) if this key is different than id_rsa.pub, try: $ ssh -i ~/.id_rsa_pld_linux.pub git at git.pld-linux.org sskm list hope this helps -- adamg From glen at delfi.ee Wed Jul 11 10:52:38 2012 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Wed, 11 Jul 2012 11:52:38 +0300 Subject: Chromium-browser - sqllite problem? In-Reply-To: <8340575.XFfuvFErqQ@inhell> References: <8340575.XFfuvFErqQ@inhell> Message-ID: <4FFD3ED6.1090201@delfi.ee> On 11.07.2012 11:06, Lukasz Glebicki wrote: > Does anybody noticed SEQV while entering an address ? yes, i did. i thought it's something to do with synchronization, as that got corrupted too, i.e crashes were less after i reconnected with profile sync. however but they still occour when autocompleting address. -- glen From glen at delfi.ee Wed Jul 11 11:00:49 2012 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 11 Jul 2012 12:00:49 +0300 Subject: Resending tagged builds [Re: ERRORS: sblim-cmpi-base.spec] In-Reply-To: <4FFC6C43.3010006@pld-linux.org> References: <9821f63f-4db8-42a7-95dc-d6e1488ef5e4@pld.src.builder> <20120710161753.GB1320@mail> <20120710170514.GX13534@camk.edu.pl> <4FFC642B.5080005@pld-linux.org> <20120710173915.GZ13534@camk.edu.pl> <4FFC6C43.3010006@pld-linux.org> Message-ID: <4FFD40C1.2030809@delfi.ee> On 10.07.2012 20:54, Marcin Krol wrote: > It will fail on git, it wasn't failing on CVS due to difference in > return codes I've mentioned before. At least thats how it behave when > I was setting up TLD git. On CVS ready builds using auto tags worked > fine (without using -cf) and thats how they should work on git as > well. Developers must be able to do: in other wirds, in cvs tagging file with existing tag, did perform the tagging and did not fail. in git tagging with existing tag will fail. $ cvs tag test-tag test.spec; echo $? T test.spec 0 $ cvs tag test-tag test.spec; echo $? 0 glen at wintersunset SPECS/p $ git tag test-tag; echo $? 0 glen at wintersunset SPECS/p $ git tag test-tag; echo $? fatal: tag 'test-tag' already exists 128 glen at wintersunset SPECS/p $ so in cvs resending old tag was always retagging it. i noticed it too at some point, but as it worked did not want to touch that part :) -- glen From mateusz-lists at ant.gliwice.pl Wed Jul 11 11:06:43 2012 From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak) Date: Wed, 11 Jul 2012 11:06:43 +0200 Subject: Git in PLD - basic HOWTO (ssh keys manipulation) In-Reply-To: <20120711081117.GA26435@adamg.eu> References: <20120709030904.GE17298@camk.edu.pl> <201207111003.37456.mateusz-lists@ant.gliwice.pl> <20120711081117.GA26435@adamg.eu> Message-ID: <201207111106.45100.mateusz-lists@ant.gliwice.pl> On Wednesday 11 of July 2012, Adam Golebiowski wrote: > > I am trying to add my key, but even listing my keys requires password: > (...) > if this key is different than id_rsa.pub, try: > $ ssh -i ~/.id_rsa_pld_linux.pub git at git.pld-linux.org sskm list Thanks, works, specifying private key via: $ ssh -i ~/.id_rsa_pld_linux works even better. -- Mateusz Korniak From glen at delfi.ee Wed Jul 11 11:54:45 2012 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 11 Jul 2012 12:54:45 +0300 Subject: Git in PLD - basic HOWTO (ssh keys manipulation) In-Reply-To: <201207111106.45100.mateusz-lists@ant.gliwice.pl> References: <20120709030904.GE17298@camk.edu.pl> <201207111003.37456.mateusz-lists@ant.gliwice.pl> <20120711081117.GA26435@adamg.eu> <201207111106.45100.mateusz-lists@ant.gliwice.pl> Message-ID: <4FFD4D65.50307@delfi.ee> On 11.07.2012 12:06, Mateusz Korniak wrote: > On Wednesday 11 of July 2012, Adam Golebiowski wrote: >>> I am trying to add my key, but even listing my keys requires password: >> (...) >> if this key is different than id_rsa.pub, try: >> $ ssh -i ~/.id_rsa_pld_linux.pub git at git.pld-linux.org sskm list > Thanks, works, specifying private key via: > $ ssh -i ~/.id_rsa_pld_linux > works even better. > > and in case you didn't know, you can also make it transparent by adding to ~/.ssh/config : Host git.pld-linux.org IdentityFile ~/.ssh/id_rsa_pld_linux -- glen From kornet at camk.edu.pl Wed Jul 11 15:03:44 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Wed, 11 Jul 2012 15:03:44 +0200 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <4FFAD9E7.9080406@delfi.ee> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> Message-ID: <20120711130344.GG13534@camk.edu.pl> On Mon, Jul 09, 2012 at 04:17:27PM +0300, Elan Ruusam?e wrote: > On 09.07.2012 15:40, Kacper Kornet wrote: > >>> those (except pldnotify.awk and pearize.sh) are daily tools used to > >>> manage pld packages developing > >>> do they all fit to rpm-build-tools git repo? can those be imported > >>> with full cvs history? > >Yes, they can be imported with cvs history if we only agree on the name > >of a packages to which they should be put. > my vote: put them into rpm-build-tools with names they already have. > if needed to remove, these can be renamed later A small doubt about it. Package rpm-build-tools is cloned to chroots used by builders. Are all this tools really needed there? -- Kacper From jajcus at jajcus.net Wed Jul 11 15:09:26 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 11 Jul 2012 15:09:26 +0200 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <20120711130344.GG13534@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> Message-ID: <20120711130926.GA8597@jajo.eggsoft> On Wed, Jul 11, 2012 at 03:03:44PM +0200, Kacper Kornet wrote: > A small doubt about it. Package rpm-build-tools is cloned to chroots > used by builders. Are all this tools really needed there? If they do not pull further dependencies, they won't hurt. Greets, Jacek From kornet at camk.edu.pl Wed Jul 11 15:24:32 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Wed, 11 Jul 2012 15:24:32 +0200 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <20120711130926.GA8597@jajo.eggsoft> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> <20120711130926.GA8597@jajo.eggsoft> Message-ID: <20120711132432.GH13534@camk.edu.pl> On Wed, Jul 11, 2012 at 03:09:26PM +0200, Jacek Konieczny wrote: > On Wed, Jul 11, 2012 at 03:03:44PM +0200, Kacper Kornet wrote: > > A small doubt about it. Package rpm-build-tools is cloned to chroots > > used by builders. Are all this tools really needed there? > If they do not pull further dependencies, they won't hurt. They are installed as an rpm package. In every chroot there is a cloned repository /home/users/builder/rpm/rpm-build-tools So they won't hurt. My arguments was more about keeping it as clean as possible. So in this spirit I will only ask to not modify init_rpm_dir function to include linking of this additional files to rpm/packages Anyway I have put the history of this files in branch rpm_files/master in rpm-build-tools. If anyone is interested please merge it to master It should be a clean merge - if not, please let me know. -- Kacper From glen at delfi.ee Wed Jul 11 16:08:40 2012 From: glen at delfi.ee (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=) Date: Wed, 11 Jul 2012 17:08:40 +0300 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <20120711130344.GG13534@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> Message-ID: <4FFD88E8.2090200@delfi.ee> On 11.07.2012 16:03, Kacper Kornet wrote: > A small doubt about it. Package rpm-build-tools is cloned to chroots > used by builders. Are all this tools really needed there? in src-builders probably (two setups both on ep09), but in bin-builder, only builder script is needed, which i have symlink to system package (so it can be kept up to date with normal package upgrades). and in fact i'm not sure it's even needed there (in bin builders). 17:08:20 root[]@ppc rpm/packages# l total 16K drwxr-x--- 2 builder builder 4.0K May 22 10:01 CVS/ lrwxrwxrwx 1 builder builder 16 May 22 10:01 builder -> /usr/bin/builder* drwxr-xr-x 3 builder builder 4.0K May 23 09:29 kernel/ -rw-rw-r-- 1 builder builder 2.2K Jan 15 2009 mirrors drwxr-xr-x 2 builder builder 4.0K May 12 19:58 samba/ -- glen From glen at delfi.ee Wed Jul 11 16:19:48 2012 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 11 Jul 2012 17:19:48 +0300 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <4FFD88E8.2090200@delfi.ee> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> <4FFD88E8.2090200@delfi.ee> Message-ID: <4FFD8B84.7040908@delfi.ee> On 11.07.2012 17:08, Elan Ruusam?e wrote: > On 11.07.2012 16:03, Kacper Kornet wrote: >> A small doubt about it. Package rpm-build-tools is cloned to chroots >> used by builders. Are all this tools really needed there? > in src-builders probably (two setups both on ep09), but in > bin-builder, only builder script is needed, which i have symlink to > system package (so it can be kept up to date with normal package > upgrades). and in fact i'm not sure it's even needed there (in bin > builders). > > 17:08:20 root[]@ppc rpm/packages# l > total 16K > drwxr-x--- 2 builder builder 4.0K May 22 10:01 CVS/ > lrwxrwxrwx 1 builder builder 16 May 22 10:01 builder -> > /usr/bin/builder* > drwxr-xr-x 3 builder builder 4.0K May 23 09:29 kernel/ > -rw-rw-r-- 1 builder builder 2.2K Jan 15 2009 mirrors > drwxr-xr-x 2 builder builder 4.0K May 12 19:58 samba/ confirmed: bin-builders do not need that builder script either -- glen From draenog at pld-linux.org Wed Jul 11 16:21:46 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Wed, 11 Jul 2012 16:21:46 +0200 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <4FFD88E8.2090200@delfi.ee> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> <4FFD88E8.2090200@delfi.ee> Message-ID: <20120711142146.GJ13534@camk.edu.pl> On Wed, Jul 11, 2012 at 05:08:40PM +0300, Elan Ruusam?e wrote: > On 11.07.2012 16:03, Kacper Kornet wrote: > >A small doubt about it. Package rpm-build-tools is cloned to > >chroots used by builders. Are all this tools really needed there? > in src-builders probably (two setups both on ep09), but in > bin-builder, only builder script is needed, which i have symlink to > system package (so it can be kept up to date with normal package > upgrades). In src builders I prefer to keep it in clone of git repo. This way if I want to make a final check if the new changes don't break anything I don't need to produce rpm, upgrade it and in case of breakage downgrade. One more idea. The history of this additional files right now has to be set to new set of seperate branches. If someone wants them together with builder and adapther it needs to merge master and one of this new branches. But maybe this merge shouldn't be made on master. This way we keep master clean for sbuilders, and what's more for building rpm packages rpm-build-toos.rpm. And if somebody wants to use the tools can use a separate branch Tools (or whatever it is called) in his rpm/rpm-build-tools local clone. -- Kacper From kornet at camk.edu.pl Wed Jul 11 16:26:05 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Wed, 11 Jul 2012 16:26:05 +0200 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <20120711142146.GJ13534@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> <4FFD88E8.2090200@delfi.ee> <20120711142146.GJ13534@camk.edu.pl> Message-ID: <20120711142605.GK13534@camk.edu.pl> On Wed, Jul 11, 2012 at 04:21:46PM +0200, Kacper Kornet wrote: > On Wed, Jul 11, 2012 at 05:08:40PM +0300, Elan Ruusam?e wrote: > > On 11.07.2012 16:03, Kacper Kornet wrote: > > >A small doubt about it. Package rpm-build-tools is cloned to > > >chroots used by builders. Are all this tools really needed there? > > in src-builders probably (two setups both on ep09), but in > > bin-builder, only builder script is needed, which i have symlink to > > system package (so it can be kept up to date with normal package > > upgrades). > In src builders I prefer to keep it in clone of git repo. This way if I > want to make a final check if the new changes don't break anything I > don't need to produce rpm, upgrade it and in case of breakage downgrade. > One more idea. The history of this additional files right now has to be > set to new set of seperate branches. If someone wants them together with > builder and adapther it needs to merge master and one of this new > branches. But maybe this merge shouldn't be made on master. > This way we keep master clean for sbuilders, and what's more for > building rpm packages rpm-build-toos.rpm. And if somebody wants to use > the tools can use a separate branch Tools (or whatever it is called) in > his rpm/rpm-build-tools local clone. One comment: obvious drawback is that if someone modifies builder or adapter this should be done on master and then merged to Tools. Changes to other files should go to Tools directly. So probably too error prone. -- Kacper From glen at delfi.ee Wed Jul 11 16:34:59 2012 From: glen at delfi.ee (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=) Date: Wed, 11 Jul 2012 17:34:59 +0300 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <20120711142605.GK13534@camk.edu.pl> References: <20120708141709.GA8114@camk.edu.pl> <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> <4FFD88E8.2090200@delfi.ee> <20120711142146.GJ13534@camk.edu.pl> <20120711142605.GK13534@camk.edu.pl> Message-ID: <4FFD8F13.50009@delfi.ee> On 11.07.2012 17:26, Kacper Kornet wrote: >> > In src builders I prefer to keep it in clone of git repo. This way if I >> > want to make a final check if the new changes don't break anything I >> > don't need to produce rpm, upgrade it and in case of breakage downgrade. >> > One more idea. The history of this additional files right now has to be >> > set to new set of seperate branches. If someone wants them together with >> > builder and adapther it needs to merge master and one of this new >> > branches. But maybe this merge shouldn't be made on master. >> > This way we keep master clean for sbuilders, and what's more for >> > building rpm packages rpm-build-toos.rpm. And if somebody wants to use >> > the tools can use a separate branch Tools (or whatever it is called) in >> > his rpm/rpm-build-tools local clone. > One comment: obvious drawback is that if someone modifies builder or > adapter this should be done on master and then merged to Tools. Changes > to other files should go to Tools directly. So probably too error prone. rather create separate branch for builders if you want the checkout to be clean? you can even omit other files for builder (adapter*, *.spec, pldnotify*) as the tools are needed daily together with already existing tools like builder and adapter, sometimes new tools added too... -- glen From kornet at camk.edu.pl Wed Jul 11 16:44:40 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Wed, 11 Jul 2012 16:44:40 +0200 Subject: packages/ tools (Re: CVS down - git migration) In-Reply-To: <4FFD8F13.50009@delfi.ee> References: <20120709021947.GC17298@camk.edu.pl> <20120709054943.GA22576@sith.mimuw.edu.pl> <4FFACCC9.4060503@delfi.ee> <20120709124056.GP8786@camk.edu.pl> <4FFAD9E7.9080406@delfi.ee> <20120711130344.GG13534@camk.edu.pl> <4FFD88E8.2090200@delfi.ee> <20120711142146.GJ13534@camk.edu.pl> <20120711142605.GK13534@camk.edu.pl> <4FFD8F13.50009@delfi.ee> Message-ID: <20120711144440.GN13534@camk.edu.pl> On Wed, Jul 11, 2012 at 05:34:59PM +0300, Elan Ruusam?e wrote: > On 11.07.2012 17:26, Kacper Kornet wrote: > >>> In src builders I prefer to keep it in clone of git repo. This way if I > >>> want to make a final check if the new changes don't break anything I > >>> don't need to produce rpm, upgrade it and in case of breakage downgrade. > >>> One more idea. The history of this additional files right now has to be > >>> set to new set of seperate branches. If someone wants them together with > >>> builder and adapther it needs to merge master and one of this new > >>> branches. But maybe this merge shouldn't be made on master. > >>> This way we keep master clean for sbuilders, and what's more for > >>> building rpm packages rpm-build-toos.rpm. And if somebody wants to use > >>> the tools can use a separate branch Tools (or whatever it is called) in > >>> his rpm/rpm-build-tools local clone. > >One comment: obvious drawback is that if someone modifies builder or > >adapter this should be done on master and then merged to Tools. Changes > >to other files should go to Tools directly. So probably too error prone. > rather create separate branch for builders if you want the checkout > to be clean? you can even omit other files for builder (adapter*, > *.spec, pldnotify*) > as the tools are needed daily together with already existing tools > like builder and adapter, sometimes new tools added too... That's my plan B ;-). But seriously probably a better idea. As it will force to be careful only the person maintaining sbuilder branch, not all developers. -- Kacper From lordblick at gmail.com Wed Jul 11 18:16:40 2012 From: lordblick at gmail.com (Lord Blick) Date: Wed, 11 Jul 2012 18:16:40 +0200 Subject: Chromium-browser - sqllite problem? In-Reply-To: <4FFD3ED6.1090201@delfi.ee> References: <8340575.XFfuvFErqQ@inhell> <4FFD3ED6.1090201@delfi.ee> Message-ID: <4FFDA6E8.7030301@gmail.com> W odpowiedzi na wiadomo?? z dnia 11.07.2012 10:52, od Elan Ruusam?e: > On 11.07.2012 11:06, Lukasz Glebicki wrote: >> Does anybody noticed SEQV while entering an address ? > yes, i did. > > i thought it's something to do with synchronization, as that got > corrupted too, i.e crashes were less after i reconnected with profile > sync. however but they still occour when autocompleting address. > th-ready version seems to be stable. $ rpm -q chromium-browser chromium-browser-20.0.1132.47-2.x86_64 -- Best Regards, Lord Blick From jajcus at jajcus.net Thu Jul 12 10:49:45 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Thu, 12 Jul 2012 10:49:45 +0200 Subject: %changelog not in descending chronological order Message-ID: <20120712084945.GA22289@jajo.eggsoft> Hi, > [jajcus at jajo rpm-build-tools]$ ../builder -bb rpm-build-tools.spec > builder: SMP make flags are set to -j1 > Already up-to-date. > Available branches: AC-brach AC-branch DEVEL LIBCHAMPLAIN_0_8 NEW_PEAR_REQUIRES PATCH_MD5 PLD RA-branch master niceprint rpm-4_1-15_1 rpm-4_4_3 rpm-4_4_6 rpm-4_4_7 rpm_files/master tag_checking > Building target platforms: i686-linux > error: %changelog not in descending chronological order > Error: package build failed. (no more info) I have examined the generated changelog in the temporary spec file and indeed: > %changelog > * Wed Jul 11 2012 Kacper Kornet c9933bf > Add help message explaining how to push branch for the first time > > [...] > * Wed Jul 11 2012 Kacper Kornet ace99bc > Check for existence of tag during tagging > > * Tue Jul 10 2012 Kacper Kornet 8b6d179 > tag_exist accepts preexisting tag pointing to HEAD > > * Wed Jul 11 2012 Kacper Kornet c9100f1 > Simplify code in tag_files as TAGVER and TAG are mutually exclusive > [...] That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate (and we want AuthorDate in the changelog)? Does this work for anybody else? If so, what should I change? Greets, Jacek From glen at delfi.ee Thu Jul 12 12:46:43 2012 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Thu, 12 Jul 2012 13:46:43 +0300 Subject: %changelog not in descending chronological order In-Reply-To: <20120712084945.GA22289@jajo.eggsoft> References: <20120712084945.GA22289@jajo.eggsoft> Message-ID: <4FFEAB13.9060000@delfi.ee> On 12.07.2012 11:49, Jacek Konieczny wrote: > I have examined the generated changelog in the temporary spec file and indeed: i noticed this too for package where i cherry-picked commits and pushed in one go (php package) also likely happens with branch merges (like draenog change there) -- glen From draenog at pld-linux.org Thu Jul 12 20:26:02 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Thu, 12 Jul 2012 20:26:02 +0200 Subject: %changelog not in descending chronological order In-Reply-To: <20120712084945.GA22289@jajo.eggsoft> References: <20120712084945.GA22289@jajo.eggsoft> Message-ID: <20120712182602.GR13534@camk.edu.pl> On Thu, Jul 12, 2012 at 10:49:45AM +0200, Jacek Konieczny wrote: > Hi, > > [jajcus at jajo rpm-build-tools]$ ../builder -bb rpm-build-tools.spec > > builder: SMP make flags are set to -j1 > > Already up-to-date. > > Available branches: AC-brach AC-branch DEVEL LIBCHAMPLAIN_0_8 NEW_PEAR_REQUIRES PATCH_MD5 PLD RA-branch master niceprint rpm-4_1-15_1 rpm-4_4_3 rpm-4_4_6 rpm-4_4_7 rpm_files/master tag_checking > > Building target platforms: i686-linux > > error: %changelog not in descending chronological order > > Error: package build failed. (no more info) > I have examined the generated changelog in the temporary spec file and indeed: > > %changelog > > * Wed Jul 11 2012 Kacper Kornet c9933bf > > Add help message explaining how to push branch for the first time > > [...] > > * Wed Jul 11 2012 Kacper Kornet ace99bc > > Check for existence of tag during tagging > > * Tue Jul 10 2012 Kacper Kornet 8b6d179 > > tag_exist accepts preexisting tag pointing to HEAD > > * Wed Jul 11 2012 Kacper Kornet c9100f1 > > Simplify code in tag_files as TAGVER and TAG are mutually exclusive > > [...] > That can be because 'git rev-list', used to generate the changelog, > returns the commits ordered by commit date and not the AuthorDate A little more complicated. Even if the commit dates were the same as the author dates but parent - child relations were still the same, this three commits would be returned in by git rev-list in the same order. And the reason for order of this commit is that I developed them in order: 8b6d179 c9100f1 ace99bc and then before push change their order with git rebase -i to keep related commits close to each other. In the meantime the UTC midnight has passed so here is the result. But you are right, that probably --date-order should be used. It wouldn't change the order in changelog in this situation, but it others it can. > (and we want AuthorDate in the changelog)??? My logic was: the author not commiitter is shown, therefore the author date is also shown. -- Kacper From lordblick at gmail.com Thu Jul 12 20:54:55 2012 From: lordblick at gmail.com (Lord Blick) Date: Thu, 12 Jul 2012 20:54:55 +0200 Subject: Chromium-browser - sqllite problem? In-Reply-To: <4FFDA6E8.7030301@gmail.com> References: <8340575.XFfuvFErqQ@inhell> <4FFD3ED6.1090201@delfi.ee> <4FFDA6E8.7030301@gmail.com> Message-ID: <4FFF1D7F.6030404@gmail.com> W odpowiedzi na wiadomo?? z dnia 11.07.2012 18:16, od Lord Blick: > th-ready version seems to be stable. $ rpm -q chromium-browser > chromium-browser-20.0.1132.47-2.x86_64 Or not stable - a few minutes ago crashed to me in fast change inputing auto-completion in new tab. Just typed "a" and whole window disappears. -- Best Regards, Lord Blick From ed at yen.ipipan.waw.pl Thu Jul 12 21:02:42 2012 From: ed at yen.ipipan.waw.pl (=?iso-8859-2?q?=A3ukasz_Ma=B6ko?=) Date: Thu, 12 Jul 2012 21:02:42 +0200 Subject: Chromium-browser - sqllite problem? In-Reply-To: <4FFF1D7F.6030404@gmail.com> References: <8340575.XFfuvFErqQ@inhell> <4FFDA6E8.7030301@gmail.com> <4FFF1D7F.6030404@gmail.com> Message-ID: <201207122102.42842@laptok.ed.pl> Dnia czwartek, 12 lipca 2012, Lord Blick napisa?: > W odpowiedzi na wiadomo?? z dnia 11.07.2012 18:16, od Lord Blick: > > th-ready version seems to be stable. $ rpm -q chromium-browser > > chromium-browser-20.0.1132.47-2.x86_64 > > Or not stable - a few minutes ago crashed to me in fast change inputing > auto-completion in new tab. Just typed "a" and whole window disappears. I confirm, same for me, also with chromium-browser-20.0.1132.57-1.i686 -- ?ukasz Ma?ko _o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana" From n3npq at me.com Thu Jul 12 21:16:02 2012 From: n3npq at me.com (Jeffrey Johnson) Date: Thu, 12 Jul 2012 15:16:02 -0400 Subject: %changelog not in descending chronological order In-Reply-To: <20120712182602.GR13534@camk.edu.pl> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> Message-ID: <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > >> That can be because 'git rev-list', used to generate the changelog, >> returns the commits ordered by commit date and not the AuthorDate > Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be easier than trying to figure out how to trick up git sewage. Its likely worth the modest additional effort to run change log text through iconv(3) and avoid encoding configuration issues. hth 73 de Jeff From przemo at firszt.eu Fri Jul 13 18:00:50 2012 From: przemo at firszt.eu (Przemo Firszt) Date: Fri, 13 Jul 2012 17:00:50 +0100 Subject: [PATCH] Fix missing gnome-shell build reqirements Message-ID: <1342195250.2295.5.camel@pldmachine> gnome-shell-3.4.1 requires gtk-doc >= 1.15 for building. Please test & apply -- Regards, Przemo Firszt -------------- next part -------------- A non-text attachment was scrubbed... Name: gnome-shell.spec.patch Type: text/x-patch Size: 712 bytes Desc: not available URL: From draenog at pld-linux.org Sat Jul 14 02:07:38 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Sat, 14 Jul 2012 02:07:38 +0200 Subject: Git migration: SPECS Message-ID: <20120714000738.GZ17656@camk.edu.pl> There is a read-only repository with snapshot of specs on master branches in all packages: git://git.pld-linux.org/SPECS It is updated every 5 minutes. -- Kacper Kornet From przemo at firszt.eu Sat Jul 14 12:02:21 2012 From: przemo at firszt.eu (Przemo Firszt) Date: Sat, 14 Jul 2012 11:02:21 +0100 Subject: [PATCH] hugin build fix Message-ID: <1342260141.17845.5.camel@pldmachine> Change BuildRequires from OpenGL-glut-devel to glut-devel With this fix hugin compiles and works, but there is a problem with saving finished panorama to tif format which is rather not related to using glut. Please test & apply. -- Przemo Firszt -------------- next part -------------- A non-text attachment was scrubbed... Name: hugin.spec.patch Type: text/x-patch Size: 664 bytes Desc: not available URL: From jajcus at jajcus.net Mon Jul 16 18:38:10 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 16 Jul 2012 18:38:10 +0200 Subject: %changelog not in descending chronological order In-Reply-To: <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> Message-ID: <20120716163809.GA2430@lolek.nigdzie> On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: > On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > > > > >> That can be because 'git rev-list', used to generate the changelog, > >> returns the commits ordered by commit date and not the AuthorDate > > > > Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be > easier than trying to figure out how to trick up git sewage. I wonder if RPM really needs to enforce the changelog order. Would it really hurt if it just allowed building a package with such seemingly unordered entries? Will anything break if we just disable the test? Greets, Jacek From n3npq at me.com Mon Jul 16 18:41:55 2012 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 16 Jul 2012 12:41:55 -0400 Subject: %changelog not in descending chronological order In-Reply-To: <20120716163809.GA2430@lolek.nigdzie> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> Message-ID: <048A6987-9080-42AF-BF14-ED7F10886E85@me.com> On Jul 16, 2012, at 12:38 PM, Jacek Konieczny wrote: > On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: >> On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: >> >>> >>>> That can be because 'git rev-list', used to generate the changelog, >>>> returns the commits ordered by commit date and not the AuthorDate >>> >> >> Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be >> easier than trying to figure out how to trick up git sewage. > > I wonder if RPM really needs to enforce the changelog order. Would it > really hurt if it just allowed building a package with such seemingly > unordered entries? Will anything break if we just disable the test? > Yes loss of "legacy compatibility" would hurt with unordered entries. Nothing would break if all change log entries were ripped out either. (aside) The ordering constraint was likely a quick hack to detect time issues on an alpha miata (knowing almost all of RPM's hysteria). 73 de Jeff > Greets, > Jacek > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From mike at osdn.org.ua Mon Jul 16 18:48:39 2012 From: mike at osdn.org.ua (Michael Shigorin) Date: Mon, 16 Jul 2012 19:48:39 +0300 Subject: %changelog not in descending chronological order In-Reply-To: <048A6987-9080-42AF-BF14-ED7F10886E85@me.com> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> <048A6987-9080-42AF-BF14-ED7F10886E85@me.com> Message-ID: <20120716164839.GU30655@osdn.org.ua> On Mon, Jul 16, 2012 at 12:41:55PM -0400, Jeffrey Johnson wrote: > (aside) > The ordering constraint was likely a quick hack to detect > time issues on an alpha miata (knowing almost all of RPM's hysteria). Well it does help detect some mismerges... -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From draenog at pld-linux.org Mon Jul 16 21:43:11 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 16 Jul 2012 21:43:11 +0200 Subject: %changelog not in descending chronological order In-Reply-To: <20120716163809.GA2430@lolek.nigdzie> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> Message-ID: <20120716194310.GA14526@camk.edu.pl> On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: > On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: > > On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > > >> That can be because 'git rev-list', used to generate the changelog, > > >> returns the commits ordered by commit date and not the AuthorDate > > Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be > > easier than trying to figure out how to trick up git sewage. > I wonder if RPM really needs to enforce the changelog order. Would it > really hurt if it just allowed building a package with such seemingly > unordered entries? Will anything break if we just disable the test? So we have two solutions: a) Switch to show committer dates in changelog. It should be possible to show these dates should be in chronological order. Drawback: for commits migrated from CVS this date is set to some value =~ time of cvs->git migration b) Patch rpm in PLD to remove enforcing of chronological order in changelog. The patch seems trivial. I would go for b). -- Kacper From n3npq at me.com Mon Jul 16 21:47:41 2012 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 16 Jul 2012 15:47:41 -0400 Subject: %changelog not in descending chronological order In-Reply-To: <20120716194310.GA14526@camk.edu.pl> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> <20120716194310.GA14526@camk.edu.pl> Message-ID: <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> On Jul 16, 2012, at 3:43 PM, Kacper Kornet wrote: > On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: >> On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: >>> On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > > >>>>> That can be because 'git rev-list', used to generate the changelog, >>>>> returns the commits ordered by commit date and not the AuthorDate > > >>> Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be >>> easier than trying to figure out how to trick up git sewage. > >> I wonder if RPM really needs to enforce the changelog order. Would it >> really hurt if it just allowed building a package with such seemingly >> unordered entries? Will anything break if we just disable the test? > > So we have two solutions: > > a) Switch to show committer dates in changelog. It should be possible to > show these dates should be in chronological order. > > Drawback: for commits migrated from CVS this date is set to some > value =~ time of cvs->git migration > > b) Patch rpm in PLD to remove enforcing of chronological order in > changelog. The patch seems trivial. > > I would go for b). > c) qsort the 3 change log tags d) rip out change logs from *.rpm entirely Unlike git scripting, any of b), c), f) are quite tricky. b) will introduce some incompatibilities: for starters, there's functionality already implemented to truncate change log's by number/oldest that will break if you just go unordered. hth 73 de Jeff > -- > Kacper > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From przemo at firszt.eu Mon Jul 16 23:33:53 2012 From: przemo at firszt.eu (Przemo Firszt) Date: Mon, 16 Jul 2012 22:33:53 +0100 Subject: [PATCH] xorg-driver-input-wacom-0.15.0 -> 0.16.0 Message-ID: <1342474433.13491.2.camel@pldmachine> ChangeLog: 0.15.0 -> 0.16.0 Provide consistent 'filler' axes to X Create a wrapper for InitValuatorAxisStruct Find mouse buttons on pad devices if no generic buttons found xsetwacom: fix leak in set() Re-enable relative wheel scrolling from pad devices Align returned type of wcmEventAutoDevProbe with expected type Fix warning: Re-scope variable in wcmPreInitParseOptions Fix warning: Remove variable re-definition in wcmSerialValidate Fix warning: Swap empty string for NULL in wcmIsHotpluggedDevice Fix warning: Swap empty string for NULL in wcmIsAValidType Fix warning: Swap empty string for NULL in wcmNeedAutoHotplug Fix warning: Swap empty string for NULL in wcmIsDuplicate Fix warning: Swap empty strings for NULL in wcmCheckSource Fix warning: Constify 'name' argument of InitWcmAtom Fix warning: Remove superflous 'event' pointer in usbParseBTNEvent Fix warning: Constify _WacomCommonRec.device_path Fix warning: Change default_options to be const Fix warning: Have wcmEventAutoDevProbe return const Fix warning: Remove superflous casts in getScrollDelta Add 0xED and 0xEF conf: add Intuos4 WL (PTK-540WL) to fdi file -- Przemo Firszt -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg-driver-input-wacom.spec.patch Type: text/x-patch Size: 735 bytes Desc: not available URL: From jajcus at jajcus.net Tue Jul 17 00:02:58 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 17 Jul 2012 00:02:58 +0200 Subject: %changelog not in descending chronological order In-Reply-To: <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> <20120716194310.GA14526@camk.edu.pl> <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> Message-ID: <20120716220258.GB2430@lolek.nigdzie> On Mon, Jul 16, 2012 at 03:47:41PM -0400, Jeffrey Johnson wrote: > b) will introduce some incompatibilities: for starters, > there's functionality already implemented to truncate > change log's by number/oldest that will break if you > just go unordered. But that would be not 'totally unordered'. GIT history is just not linear, so there is no 'one real chronological order'. What is currently generated is enough for such features like 'truncate to last X entries', it is just not 'chronological enough' for RPM. RPM doing the sorting may in fact break the history ? RPM does not know full history from the short git log excerpts. E.g. an old commit (made long time ago on a development branch) just recently added to the master branch could be moved past the truncation point. I also think that patching RPM may be the best choice here ? easy and effective. Greets, Jacek From mike at osdn.org.ua Tue Jul 17 00:54:40 2012 From: mike at osdn.org.ua (Michael Shigorin) Date: Tue, 17 Jul 2012 01:54:40 +0300 Subject: %changelog not in descending chronological order In-Reply-To: <20120716220258.GB2430@lolek.nigdzie> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> <20120716194310.GA14526@camk.edu.pl> <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> <20120716220258.GB2430@lolek.nigdzie> Message-ID: <20120716225440.GX30655@osdn.org.ua> On Tue, Jul 17, 2012 at 12:02:58AM +0200, Jacek Konieczny wrote: > But that would be not 'totally unordered'. > GIT history is just not linear It's the different history: take %changelog as NEWS and commit messages as CHANGELOG. The latter is for developers while the former is for users (sysadmins). And for a given package there's sense to make sure its git history *is* linear. See e.g. http://git.altlinux.org/gears/r/rpm.git (which is an archived version of what got into packages built -- while individual maintainers can have widely different intermediate trees published, the inheritance is enforced by the build system). -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From draenog at pld-linux.org Tue Jul 17 02:07:29 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 17 Jul 2012 02:07:29 +0200 Subject: %changelog not in descending chronological order In-Reply-To: <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> <20120716194310.GA14526@camk.edu.pl> <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> Message-ID: <20120717000728.GB14526@camk.edu.pl> On Mon, Jul 16, 2012 at 03:47:41PM -0400, Jeffrey Johnson wrote: > On Jul 16, 2012, at 3:43 PM, Kacper Kornet wrote: > > On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: > >> On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: > >>> On Jul 12, 2012, at 2:26 PM, Kacper Kornet wrote: > >>>>> That can be because 'git rev-list', used to generate the changelog, > >>>>> returns the commits ordered by commit date and not the AuthorDate > >>> Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be > >>> easier than trying to figure out how to trick up git sewage. > >> I wonder if RPM really needs to enforce the changelog order. Would it > >> really hurt if it just allowed building a package with such seemingly > >> unordered entries? Will anything break if we just disable the test? > > So we have two solutions: > > a) Switch to show committer dates in changelog. It should be possible to > > show these dates should be in chronological order. > > Drawback: for commits migrated from CVS this date is set to some > > value =~ time of cvs->git migration > > b) Patch rpm in PLD to remove enforcing of chronological order in > > changelog. The patch seems trivial. > > I would go for b). > c) qsort the 3 change log tags That can be done during changelog generation in builder. But I don't think it is a right solution. In my opinion changelog should reflect the topological history of development. > b) will introduce some incompatibilities: for starters, > there's functionality already implemented to truncate > change log's by number/oldest that will break if you > just go unordered. Do you mean the one build/parseChangelog.c:addChangelog? It depends how the breakage is defined. I have just checked and it behaves as expected in case of the non chronological changelog. If %_changelog_truncate macro is set to a date it ommits only older commits. All newer one are included independent of their position in changelog. And I think in PLD %_changelog_truncat macro should be set to a number, not a date. And there is always a possibility that was used in PLD in CVS. Generate the text of the whole changelog as a single entry in changelog from rpm point of view. That way rpm always see only one revision and does not complain. -- Kacper From draenog at pld-linux.org Tue Jul 17 02:17:59 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Tue, 17 Jul 2012 02:17:59 +0200 Subject: %changelog not in descending chronological order In-Reply-To: <20120716225440.GX30655@osdn.org.ua> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> <20120716194310.GA14526@camk.edu.pl> <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> <20120716220258.GB2430@lolek.nigdzie> <20120716225440.GX30655@osdn.org.ua> Message-ID: <20120717001759.GC14526@camk.edu.pl> On Tue, Jul 17, 2012 at 01:54:40AM +0300, Michael Shigorin wrote: > On Tue, Jul 17, 2012 at 12:02:58AM +0200, Jacek Konieczny wrote: > > But that would be not 'totally unordered'. > > GIT history is just not linear > It's the different history: take %changelog as NEWS > and commit messages as CHANGELOG. The latter is for > developers while the former is for users (sysadmins). > And for a given package there's sense to make sure > its git history *is* linear. > See e.g. http://git.altlinux.org/gears/r/rpm.git > (which is an archived version of what got into packages > built -- while individual maintainers can have widely > different intermediate trees published, the inheritance > is enforced by the build system). Could you elaborate a little more how do you do it? I see that changelog entries are still present in spec files, and they are generated from commitlogs of tagged commits. But how does these commitlogs are generated. Are they some short of condensed 'git log' from the last tag? And how to you force that the tagged commits are in chronological order? -- Kacper From mike at osdn.org.ua Tue Jul 17 09:31:11 2012 From: mike at osdn.org.ua (Michael Shigorin) Date: Tue, 17 Jul 2012 10:31:11 +0300 Subject: %changelog not in descending chronological order In-Reply-To: <20120717001759.GC14526@camk.edu.pl> References: <20120712084945.GA22289@jajo.eggsoft> <20120712182602.GR13534@camk.edu.pl> <05582E9F-6BA0-4894-88F8-DCC5DAC2E193@me.com> <20120716163809.GA2430@lolek.nigdzie> <20120716194310.GA14526@camk.edu.pl> <90C4C3D2-4BF8-4D09-B1A1-BE8F2F62D731@me.com> <20120716220258.GB2430@lolek.nigdzie> <20120716225440.GX30655@osdn.org.ua> <20120717001759.GC14526@camk.edu.pl> Message-ID: <20120717073111.GK14691@osdn.org.ua> On Tue, Jul 17, 2012 at 02:17:59AM +0200, Kacper Kornet wrote: > > > But that would be not 'totally unordered'. > > > GIT history is just not linear > > It's the different history: take %changelog as NEWS > > and commit messages as CHANGELOG. The latter is for > > developers while the former is for users (sysadmins). (at least that's my take at the problem, of course) > > And for a given package there's sense to make sure > > its git history *is* linear. > > See e.g. http://git.altlinux.org/gears/r/rpm.git > Could you elaborate a little more how do you do it? I write my %changelogs by hand since that allows me the luxury of proper commits with explanations regarding developer side (like if I was documenting things for myself reading it again a year or two later), *and* yet allows me the luxury of reading terse enough changelogs via rpm -q --lastchange :) > I see that changelog entries are still present in spec files, Yes; that's both good and bad, not sure if openSUSE or PLD approach wins for me (but it's only a personal opinion!). Generated data tend to be less useful due to lower SNR. There's a gear-commit(1) utility for doing the opposite, generating commit messages from %changelog records: http://docs.altlinux.org/manpages/gear-commit.1.html > and they are generated from commitlogs of tagged commits. Might be but not enforced to. > But how does these commitlogs are generated. Are they some > short of condensed 'git log' from the last tag? There's gear-changelog(1) utility developed for the storage format born at ALT some six or seven years ago: http://docs.altlinux.org/manpages/gear-changelog.1.html http://docs.altlinux.org/manpages/gear-changelog-rules.5.html http://www.altlinux.org/Gear/changelog [ru] Maybe it serves as a good starting point for PLD's one. Just in case, server side has girar- prefix: http://git.altlinux.org/people/ldv/packages/?s=girar > And how to you force that the tagged commits are in > chronological order? The next "buildable" tag has to inherit from the previous successfully built tag for the successfully built new package to be allowed through to the repository. There's considerable work by Alexey Tourbin in place regarding the repository consistency, I can give a link to a whitepaper in Russian (proshu pana). DISCLAIMER: there are some troubles with the (almost) free-form git repos that gear supports for package generation; if interested, I can try to sum these up. In short, getting a repo into a state when no sane Patch: series could be extracted and stored in srpm is pretty easy, it's enough to be lazy and fix things in-place... (ALT used to be a meaningful source of patches but this got hit pretty heavily by megapatches or even %name-%version-%release.tar files incorporating all the upstream code and patches/commits in nearby git branches). And that's a problem. By the way, *thank you* PLD folks for your nice specs with predictable URLs as well as for nice standalone patches. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From baggins at pld-linux.org Tue Jul 17 22:01:32 2012 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 17 Jul 2012 22:01:32 +0200 Subject: [PATCH] hugin build fix In-Reply-To: <1342260141.17845.5.camel@pldmachine> References: <1342260141.17845.5.camel@pldmachine> Message-ID: <20120717200132.GA1460@home.lan> On Sat, 14 Jul 2012, Przemo Firszt wrote: > > Change BuildRequires from OpenGL-glut-devel to glut-devel > > With this fix hugin compiles and works, but there is a problem with > saving finished panorama to tif format which is rather not related to > using glut. > > Please test & apply. poldek:/all-avail> what-provides OpenGL-glut-devel 2 package(s) found: freeglut-devel-2.6.0-1.x86_64 glut-devel-3.7-22.x86_64 Thanks for the effort, but this change is not necessary. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From baggins at pld-linux.org Tue Jul 17 22:04:47 2012 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 17 Jul 2012 22:04:47 +0200 Subject: [PATCH] xorg-driver-input-wacom-0.15.0 -> 0.16.0 In-Reply-To: <1342474433.13491.2.camel@pldmachine> References: <1342474433.13491.2.camel@pldmachine> Message-ID: <20120717200446.GB1460@home.lan> On Mon, 16 Jul 2012, Przemo Firszt wrote: > ChangeLog: > 0.15.0 -> 0.16.0 [...] Updated and rebuilt, thanks. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From pluto at agmk.net Wed Jul 18 20:22:41 2012 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Wed, 18 Jul 2012 20:22:41 +0200 Subject: gcc-dirs In-Reply-To: <4FF6F02F.9030106@pld-linux.org> References: <4FF6F02F.9030106@pld-linux.org> Message-ID: <1387741.SnE6svtZ8o@localhost> On Friday 06 of July 2012 17:03:27 Elan Ruusam?e wrote: > /usr/lib64/gcc probably it could be moved into filesystem.spec like others dirs. From przemo at firszt.eu Thu Jul 19 22:25:17 2012 From: przemo at firszt.eu (Przemo Firszt) Date: Thu, 19 Jul 2012 21:25:17 +0100 Subject: [PATCH] hugin build fix In-Reply-To: <20120717200132.GA1460@home.lan> References: <1342260141.17845.5.camel@pldmachine> <20120717200132.GA1460@home.lan> Message-ID: <1342729517.12519.6.camel@pldmachine> >poldek:/all-avail> what-provides OpenGL-glut-devel > 2 package(s) found: > freeglut-devel-2.6.0-1.x86_64 > glut-devel-3.7-22.x86_64 > > Thanks for the effort, but this change is not necessary. > Looks like I should RTFM - I never used what-provides! Thanks! -- Przemo Firszt From glen at pld-linux.org Mon Jul 23 15:36:45 2012 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 23 Jul 2012 16:36:45 +0300 Subject: [packages/synce-core] Add lib, lib-devel and lib-static subpackages Some %files fixes NFY In-Reply-To: <20120720140711.32613.67989@pld-linux.org> References: <20120720140711.32613.67989@pld-linux.org> Message-ID: <500D536D.3000203@pld-linux.org> On 20.07.2012 17:07, wiget wrote: > commit f9ec8f3b7f89d70550bd2a900140a02928947851 > Author: Artur Frysiak > Date: Fri Jul 20 16:06:03 2012 +0200 > > Add lib, lib-devel and lib-static subpackages > Some %files fixes > NFY > why -lib not -libs? even there's just one library now, does not mean there can't be more libraries in the future you wish to include to subpackage -- glen From wiget at pld-linux.org Mon Jul 23 22:36:28 2012 From: wiget at pld-linux.org (Artur Frysiak) Date: Mon, 23 Jul 2012 22:36:28 +0200 Subject: [packages/synce-core] Add lib, lib-devel and lib-static subpackages Some %files fixes NFY In-Reply-To: <500D536D.3000203@pld-linux.org> References: <20120720140711.32613.67989@pld-linux.org> <500D536D.3000203@pld-linux.org> Message-ID: On Mon, Jul 23, 2012 at 3:36 PM, Elan Ruusam?e wrote: > On 20.07.2012 17:07, wiget wrote: >> >> commit f9ec8f3b7f89d70550bd2a900140a02928947851 >> Author: Artur Frysiak >> Date: Fri Jul 20 16:06:03 2012 +0200 >> >> Add lib, lib-devel and lib-static subpackages >> Some %files fixes >> NFY >> > > why -lib not -libs? > > even there's just one library now, does not mean there can't be more > libraries in the future you wish to include to subpackage As you see this package is NFY. So simply rename subpackages. -- Artur Frysiak From wrobell at pld-linux.org Tue Jul 24 01:47:01 2012 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Tue, 24 Jul 2012 00:47:01 +0100 Subject: ipython and python 2.x Message-ID: Hi, I am planning to upgrade IPython to version 0.13, but for Python 3.x only. Python 2.7 is the last 2.x release (released over 2 years ago), so IMHO it is pointless to maintain two versions at the moment. About Python 2.8 un-release http://www.python.org/dev/peps/pep-0404/#un-release-schedule Any thoughts? Regards, w From glen at pld-linux.org Tue Jul 24 05:53:28 2012 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 24 Jul 2012 06:53:28 +0300 Subject: [packages/synce-core] Add lib, lib-devel and lib-static subpackages Some %files fixes NFY In-Reply-To: References: <20120720140711.32613.67989@pld-linux.org> <500D536D.3000203@pld-linux.org> Message-ID: <500E1C38.2030701@pld-linux.org> On 23/07/12 23:36, Artur Frysiak wrote: > On Mon, Jul 23, 2012 at 3:36 PM, Elan Ruusam?e wrote: >> On 20.07.2012 17:07, wiget wrote: >>> >>> commit f9ec8f3b7f89d70550bd2a900140a02928947851 >>> Author: Artur Frysiak >>> Date: Fri Jul 20 16:06:03 2012 +0200 >>> >>> Add lib, lib-devel and lib-static subpackages >>> Some %files fixes >>> NFY >>> >> >> why -lib not -libs? >> >> even there's just one library now, does not mean there can't be more >> libraries in the future you wish to include to subpackage > > As you see this package is NFY. So simply rename subpackages. or maybe the subpackage should be just named -n synce-libsynce to have clean upgrade path? %files lib %defattr(644,root,root,755) %attr(755,root,root) %{_libdir}/libsynce.so.*.*.* %attr(755,root,root) %ghost %{_libdir}/libsynce.so.0 i assume synce-libsynce.spec is now obsolete with synce-core.spec? -- glen From jajcus at jajcus.net Tue Jul 24 09:15:32 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 24 Jul 2012 09:15:32 +0200 Subject: ipython and python 2.x In-Reply-To: References: Message-ID: <20120724071532.GA30868@jajo.eggsoft> On Tue, Jul 24, 2012 at 12:47:01AM +0100, Artur Wroblewski wrote: > I am planning to upgrade IPython to version 0.13, but for Python 3.x only. > > Python 2.7 is the last 2.x release (released over 2 years ago), so > IMHO it is pointless to maintain two versions at the moment. There is still many software written in Python 2.7, there is still a lot of development made using Python 2.7, as some libraries are still only python2 and costs of porting some projects to python3 is too big to be worth it. And IPython is a python development tool. As long as we provide Python 2.7 package we should also provide ipython for it. It may be the last IPython version available upstream for Python2, but it should not be dropped all together just because Python 3.x is the current one. Greets, Jacek From qboosh at pld-linux.org Tue Jul 24 17:44:47 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 24 Jul 2012 17:44:47 +0200 Subject: PLD-update-TODO Message-ID: <20120724154447.GA7475@mail> Has git migration stopped PLD-update-TODO updates? -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Tue Jul 24 17:32:08 2012 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Tue, 24 Jul 2012 17:32:08 +0200 Subject: PLD-update-TODO In-Reply-To: <20120724154447.GA7475@mail> References: <20120724154447.GA7475@mail> Message-ID: <201207241732.08494.arekm@maven.pl> On Tuesday 24 of July 2012, Jakub Bogusz wrote: > Has git migration stopped PLD-update-TODO updates? It is not changed to work with git (yet). -- Arkadiusz Mi?kiewicz, arekm / maven.pl From wrobell at pld-linux.org Tue Jul 24 19:58:52 2012 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Tue, 24 Jul 2012 18:58:52 +0100 Subject: ipython and python 2.x In-Reply-To: <20120724071532.GA30868@jajo.eggsoft> References: <20120724071532.GA30868@jajo.eggsoft> Message-ID: On Tue, Jul 24, 2012 at 8:15 AM, Jacek Konieczny wrote: > On Tue, Jul 24, 2012 at 12:47:01AM +0100, Artur Wroblewski wrote: >> I am planning to upgrade IPython to version 0.13, but for Python 3.x only. >> >> Python 2.7 is the last 2.x release (released over 2 years ago), so >> IMHO it is pointless to maintain two versions at the moment. > > There is still many software written in Python 2.7, there is still a lot > of development made using Python 2.7, as some libraries are still only > python2 and costs of porting some projects to python3 is too big to be > worth it. And IPython is a python development tool. > > As long as we provide Python 2.7 package we should also provide ipython > for it. It may be the last IPython version available upstream for > Python2, but it should not be dropped all together just because Python > 3.x is the current one. 1. Last change in the spec was in October 2011 (for version 0.11). 2. Between 0.11 and 0.13 releases there were two IPython versions - 0.12 and 0.12.1. IMHO, no one is interested in IPython for Python 2.x in our distro at the moment, so maintaining IPython for Python 2.x and 3.x is waste of time. If you still disagree I can put it into separate spec (ipython3.spec). Regards, w From wrobell at pld-linux.org Tue Jul 24 20:55:42 2012 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Tue, 24 Jul 2012 19:55:42 +0100 Subject: ipython and python 2.x In-Reply-To: References: <20120724071532.GA30868@jajo.eggsoft> Message-ID: On Tue, Jul 24, 2012 at 6:58 PM, Artur Wroblewski wrote: > On Tue, Jul 24, 2012 at 8:15 AM, Jacek Konieczny wrote: >> On Tue, Jul 24, 2012 at 12:47:01AM +0100, Artur Wroblewski wrote: >>> I am planning to upgrade IPython to version 0.13, but for Python 3.x only. >>> >>> Python 2.7 is the last 2.x release (released over 2 years ago), so >>> IMHO it is pointless to maintain two versions at the moment. >> >> There is still many software written in Python 2.7, there is still a lot >> of development made using Python 2.7, as some libraries are still only >> python2 and costs of porting some projects to python3 is too big to be >> worth it. And IPython is a python development tool. >> >> As long as we provide Python 2.7 package we should also provide ipython >> for it. It may be the last IPython version available upstream for >> Python2, but it should not be dropped all together just because Python >> 3.x is the current one. > > 1. Last change in the spec was in October 2011 (for version 0.11). > 2. Between 0.11 and 0.13 releases there were two IPython > versions - 0.12 and 0.12.1. > > IMHO, no one is interested in IPython for Python 2.x in our distro > at the moment, so maintaining IPython for Python 2.x and 3.x is > waste of time. > > If you still disagree I can put it into separate spec (ipython3.spec). We agreed off-line on creating ipython3.spec - and it is done. Regards, w From glen at delfi.ee Fri Jul 27 11:40:51 2012 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Fri, 27 Jul 2012 12:40:51 +0300 Subject: template-specs Message-ID: <50126223.3000001@delfi.ee> there's still no place for template-specs in git pls import it to git, or whatever is their place, so changes to git based vcs to them can be committed -- glen From draenog at pld-linux.org Fri Jul 27 12:56:33 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Fri, 27 Jul 2012 12:56:33 +0200 Subject: template-specs In-Reply-To: <50126223.3000001@delfi.ee> References: <50126223.3000001@delfi.ee> Message-ID: <20120727105633.GB1153@camk.edu.pl> On Fri, Jul 27, 2012 at 12:40:51PM +0300, Elan Ruusam?e wrote: > there's still no place for template-specs in git > pls import it to git, or whatever is their place, so changes to git > based vcs to them can be committed I've just put them to projects/template-specs.git. -- Kacper From jajcus at jajcus.net Fri Jul 27 15:17:57 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Fri, 27 Jul 2012 15:17:57 +0200 Subject: template-specs In-Reply-To: <20120727105633.GB1153@camk.edu.pl> References: <50126223.3000001@delfi.ee> <20120727105633.GB1153@camk.edu.pl> Message-ID: <20120727131756.GA32435@jajo.eggsoft> On Fri, Jul 27, 2012 at 12:56:33PM +0200, Kacper Kornet wrote: > On Fri, Jul 27, 2012 at 12:40:51PM +0300, Elan Ruusam?e wrote: > > there's still no place for template-specs in git > > > pls import it to git, or whatever is their place, so changes to git > > based vcs to them can be committed > > I've just put them to projects/template-specs.git. Ok, good enough. Though 'template-specs' alone seems better to me. A related idea: Maybe we could add a new option to the builder script: ./builder --new template_name package_name which would create a new repository, with the spec copied from the template and with all the remotes configured as needed to push that to PLD. What do you think? Greets, Jacek From jajcus at jajcus.net Fri Jul 27 15:22:16 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Fri, 27 Jul 2012 15:22:16 +0200 Subject: Renaming packages in git Message-ID: <20120727132216.GB32435@jajo.eggsoft> Hi, What is the current procedure for renaming packages in git? Both cases: when the package already has some auto/ tags and when it does not. Todays candidate to rename is: python-pyzmq -> python-zmq (python package name is 'zmq' ? 'import zmq') This one has not been built yet, so it is a simple repository rename. Greets, Jacek From draenog at pld-linux.org Fri Jul 27 15:27:40 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Fri, 27 Jul 2012 15:27:40 +0200 Subject: template-specs In-Reply-To: <20120727131756.GA32435@jajo.eggsoft> References: <50126223.3000001@delfi.ee> <20120727105633.GB1153@camk.edu.pl> <20120727131756.GA32435@jajo.eggsoft> Message-ID: <20120727132740.GA3090@camk.edu.pl> On Fri, Jul 27, 2012 at 03:17:57PM +0200, Jacek Konieczny wrote: > On Fri, Jul 27, 2012 at 12:56:33PM +0200, Kacper Kornet wrote: > > On Fri, Jul 27, 2012 at 12:40:51PM +0300, Elan Ruusam?e wrote: > > > there's still no place for template-specs in git > > > pls import it to git, or whatever is their place, so changes to git > > > based vcs to them can be committed > > I've just put them to projects/template-specs.git. > Ok, good enough. Though 'template-specs' alone seems better to me. I would prefer root directory to be clean from repositories to which developers has push access. Right now in root there are only Refs and SPECS which are read only. > A related idea: > Maybe we could add a new option to the builder script: > ./builder --new template_name package_name > which would create a new repository, with the spec copied from the > template and with all the remotes configured as needed to push that to > PLD. builder -a creates repository on server and should configures remotes to push (at least it should to do it). So it is missing only copying of spec from templates. -- Kacper From kornet at camk.edu.pl Fri Jul 27 15:32:50 2012 From: kornet at camk.edu.pl (Kacper Kornet) Date: Fri, 27 Jul 2012 15:32:50 +0200 Subject: Renaming packages in git In-Reply-To: <20120727132216.GB32435@jajo.eggsoft> References: <20120727132216.GB32435@jajo.eggsoft> Message-ID: <20120727133250.GB3090@camk.edu.pl> On Fri, Jul 27, 2012 at 03:22:16PM +0200, Jacek Konieczny wrote: > Hi, > What is the current procedure for renaming packages in git? > Both cases: when the package already has some auto/ tags and when it > does not. Every developer can do: ssh git at git.pld-linux.org move oldname newname Afterwards newname is a copy of old name, and oldname is read only (except in github). Any attempt to push to old name shows message explaining what happens. > Todays candidate to rename is: > python-pyzmq -> python-zmq > (python package name is 'zmq' ? 'import zmq') > This one has not been built yet, so it is a simple repository rename. Done. -- Kacper From glen at pld-linux.org Sat Jul 28 09:05:31 2012 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Sat, 28 Jul 2012 10:05:31 +0300 Subject: pyc in python3 Message-ID: hi i think this hasn't come out as nobody pointed it, but pep-3147 says that the old .pyc only distribution is still possible: http://www.python.org/dev/peps/pep-3147/ For backward compatibility, Python will still support pyc-only distributions, however it will only do so when the pyc file lives in the directory where the py file would have been, i.e. not in the __pycache__ directory. pyc file outside of __pycache__ will only be imported if the py source file is missing. -- glen From glen at pld-linux.org Sat Jul 28 09:55:58 2012 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Sat, 28 Jul 2012 10:55:58 +0300 Subject: Fwd: [packages/expat] up to 2.1.0 Message-ID: <949faf8bbbc5f9afa00912982864b28a@delfi.ee> comments needed here -------- Original Message -------- Subject: [packages/expat] up to 2.1.0 Date: 2012-07-28 10:48 From: glen To: pld-cvs-commit at lists.pld-linux.org Reply-To: pld-devel-en at lists.pld-linux.org, pld-devel-pl at lists.pld-linux.org commit c645eb57cac5b8c9a6dfa0a45d864e366a88661c Author: Elan Ruusam?e Date: Sat Jul 28 10:47:50 2012 +0300 up to 2.1.0 what to do with the hacked soname? can we keep upstream? or should still increase ours? From jajcus at jajcus.net Sat Jul 28 11:54:55 2012 From: jajcus at jajcus.net (Jacek Konieczny) Date: Sat, 28 Jul 2012 11:54:55 +0200 Subject: pyc in python3 In-Reply-To: References: Message-ID: <20120728095455.GA2425@lolek.nigdzie> On Sat, Jul 28, 2012 at 10:05:31AM +0300, Elan Ruusam?e wrote: > i think this hasn't come out as nobody pointed it, but pep-3147 says > that the old .pyc only distribution is still possible: > > http://www.python.org/dev/peps/pep-3147/ > > For backward compatibility, Python will still support pyc-only > distributions, however it will only do so when the pyc file lives in the > directory where the py file would have been, i.e. not in the __pycache__ > directory. pyc file outside of __pycache__ will only be imported if the > py source file is missing. "still possible" and "for backward compatibility" doesn't sound like 'it is a wise thing to do" Greets, Jacek From qboosh at pld-linux.org Sat Jul 28 12:54:08 2012 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 28 Jul 2012 12:54:08 +0200 Subject: Fwd: [packages/expat] up to 2.1.0 In-Reply-To: <949faf8bbbc5f9afa00912982864b28a@delfi.ee> References: <949faf8bbbc5f9afa00912982864b28a@delfi.ee> Message-ID: <20120728105408.GA23085@mail> On Sat, Jul 28, 2012 at 10:55:58AM +0300, Elan Ruusam?e wrote: > comments needed here Follow upstream. Previous change was messy, now it has been cleaned up. > -------- Original Message -------- > Subject: [packages/expat] up to 2.1.0 > Date: 2012-07-28 10:48 > From: glen > To: pld-cvs-commit at lists.pld-linux.org > Reply-To: pld-devel-en at lists.pld-linux.org, > pld-devel-pl at lists.pld-linux.org > > commit c645eb57cac5b8c9a6dfa0a45d864e366a88661c > Author: Elan Ruusam?e > Date: Sat Jul 28 10:47:50 2012 +0300 > > up to 2.1.0 > > what to do with the hacked soname? can we keep upstream? or should > still > increase ours? > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- Jakub Bogusz http://qboosh.pl/ From wrobell at pld-linux.org Mon Jul 30 20:02:43 2012 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Mon, 30 Jul 2012 19:02:43 +0100 Subject: git - removing repository Message-ID: Hi, How to remove repository? BTW. The HOWTO claims that ~/rpm/packages/builder shall be used to build a package, but this one tries to fetch spec files from CVS actually. Regards, w From lordblick at gmail.com Mon Jul 30 20:05:38 2012 From: lordblick at gmail.com (Lord Blick) Date: Mon, 30 Jul 2012 20:05:38 +0200 Subject: git - removing repository In-Reply-To: References: Message-ID: <5016CCF2.5070605@gmail.com> In reply on message at 30.07.2012 20:02, from Artur Wroblewski: > Hi, > > How to remove repository? http://www.pld-linux.org/dokuwiki/cvs2git http://www.pld-linux.org/dokuwiki/howto-git -- Best Regards, Lord Blick From draenog at pld-linux.org Mon Jul 30 20:22:43 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 30 Jul 2012 20:22:43 +0200 Subject: git - removing repository In-Reply-To: References: Message-ID: <20120730182243.GA12441@camk.edu.pl> On Mon, Jul 30, 2012 at 07:02:43PM +0100, Artur Wroblewski wrote: > How to remove repository? Write to gitadmin or to the list. > BTW. The HOWTO claims that ~/rpm/packages/builder > shall be used to build a package, but this one tries to fetch > spec files from CVS actually. Are you sure your ~/rpm/packages/builder is not the one from CVS? rpm-build-tools <= 4.5-4 didn't overwrite it during builder --init-rpm-dir. -- Kacper From wrobell at pld-linux.org Mon Jul 30 20:29:50 2012 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Mon, 30 Jul 2012 19:29:50 +0100 Subject: git - removing repository In-Reply-To: <5016CCF2.5070605@gmail.com> References: <5016CCF2.5070605@gmail.com> Message-ID: On Mon, Jul 30, 2012 at 7:05 PM, Lord Blick wrote: > In reply on message at 30.07.2012 20:02, from Artur Wroblewski: > >> Hi, >> >> How to remove repository? > > http://www.pld-linux.org/dokuwiki/cvs2git > http://www.pld-linux.org/dokuwiki/howto-git Nothing there. Regards, w From draenog at pld-linux.org Mon Jul 30 20:45:29 2012 From: draenog at pld-linux.org (Kacper Kornet) Date: Mon, 30 Jul 2012 20:45:29 +0200 Subject: git - removing repository In-Reply-To: References: <5016CCF2.5070605@gmail.com> Message-ID: <20120730184529.GC12441@camk.edu.pl> On Mon, Jul 30, 2012 at 07:29:50PM +0100, Artur Wroblewski wrote: > On Mon, Jul 30, 2012 at 7:05 PM, Lord Blick wrote: > > In reply on message at 30.07.2012 20:02, from Artur Wroblewski: > >> Hi, > >> How to remove repository? > > http://www.pld-linux.org/dokuwiki/cvs2git > > http://www.pld-linux.org/dokuwiki/howto-git In http://www.pld-linux.org/dokuwiki/cvs2git action "delete package" in the table. -- Kacper From wrobell at pld-linux.org Mon Jul 30 20:47:59 2012 From: wrobell at pld-linux.org (Artur Wroblewski) Date: Mon, 30 Jul 2012 19:47:59 +0100 Subject: git - removing repository In-Reply-To: <20120730184529.GC12441@camk.edu.pl> References: <5016CCF2.5070605@gmail.com> <20120730184529.GC12441@camk.edu.pl> Message-ID: On Mon, Jul 30, 2012 at 7:45 PM, Kacper Kornet wrote: > On Mon, Jul 30, 2012 at 07:29:50PM +0100, Artur Wroblewski wrote: >> On Mon, Jul 30, 2012 at 7:05 PM, Lord Blick wrote: >> > In reply on message at 30.07.2012 20:02, from Artur Wroblewski: > >> >> Hi, > >> >> How to remove repository? > >> > http://www.pld-linux.org/dokuwiki/cvs2git >> > http://www.pld-linux.org/dokuwiki/howto-git > > In http://www.pld-linux.org/dokuwiki/cvs2git action "delete package" > in the table. ok, thanks, w From glen at pld-linux.org Mon Jul 30 20:48:08 2012 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 30 Jul 2012 21:48:08 +0300 Subject: git - removing repository In-Reply-To: References: Message-ID: <5016D6E8.1000600@pld-linux.org> On 07/30/2012 09:02 PM, Artur Wroblewski wrote: > Hi, > > How to remove repository? > > BTW. The HOWTO claims that ~/rpm/packages/builder > shall be used to build a package, but this one tries to fetch > spec files from CVS actually. if it manipulates with CVS, you have most likely wrong version of builder script builder script to be used with git is from: http://git.pld-linux.org/?p=packages/rpm-build-tools.git;a=history;f=builder.sh and in that case you probably want to start with this letter: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2012-July/022772.html -- glen From mike at osdn.org.ua Mon Jul 30 21:24:30 2012 From: mike at osdn.org.ua (Michael Shigorin) Date: Mon, 30 Jul 2012 22:24:30 +0300 Subject: git - removing repository In-Reply-To: <20120730182243.GA12441@camk.edu.pl> References: <20120730182243.GA12441@camk.edu.pl> Message-ID: <20120730192430.GN31323@osdn.org.ua> On Mon, Jul 30, 2012 at 08:22:43PM +0200, Kacper Kornet wrote: > > How to remove repository? > Write to gitadmin or to the list. ALT's experience shows that tasks like this one do need to be automated -- e.g. there used to be a similar recommendation for cases when a package was built from srpms then migrated to git and then the (new) packager might have decided it was a mistake/suboptimal decision, which would result in a request to move away a git branch corresponding to a particular repo which was also serving as a "lock" barring srpm builds in favour of git builds... well, in the end the "I know what I ask for" button was invented. HTH -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ From lm at zork.pl Tue Jul 31 13:55:50 2012 From: lm at zork.pl (=?UTF-8?B?xYF1a2FzeiBNaWNoYWxza2k=?=) Date: Tue, 31 Jul 2012 13:55:50 +0200 Subject: kernel oops when playing flash movies from chrome Message-ID: <5017C7C6.80201@zork.pl> After playing a few flash movies under Chrome I got kernel panic with kernel 3.3.7. Does anyone have a similar problem? Regards, ?ukasz