[arch-dev-public] Repository cleanup [current] and [base] --> [core], this weekend!
Hi it's quite a long time ago we had a dev meeting, but i think there were quite some agreement what [core] should be and we should start doing this soon. Our next ISOs shouldn't have the big current anymore only ftp and [core]. [non-free] repository we should add a non-free repository with stuff that is not freely distributable, like acroread, sun java, firmware files, flash etc. this cleanup would affect [extra] and [current] that way we could finally have cds of [extra] too without getting into trouble. As Romashka said, these are the types we need to look at: 1) those that are not possible to distribute due to prohibition of original package modification, but it does not work without modifications to installation procedure - like vmware 2) those that are not allowed to be redistributed by EULA - like commercial edition of virtualbox 3) those that are not allowed to be sold on a CD, but can be distributed over internet 4) those that are just not Free Software - it's nice to have them splitted if someone wants to have FOSS-only mirror/CD/etc 1+2 should be probably moved out of the official repositories, if not already done. 3+4 should be ok [core] repository should be like [base] + some extra stuff the question is: what is extra stuff? imho, it should be everything that is needed for networking free kernel network modules free wlan stuff all supported main filesystems suggestion list of packages to add: ndiswrapper ndiswrapper-utils wlan-ng26 rt2500 madwifi madwifi-utils fuse ntfs-3g iptables bcm43xx-fwcutter dosfsutils ntfsprogs kexec-tools snarf dnsutils hdparm bridge-utils ifenslave xinetd portmap nfsidmap nfs-utils openssh netkit-telnet screen isdn4k-utils capi4k-utils vpnc openvpn everything else from [current] should be moved to [extra]. your opinions, lets get something done this weekend. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Tobias Powalowski wrote:
Hi it's quite a long time ago we had a dev meeting, but i think there were quite some agreement what [core] should be and we should start doing this soon. Our next ISOs shouldn't have the big current anymore only ftp and [core].
[non-free] repository we should add a non-free repository with stuff that is not freely distributable, like acroread, sun java, firmware files, flash etc. this cleanup would affect [extra] and [current] that way we could finally have cds of [extra] too without getting into trouble.
As I recall (because I originally supported this and then conceded that the other was a better plan), we decided NOT to separate the repos based on license/free/non-free but rather to have some way in pacman to say "only install items with such and such licenses"-- so not to organize our packages by license but rather to let the license features built into pacman to allow us to choose software with the licenses we want. Aside from that, rest of the stuff sounds good based on what people said. I personally still like having a [current] with "one of each" that is small and portable, but I think I'm outvoted. - P
2007/9/12, Paul Mattal <paul@mattal.com>:
Tobias Powalowski wrote:
Hi it's quite a long time ago we had a dev meeting, but i think there were quite some agreement what [core] should be and we should start doing this soon. Our next ISOs shouldn't have the big current anymore only ftp and [core].
[non-free] repository we should add a non-free repository with stuff that is not freely distributable, like acroread, sun java, firmware files, flash etc. this cleanup would affect [extra] and [current] that way we could finally have cds of [extra] too without getting into trouble.
As I recall (because I originally supported this and then conceded that the other was a better plan), we decided NOT to separate the repos based on license/free/non-free but rather to have some way in pacman to say "only install items with such and such licenses"-- so not to organize our packages by license but rather to let the license features built into pacman to allow us to choose software with the licenses we want.
Licenses support in pacman is good and all that (I do like this idea), but it does not help in case when some magazine want to create CD/DVD with Arch repos snapshot and sell it with magazine. Instead of crawling through all packages they should just omit [non-free] repo, where all packages that are not allowed to sell on CD will be placed.
Aside from that, rest of the stuff sounds good based on what people said. I personally still like having a [current] with "one of each" that is small and portable, but I think I'm outvoted.
-- Roman Kyrylych (Роман Кирилич)
Wednesday 12 September 2007, Roman Kyrylych wrote: | Licenses support in pacman is good and all that (I do like this | idea), but it does not help in case when some magazine want to | create CD/DVD with Arch repos snapshot and sell it with magazine. | Instead of crawling through all packages they should just omit | [non-free] repo, where all packages that are not allowed to sell | on CD will be placed. [current] and [base] --> [core] do we have anything non-free in [current] or [base]? i cannot find anyhting. if the whole contents of [extra] are going to be on a DVD, things are different... one has then to make sure, when this ISO image is made, that the non-free things do not get included... just have a blacklist of licences or a whitelist of licences for building the iso. - D
I have intended to go back and join all the discussions about the "non-free" repo but I have not had time so I will have to dive in here. In my opinion it is totally unnecessary. I agree that support for id-ing non-free pkgs should be fully implemented in pacman, indeed this is what I had thought the license field was for. As for the case of magazines and dumps of the repo - it's a scriptable solution. This can either be done locally by the downloader or server-side by us. How hard would it be to have pacman churn out all the URLs for free pkgs in [extra]? Not hard at all I think. This can then be used with wget. pacman support also has much broader benefits. That's a much more Arch-like solution than a separate repo. I'm also of the opinion certain people want a non-free repo because it will tidy up some "loose ends" with regards to the non-i686 arch projects. I'd hate to see time and emphasis diverted from pacman development to achieve something this spurious. As for our own DVD of [extra]...keep up, guys. It's 2007. DVD is virtually a synonym for "movie on disc" and even they are now being phased out in favour of downloads. The market is moving away from solid state format, not towards it. Arch is about 4-5 years too late for a package snapshot on hard media. Now, I am aware that there is an argument that there are some people in some parts of the world that don't have reliable internet access and so can't access the repos. I have the following questions on this case: * Can someone demonstrate 10 cases of this here and now? * Should these people be using a rolling release distro? * Why can't they make one DVD for multiple uses themselves? * What is the benefit to Arch of producing a DVD? * Why can't creation of the DVD be scripted using pacman features (as outlined above)? * If a lack of a DVD is restricting our audience then when did we care about that? I know my opinion is hardly a deal breaker but I just don't get the point of this whole non-free thing. Phil
On Wed, Sep 12, 2007 at 05:06:04PM +0100, Phil Dillon-Thiselton wrote:
I have intended to go back and join all the discussions about the "non-free" repo but I have not had time so I will have to dive in here.
In my opinion it is totally unnecessary. I agree that support for id-ing non-free pkgs should be fully implemented in pacman, indeed this is what I had thought the license field was for.
As for the case of magazines and dumps of the repo - it's a scriptable solution. This can either be done locally by the downloader or server-side by us. How hard would it be to have pacman churn out all the URLs for free pkgs in [extra]? Not hard at all I think. This can then be used with wget. pacman support also has much broader benefits.
That's a much more Arch-like solution than a separate repo. I'm also of the opinion certain people want a non-free repo because it will tidy up some "loose ends" with regards to the non-i686 arch projects. I'd hate to see time and emphasis diverted from pacman development to achieve something this spurious.
As for our own DVD of [extra]...keep up, guys. It's 2007. DVD is virtually a synonym for "movie on disc" and even they are now being phased out in favour of downloads. The market is moving away from solid state format, not towards it. Arch is about 4-5 years too late for a package snapshot on hard media.
Now, I am aware that there is an argument that there are some people in some parts of the world that don't have reliable internet access and so can't access the repos. I have the following questions on this case:
* Can someone demonstrate 10 cases of this here and now? * Should these people be using a rolling release distro? * Why can't they make one DVD for multiple uses themselves? * What is the benefit to Arch of producing a DVD? * Why can't creation of the DVD be scripted using pacman features (as outlined above)? * If a lack of a DVD is restricting our audience then when did we care about that?
I know my opinion is hardly a deal breaker but I just don't get the point of this whole non-free thing.
+20, seriously. When are we going to stop finding ways to cater to every oddball use case and get back to the basics? * If a magazine wants to distribute us on DVD, while we're more than willing to help them achieve that by generating custom images for them (or ideally they can do it themselves), etc, there is NO, I REPEAT ABSOLUTELY NO REASON, we need to restructure our repos to accomodate that. * If someone doesn't have a whole lot of bandwidth, maybe they shouldn't be using Arch. Oh I know I'm a jerk now. Seriously, arch just... you know... isn't....for some people. And that's perfectly OK. Just like debian isn't for us, and that's ok. You don't see them scrambling to fix all the little things that keep us from using it do you? What I'm trying to get across here is that some parts of this dev team have adopted a reactive development model. By this I mean that the majority of your devel is driven by whatever issues come up, as they come up. Do you realize why that's bad? Typically projects will go through some solid research and plannning to avoid this situation. I've heard that when the developer has a solid understanding of the problem, they often develop more generic tools that have more unforseen uses in the future than when they develop reactively. This is why, for instance, pacman is so versatile in that it alone can be used to solve all these problems (like phil said). Gee, what a great tool. Sorry for the slight OT, it's kind of related. -S
2007/9/12, Phil Dillon-Thiselton <dibblethewrecker@gmail.com>:
As for our own DVD of [extra]...keep up, guys. It's 2007. DVD is virtually a synonym for "movie on disc" and even they are now being phased out in favour of downloads. The market is moving away from solid state format, not towards it. Arch is about 4-5 years too late for a package snapshot on hard media.
Now, I am aware that there is an argument that there are some people in some parts of the world that don't have reliable internet access and so can't access the repos. I have the following questions on this case:
* Can someone demonstrate 10 cases of this here and now?
Easily.
* Should these people be using a rolling release distro?
They could. And they're happy with Arch. There are a lot of people here that would like to [try to] use Arch, but it's not easy for them to _start_ doing this. Because to get a useable system it requires a lot of downloads. A CD not enought because it contains only basic system. I personally sent 3 sets of DVDs with all binary repos for such users. Those users successfully installed Arch and use it now. They get updates from Internet at home or at job, though it requires much time to download them. But wouldn't be possible for them to get full-ffeatured working environment without those hundreds of megabytes that I supplied to them on DVDs.
* Why can't they make one DVD for multiple uses themselves?
They don't need a DVD, they need packages! And packages can be easily shipped on DVD when there's bad internet connection.
* What is the benefit to Arch of producing a DVD?
Money? ;-) From http://www.archlinux.org/download/: "CDs are available for purchase from OSDisc.com. For each CD purchased, a portion of the money goes to the Arch Linux Project." If I would have the choice to buy a CD and then download hundreds of megabytes to get feature-rich working evironment or just buy a DVD with everything included - I'd definetely choose a DVD. ;-) Besides, it's easier to anyone to just burn ISO or duplicate disc without even knowledge what pacman () is and how to script the process of license filtering.
* Why can't creation of the DVD be scripted using pacman features (as outlined above)?
This requires pacman to be installed on a system when DVD will be prepared, which may not be the case (e.g. DVD-maker is using another distro). User can just burn/copy disc from Windows! Besides, AFAIK pacman does not include license filtering features yet.
* If a lack of a DVD is restricting our audience then when did we care about that?
I know my opinion is hardly a deal breaker but I just don't get the point of this whole non-free thing.
Now, could we please back on topic? -- Roman Kyrylych (Роман Кирилич)
Paul Mattal schrieb:
As I recall (because I originally supported this and then conceded that the other was a better plan), we decided NOT to separate the repos based on license/free/non-free but rather to have some way in pacman to say "only install items with such and such licenses"-- so not to organize our packages by license but rather to let the license features built into pacman to allow us to choose software with the licenses we want.
Some time ago, I proposed on the pacman list that there should be more license support in pacman - and was turned down (I think it was about displaying licenses with a pacman option). But what we need for pacman is a list of licenses that the user already accepted and it needs to explicitly ask the user to accept another license once he installs a package with a custom license. I don't think anyone in the pacman area is working on that right now. This concerns the "support" category of our new core repository: Intel agreed that we put their firmware files on the installer (which is very useful imo), but said the user should accept the license first. Also pacman has no support for "filtering" non-free packages, so we can't use a script to not put them on a DVD.
I'm all for added some more packages to base/ and use that as core. The list Tobias made, sounds good to me for as long as we don't need to distribute firmware for certain chip sets where vendors do not allow it. Then again, it should be simple to regenerate the ISO to include those by the user. Which is already implemented by the hook system in archboot, no? What I don't want to have is a out of 2 make 3 or even more repositories. I personally don't have a problem with Sun's JRE or anything if OpenOffice - which is free - works best with it. Same for nvidia drivers and stuff. Java is a special case here because stuff may depend on it. +1 for adding drivers to base/core & push the rest to extra. Cheers, -O
On Wed, Sep 12, 2007 at 04:31:26PM +0200, Tobias Powalowski wrote:
Hi it's quite a long time ago we had a dev meeting, but i think there were quite some agreement what [core] should be and we should start doing this soon. Our next ISOs shouldn't have the big current anymore only ftp and [core].
[non-free] repository we should add a non-free repository with stuff that is not freely distributable, like acroread, sun java, firmware files, flash etc. this cleanup would affect [extra] and [current] that way we could finally have cds of [extra] too without getting into trouble.
As Romashka said, these are the types we need to look at: 1) those that are not possible to distribute due to prohibition of original package modification, but it does not work without modifications to installation procedure - like vmware 2) those that are not allowed to be redistributed by EULA - like commercial edition of virtualbox 3) those that are not allowed to be sold on a CD, but can be distributed over internet 4) those that are just not Free Software - it's nice to have them splitted if someone wants to have FOSS-only mirror/CD/etc
1+2 should be probably moved out of the official repositories, if not already done. 3+4 should be ok
-1 I think that we never solved the dependency graph problem with non-free and I strongly suggest we don't do it. This can be revisited later.
[core] repository should be like [base] + some extra stuff the question is: what is extra stuff? imho, it should be everything that is needed for networking free kernel network modules free wlan stuff all supported main filesystems
suggestion list of packages to add: ndiswrapper ndiswrapper-utils wlan-ng26 rt2500 madwifi madwifi-utils fuse ntfs-3g iptables bcm43xx-fwcutter dosfsutils ntfsprogs kexec-tools snarf dnsutils hdparm bridge-utils ifenslave xinetd portmap nfsidmap nfs-utils openssh netkit-telnet screen isdn4k-utils capi4k-utils vpnc openvpn
+1 I haven't really looked over this list, but I'm going to assume that other people will. I do like the criteria though. What are all the steps we'll have to take and what problems will those cause? - Create a new CVS repo for core (or do we just use the current "arch" one?). - Copy PKGBUILDs from one CVS repo to another (thus losing history). - Retag the CURRENT and CURRENT64 versions (which aren't necessarily the most recently commited versions). - Update the web db to reflect the new core repo and remove the old current repo and point to the proper cvs.archlinux.org urls. - Delete packages from one repo and add them to the other (~/staging/arch/del and ~/staging/extra/add). - Update and test db scripts to create db-core (and db-core64) and remove db-arch (and db-arch64). - Release a new version of pacman with the new repo paths. - Tell all users to update their pacman.confs to point to core, not current. - Update the rsync.conf to sync the core directory and not sync the current directory. - Update viewcvs with the new CVS repo and remove the old one (but there's still non-packages in there...). Is there anything I missed? When I look at this list there sure seems like a lot that needs doing... Can we maybe break it down into stages where things are still backwards compatible? As much as Aaron is going to hate me for it, I really don't want to do anything this weekend if we don't have a complete list of the things that need to be done (preferably in what order) to make this transition smooth. I want to cause as little problems for current users as we can during this transition. Jason
On 9/12/07, Jason Chu <jason@archlinux.org> wrote:
- Create a new CVS repo for core (or do we just use the current "arch" one?).
Um, or we could be sensible about this, create a real SCM repo (git, hg, etc) and use tailor to import, history and all.
On Wed, Sep 12, 2007 at 12:29:05PM -0500, Aaron Griffin wrote:
On 9/12/07, Jason Chu <jason@archlinux.org> wrote:
- Create a new CVS repo for core (or do we just use the current "arch" one?).
Um, or we could be sensible about this, create a real SCM repo (git, hg, etc) and use tailor to import, history and all.
This is a long discussion that I don't think we want to have right now. Needless to say, most SCMs that we'd move to wouldn't necessarily like the way we currently abuse CVS to tag our packages. Can we find a solution that uses CVS first? Jason
2007/9/12, Jason Chu <jason@archlinux.org>:
What are all the steps we'll have to take and what problems will those cause?
- Create a new CVS repo for core (or do we just use the current "arch" one?).
- Copy PKGBUILDs from one CVS repo to another (thus losing history).
- Retag the CURRENT and CURRENT64 versions (which aren't necessarily the most recently commited versions).
- Update the web db to reflect the new core repo and remove the old current repo and point to the proper cvs.archlinux.org urls.
- Delete packages from one repo and add them to the other (~/staging/arch/del and ~/staging/extra/add).
- Update and test db scripts to create db-core (and db-core64) and remove db-arch (and db-arch64).
- Release a new version of pacman with the new repo paths.
- Tell all users to update their pacman.confs to point to core, not current.
- Update the rsync.conf to sync the core directory and not sync the current directory.
- Update viewcvs with the new CVS repo and remove the old one (but there's still non-packages in there...).
Is there anything I missed?
When I look at this list there sure seems like a lot that needs doing... Can we maybe break it down into stages where things are still backwards compatible?
We can modify scripts that create core.db.tar.gz to also create current.tar.gz and on ftp we can make current symlink to core. This should provide (temporary) backward compatability without modification of pacman.conf and new pacman package release.
As much as Aaron is going to hate me for it, I really don't want to do anything this weekend if we don't have a complete list of the things that need to be done (preferably in what order) to make this transition smooth. I want to cause as little problems for current users as we can during this transition.
-- Roman Kyrylych (Роман Кирилич)
Hi as first step for the weekend it would be enough, to just cleanup current to the state core should be, means move everything to extra which isn't in core and move everything from extra to current which should be in core. then we can decide on what and how to do later, during the weekend. It would be probably a good idea to stop the rsync tasks in this time and post a news entry about this. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Mittwoch, 12. September 2007 22:42:05 schrieb Tobias Powalowski:
Hi as first step for the weekend it would be enough, to just cleanup current to the state core should be, means move everything to extra which isn't in core and move everything from extra to current which should be in core. then we can decide on what and how to do later, during the weekend. It would be probably a good idea to stop the rsync tasks in this time and post a news entry about this. greetings tpowa
Yes, let`s do it step by step and stop the endless discussion about non-free etc.. We should transform current to core and create a new repo later. -- archlinux.de
On Wed, Sep 12, 2007 at 10:42:05PM +0200, Tobias Powalowski wrote:
Hi as first step for the weekend it would be enough, to just cleanup current to the state core should be, means move everything to extra which isn't in core and move everything from extra to current which should be in core. then we can decide on what and how to do later, during the weekend. It would be probably a good idea to stop the rsync tasks in this time and post a news entry about this. greetings tpowa
Ok, if the first step is moving all the non-core package to extra and all the core packages to current, we can do that this weekend. After that is completed, we'll talk about the rest of it. I know there were lots of packages that have been commited and not tagged, so I suggest we figure out how to move over the 3 versions (CURRENT, CURRENT64, and HEAD) of the PKGBUILD and files before doing it en mass. Also, who will be doing it? Jason
On Wed, 12 Sep 2007 13:53:56 -0700 Jason Chu <jason@archlinux.org> wrote:
Also, who will be doing it?
Andy and I have time over the weekend. So, you can count on us... Daniel
Am Mittwoch 12 September 2007 schrieb Daniel Isenmann:
On Wed, 12 Sep 2007 13:53:56 -0700
Jason Chu <jason@archlinux.org> wrote:
Also, who will be doing it?
Andy and I have time over the weekend. So, you can count on us...
Daniel
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
Im pretty sure Jan(is a little bit busy) and me will be there too -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 9/12/07, Tobias Powalowski <t.powa@gmx.de> wrote:
Im pretty sure Jan(is a little bit busy) and me will be there too
I don't have plans this weekend, but of course, I'm on a different schedule than the germans. I'm sure I can do some of the work, just let me know what time you plan on starting, and I can figure out what works best for me. I think tpowa is on the right track here - even if we don't get everything, we don't cover 100% of the packages, we can get MOST of it. We may forget one or two - big deal, we can add them later. Thanks for picking this up again, this is one of the (many) important infrastructure things that have gone by the wayside.
On Wed, Sep 12, 2007 at 04:42:51PM -0500, Aaron Griffin wrote:
On 9/12/07, Tobias Powalowski <t.powa@gmx.de> wrote:
Im pretty sure Jan(is a little bit busy) and me will be there too
I don't have plans this weekend, but of course, I'm on a different schedule than the germans.
Ze Germans!
I'm sure I can do some of the work, just let me know what time you plan on starting, and I can figure out what works best for me.
I think tpowa is on the right track here - even if we don't get everything, we don't cover 100% of the packages, we can get MOST of it. We may forget one or two - big deal, we can add them later.
Thanks for picking this up again, this is one of the (many) important infrastructure things that have gone by the wayside.
I'm still worried about the three different versions of the packages. Can someone give me some numbers about untagged changes or differences between arch64 and arch32? Jason
Am Mittwoch 12 September 2007 schrieb Jason Chu:
On Wed, Sep 12, 2007 at 04:42:51PM -0500, Aaron Griffin wrote:
On 9/12/07, Tobias Powalowski <t.powa@gmx.de> wrote:
Im pretty sure Jan(is a little bit busy) and me will be there too
I don't have plans this weekend, but of course, I'm on a different schedule than the germans.
Ze Germans!
I'm sure I can do some of the work, just let me know what time you plan on starting, and I can figure out what works best for me.
I think tpowa is on the right track here - even if we don't get everything, we don't cover 100% of the packages, we can get MOST of it. We may forget one or two - big deal, we can add them later.
Thanks for picking this up again, this is one of the (many) important infrastructure things that have gone by the wayside.
I'm still worried about the three different versions of the packages. Can someone give me some numbers about untagged changes or differences between arch64 and arch32?
Jason
http://archlinux.org/~andyrtr/pkg_diff.html i would say the red ones could be troublemakers the rest should be fine -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Thu, Sep 13, 2007 at 12:01:01AM +0200, Tobias Powalowski wrote:
Am Mittwoch 12 September 2007 schrieb Jason Chu:
On Wed, Sep 12, 2007 at 04:42:51PM -0500, Aaron Griffin wrote:
On 9/12/07, Tobias Powalowski <t.powa@gmx.de> wrote:
Im pretty sure Jan(is a little bit busy) and me will be there too
I don't have plans this weekend, but of course, I'm on a different schedule than the germans.
Ze Germans!
I'm sure I can do some of the work, just let me know what time you plan on starting, and I can figure out what works best for me.
I think tpowa is on the right track here - even if we don't get everything, we don't cover 100% of the packages, we can get MOST of it. We may forget one or two - big deal, we can add them later.
Thanks for picking this up again, this is one of the (many) important infrastructure things that have gone by the wayside.
I'm still worried about the three different versions of the packages. Can someone give me some numbers about untagged changes or differences between arch64 and arch32?
Jason
http://archlinux.org/~andyrtr/pkg_diff.html i would say the red ones could be troublemakers the rest should be fine
What about things like commited changes that haven't been tagged yet? Updated install files, license field changes... We have to make sure that the untagged changes stay untagged. Jason
On 9/12/07, Jason Chu <jason@archlinux.org> wrote:
We have to make sure that the untagged changes stay untagged.
Why's that? I'm not playing devil's advocate, I just actually don't see why. If something breaks or doesn't compile, we fix it. That's why we carved out a whole weekend for this, right?
On Wed, Sep 12, 2007 at 05:50:06PM -0500, Aaron Griffin wrote:
On 9/12/07, Jason Chu <jason@archlinux.org> wrote:
We have to make sure that the untagged changes stay untagged.
Why's that? I'm not playing devil's advocate, I just actually don't see why. If something breaks or doesn't compile, we fix it. That's why we carved out a whole weekend for this, right?
These sorts of problems aren't the kinda that show up right away. They usually show up weeks later when someone says, "pacman's acting really weird. -Si is telling me different things than the web site...". I'd rather err on the side of caution than on the side of we'll-fix-it-when-it-breaks. The less disruption we cause our users, the better. Also, if we're doing it this weekend, maybe we should warn everyone now? Jason
On 9/12/07, Jason Chu <jason@archlinux.org> wrote:
These sorts of problems aren't the kinda that show up right away. They usually show up weeks later when someone says, "pacman's acting really weird. -Si is telling me different things than the web site...".
I'd rather err on the side of caution than on the side of we'll-fix-it-when-it-breaks. The less disruption we cause our users, the better.
Caution is all fine and good, but if it's "lets put lots of effort into this so the mysql db is in sync" that seems kinda... I dunno, "too much" - I mean, display problems can be fixed later. If it's just a "why is this saying version 1 when we're on version 2" then it's not even relevant to this, if you ask me. To hold up a restructuring as important of this because of the numbers listed on a web site is wrong. Then again, this is just my opinion.
Also, if we're doing it this weekend, maybe we should warn everyone now?
Probably a good idea.
Also, if we're doing it this weekend, maybe we should warn everyone now?
Sorry I can't help guys - I'll be getting married this weekend and then gone for two weeks. Eliott, do you want to try an -Syu on gerolde before I leave (i.e. today or tomorrow)? Hope everything goes well with the cleanup, Dale
2007/9/13, Dale Blount <dale@archlinux.org>:
Also, if we're doing it this weekend, maybe we should warn everyone now?
Sorry I can't help guys - I'll be getting married this weekend and then gone for two weeks.
Congratulations! And have a goood vacation! :-D -- Roman Kyrylych (Роман Кирилич)
On 9/13/07, Dale Blount <dale@archlinux.org> wrote:
Also, if we're doing it this weekend, maybe we should warn everyone now?
Sorry I can't help guys - I'll be getting married this weekend and then gone for two weeks.
Congratulations man. :) Welcome to the club. heh heh
Eliott, do you want to try an -Syu on gerolde before I leave (i.e. today or tomorrow)?
I am fine with either day. Just let me know when you want to do it.
On 9/13/07, eliott <eliott@cactuswax.net> wrote:
On 9/13/07, Dale Blount <dale@archlinux.org> wrote:
Also, if we're doing it this weekend, maybe we should warn everyone now?
Sorry I can't help guys - I'll be getting married this weekend and then gone for two weeks.
Congratulations man. :) Welcome to the club. heh heh
Congo rats! This means my side is losing another one, damnit. /me shakes his fist at women in general
Eliott, do you want to try an -Syu on gerolde before I leave (i.e. today or tomorrow)?
I am fine with either day. Just let me know when you want to do it.
I can help out with arbitrary damage control/leg work if need be, but you guys seem to be much more versed in this stuff than I.
On 9/13/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 9/13/07, eliott <eliott@cactuswax.net> wrote:
On 9/13/07, Dale Blount <dale@archlinux.org> wrote:
Also, if we're doing it this weekend, maybe we should warn everyone now?
Sorry I can't help guys - I'll be getting married this weekend and then gone for two weeks.
Congratulations man. :) Welcome to the club. heh heh
Congo rats!
This means my side is losing another one, damnit.
/me shakes his fist at women in general
Eliott, do you want to try an -Syu on gerolde before I leave (i.e. today or tomorrow)?
I am fine with either day. Just let me know when you want to do it.
I can help out with arbitrary damage control/leg work if need be, but you guys seem to be much more versed in this stuff than I.
Dale has limited time to do this before his pending nuptuals, so I think we will need to punt on this until he returns. If something goes terribly south in the meantime, then we (I) can deal with it then.
On 13/09/2007, Dale Blount <dale@archlinux.org> wrote:
Also, if we're doing it this weekend, maybe we should warn everyone now?
Sorry I can't help guys - I'll be getting married this weekend and then gone for two weeks.
Congratulations!
2007/9/13, Tobias Powalowski <t.powa@gmx.de>:
Am Mittwoch 12 September 2007 schrieb Jason Chu:
On Wed, Sep 12, 2007 at 04:42:51PM -0500, Aaron Griffin wrote:
On 9/12/07, Tobias Powalowski <t.powa@gmx.de> wrote:
Im pretty sure Jan(is a little bit busy) and me will be there too
I don't have plans this weekend, but of course, I'm on a different schedule than the germans.
Ze Germans!
I'm sure I can do some of the work, just let me know what time you plan on starting, and I can figure out what works best for me.
I think tpowa is on the right track here - even if we don't get everything, we don't cover 100% of the packages, we can get MOST of it. We may forget one or two - big deal, we can add them later.
Thanks for picking this up again, this is one of the (many) important infrastructure things that have gone by the wayside.
I'm still worried about the three different versions of the packages. Can someone give me some numbers about untagged changes or differences between arch64 and arch32?
Jason
http://archlinux.org/~andyrtr/pkg_diff.html i would say the red ones could be troublemakers the rest should be fine
There should be some untagged packages with done bugfixes in them. In any case we shouldn't lose those untagged changes, as it will be a PITA to find and fix them later again. Doesn't CVS has some possibility to move untagged changes? -- Roman Kyrylych (Роман Кирилич)
On Thu, 13 Sep 2007 10:14:46 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
2007/9/13, Tobias Powalowski <t.powa@gmx.de>:
Am Mittwoch 12 September 2007 schrieb Jason Chu:
On Wed, Sep 12, 2007 at 04:42:51PM -0500, Aaron Griffin wrote:
On 9/12/07, Tobias Powalowski <t.powa@gmx.de> wrote:
Im pretty sure Jan(is a little bit busy) and me will be there too
I don't have plans this weekend, but of course, I'm on a different schedule than the germans.
Ze Germans!
I'm sure I can do some of the work, just let me know what time you plan on starting, and I can figure out what works best for me.
I think tpowa is on the right track here - even if we don't get everything, we don't cover 100% of the packages, we can get MOST of it. We may forget one or two - big deal, we can add them later.
Thanks for picking this up again, this is one of the (many) important infrastructure things that have gone by the wayside.
I'm still worried about the three different versions of the packages. Can someone give me some numbers about untagged changes or differences between arch64 and arch32?
Jason
http://archlinux.org/~andyrtr/pkg_diff.html i would say the red ones could be troublemakers the rest should be fine
There should be some untagged packages with done bugfixes in them. In any case we shouldn't lose those untagged changes, as it will be a PITA to find and fix them later again. Doesn't CVS has some possibility to move untagged changes?
If one of the packages we're moving has untagged changes, then why don't we use this move to tag the newest version, build, and upload it? Problem solved? Is anything we're moving in TESTING currently? 'Cause there's another tag we have to deal with. -- Travis
2007/9/13, Travis Willard <travis@archlinux.org>:
On Thu, 13 Sep 2007 10:14:46 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
2007/9/13, Tobias Powalowski <t.powa@gmx.de>:
Am Mittwoch 12 September 2007 schrieb Jason Chu:
I'm still worried about the three different versions of the packages. Can someone give me some numbers about untagged changes or differences between arch64 and arch32?
Jason
http://archlinux.org/~andyrtr/pkg_diff.html i would say the red ones could be troublemakers the rest should be fine
There should be some untagged packages with done bugfixes in them. In any case we shouldn't lose those untagged changes, as it will be a PITA to find and fix them later again. Doesn't CVS has some possibility to move untagged changes?
If one of the packages we're moving has untagged changes, then why don't we use this move to tag the newest version, build, and upload it? Problem solved?
Yes. We just need to indentify all those packages, bump their pkgrel and upload.
Is anything we're moving in TESTING currently? 'Cause there's another tag we have to deal with.
-- Roman Kyrylych (Роман Кирилич)
Forgive me if it's been mentioned, but keep a close eye on deps. We don't want to move deps of [current] apps to [extra]. Anyway we can automatically ensure this? James
On 9/13/07, James Rayner <iphitus@gmail.com> wrote:
Forgive me if it's been mentioned, but keep a close eye on deps. We don't want to move deps of [current] apps to [extra].
Anyway we can automatically ensure this?
I'm sure a quick script wouldn't be hard.... when I get a chance, I'll throw something dumb together
Am Donnerstag 13 September 2007 schrieb Aaron Griffin:
On 9/13/07, James Rayner <iphitus@gmail.com> wrote:
Forgive me if it's been mentioned, but keep a close eye on deps. We don't want to move deps of [current] apps to [extra].
Anyway we can automatically ensure this?
I'm sure a quick script wouldn't be hard.... when I get a chance, I'll throw something dumb together
_______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
Hi can we stop rsyncs soon and announce our maintance work on homepage? also at this time noone should add and commit new packages in current/extra! greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Donnerstag, 13. September 2007 16:32:34 schrieb Tobias Powalowski:
Hi can we stop rsyncs soon and announce our maintance work on homepage? also at this time noone should add and commit new packages in current/extra! greetings tpowa
Perhaps everybody should commit outstanding changes till tonight. We can resync the repos tomorrow then. According to the list at http://www.archlinux.org/~andyrtr/pkg_diff.html Btw: I think it would best to create a new repo for [core] and not use the arch cvs repo. It includes additional stuff like the website and has another name than the package repo. In addition to this we keep a "backup" for the case we mess up everything. :-) -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
On 9/13/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Btw: I think it would best to create a new repo for [core] and not use the arch cvs repo. It includes additional stuff like the website and has another name than the package repo. In addition to this we keep a "backup" for the case we mess up everything. :-)
I agree. If we use tailor, we can easily create new repos and maintain history. Or hell, it's RCS backed so we could always just copy the full repo and then tear it apart.
On 9/13/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Perhaps everybody should commit outstanding changes till tonight. We can resync the repos tomorrow then. According to the list at http://www.archlinux.org/~andyrtr/pkg_diff.html
Forgot this part. This is a good idea. tpowa, seeing as you're leading this charge, can you just start a separate thread that says "please hold commits" just in case people haven't been reading this far into this one? It also gives us some nice history by title 8)
This thread has become loooong, took me a while to read. Tobias Powalowski schrieb:
it's quite a long time ago we had a dev meeting, but i think there were quite some agreement what [core] should be and we should start doing this soon. Our next ISOs shouldn't have the big current anymore only ftp and [core].
Good!
[non-free] repository we should add a non-free repository with stuff that is not freely distributable, like acroread, sun java, firmware files, flash etc. this cleanup would affect [extra] and [current] that way we could finally have cds of [extra] too without getting into trouble.
As mentioned above by someone else, we shouldn't do that now! One step at a time, care about core now.
[core] repository should be like [base] + some extra stuff the question is: what is extra stuff? imho, it should be everything that is needed for networking free kernel network modules free wlan stuff all supported main filesystems
I am generally fine with your list, we just should put them in categories: [core] -> base: everything in our current/base except gcc, auto*, pkgconfig and such (make base smaller) -> devel: the gcc, auto*, pkgconfig -> support: (=stuff you may need to get the system running) ndiswrapper ndiswrapper-utils wlan-ng26 rt2500 madwifi madwifi-utils bcm43xx-fwcutter These are the ones you added, I'd like to add ipw3945, ipw3945d, ipw3495-ucode, iwlwifi, iwlwifi-{3945,4965}-ucode, rt2x00 and any other network driver or firmware we are allowed to add (Intel is okay with it, who else is?) fuse ntfs-3g iptables dosfsutils ntfsprogs -kexec-tools (you added that, we don't need that here) snarf dnsutils hdparm bridge-utils ifenslave xinetd portmap nfsidmap nfs-utils openssh netkit-telnet screen isdn4k-utils capi4k-utils ppp (move it from base) rp-pppoe (move from base) pptpclient vpnc openvpn wpa_supplicant (move from base)
everything else from [current] should be moved to [extra]. your opinions, lets get something done this weekend.
Okay.
Thomas Bächler wrote:
[core] -> base: everything in our current/base except gcc, auto*, pkgconfig and such (make base smaller) -> devel: the gcc, auto*, pkgconfig -> support: (=stuff you may need to get the system running) ndiswrapper ndiswrapper-utils wlan-ng26 rt2500 madwifi madwifi-utils bcm43xx-fwcutter These are the ones you added, I'd like to add ipw3945, ipw3945d, ipw3495-ucode, iwlwifi, iwlwifi-{3945,4965}-ucode, rt2x00 and any other network driver or firmware we are allowed to add (Intel is okay with it, who else is?)
I mailed Ralink about their firmware, and I now have authorisation for us to distribute them, along with a specific license file. Do we need both rt2500 and rt2x00? I've never used rt2500, but rt2x00 is working very well for me these days.
fuse ntfs-3g iptables dosfsutils ntfsprogs -kexec-tools (you added that, we don't need that here) snarf dnsutils hdparm bridge-utils ifenslave xinetd portmap nfsidmap nfs-utils openssh netkit-telnet screen isdn4k-utils capi4k-utils ppp (move it from base) rp-pppoe (move from base) pptpclient vpnc openvpn
If we're doing VPN support, IPSec users would probably appreciate openswan.
participants (17)
-
Aaron Griffin
-
Alexander Baldeck
-
Dale Blount
-
Damir Perisa
-
Daniel Isenmann
-
eliott
-
James Rayner
-
Jason Chu
-
Paul Mattal
-
Phil Dillon-Thiselton
-
Pierre Schmitz
-
Roman Kyrylych
-
Simo Leone
-
Thomas Bächler
-
Tobias Powalowski
-
Tom K
-
Travis Willard