[arch-dev-public] Status Report 2007-10-22
ArchLinux Status Report, 2007-10-22 And another week goes by. Hectic for me, and I'm sure others too. Sadly, I got very little of what I hoped accomplished. So I'll be sure to revisit those items this time. Just to be clear here, because I don't think I expressed this properly: The tasks listed here are things I'd _like_ to see done. I'm 100% positive there are other things that need doing, but if you let _me_ worry about that, it will lift some weight off of all of us. What I'm saying is this: if you see some sort of larger task that we should all be a part of, let me know, and I will deal with delegation and all that fun stuff so you don't have to. And if you have some free time, check the list I have here. == Newsworthy Items == * New Announcement Mailing List In a bit of irony, this will be the first email to this new list, I believe. Please try and use this list for all official announcements, until I sit down and setup rss2email on gerolde for the front page news. == Completed Tasks == * New initscripts in testing Looks like we closed out 4 or 5 bugs with this initscripts package, so congrats guys. In addition, we've moved the initscripts code out of our package tree: http://projects.archlinux.org/git/?p=initscripts.git;a=summary * git project owners I've setup all our code projects with real owners and groups, so we can more effectively manage this stuff. So now we have real people to point fingers at, yay! You can see the list here: http://projects.archlinux.org/git/ * AUFS support patch added to kernel26 A small patch was added to our kernel to support building AUFS out-of-tree from the kernel. This means that we'll also see aufs packages in extra soon. * New release named Our next ISO release, codenamed "Hardcore", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week. == Pending Tasks, Short Term == * Core rebuild With the release of the new glibc, we want to, at the very least, rebuild all of the core repo to take advantage of the latest changes. Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002441.html Extra will be much harder to do, so we should attack the core repo first. Lets focus on that for now, and complete a rebuild of extra as the next step. * License Updates Travis has provided us a list of packages that have broken or improper licenses. This stuff is becoming more and more important, so I'd like to get some supervision here as soon as possible. This looks like it's a task that pairs well with the core rebuild and extra cleanup. So, anyone participating in those tasks should keep this list in mind. Travis, would it be possible to get this list on the dev wiki? Or possibly setup as a todo list? Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002505.html * New logo competition Travis is spearheading this competition for our new logo. Sometime this week, we should get things started, as we have all the rules down. There is, however, a question of legality raised by Simo. http://archlinux.org/pipermail/arch-dev-public/2007-October/002494.html If anyone has some insight here, it'd be helpful. We need to address this before we move forward with this competition. * The dividing line: extra and community Last time, we had this discussion, and it didn't go all that much farther. The question is this: What defines 'extra'? We seemed to talk a big game, but no decision was really reached. So, let us revisit this thread if possible: http://archlinux.org/pipermail/arch-dev-public/2007-October/002263.html Do we want to go with Damir's suggestion and make "mantle" and "crust", or would we rather stick with the current layout and make extra the "mantle" and community the "crust" ? * Package and Orphan Cleanup And again, I've dropped the ball here. We have a list of packages here: https://www.archlinux.org/wiki/Repo%20Cleanup/ If anyone has some freetime, could you help me figure out what needs to go where, perhaps with another column on that page? Could we annotate the list with what should move to community and what should move to unsupported? In addition, is there any way someone would want to export this list to the public wiki for review by the TUs? * DVD and Additional Package ISO Lists This item has been pending for some time. Discussion was heavy when this was first brought up, but now no one seems concerned about additional ISOs for packages. https://www.archlinux.org/wiki/ISO-Packages/ So, here's the ultimatum: either we at least add a few packages here, or we decide against doing this at all. Should we be distributing additional CDs/DVDs like this? * Unified chroot build tools I have some minor modifications still pending, but this should be ready to go this week. Andy's already done some testing and reported some errors. If you guys could try and go through here and test, that'd be great. Any criticism is appreciated. http://code.phraktured.net/?p=devtools.git;a=summary * Perl policy I've created a bug collector for Perl policy changes: http://bugs.archlinux.org/task/8374 It would be nice if anyone vested in perl on Arch would help out here. Patches for PKGBUILDs are always appretiated. == Pending Tasks, Long Term == * Getting rid of CVS This is a LONG time coming. We've been sitting on CVS for some time, and many of us (including myself) feel that it's time to move on. We've tried to discuss how to do this numerous times, but hit a brick wall that seems to be made of lack-of-work and I-don't-want-to-change. Thankfully, Jason stepped up to the plate and provided us with a working SVN implementation of a new PKGBUILD repo setup: http://archlinux.org/pipermail/arch-dev-public/2007-October/002308.html If anyone else has something to show for this, don't be shy, let us see it. For some reason apathy overtakes this topic whenever it's discussed, and Id love to prevent that from happening again. * Pacman 3.1 Release http://bugs.archlinux.org/task/8109 Ah, another stagnating task. Dan's been pushing some interesting patches into git, but haven't got many of these big bugs closed. Dan, could you let me know when you're free this week? We could sit down and 'sprint' a few of these bugs away. * DB Script Rewrite This item is going to become more and more important if we change repo layouts (see above). I'd like to split this task up into a few actionable portions: a) Get the DB scripts setup in a git repo like everything else b) Find an "owner" who wants to read through the code and address what would need to change if we changed SCMs. c) Try * Official pacbuild usage http://archlinux.org/pipermail/arch-dev-public/2007-October/001944.html We have an official git repo for pacbuild sitting here: http://projects.archlinux.org/git/?p=pacbuild.git;a=summary I don't think we've had any news on this front. We only have a small contingent of developers actually writing code, so this is a difficult one. I'd love to get someone in place actually working on pacbuild fulltime, as it's a very important tool for us. Do we have any python coders among us that want to show their mettle? * 'Continuous Integration' setup / machine Still an item on here. I think we're going to wait and see how we move our repo SCM in order to do this, as it'd really be just a hook to that SCM. * Modernize our Dashboard I have some documentation on doing this, I want to finalize it and possibly setup a test instance on one of my machines at home for us to play with. Eliott, Simo: I'd still like to get a sanitized git repo up for the web code, so the public can play with it as well. Is either of you available to do this sometime this week? * Architecture Independent Repos This one also seems to have gone by the wayside. What happened to the flare we had for this, or are we all waiting for someone else to do the work? http://bugs.archlinux.org/task/8153 Action Items: a) Update devtools to support arch=(all) by tagging for BOTH CURRENT and CURRENT64 b) Update DB scripts to support arch=(all) by running DB scripts for BOTH architectures. c) Test. Test. Test. * ArchCon 2009: Big Baaad Idea http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html Ah ArchCon. There was a burst of enthusiasm at first, but it died down. I wonder what country would be best? Is the rest of the world still scared to come here to the US? Or should we go to Canada?
On Mon, Oct 22, 2007 at 07:43:34PM -0500, Aaron Griffin wrote:
* ArchCon 2009: Big Baaad Idea
http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html
Ah ArchCon. There was a burst of enthusiasm at first, but it died down.
I wonder what country would be best? Is the rest of the world still scared to come here to the US? Or should we go to Canada?
Hmmm... Canada... how about Victoria? We could take over Judd and/or Jason's place for a few days 8)
On Mon, 22 Oct 2007 19:43:34 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
* License Updates
Travis has provided us a list of packages that have broken or improper licenses. This stuff is becoming more and more important, so I'd like to get some supervision here as soon as possible.
This looks like it's a task that pairs well with the core rebuild and extra cleanup. So, anyone participating in those tasks should keep this list in mind.
Travis, would it be possible to get this list on the dev wiki? Or possibly setup as a todo list?
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002505.html
Yeah, I can throw that up on the dev wiki or a todo list, I suppose. I don't know how to do TODOs though - can someone walk me through it please? I'll update the script I have that finds these bad licenses to do case-insensitive searches as well - that should knock off a few that're wrongly marked "bad". Oh, I guess I'll make it accept "MIT", "BSD", "Python", "zlib", and "libpng" as valid licenses, but ensure those packages reference /usr/share/licenses/ in their build function, since they have to install the modified version of the license. I'll get a new list made up shortly, in any case, and either wikify it or todo it, depending on which I know how to do by that point. ;)
* New logo competition
Travis is spearheading this competition for our new logo. Sometime this week, we should get things started, as we have all the rules down.
There is, however, a question of legality raised by Simo. http://archlinux.org/pipermail/arch-dev-public/2007-October/002494.html
If anyone has some insight here, it'd be helpful. We need to address this before we move forward with this competition.
Definitely needed - as I mentioned (just now) in that ML thread, I'm useless when it comes to this stuff. Help?
* ArchCon 2009: Big Baaad Idea
http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html
Ah ArchCon. There was a burst of enthusiasm at first, but it died down.
I wonder what country would be best? Is the rest of the world still scared to come here to the US? Or should we go to Canada?
+1 - I'll stick you all in my backyard, eh? -- Travis
This is just to you...
I'll update the script I have that finds these bad licenses to do case-insensitive searches as well - that should knock off a few that're wrongly marked "bad". Oh, I guess I'll make it accept "MIT", "BSD", "Python", "zlib", and "libpng" as valid licenses, but ensure those packages reference /usr/share/licenses/ in their build function, since they have to install the modified version of the license.
Do you have a copy of your script? Does it work against package files? If so, we might as well just port your updates to the licensepkg rule of namcap and we can run that on entire repositories. Jason
2007/10/23, Jason Chu <jason@archlinux.org>:
This is just to you...
I'll update the script I have that finds these bad licenses to do case-insensitive searches as well - that should knock off a few that're wrongly marked "bad". Oh, I guess I'll make it accept "MIT", "BSD", "Python", "zlib", and "libpng" as valid licenses, but ensure those packages reference /usr/share/licenses/ in their build function, since they have to install the modified version of the license.
Do you have a copy of your script? Does it work against package files? If so, we might as well just port your updates to the licensepkg rule of namcap and we can run that on entire repositories.
AFAIR Travis' script was written in bash, so it would be nice if it would go to devtools. On the other hand, namcap seems to be more appropriate place for that functionality. -- Roman Kyrylych (Роман Кирилич)
On Mon, 22 Oct 2007 22:11:38 -0700 Jason Chu <jason@archlinux.org> wrote:
This is just to you...
I'll update the script I have that finds these bad licenses to do case-insensitive searches as well - that should knock off a few that're wrongly marked "bad". Oh, I guess I'll make it accept "MIT", "BSD", "Python", "zlib", and "libpng" as valid licenses, but ensure those packages reference /usr/share/licenses/ in their build function, since they have to install the modified version of the license.
Do you have a copy of your script? Does it work against package files? If so, we might as well just port your updates to the licensepkg rule of namcap and we can run that on entire repositories.
Yay redundant questions - yes, I do have a copy of my script. :) I sent it out to the ML quite a while back - I've attached an updated version to this email though, which handles the case-insensitive issue as well as the 'bsd'-style license issue. It doesn't work on packages - only on PKGBUILDs. -- Travis
On Mon, 22 Oct 2007 23:01:05 -0400 Travis Willard <travis@archlinux.org> wrote:
On Mon, 22 Oct 2007 19:43:34 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
* License Updates
Travis has provided us a list of packages that have broken or improper licenses. This stuff is becoming more and more important, so I'd like to get some supervision here as soon as possible.
This looks like it's a task that pairs well with the core rebuild and extra cleanup. So, anyone participating in those tasks should keep this list in mind.
Travis, would it be possible to get this list on the dev wiki? Or possibly setup as a todo list?
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002505.html
Yeah, I can throw that up on the dev wiki or a todo list, I suppose. I don't know how to do TODOs though - can someone walk me through it please?
I'll update the script I have that finds these bad licenses to do case-insensitive searches as well - that should knock off a few that're wrongly marked "bad". Oh, I guess I'll make it accept "MIT", "BSD", "Python", "zlib", and "libpng" as valid licenses, but ensure those packages reference /usr/share/licenses/ in their build function, since they have to install the modified version of the license.
I'll get a new list made up shortly, in any case, and either wikify it or todo it, depending on which I know how to do by that point. ;)
https://www.archlinux.org/todo/43/ Todo list created.
On 10/24/07, Travis Willard <travis@archlinux.org> wrote:
On Mon, 22 Oct 2007 23:01:05 -0400 Travis Willard <travis@archlinux.org> wrote:
On Mon, 22 Oct 2007 19:43:34 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
* License Updates
Travis has provided us a list of packages that have broken or improper licenses. This stuff is becoming more and more important, so I'd like to get some supervision here as soon as possible.
This looks like it's a task that pairs well with the core rebuild and extra cleanup. So, anyone participating in those tasks should keep this list in mind.
Travis, would it be possible to get this list on the dev wiki? Or possibly setup as a todo list?
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002505.html
Yeah, I can throw that up on the dev wiki or a todo list, I suppose. I don't know how to do TODOs though - can someone walk me through it please?
I'll update the script I have that finds these bad licenses to do case-insensitive searches as well - that should knock off a few that're wrongly marked "bad". Oh, I guess I'll make it accept "MIT", "BSD", "Python", "zlib", and "libpng" as valid licenses, but ensure those packages reference /usr/share/licenses/ in their build function, since they have to install the modified version of the license.
I'll get a new list made up shortly, in any case, and either wikify it or todo it, depending on which I know how to do by that point. ;)
https://www.archlinux.org/todo/43/
Todo list created.
I notice libarchive in the list. Whats the call here? license=('BSD') For this to be valid, do I need to install the license? I'm assuming that is why. -Dan
On Wed, 24 Oct 2007 21:22:36 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
On 10/24/07, Travis Willard <travis@archlinux.org> wrote:
On Mon, 22 Oct 2007 23:01:05 -0400 Travis Willard <travis@archlinux.org> wrote:
On Mon, 22 Oct 2007 19:43:34 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
* License Updates
Travis has provided us a list of packages that have broken or improper licenses. This stuff is becoming more and more important, so I'd like to get some supervision here as soon as possible.
This looks like it's a task that pairs well with the core rebuild and extra cleanup. So, anyone participating in those tasks should keep this list in mind.
Travis, would it be possible to get this list on the dev wiki? Or possibly setup as a todo list?
Ref: http://archlinux.org/pipermail/arch-dev-public/2007-October/002505.html
Yeah, I can throw that up on the dev wiki or a todo list, I suppose. I don't know how to do TODOs though - can someone walk me through it please?
I'll update the script I have that finds these bad licenses to do case-insensitive searches as well - that should knock off a few that're wrongly marked "bad". Oh, I guess I'll make it accept "MIT", "BSD", "Python", "zlib", and "libpng" as valid licenses, but ensure those packages reference /usr/share/licenses/ in their build function, since they have to install the modified version of the license.
I'll get a new list made up shortly, in any case, and either wikify it or todo it, depending on which I know how to do by that point. ;)
https://www.archlinux.org/todo/43/
Todo list created.
I notice libarchive in the list. Whats the call here? license=('BSD')
For this to be valid, do I need to install the license? I'm assuming that is why.
Yeah, the description of the todo got kind of mangled in formatting - it should read: Licenses in our official packages need some serious cleanup. The following are a list of packages in [extra] with incorrect licenses. Reasons a package might end up on this list: . No, or empty, license= field. . License= field containing a license not in /usr/share/licenses/common . License= field containing "custom", "mit", "apache", "bsd", "python", "zlib", or "libpng" which doesn't reference /usr/share/licenses/ anywhere in build() Basically, since the BSD, MIT, APACHE, PYTHON, ZLIB, and LIBPNG licenses require the text be modified for each individual app, but they're still 'common' licenses, we want to be able to say license=("BSD") but we still need to install the slightly-modified license into /usr/share/licenses. -- Travis
* New release named
Our next ISO release, codenamed "Hardcore", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week.
> NEW RELEASE NAME: > - Hardcore (Roman, Dale, Varun > - All you can Wuerstchen (Alex > - Pizza (Thomas > - Slice (Damir > - Proton > - Magma > - Core Dump(Aaron, Tpowa, Pierre, Dan, Daniel, Juergen, Eric
hrm the voting showed Core Dump and not Hardcore greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 10/23/07, Tobias Powalowski <t.powa@gmx.de> wrote:
* New release named
Our next ISO release, codenamed "Hardcore", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week.
>> NEW RELEASE NAME: >> - Hardcore (Roman, Dale, Varun >> - All you can Wuerstchen (Alex >> - Pizza (Thomas >> - Slice (Damir >> - Proton >> - Magma >> - Core Dump(Aaron, Tpowa, Pierre, Dan, Daniel, Juergen, Eric
hrm the voting showed Core Dump and not Hardcore
Oh crap, I typed the wrong one!
2007/10/23, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/23/07, Tobias Powalowski <t.powa@gmx.de> wrote:
* New release named
Our next ISO release, codenamed "Hardcore", is almost ready to go, and will be released at the beginning of next month. Be prepared for a good old round of testing starting this week.
Haha, my proposal almost won. :-P
>>> NEW RELEASE NAME: >>> - Hardcore (Roman, Dale, Varun >>> - All you can Wuerstchen (Alex >>> - Pizza (Thomas >>> - Slice (Damir >>> - Proton >>> - Magma >>> - Core Dump(Aaron, Tpowa, Pierre, Dan, Daniel, Juergen, Eric
hrm the voting showed Core Dump and not Hardcore
Oh crap, I typed the wrong one!
Sigmund Freud would be happy. ;-) -- Roman Kyrylych (Роман Кирилич)
Tuesday 23 October 2007, Aaron Griffin wrote: | We have a list of packages here: | https://www.archlinux.org/wiki/Repo%20Cleanup/ | | If anyone has some freetime, could you help me figure out what | needs to go where, perhaps with another column on that page? | | Could we annotate the list with what should move to community and | what should move to unsupported? | | In addition, is there any way someone would want to export this | list to the public wiki for review by the TUs? i've just addopted all aspell-dix in extra. if i find some free minutes, i will browse the list. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
* AUFS support patch added to kernel26
A small patch was added to our kernel to support building AUFS out-of-tree from the kernel.
This means that we'll also see aufs packages in extra soon.
I have just placed the aufs and aufs-utils packages in [extra]. - P
On Mon, 2007-10-22 at 19:43 -0500, Aaron Griffin wrote:
ArchLinux Status Report, 2007-10-22
And another week goes by. Hectic for me, and I'm sure others too. Sadly, I got very little of what I hoped accomplished.
So I'll be sure to revisit those items this time.
...blah...blah...
* Perl policy
I've created a bug collector for Perl policy changes: http://bugs.archlinux.org/task/8374
It would be nice if anyone vested in perl on Arch would help out here. Patches for PKGBUILDs are always appretiated.
FYI, I've started look at this. I'm currently changing the perl package to use "core" directories. I'm not too sure about the massive provides array tho... k -- K. Piche <kpiche@rogers.com>
participants (10)
-
Aaron Griffin
-
Damir Perisa
-
Dan McGee
-
Jason Chu
-
K. Piche
-
Paul Mattal
-
Roman Kyrylych
-
Simo Leone
-
Tobias Powalowski
-
Travis Willard