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

[arch-dev-public] Integrity check in devtools
by Thomas Bächler 25 Sep '07

25 Sep '07

This is a little patch to check the integrity of the uploaded file after uploading it. It will avoid problems like the ones with kernel26 or openoffice-base recently. I don't have time to build new devtools packages now, so I'll do it later if nobody has done it already. You can however apply the patch to your local extrapkg and test it. --- extrapkg 2007-09-25 20:45:17.000000000 +0200 +++ /mnt/arch32/usr/bin/extrapkg 2007-09-19 21:37:52.000000000 +0200 @@ -46,6 +46,12 @@ if [ "$repo" != "community" ]; then scp $pkgfile archlinux.org:staging/$repo/add + if [ "$(md5sum $pkgfile | cut -d' ' -f1)" != "$(ssh archlinux.org md5sum staging/${repo}/add/$pkgfile | cut -d' ' -f1)" ]; then + echo "File got corrupted during upload, cancelled." + exit 1 + else + echo "File integrity okay." + fi else if [ ! -f ~/.tupkg ]; then echo "Must configure tupkg via ~/.tupkg, cancelled"

1 0

[arch-dev-public] moving php-suhopsin to [extra]
by Pierre Schmitz 25 Sep '07

25 Sep '07

Hi all, I am about to move the new php package to testing soon. (I will talk about this later) I would like to move the suhosin extension, which I currently maintain in [community], to [extra]. Everybody who wants to use php on a server should use this extension. Moving this to [extra] should underline this security aspect. What do you think about this? Any complaints? :-) Pierre -- archlinux.de

4 5

[arch-dev-public] commiting arch-independend pkgs to both repos at the same time
by Damir Perisa 25 Sep '07

25 Sep '07

weird idea, but i'm putting it here anyway: some pkgs are arch-independend (e.g. fonts). they can actually be built and commited to i686 and x86_64 at the same time, since the bindiff of the pkg is nonexistant. any chance to have this in devtools implemented? or generally asked: do you like the idea? the main advantage is, that this pkgs need to be uploaded only once (and then just copied to the other staging dir) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

4 5

[arch-dev-public] X.org 7.3 about to hit Testing
by Alexander Baldeck 25 Sep '07

25 Sep '07

Hey all, I've had several discussions with devs and users about X.org 7.3 and the question why it was not yet pushed to testing. My reasons were the ABI changes that rendered nvidia drivers unusable and I had no reports on fglrx so far. Now that nvidia released version 100.14.19 the -ignoreABI workaround is not necessary anymore. The legacy drivers have not yet been updated though and still no definite reports on fglrx. I would very much like to push 7.3 to testing still, as it would save a great deal of work since I would only have to maintain one version of it. What are your thoughts? Cheers, -F

5 13

[arch-dev-public] Test Isos with core repository
by Tobias Powalowski 24 Sep '07

24 Sep '07

Hi here the changelog: i changed everything to fit to new core repository, 2 isos left ftp iso and core iso, the rest was setup/archboot changes to achieve this. - I cleaned up our documentation, to fit to those stuff please read it and tell me what is missing or wrong. - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - disabled arch_addons hook by default, it is triggered by arch-addons boot parameter - Ram usage increased to 160MB - added hosts.deny and hosts.allow to config dialog - added licenses to install environment - fixed km to not show broken chars after exit you can download i686 Isos here: http://www.archlinux.org/~tpowa/rc-iso/686 you can download x86_64 Isos here: http://www.archlinux.org/~tpowa/rc-iso/x86_64 have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 8

[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