Re: [arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?

Am 29.01.2018 um 22:00 schrieb Christian Rebischke via arch-dev-public: > Hello everybody, > I would like to start a discussion about Windows Subsystem Linux and > Arch linux. You all might know that Microsoft has increased their > participation in open source software a lot since Satya Nadella is

Re: [arch-dev-public] FrOSCon 2017

Am 01.01.2017 um 17:24 schrieb Bartłomiej Piotrowski: > On 2017-01-01 17:05, Jelle van der Waa wrote: >> Hi all, >> >> After meeting Levente and Sven at 33c3, I would like to see another >> developer / TU meetup at FrOSCon. The last time I was at FrOSCon, pierre >> or brain0 or heftig? managed to b

Re: [arch-dev-public] todo list for moving http -> https sources

Am 31.10.2016 um 15:05 schrieb Dave Reisner: > Asking every upstream to provide a PGP signature isn't a process which > will scale, I am against enforcing https for projects which provide signatures. As Sebastien pointed out, there are valid reasons against using https and it adds no benefit when

Re: [arch-dev-public] Me and my packages: A sad truth

Am 30.07.2016 um 18:23 schrieb Sven-Hendrik Haase: > Hey Thomas, > > Thank you for being honest and straightforward about this. Could you > provide a list of packages that are now orphaned due to this? > > All the best. Glad to hear you are generally planning to stay onboard. > > Sven I forgot

[arch-dev-public] Me and my packages: A sad truth

Hello guys, for over a year and a half, I have barely been able to do any packaging. Between job, kids, real life and some time to relax, only a few hours of time remains here and there. Sadly, this time is not enough to be able to contribute significantly to Arch Linux. Until recently, I always

[arch-dev-public] [archweb] [PULL] Archweb netboot and sponsorship updates

2c157821e17e90245888b5671baa1a47294da648: Remove AirVM ads since AirVM has ended their sponsorship (2016-06-03 14:05:48 +0200) Thomas Bächler (3): Add information and ipxe images for the new netboot system Netboot: Disable network interface renaming

[arch-dev-public] [archweb][PATCH] releng: Add netboot ipxe environment to archweb.

--- Now that the March and May ISOs have the required initramfs signatures (April version is broken, sadly), I think it is time to deploy the new netboot environment to the main archweb site. This patch does not add a website and compatible IPXE images yet, but only supplies the correct ipxe co

Re: [arch-dev-public] Issues updating to openssl 1.0.2g

Am 01.03.2016 um 20:08 schrieb Bruno Pagani: > Le 01/03/2016 19:59, Thomas Bächler a écrit : >> Am 01.03.2016 um 15:53 schrieb Pierre Schmitz: >>> Hi all, >>> >>> I just looked into updating to openssl 1.0.2g. Unfortunately this comes >>> with an ABI

Re: [arch-dev-public] Issues updating to openssl 1.0.2g

Am 01.03.2016 um 15:53 schrieb Pierre Schmitz: > Hi all, > > I just looked into updating to openssl 1.0.2g. Unfortunately this comes > with an ABI change due to SSL2 being disabled by default. This would > mean we need to rebuild most packages that link against openssl. Imho > re-enabling ssl2 see

Re: [arch-dev-public] [RFC] Filesystem package update

Am 18.12.2015 um 20:43 schrieb Sébastien Luttringer: > 2) Merge /usr/local/bin and /usr/local/sbin. This may require user > intervention > if /usr/local/sbin is not empty. So I'll post an announcement about that. > I'm running my system since September with merged sbin with no problem. /usr/local

Re: [arch-dev-public] Master key holders response time

Am 06.12.2015 um 00:35 schrieb Gaetan Bisson: > [2015-12-06 08:52:04 +1000] Allan McRae: >> Is it time to cycle our key holders? > > I vote yes. I agree. We should start introducing one new master key as soon as possible so it is spread to our users before we decide to revoke an old key. sign

Re: [arch-dev-public] TU - Lost private key

Am 05.11.2015 um 19:09 schrieb Alexandre Filgueira: > Hi > > I recently lost my private key and I can't package for community. What are > the steps in this case? > > Thanks That depends. Did you lose your ssh private key of gpg private key? Loss of the ssh private key is less of a problem than l

[arch-dev-public] FOSDEM 2016 participation (please reply until Wednesday if you are interested)

Hello guys, a user I met at FrOSCon this year and last year wants to organize an Arch Linux Devroom at FOSDEM on January 30th/31st [1]. We would need a few devs and TUs to be there at least. A program with a few talks would also be nice (users can also give talks, not only developers and TUs). Th

Re: [arch-dev-public] Fwd: [arch-events] FrOSCon 2015

Am 02.06.2015 um 17:39 schrieb Pierre Schmitz: > Hi all, > > I did not get any feedback yet. Is there any interest to meet up at > FrOSCon? And if anybody like to join and prepare a talk or workshop > that'd be great. I'd then update our submission. > > A few rough ideas would be sufficient. I a

Re: [arch-dev-public] Signing new TU keys

Am 11.05.2015 um 11:35 schrieb Allan McRae: > Hi all, > > Adding new keys is taking a long time... Here is a summary of the open > bugs and who needs to sign: > > Johannes Löthberg (50FB 9B27 3A9D 0BB5) - 22nd April: > Pierre, Thomas, Dan, Ionut > > Levente Polyak (FC1B 547C 8D81 72C8) - 16th A

Re: [arch-dev-public] Removing Ionuț as a master key holder

Am 07.02.2015 um 10:41 schrieb Allan McRae: > Ionut has done no signing/revoking for six months now. When queried on > IRC, he has repeatedly stated that it will be dealt with tomorrow. > > This is not a great issue currently as people require three valid > signatures from the five master keyhold

[arch-dev-public] Announcement Draft: Changes to microcode updates

Changes to microcode updates Microcode on Intel CPUs is no longer loaded automatically, as it needs to be loaded very early in the boot process. This requires adjustments in the bootloader. If you have an Intel CPU, please follow [the instruction in the wiki](https://wiki.archlinux.org/index.php/M

Re: [arch-dev-public] Changes to microcode updates

Am 12.10.2014 um 16:52 schrieb Christian Hesse: > Successfully tested with grub (1:2.02.beta2-4). You need something like this > in grub.cfg: > > echo'Loading Intel ucode update and initial ramdisk ...' > initrd /intel-ucode.img /initramfs-linux.img > > I edited grub.cfg manu

Re: [arch-dev-public] Changes to microcode updates

Am 12.10.2014 um 16:52 schrieb Christian Hesse: > Successfully tested with grub (1:2.02.beta2-4). You need something like this > in grub.cfg: > > echo'Loading Intel ucode update and initial ramdisk ...' > initrd /intel-ucode.img /initramfs-linux.img > > I edited grub.cfg manu

[arch-dev-public] Changes to microcode updates

Intel released a new microcode update that disables an instruction on Haswell CPUs. However, Linux doesn't handle this very well and in combination with our glibc version, this essentially crashes your system. The solution is to use the "new" early microcode update mechanism that was introduced al

Re: [arch-dev-public] Busy until mid-July, maybe?

Am 03.07.2014 16:22, schrieb Felix Yan: > On Thursday, July 03, 2014 13:26:20 Thomas Bächler wrote: >> Am 03.07.2014 12:09, schrieb Felix Yan: >>>> * lvm2 (flagged 23.06.) - easy version bump (hopefully, sometimes it >>>> breaks)> >>> lvm2-make-socke

Re: [arch-dev-public] Busy until mid-July, maybe?

Am 03.07.2014 12:09, schrieb Felix Yan: >> * lvm2 (flagged 23.06.) - easy version bump (hopefully, sometimes it breaks) > > lvm2-make-sockets-static.patch has some conflicts, I'll look into it later if > no one else is interested (I don't use LVM myself, so I may not be able to > test it). It's

[arch-dev-public] Busy until mid-July, maybe?

Hi guys, I am currently rather busy and unable to invest time into packaging. This situation has been going on all June and will likely remain unchanged for a few weeks. In the meantime, can someone upgrade my packages? The following have been flagged: * cryptsetup (flagged 29.06.) - easy versio

Re: [arch-dev-public] [RFC] Moving mail away from gerolde

Am 26.06.2014 01:11, schrieb Allan McRae: > On 26/06/14 06:17, Florian Pritz wrote: >> On 23.06.2014 19:42, Florian Pritz wrote: >>> I haven't yet look into also migrating mailman from gudrun to nymeria >>> or maybe alderaan. >> >> When I created aur-requests I had to edit 3 files on 2 hosts to ge

Re: [arch-dev-public] dosfstools to base group?

Am 17.06.2014 15:49, schrieb Tobias Powalowski: > Hi, > https://bugs.archlinux.org/task/38076 > looking at this old request, any objection to add this to base group? > > greetings > tpowa > The rationale of the bug report is incorrect. "[...] the user will also need to install dosfstools, other

Re: [arch-dev-public] Fwd: [systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1)

Am 24.04.2014 14:06, schrieb Florian Pritz: > On 24.04.2014 13:27, Tom Gundersen wrote: >> It was recently brought to my attention (see below) that we still ship >> net-tools in Arch. Should we perhaps start working on dropping that? > > I dislike ss's output format. 'ss -tulpn' is kind of the sam

[arch-dev-public] fakeroot breakage (WAS: Re: providing grsecurity in [community])

Okay, so I "fixed" the fakeroot to work with ACLs by simply removing all special ACL handling: Index: PKGBUILD === --- PKGBUILD(Revision 210798) +++ PKGBUILD(Arbeitskopie) @@ -4,7 +4,7 @@ pkgname=fakeroot pkgver=1.20 -pkgre

Re: [arch-dev-public] providing grsecurity in [community]

Am 16.04.2014 14:16, schrieb Allan McRae: > Getting off-topic... Indeed. > but only one package in our repos uses setfacl > (systemd on the journal directory) in its install script, and seven use > setcap. Getting the majority case fixed is still worth including this > in my opinion. We can d

Re: [arch-dev-public] providing grsecurity in [community]

Am 16.04.2014 12:21, schrieb Allan McRae: >>> Just submitted a patch to pacman that will allow setting capabilites in >>> the package() function. >> >> Since we want PAX support to remain optional, we'd still need hooks so >> that after each upgrade, a script can adjust the flags appropriately. >

Re: [arch-dev-public] providing grsecurity in [community]

Am 16.04.2014 11:52, schrieb Allan McRae: > On 16/04/14 17:25, Daniel Micay wrote: >> On 16/04/14 03:15 AM, Daniel Micay wrote: >>> Pacman hooks would >>> be a nicer solution than editing all the install scripts, but we don't >>> have those :). >> >> It also wouldn't be nearly as bad if packages co

Re: [arch-dev-public] CFLAGS changes with gcc-4.9

Am 12.04.2014 09:22, schrieb Allan McRae: > Hi all, > > gcc-4.9 is due to be released on the 22nd. This brings a new stack > protection flag, -fstack-protector-strong. See this blog post for some > details [1]. > > I would like to do two things with the release of gcc-4.9: > 1) Add -fstack-prot

[arch-dev-public] Linux 3.14-4 to [core]

I am currently uploading Linux 3.14-4 to [testing]. Once signoffs are done, I am planning to move this version to [core]. I'll also move util-linux and coreutils with it. There were no major new bugs I can remember that we didn't fix, so things should be pretty smooth. signature.asc Descriptio

Re: [arch-dev-public] Linux 3.14 in [testing]

Am 03.04.2014 12:33, schrieb Massimiliano Torromeo: > In data mercoledì 2 aprile 2014 00:44:42, Thomas Bächler ha scritto: >> The community/rt3562sta did not build. I am not interested in fixing >> this crap, so either its maintainer takes care of it shortly, or I'll >>

Re: [arch-dev-public] Linux 3.14 in [testing]

Am 03.04.2014 05:24, schrieb Evangelos Foutras: > On 2 April 2014 01:20, Thomas Bächler wrote: >> It may be another short while until I run db-update, but I started >> pushing the 3.14 stuff to [testing]. > > Has anyone else experienced hangs in Firefox with the latest ker

Re: [arch-dev-public] Linux 3.14 in [testing]

Am 02.04.2014 16:00, schrieb Dave Reisner: >> For 2), I don't see a fix upstream. It looks like a similar issue - >> apparently, st_dev for rootfs no longer has major 0 and minor 1 - maybe >> this also changed to 0? >> > > Seems you're right: > > [rootfs /]# cat /proc/self/mountinfo > 0 0 0:0 / /

Re: [arch-dev-public] Linux 3.14 in [testing]

Am 02.04.2014 13:17, schrieb Dave Reisner: > On Apr 2, 2014 5:56 AM, "Thomas Bächler" wrote: >> >> Am 02.04.2014 00:44, schrieb Thomas Bächler: >>> Am 02.04.2014 00:20, schrieb Thomas Bächler: >>>> It may be another short while until I run db-update

Re: [arch-dev-public] Linux 3.14 in [testing]

Am 02.04.2014 00:44, schrieb Thomas Bächler: > Am 02.04.2014 00:20, schrieb Thomas Bächler: >> It may be another short while until I run db-update, but I started >> pushing the 3.14 stuff to [testing]. > > Okay, pushed everything to [testing] and [community-testing]. Okay, s

Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

Am 01.04.2014 16:44, schrieb Thomas Bächler: > Am 29.03.2014 08:52, schrieb Thomas Bächler: >> Am 28.03.2014 22:26, schrieb Thomas Bächler: >>> Am 28.03.2014 01:01, schrieb Thomas Bächler: >>>> core/logrotate 3.8.7-1 /etc/cron.daily/logrotate >>>

Re: [arch-dev-public] Linux 3.14 in [testing]

Am 02.04.2014 00:20, schrieb Thomas Bächler: > It may be another short while until I run db-update, but I started > pushing the 3.14 stuff to [testing]. Okay, pushed everything to [testing] and [community-testing]. The community/rt3562sta did not build. I am not interested in fixing thi

[arch-dev-public] Linux 3.14 in [testing]

It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing]. This release brings some changes to the configuration. * Disabled LSMs There was a long discussion about it, but in the end there were some concerns and I do not see the point in supporting a f

[arch-dev-public] Drop cronie and logrotate from base?

The other day, Daniel Micary suggested dropping these packages from base (potentially even moving them to extra). * cronie Nothing in our default installation uses it anymore and it was disabled by default since we switched to systemd. Only a small percentage of our users actually use crontabs ac

Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

Am 29.03.2014 08:52, schrieb Thomas Bächler: > Am 28.03.2014 22:26, schrieb Thomas Bächler: >> Am 28.03.2014 01:01, schrieb Thomas Bächler: >>> core/logrotate 3.8.7-1 /etc/cron.daily/logrotate >>> core/man-db 2.6.6-1 /etc/cron.daily/man

Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

Am 28.03.2014 22:26, schrieb Thomas Bächler: > Am 28.03.2014 01:01, schrieb Thomas Bächler: >> core/logrotate 3.8.7-1 /etc/cron.daily/logrotate >> core/man-db 2.6.6-1 /etc/cron.daily/man-db >> core/mlocate 0.26-1 /etc/cron.daily/updatedb >

Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

Am 29.03.2014 01:31, schrieb Gerardo Exequiel Pozzi: > I guess for man-db should be better use tmpfiles instead of mkdir in the > service unit. The old cron.d script had the mkdir call inside with a comment that the directory should be recreated in case of deletion. I guess having it inside the se

Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

Am 28.03.2014 01:01, schrieb Thomas Bächler: > core/logrotate 3.8.7-1 /etc/cron.daily/logrotate > core/man-db 2.6.6-1 /etc/cron.daily/man-db > core/mlocate 0.26-1 /etc/cron.daily/updatedb > core/shadow 4.1.5.1-7 /etc/cron.daily/shadow > ext

Re: [arch-dev-public] Trimming down our default kernel configuration

Am 28.03.2014 06:25, schrieb Connor Behan: > On 27/03/14 08:24 AM, tho...@archlinux.org wrote: >> Am 27.03.2014 09:52, schrieb Connor Behan: >>> On 27/03/14 01:07 AM, tho...@archlinux.org wrote: Am 26.03.2014 20:08, schrieb Dave Reisner: > Looks like audit is still built into our kernel. W

[arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron: Persistent= Takes a boolean argument. If true the service unit is immediately triggered when the timer unit is activated and the timer elapsed at least

Re: [arch-dev-public] nvidia 334.21-3 / nvidia-lts 334.21-4 pulled from [testing]

Am 27.03.2014 16:02, schrieb Felix Yan: > Hi all, > > The nvidia-modprobe binary was provided in the "nvidia" / "nvidia-lts" > packages, but this doesn't work well because the two packages should not be > prevented from installing together. > > To fix this, I've pulled the two packages from [te

Re: [arch-dev-public] Trimming down our default kernel configuration

Am 27.03.2014 09:52, schrieb Connor Behan: > On 27/03/14 01:07 AM, tho...@archlinux.org wrote: >> Am 26.03.2014 20:08, schrieb Dave Reisner: >>> Looks like audit is still built into our kernel. Wasn't this meant to be >>> reverted as well? >> Forgot about that. That was pulled in by AppArmor or so.

Re: [arch-dev-public] Trimming down our default kernel configuration

Am 26.03.2014 20:08, schrieb Dave Reisner: > Looks like audit is still built into our kernel. Wasn't this meant to be > reverted as well? Forgot about that. That was pulled in by AppArmor or so. signature.asc Description: OpenPGP digital signature

[arch-dev-public] Trimming down our default kernel configuration

Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on e

Re: [arch-dev-public] [RFC] Add ARM to archlinux.org

Am 24.03.2014 23:35, schrieb Sébastien Luttringer: > Hello, > > As you may know I'm running ARM[1] since the last maintainer resign in > August 2013. I would like to propose its addition into our official > services. As a side not, may I point out that the name 'ARM' is poorly chosen for this ser

Re: [arch-dev-public] brynhild down a.k.a pkgbuild.com

Am 22.03.2014 18:21, schrieb Florian Pritz: > On 22.03.2014 18:15, Ionuț Bîru wrote: >> You guys mentioned that ecc it's a must. They have ex60 now with 32gb with >> intel xeon. for 69€/mo and for an additional ip we can have ipmi access as >> well but setup is 99€ > > PX60 not EX60. The necessary

Re: [arch-dev-public] Integrity Check x86_64: core, extra, community, multilib 21-03-2014

Am 21.03.2014 16:14, schrieb repoma...@archlinux.org: > Repo Hierarchy for Dependencies > - > core/gettext depends on extra/libunistring (439 extra (make)deps to pull) > core/make depends on extra/guile (439 extra (make)deps to pull) > core/systemd depends on extra/l

Re: [arch-dev-public] Cyclic dependencies between systemd and util-linux

Am 12.03.2014 06:32, schrieb Gerardo Exequiel Pozzi: > On 02/24/2014 03:56 PM, Thomas Bächler wrote: >> Right now, we have a problem with cyclic dependencies in core: systemd >> requires libblkid and libuuid (systemd-udevd) and util-linux requires >> libudev (findmnt, and soo

Re: [arch-dev-public] Cyclic dependencies between systemd and util-linux

Am 12.03.2014 17:21, schrieb Tobias Powalowski: > Am 12.03.2014 06:32, schrieb Gerardo Exequiel Pozzi: >> On 02/24/2014 03:56 PM, Thomas Bächler wrote: >>> Right now, we have a problem with cyclic dependencies in core: systemd >>> requires libblkid and libuuid (sy

Re: [arch-dev-public] Cyclic dependencies between systemd and util-linux

Am 12.03.2014 04:07, schrieb Dave Reisner: >> As discussed on IRC, this is only going to be a runtime split. >> libutil-linux will only contain the dynamic libs for libuuid, libblkid, >> and libmount. Similar for systemd -- libsystemd, libudev, and the compat >> libs. >> > > Much to my dismay, thi

Re: [arch-dev-public] Cyclic dependencies between systemd and util-linux

Am 24.02.2014 23:05, schrieb Thomas Bächler: > Am 24.02.2014 20:18, schrieb Dave Reisner: >> On Mon, Feb 24, 2014 at 07:56:56PM +0100, Thomas Bächler wrote: >>> Right now, we have a problem with cyclic dependencies in core: systemd >>> requires libblkid and libuuid (sy

Re: [arch-dev-public] Cyclic dependencies between systemd and util-linux

Am 24.02.2014 20:18, schrieb Dave Reisner: > On Mon, Feb 24, 2014 at 07:56:56PM +0100, Thomas Bächler wrote: >> Right now, we have a problem with cyclic dependencies in core: systemd >> requires libblkid and libuuid (systemd-udevd) and util-linux requires >> libudev (findm

[arch-dev-public] Cyclic dependencies between systemd and util-linux

Right now, we have a problem with cyclic dependencies in core: systemd requires libblkid and libuuid (systemd-udevd) and util-linux requires libudev (findmnt, and soon uuidd [1]). I don't like this situation and currently it is revoled by adding systemd as optdepend to util-linux. This has the sid

Re: [arch-dev-public] [arch-general] ppp 2.4.6 in testing breaks pptp connections in NetworkManager

Am 23.02.2014 12:53, schrieb Arthur Țițeică: > I've seen these issues but I didn't have enough time to come to a sane > conclusion in order to report it. > > IIRC rp-pppoe in core has the same problem. > > pppd[27117]: Plugin /usr/lib/rp-pppoe/rp-pppoe.so is for pppd version 2.4.5, > this is 2.

Re: [arch-dev-public] [arch-general] ppp 2.4.6 in testing breaks pptp connections in NetworkManager

Am 23.02.2014 08:42, schrieb Savyasachee Jha: > Whenever I try connecting to my university's VPN, the authentication fails. > Running systemctl status NetworkManager gives me the message: > > Feb 23 16:06:06 Empire NetworkManager[285]: Starting VPN service > 'pptp'... > Feb 23 16:06:06 Empire N

Re: [arch-dev-public] systemd 209 in [testing]

Am 20.02.2014 17:33, schrieb Dave Reisner: > Hi all, > > I'm working on packaging the systemd 209 release, and I expect to have > pkgrel=1 into [testing] in a few hours, barring any unforseen problems. > It's a huge release (nearly 2000 commits since 208), and I don't > anticipate that this will m

Re: [arch-dev-public] Linux 3.13 status

Am 21.02.2014 08:43, schrieb Pierre Schmitz: > Am 20.02.2014 20:32, schrieb Thomas Bächler: >> $ dmesg -t | grep ^i8042 > > This needs to be in quotes (at least on zsh): > $ dmesg -t | grep '^i8042' In bash it doesn't, but I'll add it. sign

Re: [arch-dev-public] Linux 3.13 status

Am 20.02.2014 23:36, schrieb Gaetan Bisson: > [2014-02-20 20:32:54 +0100] Thomas Bächler: >> $ dmesg -t | grep ^i8042 >> i8042: PNP: No PS/2 controller found. Probing ports directly. > > One of my machines says: > > i8042: PNP: No PS/2 controller fo

[arch-dev-public] Linux 3.13 status

Okay, it's been way too long. I don't really have the time to spend much time on the kernel right now, and neither does Tobias, so it's been sitting in [testing] for way too long. I am currently building 3.13.3-2 with a critical NFS fix and I intend to move that kernel to [core] very soon. Due to

Re: [arch-dev-public] systemd 209 in [testing]

Am 20.02.2014 18:13, schrieb Dave Reisner: >> Can't we simply do a rebuild (if needed), disable the compat libraries >> but keep providing the compat .pc files for a while? > > We would need to hack up the .pc files to use -lsystemd instead of > whatever they provide, and then rebuild. They do th

Re: [arch-dev-public] systemd 209 in [testing]

Am 20.02.2014 17:33, schrieb Dave Reisner: > - libsystemd-{login,journal,daemon,etc}.so are deprecated, and the > symbols have been merged into a singular libsystemd.so. You'll still > see the legacy library names, but they're now just a bunch of IFUNC > symbols. Please raise up any build pro

Re: [arch-dev-public] 3.13 packages in testing

Am 26.01.2014 19:37, schrieb Tom Gundersen: >> So, should we just apply the patch and leave it as a module, or should >> we make it built-in again and close >> https://bugs.archlinux.org/task/27555 as "Won't fix"? > > So I'm obviously biased, but I'd prefer if we kept this as a module. > Given the

Re: [arch-dev-public] 3.13 packages in testing

Am 26.01.2014 19:37, schrieb Tom Gundersen: > Hm, this sucks a bit, as the manual probing (at least in my tests) > will delay boot quite significantly. I was told that the manual > probing stuff was not really relevant anymore, but if you are running > into it that info seems dubious. This is a bl

Re: [arch-dev-public] 3.13 packages in testing

Am 26.01.2014 18:54, schrieb Thomas Bächler: > Am 26.01.2014 13:56, schrieb Tom Gundersen: >> On Sun, Jan 26, 2014 at 12:41 PM, Thomas Bächler >> wrote: >>> One major change is coming (and Tom will be happy about it): Keyboard >>> support is entirely modular, ev

Re: [arch-dev-public] 3.13 packages in testing

Am 26.01.2014 13:56, schrieb Tom Gundersen: > On Sun, Jan 26, 2014 at 12:41 PM, Thomas Bächler wrote: >> One major change is coming (and Tom will be happy about it): Keyboard >> support is entirely modular, even for AT(PS/2) keyboards. Beware that in >> order to have keyboa

Re: [arch-dev-public] 3.13 packages in testing

Am 26.01.2014 12:41, schrieb Thomas Bächler: > The community packages bbswitch, r8168, rt3562sta, tp_smapi, > vhba-module, virtualbox-guest-modules and virtualbox-host-modules still > need a rebuild, I like won't get to it now. The respective maintainers > should update the

[arch-dev-public] 3.13 packages in testing

I am now starting to push Linux 3.13 to testing. This has taken a bit, since i686 refused to boot at all, and the actual cause of the problem is still a mystery to me. Anyway, I found a semi-permanent workaround. For more information, please see [1] and the discussion that will hopefully follow. I

Re: [arch-dev-public] libaacs - suitable for [community]?

Am 07.01.2014 16:53, schrieb Martin Wimpress: > Hi, > > One of the packages I'd like to move from the AUR to [community] is > `libaacs` [1]. I think is suitable because I see that `libdvdcss` is in > [extra]. > > But after a chat in #archlinux-tu I was suggested that I should check > here first.

Re: [arch-dev-public] [HEADSUP] Arch boot splash

Am 22.12.2013 03:11, schrieb Gerardo Exequiel Pozzi: > Anyways, I am planning to replace gummiboot by syslinux in archiso. (but > this need some tests and feedback from people). Given the state of syslinux on EFI (fails to load some kernels entirely for some people) and its lack of features (canno

[arch-dev-public] HEADSUP: mkinitcpio and shutdown

The new mkinitcpio 16 (yes, we bumped from 0.15 to 16) in testing contains a new feature that automatically generates an "initramfs" on shutdown. systemd will pivot to this image on shutdown. All it does is re-run systemd-shutdown in a ramdisk, thus allowing a proper umount of / and proper shutdown

Re: [arch-dev-public] core repo build report 2013-12-12

Am 12.12.2013 13:14, schrieb Allan McRae: > FAILxinetd > ==> ERROR: Failure while downloading xinetd-2.3.15.tar.gz Shouldn't we move xinetd to [extra]? Nowadays, systemd covers the most common use cases, if not all of them. I replaced xinetd with systemd sockets on all machines I use. sign

Re: [arch-dev-public] Dropping sysvinit-tools

Am 09.12.2013 08:31, schrieb Gaetan Bisson: > [2013-12-06 07:04:54 -1000] Gaetan Bisson: >> [2013-10-26 12:29:42 -0400] Dave Reisner: >>> I'm open to arguments against this, but I suggest we drop sysvinit-tools >>> after pidof is part of a release from procps-ng. >> >> Let's do that once procps-ng-

Re: [arch-dev-public] Fwd: The Final Cleanup

Am 06.12.2013 18:20, schrieb Alexander Rødseth: > * Arch Linux has vanilla packages, so we should try to avoid including > files that are hand-crafted by packagers If the files are needed, we include them. It's that simple. > * It clutters the repository One or two extra files per package is not

Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)

Am 27.11.2013 14:57, schrieb Alexander Rødseth: > A bit sad to be starting out the new docker package with "the mark of > shame" (epoch=1), but so be it. ;) > > Summary / suggsted plan: > 1. Rename docker (the old one) to docker-tray and add replaces=('docker=1.5') Shouldn't that be 'docker<=1.5'

Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)

Am 27.11.2013 11:29, schrieb Allan McRae: > Please don't do this... 11 line output in post_install. If you > REALLY need this, use a single line pointing to the wiki page. > > Allan Usage instructions generally don't belong into install/upgrade messages. In the best case, there is no message

Re: [arch-dev-public] Dropping sysvinit-tools

Am 26.10.2013 18:29, schrieb Dave Reisner: > fstab-decode We never used this anywhere. > killall5 This was only ever used in initscripts and its functionality has been obsoleted by systemd-shutdown. > bootlogd. Obsoleted by the journal and the existence of /run. Logging what's printed on the s

Re: [arch-dev-public] Orphaning Wireshark

Am 18.10.2013 10:46, schrieb Timothy M. Redaelli: > On 06/25/2013 08:55 PM, Guillaume ALAUX wrote: >> Hi everyone, >> >> As the title says, I am going to orphan Wireshark. I do not use it on >> a regular basis which makes it complicated for me to make decisions on >> whether to implement this or th

Re: [arch-dev-public] Orphans

Am 30.09.2013 04:54, schrieb Xyne: > Xyne wrote: > >> On 2013-09-29 21:03 +0200 >> Alexander Rødseth wrote: >> >>> bchunk >>> cmus >>> fdupes > > These are updated and waiting in my staging directory on Nymeria. My new > signing key hasn't been added to the keyring on the server yet, so I can't

[arch-dev-public] IMPORTANT: New procedures regarding PGP key signatures

In order to organize the keyring management better, we will now follow new procedures for managing signatures: ADDING A NEW KEY: Whenever a new developer or TU joins the team, the developer responsible for adding him/her or the TU sponsor (whatever is appropriate) has to open a new task with the

Re: [arch-dev-public] Account removal for Daenyth

Am 28.09.2013 11:57, schrieb Florian Pritz: > Daenyth resigned on 27 Aug 2013 via Mail to Lukas with the subject "Re : > TU Votes -- Reminder!". Apparently this has been missed so his accounts > are still marked TU in the bbs and archweb and he is still listed as > maintainer for 35 packages in arc

Re: [arch-dev-public] Dropping mplayer2

Am 28.09.2013 00:52, schrieb Jan Alexander Steffens: > Neither mplayer2 nor mpv seem to support vaapi output. mpv depends on > libva, but does not link against it. Actually, mpv-git works just fine with libva. signature.asc Description: OpenPGP digital signature

Re: [arch-dev-public] arch bootstrapping

Am 19.08.2013 21:05, schrieb Zbigniew Jędrzejewski-Szmek: >> Now to do the --populate archlinux, you need to have an archlinux >> keyring in /usr/share/pacman/keyrings/. If you look at the >> `archlinux-keyring` package in arch, that should give you some ideas. > So, I've created a simple archlinux

Re: [arch-dev-public] nvidia-304 packages

Am 19.08.2013 19:35, schrieb Andreas Radke: > I don't have a Nvidia card anymore. I've done a final untested bump to > 304.108 to testing. I'm orphaning nvidia-304-utils and both kernel > modules now. > > If nobody will pick them up we should move them to community or AUR. All I can say on the ma

Re: [arch-dev-public] arch bootstrapping

Am 17.08.2013 17:27, schrieb Zbigniew Jędrzejewski-Szmek: > Hi, > > I was trying to get the arch installation example in systemd-spawn > to work on Fedora. My intent is to package pacman and pacstrap for > Fedora, to make it easy to play with distributions. Fedora already > has alien and dpkg/apt-

Re: [arch-dev-public] Warning: remove /dev/pts from /etc/fstab - glibc-2.18 update

Am 15.08.2013 14:06, schrieb Allan McRae: > Hi all, > > The update to glibc-2.18 removes pt_chown which is a security risk. It > is not needed on an Arch system given we have /dev/pts. > > However, some people appear to have /dev/pts in their /etc/fstab file, > which generates it with the wrong

Re: [arch-dev-public] [HEADSUP] util-linux deprecating sysvinit-tools

Am 13.08.2013 16:06, schrieb Thomas Bächler: > Am 13.08.2013 15:59, schrieb Tom Gundersen: >> Hi guys, >> >> As you can see below, util-linux-24 will contain most of the tools >> from sysvinit-tools. I therefore intend to propose that we drop >> sysvinit-tools on

Re: [arch-dev-public] [HEADSUP] util-linux deprecating sysvinit-tools

Am 13.08.2013 15:59, schrieb Tom Gundersen: > Hi guys, > > As you can see below, util-linux-24 will contain most of the tools > from sysvinit-tools. I therefore intend to propose that we drop > sysvinit-tools once util-linux-24 is out. > > If anyone have any objections or concerns, this would be

Re: [arch-dev-public] The next LTS

Am 05.08.2013 21:16, schrieb Rémy Oudompheng: > Would it be a good idea to switch to 3.2 now until October? Linux 3.2 > is used by Debian 7 and is definitely widely tested by a lot of > people. The plan for the LTS kernel is to avoid frequent major upgrades. We've stayed with 3.0 for about 2 years

Re: [arch-dev-public] The next LTS

Am 04.08.2013 14:37, schrieb Tom Gundersen: > Hi, > > In case someone missed it, Greg just announced that 3.10 will be the > next LTS kernel [0]. > > It might make sense to bump linux-lts to 3.10 shortly after linux-3.11 > moves to [core]. What do you think? > > -t > > [0]:

Re: [arch-dev-public] linux-3.10.2-1 in [testing], still broken community modules

Am 22.07.2013 17:01, schrieb Thomas Bächler: > Am 22.07.2013 16:47, schrieb Tobias Powalowski: >> Hi, >> I built the kernel, now there are issues with following >> - community binary modules: >> cdfs >> ndiswrapper >> open-vm-tools-modules >> &g

[arch-dev-public] rc.d files, unmaintained packages - and the quality of our repositories

So, I understand that some people did not want to rebuild their packages just for the removal of the rc.d files. The "next rebuild" will come eventually. Now, adding new packages to the repositories with rc.d files in them is a different story: $ pkgfile -vr ^/etc/rc.d extra/ntp 4.2.6.p5-14 /etc

Re: [arch-dev-public] linux-3.10-1 in [staging], still broken community modules

Am 04.07.2013 12:23, schrieb Tobias Powalowski: > Hi, > I built the kernel, now there are issues with following > - community binary modules: > cdfs > ndiswrapper > open-vm-tools-modules > > Please find patches and fix those, 3.10 will move to [testing] when > 3.9.9 leaves. > > Please repor

Re: [arch-dev-public] Bootstrap images for installing Arch from another system

Am 28.06.2013 20:02, schrieb Thomas Bächler: > Am 22.06.2013 21:19, schrieb Pierre Schmitz: >>>> I'd say we include this script into the releng scripts (either archiso >>>> or create a nwe package; atm I use some additional script for releasing >>>> an

  1   2   3   4   5   6   7   8   9   10   >