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

[Thomas Bächler via arch-dev-public]

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 CEO
> of Microsoft.
> 
> They even implemented a subsystem on Windows 10 for executing natively
> ELF binaries on Windows. This system is based on docker images and some
> nice guys from Microsoft have asked Allan and me if Arch Linux would be
> interested to participate in this project.
> 
> The steps for getting into the project are:
> 
> * Signup in the Microsoft Appstore (we would get a free voucher if we
>   want to participate) as Organization (we need the ok from one of our
>   trademark holders for this step)
> * modifying our docker container a little bit
> * pushing it into the microsoft appstore
> 
> So what do you think? Should we participate in that project?
> 
> Here are some pros and contras:
> 
> pro:
> - CentOS and Ubuntu are there too
> - Would be a nice chance to increase the awareness about Arch Linux
> - might get people to change from Windows to Arch Linux (or linux in
>   general)
> - Nice way to test our docker image in production
> - People who are forced to work on windows at work can use Arch
>   Linux at work as well
> - More bugreports / feedback / forum activity?
> 
> contras:
> - Microsoft is Microsoft (I think I don't need to explain)
> - More Newbies?
> - Somebody would need to maintain it (I would do it)
> - If Arch Linux partnerships with Microsoft could lead into bad image?
> 

I'd like to give some feedback too. Personally, I love WSL, since I am
stuck with Windows 10 at work and it gives me certain applications I
otherwise don't have.

AFAIK, with the "Fall Creators Update" Version, they updated WSL to only
be available via the appstore and as far as I can see, this makes
installing Arch via other means significantly more difficult.

Right now, I only have experience with the version before the fall
creators update, and that has issues:

* As others mentioned, some glibc functionality relies on certain
clone() flags that WSL did/does not support.
* pacman needs an LD_PRELOAD hack since it insists on using chroot even
without a --root option, but WSL does/did not have chroot.

I would hope they fixed these problems by now, but I did not check yet.

I personally would love to see an official WSL Arch image, since it's
very useful to me. That said, I don't like the way they promote WSL,
because it is Linux the way that wine is Windows (read: it isn't).



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] FrOSCon 2017

[Thomas Bächler]

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 book an project room for us. It would be
>> awesome if we can get a room and work on some of our (bigger) projects
>> for example:
>>
>> * archweb
>> * auto staging-rebuild system
>> * dbscripts
>> * reproducible builds
>> * security tracker
>> * 32 bit deprecation :)
>>
>> The date and location for FrOSCon is:
>>
>> 19. + 20. August 2017
>> Hochschule Bonn-Rhein-Sieg
>> https://www.froscon.de/en/faq/
>>
> 
> Bonn is about 8 hours away by train from me so I'm not really eager to
> travel that long. Please either stream the meeting or send some notes
> after to arch-dev-public.
> 
> Bartłomiej

With the heavy bandwidth usage at FrOSCon, streaming is out of the question.

If we have a room again, I want to have a series of talks this time, and
announce it in time so that it appears in the FrOSCon program.





signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 using signatures.

However, I agree that asking every single author to provide signatures
is likely infeasible.

> and some of them will likely not be interested in doing such
> a thing.

Having no interest in signing your work is surely a bad sign. Maybe we
should look into dropping such software where we can.

> If an upstream won't provide PGP signatures, do you have
> another suggestion as to how we can secure our process of obtaining
> upstream sources in a reliable manner?

You can't.

We could mirror the sources and sign them ourselves, but that would
require that we actually audit the sources somehow.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 to write the list down, but I'll try to reproduce it from the
list of orphan packages (many had a second maintainer, so they're not
orphan now):

bftpd
lib32-v4l-utils
linux-firmware
mkinitcpio-busybox
mkinitcpio-nfs-utils
ppp
v4l-utils
watchdog
wpa_actiond
wpa_supplicant_gui




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 thought to myself that I'll return to packaging
very soon. The reality is that this won't happen. This is a hard step
for me, but I have to be honest to my fellow Arch Developers, the users
and most importantly, to myself.

Just a moment ago, I orphaned all my packages except for joe and ovmf,
which I plan on taking care of for now, since they'll certainly be
dropped from the repos if I don't (I think I can handle two packages).
For the time being, I won't be taking any new packages. I'll also see if
I can unsubscribe from all bug reports.

However, I am not gone completely:

* I will still keep my Arch Linux package signing master key and take
care of signing and revoking developer and trusted user keys.
* I will keep an eye on release engineering and espeically the new
netboot system I just set up recently.
* I will always remain available to you all via this list, the private
dev list, IRC, XMPP and e-mail for advice and help.

My heart beats for Arch and its community and I doubt that will ever
change. I am sorry that I let you guys down. Facing this sad reality is
a first step towards improving this, and I certainly hope that at some
point, I will return to a more active role.

Best regards
Thomas



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

The following changes since commit 042763555885986a64c06e340b98da595f27d0e1:

  Add netboot ipxe environment to archweb (2016-05-26 05:26:37 +)

are available in the git repository at:

  https://github.com/brain0/archweb working

for you to fetch changes up to 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 by default
  Remove AirVM ads since AirVM has ended their sponsorship

 public/views.py  |   2 --
 releng/urls.py   |   3 ++-
 releng/views.py  |   3 +++
 settings.py  |   3 ---
 sitestatic/airvm_button.png  | Bin 4931 -> 0 bytes
 sitestatic/netboot/ipxe.efi  | Bin 0 -> 929120 bytes
 sitestatic/netboot/ipxe.efi.sig  | Bin 0 -> 543 bytes
 sitestatic/netboot/ipxe.lkrn | Bin 0 -> 336027 bytes
 sitestatic/netboot/ipxe.lkrn.sig | Bin 0 -> 543 bytes
 sitestatic/netboot/ipxe.pxe  | Bin 0 -> 336695 bytes
 sitestatic/netboot/ipxe.pxe.sig  | Bin 0 -> 543 bytes
 templates/public/donate.html |   7 ---
 templates/public/download.html   |   4 ++--
 templates/public/index.html  |   3 ---
 templates/releng/archlinux.ipxe  |   2 +-
 templates/releng/netboot.html|  54
++
 16 files changed, 62 insertions(+), 19 deletions(-)
 delete mode 100644 sitestatic/airvm_button.png
 create mode 100644 sitestatic/netboot/ipxe.efi
 create mode 100644 sitestatic/netboot/ipxe.efi.sig
 create mode 100644 sitestatic/netboot/ipxe.lkrn
 create mode 100644 sitestatic/netboot/ipxe.lkrn.sig
 create mode 100644 sitestatic/netboot/ipxe.pxe
 create mode 100644 sitestatic/netboot/ipxe.pxe.sig
 create mode 100644 templates/releng/netboot.html



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

---

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 configuration. Once this patch is live, I will 
provide test images
and start working on instructions for the website.

Highlights of this new feature:
* Uses release and mirror data from archweb
* Comfortable configuration of version, architecture, mirror and boot options 
via
  ipxe menu.
* Complete signature verification: With the proper ipxe image, the signature
  of the kernel and initramfs files is verified. Then the kernel is booted
  and archiso verifies the signature of the squashfs image.


 releng/urls.py  |   5 ++
 releng/views.py |  21 +-
 templates/releng/archlinux.ipxe | 157 
 3 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 templates/releng/archlinux.ipxe

diff --git a/releng/urls.py b/releng/urls.py
index ca76eb2..0e87de4 100644
--- a/releng/urls.py
+++ b/releng/urls.py
@@ -22,9 +22,14 @@
 'release_torrent', {}, 'releng-release-torrent'),
 )
 
+netboot_patterns = patterns('releng.views',
+(r'^archlinux\.ipxe$', 'netboot_config', {}, 'releng-netboot-config')
+)
+
 urlpatterns = patterns('',
 (r'^feedback/', include(feedback_patterns)),
 (r'^releases/', include(releases_patterns)),
+(r'^netboot/', include(netboot_patterns)),
 )
 
 # vim: set ts=4 sw=4 et:
diff --git a/releng/views.py b/releng/views.py
index dbb65c2..7db469c 100644
--- a/releng/views.py
+++ b/releng/views.py
@@ -13,7 +13,7 @@
 from .models import (Architecture, BootType, Bootloader, ClockChoice,
 Filesystem, HardwareType, InstallType, Iso, IsoType, Module, Source,
 Test, Release)
-
+from mirrors.models import (Mirror, MirrorUrl, MirrorProtocol)
 
 def standard_field(model, empty_label=None, help_text=None, required=True):
 return forms.ModelChoiceField(queryset=model.objects.all(),
@@ -280,4 +280,23 @@ def releases_json(request):
 response = HttpResponse(to_json, content_type='application/json')
 return response
 
+def netboot_config(request):
+release_qs = 
Release.objects.filter(available=True).order_by('-release_date')
+releases = [ release.version for release in release_qs ]
+mirrorurls = MirrorUrl.objects.filter(protocol__protocol='http',
+  active=True,
+  mirror__public=True,
+  mirror__active=True,
+  mirror__isos=True)
+mirrorurls = sorted( mirrorurls,
+ key=lambda x: x.mirror.name)
+mirrorurls = sorted( mirrorurls,
+ key=lambda x: x.country.name)
+context = {
+'archs': [ 'i686', 'x86_64' ],
+'releases': releases,
+'mirrorurls': mirrorurls,
+}
+return render(request, "releng/archlinux.ipxe", context, 
content_type='text/plain')
+
 # vim: set ts=4 sw=4 et:
diff --git a/templates/releng/archlinux.ipxe b/templates/releng/archlinux.ipxe
new file mode 100644
index 000..87f9c83
--- /dev/null
+++ b/templates/releng/archlinux.ipxe
@@ -0,0 +1,157 @@
+#!ipxe
+{% regroup mirrorurls by country as mirrors_by_country %}
+
+# Figure out if client is 64-bit capable
+cpuid --ext 29 && set cpuarch x86_64 || set cpuarch i686
+
+# allow only trusted images
+imgtrust
+
+# initial options
+set bootarch ${cpuarch}
+set release {{ releases.0 }}
+set mirrorurl
+set extrabootoptions ip=dhcp
+set countrycode
+
+:main
+menu Arch Linux Netboot
+item --gap Settings
+item set_architecture Architecture: ${bootarch}
+item set_release Release: ${release}
+isset ${mirrorurl} && item set_mirror Mirror: ${mirrorurl} || item set_mirror 
Choose a mirror
+item set_options Boot options: ${extrabootoptions}
+item
+isset ${mirrorurl} && item boot Boot Arch Linux || item --gap Boot Arch Linux
+item shell Drop to iPXE shell
+item reboot Reboot
+item exit Exit iPXE
+isset ${mirrorurl} && choose --default set_options selected || choose 
--default set_mirror selected || goto shell
+goto ${selected} || goto main
+
+:shell
+echo Type 'exit' to get the back to the menu
+shell
+goto main
+
+:reboot
+reboot
+
+:exit
+exit
+
+:set_architecture
+menu Arch Linux Netboot: Select Architecture
+item back back
+item
+item --gap Available architectures:
+iseq ${cpuarch} x86_64 && item x86_64 x64_64 ||
+item i686 i686
+choose selected || goto main
+iseq ${selected} back && goto main ||
+set bootarch ${selected}
+goto main
+
+:set_release
+menu Arch Linux Netboot: Select Release
+item back back
+item
+item --gap Available releases:
+{% for release in releases %}item {{ release }} {{ release }}
+{% endfor %}
+choose selected || goto main
+iseq ${selected} back && goto main ||
+se

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

[Thomas Bächler]

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 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 seems to be a bad idea.
>>>
>>> I already pushed the packages into staging. We would need to do the
>>> rebuild as quickly as possible.
>>>
>>> What do you think?
>> Last time an ABI change happened during a release cycle, it was a bug in
>> OpenSSL and the next release fixed it. Don't you think this is the case
>> again?
> 
> Hum, I don’t think so. Because last time was previous release last
> month, and it has not been “fixed” on OpenSSL side:
> https://github.com/OpenSMTPD/OpenSMTPD/issues/650#issuecomment-178168966
> 
> And for this new release, it’s even in the Changelog:
> https://github.com/openssl/openssl/blob/902f3f50d051dfd6ebf009d352aaf581195caabf/NEWS
> https://github.com/openssl/openssl/blob/902f3f50d051dfd6ebf009d352aaf581195caabf/CHANGES

I see nothing in these files that suggest that there is an ABI
incompatibility.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 seems to be a bad idea.
> 
> I already pushed the packages into staging. We would need to do the
> rebuild as quickly as possible.
> 
> What do you think?

Last time an ABI change happened during a release cycle, it was a bug in
OpenSSL and the next release fixed it. Don't you think this is the case
again?




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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/ is user territory, we do not touch it, ever. We also do not
change any standard paths there. Big NAK.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 loss of the gpg private
key for me.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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).

There is also the question whether we want the room on Saturday, Sunday,
or both.

So, anyone who is interested to
 1) help watch the room
 2) give a talk
 3) hold a discussion panel
 4) bring hardware
 5) generally be there
 6) ...
should reply until Wednesday so we can respect FOSDEM's deadline.

Does anyone have contact to the ALRAM guys? Maybe one of them will be on
board. Or maybe there is another Arch-derivative that would join us?

[1] https://fosdem.org/2016/



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 am sorry, but I have been pretty much absent for almost half a year
now. Still looking to change that soon-ish. Anyway, I think we should
open up the devroom to make sort of a mini-Archcon there. Try to get
people to register for talks until the end of June and make a small track.

I am trying to be there, and I am also trying to think of a good topic
for a talk.

> Greetings,
> 
> Pierre
> 
>  Original Message 
> Subject: [arch-events] FrOSCon 2015
> Date: 21.05.2015 21:30
> From: Pierre Schmitz 
> To: Mailing list for Archlinux events 
> Reply-To: Arch Linux Events 
> 
> Hi all,
> 
> let's get started for this year. I went ahead and registered a Devroom
> as the deadline is approaching. I think we saw some nice potential last
> year in having our own track.
> 
> Now, who like's to give a talk or help hosting an event (including
> "hackathons" etc.)
> 
> If a booth is wanted as well we need to register asap; but we'll need a
> couple more staff on site then.
> 
> Btw, see http://www.froscon.de/startseite/ or
> http://www.froscon.de/en/home/
> 
> Greetings,
> 
> Pierre
> 




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 April:
> Pierre, Thomas, Dan, Ionut

I seem to have missed these mails. However, I cannot sign anything until
next week.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 keyholders, so adding/remove devs/TUs is
> working fine.  But it is time to consider rotating in a new master key
> holder.

Before you remove me, I've been sort of MIA for 3 weeks or so, and have
been a bit sick for the past week, but I'll take care of the outstanding
issues (Keyring, packages) in the next few days (please hit me if I don't).




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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/Microcode#Enabling_Intel_Microcode_Updates).



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 manually, though. Will the grub package be updated to
> handle this in /etc/grub.d/10_linux?

Did anything happen regarding grub?




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 manually, though. Will the grub package be updated to
> handle this in /etc/grub.d/10_linux?
> 

No idea how this should be handled in grub, since I don't use it.



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Changes to microcode updates

[Thomas Bächler]

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 almost two years ago ([1]). This means we need to build
microcode support into the kernel.

For Intel, the new intel-ucode package provides the file
/boot/intel-ucode.img which you can load as the first initrd image.
Intel users can follow the instructions at [2].

This is the result on one of my Haswell machines:

$ journalctl -b -o short-monotonic | grep updated\ early
[0.00] lije kernel: CPU0 microcode updated early to revision
0x1c, date = 2014-07-03
[0.091952] lije kernel: CPU1 microcode updated early to revision
0x1c, date = 2014-07-03
[0.112570] lije kernel: CPU2 microcode updated early to revision
0x1c, date = 2014-07-03
[0.133215] lije kernel: CPU3 microcode updated early to revision
0x1c, date = 2014-07-03


For AMD, a similar mechanism is available, but since I don't own an AMD
CPU, I cannot implement this. This causes problems, since the microcode
update is no longer triggered automatically on boot (since microcode is
no longer a module). If you want to update the AMD ucode, you probably
need to run
 echo > /sys/devices/system/cpu/microcode/reload
on boot. I hope someone with an AMD CPU will look into this.

I am releasing the following package version to testing right now with
these changes:
 * linux 3.17-2
 * linux-lts 3.14.21-2
 * intel-ucode 20140913-1

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/early-microcode.txt#
[2]
https://wiki.archlinux.org/index.php/Microcode#Enabling_Intel_Microcode_Updates



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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-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 probably trivial to fix. The patch simply removes the [Install]
>> sections from the .socket files and the PKGBUILD enables them
>> unconditionally.
> 
> lvm2_lvmetad_systemd_red_hat.socket.in has "WantedBy=sysinit.target" instead 
> of "WantedBy=sockets.target" (which is in the patch).

Okay, that was changed because I told them sockets.target isn't
sufficient. Regardless, we already add a static unit with
sysinit.target, so that install section should still go away.

> dm_event_systemd_red_hat.socket.in has added "RemoveOnStop=true"

Yes, that's a good addition.

> That's the two conflicts. Let me know if you think it is okay to push :)

Yes, it's probably fine.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 probably trivial to fix. The patch simply removes the [Install]
sections from the .socket files and the PKGBUILD enables them
unconditionally.

If they actually changed the systemd units, maybe I should do this
upgrade myself, this stuff is easy to break.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 version bump

* intel-ucode (flagged 26.06.) - easy version bump, finding the correct
download link requires a few minutes though

* linux (it seems Tobias is taking care of the 3.15 series again, so no
problem here)

* lvm2 (flagged 23.06.) - easy version bump (hopefully, sometimes it breaks)

* mkinitcpio-busybox (flagged 18.04.) - this is not urgent at all and
requires lots of testing in order to not break mkinitcpio. Since I don't
use it anymore (I use mkinitcpio with systemd), I lacked the motivation
to build this so far.

* v4l-utils / lib32-v4l-utils (flagged 01.07.) - easy version bump.

* wireless-regdb (already in testing, can probably be moved)

* wpa_supplicant + wpa_supplicant_gui (flagged 10.06.) - this should
stay in testing for a while, since it is so important and has so much
potential for subtle breakage. It also takes time to find out if the
build configuration needs to be adjusted.



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 get the
>> list to work. I'd like to change that so adding a new list is as easy as
>> just adding it via the mailman webui.
>>
> 
> I added arch-security through the webui - I don't remember needing to
> edit more...

When you added the list, it didn't work - you don't remember doing
anything because it was me who did it.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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, otherwise fsck.fat
will fail on every boot, and he/she will be unable to interact with the
EFI partition."

Failure to find fsck.fat does not prevent mounting at all.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 same as
> 'netstat -tulpen' yet way harder to read (tons of useless whitespace in
> there and 2 lines per listener).
> 
> I don't care about ifconfig too much, but other binaries in the package
> are still useful imho and should be kept so -1 for dropping to aur. I'm
> fine with dropping it from core though.

I feel exactly the same. I always install net-tools for netstat.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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
-pkgrel=1
+pkgrel=2
 pkgdesc="Gives a fake root environment, useful for building packages as
a non-privileged user"
 arch=('i686' 'x86_64')
 license=('GPL')
@@ -15,6 +15,11 @@
 
source=(http://ftp.debian.org/debian/pool/main/f/${pkgname}/${pkgname}_${pkgver}.orig.tar.bz2)
 md5sums=('9777a81d4d1878422447a1d0030c1f9f')

+prepare() {
+  cd "${srcdir}/${pkgname}-${pkgver}"
+  sed 's|^#ifdef HAVE_ACL_T$|#if 0|' -i libfakeroot.c wrapfunc.inp
+}
+
 build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure --prefix=/usr --libdir=/usr/lib/libfakeroot \

With this, fakeroot does everything as expected:

# getfattr -d -m - foo
# setcap cap_net_admin=p foo
# getfattr -d -m - foo
# file: foo
security.capability=0sAgAQAAA=

# getcap foo
foo = cap_net_admin+p
#
# getfattr -d -m - bar
# setfacl -m u:thomas:rw bar
# getfattr -d -m - bar
# file: bar
system.posix_acl_access=0sAgEABgD/AgAGAOgDAAAEAAQA/xAABgD/IAAEAP8=

# getfacl bar
# file: bar
# owner: thomas
# group: users
user::rw-
user:thomas:rw-
group::r--
mask::rw-
other::r--

Should I push this to testing?



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 deal with get/setfacl when fakeroot does
> properly.  Any chance you can take that upstream?

I don't really have the time now, maybe some time on the weekend. From
what I saw quickly, the solution is merely to remove all the function
overrides for the acl_* functions from libfakeroot.c. Unless you beat me
to it, I'll test this on the weekend.

> Also, I really thought setcap would be used in more install scripts!

It becomes really bad when upstream uses it in the Makefile (like
systemd does) and the maintainer does not add this it to the .install
manually.

But indeed, many more setuid binaries should make use of file
capabilities instead.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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.
> 
> Sure...   I really don't care about PAX (and think it should just be
> packaged in a separate repo...).  I just wanted pacman to support
> setting capabilities during packaging.

I am not sure that your patch will work at all due to limitations of
fakeroot. I just tested this shortly, and fakeroot supports setting file
capabilities using setcap, but not setting ACLs using setfacl.

So, support for extended attributes in fakeroot is incomplete at best.



A further look indicates that this may simply be stupidity on the side
of fakeroot: it explicitly hardcodes ENOTSUP for acl_{s,g}et_f{ile,d},
while the now implemented f{s,g}etxattr support should be sufficient in
order to support ACLs entirely. I guess these acl overrides are remnants
of the days when xattr support was missing.

Anyway, we need to fix fakeroot before this makepkg feature can be useful.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 could store extended
>> attributes, since the ugly install scripts could be avoided and paxctl
>> would only be a make dependency. Packages like iputils already run into
>> this issue due to using capabilities as a replacement for setuid.
>>
> 
> 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.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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-protector-strong to our CFLAGS
> 2) Rebuild all [core] packages
> 
> The rebuild would not only add the extra stack protection, but also
> ensure all [core] packages have .MTREE files (which become more useful
> with the next pacman release, although still do not test checksums).

Don't they already have them?

> Any opinions on both of these points?

The kernel also has a new option
 CONFIG_CC_STACKPROTECTOR_STRONG
in 3.14. Obviously, this is currently disabled in our build.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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
Description: OpenPGP digital signature

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

[Thomas Bächler]

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
>> drop it when I move this out of testing.
> 
> Package fixed.

Much appreciated.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 kernel?

None that I can remember.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 / / rw - rootfs rootfs rw
> 14 0 0:2 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
> 15 0 0:13 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sys rw
> 16 0 0:4 / /dev rw,nosuid,relatime - devtmpfs dev 
> rw,size=508412k,nr_inodes=127103,mode=755
> 17 0 0:14 / /run rw,nosuid,nodev,relatime - tmpfs run rw,mode=755
> 
> I mentioned this to Karel on IRC and offered a few possible solutions

Did you mention that we could do what busybox does ([1]) and check with
statfs whether we are on either tmpfs or ramfs?

[1] http://git.busybox.net/busybox/tree/util-linux/switch_root.c#n100



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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, but I started
>>>> pushing the 3.14 stuff to [testing].
>>>
>>> Okay, pushed everything to [testing] and [community-testing].
>>
>> Okay, sent this to the wrong list at first.
>>
>> Two problems:
>>
>> 1) findmnt/libmount broken with 3.14 - fixing that now.
>> 2) util-linux/switch_root has problems (this seems like the same issue),
> 
> Crap. Forgot about this. It's already fixed upstream (thanks to an Arch
> user). I don't have a reference to the commit, but I can take care of this
> if you don't find it before me.
> 
>> see https://bbs.archlinux.org/viewtopic.php?pid=1399663

The commit for 1) was 6c373810f5b1d32824371e9dff6ee5a006388f98. This is
already applied in testing/util-linux.

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?



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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, sent this to the wrong list at first.

Two problems:

1) findmnt/libmount broken with 3.14 - fixing that now.
2) util-linux/switch_root has problems (this seems like the same issue),
see https://bbs.archlinux.org/viewtopic.php?pid=1399663



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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
>>>> 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
>>>> extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats
>>>
>>> After the overall positive response, I converted these. Since none of my
>>> machines used any cron jobs, I uninstalled cronie from them.
>>
>> I am not sure how this interacts with suspend. My laptop was suspended
>> at midnight, and on resume two of my timers fired, but 3 didn't. Maybe
>> this is because interaction with suspend is broken, mabe because of
>> AccuracySec set to 12h. I need to investigate this issue further.
> 
> *shrugs* Seems to work just fine now. All timers fired when I resumed at
> work today.

Okay, this should stay in testing for the moment.

There's a case where the persistent timer *never* run until your machine
is running just at the right moment. I prepared a patch for this
problem, just need to test and submit it tonight.

I also forgot to set the PACKAGER variable on this machine, so the
packages have "Unkown packager", I should probably rebuild the packages
soon, then.




signature.asc
Description: OpenPGP digital signature

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

[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].

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
drop it when I move this out of testing.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 feature in the
kernel that we do not provide userspace support for.

I also disabled audit, since it is enabled by default and there is no
kernel switch to change that. I hate that it annoys users who don't use
it - and we don't support it in our base system either (our systemd has
no audit support, just as it has no SMACK or SELinux support).

I kept YAMA, since it's not actually a real LSM, but only provides the
very useful ptrace scope protection - which can be disabled easily if so
desired.

* Disabled x32

I disabled the x32 support - we are not providing any x32 userspace and
there is no point for Arch in doing so. Given that the x32 syscalls
already had one major security flaw, I don't see why this should be enabled.

* Disabled userspace firmware helper support

The fallback firmware helper is now disabled. This forced me to disable
the "Dell BIOS uprgade via sysfs" support, but as far as I can see, that
was broken anyway and nobody used it.

* Made some drivers modular

Some more drivers that were built-in are now modules. Nothing exciting,
just random stuff.

* Enabled infiniband modules

I added the (modular) support for infiniband, as it was requested in a
bug report and it's only modules.

* Changed some kernel hacking options (not a lot)

I changed some things in the kernel hacking section, but can't remember
exactly what. I did not have the time to research why option XYZ was
needed or not, so I didn't feel like switching things around a lot.

* Removed some differences between 32 and 64 bit config

Some drivers were enabled in 32 and disabled in 64, or vice versa. I
think I fixed all those.

* Removed criu patch

I removed the patch that allows CONFIG_CHECKPOINT_RESTORE without
CONFIG_EXPERT. If this option is supposed to be used by end users, then
it should not be labelled CONFIG_EXPERT. As long as it is, I will assume
it is something evil.

* Added the 'simple' framebuffer driver

This driver tries to take over the firmware's framebuffer instead of
enabling the kernel's own generic vesa, uvesa of efi framebuffer. The
non-generic drivers obviously still take precedence and will disable
simplefb.

=

We still apply the following patches:

* Change default log level from 7 to 4

Merging our patch to make that configurable upstream somehow lead to
nothing, since nobody cared.

* Bluetooth: allocate static minor for vhci

It's not yet in 3.14, but I won't have those stupid bug reports
complaining about a harmless message anymore. I'm keeping this patch
until 3.15 is here.

* module: allow multiple calls to MODULE_DEVICE_TABLE() per module
* module: remove MODULE_GENERIC_TABLE

Fixes to module alias setup needed for the i8042 controller aliases to
work right. This is needed since i8042 is now modular, but upstream is slow.

* Revert "syscalls.h: use gcc alias instead of assembler

i686 won't work without it. Still waiting for anything from upstream.
Got a messsage from the patch author to resend my original message, but
no reaction again since then. See https://lkml.org/lkml/2014/1/26/22 for
details.

=

Bugs I've seen so far:

* The cirrus kms driver for qemu fails when booted with OVMF firmware.
Works with the standard qemu BIOS. No idea what's going on here.



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 actively, and for those, pacman -S cronie &&
systemctl enable cronie is not too much of a hassle.

* logrotate

In a default installation, it rotates nothing. It could be added as an
optdepend to those packages that provide logrotate.d files so people are
aware that they should install it.

Opinions?



signature.asc
Description: OpenPGP digital signature

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

[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
>>> 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
>>> extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats
>>
>> After the overall positive response, I converted these. Since none of my
>> machines used any cron jobs, I uninstalled cronie from them.
> 
> I am not sure how this interacts with suspend. My laptop was suspended
> at midnight, and on resume two of my timers fired, but 3 didn't. Maybe
> this is because interaction with suspend is broken, mabe because of
> AccuracySec set to 12h. I need to investigate this issue further.

*shrugs* Seems to work just fine now. All timers fired when I resumed at
work today.




signature.asc
Description: OpenPGP digital signature

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

[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-db
>> core/mlocate 0.26-1 /etc/cron.daily/updatedb
>> core/shadow 4.1.5.1-7   /etc/cron.daily/shadow
>> extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats
> 
> After the overall positive response, I converted these. Since none of my
> machines used any cron jobs, I uninstalled cronie from them.

I am not sure how this interacts with suspend. My laptop was suspended
at midnight, and on resume two of my timers fired, but 3 didn't. Maybe
this is because interaction with suspend is broken, mabe because of
AccuracySec set to 12h. I need to investigate this issue further.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 service makes sure the service works even if someone rm -r's
the directory at runtime.

IMO mkdir should not be necessary at all, man-db should create the
directory itself when needed.



signature.asc
Description: OpenPGP digital signature

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

[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
> core/shadow 4.1.5.1-7   /etc/cron.daily/shadow
> extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats

After the overall positive response, I converted these. Since none of my
machines used any cron jobs, I uninstalled cronie from them.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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. Wasn't this meant to be
> reverted as well?
 Forgot about that. That was pulled in by AppArmor or so.
>>> Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact
>>> that community/audit came out shortly after?
>> No, it was pulled in accidentally as a dependency of AppArmor.
> I doubt that. AppArmor was enabled a year and a half after audit was.
> 
> https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26&id=e46bc1d41848b258a138df26590967dc1e0a3417
> 
> https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kernel26&id=688e0f7508fa943868470e9d6c0dcb12823b06f0

Yeah, that was incorrect in my memory. It was actually SELinux that
pulled it in.

>> If we actually want audit, we should support it as well. Our systemd
>> package is compiled with -AUDIT for example.
>>
>> Since audit is one of those "enabled unless the user intervenes" option
>> that also does annoying things, I would like to get rid of it in our kernel.
> It is supported if you count [community] packages. I'll ask on the LKML
> if anything can be done about the logging.

It's not about logging, it's about being enabled by default when it is
supported by the kernel. There's no "disable audit by default" switch.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 once since the last time the service unit has been triggered
by the timer unit. The time when the service unit was last
triggered is stored on disk. This is useful to catch up for missed
timers when a machine is shutdown temporarily and then is powered
up again. Note that this setting only has an effect on timers
configured with OnCalendar=.

This means that we could replace the cron.* dropin scripts with systemd
services and timers.

Pros:
 * enabled by default (in contrast to cronie)
 * systems without need for crontabs can disable/uninstall cron
 * service will be simpler than the rather long dropin scripts

Cons:
 * services are run in parallel instead of sequentially (is this even a
con? timer start will be randomized, and we can increase accuracy to an
hour to randomize even more)
 * no holdoff time after boot as it seems

Affected packages:

community/awstats 7.2-1 /etc/cron.hourly/awstats
community/snapper 0.2.1-1   /etc/cron.hourly/snapper
community/sysstat 10.3.1-1  /etc/cron.hourly/sysstat

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
extra/hylafax 6.0.6-4   /etc/cron.daily/hylafax
community/atop 2.0.2-1  /etc/cron.daily/atop
community/dspam 3.10.2-8/etc/cron.daily/dspam_maintenance
community/logwatch 7.4.0-3  /etc/cron.daily/0logwatch
community/snapper 0.2.1-1   /etc/cron.daily/snapper
community/sysstat 10.3.1-1  /etc/cron.daily/sysstat

extra/pkgstats 2.3-3/etc/cron.weekly/pkgstats
community/squid 3.4.4-1 /etc/cron.weekly/squid

I'd be willing to convert all the core packages and put them to testing
if people agree that this is the right course.



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 [testing], and will upload a 
> new nvidia-utils package containing the binary to [testing]. FS#39203 and 
> FS#39636 will be closed if the new package fixed everything. (A setuid binary 
> is not good, but no trivial workaround was found)

Seriously, that is a crappy solution. If nvidia would properly register
its devices with linux, these devices could be created dynamically. It's
really up to nvidia to fix their kernel module.

(By the way, the /dev/nvidia* devices do not even generate proper
uevents and thus cannot be caught by udev or systemd. I wish they would
stop relying on a closed-source kernel driver with debatable quality.)



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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.
> Wasn't it pulled in by http://bugs.archlinux.org/task/12584 and the fact
> that community/audit came out shortly after?

No, it was pulled in accidentally as a dependency of AppArmor.

If we actually want audit, we should support it as well. Our systemd
package is compiled with -AUDIT for example.

Since audit is one of those "enabled unless the user intervenes" option
that also does annoying things, I would like to get rid of it in our kernel.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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

[Thomas Bächler]

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
everyone.

I want to trim our kernel down to what we actually support.

1) Once we agreed to disable one LSM, everyone else said "we can enable
LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK,
Tomoyo, AppArmor and Yama, although we don't support the userspace for
any of those.

I propose to drop all of them.

2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without
enabling CONFIG_EXPERT. I have no idea what the impact of this option
is, other than that it was requested in order to support some tool that
can freeze and save single processes resume them later. I am generally
sceptical towards options that require CONFIG_EXPERT, so I propose
dropping this one, too.

3) We enable tons of debug options in the "Kernel Hacking" section, many
of which have a "small performance impact". I'd like to get rid of those
that we don't need (I didn't go through all of them yet).

What I'd like is a discussion where people suggest more things that
could or should be dropped, and tell me what is absolutely needed and
why. I hope that such a discussion makes it clearer to me how I should
proceed.

Regards
Thomas



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 service?




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 extra ip costs 1€/month.
> 
> Specs: http://www.hetzner.de/en/hosting/produkte_rootserver/px60

Can't we setup IPMI with ipv6? Reserving an ipv4 address for this is a
waste of money.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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/libseccomp (439 extra (make)deps to pull)

These shouldn't be too hard to fix (someone should fix that insane number).




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 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 side effect that in a
>> chroot with only certain packages installed, one has to explicitly
>> install systemd to get findmnt working. Since I've run into this
>> situation and cyclic deps are bad, I propose the following:
>>
>> Split both util-linux and systemd into libutil-linux/util-linux and
>> libsystemd/systemd. Then we could have both util-linux and systemd
>> depend on both libsystemd and libutil-linux.
>>
>> [1] http://www.spinics.net/lists/util-linux-ng/msg08699.html
>>
> 
> We also have another set when installing {base} group:
> 
> warning: util-linux will be installed before its coreutils dependency
> warning: util-linux will be installed before its pam dependency
> warning: shadow will be installed before its pam dependency

This was e2fsprogs' fault, it should now be fixed in testing.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 (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 side effect that in a
>>> chroot with only certain packages installed, one has to explicitly
>>> install systemd to get findmnt working. Since I've run into this
>>> situation and cyclic deps are bad, I propose the following:
>>>
>>> Split both util-linux and systemd into libutil-linux/util-linux and
>>> libsystemd/systemd. Then we could have both util-linux and systemd
>>> depend on both libsystemd and libutil-linux.
>>>
>>> [1] http://www.spinics.net/lists/util-linux-ng/msg08699.html
>>>
>> We also have another set when installing {base} group:
>>
>> warning: util-linux will be installed before its coreutils dependency
>> warning: util-linux will be installed before its pam dependency
>> warning: shadow will be installed before its pam dependency
>>
>>
> New depends introduce error during base installation,
> libutil-linux needs coreutils first else no install is found.
> 
> I cannot get coreutils installed before util-linux so this is really
> annoying.

That's a packaging mistake: the install= should only be in util-linux,
not libutil-linux.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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, this is now done.

If you need any moral support, feel free to contact me.



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 (systemd-udevd) and util-linux requires
>>> libudev (findmnt, and soon uuidd [1]).
>>
>> Do you run a huge SAP install? I don't run a huge SAP install. I'm not
>> sure why anyone who doesn't run a huge SAP install cares about uuidd,
>> but I understand your concern.
> 
> I think my sarcasm-detector is broken, there's a red light flashing that
> wasn't there before.

And now it's lsblk, too. We could get a sane dependency chain without
circles now - or wait until all of util-linux is broken.




signature.asc
Description: OpenPGP digital signature

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

[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 (systemd-udevd) and util-linux requires
>> libudev (findmnt, and soon uuidd [1]).
> 
> Do you run a huge SAP install? I don't run a huge SAP install. I'm not
> sure why anyone who doesn't run a huge SAP install cares about uuidd,
> but I understand your concern.

I think my sarcasm-detector is broken, there's a red light flashing that
wasn't there before.

>> I don't like this situation and currently it is revoled by adding
>> systemd as optdepend to util-linux. This has the side effect that in a
>> chroot with only certain packages installed, one has to explicitly
>> install systemd to get findmnt working. Since I've run into this
>> situation and cyclic deps are bad, I propose the following:
>>
>> Split both util-linux and systemd into libutil-linux/util-linux and
>> libsystemd/systemd. Then we could have both util-linux and systemd
>> depend on both libsystemd and libutil-linux.
> 
> Is this really necessary just to avoid minor problems in chroots? We
> used to have a libsystemd package, and subsequently ditched it. I don't
> see anything critical here.

It's probably the right thing to do (better than some fishy optdepend).
And since I am extremely fond of findmnt, it would make me incredibly happy.

> But hey, for some good news, there's already/still packages which depend
> on libsystemd.

Great stuff!



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 side effect that in a
chroot with only certain packages installed, one has to explicitly
install systemd to get findmnt working. Since I've run into this
situation and cyclic deps are bad, I propose the following:

Split both util-linux and systemd into libutil-linux/util-linux and
libsystemd/systemd. Then we could have both util-linux and systemd
depend on both libsystemd and libutil-linux.

[1] http://www.spinics.net/lists/util-linux-ng/msg08699.html



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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.4.6
> 
> Bug report at: https://bugs.archlinux.org/task/39007

Since that plugin is not even in the pppd plugin path, there is no way
to detect this problem.

Besides rp-pppoe, pppd-ldap also needs a rebuild (the plugin is still
for 2.4.4, so I wonder if a single person ever used it).

I also wonder why rp-pppoe is still in core. It provides no essential
functionality that netctl+ppp don't.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 NetworkManager[285]:  VPN service 'pptp' started 
> (org.freedesktop.NetworkManager.pptp), PID 946
> Feb 23 16:06:06 Empire NetworkManager[285]:  VPN service 'pptp' 
> appeared; activating connections
> Feb 23 16:06:06 Empire NetworkManager[285]:  VPN plugin state changed: 
> starting (3)
> Feb 23 16:06:06 Empire NetworkManager[285]:  VPN connection 'KUINS' 
> (Connect) reply received.
> Feb 23 16:06:06 Empire pppd[947]: Plugin 
> /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so is for pppd version 2.4.5, this is 
> 2.4.6
> Feb 23 16:06:06 Empire NetworkManager[285]:  VPN plugin failed: 0
> Feb 23 16:06:06 Empire NetworkManager[285]:  VPN plugin state changed: 
> stopped (6)
> Feb 23 16:06:06 Empire NetworkManager[285]:  VPN plugin state change 
> reason: 10
> 
> I went to /usr/lib/pppd and found 2 folders, 2.4.5 and 2.4.6. Should I 
> recompile networkmanager-pptp and pptpclient?

The networkmanager, networkmanager-pptp and pppd-ldap-simple packages
should probably be recompiled.

extra/networkmanager 0.9.8.8-1
/usr/lib/pppd/2.4.5/nm-pppd-plugin.so
extra/networkmanager-pptp 0.9.8.4-1
/usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so
community/pppd-ldap-simple 0.12b-6
/usr/lib/pppd/2.4.5/pppd_ldap_simple.so

(Good thing that anyone actually uses testing/ppp to notice these problems.)



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 make it into [core].

This version works fine on my desktop, but fails on my laptop. The
initramfs works fine. While booting up the system, systemd hangs and
this appears in the journal:

systemd[1]: Assertion '(x->type == SOURCE_MONOTONIC && y->type ==
SOURCE_MONOTONIC) || (x->type == SOURCE_REALTIME && y->type ==
SOURCE_REALTIME)' failed at src/libsystemd/sd-event/sd-event.c:264,
function latest_time_prioq_compare(). Aborting.
systemd[1]: Caught , dumped core as pid 317.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 found. Probing ports directly.
>   i8042: No controller found
> 
> I assume that's fine too, although I'm not too sure if we need to make
> this clear in the announcement.

The news says "If you have a PS/2 port and get this message," - you
obviously don't have a PS/2 port.




signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Linux 3.13 status

[Thomas Bächler]

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 the keyboard changes, I'd like to make the following announcement:


Linux 3.13 WARNING: PS/2 Keyboard support is now modular

It has been requested that we make support for the i8042 keyboard and
mouse controller modular. Some people get weird error messages because
they don't have one and the manual probing slows down their boot. Tom
took care of this on the kernel side (thank you) and the result finally
landed in 3.13.

In order to get keyboard input during early init, if you don't have it
already, add the `keyboard` hook to the `HOOKS=` line in
`/etc/mkinitcpio.conf`. It has been in the default configuration for
some time.

**WARNING**: There's a downside to all this: On some motherboards
(mostly ancient ones, but also a few new ones), the i8042 controller
cannot be automatically detected. It's rare, but some people will surely
be without keyboard. You can detect this situation in advance:

$ dmesg -t | grep ^i8042
i8042: PNP: No PS/2 controller found. Probing ports directly.

If you have a PS/2 port and get this message, add `atkbd` to the
`MODULES=` line in `mkinitcpio.conf` and run `mkinitcpio -P`. If you
just noticed that you are without keyboard after rebooting, fear not!
Simply add

earlymodules=atkbd modules-load=atkbd

to your kernel command line in your bootloader.

I apologize for any inconvenience this transition may cause.



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 that.

$ grep ^Libs ./src/compat-libs/*.pc.in
./src/compat-libs/libsystemd-daemon.pc.in:Libs: -L${libdir} -lsystemd
./src/compat-libs/libsystemd-id128.pc.in:Libs: -L${libdir} -lsystemd
./src/compat-libs/libsystemd-journal.pc.in:Libs: -L${libdir} -lsystemd
./src/compat-libs/libsystemd-login.pc.in:Libs: -L${libdir} -lsystemd

> What do we stand to gain from
> this instead of passing off the work to upstream?

Just saying, that short-term, we could get rid of the compat libraries
this way.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 problems and try to nudge
>   respective upstreams to move to the new library name.

Do you expect any build problems? And why do projects explicitly need to
move?

Can't we simply do a rebuild (if needed), disable the compat libraries
but keep providing the compat .pc files for a while?




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 problem you ran into, I see two options: inform about the
> possible need to force-load the module in a post-install message (if
> we work from the assumption that it will be a rare issue). Or, if the
> problem appears to be more wide-spread, simply ship a modules-load.d
> fragment that will load the module. This will at least will give
> people the option to mask the fragment if they don't need the module
> to avoid the boot-delays (and spurious error message in dmesg).

For the moment, I'll upload the kernel with the fixed aliases and see
what happens. It is no problem to revert to built-in before we move to core.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 bleeding edge PC with Intel H87 chipset. I don't actually use
the PS/2 though since I have everything on USB.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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, even for AT(PS/2) keyboards. Beware that in
>>> order to have keyboard input during early boot, you need the 'keyboard'
>>> hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A
>>> post-install message has been added.
>>
>> Awesome :-) \o/
>>
>> -t
> 
> As it turns out, many people have no keyboard at all due to a bug (blame
> Tom). Please refrain from updating unless you have some other way to
> type 'modprobe atkbd' until we decide what exactly we should do.

Okay, there are two problems: 1), the i8042 module was lacking
modaliases. This is resolved by this patch http://pastebin.com/bKydQZLF

2) Some machines to not export the i8042 controller by either ACPI or
PNP - for example, on my machine. Loading i8042 works just fine, but it
will never be autodetected.

This message is probably related:
[14287.808024] i8042: PNP: No PS/2 controller found. Probing ports directly.

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"?



signature.asc
Description: OpenPGP digital signature

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

[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, even for AT(PS/2) keyboards. Beware that in
>> order to have keyboard input during early boot, you need the 'keyboard'
>> hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A
>> post-install message has been added.
> 
> Awesome :-) \o/
> 
> -t

As it turns out, many people have no keyboard at all due to a bug (blame
Tom). Please refrain from updating unless you have some other way to
type 'modprobe atkbd' until we decide what exactly we should do.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 these ASAP.

Okay, I finished those modules as well. But I tested none of them.




signature.asc
Description: OpenPGP digital signature

[arch-dev-public] 3.13 packages in testing

[Thomas Bächler]

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 already built lirc, nvidia and nvidia-304xx and tested nvidia on
x86_64, successfully.

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 these ASAP.

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 keyboard input during early boot, you need the 'keyboard'
hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A
post-install message has been added.

[1] http://marc.info/?l=linux-kernel&m=139072738431286&w=2



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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.
> 
> Thoughts?
> 
> [1] http://www.videolan.org/developers/libaacs.html

At least libdvdcss is probably illegal in the US under the DMCA (I am no
lawyer, but this is what I "heard"). In Germany, for example, libdvdcss
is legal since the CSS protection has been declared "ineffective" by a
court and thus working around it is legal (I have no idea if software by
itself can even be illegal in Germany).

libaacs cannot break AACS encryption without extra data (which is not
and should not be delivered with the package). I have no idea how this
would affect its standing under the DMCA or any other law in any
country. The same goes for the newly released libbdplus.

IMO, if we can publish a libdvdcss build, we can also publish a libaacs
build - thus far nobody ever cared.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 (cannot chainload EFI
executables, for example), I am now very sceptical towards this.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 of ALL loop and device mapper devices.

This feature is enabled automatically if
* /run/initramfs exists (will be created on your next boot by tmpfiles),
* /run/initramfs/shutdown doesn't exist or is not an executable,
* The user hasn't masked mkinitcpio-generate-shutdown-ramfs.service.

This method should also be able to completely obsolete the custom
shutdown hook in archiso and the mkinitcpio shutdown hook (using any of
those will disable the new stuff).



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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-3.3.9-1 lands in [core].
> 
> Done.

It's one of those little things that improve Arch. Dropping sysvinit
entirely is another step into the future.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 a problem.

> * Including .desktop files is basically the same as patching. And this
> quote: "Patching only occurs in extremely rare cases, to prevent
> severe breakage in the instance of version mismatches that may occur
> within a rolling release model." from
> https://wiki.archlinux.org/index.php/Arch_Linux

That is nonsense. A .desktop file is a simple configuration file. We
ship custom default configurations for our packages whenever necessary.

More importantly, we should never compromise functionality for
ideological or political reasons - for me, that is part of Arch's
simplicity.

In short, whenever upstream provides a correct .desktop file, we should
use it. Otherwise, we should provide our own (exactly like we do with
.service files).



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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'?

> 2. Upload and add epoch=1 to docker (the new one)
> 
> I can do step 2 if someone can handle step 1.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 at all.

In this case, the install message contains basic systemctl commands and
networking tips, none of this is specific to docker or urgent enough to
be printed during pacman.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 screen during boot is entirely obsolete.

> I'm open to arguments against this, but I suggest we drop sysvinit-tools
> after pidof is part of a release from procps-ng.

Sounds great.




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Orphaning Wireshark

[Thomas Bächler]

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 that for this package. Plus it is far
>> away from my Java skills!
>>
>> If anyone is interested, help yourself. If no one steps forward I
>> could also move it to community.
> 
> Hi,
> I'm interested in maintaining Wireshark, since I use almost every day at
> work.
> 
> The only problem is I can't maintain it in extra since I'm a Trusted User.
> 
> So, if nobody wants to maintain it in the extra repo, can you move it to
> community so I can start maintain it?

Nothing depends on wireshark, so it can safely go to community.




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Orphans

[Thomas Bächler]

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 
> push
> them.
> 
> Feel free to push them when the key has been added, otherwise send me a
> reminder.

I just updated the archlinux-keyring package on nymeria, you should be
free to push now.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 "New Key" type in the "Keyring" project on the
bug tracker. In that task, the following must be listed:

1) Bug tracker user name of the new dev/TU
2) PGP fingerprint
3) Any links to relevant discussion threads or similar

In addition, the information 1) and 2) must be written into a plain-text
file, signed with gpg --sign (using a valid packager key) and attached
to the bug report.

A master key holder can then add the new user to the "Members" group of
the "Keyring" project, so he/she can comment and provide additional
information (you should all be members of that group and thus be able to
see the Keyring project, if anyone isn't, please tell me).

REMOVAL OF A KEY:

Whenever a TU resigns or a developer leaves the team (or is forcefully
removed from the team), a task with the "Key Removal" type must be
opened in the "Keyring" project to schedule revocation of the key and
necessary rebuilds.

A master key holder should remove the user from the "Members" group.

OTHERS:

Any other issues regarding key signatures should be stated in a task
with the "Other" type in the "Keyring" project.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 archweb.
> 
> I've disabled his accounts on nymeria and brynhild, marked him "past TU"
> in the wiki and removed the TU status on flyspray. Someone else please
> take care of archweb and bbs.

Can we somehow get a list of people not listed as TUs/Devs in Archweb
that still have valid PGP keys? I think that besides Daenyth, Dieter
also still has a valid key.

We might want to revoke all those signatures.




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Dropping mplayer2

[Thomas Bächler]

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

[Thomas Bächler]

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-keyring package for Fedora.
> I have one question: is there an official license for the archlinux-keyring
> sources? It is just a collection of publicly accessible information,
> but it would be much easier if the license (Public Domain?) would
> be publicly specified.

It seems there is no license in the archlinux-keyring repository, and
the Arch Linux package says "GPL", which may not even make sense for
this stuff (the package doesn't include the scripts, only the collection
of PGP keys).

I CC'd Pierre - can we clarify the license on this?




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 matter is that I have a laptop at work which used
nvidia-304xx - however, it had so many problems that I switched that
machine to nouveau. Given the low maintenance effort that nvidia puts
into those legacy releases, I wouldn't mind if those packages were
dropped entirely.




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] arch bootstrapping

[Thomas Bächler]

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-get, so adding pacman seems kind of nice.
> 
> The packaging process is going well, but the intallation is not
> as easy, because of gpg key issues. It's possible that I made some
> error, I tried both to add SigLevel=TrustAll in (host's) /etc/pacman.conf,
> and to to import gpg keys with 'pacman-key --populate archlinux'.
> The second solution didn't seem to work, and both have downsides:
> - disabling checking is bad because of security issues,
>   and it also seems to mess up the trust database inside the container,
> - importing the trust database in the host (assuming that I'd get it
>   to work), would require either also packaging the keys for Fedora,
>   or telling the user to trust keys blindly and download them from
>   the internet...

pacstrap assumes that you have a working key database on the host (which
is the case for our live CD and bootstrap tarball). To work around that,
you need to

1) set up a keyring in /instroot/etc/pacman.d/gnupg
2) call pacstrap with the -G option

This will set up a keyring in /instroot without the need for one in the
host.

For 1), simply run
 pacman-key --gpgdir /instroot/etc/pacman.d/gnupg --init
 pacman-key --gpgdir /instroot/etc/pacman.d/gnupg --populate archlinux

For that, you must have the keyring available in
/usr/share/pacman/keyrings/. Get the keyring from
https://projects.archlinux.org/archlinux-keyring.git/ - you need the
archlinux.gpg, archlinux-revoked and archlinux-trusted files.

The only thing that is critical for security is the archlinux-trusted
file - the fingerprints in there must match the ones from
https://www.archlinux.org/master-keys/. The rest of the files are just
there for convenience.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 permissions.  This will result in
> errors like "grantpt failed: Operation not permitted".

Thank you for this. Before, it was impossible to use glibc's openpty()
in an environment where your root was mounted nosuid or with
PR_SET_NO_NEW_PRIVS set to 1.

The system call for the new pty would succeed, the permissions on the
pts-device would be correct, too. Then glibc would call pt_chown to fix
the permissions (which were already correct) which would fail due to
insufficient permissions. On top of that, it would output an errno code
that was not documented for openpty(). Took me hours to figure this out
(and replace pt_chown with a symlink to /bin/true to fix it).




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 once util-linux-24 is out.
>>
>> If anyone have any objections or concerns, this would be the perfect
>> time to speak up, so we can sort out any problems before the release.
> 
> I think ppp uses 'pidof' in some scripts. pidof is similar to pgrep, but
> not quite the same. The other remaining tools (bootlogd, fstab-decode,
> killall5) seem to serve no purpose anymore.

Relevant thread here:

http://www.freelists.org/post/procps/pidof-in-procpsng




signature.asc
Description: OpenPGP digital signature

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

[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 once util-linux-24 is out.
> 
> If anyone have any objections or concerns, this would be the perfect
> time to speak up, so we can sort out any problems before the release.

I think ppp uses 'pidof' in some scripts. pidof is similar to pgrep, but
not quite the same. The other remaining tools (bootlogd, fstab-decode,
killall5) seem to serve no purpose anymore.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 now. We could have moved to 3.4 a year
ago, but since 3.0 was going to be maintained until fall 2013, we chose
to keep it. We might as well keep 3.10 for another 2 years.

I'd also prefer to use only G-KH's kernels for LTS, and 3.2 is not
maintained by him, but by Debian (not that that's bad in itself).




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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]: 

Agreed, but no need to hurry. We can wait until the last 3.0 release
which was planned for October(?).



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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
>>
>> Please find patches and fix those, 3.10 will move to [core] when signoff
>> procedure is done.
> 
> This warning has been posted weeks ago already and nothing happened
> about it. There was not even a message from the "maintainers" about the
> status ([1]). Since 3.9 is EOL now, we will move 3.10 whether those
> modules are fixed or not and as a result, drop the aforementioned packages.
> 
> 
> [1] By "maintainers" I mean TUs who cannot even afford to react to an
> email that affects their package. Maybe we should start insulting people
> like Linus does.

Oops, sent to arch-general by accident, this should have gone to this list.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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/rc.d/ntpd
extra/ntp 4.2.6.p5-14   /etc/rc.d/ntpdate
extra/tomcat6 6.0.37-1  /etc/rc.d/tomcat6
extra/x11vnc 0.9.13-3   /etc/rc.d/x11vnc
community/netcfg 3.1-4  /etc/rc.d/net-auto-wireless
community/netcfg 3.1-4  /etc/rc.d/net-auto-wired
community/netcfg 3.1-4  /etc/rc.d/net-profiles
community/netcfg 3.1-4  /etc/rc.d/net-rename
community/netcfg 3.1-4  /etc/rc.d/functions.d/net-set-variable

While ntp, tomcat6 and x11vnc could have used a rebuild after being in
this state for 2 months, it's not that big a deal.

However, now netcfg has been readded to community in the exact same
state as the package that was originally removed:

* It does not work properly with systemd.
* There is no init system in our repositories that it works with.
* It actually re-added rc.d files to our repositories, although we had a
TODO list recently to explicitly remove those (and btw, they depend on
files that no longer exist in our repositories, like /etc/rc.d/functions
and /etc/rc.conf).

I am really confused about the decision to re-add this and I am
seriously considering if we should talk about stricter guidelines for
adding packages and - in particular - the quality of our packages.



signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 report other issues.

Someone should actually test nvidia-304xx - we simply removed some code
that didn't compile due to lack of a proper fix. This code seems
unneeded (some read-only proc entries), but you can never be sure.




signature.asc
Description: OpenPGP digital signature

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

[Thomas Bächler]

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 ISO image) and upload such a tar at the same time as the ISO image.
>>>
>>> I was thinking about including this into arch-install-scripts, but I am
>>> unsure if it really fits in there.
>>
>> Yes, seems difficult. As I said, I also have other scripts like creating
>> torrents etc. that are used for a realease. Maybe we can create a releng
>> repo/package for these.
> 
> Regardless of where the scripts end up, should we publish these images
> with the July ISO? I can write a short README for it.

Script is here for the moment:
https://github.com/brain0/genbootstrap



signature.asc
Description: OpenPGP digital signature