Re: [gentoo-dev] Packages up for grab
В Вск, 16/11/2008 в 21:13 +0100, Gilles Dartiguelongue пишет: here is a list of packages gnome herd would like to get rid of since no-one seem to take care of them and users are not so verbose about it either: * app-text/ggv https://bugs.gentoo.org/show_bug.cgi?id=223427 Upstream there was a discussion of interest. Pointing at random mail in that tread: http://mail.gnome.org/archives/gnome-hackers/2006-July/msg8.html So there are people which prefer ggv over evince... * net-news/straw https://bugs.gentoo.org/show_bug.cgi?id=187285 This bug is already fixed since straw-0.27 is in the tree. * net-news/logjam https://bugs.gentoo.org/show_bug.cgi?id=181236 If no-one takes them, I'll proceed to package removal. This are the cases where removal is not a best solution. straw and logjam have upstream so it's better to move them into Sunrise: users who use this packages could maintain them there... For ggv it seems that it's better to leave it as is. May be just stabilize the most recent version - let arch teams test it and if it works no need to remove it from the tree. -- Peter.
Re: [gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!
В Вск, 16/11/2008 в 15:33 -0600, Ryan Hill пишет: - FEATURES=test failures; And what we are supposed to do if upstream states that tests are not supposed to be ran on users systems and exists for package development only? For example one upstream states that the purpose of tests is to test integrity of the program itself and not program's environment and he (upstream) is pretty sure that program works as designed... Also relevant question: some tests require root privileges. What we should do in such case? -- Peter.
Re: [gentoo-dev] Packages up for grab
Peter Volkov a écrit : В Вск, 16/11/2008 в 21:13 +0100, Gilles Dartiguelongue пишет: here is a list of packages gnome herd would like to get rid of since no-one seem to take care of them and users are not so verbose about it either: * app-text/ggv https://bugs.gentoo.org/show_bug.cgi?id=223427 Upstream there was a discussion of interest. Pointing at random mail in that tread: http://mail.gnome.org/archives/gnome-hackers/2006-July/msg8.html So there are people which prefer ggv over evince... Nothing more recent than that? 2 1/2 years ago seems pretty far away... The last meaningful commit was done a little over 3 years ago... For ggv it seems that it's better to leave it as is. May be just stabilize the most recent version - let arch teams test it and if it works no need to remove it from the tree. ggv is a dead project. Upstream refused to fix performance issues I had with it a few years ago. Evince is _now_ both faster and prettier (I agree it wasn't true at first, ggv was much faster) I'd rather we take ggv out of portage. We'd be doing our users a big favor. Cheers Rémi
[gentoo-dev] Package up for grabs
dev-util/cvs2svn If anyone wants it, please have at it. I haven't used it in 2 years.
Re: [gentoo-dev] Package up for grabs
On 11:27 Mon 17 Nov , Doug Goldstein wrote: dev-util/cvs2svn If anyone wants it, please have at it. I haven't used it in 2 years. This is the tool I've been using for git conversions, FWIW, so I'll maintain it as long as it's relevant there. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpVykq85LKJB.pgp Description: PGP signature
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
Tobias Scherbaum [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 17 Nov 2008 19:08:39 +0100: Process might be as easy as CC'ing a arch-tinderbox on a bug, a script does parse the bug number out of the mail being sent out and using gatt it catches the ebuild to test, compiles it and reports back a) failure/success, b) error log as attachment if it fails plus c) if there was a test-phase. Surely, you're talking something other than the publicly writable CC field, something writable by devs (and maybe ATs) only, right? Otherwise it's a security nightmare. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Re: Please review: function epunt_la_files for eutils.eclass
Peter Alfredsen wrote: I've given this some thought and I think I've been convinced that dberkholz' position is probably the most tenable. If this is to be done, we should do it in a documented Gentooish way. The problem with going down the FEATURES road are two-fold: 1) What should the behavior of the FEATURES flag be? I think it should act like an INSTALL_MASK=*.la and EXTRA_ECONF=--disable-static There should also be a function, let's call it exemptthis.la that would exempt a .la file from being punted, so the RESTRICT could be made on a per-la file basis. If it's a FEATURE defaulting to off, which makes sense from the opt-in perspective, surely a simple Property would do the job for most cases? 2) Who implements in portage? [...I know nothing of portage internals...] Properties are bedded in, all you need is a bit of BASH, to be run for those packages you maintain; and to add the functionality you mentioned above, etc. 3) Grunt work? This should be rather easy. Just assign the bugs to me and I shall add RESTRICTs as-needed. Might be wise to prove it on a smaller subset first, for those packages where you know it's not going to cause an issue, and if it did it wouldn't cause a machine to be unbootable. (Personally I'd understand a user being peeved if they couldn't get their desktop up, but it's not that big a deal provided there's an easy command to run to fix it, and there's notice given; this is Gentoo, after all.) Anyway, we really need to start punting .la files one way or the other. For desktop users of our distro, they do a lot more harm than good. For embedded, perhaps static linking serves some purpose, but really, if you can't afford dynamic linking, what are you going to run on your board? Libtool is sweet from a software developer's pov, especially in its heyday. OFC it might cause distros a bit of aggro, but hey you get to decide what to patch and how. I'm in favour so long as it is only ever an opt-in, or not enabled in anything but developer or desktop/Linux profiles (the latter after at least a year or two of testing and bug resolution.)
[gentoo-dev] Please avoid absolute paths in patched filenames
I ask it here as a favour, please avoid using absolute paths in the filenames of patched files. This mean avoid having stuff like --- foobar/foo.c +++ /tmp/foobar/foobar.c This tends to break from time to time, and I had to fix at least three packages since I started my treewide build for these problems. I already asked Zac about adding such a check on repoman, but in the mean time I'd like to ask here for people to verify their packages. I actually am culprit of doing this some time ago but I learnt my lesson the hard way :P My suggestion for everybody else is to use quilt when you need to write patches. And if you have patches with the filenames like I shown above, you can change it the git way so that it becomes: --- a/foobar/foo.c +++ b/foobar/foo.c and the problem is usually solved. Thanks, -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgp1IcCBfPorv.pgp Description: PGP signature
Re: [gentoo-dev] Please avoid absolute paths in patched filenames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This check was added to epatch all of a sudden breaking all working patches in the tree, although defending those patches having absolute paths, we as Java team had several bugs filed due to that. Maybe the tree should be scanned for those and fixed. Diego 'Flameeyes' Pettenò yazmış: I ask it here as a favour, please avoid using absolute paths in the filenames of patched files. This mean avoid having stuff like --- foobar/foo.c +++ /tmp/foobar/foobar.c This tends to break from time to time, and I had to fix at least three packages since I started my treewide build for these problems. I already asked Zac about adding such a check on repoman, but in the mean time I'd like to ask here for people to verify their packages. I actually am culprit of doing this some time ago but I learnt my lesson the hard way :P My suggestion for everybody else is to use quilt when you need to write patches. And if you have patches with the filenames like I shown above, you can change it the git way so that it becomes: --- a/foobar/foo.c +++ b/foobar/foo.c and the problem is usually solved. Thanks, - -- Sincerely, Serkan KABA Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkhxhgACgkQRh6X64ivZaK4wwCeIUCZ6BIqWvo7tiFXpXa+Njpe AL4An2E5N+yGaIfv1kPaV4Gc9W8DG3M3 =2nhY -END PGP SIGNATURE-
[gentoo-dev] Re: Please avoid absolute paths in patched filenames
Serkan Kaba [EMAIL PROTECTED] writes: This check was added to epatch all of a sudden breaking all working patches in the tree, although defending those patches having absolute paths, we as Java team had several bugs filed due to that. Maybe the tree should be scanned for those and fixed. Fun, I didn't really notice it was an epatch specific code that failed, I know it fails when the paths don't add up between systems and I thought that was it.. Okay, I guess I'll get to fix the rest tonight after Bones... -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpkepw47URBE.pgp Description: PGP signature
[gentoo-dev] Re: Please avoid absolute paths in patched filenames
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: Fun, I didn't really notice it was an epatch specific code that failed, I know it fails when the paths don't add up between systems and I thought that was it.. Okay, I guess I'll get to fix the rest tonight after Bones... All the tree should be sanitised now for what concerns patches in $FILESDIR ... It's up to you to see if there are broken patches on mirrors, I guess. My tinderbox will try its best to find them anyway. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgp6W1we1FJi0.pgp Description: PGP signature
Re: [gentoo-dev] Please avoid absolute paths in patched filenames
On Mon, 2008-11-17 at 20:24 +0100, Diego 'Flameeyes' Pettenò wrote: I ask it here as a favour, please avoid using absolute paths in the filenames of patched files. This mean avoid having stuff like --- foobar/foo.c +++ /tmp/foobar/foobar.c This tends to break from time to time, and I had to fix at least three packages since I started my treewide build for these problems. I already asked Zac about adding such a check on repoman, but in the mean time I'd like to ask here for people to verify their packages. I actually am culprit of doing this some time ago but I learnt my lesson the hard way :P My suggestion for everybody else is to use quilt when you need to write patches. And if you have patches with the filenames like I shown above, you can change it the git way so that it becomes: --- a/foobar/foo.c +++ b/foobar/foo.c and the problem is usually solved. Could you please expand on what the actual problem is for reference, having never seen them fail myself or hear any fail for others? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Mon, 17 Nov 2008 10:10:57 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: snip The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the latest stable ebuild of an arch without the approval of the arch team or he/she will be fed to the Galrog. As long as the maintainer can pass off the maintenance of the (sometimes dozens) of ancient ebuilds that need to be kept around for that one arch to the arch team, and re-assign any resulting bugs to them, fine. Since when do we maintain ancient ebuilds kept around for an arch team now? Drop the other keywords and get on with your life. Or, alternatively, unilaterally decide to drop all keywords for the arch in question. Yes, that was extreme, but no more than the previous quoted statement. You sir, have an appointment with the Galrog. There needs to be give and take here. Yes, it's really bad to remove the last stable ebuild for an arch. However, its *also* bad to have to maintain years old versions of lots of ebuilds. And yes, it will be a lot, since most packages don't exist in a vacuum, and require older deps (which possibly will be maintained by other maintainers than the first package, causing a cascade of old packages in the tree). All this will do in practice is cause maintainers to ignore bugs for those old packages for those few arches, since the maintainer won't have that version installed. In fact, in my experience, they frequently *can't* have that version installed, since it requires older versions of other packages that need to be upgraded to maintain newer versions of the same package. How much bit rot do we want in the tree? Daniel (who is both an arch team member and gnome team lead) Did you not read the first part of the suggestion? - maintainer files a stabilization request. - arch testers do their thing - arch teams gradually mark ebuild stable - maintainer pokes arm, sh, mips, ppc (only an example, relax) - mips reminds maintainer there is no stable mips keyword - ppc stables - maintainer waits - maintainer pokes arm, sh - maintainer waits - maintainer marks stable on arm, sh - maintainer removes ancient stable ebuilds that maintainer doesn't want to maintain anymore because everyone has a nice new stable ebuild. - maintainer goes out for a frosty beverage the idea is that arch teams are around to help the maintainer test on architectures the maintainer doesn't have. if the arch teams are unable or unwilling to help at the moment, that should not stop the maintainer from maintaining. also keep in mind that this only occurs after the arch teams have ample time to interject (which is why i suggested 90 days). if an arch team can't comment on a bug in 3 months (a simple i'd rather this not go stable until i can test it further should be enough) then they have IMO lost their opportunity to matter. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Please avoid absolute paths in patched filenames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mart Raudsepp yazmış: On Mon, 2008-11-17 at 20:24 +0100, Diego 'Flameeyes' Pettenò wrote: I ask it here as a favour, please avoid using absolute paths in the filenames of patched files. This mean avoid having stuff like --- foobar/foo.c +++ /tmp/foobar/foobar.c This tends to break from time to time, and I had to fix at least three packages since I started my treewide build for these problems. I already asked Zac about adding such a check on repoman, but in the mean time I'd like to ask here for people to verify their packages. I actually am culprit of doing this some time ago but I learnt my lesson the hard way :P My suggestion for everybody else is to use quilt when you need to write patches. And if you have patches with the filenames like I shown above, you can change it the git way so that it becomes: --- a/foobar/foo.c +++ b/foobar/foo.c and the problem is usually solved. Could you please expand on what the actual problem is for reference, having never seen them fail myself or hear any fail for others? See bug #237667 and dev-thread http://archives.gentoo.org/gentoo-dev/msg_777d416bb082a45b0e4848d8db5bfec8.xml - -- Sincerely, Serkan KABA Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkiSXEACgkQRh6X64ivZaJfgACfbA/wjlEoldGyZUaDev0jXyng /SkAoIHS1c8x2bAHbeFDO+r4M8NIK++R =+Ho/ -END PGP SIGNATURE-
