[gentoo-dev] Re: RFC: lzma tarball usage
Ulrich Mueller [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 07 May 2008 16:55:39 +0200: The decoder of lzma-utils is also written in C only. So it would also be possible to compile lzmadec without any need for C++. Just call make in subdirs liblzmadec and lzmadec. What about USE=decode-only or something similar for lzma-utils, then? If desired, it could even be masked on normal profiles, but would then be there for the embedded and releng folks. -- 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@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On 03:04 Wed 07 May , Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Here's the suggested agenda. Please feel free to respond to some of the commentary within, because it's hard for me to usefully summarize a topic's background in an entirely objective manner. Thanks, Donnie Requested attendees === Active developer: araujo, anyone who could talk about how to get this script running on Gentoo infra PMS: ciaranm, pkgcore dev, portage dev, any other tools that care about versions Enforced retirement: fmccor, musikc musikc has already informed us that she can't make it until an hour later, so this is the final topic. New process === The last few meetings have dragged out for hours unnecessarily. This time, let's return to moderating the channel. Let's try moderating during discussion of each topic, then temporarily opening the floor for that topic before a vote so anyone can contribute. Updates to last month's topics == http://www.gentoo.org/proj/en/council/meeting-logs/20080410-summary.txt Document of being an active developer - Last month: No updates Updates: araujo made http://dev.gentoo.org/~araujo/gcert1.pdf in Scribus. He'd like to ask for approval of this design and discuss the script, in particular its infrastructure requirements. Slacker arches -- 4 months ago: vapier will work on rich0's suggestion and repost it for discussion on -dev ML 2 months ago: vapier said he was going to work on it that weekend. Last month: No updates Updates: New topics == When are ChangeLog entries required? This question mainly relates to arch stabilizations. Can the council help fewer bugs get ignored by arm/sh/s390 teams? - The work happens, but Mart says it's not communicated to anyone and has no relationship to whether bugs are open. PMS: Are versions allowed to have more than 8 digits? - http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml https://bugs.gentoo.org/show_bug.cgi?id=188449 What do various PMs/tools support? Enforced retirement --- What was the council's role in the recent enforced retirement of 3 developers? The council received numerous complaints, agreed that the devrel lead could take action and discussed the problems with her. The council did not force her to claim its actions were hers. Why does the council permit such actions in apparent violation of Gentoo's policy of openness? - http://www.gentoo.org/foundation/en/#doc_chap2 says this: Every aspect of Gentoo is and remains open. Gentoo does not benefit from hiding any of its development processes (whether it is source code or documentation, decisions or discussions, coordination or management). Chris (wolf) noted that it does specifically refer to development process. Devrel's current process document http://www.gentoo.org/proj/en/devrel/policy.xml also makes specific note of the lack of transparency, and disciplinary actions have historically been discussed in a closed environment, in part because of the potential harmful effects of the discussions if action is not taken. What is the council's role in an appeal? How should we proceed with the current appeals? If the council is directly involved in disciplinary action, Ferris requests that we amend GLEP 39 to explain how the council handles appeals
[gentoo-dev] Re: RFC: lzma tarball usage
Duncan [EMAIL PROTECTED] writes: So it would also be possible to compile lzmadec without any need for C++. Just call make in subdirs liblzmadec and lzmadec. What about USE=decode-only or something similar for lzma-utils, then? If desired, it could even be masked on normal profiles, but would then be there for the embedded and releng folks. USE=cxx should do just fine, it will disable the C++-related parts, whatever they are. Sincerely I'd quite like to enable it on my vserver's build chroots too. (BTW I considered using lzma for backup compression, but I didn't get much different results from bzip2 in term of size, but took quite longer in case of compression... I still have some doubts whether lzma is worth it). -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpRSDaMmZtfS.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 08, 2008 at 02:03:45AM -0700, Donnie Berkholz wrote: Requested attendees === PMS: ciaranm, pkgcore dev, portage dev, any other tools that care about versions Might I suggest that if PMS is going to be discussed, a copy of PMS.pdf actually be available somewhere? Preferably with the kdebuild-1 crap stripped out... Definitely would help considering the damned thing has yet to build on my system (longterm complaints re: missing fixme.sty during make). ~harring pgprV85HhjwQW.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: lzma tarball usage
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: USE=cxx should do just fine, it will disable the C++-related parts, whatever they are. Sincerely I'd quite like to enable it on my vserver's build chroots too. Should that be USE=-cxx? The help for USE=cxx says that this builds support for C++. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, 8 May 2008 03:57:16 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, May 08, 2008 at 02:03:45AM -0700, Donnie Berkholz wrote: Requested attendees === PMS: ciaranm, pkgcore dev, portage dev, any other tools that care about versions Might I suggest that if PMS is going to be discussed, a copy of PMS.pdf actually be available somewhere? Preferably with the kdebuild-1 crap stripped out... Might I suggest that you read the agenda rather than going completely off topic like last time? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 08, 2008 at 12:01:19PM +0100, Ciaran McCreesh wrote: On Thu, 8 May 2008 03:57:16 -0700 Brian Harring [EMAIL PROTECTED] wrote: On Thu, May 08, 2008 at 02:03:45AM -0700, Donnie Berkholz wrote: Requested attendees === PMS: ciaranm, pkgcore dev, portage dev, any other tools that care about versions Might I suggest that if PMS is going to be discussed, a copy of PMS.pdf actually be available somewhere? Preferably with the kdebuild-1 crap stripped out... Might I suggest that you read the agenda rather than going completely off topic like last time? If PMS is going to be discussed in some form, it's a fair request that folks have an easily readable version. Insane enough, loosening the 8 digit version restriction can have other implications- very least, verifying that bash 3.0 is when [[ ]] support was introduced since [ ] breaks down for long long from a quick look. That's off the top of the head- could be more. Actually having a pdf to read would make that a helluva lot easier too. Course, it's way more fun to just bitch at me then build a pdf so others can look at the current spec for the discussion at hand (bugs are one thing, looking at the actual spec is another). One thing I wouldn't mind the council discussing is whether or not the recent behaviour re: pms on -dev is acceptable for running a project- it's not exactly engendering cooperation. Feel free to delay that till the next month, or ignore it (y'alls court after all). ~brian pgp8vwbQ9jdqt.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, 8 May 2008 04:15:10 -0700 Brian Harring [EMAIL PROTECTED] wrote: If PMS is going to be discussed in some form, it's a fair request that folks have an easily readable version. The relevant sentence was provided. Had you bothered to read the agenda, you would know this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: lzma tarball usage
Mart Raudsepp wrote: Hello, Over the course of this year, a lzma-utils buildtime dependency has been added to a few system packages, to handle .tar.lzma tarballs. This has huge implications on the requirement of the system toolchain, which is highly disturbing from a minimal (lets say embedded) systems concern - lzma-utils depends on the C++ compiler and the libstdc++ beast, while a minimal system would like to avoid this at all cost. I'd rewrite the C++ code in plain C if isn't that complex... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: lzma tarball usage
Graham Murray [EMAIL PROTECTED] writes: Should that be USE=-cxx? The help for USE=cxx says that this builds support for C++. It was meant as setting a cxx USE on the ebuild, I wasn't certainly meaning to disable the C++ parts with USE=cxx enabled ;) -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpZoYJGuVAYM.pgp Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008, Diego 'Flameeyes' Pettenò wrote: So it would also be possible to compile lzmadec without any need for C++. Just call make in subdirs liblzmadec and lzmadec. What about USE=decode-only or something similar for lzma-utils, then? If desired, it could even be masked on normal profiles, but would then be there for the embedded and releng folks. USE=cxx should do just fine, it will disable the C++-related parts, whatever they are. Sincerely I'd quite like to enable it on my vserver's build chroots too. See https://bugs.gentoo.org/show_bug.cgi?id=220899 for a first attempt of an ebuild. Ulrich -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 8, 2008 at 1:15 PM, Brian Harring [EMAIL PROTECTED] wrote: If PMS is going to be discussed in some form, it's a fair request that folks have an easily readable version. Here you have latest pms revision built without kdebuild-1 spec: http://dev.gentoo.org/~coldwind/pms.pdf It's not that hard to extract the relevant paragraph from the tex sources, though. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 08, 2008 at 01:44:53PM +0200, Santiago M. Mola wrote: On Thu, May 8, 2008 at 1:15 PM, Brian Harring [EMAIL PROTECTED] wrote: If PMS is going to be discussed in some form, it's a fair request that folks have an easily readable version. Here you have latest pms revision built without kdebuild-1 spec: http://dev.gentoo.org/~coldwind/pms.pdf It's not that hard to extract the relevant paragraph from the tex sources, though. Already did (hence the bash 3.0 comment), that said having a live copy of the doc for ebuild devs to review, or portage tree tool developers to review isn't exactly a bad idea. It's a helluva lot simpler then digging through a mishmash of tex files also ;) Thanks meanwhile, ~harring pgp9CoJLa55oG.pgp Description: PGP signature
[gentoo-dev] Last rites: gnome-extra/shermans-aquarium
# Gilles Dartiguelongue [EMAIL PROTECTED] (08 May 2008) # Masked for removal on 8 June 2008. # Builds but as issues here and there. # Not bumpable without fixing dead libs. # See bug #216566. gnome-extra/shermans-aquarium btw, gai for example is masked for removal since January or so, guys please clean up your lastrites. -- Gilles Dartiguelongue [EMAIL PROTECTED] Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 08, 2008 at 12:23:39PM +0100, Ciaran McCreesh wrote: On Thu, 8 May 2008 04:15:10 -0700 Brian Harring [EMAIL PROTECTED] wrote: If PMS is going to be discussed in some form, it's a fair request that folks have an easily readable version. The relevant sentence was provided. Had you bothered to read the agenda, you would know this. Council: if you wouldn't mind and have time, kindly extend the discussion of PMS beyond version components (which I already clarified where the potential issue is) to the future of it, current behaviour from (frankly) the sole developer of it, how involved other package managers (say... portage, the biggest out there) are in the process. It's frankly a discussion long overdue. Cheers. ~harring pgpFCYxppuMZ5.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 8, 2008 at 2:01 PM, Brian Harring [EMAIL PROTECTED] wrote: On Thu, May 08, 2008 at 01:44:53PM +0200, Santiago M. Mola wrote: Here you have latest pms revision built without kdebuild-1 spec: http://dev.gentoo.org/~coldwind/pms.pdf Already did (hence the bash 3.0 comment), that said having a live copy of the doc for ebuild devs to review, or portage tree tool developers to review isn't exactly a bad idea. I've updated it now to: http://dev.gentoo.org/~coldwind/pms.pdf http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf Someone may want to automate it. At the moment, ping me if you want me to update them. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ryan Hill wrote: On Wed, 07 May 2008 16:23:12 +0300 Mart Raudsepp [EMAIL PROTECTED] wrote: Hello, Over the course of this year, a lzma-utils buildtime dependency has been added to a few system packages, to handle .tar.lzma tarballs. This has huge implications on the requirement of the system toolchain, which is highly disturbing from a minimal (lets say embedded) systems concern - lzma-utils depends on the C++ compiler and the libstdc++ beast, while a minimal system would like to avoid this at all cost. The new lzma-utils codebase uses liblzma, written in C. It's at the alpha stage but supposedly supports encoding/decoding the current lzma format well enough (;P). It probably has some fun bugs to find and squish. http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.orgforum_name=lzmautils-announce According to the mailing list this change was done to fix security holes in the format and also resulted in a slightly different format that's incompatible with the previous verion. So lzma 5.x and higher will be a different on disk format. It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh wrote: On Thu, 08 May 2008 09:32:34 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. You miss my point. GNU tar sometimes changes its on disk format (and will be doing so again at some point for xattrs), and it's had security issues. Fair enough. However, newer GNU tar's are able to untar the older formats. If you read the lzma changelogs, it appears to imply that newer ones won't be able to read older formats. The changelog specifically states if a user they are handling the issue gracefully by telling the user to upgrade or downgrade their lzma. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Doug Goldstein wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. Additionally to follow myself up, I believe one of the security issues was execution of arbitrary data either when untarred or just decompressed (assuming a specially crafted lzma file). Some of the other fun bits are lzma requires autotools but autotools are going to be compressed with lzma. So if we ever need to autoreconf, we have a chicken/egg issue. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008 09:32:34 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. You miss my point. GNU tar sometimes changes its on disk format (and will be doing so again at some point for xattrs), and it's had security issues. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh [EMAIL PROTECTED] writes: You miss my point. GNU tar sometimes changes its on disk format (and will be doing so again at some point for xattrs) It's not really important to the discussion, but... The TAR format is designed as such that on disk formats can be extended without breaking entirely backward compatibility. For what it's worth, extended attributes and ACLs are already supported by star (Schilling's) and bsdtar (libarchive). The fact that GNU tar doesn't support them at the moment is a different problem. On the other hand, even if the GNU tar does not support reading those attributes, it does handle them gracefully, warning the user of unknown extended headers, and then proceeding to unpack the data without preserving the extended attributes. So what Doug said stands perfectly and does not interest GNU tar at all. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpP94k0pAIHZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: lzma tarball usage
On Thursday 08 May 2008, Doug Goldstein wrote: Additionally to follow myself up, I believe one of the security issues was execution of arbitrary data either when untarred or just decompressed (assuming a specially crafted lzma file). Can you please point me to the location where this is mentioned. I read through the lzma git log, and I all I could find was data corruption (which usually is not a security issue) and the mention of the word security inside the announcement. Thanks, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: lzma tarball usage
On 08-05-2008 21:45:00 +0300, Mart Raudsepp wrote: d) too early adoption in critical system packages - once above issues are solved, higher levels should be using it first, before critical system packages (for example shows in the circular dep hell with m4) been there, done that. e) It has been suggested the support should have been added with new EAPI instead of local build deps (some of which are missing, for instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format net-tools doesn't have a dep in addition to using lzma for no good reason) Chill, relax and cool down. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On Thu, May 8, 2008 at 9:09 PM, Fabian Groffen [EMAIL PROTECTED] wrote: e) It has been suggested the support should have been added with new EAPI instead of local build deps (some of which are missing, for instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format net-tools doesn't have a dep in addition to using lzma for no good reason) Chill, relax and cool down. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. Note that we're also speaking about downstream lzma archives. Like in sys-apps/net-tools, where lzma hasn't been adopted even by upstream. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On N, 2008-05-08 at 21:09 +0200, Fabian Groffen wrote: e) It has been suggested the support should have been added with new EAPI instead of local build deps (some of which are missing, for instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format net-tools doesn't have a dep in addition to using lzma for no good reason) Chill, relax and cool down. Well, I said how it is. I don't see anything in it that indicates I am so upset and angry that I need to do these things. I did however loose hours of work time, but that's life. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. This is what I am doing with this as well, in addition to the bug reports. But as this is widespread to at least 4-6 system packages, I brought it up here as well to ensure this is not something I have to fight against in overlays and time wastes continuously in the future. Oh and net-tools has not distributed anything in .tar.lzma, so this has nothing to do with following upstream in any shape or form in this case. -- 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] Council meeting summary for 8 May 2008
Hi all, Here is the summary from today's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. Thanks, Donnie Quick summary = Active-developer document: We reviewed it and made some suggestions for improving both the document and the online developer list (adding dates). ChangeLog entries: Always required. If you aren't making them now, fix your script to call echangelog. Ignored arch-team bugs: What's the workflow for undermanned arch teams? Can we improve it? 8-digit versions: Ask package maintainers with extremely long PVs whether they were needed and test the impact of extending versionator.eclass. Make decision once this data is available. Enforced retirement: After 2.5 hours on the previous topics, people had to go to sleep and jokey's computer broke. Instead of waiting till the next regular meeting, because of its urgency, we scheduled a special session next week at the same time. The appeals will *not* be decided then -- it's about figuring out the validity and the process. New meeting process: 105 minutes were closed and 57 were open. It might save some time if we always moderated, but it won't cut it in half. Should we keep doing this, or modify it a little to have a moderated #-council and open backchannel? Roll call = (here, proxy [by whom] or slacker?) amneslacker [30 minutes late] betelgeuse here dberkholz here flameeyes here lu_zero here vapier proxy [solar] jokey here We gave amne 15 minutes to show up before getting a slacker mark. New process === The last few meetings have dragged out for hours unnecessarily. This time, we tried moderating the channel during discussion of each topic, then temporarily opening the floor for that topic before a vote so anyone could contribute. Here's the time breakdown: 2000-2030: closed, 30 min 2030-2046: open, 16 min 2046-2056: closed, 10 min 2056-2114: open, 18 min 2114-2146: closed, 32 min 2146-2209: open, 23 min 2209-2242: closed, 33 min 2242-: open floor Total before open floor: 105 minutes closed, 57 minutes open. Optimistically, we could have saved an hour if the channel was moderated throughout the meeting. That's unlikely to be the case in reality, because we'd be redirecting people's comments from queries into the channel. Should we keep it moderated until the final open floor? Should we have an open backchannel? Updates to last month's topics == http://www.gentoo.org/proj/en/council/meeting-logs/20080410-summary.txt Document of being an active developer - Last month: No updates Updates: araujo made http://dev.gentoo.org/~araujo/gcert1.pdf in Scribus. He'd like to ask for approval of this design and discuss the script, in particular its infrastructure requirements. Suggestions on certificate content: -Add title to the top: Developer Certification -Add devrel contact info (general devrel email address) -Add link to devrel userinfo page -Add start and end dates to devrel retired developers page -Add a sentence saying e.g. This certifies that XXX was a Gentoo developer from START_DATE to TODAY_DATE. The point is to avoid implying that the developer is certified forever, or will be a developer in the future. The information should be gotten from LDAP, for example using python-ldap. Could base this script on devrel's slacker script. It's unsure how signatures are going to happen, but one option is to keep a GPG-encrypted image of a signature and decrypt it on-demand for certificate creation. This should be discussed with the person doing the signing. Slacker arches -- 4 months ago: vapier will work on rich0's suggestion and repost it for discussion on -dev ML 2 months ago: vapier said he was going to work on it that weekend. Last month: No updates Updates: New topics == When are ChangeLog entries required? This question mainly relates to arch stabilizations. The consensus was that ChangeLog entries even for arch stabilizations provide valuable information that is unique without network access and more accessible than CVS logs even with network access. Some people were curious what proportion of space ChangeLogs take in
[gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ryan Hill wrote: The new lzma-utils codebase uses liblzma, written in C. It's at the alpha stage but supposedly supports encoding/decoding the current lzma format well enough (;P). It probably has some fun bugs to find and squish. http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.orgforum_name=lzmautils-announce According to the mailing list this change was done to fix security holes in the format and also resulted in a slightly different format that's incompatible with the previous verion. So lzma 5.x and higher will be a different on disk format. It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. The current format is fine. It's the new format that has design/security issues. Yes the formats are incompatible, but so are .tar.lzma and .7z, which are both lzma. Either way I was just offering it as a data point. I have no real opinion one way or the other. -- fonts, gcc-porting, by design, by neglect mips, 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
[gentoo-dev] Lenght of version components [was: Council meeting summary for 8 May 2008]
On Thu, 8 May 2008, Donnie Berkholz wrote: PMS: Are versions allowed to have more than 8 digits? - specifically to ask the package maintainers with extremely long PVs whether they were needed and to test the impact of extending versionator.eclass. The involved packages: sys-process/fuser-bsd sys-apps/net-tools sys-apps/gradm net-im/ntame media-video/captury media-libs/libcaptury media-libs/capseo sys-block/btrace www-apache/mod_depends net-wireless/rt2500 sys-fs/unionfs You may add app-emacs/limit and app-emacs/mu-cite to this list. Currently we limit ourselves to 8 digits for them, but both upstream tarballs are named in the infamous MMDDHHMM format. Ulrich -- gentoo-dev@lists.gentoo.org mailing list
