[arch-dev-public] rootprefix change for kmod 10
Hi all, I've been talking to Thomas about this, and we've come to the conclusion that it's probably just broken to continue shipping kmod built with a rootprefix. I think there's been two recurring problems coming up that make this revert warranted: - It makes building kernels for other distros not fun - The kernel doesn't really support it. Various Kbuild targets just break with no clean fix available. kmod 10 is to be released quite soon, and I'm planning on building without the rootprefix. It should not affect us in any real way at this point, given that /lib is now a symlink. It does mean that for the next kernel built, we'll need to make a minor adjustment to the kernel PKGBUILDs: running depmod before moving the module dir instead of vice versa. I can fix this myself in SVN when I push kmod-10 to [testing]. I've been running my own kmod without the rootprefix for the past month and change and haven't run into any problems. The only oddity is that modinfo will report "bogus" paths (/lib/modules, not /usr/lib/modules). mkinitcpio and other tools have no problems with this. The ideal solution to this, in the end, is probably to introduce another flag to kmod tools to specify the base dir at runtime, rather than at compile time. When I get some time, I'll talk to upstream and see if they're amiable to the idea. Cheers, Dave P.S. I'd also like to see us stop shipping compressed modules, but that's another matter all together.
Re: [arch-dev-public] fontconfig 2.10.1 will require user interaction
On Thu, Sep 6, 2012 at 2:25 AM, Andreas Radke wrote: > Am Wed, 5 Sep 2012 23:02:27 +0200 > schrieb Rémy Oudompheng : > >> I would simply recommend removing the offending files using rm, we >> certainly know the list. >> >> Rémy. >> > > News draft: > > fontconfig 2.10.1 update - manual intervention required > > Fontconfig 2.10.1 update overwrites symlinks created by > the former package version. These symlinks need to be removed before > any further update: > > rm -f /etc/fonts/conf.d/20-unhint-small-vera.conf > rm -f /etc/fonts/conf.d/29-replace-bitmap-fonts.conf > rm -f /etc/fonts/conf.d/30-metric-aliases.conf > rm -f /etc/fonts/conf.d/30-urw-aliases.conf > rm -f /etc/fonts/conf.d/40-nonlatin.conf > rm -f /etc/fonts/conf.d/45-latin.conf > rm -f /etc/fonts/conf.d/49-sansserif.conf > rm -f /etc/fonts/conf.d/50-user.conf > rm -f /etc/fonts/conf.d/51-local.conf > rm -f /etc/fonts/conf.d/60-latin.conf > rm -f /etc/fonts/conf.d/65-fonts-persian.conf > rm -f /etc/fonts/conf.d/65-nonlatin.conf > rm -f /etc/fonts/conf.d/69-unifont.conf > rm -f /etc/fonts/conf.d/80-delicious.conf > rm -f /etc/fonts/conf.d/90-synthetic.conf > pacman -Syu > > Main systemwide configuration should be done by symlinks > (especially for autohinting, sub-pixel and lcdfilter): > > cd /etc/fonts/conf.d > ln -s ../conf.avail/XX-foo.conf > > Check also https://wiki.archlinux.org/index.php/Font_Configuration and > https://wiki.archlinux.org/index.php/Fonts. I edited the news item only slightly so Markdown formatting would kick in on the command listings.
Re: [arch-dev-public] fontconfig 2.10.1 will require user interaction
On 6 September 2012 23:57, Daniel Wallace wrote: > can the news article bechanged to say -Syu instead of now where it says > -Sy fontconfig which we have always said was frowned upon if I remember > correctly. > https://bbs.archlinux.org/viewtopic.php?pid=802661#p802661 You don't want to pull in extra burden when there's intervention for just one package. More can go wrong. So it's a case-by-case sort of thing. The warning to always -Syu is something general, mostly for people that don't know what they're doing. An update can involve a number of packages, so if you simply -Sy pkg there is a chance to break things. This does not apply to independent package updates and cases such as the one we have here today. So, do -Syu, unless otherwise stated. There will always be special cases, there is no one solution. -- GPG/PGP ID: C0711BF1
Re: [arch-dev-public] [RFC] Moving repos to nymeria
On Thu, Sep 6, 2012 at 12:46 PM, Gaetan Bisson wrote: > [2012-09-06 17:39:03 +0200] Florian Pritz: >> The idea is to reduce the possible damage an attacker can cause if he >> happens to obtain a dev's/TU's ssh key. Without a shell and only a few >> whitelisted commands the box should be very safe. That allows us to use >> a server stored signing key for the database without having to worry >> about someone using a kernel exploit and gaining access to the key. > > Did we abandon the idea of having packagers download the old DB, check > its signature, do changes to it, sign the new DB, and upload it back? > Because I would certainly find this much safer and trustworthy than > having a black-box server blindly signs anything it is given. Agree. > > And I would also find it too bad to lose the flexibility actual non-root > Linux accounts give, such as being able to fix things ourselves when > they go wrong (like when pushing to the wrong repo). What will happen to our personal web space? And what about /srv/ftp/other/ ? Will they move to the new server? If so, we'll need to whitelist enough commands so we can use them without being a PITA. Could you give us a more detailed list of the commands that will be allowed? I'm concerned that the shell would become so crippled that it would be practically unusable. Eric > > Cheers. > > -- > Gaetan
Re: [arch-dev-public] [RFC] Moving repos to nymeria
[2012-09-06 17:39:03 +0200] Florian Pritz: > The idea is to reduce the possible damage an attacker can cause if he > happens to obtain a dev's/TU's ssh key. Without a shell and only a few > whitelisted commands the box should be very safe. That allows us to use > a server stored signing key for the database without having to worry > about someone using a kernel exploit and gaining access to the key. Did we abandon the idea of having packagers download the old DB, check its signature, do changes to it, sign the new DB, and upload it back? Because I would certainly find this much safer and trustworthy than having a black-box server blindly signs anything it is given. And I would also find it too bad to lose the flexibility actual non-root Linux accounts give, such as being able to fix things ourselves when they go wrong (like when pushing to the wrong repo). Cheers. -- Gaetan pgprGhnVzERGr.pgp Description: PGP signature
Re: [arch-dev-public] fontconfig 2.10.1 will require user interaction
Yes, I'm top posting from my phone. No, there isn't much point in worrying about -Sy if the next thing you do is -Su. At some point we have to accept that no matter what we post, someone will complain that it was misleading, wrong, or otherwise kicked their cat. On Sep 6, 2012 11:58 AM, "Daniel Wallace" wrote: > On Thu, Sep 06, 2012 at 09:25:06AM +0200, Andreas Radke wrote: > > Am Wed, 5 Sep 2012 23:02:27 +0200 > > schrieb Rémy Oudompheng : > > > > > I would simply recommend removing the offending files using rm, we > > > certainly know the list. > > > > > > Rémy. > > > > > > > News draft: > > > > fontconfig 2.10.1 update - manual intervention required > > > > Fontconfig 2.10.1 update overwrites symlinks created by > > the former package version. These symlinks need to be removed before > > any further update: > > > > rm -f /etc/fonts/conf.d/20-unhint-small-vera.conf > > rm -f /etc/fonts/conf.d/29-replace-bitmap-fonts.conf > > rm -f /etc/fonts/conf.d/30-metric-aliases.conf > > rm -f /etc/fonts/conf.d/30-urw-aliases.conf > > rm -f /etc/fonts/conf.d/40-nonlatin.conf > > rm -f /etc/fonts/conf.d/45-latin.conf > > rm -f /etc/fonts/conf.d/49-sansserif.conf > > rm -f /etc/fonts/conf.d/50-user.conf > > rm -f /etc/fonts/conf.d/51-local.conf > > rm -f /etc/fonts/conf.d/60-latin.conf > > rm -f /etc/fonts/conf.d/65-fonts-persian.conf > > rm -f /etc/fonts/conf.d/65-nonlatin.conf > > rm -f /etc/fonts/conf.d/69-unifont.conf > > rm -f /etc/fonts/conf.d/80-delicious.conf > > rm -f /etc/fonts/conf.d/90-synthetic.conf > > pacman -Syu > > > > Main systemwide configuration should be done by symlinks > > (especially for autohinting, sub-pixel and lcdfilter): > > > > cd /etc/fonts/conf.d > > ln -s ../conf.avail/XX-foo.conf > > > > Check also https://wiki.archlinux.org/index.php/Font_Configuration and > > https://wiki.archlinux.org/index.php/Fonts. > > > > > > I'd like to move it soon. It seems to work pretty solid. I only had to > > fix the dpi settings on my nvidia twinview desktop where small fonts > > suddenly were displayed a lot smaller and somehow ugly. > > > > -Andy > > > can the news article bechanged to say -Syu instead of now where it says > -Sy fontconfig which we have always said was frowned upon if I remember > correctly. > https://bbs.archlinux.org/viewtopic.php?pid=802661#p802661 > -- > Daniel Wallace > Archlinux Trusted User (gtmanfred) > Georgia Institute of Technology >
Re: [arch-dev-public] fontconfig 2.10.1 will require user interaction
On Thu, Sep 06, 2012 at 09:25:06AM +0200, Andreas Radke wrote: > Am Wed, 5 Sep 2012 23:02:27 +0200 > schrieb Rémy Oudompheng : > > > I would simply recommend removing the offending files using rm, we > > certainly know the list. > > > > Rémy. > > > > News draft: > > fontconfig 2.10.1 update - manual intervention required > > Fontconfig 2.10.1 update overwrites symlinks created by > the former package version. These symlinks need to be removed before > any further update: > > rm -f /etc/fonts/conf.d/20-unhint-small-vera.conf > rm -f /etc/fonts/conf.d/29-replace-bitmap-fonts.conf > rm -f /etc/fonts/conf.d/30-metric-aliases.conf > rm -f /etc/fonts/conf.d/30-urw-aliases.conf > rm -f /etc/fonts/conf.d/40-nonlatin.conf > rm -f /etc/fonts/conf.d/45-latin.conf > rm -f /etc/fonts/conf.d/49-sansserif.conf > rm -f /etc/fonts/conf.d/50-user.conf > rm -f /etc/fonts/conf.d/51-local.conf > rm -f /etc/fonts/conf.d/60-latin.conf > rm -f /etc/fonts/conf.d/65-fonts-persian.conf > rm -f /etc/fonts/conf.d/65-nonlatin.conf > rm -f /etc/fonts/conf.d/69-unifont.conf > rm -f /etc/fonts/conf.d/80-delicious.conf > rm -f /etc/fonts/conf.d/90-synthetic.conf > pacman -Syu > > Main systemwide configuration should be done by symlinks > (especially for autohinting, sub-pixel and lcdfilter): > > cd /etc/fonts/conf.d > ln -s ../conf.avail/XX-foo.conf > > Check also https://wiki.archlinux.org/index.php/Font_Configuration and > https://wiki.archlinux.org/index.php/Fonts. > > > I'd like to move it soon. It seems to work pretty solid. I only had to > fix the dpi settings on my nvidia twinview desktop where small fonts > suddenly were displayed a lot smaller and somehow ugly. > > -Andy can the news article bechanged to say -Syu instead of now where it says -Sy fontconfig which we have always said was frowned upon if I remember correctly. https://bbs.archlinux.org/viewtopic.php?pid=802661#p802661 -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology pgp0njEQ4BSLG.pgp Description: PGP signature
Re: [arch-dev-public] [RFC] Moving repos to nymeria
On 06.09.2012 17:23, Stéphane Gaudreault wrote: > Could we run sogrep on nymeria ? I don't really see a benefit there. You can already run it on brynhild and sogrep needs a databases which is updated via a cron job so you probably won't even see a difference in update latency between the two. > Also, could you please explain why browsing the repo in a shell account > will be disabled ? I found this very useful when moving a large number > of packages from staging/testing to extra/core. The idea is to reduce the possible damage an attacker can cause if he happens to obtain a dev's/TU's ssh key. Without a shell and only a few whitelisted commands the box should be very safe. That allows us to use a server stored signing key for the database without having to worry about someone using a kernel exploit and gaining access to the key. sftp will still be available so if all you want is a file list you can use that. You can also run "sudo syncrepo" on brynhild to force a sync at any time and then browse there. -- Florian Pritz signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Moving repos to nymeria
Le 2012-09-06 11:05, Florian Pritz a écrit : Hi, So we got a new box (nymeria) and I'd like to move core/extra/community/multilib/testing/.. repos + svn over there. Setup overview / changes: - create shell accounts for every user, but only allow certain commands to be executed (dbscripts, rsync) - move the svn2git conversion script to nymeria and let gudrun sync the repo periodically for cgit - let archweb sync the needed database files periodically - integrity check will run on nymeria - postfix for @archlinux.org and @aur.archlinux.org: see below [postfix] - did I miss something? Benefits: - more trustful/locked-down system (could be useful for db signing) - 1TB of disk space (~900GiB for packages) - 100Mbit/s uplink - all packages on one box so if we do a big move, extra and community can be synced without admin intervention if dbscripts support that - gerolde won't run much (anything?) any more so it could potentially be merged back into gudrun/host system Drawbacks (kind of): - no more shell accounts for browsing the repo (brynhild can be used for that) - different network latency (gudrun is located in the US, nymeria in Germany) - users can no longer mess up change the repo db manually (no idea if that's still valid, but it happened a few years ago) [postfix]: We can move both domains to nymeria and let users change the forward destination themselves (need to make sure that you can't run arbitrary commands) or just appoint an admin that takes care of changing the destination since that shouldn't happen too often. In the second case we can keep them on gudrun/sigurd or move them where ever we want. Comments welcome. Could we run sogrep on nymeria ? Also, could you please explain why browsing the repo in a shell account will be disabled ? I found this very useful when moving a large number of packages from staging/testing to extra/core. Regards, Stéphane
[arch-dev-public] [RFC] Moving repos to nymeria
Hi, So we got a new box (nymeria) and I'd like to move core/extra/community/multilib/testing/.. repos + svn over there. Setup overview / changes: - create shell accounts for every user, but only allow certain commands to be executed (dbscripts, rsync) - move the svn2git conversion script to nymeria and let gudrun sync the repo periodically for cgit - let archweb sync the needed database files periodically - integrity check will run on nymeria - postfix for @archlinux.org and @aur.archlinux.org: see below [postfix] - did I miss something? Benefits: - more trustful/locked-down system (could be useful for db signing) - 1TB of disk space (~900GiB for packages) - 100Mbit/s uplink - all packages on one box so if we do a big move, extra and community can be synced without admin intervention if dbscripts support that - gerolde won't run much (anything?) any more so it could potentially be merged back into gudrun/host system Drawbacks (kind of): - no more shell accounts for browsing the repo (brynhild can be used for that) - different network latency (gudrun is located in the US, nymeria in Germany) - users can no longer mess up change the repo db manually (no idea if that's still valid, but it happened a few years ago) [postfix]: We can move both domains to nymeria and let users change the forward destination themselves (need to make sure that you can't run arbitrary commands) or just appoint an admin that takes care of changing the destination since that shouldn't happen too often. In the second case we can keep them on gudrun/sigurd or move them where ever we want. Comments welcome. -- Florian Pritz signature.asc Description: OpenPGP digital signature
[arch-dev-public] Laurent Carlier promoted as Bug Wrangler
Just to let you know that we have a new bug wrangler on flyspray: Laurent Carlier (lordheavy) which is already a TU. Cheers -- Andrea
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 8 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 12 fully signed off packages * 28 packages missing signoffs * 16 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (8 total) == * less-451-1 (i686) * syslog-ng-3.3.6-1 (i686) * util-linux-2.22-3 (i686) * less-451-1 (x86_64) * syslog-ng-3.3.6-1 (x86_64) * util-linux-2.22-3 (x86_64) * fontconfig-2.10.1-2 (i686) * fontconfig-2.10.1-2 (x86_64) == Incomplete signoffs for [core] (7 total) == * iw-3.6-1 (i686) 0/2 signoffs * ppp-2.4.5-4 (i686) 0/2 signoffs * procps-ng-3.3.3-5 (i686) 1/2 signoffs * syslog-ng-3.3.6-1 (i686) 0/2 signoffs * sysvinit-2.88-8 (i686) 0/2 signoffs * ppp-2.4.5-4 (x86_64) 1/2 signoffs * syslog-ng-3.3.6-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (21 total) == * fetchmail-6.3.22-1 (i686) 0/2 signoffs * fontconfig-2.10.1-2 (i686) 0/2 signoffs * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (i686) 0/2 signoffs * modemmanager-0.6.0.0-1 (i686) 0/2 signoffs * network-manager-applet-0.9.6.2-1 (i686) 0/2 signoffs * networkmanager-0.9.6.0-1 (i686) 0/2 signoffs * networkmanager-openconnect-0.9.6.2-1 (i686) 0/2 signoffs * networkmanager-openvpn-0.9.6.0-1 (i686) 0/2 signoffs * networkmanager-pptp-0.9.6.0-1 (i686) 0/2 signoffs * networkmanager-vpnc-0.9.6.0-1 (i686) 0/2 signoffs * openconnect-1:4.06-1 (i686) 0/2 signoffs * upower-0.9.18-2 (i686) 0/2 signoffs * fetchmail-6.3.22-1 (x86_64) 0/2 signoffs * fontconfig-2.10.1-2 (x86_64) 0/2 signoffs * network-manager-applet-0.9.6.2-1 (x86_64) 0/2 signoffs * networkmanager-openconnect-0.9.6.2-1 (x86_64) 0/2 signoffs * networkmanager-openvpn-0.9.6.0-1 (x86_64) 0/2 signoffs * networkmanager-pptp-0.9.6.0-1 (x86_64) 0/2 signoffs * networkmanager-vpnc-0.9.6.0-1 (x86_64) 0/2 signoffs * openconnect-1:4.06-1 (x86_64) 0/2 signoffs * upower-0.9.18-2 (x86_64) 1/2 signoffs == Completed signoffs (12 total) == * coreutils-8.19-1 (i686) * less-451-1 (i686) * util-linux-2.22-3 (i686) * coreutils-8.19-1 (x86_64) * iw-3.6-1 (x86_64) * less-451-1 (x86_64) * procps-ng-3.3.3-5 (x86_64) * sysvinit-2.88-8 (x86_64) * util-linux-2.22-3 (x86_64) * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (x86_64) * modemmanager-0.6.0.0-1 (x86_64) * networkmanager-0.9.6.0-1 (x86_64) == All packages in [testing] for more than 14 days (16 total) == * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (i686), since 2012-07-29 * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (x86_64), since 2012-07-29 * networkmanager-vpnc-0.9.6.0-1 (i686), since 2012-08-07 * networkmanager-openvpn-0.9.6.0-1 (i686), since 2012-08-07 * networkmanager-pptp-0.9.6.0-1 (i686), since 2012-08-07 * networkmanager-0.9.6.0-1 (i686), since 2012-08-07 * networkmanager-vpnc-0.9.6.0-1 (x86_64), since 2012-08-07 * networkmanager-openvpn-0.9.6.0-1 (x86_64), since 2012-08-07 * networkmanager-pptp-0.9.6.0-1 (x86_64), since 2012-08-07 * networkmanager-0.9.6.0-1 (x86_64), since 2012-08-07 * networkmanager-openconnect-0.9.6.2-1 (i686), since 2012-08-09 * network-manager-applet-0.9.6.2-1 (i686), since 2012-08-09 * networkmanager-openconnect-0.9.6.2-1 (x86_64), since 2012-08-09 * network-manager-applet-0.9.6.2-1 (x86_64), since 2012-08-09 * openconnect-1:4.06-1 (i686), since 2012-08-12 * openconnect-1:4.06-1 (x86_64), since 2012-08-12 == Top five in signoffs in last 24 hours == 1. tpowa - 11 signoffs 2. allan - 6 signoffs 3. thomas - 5 signoffs 4. tomegun - 5 signoffs 5. bisson - 4 signoffs
Re: [arch-dev-public] fontconfig 2.10.1 will require user interaction
Am Wed, 5 Sep 2012 23:02:27 +0200 schrieb Rémy Oudompheng : > I would simply recommend removing the offending files using rm, we > certainly know the list. > > Rémy. > News draft: fontconfig 2.10.1 update - manual intervention required Fontconfig 2.10.1 update overwrites symlinks created by the former package version. These symlinks need to be removed before any further update: rm -f /etc/fonts/conf.d/20-unhint-small-vera.conf rm -f /etc/fonts/conf.d/29-replace-bitmap-fonts.conf rm -f /etc/fonts/conf.d/30-metric-aliases.conf rm -f /etc/fonts/conf.d/30-urw-aliases.conf rm -f /etc/fonts/conf.d/40-nonlatin.conf rm -f /etc/fonts/conf.d/45-latin.conf rm -f /etc/fonts/conf.d/49-sansserif.conf rm -f /etc/fonts/conf.d/50-user.conf rm -f /etc/fonts/conf.d/51-local.conf rm -f /etc/fonts/conf.d/60-latin.conf rm -f /etc/fonts/conf.d/65-fonts-persian.conf rm -f /etc/fonts/conf.d/65-nonlatin.conf rm -f /etc/fonts/conf.d/69-unifont.conf rm -f /etc/fonts/conf.d/80-delicious.conf rm -f /etc/fonts/conf.d/90-synthetic.conf pacman -Syu Main systemwide configuration should be done by symlinks (especially for autohinting, sub-pixel and lcdfilter): cd /etc/fonts/conf.d ln -s ../conf.avail/XX-foo.conf Check also https://wiki.archlinux.org/index.php/Font_Configuration and https://wiki.archlinux.org/index.php/Fonts. I'd like to move it soon. It seems to work pretty solid. I only had to fix the dpi settings on my nvidia twinview desktop where small fonts suddenly were displayed a lot smaller and somehow ugly. -Andy signature.asc Description: PGP signature
