Re: [gentoo-dev] [RFC] New eclass for x11 packages
Tomáš Chvátal wrote: and renamed snapshot variable into saner XORG_EAUTORECONF. Does it fit your needs? Sane enough for me ;), thank you! /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] [RFC] New eclass for x11 packages
On 03/01/2010 10:58 AM, Michael Haubenwallner wrote: Tomáš Chvátal wrote: and renamed snapshot variable into saner XORG_EAUTORECONF. Does it fit your needs? Sane enough for me ;), thank you! /haubi/ I'd prefer EAUTORECONF (as it's already used in xfconf.eclass for the same purpose, and has no reason to differ) or even SNAPSHOT, but XORG_ prefix seems redudant - Samuli
[gentoo-dev] Monthly Gentoo Council Reminder for March
This is your monthly friendly reminder ! Same bat time (typically the 3rd Thursday at 1800 UTC / 2000 CET / 1400 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
[gentoo-dev] Lastrite: dev-tex/mplib
# Samuli Suominen ssuomi...@gentoo.org (01 Mar 2010) # Orphaned library. Doesn't compile with recent toolchain. # Masked for removal in 30 days. Bug 300595. dev-tex/mplib
Re: [gentoo-dev] metadata.xml: changepolicies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-03-2010 06:39, Markos Chandras wrote: On Friday 26 February 2010 18:40:47 Alec Warner wrote: You mistake the intent I think. We deploy automation because humans fail; even when they have the best intentions. We make typos, copy and paste errors, accidentally leave whitespace, type commands into the wrong shell, hit the wrong key that kills our session, etc. Smart people avoid work by making a computer do parts that are easily automated; which is why the proposed system is so fine-grained. We can likely add some logic to our current toolset to remind the human that they may have further obligations than just typing repoman commit (like asking on a bug, a mailing list, irc, etc.) With a really simple system; we cannot easily automate when to do what because the criteria are so broad. I agree that a moderately complex system is useless for humans (I'd ignore it straight out) which is why we should write software to do the work for us. I am much more likely to respond to a message from repoman telling me I need to file a bug first as opposed to me looking at metadata.xml every time I commit something. Sure there are people who never read repoman output and commit utter crap to the tree; but I do not really expect 100% success from any system we deploy; I'd be happy with 60% honestly. In my eyes, we don't need a smarter repoman to check whether we are supposed or not to do a specific commit. What we need are rules ( stricter or not ) which DO apply to all developers, and a team ( devrel ) which will be responsible to do that. Repoman will not help the situation but it will add a new level of complexity into our already complex communication system. We need an active devrel team which will postpone commit access to those developers who are repeatedly fail to behave correctly whatever that means. That said, i am totally again messing with metadata.xml as long as there problem resides in a much higher level Markos, the job of Developer Relations is not to act as a repo police. What you're talking about is mostly a QA issue. Whenever Developers, in particular maintainers for a package, feel someone ignored or broke policy and report that to Developer Relations, than it will get into the team's radar. However, Developer Relations is not and will not grep the commits ml to find offenders. PS - As Alec suggested, automated tools that help identify and report issues are a good idea. In the least, when someone ignores a rule repoted by repoman, you can be sure it wasn't a distraction, but a conscious decision to ignore its output. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLi7U1AAoJEC8ZTXQF1qEPJHEP/3eZp8fFoqdcgNJJVDHS6Xa3 YXKUYthkEzZZQhtfPgQdRh4pYqFwrc+d+uq1CoRLECLOuhNk0m+wu+jN7UByJGQp wSlZMFxHuvI410oHhGTkNH7Mes9BBGKF3hYRyyd5og7qCseo3S6BTvJSdvV1QbH9 l1W3inag56ZjwCMWDjr2Z/iqhiym6lPBI7ShEz13SYffOKWrbMErDqIDi/JbIb4a N7YKhTUEqsfYkVZbO42uj0wVWGR+mz0lAwJozh0jLvTtLLQc3xcr74SlsRno18k6 922JXxatbDQdsL3xDY4rxWUKlF2q/HDNLdKx4LLEIyr+oOH1V6Jaf9ygWlfhjQGQ 6KV6yQSvRcDhIGg4PLirfzXswFqxjfVc1jtc1JEHRjSFsWxAfZ4FNNk7w+XHo0Cx 5oPV5yNKCnYfOmq2BLyVQI8VALQ0dnv3OW3Hg1nGv0ILcrM6g35cvmPNqgyZXDid 5ut6u86U+JSFhq2geeCaIBqaZbOpWy8wJ7zIZ7MjMx9CzYpSHF4olAVy0JY+sQe7 NjNy1BM+gENqlFezltQGDaHwA1A/xNsaH0c8P0Zlc7QeoNQw/KQn7n5EpsWr+RR6 8c/mOQAruyA3BsWD2g+NOU64+Yo7NuGUAo94broIVBNf5wWbynC1pPFU7r3g0055 d385QdXsv8MlvosRkWck =tXdy -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption
The 72 hours have passed, so I take it we are ready to officially publish this. Richard, are you going to commit this? Thanks, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption
On 03/01/2010 09:24 AM, Ben de Groot wrote: The 72 hours have passed, so I take it we are ready to officially publish this. Richard, are you going to commit this? I will do so today.
[gentoo-dev] Lastrite: reverse dependencies of x11-libs/qt:3 (bug 283429)
# Ben de Groot yng...@gentoo.org (01 Mar 2010) # Grand mask of qt:3 and remaining reverse dependencies # pending removal on 21 Mar 2010 (bug 283429) =x11-libs/qt-3* app-misc/chesstask app-office/indeview dev-db/qt-unixODBC dev-embedded/yapide dev-util/bouml dev-util/gambas dev-util/qsoapman games-board/mahjongg3d =games-board/qgo-1* games-board/r-katro games-emulation/qtvba games-engines/qtads games-puzzle/quadros games-server/WarpPipe games-strategy/spacehulk games-util/agistudio games-util/emilia-pinedit games-util/showeq media-gfx/engauge net-dialup/umtsmon net-im/openc6 net-im/sim net-misc/kiax net-voip/kphone net-voip/twinkle net-wireless/waveselect sci-calculators/kunit sci-chemistry/xdrawchem sci-electronics/vstgl sci-mathematics/kseg sci-misc/qcad x11-misc/ifpgui x11-themes/polymer -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
[gentoo-dev] Lastrite: libmpcdecsv7
# Samuli Suominen ssuomi...@gentoo.org (01 Mar 2010) # Orphaned library for obsolete musepack API support. # Doesn't work with autoconf 2.65. Masked for removal # in 30 days. See bug 294582. media-libs/libmpcdecsv7 (The new libmpcdec API is in musepack-tools which all pkgs in gentoo-x86 now use. :-)
Re: [gentoo-dev] Marking bugs for bugday?
Hello, After having a talk with Sebastien (aka sping), I think it is time to give a clear reply from my side to this discussion, given that I am still a member of the project and I am willing to rescue it. At this moment, the Bugday Project is starving because no one feeds it. It needs to eat bugs, so before anything let's fill up the plate with as many of them as possible. In order to do this, we need to change a few things here and there so that the bugs flow correctly towards the project. The first thing that would help us a lot is to actually have a keyword 'bugday' in our bugzilla. This will definitely help us out a lot when managing all the tickets and be able to produce some sort of report. The second thing that comes to my mind is pretty internal, but requires some external interaction. We need to work ahead of the Bug Day and be capable of having everything needed ready. Having the proper tools is very important for this task, and getting control of bugday.gentoo.org and be able to upload our own content would be great. It's a virtual apache host running in the same place as bugs.gentoo.org, as it requires access to the database (although this does not necessarily need to be like this if the database is accessible through the network). The third thing that we need is the proper audience. We need more PR. My proposal here is to start with an announcement two weeks before the Bug Day, followed by an announcement the week before and a reminder the day before. This needs to happen in publicly visible places (and has happened in some of them as far as I recall): forums, gentoo-user, gentoo-dev, gentoo-announce, gentoo-dev-announce, the newsletter (dead?) and the website. Having people related to the Bug Day project posting to their blogs can help a lot in this case as well. The fourth thing, is to actually get the proper information in the proper format. We need a compromise from each of the teams, so that they send us at least one bug every month that can be delegated to our users. Then the Bugday Project can decide whether the bug is appropriate or not for delegation, and tag it with the before-mentioned 'bugday' keyword. The teams should send the list of bugs, with each bug filling a skeleton similar to the following: * Ticket number. * Title. * Clear, easy to understand, short description of what we want to delegate to our users. * Topic of the task (as in networking, C/C++, python, ebuild, etc.). * Difficulty of the task. * Detailed step-by-step description of the task. Let me hear of what you have to say to all this. Regards. If we have this piece of information, we can organize ourselves better. On Mon, Mar 1, 2010 at 2:35 AM, Joshua Saddler nightmo...@gentoo.org wrote: On Sun, 28 Feb 2010 21:04:04 +0100 Sebastian Pipping sp...@gentoo.org wrote: On 02/28/10 20:54, Markos Chandras wrote: Do we still have bugdays? Who is taking care of this project and the respective webpage? I think we first need to answer these questions before we even consider resurrect this project welp - away He's not away, he's retired. It's just taken several months to close his bug. gurligebis - no reply yet I thought gurli was also retired. -- Ioannis Aslanidis http://www.deathwing00.org deathwing00[at]gentoo.org 0x47F370A0
[gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
For some reason beyond my understanding, we have the cups useflag enabled by default in profiles. This has started to generate circular dependencies, at least for desktop profile users (gtk - cups - poppler - gtk). I propose we no longer enable the cups useflag. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 03/01/2010 01:24 PM, Ben de Groot wrote: For some reason beyond my understanding, we have the cups useflag enabled by default in profiles. This has started to generate circular dependencies, at least for desktop profile users (gtk - cups - poppler - gtk). I propose we no longer enable the cups useflag. If you don't want to disable the cups flag globally, you might choose to disable for gtk+ by default in profiles/base/package.use like this: x11-libs/gtk+ -cups That can be overridden by user's USE=cups setting in make.conf, so the only effect would be to break the circular dependency by default. -- Thanks, Zac
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Mon, Mar 1, 2010 at 22:24, Ben de Groot yng...@gentoo.org wrote: For some reason beyond my understanding, we have the cups useflag enabled by default in profiles. I'm +1 on disabling it by default. Cheers, Dirkjan
Re: [gentoo-dev] Marking bugs for bugday?
On 1 March 2010 22:17, Ioannis Aslanidis aslani...@gmail.com wrote: [...] Great ideas! The teams should send the list of bugs, with each bug filling a skeleton similar to the following: * Ticket number. * Title. * Clear, easy to understand, short description of what we want to delegate to our users. * Topic of the task (as in networking, C/C++, python, ebuild, etc.). * Difficulty of the task. * Detailed step-by-step description of the task. This will not work. You need to keep things really simple for our devs. I don't see anybody but the most dedicated ones, who also happen to have a lot of time on their hands, fill out such a detailed form. I'd say let devs just nominate bugs, either by adding BugDay to the keywords field or something similar, or by passing the bugday team a list of bug numbers. Then the bugday team can sort these and see if any instructions are needed. They could always ask the involved devs/teams for more info when necessary. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Marking bugs for bugday?
I understand that the implication and the time demand of this last point may be a little excessive. If anyone still has the time to fill the skeleton in, they are still welcome to do it. Otherwise with the bug list it will be enough. I would prefer to keep the keyword for Bugday Members to administer. On Mon, Mar 1, 2010 at 11:19 PM, Ben de Groot yng...@gentoo.org wrote: On 1 March 2010 22:17, Ioannis Aslanidis aslani...@gmail.com wrote: [...] Great ideas! The teams should send the list of bugs, with each bug filling a skeleton similar to the following: * Ticket number. * Title. * Clear, easy to understand, short description of what we want to delegate to our users. * Topic of the task (as in networking, C/C++, python, ebuild, etc.). * Difficulty of the task. * Detailed step-by-step description of the task. This will not work. You need to keep things really simple for our devs. I don't see anybody but the most dedicated ones, who also happen to have a lot of time on their hands, fill out such a detailed form. I'd say let devs just nominate bugs, either by adding BugDay to the keywords field or something similar, or by passing the bugday team a list of bug numbers. Then the bugday team can sort these and see if any instructions are needed. They could always ask the involved devs/teams for more info when necessary. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __ -- Ioannis Aslanidis http://www.deathwing00.org deathwing00[at]gentoo.org 0x47F370A0
Re: [gentoo-dev] Marking bugs for bugday?
Ioannis Aslanidis aslani...@gmail.com said: Hello, [... whole bunch of ideas ...] Let me hear of what you have to say to all this. Has anyone looked at how others projects do bugdays? We shouldn't need to reinvent the wheel here and can probably get some great ideas from other distributions out there. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com
Re: [gentoo-dev] Marking bugs for bugday?
On 01/03/2010 22:19, Ben de Groot wrote: On 1 March 2010 22:17, Ioannis Aslanidisaslani...@gmail.com wrote: [...] Great ideas! The teams should send the list of bugs, with each bug filling a skeleton similar to the following: * Ticket number. * Title. * Clear, easy to understand, short description of what we want to delegate to our users. * Topic of the task (as in networking, C/C++, python, ebuild, etc.). * Difficulty of the task. * Detailed step-by-step description of the task. This will not work. You need to keep things really simple for our devs. I don't see anybody but the most dedicated ones, who also happen to have a lot of time on their hands, fill out such a detailed form. I'd say let devs just nominate bugs, either by adding BugDay to the keywords field or something similar, or by passing the bugday team a list of bug numbers. Then the bugday team can sort these and see if any instructions are needed. They could always ask the involved devs/teams for more info when necessary. Cheers, You don't need to make it compulsory to fill out those fields and if just 1 out of every 10 or 20 bugs gets that filled then it is still a big leap forward. Or... Ask for a dev whose whole job is to fill out those forms. I'm sure there are plenty of non-coders out there who would be willing to do it, even a team!
Re: [gentoo-dev] Python-3.2-related changes
2010-03-01 06:13:19 Max Arnold napisał(a): On Mon, Mar 01, 2010 at 04:13:10AM +0100, Arfrever Frehtes Taifersar Arahesis wrote: (Please note that wrapper scripts generated by python_generate_wrapper_scripts() work with all versions of Python from 2.4 to 3.2, so shebangs in these scripts do not need any changes.) What is the recommended policy about using or not using wrapper scripts? They are to solve collisions between scripts installed with different Python versions, not to support Python 3. Maybe it also should be documented? I will document it. [1] http://www.gentoo.org/proj/en/Python/developersguide.xml What about merging (or at least linking) this documentation with Gentoo Development Guide? The latter one already contains distutils related chapter and probably it is a good idea to decribe python.eclass usage in another chapter or eclass reference. It's better to maintain our documentation separately. Gentoo Development Guide can contain URL to http://www.gentoo.org/proj/en/Python/developersguide.xml. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Marking bugs for bugday?
Quoting Ioannis Aslanidis aslani...@gmail.com: I would prefer to keep the keyword for Bugday Members to administer. I don't think that sending mails would work well. If you want extra control/QA for bugday team members I would propose two different keywords: one for bugday candidates and one for confirmed bugday bugs. Any dev could mark bugs as candidates easily and without delays while you could still reserve acknoledgement to you. Sebastian
[gentoo-dev] Re: eutils changes wrt EAPI-3 - ebeep and epause no longer available
On Thursday 25 of February 2010 04:11:49 Maciej Mrozowski wrote:
On Wednesday 17 of February 2010 03:25:16 Maciej Mrozowski wrote:
If no objections, I'm going to commit in 5 days the following patch to
eutils.eclass
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.333
diff -u -B -r1.333 eutils.eclass
--- eutils.eclass 17 Feb 2010 17:10:23 - 1.333
+++ eutils.eclass 25 Feb 2010 03:11:32 -
@@ -54,13 +54,11 @@
else
ebeep() {
- [[ $(type -t eqawarn) == function ]] \
- eqawarn QA Notice: ebeep is not defined in EAPI=3, please
file a bug at http://bugs.gentoo.org;
+ ewarn QA Notice: ebeep is not defined in EAPI=${EAPI}, please file
a bug at http://bugs.gentoo.org;
}
epause() {
- [[ $(type -t eqawarn) == function ]] \
- eqawarn QA Notice: epause is not defined in EAPI=3, please
file a bug at http://bugs.gentoo.org;
+ ewarn QA Notice: epause is not defined in EAPI=${EAPI}, please
file a bug at http://bugs.gentoo.org;
}
fi
No objections, so commiting this one.
--
regards
MM
Re: [gentoo-dev] Re: Marking bugs for bugday?
On Mon, Mar 1, 2010 at 5:09 PM, Duncan 1i5t5.dun...@cox.net wrote: Sebastian Pipping posted on Tue, 02 Mar 2010 01:02:05 +0100 as excerpted: Quoting Ioannis Aslanidis aslani...@gmail.com: I would prefer to keep the keyword for Bugday Members to administer. I don't think that sending mails would work well. If you want extra control/QA for bugday team members I would propose two different keywords: one for bugday candidates and one for confirmed bugday bugs. Any dev could mark bugs as candidates easily and without delays while you could still reserve acknoledgement to you. ... And here I'm proposing three: BUGDAY (nomination) BUGDAY-ACCEPTED (or whatever is thought appropriate) NOBUGDAY (or BUGDAY-DECLINED, or BUGDAY-REFUSED, or...) I think the last one is over-engineering a bit; bugzilla keywords are not permanent so this will likely not help as much as one may think in practice. Old bugday keywords are visible in the activity trail. -A The latter would be for nominated bugs that were declined as inappropriate for whatever reason, to help prevent them being nominated again. Presumably there'd be a comment added explaining why as well, but the keyword would be what shows up in someone's face if they're thinking about keywording it BUGDAY. -- 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
RE: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
+1 for disabling it by default, long as it's done with care, because it pretty hard for a newbie to understand what the hell is going on on his first installation and a lot of people use the desktop profile since it's one of the best way to install Gentoo for the first time. Sylvain Date: Tue, 2 Mar 2010 00:06:10 +0200 From: ssuomi...@gentoo.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps On 03/01/2010 11:24 PM, Ben de Groot wrote: For some reason beyond my understanding, we have the cups useflag enabled by default in profiles. This has started to generate circular dependencies, at least for desktop profile users (gtk - cups - poppler - gtk). I propose we no longer enable the cups useflag. Cheers, +1 for disabling it by default, long as it's done with care for example, see how it will change the pkgs using USE cups, some might need a + default flag or they might get defaulted to lpr (and that is really only a example) _
