- Arch-dev-public - lists.archlinux.org

[arch-dev-public] save some kb - ln ;)
by Damir Perisa 24 Sep '07

24 Sep '07

kde stores some licences under /opt/kde/share/apps/LICENSES/ and as we have this same licences already in arch (/usr/share/licenses/), what about replacing them in the kde pkg with links to the ones in our system? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

4 7

[arch-dev-public] Questions about quickinst
by Jason Chu 24 Sep '07

24 Sep '07

Maybe I missed the discussion on this one... I was trying to work on pacbuild but quickinst doesn't work for me. If I'm not mistaken, we should have a setup directory in core/os/i686, right? Is there a reason why we don't? Is this all we need to convert over to the new repo layout? Jason

4 5

[arch-dev-public] GNOME updates to testing
by Jan de Groot 24 Sep '07

24 Sep '07

Hi All, I'm preparing GNOME 2.20 for testing, which should be done by upcoming sunday. I'm not rushing anything: I'm evaluating package quality of every individual package (namcap, checkpkg), checking upstream SVN for post-release patches that should be included, etc. At this moment I have most of GNOME 2.20 platform in my staging dir on gerolde, the PKGBUILDs and patches have been committed to CVS. I haven't seen many issues with this release, most problems are tackled in the GNOME 2.19 repository already, some other known bugs are waiting for simple fixes which are known on the forums and our bugtracker. I think this release will sit in testing for one or maybe two weeks, nothing more. During this period I expect some rebuilds for applications that link to API/ABI unstable libraries in the GNOME desktop suite (totem-plparser has a sobump, probably libgtop and libwnck also, have to checkpkg for all the details of this). I'll keep everyone updated on the status of this.

3 5

[arch-dev-public] Which Way Forward For Package Maintainance [was: next major steps have to be planned]
by Aaron Griffin 23 Sep '07

23 Sep '07

aaron.proxy_mail(); Essien had some points to say on this topic, so I figured it was a good time to break this point out into a separate thread too. Here goes: ---------- Forwarded message ---------- From: Essien Ita Essien <me(a)essienitaessien.com> You know, we really need to have properly defined seperate dev teams, this main is going to focus on just one of them teams, but in a later mail i'll elaborate my ideas further. Paul Mattal wrote: >> <snip> >> 3) This has historically be a problem forever - unmaintained packages. >> Some of us do a lot of development work (Dan, Eliott, etc) and don't >> have huge amounts of time to help out with 200 packages at once. But >> we do need a way to stabilize this load a little better. >> Andy, you seem to know our current package set better than anyone. >> Could you possibly keep on bringing this up to people - in an attempt >> to push the load around just a little bit. >> By this, I mean, if we have a person with 10 packages (not people >> doing heavy development work) and others with 300, we should do >> something about that - you seem the best person for this job. > > I remain convinced that the way to tackle this problem is to allow > more than one maintainer per package. If groups of people are > responsible for a package, people will feel more empowered to work > on packages that aren't "theirs" and will know who to coordinate > with to do so. I agree with Paul here, but I even go futher and *formalize* the problem scope. The problem like I see it is that you *need* to be an *archlinux-developer* to be allowed to maintain packages in core and extra. I guess this is just to guarantee quality of packages but i think there are other ways of guaranteeing package quality and at the same time allowing the current strict definition of arch developers to be the only ones responsible for package maintainance. I want to propose the following approach. 1. The package management team should be properly defined out of the rest of the *blessed* archlinux development team. 2. Every member of this team will be a package Maintainer (even if you maintain just one package, you are a maintainer). But not every member of this team will be able to *commit* to the official repositories. 3. There will be some members of the team called _sponsors_ who will be the only ppl able to commit to the actual repositories and will also act as the QA guards to ensure proper quality of packages. 4. The other maintainers will have to go thru the sponsors to get their packages accepted or updated, and a sponsor can decide to desponsor a package for various reasons (like inactive maintainance by a maintainer or a maintainers non-response to bug reports). The thing is we already have this kind of setup:- namely the community/aur system. I think we _need_ to admit to ourselves that the communit/aur repo works properly, but we need to somehow co-opt that system now that our workload is growing. I propose that: 1. first... all *orphaned packages* from extra, core, community, aur, etc, should be moved into an [unmaintained] repository and just be done with it. 2. Then we should extend official status to community. (adding it to pacman repo files) 3. Then we should slowly start setting up the sponsor/maintainer infrastructure, with all TUs automatically becoming sponsors in the new dispensation along with current developers who want to continue with package maintainance tasks as opposed to other development tasks (ISO building, etc). 4. The new sponsors should go around and for packages that list them as Maintainers but have seperate Contributors, invite those contributors to become Maintainers. 5. Draw up guidelines for the operation of the sponsor/maintainer relationship. I'll be willing to help in any documentation that will be needed if this is to be done. 6. Encourage ppl that are maintaining packages on AUR to apply for package sponsorship for their packages and let the rest happen from there. > > I know I personally would sign up as a maintainer for more packages > if I weren't the "only one" taking them on but rather part of a team > maintaining those packages. I think the system i describe above is more efficient than staying tied to just a small team doing all the work. cheers, Essien

3 2

[arch-dev-public] Additional Package ISOs [was Xorg in extra]
by Aaron Griffin 22 Sep '07

22 Sep '07

On 9/20/07, JJDaNiMoTh <jjdanimoth(a)gmail.com> wrote: > I know that this isn't the right place, but I try. > What about people without a DSL connection? > They can download core isos ( that are more frequently released ) from university or > at work, it's right.. but how they can download all the packages in /extra? > Have we a plain for these situation (like a iso with-all, using a dvd)? > > Excuse me if this was recently discussed. Links are appreciated :D This was discussed, but it wasn't covered in a public manner all that well. The rough plan, at this point, would be to create *additional* ISOs with sets of packages. This was suggested around the proverbial water cooler, but was never really laid out all that well. Here's what I see, and I will bring this up with the rest of the developers, to see what they think, but I do agree it is something we didn't fully address before doing this. I personally feel we could make one or two addon disks which JUST have packages for people to download. Or, alternatively, throw some scripts out there so people can make a package iso simply... or hell, even both. What do the rest of the devs think?

4 3

[arch-dev-public] nfs init script changes
by Tom K 21 Sep '07

21 Sep '07

Ever since http://bugs.archlinux.org/task/7368 was raised, back in the summer, I've intended to do this, but life has been less than cooperative. Now that we have the new nfs-utils/util-linux-ng setup in place, it seems like a good time to address it, finally. The nfs-utils tarball includes this README: http://www.linux-nfs.org/cgi-bin/gitweb.cgi?p=nfs-utils;a=blob_plain;h=e219… which details the preferred daemon startup order for both server and client. There are significant differences between the order described there and our current nfs scripts, notably the omission of the /proc/fs/nfsd mount and the sm-notify command. I have edited the main /etc/rc.d/nfsd script accordingly, and I have also made changes to /etc/rc.d/nfslock and /etc/conf.d/nfs as required. I'd like to acknowledge shazeal's contribution, posted in the above-mentioned bug report, and also the 'inspiration' provided by the equivalent Gentoo scripts. ;) The end result works fine here, on my server-&-3-clients setup - mounted shares are retained/remounted over both server and client reboots. I'm inclined to put it straight into core, but being naturally cautious, I'm opting instead for a 'cooling-off' period, during which any peer who feels like doing some reviewing is more than welcome. The package is here: http://www.archlinux.org/~tom/packages/nfs-utils-1.1.0-2-i686.pkg.tar.gz and the build files are here: http://www.archlinux.org/~tom/packages/nfs-utils/ Unless there are valid objections, I'll put this up in 24 hours, accompanied by appropriate changes to the NFS wiki page. And just so it's clear - as with the current scripts, these ones handle nfsv2/3 only. Once this is in, I intend to look at nfsv4. Happy Friday T.

2 1

[arch-dev-public] Idea: ArchLinux News
by Paul Mattal 21 Sep '07

21 Sep '07

I know we are all inundated with sources of Arch Linux news and have tried various blogs and ideas that haven't worked well in the past, but I had a new twist on this idea. What if we set up a CMS allowing anyone to submit articles, and then assembled a small group of moderators with community track record and good language/editing skills who would triage/read/edit the articles/posts? This would create a more meaty way to generate interesting thought in the Arch community, and provide a more serious "publication" about Arch without extreme amounts of effort. If we used software optimized for this (there must be many choices), then approving posts and doing minor edits would be little work for the moderators. I'm imagining something like a Slashdot model for post/moderation but with more meaty new ideas and news by the poster. Essentially this would be a way to get your interesting material read and heard by the Arch world, regardless of how long you've been here or what positions you may have in the community. Content guidelines I would suggest: * should be related to Arch Linux and be of general interest to someone interested in Arch and the community * posts should provide some new information and reflect some new thoughts by the writer; these are intended to be "articles" that will enrich the community, and we want more than just a link to another post or an open-ended discussion-starter question * should be well-written and require as little editing as possible; the closer the submission is to press-ready, the less work the moderators will need to do and the more likely your post is to be accepted * submitted posts become openly licensed and are subject to editing by the moderators If such a system could be set up, I'd be willing to moderate regularly, and post occasionally. I could see this also as replacing the "news" on the main page, but also enriching it significantly. The nice part is that it would provide one single place people can go for their important Arch news. Of course, people are always free to look elsewhere-- but we'd guarantee a high-quality product with interesting news you'd want to read. What do folks think? Anyone have experience with using a CMS in this manner where anyone can create posts and moderators edit/approve/post them? Are there refinements of this idea that would work better? - P

4 5

[arch-dev-public] Next package cleanup [was next major steps have to be planned]
by Aaron Griffin 21 Sep '07

21 Sep '07

On 9/20/07, Eric Belanger <belanger(a)astro.umontreal.ca> wrote: > > > 4) So we need to revisit, once again, the package cleanup that I had > > started months ago. Eric, you were helpful last time - would you be ok > > with figuring out the details of another round of cleanup? > > Sure. I already have a few names in my mind because a while ago I tried > porting packages to x86_64 and came across several ones where the sources > were missing or that were dead projects. I'll also check again the wiki > list and the orphaned packages in the repo. > > Before removing anything, I'll post the list of candidates for removal > here with a short reason for the removal to inform you and give an > occasion to contest the removal of a package. Great, thanks a lot! The last time, we had a lot of success with a public wiki and getting the userbase involved. Do you think that's still appropriate until we winnow the packages to a more concrete set? Or should we stick to internal at this time and get rid of packages with incompatibilities and the like? -- Aaron

3 2

[arch-dev-public] core error/conflicts found
by Tobias Powalowski 20 Sep '07

20 Sep '07

Hi while testing the new ISO i found that the ralink fw packages provide the same LICENSE file, im gone the whole day so if someone could fix it would be cool. make is also missing from /devel or packages.txt was again broken, please take a look at it. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 5

[arch-dev-public] next major steps have to be planned
by Andreas Radke 20 Sep '07

20 Sep '07

The repo shuffle is almost done. Next big tasks are pending. So i want to discuss with you the order for the next steps and how much time we need to finish remaining tasks. 1) Xorg is in testing for months. should we move it knowing some things will be broken. Should it stay in testing for some more time. Give up the bump and delay the upgrade? It's not good to have such a big player in testing for so long. I'm not sure if any other pkg we want to build in testing will link against it and might make trouble later moving it to extra. 2) Pending big updates: db, heimdal, cups 1.3.x together with gpl ghostscript. You all know how long the list of rebuilds will become... 3) We need to make sure all packages in core/extra have at least one active(!) maintainer(not talking about wanted package divisions). Right now we have 550(before core move)-700(now) orphaned packages. Even 112 orphaned core packages after the move. This is not acceptable! Also some maintained packages keep waiting for updates for too long. 4) This brings us to the real repo cleanup. We had a Wiki side collecting ideas for removal and somebody was talking about an improved ArchStats. Both can help us. We should also leave the way how we choose packages we bring into the repo from "hey, I like it so I bring it in" to the needs of our users/community. 5) Move to another version control system. Was it a common decision to move to svn? Then we should prepare the move well not to far away. 6) Setup a standard build tool for all devs: force everyone to make use of a unionfs based devtool. 7) State of repoman? I don't want to hurry from one chaos to the next one. But I also don't want to see us again falling back and watch several months passing. Andy

4 3