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

[arch-dev-public] [signoff] ifenslave 1.1.0-6
by Dan McGee 31 Jan '11

31 Jan '11

Likely that I won't hear much back, so I'll just move this in a week if nothing else. Just an old package refresh: * Change source location to a git blob URL * makedepends kernel26-headers -> linux-api-headers * Respect $LDFLAGS -Dan

1 0

[arch-dev-public] perl 5.12.3
by Ángel Velásquez 31 Jan '11

31 Jan '11

Hi, As you know yesterday a new minor version of 5.12 branch of perl were released. I've recently rebuilt perl 5.12.2 which is in [testing] waiting for signoff to fix a little bug with building with gcc 4.5. So, basicly we have to do the rebuild that we did the last month again for some packages, I can work with this if Kevin isn't available (cc'ing him) so ideally IMO we can start the rebuild of perl dependencies into [staging] then get into [testing] after the week of Feb 5th Opinions? ideas? -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com

4 5

Re: [arch-dev-public] [signoff] iputils-20101006-1
by Tobias Powalowski 31 Jan '11

31 Jan '11

Am Samstag 29 Januar 2011 schrieb Andrea Scarpino: > On Wednesday 26 January 2011 17:51:09 Stéphane Gaudreault wrote: > > * Upgrade to 20101006 (this release fix the security issue > > CVE-2010-2529). Complete changelog here : > > http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=blob_ > > pla in;f=RELNOTES;hb=HEAD > > > > * As a workaround for FS#20251, a patch that contain the man pages is > > applyed. > > signoff x86_64 signoff x86_64 -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] [signoff] pciutils-3.1.7-3
by Tobias Powalowski 30 Jan '11

30 Jan '11

Hi guys, rebuild with fixed CFLAGS. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-dev-public] Fwd: Extra package [mplayer] marked out-of-date
by Ionuț Bîru 30 Jan '11

30 Jan '11

I'm unable to respond to you because you "missed" to add your real email. This is a good opportunity to announce that i won't follow releases and i'll stick with svn snapshots. -------- Original Message -------- Subject: Extra package [mplayer] marked out-of-date Date: Sun, 30 Jan 2011 20:41:41 -0000 From: Arch Website Notification <nobody(a)archlinux.org> To: ibiru(a)archlinux.org * Note: this is an automated message ab(a)cd.ef wants to notify you that the following package may be out-of-date: Package Name: mplayer Architecture: i686 Repository: Extra (http://www.archlinux.org/packages/extra/i686/mplayer/) The user provided the following additional text: Why not stick to releases? In this case 1.0 release candidate 4 ftp://ftp1.mplayerhq.hu/MPlayer/releases/MPlayer-1.0rc4.tar.bz2

1 0

[arch-dev-public] Stop reopening old bug reports.
by Thomas Bächler 30 Jan '11

30 Jan '11

I had this a couple of times now: Some of my bug reports, which have been closed for a over year have been reopened. Please do not do this. While the symptoms are related, the problem is most of the time completely different, and having two issues in one report is only confusing, and it annoys me a lot. Please please, don't do this, tell the users to open new bug reports.

1 0

[arch-dev-public] [signoff] gcc-4.5.2-6
by Allan McRae 30 Jan '11

30 Jan '11

There are a lot of nice backports going into the 4.5 branch as bugs get fixed on the way to the 4.6 release so I decided it was time to grab a new 4.5 snapshot. Signoff both, Allan

3 2

[arch-dev-public] [signoff] TeXLive packages
by Rémy Oudompheng 30 Jan '11

30 Jan '11

Hello, I have updated the texlive non-binary packages to track the upstream updates. You will find the detailed list of updated packages in the attached file. The update should remain straightforward. I have cleaned up the install scriptlet, hoping that it still works as intended. Please notify me of any inconsistencies. Rémy.

3 6

[arch-dev-public] [signoff] kernel26-2.6.37-5
by Tobias Powalowski 30 Jan '11

30 Jan '11

Hi guys, now with fixed module-init-tools please signoff 2.6.37 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - modules are now gzipped, this saves 70MB disk space - added CONFIG_EXT3_DEFAULTS_TO_ORDERED=y - aufs2.1 latest snapshot - added crypto headers - added xen headers greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4

[arch-dev-public] definition of the core repo, putting nilfs-utils, btrfs-progs and dosfstools in core
by Dieter Plaetinck 29 Jan '11

29 Jan '11

Last time the topic "moving nilfs/btrfs utilities in core" generated some discussion, but no outcome. (and not even all my questions were answered) (http://mailman.archlinux.org/pipermail/arch-dev-public/2010-December/018656…) So I'll try again, and I'll try to be more clear. question 1: If you install arch linux on a foo-filesystem, should you install foo-utils as well? so that at least your system doesn't break when it needs to run fsck.foo during boot. IMHO the answer is yes. question 2: what exacly is the definition of the core repo? Pierre tells me "The idea of core was to provide a minimal set of packages that are needed by nearly all users to set up a base system." If is true, what separates base from core? Because this definition looks an awful lot like the definition of base to me. AFAIK core is about bundling all packages which are critical (for the purpose of getting the system to run) for some users, depending on their particular setup. This is the reasoning why we include the core repo on our core install images, because we say "with this repo, users can install what they need in order to make their system boot and run fine". This is also in line with what I see on https://wiki.archlinux.org/index.php/Official_Repositories ("will provide you with a fully functional base system") This is the problem: - we want to allow users to use new filesystems during installation. Currently this includes nilfs2 and btrfs. (marked as experimental in aif). - On the other hand we apparently don't allow infrequently used packages in core. Even if I would wait and only support these filesystems when they are declared stable, their package usage would still be low. It would be pretty backwards if I would need to wait for users to configure their systems using the filesystems manually, so the package usage goes up, before I can include them on the installation media. Currently, dosfstools, nilfs-utils and btrfs-progs-unstable are not in core and can't be installed by using a networkless install with the core-images. So, How do we solve this? I see two outcomes: - we add the packages mentioned above to core, and loosen up the signoff requirements for packages with low usage. (because "commonly used" and "needed for a base system" are very different things) - we do not add these packages to core, and add something about "must have high usage" on the wikipage i mentioned above. this also means I will need to include a small repo with "needed for base systems, but with low usage" on the core install images, to allow users to install these packages. And I'll need to adapt aif because it now needs to use additional repositories to install required-to-boot packages. I vote for outcome 1. Dieter

8 11