Re: [arch-dev-public] Potential removal of Chromium in ~2 months

[Dave Reisner]

On Sat, Feb 22, 2020 at 09:59:00AM -0500, Santiago Torres-Arias via 
arch-dev-public wrote:
> > > To make a long story short, I consider broken geolocation sufficient
> > > reason for removal. I don't mind it being broken for my own use, but
> > > shipping a package with broken functionality due to lack of upstream
> > > support does not sit well with me.
> > 
> > The short story doesn't accurately reflect reality. There's still upstream
> > support, you've just not been willing to conform to the new officially
> > supported process.
> > 
> > > To protect against systems with outdated Chromium (following the stable
> > > release of version 82), at the beginning of April I intend to post a
> > > news item about the need to switch to another browser. That is assuming
> > > no solution is found and nobody objects to the removal or wishes to
> > > continue maintenance of the package with reduced functionality.
> > 
> > If anyone wants help in getting Geolocation working again, please let me
> > know.
> > 
> I'm curious, do you have a reference on how the process has changed? I
> think it'd be easier for people to gauge interest if they know what the
> new process entails. I'm also wondering if the billing requirement could
> be handled by SPI or some other organization-level approach

The old process was essentially "know someone on the inside". Billing
and access for Maps-based APIs has a lng history. It existed
before Google was really in the business of selling other APIs. Thus,
it's gone through multiple iterations and a somewhat independent
evolution. Lately, that's changed and it's now using standard internal
infrastructure. As a side effect, the backdoor that Chrome developers
used to be able to provide to distros is no longer available

The new process is well-described here:

https://support.google.com/nonprofits/answer/3367237?hl=en

dR

Re: [arch-dev-public] Potential removal of Chromium in ~2 months

[Dave Reisner]

On Sat, Feb 22, 2020 at 07:50:58AM +0200, Evangelos Foutras via arch-dev-public 
wrote:
> Just a quick heads up that I am considering dropping Chromium from
> [extra] a week or two before the Chromium 82 stable release (~April 28).
> The reason for this is that our API keys no longer work for geolocation
> requests and there is no clear upstream guidance on how to resolve this
> issue. [1]

We've talked about this. You're well aware that this isn't an accurate
portrayal of the situation. I'm happy to guide you (or anyone else)
through the remedy. What you're looking for is continuation of the
preferential treatment that distros have historically received and
unfortunately, that avenue has changed shape. Your gripe seems to be
focused on the requirement of having a billing account now, regardless
of the fact that the end goal is the same -- for distros (non-profits)
to have free access.

> When I created these API keys back in 2013, there was a semi-official
> effort by the Chrome Team to support distro builds of Chromium in regard
> to accessing Google APIs; a few minor hiccups along the way were quickly
> resolved. I feel this arrangement is starting to fall apart (in spite of
> some upstream Chrome developers' best efforts).
> 
> To make a long story short, I consider broken geolocation sufficient
> reason for removal. I don't mind it being broken for my own use, but
> shipping a package with broken functionality due to lack of upstream
> support does not sit well with me.

The short story doesn't accurately reflect reality. There's still upstream
support, you've just not been willing to conform to the new officially
supported process.

> To protect against systems with outdated Chromium (following the stable
> release of version 82), at the beginning of April I intend to post a
> news item about the need to switch to another browser. That is assuming
> no solution is found and nobody objects to the removal or wishes to
> continue maintenance of the package with reduced functionality.

If anyone wants help in getting Geolocation working again, please let me
know.

dR

Re: [arch-dev-public] Todos for language specific rebuilds

[Dave Reisner]

On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Hi everybody,
>
> I would like to propose that we create todos for rebuilds of language
> specific packages.
>
> We had two major rebuilds in the last months: python3.8 and ruby2.7.
>
> Can we agree that we create a todo before such rebuilds?
> The advantages outweigh the disadvantages. We would gain:
>

Hi,

I'm not sure I understand. Can you clearly state the problems we've
encountered due to not doing this? What downsides do you see to your
proposal? Can you think of any alternative solutions?

* More people help rebuilding the packages.
>

Solving the wrong problem, IMO. This is largely toil and should be
automated away. Foutrelis already has such a system that we've used for
rebuilds in the past. We could/should instead work towards making this more
generally available on the build machines.

* Every maintainer gets informed about the rebuild.
>

As a maintainer, I don't care that you're rebuilding my package to keep up
with library changes. Rather, I'm thankful to whomever did this for me.

Why would a language rebuild differ from any other soname bump?

* Maintainers have the possibility to test the packages.
>

Why is this not currently possible? Couldn't we just use testing prior to
pushing out to the repos (something we've done in the past and continue to
do)? What about packages which aren't using the lowlevel API and are simply
interpreted code. Those don't get rebuilt, but they're potentially impacted
by the language version bump. They'll never be called out on a rebuild lost
because we generate those based on ELF dependencies.

dR

If tools exist for creating todos, I would like to ask the persons with
> such tools to make them available for everybody (if not already
> happened).
>
> Greetings,
> shibumi
>

[arch-dev-public] Looking for maintainer for mkinitcpio/a-i-s

[Dave Reisner]

Hi,

I'm finding myself lacking these days in both time and motivation to
continue maintenance of both mkinitcpio and arch-install-scripts. Is
anyone interested in taking these over? Both projects are fairly stable,
but bugs do crop up as the rest of the OS evolves.

dR

[arch-dev-public] away from packaging duties until ~Feb '18

[Dave Reisner]

Hi friends,

Between the holidays as well as business trips next week and in mid
January, I don't expect to have much time to pay attention to packaging
duties. Stepping away for a month+ also gives me the opportunity to
reduce the time I'm spending at a keyboard and nurse some RSI
aggravation that I've been carrying for the past few weeks.

Cheers,
Dave

[arch-dev-public] away/unavailable

[Dave Reisner]

Hi,

I'm sporadically unavailable for the next month or so:

* vacation: 8/11 - 8/20
* work trip: 9/1 - 9/9
* wedding: 9/22 - 9/24

If it's not one of the above, I'm likely doing planning for said wedding
and/or contemplating some other fairly major upcoming changes.

Feel free to update any/all of my packages as needed.

dR

[arch-dev-public] switching to systemd-stable

[Dave Reisner]

Hey all,

This should be pretty much a no-brainer, but wanted to be sure I wasn't
missing anything. Systemd upstream publishes a "systemd-stable" repo [1]
which branches at each tag and cherry-picks backports. I'd like to
switch our systemd package to this repo to avoid some of the duplication
of work that Jan, Christian and myself have done in the past. The repo
sees a bunch more activity than what our own backporting strategy has
been, and I see that as a positive.

One potentially bikeshed-worthy question is versioning. Do we count
commits and modify the pkgver every time we build from the repo, e.g.
233.23-1 (meaning pkgrel=1 of a v233 build containing 23 backports), or
do we simply keep the base pkgver true to upstream and increment pkgrel
every time we release, e.g. 233-5 (meaning pkgrel=5 of some build of the
v233 stable branch).

Regards,
Dave

[1] https://github.com/systemd/systemd-stable

Re: [arch-dev-public] AUR ToS (aka making AUR user names public)

[Dave Reisner]

On Sun, Mar 5, 2017 at 10:34 AM, Lukas Fleischer <lfleisc...@archlinux.org>
wrote:

> On Sun, 05 Mar 2017 at 19:11:33, Dave Reisner wrote:
> > As long as we publish a list of all available packages, it doesn't matter
> > if we comply with this request -- the information is already obtainable
> > through RPC requests.
>
> Could you elaborate, please? I do not see how this information is
> already obtainable. In particular, there is no easy way to obtain user
> names of "inactive" accounts (no comments, no package submissions, no
> requests, ...) -- is there?
>

Ah, I guess you're right -- there isn't.

Re: [arch-dev-public] AUR ToS (aka making AUR user names public)

[Dave Reisner]

On Mar 5, 2017 8:35 AM, "Lukas Fleischer"  wrote:

Hi,

I was recently contacted by a Polish researcher asking for a list of AUR
account names. I did not expect this to be controversial but a couple of
Trusted Users raised concerns on IRC, so I decided to move this to the
public mailing list and discuss the whole topic in generality. I would
like to head more opinions but please read the whole email and give it a
second thought before simply bringing up the usual privacy arguments
mentioned below.

My original questions was: Are we fine with sharing the list of AUR
accounts names (only user names, no real names or email addresses) with
a researcher that seems trustworthy and agrees to not share the data in
any form other than the resulting anonymized statistics?


As long as we publish a list of all available packages, it doesn't matter
if we comply with this request -- the information is already obtainable
through RPC requests.

In this particular case, we are talking about Dorota Celinska [1] from
the University of Warsaw, Faculty of Economic Sciences [2], see [3] for
a list of her publications and [4] for a summary of her research project
funded recently by the Polish National Science Centre. She needs the
list of user names to perform a segmentation analysis, including users
which were active on the older AUR releases both do not show any
activity on AUR 4. She would also like to use the user names as
identifiers to establish connections with other platforms, such as
GitHub.

The next question is: Would it make sense to even make this data
publicly available? Would it make sense to extend our RPC interface such
that one can search for users names? GitHub, for example, already
provides such an interface [5]. Let me quickly summarize some arguments
for this idea which came up on IRC:

* User names are mostly identifiers. It is questionable whether they
  can/should be considered personal/private information. Maybe this can
  only be answered by a lawyer, though.

* The user names of all accounts with any kind of public activity, like
  uploading a package, filing a request, writing a comment, are public
  already.

* After logging into the aurweb interface, you can already check whether
  an account with a given user name exists because the account details
  page URIs have the form https://aur.archlinux.org/account/$username.
  This means that for any platform providing a list of user names (such
  as GitHub), you can "establish connections" with the AUR already.

Now the arguments against:

* Principle of data economy: We should not share any kind of information
  we do not need to share.

* Sharing user names lowers the threshold for sharing other information
  which is considered more confidential.

* Users can (and should) already use crawlers to fetch the user names.
  For example, the user names of all package maintainers and comment
  authors appear on the package details pages. The names of all users
  filing package requests appear in the mailing list archives etc.

* We do not have ToS so we better not share anything.

I, personally, find the second last argument a very weak one. Telling
users to build crawlers scraping an brute-forcing our HTML pages makes
life difficult for both them and us. What do you think?

On the other side of the coin, the last argument is a very good one and
it brings me to my last point. Independently of the outcome of this
discussion, I think we should add some ToS that users need to agree upon
when registering. It should contain information on liability and on
privacy. Is anybody willing to write a draft? Do we need the support of
a lawyer here?

Thank you for your time and have a nice Sunday!

Regards,
Lukas

[1] http://coin.wne.uw.edu.pl/dcelinska/en/
[2] https://www.wne.uw.edu.pl/index.php/en/
[3] http://coin.wne.uw.edu.pl/dcelinska/en/pages/publications.html
[4] https://ncn.gov.pl/sites/default/files/listy-rankingowe/2016-03-15/
streszczenia/337724-en.pdf
[5] https://developer.github.com/v3/users/

[arch-dev-public] away on vacation 12/19 - 1/11

[Dave Reisner]

Hi all,

As per $subject, I will not have access to my signing key time and will
be slow/unresponsive to any bug reports. Feel free to rebuild any of my
packages should the need arise.

mahalo,
d

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

[Dave Reisner]

On Mon, Oct 31, 2016 at 04:09:40PM -1000, Gaetan Bisson wrote:
> [2016-10-31 10:05:26 -0400] Dave Reisner:
> > On Sun, Oct 30, 2016 at 04:43:04PM -1000, Gaetan Bisson wrote:
> > > I agree with Sébastien. We should encourage upstream to digitally sign
> > > their releases, and verify their authenticity in our PKGBUILDs.
> > >
> > > Downloading releases over HTTPS gives a false sense of security:
> > > everybody knows the CA model is severely broken. In terms of security
> > > this simply does not compare with OpenPGP... In my view, switching our
> > > download links to HTTPS is nothing but an annoyance.
> > 
> > The CA model is broken. http clients have bugs. http servers have bugs.
> > pgp has bugs. sovereign states might be snooping on connections. None of
> > these are reasons to avoid an attempt at providing another layer of
> > security. That's all TLS is and I'm not suggesting it's some panacea.
> > 
> > Asking every upstream to provide a PGP signature isn't a process which
> > will scale, and some of them will likely not be interested in doing such
> > a thing. 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?
> 
> All the nuances in my message were apparently lost on you...
> 
> I said OpenPGP provides a much higher degree of security than HTTPS, so
> that's what we should strive to use. Obviously, for cases where digital
> signatures aren't available, downloading sources over HTTPS is better
> than nothing. What I argued, however, is that it's not much better than
> nothing, so we shouldn't become complacent and trust sources just
> because they came over TLS.
> 
> Cheers.
> 
> -- 
> Gaetan

I'll take this to mean that you don't have any objections about
adding additional layers of security.

d

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

[Dave Reisner]

On Mon, Oct 31, 2016 at 03:33:42PM -0400, Dave Reisner wrote:
> On Mon, Oct 31, 2016 at 08:14:32PM +0100, Thomas Bächler wrote:
> > 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.
> 
> IMO, Sebastien didn't really provide any compelling evidence that
> switching to https would be an incumberance -- rather, a minor
> inconvenience at worst.
> 
> Do you have other reasons to add? I'd be very interested to know why
> this is a problem. We already have a large number of sources fetched
> over https including several which include gpg signatures. Do you want
> to revert those to http? Why or why not?

To put some ballpark numbers to this with some simple grep'ing over the
PKGBUILD tree and my initial scripting work...

- We have 4539 sources fetched over https
- 193 of those 4539 sources also include a pgp signature
- 2169 more sources could be fetched over https instead of http
- 597 of those 2169 sources could include a https-fetched pgp signature

> > 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.
> 
> I don't really think you believe this...
> 
> > > 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.
> > 
> 
> This, too, does not scale, and might even constitute a breach of the
> software's license.

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

[Dave Reisner]

On Mon, Oct 31, 2016 at 08:14:32PM +0100, Thomas Bächler wrote:
> 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.

IMO, Sebastien didn't really provide any compelling evidence that
switching to https would be an incumberance -- rather, a minor
inconvenience at worst.

Do you have other reasons to add? I'd be very interested to know why
this is a problem. We already have a large number of sources fetched
over https including several which include gpg signatures. Do you want
to revert those to http? Why or why not?

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

I don't really think you believe this...

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

This, too, does not scale, and might even constitute a breach of the
software's license.

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

[Dave Reisner]

On Sun, Oct 30, 2016 at 04:43:04PM -1000, Gaetan Bisson wrote:
> [2016-10-31 03:23:48 +0100] Sébastien Luttringer:
> > On Sun, 2016-10-30 at 20:55 -0400, Dave Reisner wrote:
> > > There's been a sizeable number of bugs filed over the past month or so
> > > about changin PKGBUILDs to acquire sources from https rather than http.
> > > Rather than continue to flood the bug tracker, would anyone mind if I
> > > wrote a script to find instances of this and start a TODO list?  This
> > > would, of course, be low priority. Even if no one does anything, we at
> > > least have a statement of work and can avoid having these "bugs"
> > > littered around flyspray.
> > > 
> > > Unless there's strong opposition to this (and I'd be very interested to
> > > know why), I'll polish up my automation and create the list.
> > 
> > The few BR that reached me also requested the addition of a .sig.
> > As I use a transparent http cache at home (2Mb/s bandwidth), so far I only
> > added the signature, and not the https as it breaks the cache.
> > 
> > Except the confidentiality of the request, what's the point to force https?
> 
> I agree with Sébastien. We should encourage upstream to digitally sign
> their releases, and verify their authenticity in our PKGBUILDs.
>
> Downloading releases over HTTPS gives a false sense of security:
> everybody knows the CA model is severely broken. In terms of security
> this simply does not compare with OpenPGP... In my view, switching our
> download links to HTTPS is nothing but an annoyance.

The CA model is broken. http clients have bugs. http servers have bugs.
pgp has bugs. sovereign states might be snooping on connections. None of
these are reasons to avoid an attempt at providing another layer of
security. That's all TLS is and I'm not suggesting it's some panacea.

Asking every upstream to provide a PGP signature isn't a process which
will scale, and some of them will likely not be interested in doing such
a thing. 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?

d

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

[Dave Reisner]

On Mon, Oct 31, 2016 at 03:23:48AM +0100, Sébastien Luttringer wrote:
> On Sun, 2016-10-30 at 20:55 -0400, Dave Reisner wrote:
> > Hi all,
> > 
> > There's been a sizeable number of bugs filed over the past month or so
> > about changin PKGBUILDs to acquire sources from https rather than http.
> > Rather than continue to flood the bug tracker, would anyone mind if I
> > wrote a script to find instances of this and start a TODO list?  This
> > would, of course, be low priority. Even if no one does anything, we at
> > least have a statement of work and can avoid having these "bugs"
> > littered around flyspray.
> > 
> > Unless there's strong opposition to this (and I'd be very interested to
> > know why), I'll polish up my automation and create the list.
> > 
> > d
> 
> Hello,
> 
> The few BR that reached me also requested the addition of a .sig.

Yes, this was raised on IRC as well. I'm going to do this in a separate
pass.

> As I use a transparent http cache at home (2Mb/s bandwidth), so far I only
> added the signature, and not the https as it breaks the cache.

This doesn't seem to hold much weight. You're duplicating the source
tarball now, as it exists (on disk?) in your http cache and in makepkg's
SRCDEST. I'm not sure I see the benefit to doing this, particularly
since the caching in SRCDEST is entirely agnostic to the protocol used
to fetch it.

> Except the confidentiality of the request, what's the point to force https?

Security of sources, particularly those which we obtain without any
upstream verification mechanism such as a checksum or PGP signature.
Even for those with signatures or checksums, you must consider that
security is not a binary thing, and is always approached in layers.

d

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

[Dave Reisner]

Hi all,

There's been a sizeable number of bugs filed over the past month or so
about changin PKGBUILDs to acquire sources from https rather than http.
Rather than continue to flood the bug tracker, would anyone mind if I
wrote a script to find instances of this and start a TODO list?  This
would, of course, be low priority. Even if no one does anything, we at
least have a statement of work and can avoid having these "bugs"
littered around flyspray.

Unless there's strong opposition to this (and I'd be very interested to
know why), I'll polish up my automation and create the list.

d

[arch-dev-public] travelling 9/17 - 9/27

[Dave Reisner]

Hi all,

I'll be travelling to Sydney for work on the above dates. Free time will
be spent avoiding dropbears rather than packaging things.

Cheers,
d

Re: [arch-dev-public] dropping mkinitcpio-nfs-utils

[Dave Reisner]

On Mon, Jul 04, 2016 at 08:12:42PM -0300, Gerardo Exequiel Pozzi via 
arch-dev-public wrote:
> On 07/04/16 14:16, Dave Reisner wrote:
> > Hi all,
> > 
> > I'd like to drop mkinitcpio-nfs-utils from the repos. I suspect (but
> > would be happy to be proven wrong) that nobody uses this package. It's
> > based on code extracted from klibc which, while still a somewhat active
> > project, is lacking sorely in features in the network stack and NFS
> > itself (supporting only nfs3).
> > 
> > If someone were interested in reviving this in the future, I'd suspect
> > that it would be best to start from the ground up with a systemd-based
> > initramfs, using nfs-utils and systemd-networkd. The best part of this
> > deal would be that someone who actually uses this setup would then be
> > maintaining the code!
> > 
> > Any objections?
> > 
> > d
> > 
> 
> Yes, used in archiso.
> 
> Will be great if posible to migrate to pure systemd, but it does not
> provide such functionality and flexibility (cmdline params).
> Three years ago, I proposed a feature request in systemd, for some
> related things, but nobody was interested [#1].
> 
> [#1]
> https://lists.freedesktop.org/archives/systemd-devel/2013-July/012397.html
> 
> 

Well, it seems rather unfair that we attempt to treat the kernel command
line as environment. Any resemblance to shell environment variables is
merely a coincidence, IMO, as it's much closer to command line arguments
to an ordinary userspace program (hence the proc filename 'cmdline').

With that in mind, it doesn't really seem suitable to push this upstream
to systemd as it would need to make arbitrary decisions about what to do
with data in cmdline which isn't exportable through the shell. Should it
sanitize these (and would it do this by replacement or just dropping the
invalid data)? Assign arbitrary values to bare words? Drop them
entirely? I think it's rather app-specific as to how this is handled,
since the data which is invalid to the shell may very well not be
invalid elsewhere.

With that in mind, would it be useful if I were to refactor the cmdline
parsing logic in mkinitcpio to make it reusable? I went ahead and wrote
some unit tests against the existing parser (findings a number of bugs)
and then rewrote it to do exactly this:

http://code.falconindy.com/cgit/mkinitcpio.git/commit/?id=a3829b600

Now you can do something like:

  cmdline_item_callback() {
local key=$1 value=$2

case $key in
  ...)
...
;;
esac
  }

  . ./init_functions
  process_cmdline 'cmdline_item_callback'

Perhaps you could use this to write out something suitable as an
EnvironmentFile which ArchISO could source and use in its units.

Let me know what you think,
d

[arch-dev-public] travelling, unavailable 5/18 - 5/26

[Dave Reisner]

Hi all,

I'll be away on work for the next week and won't have time for some
pending Arch-related work. If anyone would like to take care of version
bumps for 2 of my packages, curl and dnsmasq, please feel free.  They
should be straightforward (though dnsmasq has not had a release in a
while, so who knows).

Cheers,
Dave

Re: [arch-dev-public] Hooks!

[Dave Reisner]

On Mon, May 02, 2016 at 05:10:15PM +0200, Christian Hesse wrote:
> Gerardo Exequiel Pozzi  on Mon, 2016/05/02 08:46:
> > On 05/02/16 07:20, Christian Hesse wrote:
> > > Massimiliano Torromeo  on Fri, 2016/04/29
> > > 12:47:  
> > >> I was also wondering about a pacman hook ro run "systemctl daemon-reload"
> > >> after systemd units installations/upgrades. This is something that was
> > >> not done even in .install files but I don't know if there was a reason
> > >> why.
> > >>
> > >> Others distros do this automatically, even the ones that do not have the
> > >> bad habit of restarting the services for you without asking. Eg: I never
> > >> had to do daemon-reload on CentOS 7.
> > >>
> > >> As far as I understand it shouldn't have any unintended side effects
> > >> (and I certainly never experienced one). Thoughts?  
> > > 
> > > Ah, and another one to reload udev rules:
> > > 
> > > [Trigger]
> > > Operation = Install
> > > Operation = Upgrade
> > > Operation = Remove
> > > Type = File
> > > Target = usr/lib/udev/rules.d/*
> > > 
> > > [Action]
> > > Description = Reload udev rule files
> > > When = PostTransaction
> > > Exec = /usr/bin/udevadm control --reload-rules
> > > Depends = systemd
> > >   
> > 
> > --reload-rules (is keep but hidden for compatibility), renamed to
> > --reload,
> 
> Ah, did not notice, yet.
> 
> > in any case, rules are reloaded automagically (thanks to inotify).
> 
> Are you sure? Even attached strace to systemd-udevd and could not see any
> activity when changing files in /usr/lib/udev/rules.d/.

inotify hasn't been used in years. This is the current mechanism:

https://github.com/systemd/systemd/blob/master/src/udev/udevd.c#L796

Rules won't be reloaded until there are events to process, and it's
rate-limited to a max of once every 3 seconds.

Re: [arch-dev-public] Hooks!

[Dave Reisner]

On Mon, May 02, 2016 at 12:20:31PM +0200, Christian Hesse wrote:
> Massimiliano Torromeo  on Fri, 2016/04/29
> 12:47:
> > I was also wondering about a pacman hook ro run "systemctl daemon-reload"
> > after systemd units installations/upgrades. This is something that was not
> > done even in .install files but I don't know if there was a reason why.
> > 
> > Others distros do this automatically, even the ones that do not have the
> > bad habit of restarting the services for you without asking. Eg: I never
> > had to do daemon-reload on CentOS 7.
> > 
> > As far as I understand it shouldn't have any unintended side effects (and I
> > certainly never experienced one). Thoughts?
> 
> Ah, and another one to reload udev rules:
> 
> [Trigger]
> Operation = Install
> Operation = Upgrade
> Operation = Remove
> Type = File
> Target = usr/lib/udev/rules.d/*
> 
> [Action]
> Description = Reload udev rule files
> When = PostTransaction
> Exec = /usr/bin/udevadm control --reload-rules

This doesn't (or shouldn't) do anything. udev periodically polls the
timestamps on all of its rules.d directories (not just /usr/lib) and
re-reads rules when it discovers they've changed.

> Depends = systemd
> -- 
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
> putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}

Re: [arch-dev-public] pacman-5.0 is in [testing]

[Dave Reisner]

In theory, but pkgfike is still a few orders of magnitude faster and,
imnsho, has a more intuitive interface and output.
On Jan 30, 2016 04:54, "Jerome Leclanche"  wrote:

> Lots of useful additions in there!
>
> Am I to understand pacman -Fs basically replaces the need for pkgfile?
>
> On Sat, Jan 30, 2016 at 2:42 AM, Allan McRae  wrote:
> > https://projects.archlinux.org/pacman.git/tree/NEWS?h=v5.0.0
>

[arch-dev-public] away from Dec 23rd to Jan 12th

[Dave Reisner]

Hi all,

I'll be stranded on a small volcanic island for a few weeks without
access to my signing key. Feel free to take care of my packages while
I'm forgetting about mainland civilization.

Cheers,
dR

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

[Dave Reisner]

On Dec 18, 2015 14:43, "Sébastien Luttringer"  wrote:
>
> Hello,
>
> I'm planning to make a new release of the filesystem package and I would
like
> to ship the following improvement.
>
> 1) Update the nsswitch.conf to default systemd recommandation for hostname
> resolution. This will fix FS#46694 [1].
>
> --- nsswitch.conf   (revision 256723)
> +++ nsswitch.conf   (working copy)
> @@ -6,7 +6,7 @@
>
>  publickey: files
>
> -hosts: files dns myhostname
> +hosts: files resolve m

I assume this is a copy paste error... Seems like you're suggesting we use
resolved by default?

> Note that nss-resolve will chain-load nss-dns if systemd-resolved.service
is
> not running.
>
> 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.

Why do we care what people do with /usr/local? Nothing we change here makes
our lives easier and only potentially inflicts pain on users who have split
between /usr/local/bin and sbin. If we were to change this, I'd suggest we
just drop /usr/local/sbin from the package. Pacman will drop tracking of
the dir and there won't be any potential need for user interaction.

> Is there any objections?
>
> Bonus question, if you have opinion on FS#45196 [2], please give them
inside
> the bug report.
>
> Cheers,
>
>
> [1] https://bugs.archlinux.org/task/46694
> [2] https://bugs.archlinux.org/task/45196
>
> --
> Sébastien "Seblu" Luttringer
> https://seblu.net | Twitter: @seblu42
> GPG: 0x2072D77A

Re: [arch-dev-public] git packages and checksums

[Dave Reisner]

On Sat, Jul 18, 2015 at 01:10:29PM -1000, Gaetan Bisson wrote:
 [2015-07-18 15:13:43 -0700] Anatol Pomozov:
  On Sat, Jul 18, 2015 at 1:04 PM, Gaetan Bisson bis...@archlinux.org wrote:
   Instead I suggest we use the full commit hash. In the example above,
   that'd become something like:
  
   _commit=9a50ce20ef60263a6c88c29470ce761fcc424f2d
   source=(git://github.com/systemd/systemd.git#commit=$_commit)
   md5sums=('SKIP')
  
  Would it be better to improve *sums=() function to work with
  directories? This will also help svn/hg based packages.
 
  A simple solution is to tar whole directory and then calculate the checksum:
  
  tar -c $DIR | md5sum
 
 This involves file attributes, so it seems the md5sum would change any
 time you do a new `git clone` even if no actual content has changed.
 
 Also I think the commit hash is an intrinsically better value because it
 is explicitly published by upstream. Just as checksums are (or should
 be) published next to release tarballs.

Tags are more explicitly published by upstreams than commit hashes. I'm
not sure I understand the benefit of switching. Why is it preferrable to
use the value rather than the pointer? What makes it better?

dR

[arch-dev-public] away on vacation 7/22-8/9

[Dave Reisner]

Hi,

I'll be away on the dates in the subject. Internet connectivity will be
sketchy at best, and I won't have access to my GPG keys. Feel free to do
whatever's needed with systemd and the rest of my packages.

dR

Re: [arch-dev-public] Namcap maintainer

[Dave Reisner]

On Fri, Dec 19, 2014 at 08:03:37AM -0500, keenerd wrote:
 On 12/14/14, Dave Reisner d...@falconindy.com wrote:
  No objections to Kyle taking over namcap alone, but I have to ask, Kyle,
  are you interested in taking on pyalpm as well?
 
 Not terribly interested, but I guess I can if I have to.  Attached is
 a quick 30 minute hack that lets pyalpm build against 4.2 and restores
 namcap functionality.  Pycman probably suffers greatly.

Almost. Missing from this patch is handling for the new 'Usage' key in
repo sections of the config parser.

 -Kyle
 http://kmkeen.com

 --- src/transaction.c 2013-04-01 08:21:10.0 -0400
 +++ src/transaction.c 2014-12-19 07:24:54.595390109 -0500
 @@ -30,7 +30,7 @@
  /** Transaction callbacks */
  extern PyObject *global_py_callbacks[N_CALLBACKS];
  
 -void pyalpm_eventcb(alpm_event_t event, void* data1, void *data2) {
 +void pyalpm_eventcb(alpm_event_type_t event, void* data1, void *data2) {

This is wrong. pyalpm_eventcb must match alpm_cb_event, which is defined
as:

typedef void (*alpm_cb_event)(alpm_event_t *);

const char *eventstr;
PyObject *obj1 = Py_None;
PyObject *obj2 = Py_None;
 @@ -59,6 +59,8 @@
  case ALPM_EVENT_INTERCONFLICTS_DONE:
eventstr = Done checking inter conflicts;
break;
 +/* deprecated in 4.2
 +* leaving these commented out while finding 4.2 equivalents

data1 and data2 are now pulled from the event itself, so you'll use
something like this in place:

  obj1 = pyalpm_package_from_pmpkg(event.package_operation.oldpkg);
  obj2 = pyalpm_package_from_pmpkg(event.package_operation.newpkg);

  case ALPM_EVENT_ADD_START:
eventstr = Adding a package;
obj1 = pyalpm_package_from_pmpkg(data1);
 @@ -86,6 +88,7 @@
obj1 = pyalpm_package_from_pmpkg(data1);
obj2 = pyalpm_package_from_pmpkg(data2);
break;
 +*/
  case ALPM_EVENT_INTEGRITY_START:
eventstr = Checking integrity;
break;
 @@ -114,12 +117,26 @@
  case ALPM_EVENT_DISKSPACE_DONE:
eventstr = Done checking disk space;
break;
 +/* deprecated in 4.2
  case ALPM_EVENT_OPTDEP_REQUIRED:
 +*/
  case ALPM_EVENT_DATABASE_MISSING:
  case ALPM_EVENT_KEYRING_START:
  case ALPM_EVENT_KEYRING_DONE:
  case ALPM_EVENT_KEY_DOWNLOAD_START:
  case ALPM_EVENT_KEY_DOWNLOAD_DONE:
 +/* new in 4.2 */
 +case ALPM_EVENT_PACKAGE_OPERATION_START:
 +case ALPM_EVENT_PACKAGE_OPERATION_DONE:
 +case ALPM_EVENT_RETRIEVE_DONE:
 +case ALPM_EVENT_RETRIEVE_FAILED:
 +case ALPM_EVENT_PKGDOWNLOAD_START:
 +case ALPM_EVENT_PKGDOWNLOAD_DONE:
 +case ALPM_EVENT_PKGDOWNLOAD_FAILED:
 +case ALPM_EVENT_OPTDEP_REMOVAL:
 +case ALPM_EVENT_PACNEW_CREATED:
 +case ALPM_EVENT_PACSAVE_CREATED:
 +case ALPM_EVENT_PACORIG_CREATED:
  default:
eventstr = unknown event;
}

Re: [arch-dev-public] Namcap maintainer

[Dave Reisner]

On Sun, Dec 14, 2014 at 11:23:40PM +1000, Allan McRae wrote:
 On 14/12/14 23:20, keenerd wrote:
  Hi devs.
  
  With your approval and permission I would like to be added to the
  maintainers for Namcap.  It aligns well with my interests and does not
  seem to have any active maintainer at present.  I'd like to
  immediately get through the backlog of patches, feature requests and
  bug reports (mine included).
  
 
 I am happy for this to happen.  I am told that we will need some patches
 to be applied with the pacman-4.2 release, so getting an active
 maintainer now would be a good thing.
 
 If no-one objects soon, I will give permissions to Kyle.
 
 Allan

namcap doesn't need attention -- it's pyalpm which needs it for the
4.2 release. I've got a few patches which work towards this (and make
namcap work with pacman-git), but they need further help from someone
who's actually interested in development to finish them off and make
pycman fully useful again.

No objections to Kyle taking over namcap alone, but I have to ask, Kyle,
are you interested in taking on pyalpm as well?

dR

[arch-dev-public] moving lz4 to [core]

[Dave Reisner]

Hi,

lz4 is growing in popularity as a compression algorithm. As of systemd
216, systemd-journald supports lz4 (in addition to xz). Benchmarks[1]
were provided at the time Zbigniew wrote the patches to show the
impressive drop in CPU required to compress journal files.

There's already a feature request to enable this[2], and a complaint
about the excessive CPU usage of XZ in the presence of a program which
doesn't behave[3] in some given environment.

So, with that, is anyone opposed to moving lz4 to [core] so that systemd
can sanely depend on it?

Cheers,
d

[1] http://lists.freedesktop.org/archives/systemd-devel/2014-July/021048.html
[2] https://bugs.archlinux.org/task/41721
[3] https://bugs.archlinux.org/task/41728

[arch-dev-public] systemd 216 coming soon to testing

[Dave Reisner]

Hi,

I'm working on the final pieces of systemd 216 packaging (will push to
[testing] tonight EST barring the unforseen). As always, there's a
number of new features/bugs, but a few gotchas might want special
mention:

For packagers:
- systemd-sysusers is now a reasonable thing as it now reads and writes
  to /etc/shadow and /etc/gshadow. This means that we can simplify the
  filesystem package immensely, and packages which want to ship their
  own runtime users can switch to this as well. Note that new IDs are
  allocated semi-arbitrarily starting from 999 and counting down. Please
  be aware of the implications of using this if your package ships files
  owned by the user you're going to create! There's still no way of
  removing users via sysusers.d, but I think this is fine (Fedora
  actually never removes users or groups).

- The never-ending NTP provider dance continues. Effective immediately,
  all files in /usr/lib/systemd/ntp-units.d are defunct, and will no
  longer be read. In exchange, extra/ntp and community/openntpd must add
  Conflicts=systemd-timesyncd.service to their service file. (chrony
  is already taken care of). timedated will no longer attempt to
  activate implementations other than timesyncd. So, use timesyncd
  unless you really care about having a full blown NTP server running.
  This currently requires systemd-networkd to be *running* (but not
  necessarily actively configuring anything). In 217, this requirement
  will likely be lifted.

For users:
- systemd no longer tells the kernel about the timezone when the RTC is
  set to localtime. An immediately visible effect of this might be that
  timestamps on FAT filesystems will be wrong (displayed in UTC).
  There's no way around this unless you play with settimeofday()
  yourself before systemd starts (this idea comes with zero warranty).

Full NEWS file:

  http://cgit.freedesktop.org/systemd/systemd/tree/NEWS

Cheers,
d

Re: [arch-dev-public] systemd 216 coming soon to testing

[Dave Reisner]

On Wed, Aug 20, 2014 at 02:25:24PM -0400, Dave Reisner wrote:
 Hi,
 
 I'm working on the final pieces of systemd 216 packaging (will push to
 [testing] tonight EST barring the unforseen). As always, there's a
 number of new features/bugs, but a few gotchas might want special
 mention:
 
 For packagers:
 - systemd-sysusers is now a reasonable thing as it now reads and writes
   to /etc/shadow and /etc/gshadow. This means that we can simplify the
   filesystem package immensely, and packages which want to ship their
   own runtime users can switch to this as well. Note that new IDs are
   allocated semi-arbitrarily starting from 999 and counting down. Please
   be aware of the implications of using this if your package ships files
   owned by the user you're going to create! There's still no way of
   removing users via sysusers.d, but I think this is fine (Fedora
   actually never removes users or groups).
 
 - The never-ending NTP provider dance continues. Effective immediately,
   all files in /usr/lib/systemd/ntp-units.d are defunct, and will no
   longer be read. In exchange, extra/ntp and community/openntpd must add
   Conflicts=systemd-timesyncd.service to their service file. (chrony
   is already taken care of). timedated will no longer attempt to
   activate implementations other than timesyncd. So, use timesyncd
   unless you really care about having a full blown NTP server running.
   This currently requires systemd-networkd to be *running* (but not
   necessarily actively configuring anything). In 217, this requirement
   will likely be lifted.
 
 For users:
 - systemd no longer tells the kernel about the timezone when the RTC is
   set to localtime. An immediately visible effect of this might be that
   timestamps on FAT filesystems will be wrong (displayed in UTC).
   There's no way around this unless you play with settimeofday()
   yourself before systemd starts (this idea comes with zero warranty).

So apparently FAT has an undocumented time_offset mount option which
takes a ($value = -12  $value = 12) to offset timestamps displayed
in the FS.

 Full NEWS file:
 
   http://cgit.freedesktop.org/systemd/systemd/tree/NEWS
 
 Cheers,
 d

Re: [arch-dev-public] Virtualbox binary modules maintainer

[Dave Reisner]

On Wed, Jul 16, 2014 at 07:26:16PM +0200, Sébastien Luttringer wrote:
 Ehlo,

500-NOTAMAILSERVER

 Last maintainer of virtualbox binary modules has resigned.

I guess this is/was you?

 These packages[1] are generated from  virtualbox-guest-dkms and
 virtualbox-host-dkms each time a new linux or linux-lts package are
 released.

Relevant pkgbases are 'virtualbox-modules' and 'virtualbox-modules-lts',
since this isn't obvious from your package list.

 Is there a volunteer to take care of them and handle rebuilds ?

I'm not interested, but this is pretty vague. How much time is involved?
How often? Are there open bugs? Have you worked with upstream at all? Do
they suck?

 Although, I would prefer remove them and let users build vbox modules
 with the dkms package. That handle perfectly multiple kernel
 installation and simplify our job.

DKMS is pretty lousy without hook functionality in the package manager.
The whole point is that you can trigger this seamlessly on
install/upgrade. Dropping this means that you simplify our job by
pushing off more responsibility on users. There *will* be bug reports if
you just drop these packages.

 [1] virtualbox-guest-modules, virtualbox-guest-modules-lts,
 virtualbox-host-modules, virtualbox-host-modules-lts.
 
 
 -- 
 Sébastien Seblu Luttringer
 https://seblu.net
 GPG: 0x2072D77A

Re: [arch-dev-public] Virtualbox binary modules maintainer

[Dave Reisner]

On Wed, Jul 16, 2014 at 09:05:50PM +0200, Sébastien Luttringer wrote:
 On 16/07/2014 19:39, Dave Reisner wrote:
  On Wed, Jul 16, 2014 at 07:26:16PM +0200, Sébastien Luttringer wrote:
  I guess this is/was you?
 It was Bartłomiej.
 
  I'm not interested, but this is pretty vague. How much time is involved?
  How often? Are there open bugs? Have you worked with upstream at all? Do
  they suck?
 
 From upstream tarball, I create virtualbox-host-dkms and
 virtualbox-guest-dkms (split packages from virtualbox pkgbase). This is
 the official way of building vbox* kernel modules. All real modules
 bugs are handled in the virtualbox package.
 
 To provide pre-compiled version of these modules for our linux and
 linux-lts packages, we have virtualbox-modules and
 virtualbox-modules-lts. Each one generate 2 packages, one for modules
 required in the hypervisor and one for modules required in the vm.
 
 Note: We don't provides pre-compiled modules for linux-grsec.
 
 AFIR, rebuild of these packages occur when:
 - New release of virtualbox (I handle them)
 - New release of the attached kernel package
 - Someone open a BR because a rebuild was not done when the kernel was
 updated.
 
 There is currently one open bug report, which will be fixed when I will
 push the last release of vbox tonight.
 
 You can have an idea of the time needed looking at the package history[1].
 
 
  DKMS is pretty lousy without hook functionality in the package manager.
  The whole point is that you can trigger this seamlessly on
  install/upgrade.
 I'm not sure the package manager is an issue here, what we want is
 build vbox modules for the running kernel.

...and you want to build modules for the kernel that was just installed,
hence, you need package manager integration. See below for why you
should care about this.

 If you enable dkms service, the modules you need for kernel you are
 running will be built and loaded during the boot. It's transparent.

Building modules on boot is doing it too late. It's on the same plane as
what our initscripts used to do -- call 'depmod -A' on bootup. It's too
late, and you're asking for a race condition. What about dkms-based
modules which you're trying to build into the initramfs? You now need to
circumvent this whole process, build the modules manually, and then
rebuild your initramfs.

Calling this early enough that it tries to avoid some of the races will
just mean that you're unnecessarily blocking boot for X minutes while
you build modules. Unless I'm missing something, that's a lousy user
experience.

Please, if you really want this to be some defacto standard for how we
handle third-party modules, we *really* need someone dedicated to adding
hook support in pacman.

 The problem is more around our way of dealing with kernel updates
 (removing running kernel headers) than pacman packages ordering. We
 already don't support the case when user upgrade the kernel and don't
 reboot (kernel vs modules mismatch) immediately.
 
  There *will* be bug reports if you just drop these packages.
 Could you be more specific?

If you're touting DKMS as the new hotness, you will absolutely need to
have replaces/conflicts on the DKMS package for the packages you want to
obviate. Otherwise, these packages will remain installed and eventually
conflict with a kernel update. Around that time, you'll see bug reports.

 I have the feeling that using dkms packages will prevent bug reports
 coverings depmod or packages was not rebuilt for the current kernel.
 
 This also simplify management for non official kernels.

This doesn't make sense. As I see it, nothing is simplified, because
nothing changes for this use case. User-built kernels can use DKMS now,
and they'll still be able to use after this change. The precompiled
module packages never had any relevance.

 Cheers,
 
 [1]
 https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/virtualbox-modules

Looks like 6 people (including yourself) have handled about ~4 builds
per month over the past year. Higher maintenance than most packages, but
certainly no higher than the cost of maintaining a single kernel package
(assuming you're Doing It Right™).

Are you, as the virtualbox maintainer, not willing to accept this shared
responsibility?

d

[arch-dev-public] systemd 215 group names

[Dave Reisner]

Hi,

If you're a [testing] user who's installed systemd 215 with a pkgrel of
1-3, you're interested in this.

A new feature of systemd, sysusers, was introduced which creates
users/groups on demand for stateless systems.  The upstream files ship
the groups 'dialout', 'tape', and 'cdrom'. With systemd-215-4, these are
properly modified to Arch's 'uucp', 'storage', and 'optical',
respectively.

If you installed a prior version, you likely now have these former
groups in your /etc/group -- these can be safely deleted, as we will not
currently use them. In other words, you can safely run:

sed -i.bkup '/^\(dialout\|tape\|cdrom\):x:/d' /etc/group

Make sure to diff the result against /etc/group.bkup afterwards and
delete the backup if not needed.

Cheers,
Dave

[arch-dev-public] Away this week

[Dave Reisner]

I'm traveling this week, and it seems my internet at home has decided to go
away. Consider me off the air for packaging related duties until Saturday.
I will likely still be reading email.

Cheers,
Dave

Re: [arch-dev-public] Mirror request are not being handled; status of Jakob?

[Dave Reisner]

On Tue, May 20, 2014 at 09:11:54AM -0500, Dan McGee wrote:
 On Tue, May 20, 2014 at 8:50 AM, Florian Pritz bluew...@xinu.at wrote:
 
  Hi,
 
  Anyone knows what happened to Jakob? Looks like he didn't respond to any
  mirror requests for the last 5 months[1].
 
  [1]:
  https://bugs.archlinux.org/index.php?project=1status[]=dev=fleetdo=index
 
  CC'ing arch-dev-public and Jakob for a wider audience. Discussion should
  probably continue on arch-mirrors.
 
 
 I have been getting to these on occasion when I have the time, but could
 really use some help if someone wants to step up and volunteer, current
 developer or not. I don't even know most of these tickets exist since they
 aren't assigned to me and I don't regularly search for them.
 
 Let me know if you are interested in helping, it consists of probably 15-30
 minutes a week on average of the following type of stuff:
 
 * Keeping an eye on the mirror status page for out-of-date or broken mirrors 
 and notifying admins via email
 * Adding new mirrors as necessary, and deciding when to say no to a request
 * Responding to tickets with insufficient info
 
 -Dan

Joannes Löthberg (demize on IRC, Kyrias on Flyspray) has expressed an
interest in helping out here. He's been poking some of the
mirror-related requests on Flyspray recently, essentially already doing
the first and third mentioned responsibilities.

d

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

[Dave Reisner]

On Apr 2, 2014 5:56 AM, Thomas Bächler tho...@archlinux.org 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

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

[Dave Reisner]

On Wed, Apr 02, 2014 at 01:21:32PM +0200, Thomas Bächler wrote:
 Am 02.04.2014 13:17, schrieb Dave Reisner:
  On Apr 2, 2014 5:56 AM, Thomas Bächler tho...@archlinux.org 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?
 

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

d

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

[Dave Reisner]

On Wed, Apr 02, 2014 at 04:21:04PM +0200, Thomas Bächler wrote:
 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
 

Yes, that was one possibility. I'm testing a patch now.

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

[Dave Reisner]

On Thu, Mar 27, 2014 at 04:15:21PM +0100, Thomas Bächler wrote:
 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.)
 

Heh. Now they have *2* modules of debatable quality.

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

[Dave Reisner]

On Wed, Mar 26, 2014 at 07:56:26PM +0100, Thomas Bächler wrote:
 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

 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.

Very much agreed. Though, I wouldn't mind if we kept yama around in some
disabled form if possible. There's no userspace component here, just the
ptrace_scope knob in sysctl, which a lot of other distros enable.  It
affects a rather small number of app, but potentially closes off a
fairly large security concern.

 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.

CRIU userspace tools are in the AUR. +1 to dropping this unless we have
someone to wants to actually maintain this in the repos.

 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.

Looks like audit is still built into our kernel. Wasn't this meant to be
reverted as well?

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

[Dave Reisner]

On Wed, Mar 26, 2014 at 06:53:43PM -0400, Daniel Micay wrote:
 On 26/03/14 02:56 PM, Thomas Bächler wrote:
  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.
 
 I think we should drop x32 support if no one is planning on packaging
 the minimum of a compiler and standard C library. It's cool, but no one
 appears to be very interested in using it in the real world. You would
 probably get bigger wins from recompiling with -march=native, so I
 somewhat doubt that anyone grasping for the last bit of performance will
 use our binaries anyway.
 
 This was already responsible for a security vulnerability in Arch:
 
 http://seclists.org/oss-sec/2014/q1/187
 

Ah, I knew I forgot something from my last email. Yes, x32 should go
away if we aren't interested in hosting the toolchain for it.

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

[Dave Reisner]

On Mon, Mar 24, 2014 at 11:35:36PM +0100, Sébastien Luttringer wrote:
 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.
 
 My current suggestion is to keep the current server and hierarchy and to
 move it under an archlinux.org subdomain. So far, best suggestions are:
 - archive.archlinux.org
 - museum.archlinux.org
 - rollback.archlinux.org
 
 Current cost in byte is:
 # du -hcs 2013 2014
 111G2013
 55G 2014
 165Gtotal
 
 In a second time, we could:
 - move the files on an official server

Does 2013 cover the whole year? You're suggesting that 2014 will occupy
over 200GB. We'd need new infrastructure for this, and it comes with a
monetary cost we'd need to accomodate (or are you proposing that you'll
be paying for this forever?). Have you looked into how much this would
be per month with a potential provider? How much bandwidth is associated
with this? How long would packages be retained? What about resource
planning for future growth?

 - move installer backups[2]

Not sure why old install ISOs are interesting for anything but
nostalgia.

 - add AUR

This doesn't make sense. We already have a git repo which does a far
better job of compressing the deltas between versions of text files.

 - backup them (by mirroring or others)

There's going to be a large cost here and I doubt it's any potential
benefit. Do you get complaints/requests from your users to mirror your
implementation?

 
 Current used scripts are freely available here[3].
 
 [1] https://wiki.archlinux.org/index.php/ARM
 [2] https://users.archlinux.de/~pierre/archive/
 [3] https://github.com/seblu/armtools
 
 -- 
 Sébastien Seblu Luttringer
 https://seblu.net | Twitter: @seblu42
 GPG: 0x2072D77A
 

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

[Dave Reisner]

On Tue, Mar 25, 2014 at 12:55:51AM +0100, Sébastien Luttringer wrote:
 On 24/03/2014 23:50, Dave Reisner wrote:
  On Mon, Mar 24, 2014 at 11:35:36PM +0100, Sébastien Luttringer wrote:
  Does 2013 cover the whole year? 
 Four full months. More details in listing this page[1]
 
  You're suggesting that 2014 will occupy
  over 200GB. We'd need new infrastructure for this, and it comes with a
  monetary cost we'd need to accomodate (or are you proposing that you'll
  be paying for this forever?). 
 I don't suggest to pay forever, one of the benefits of moving this, is
 to stop rely on one guy. We already suffer of a previous shutdown on
 this service.

Right, but throwing this responsibility on the arms of Arch developers
isn't really a solution, either, without quiescence. You seem to be of
the mindset of that adding this to the archlinux.org domain will
magically lighten your own sysadmin load.

While I think the idea is neat, I don't think is has a place underneath
archlinux.org -- we'd be taking a step towards supporting partial
upgrades (which we refuse to support everywhere else). Before you
mention the AUR, remember that the AUR hosts source packages; not binary
packages.

  Have you looked into how much this would
  be per month with a potential provider? How much bandwidth is associated
  with this? 
 The current server cost is 16.99€/month excl. VAT with 2x1TB HDD with
 1Gbit/s connectivity, 200Mbit/s internet bandwidth and unlimited traffic.
 
 A cheap solution based on a dedibox classic[2] with 2x1TB, 1 Gbit/s con,
 150Mbit/s internet and unlimited traffic for 29.99€/month excl. VAT.
 should be sufficient.
 
 A more future proof solution may based on a dedibox pro[3] with 2x3TB
 drives, with 400Mbit/s internet bandwidth and unlimited traffic for
 69€/month excl. VAT.

And the SLA? This all seems reasonable at a glance, but I can't speak to
how this would impact our budgeting.

 Of course, any Hetzner alternative may fit, but traffic limitation may
 cause extra cost that we don't have with online.net offers.
 
  How long would packages be retained? What about resource
  planning for future growth?
 My suggestion would to keep them as far as we can, until costs is not a
 showstopper. With a 1TB server and 300GB by year, we can keep ~3 years.
 
  - add AUR
  
  This doesn't make sense. We already have a git repo which does a far
  better job of compressing the deltas between versions of text files.
 Keeping the git backend or not, it makes sense to me to move this from
 the build server (pkgbuild.com) to the archive server (something like
 archive.archlinux.org).

Sure, I agree with this. Our serving structure is pretty strange and it
doesn't make sense to host the repo on the build server for any other
reason than: this is where we had unallocated resources.

 Git is an awesome SCM, but it was not think to backup stuff, especially

You lost me here. git is made up entirely of deltas and serves as a
distributed backup. It's *really* *good* at this, even on wide trees.

 with a big directory tree. My feeling trying to find a previous version
 of a PKGBUILD with aur-mirror.git is:
 - a very long time to fetch the repository
 - a space based dig into changelog to find the right commit for my date
 - a long checkout to get the tree at this commit

Seems like this is just three different ways to spin the same point. We
can restructure to repo to make it more clone-friendly if that's all
that's needed.

 Having something with faster access and in a similar hierarchy may have
 use cases.

How often do you use the git repo?

  - backup them (by mirroring or others)
  
  There's going to be a large cost here and I doubt it's any potential
  benefit. Do you get complaints/requests from your users to mirror your
  implementation?
 No extra cost is expected for mirroring, which is a kind of distributed
 backup. I see at least 2 potentials benefits for mirroring:

Are you really suggesting that mirroring 300GB-3TB of data has no
cost? Who's hosting the mirrors? Have they agreed to shoulder the
additional storage and bandwidth requirements?

 - Better latency around the world.
 - Get our data back in case of disaster recovery.
 
 Of course, I suggest to keep these mirrors separate from our packages
 mirrors. Purpose and HW requirement are not the same.
 
 The only complain I get is because this service is not official and rely
 on my health.
 I had 3 requests:
 - One guy for mirroring because of latency.
 - One from ArchARM asking to add ARM to their project :)
 - One from a guy asking to add AUR support.

Do you have any metrics to show how many 30 day users you have?
Downloads per day? Week? Bandwidth consumed? I'm really interested in
knowing how much impact this actually has

d

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

[Dave Reisner]

On Wed, Mar 12, 2014 at 07:16:18PM +0100, Thomas Bächler wrote:
 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.
 
 

Fixed in SVN.

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

[Dave Reisner]

On Mon, Mar 10, 2014 at 10:44:12PM -0400, Dave Reisner wrote:
 On Sun, Mar 09, 2014 at 09:36:39AM -0400, Dave Reisner wrote:
  
  On Mar 9, 2014 9:31 AM, Thomas Bächler tho...@archlinux.org wrote:
  
   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.
  
  Sigh. I probably have time to fix this today.
  
 
 Sadly, I didn't get to this yesterday and I spent most of today
 flying cross-country. Because we never ditched the libsystemd provide on
 systemd, we can do this piecemeal. I'm pushing a split of util-linux
 into testing tonight, and I'll handle the libsystemd/systemd split
 tomorrow or Wednesday when systemd 211 is released.
 
 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.

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

[Dave Reisner]

On Sun, Mar 09, 2014 at 09:36:39AM -0400, Dave Reisner wrote:
 
 On Mar 9, 2014 9:31 AM, Thomas Bächler tho...@archlinux.org wrote:
 
  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.
 
 Sigh. I probably have time to fix this today.
 

Sadly, I didn't get to this yesterday and I spent most of today
flying cross-country. Because we never ditched the libsystemd provide on
systemd, we can do this piecemeal. I'm pushing a split of util-linux
into testing tonight, and I'll handle the libsystemd/systemd split
tomorrow or Wednesday when systemd 211 is released.

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.

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

[Dave Reisner]

On Mar 9, 2014 9:31 AM, Thomas Bächler tho...@archlinux.org wrote:

 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.

Sigh. I probably have time to fix this today.

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

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

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

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

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

***
Because of the number of substantial internal changes, the post_upgrade
will NOT reexec systemd. I strongly advise you to, instead, reboot after
upgrading. If you *do* reexec systemd, you'll see all of the applets
(machined, logind, journald, etc) killed once when they don't respond to
an expected watchdog ping. There may be other breakages of varying
verbosity.
***

The full list of changes is here:

http://cgit.freedesktop.org/systemd/systemd/tree/NEWS

Packaging changes of varying importance:

- The network interface naming mechanism has been changed. The
  post_upgrade() has a fairly naive heuristic to try and preserve the
  existing behavior.
- systemd's in-house seccomp filtering has been replaced by linkage to
  libseccomp (now that the API doesn't suck). I'd really like to keep
  support for this in our package, so it means moving libseccomp from
  [extra] to [core]. If it means I need to adopt libseccomp, I'm willing
  to do this.
- 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.
- No, I will not ever be building v209 with --enable-kdbus.

Happy testing,
Dave

Re: [arch-dev-public] drift between repo packages and ABS

[Dave Reisner]

On Thu, Jan 23, 2014 at 08:45:28AM +1000, Allan McRae wrote:
 On 23/01/14 05:14, Dave Reisner wrote:
  I won't be tracking down individual
  people to fix these, but please do a pkgrel bump and fix these when you
  get a chance.
 
 These deserve tracked down...
 
  [community]
  rt3562sta - depends

Looks like I was mistaken about this one -- it's just a parser failure
on my side.

  madman - depends
  kiwi - depends

Filed bugs against these two.

 
 Seriously!  Bad packager!  BAD!
 

No biscuit.

[arch-dev-public] drift between repo packages and ABS

[Dave Reisner]

Hi,

I've noticed that there's a significant number of packages which show
drift between the repo package and the PKGBUILD in ABS. This occurs
because devs/TUs update the PKGBUILD in SVN and call archrelease (or one
of its derivatives such as extrapkg) without releasing the package to
the repos. I don't think we should be doing this. It's fine if you want
to update trunk, but the repo directories should always match the live
repo package.

Here's the list with their respective mismatches. While most of them are
simple metadata, there's definitely more severe cases where attributes
like dependencies have drifted. I won't be tracking down individual
people to fix these, but please do a pkgrel bump and fix these when you
get a chance.

Cheers,
Dave

[extra]
purple-plugin-pack - url
hyphen-de - url
antlr2 - pkgdesc
kdeutils-kgpg - makedepends
msmtp - makedepends
chromium - makedepends
gcr - makedepends
libgnome-keyring - makedepends

[community]
libircclient - pkgdesc
bumblebee - optdepends
cgminer - makedepends
rt3562sta - depends
madman - depends
cgit - url
sisctrl - pkgdesc
packagekit-qt2 - pkgdesc
python2-packagekit - pkgdesc
gcompris-data - makedepends
osmo - makedepends
cksfv - url
wmname - url
perl-font-afm - url
xdelta3 - pkgdesc
rubinius - makedepends
pawm - url
blender - makedepends
kiwi - depends
liblightdm-qt4 - pkgdesc
liblightdm-qt5 - pkgdesc

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

[Dave Reisner]

On Thu, Dec 12, 2013 at 10:14:11PM +1000, Allan McRae wrote:
 Seems there is nothing broken by the binutils update.  Mostly source
 issues from changes made to files on svn trunk without updating checksum.
 
 
 FAILcurl
 0001-glob-fix-regression-from-commit-5ca96cb844.patch ... FAILED

Fixed.

 FAILdhcpcd
 dhcpcd.service ... FAILED
 
 FAILgrub
 util/grub-mkfont.c:46:30: fatal error: freetype/ftsynth.h: No such file
 or directory
 
 FAILipw2100-fw
 == ERROR: Failure while downloading ipw2100-fw-1.3.tgz
 
 FAILipw2200-fw
 == ERROR: Failure while downloading ipw2200-fw-3.1.tgz
 
 FAILisl
 == ERROR: Failure while downloading isl-0.12.1.tar.bz2
 
 FAILlibarchive
 22531545514043e04633e1c015c7540b9de9dbe4.patch ... FAILED

Fixed.

 FAILlicenses
 mpl-1.1.txt ... FAILED
 ruby-license.txt ... FAILED
 
 FAILlogrotate
 logrotate.conf ... FAILED
 
 FAILshadow
 == ERROR: Failure while downloading shadow-4.1.5.1.tar.bz2

Alioth has restructured and shadow hasn't bothered to do anything,
leaving their source (tarballs and SVN repo) completely inaccessible.
Rather irresponsible on both sides, IMO. Mailing list and IRC are dead,
as expected.

I happen to have the tarball and GPG sig kept locally, so I've uploaded
them to nymeria. I'll fix up the PKGBUILD once it replicates to FTP.

 FAILxinetd
 == ERROR: Failure while downloading xinetd-2.3.15.tar.gz
 

[arch-dev-public] Dropping sysvinit-tools

[Dave Reisner]

The next release of procps-ng will contain pidof and clash with
sysvinit-tools. The obvious decision is to use the maintained source of
pidof. At this point, we'll be left with 3 binaries in sysvinit-tools,
all which I propose are all obsolete: fstab-decode, killall5, and bootlogd.

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

Cheers,
Dave

Re: [arch-dev-public] [core] build status - 2013-10-24

[Dave Reisner]

On Thu, Oct 24, 2013 at 02:32:36PM +1000, Allan McRae wrote:
 I rebuilt all of [core] from trunk to see if the static library removal
 from the toolchain had any unwanted side effects.  Here are the results:
 
 
 Source download failure:
 FAILdhcpcd
 FAILdialog
 FAILisl
 FAILipw2100-fw
 FAILipw2200-fw
 FAILopenresolv
 FAILxinetd
 
 
 makepkg/devtools failure to ensure VCS tools needed for source download:
 FAILgrub
 
 
 Checksum error:
 FAILlicenses
 mpl-1.1.txt ... FAILED
 ruby-license.txt ... FAILED
 
 
 Build failures:
 FAILkrb5
 deltat.c:215:5: error: conflicting types for 'yyparse'  (bison
 incompatibilty?)
 FAILsysvinit-tools
 sulogin.c:(.text.startup+0x2f0): undefined reference to `crypt'

Garbage...

# Additional libs for GNU libc.
ifneq ($(wildcard /usr/lib*/libcrypt.a),)
  SULOGINLIBS»+= -lcrypt
endif

I'm inclined to revamp the PKGBUILD to only build what we use and
explicitly package it. Will fix

 
 

Re: [arch-dev-public] Add guile support to make-4.0?

[Dave Reisner]

On Wed, Oct 09, 2013 at 07:36:12PM +1000, Allan McRae wrote:
 make-4.0 has this new feature:
 
 * New feature: GNU Guile integration
   This version of GNU make can be compiled with GNU Guile integration.
   GNU Guile serves as an embedded extension language for make.
   See the Guile Function section in the GNU Make manual for details.
   Currently GNU Guile 1.8 and 2.0+ are supported.  In Guile 1.8 there is no
   support for internationalized character sets.  In Guile 2.0+, scripts
 can be
   encoded in UTF-8.
 
 I'd like to enable it so we can hang with the cool kids...  Building
 make against guile means we will need to bring it to [core] along with
 its dependencies gc and libunistring.  Using optdepends is not an option.
 
 Any objections to this?
 
 Allan

This seems pretty useless. Is there an immediate want/need for this
somewhere?

I'm seeing evidence of this being a long time in development[1], but a
lot of the propaganda in favor of the feature seems to be around the
make integration in Guile, not vice versa... weird stuff. I'm plainly
surprised that there doesn't seem to be any overlap between proponents
of this feature and Guix...

[1] http://lists.gnu.org/archive/html/guile-user/2011-09/msg00038.html

Re: [arch-dev-public] Git

[Dave Reisner]

On Mon, Oct 07, 2013 at 09:47:18AM +0200, Massimiliano Torromeo wrote:
 What about handling mass-edits?

Really, how often do you do this? Why would your workflow be so
different?  Instead of 'svn up', you'd 'git clone'. Instead of 'svn
commit', you'd write a for loop with 'git commit'. The actual editing
remains exactly the same.

 Right now I feel the approach of having one repo for core/extra and one for
 community with branches for testing would be better, my only issue with
 this being that I wouldn't tag each package release in it and I don't
 really see the need for it.

The fact is, git does not perform well with wide trees. In your world,
each branch would be fully divergent from the root. This leads to bloat
and poor performance. Switching branches would, over time, become
increasingly slow as you'd need to rebuild the entire tree. In essence,
you'd be poorly mimicking subtress, submodules, or repo-for-each, but
with a restricted feature set. Some git operations cease to make sense
in this sort of world -- tagging is less obvious, and branching would be
weird since you're in a restricted namespace.

d

[arch-dev-public] Fwd: [ANNOUNCE] util-linux v2.24-rc1

[Dave Reisner]

Hi all,

Karel has announced the first RC for util-linux 2.24. In support of
this, I'm providing packages for brave testers:

  [falconindy]
  Server = http://repo.falconindy.com/$arch/$repo

Two things to note:

1) Debug packages are present in the repo in case they're needed.
2) A rebuild of sysvinit-tools is included as the util-linux RC includes
last and lastb (and conflicts with core/sysvinit-tools).

Best bet is to simply enable the extra repo (above [testing]) and -Syu.

For any packaging bugs, please email me at dreis...@archlinux.org (do
not post on flyspray). For any upstream bugs, please post details on
util-li...@vger.kernel.org or use the GitHub tracker.

The release highlights are too long to append, so here's a link:

http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/7964

cheers,
Dave

Re: [arch-dev-public] systemd 207 ignores /etc/sysctl.conf

[Dave Reisner]

On Fri, Sep 13, 2013 at 01:12:20PM +0200, Pierre Schmitz wrote:
 Hi,
 
 a new features in systemd 207 is to no longer read /etc/sysctl.conf.
 Instead /etc/sysctl.d/*.conf has to be used. Imho this needs a news item
 and we also need to think about what to do with the file we ship as part
 of procps-ng.

I've been talking about shipping that file in /usr/lib/sysctl.d for a
while, but never got around to filing a bug (or doing it myself). We
might also consider just dropping it, since this is in line with the
upstream default.

There's some bugfixes I should backport to 207 (sigh), so I can add a
post_upgrade message to mention this once we figure out the direction
we're going in.

 From the systemd changelog:
 * The systemd-sysctl tool no longer natively reads the
   file /etc/sysctl.conf. If desired, the file should be
   symlinked from /etc/sysctl.d/99-sysctl.conf. Apart from
   providing legacy support by a symlink rather than built-in
   code, it also makes the otherwise hidden order of application
   of the different files visible.
 
 Greetings,
 
 Pierre
 
 -- 
 Pierre Schmitz, https://pierre-schmitz.com

Re: [arch-dev-public] [FYI] systemd 205, cgroup attribute changes

[Dave Reisner]

On Wed, Jul 03, 2013 at 02:44:12PM -0400, Dave Reisner wrote:
 On Wed, Jul 03, 2013 at 12:48:49PM -0400, Dave Reisner wrote:
  Hey all,
  
  systemd 205 was just tagged, and brings some major, promised, cgroup changes
  [1]. I'll be pushing this into [testing] tonight. I do NOT expect that this
  release will ever move to [core], but maybe I'll be pleasantly surprised.
  
  The NEWS file [2] is fairly large and warrants a read, particularly about 
  the
  new machine API.
  
  Cheers,
  Dave
  
  [1] 
  http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html
  [2] http://cgit.freedesktop.org/systemd/systemd/tree/NEWS
 
 On second thought, this may not be hitting [testing] so soon. systemd
 --user sessions will be broken, and I need to work out exactly what's
 happening with some of the applets like logind. I think the best course
 of action for this upgrade may be to simply advise a reboot.
 
 d

If anyone wants a package to play with anyways, I've setup a repo:

[falconindy]
Server = http://repo.falconindy.com/$arch

Apologies if your DNS hasn't caught up for the A record yet -- you can
find it on he.net:

$ host repo.falconindy.com ns1.he.net

level3 and openDNS seem to have scavenged the record already, while
google has not.

Have fun.

[arch-dev-public] [FYI] systemd 205, cgroup attribute changes

[Dave Reisner]

Hey all,

systemd 205 was just tagged, and brings some major, promised, cgroup
changes [1]. I'll be pushing this into [testing] tonight. I do NOT expect
that this release will ever move to [core], but maybe I'll be pleasantly
surprised.

The NEWS file [2] is fairly large and warrants a read, particularly about
the new machine API.

Cheers,
Dave

[1]
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html
[2] http://cgit.freedesktop.org/systemd/systemd/tree/NEWS

Re: [arch-dev-public] [FYI] systemd 205, cgroup attribute changes

[Dave Reisner]

On Wed, Jul 03, 2013 at 12:48:49PM -0400, Dave Reisner wrote:
 Hey all,
 
 systemd 205 was just tagged, and brings some major, promised, cgroup changes
 [1]. I'll be pushing this into [testing] tonight. I do NOT expect that this
 release will ever move to [core], but maybe I'll be pleasantly surprised.
 
 The NEWS file [2] is fairly large and warrants a read, particularly about the
 new machine API.
 
 Cheers,
 Dave
 
 [1] http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html
 [2] http://cgit.freedesktop.org/systemd/systemd/tree/NEWS

On second thought, this may not be hitting [testing] so soon. systemd
--user sessions will be broken, and I need to work out exactly what's
happening with some of the applets like logind. I think the best course
of action for this upgrade may be to simply advise a reboot.

d

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

[Dave Reisner]

On Jun 22, 2013 2:49 PM, Thomas Bächler tho...@archlinux.org wrote:

 Am 22.06.2013 20:10, schrieb Pierre Schmitz:
  Am 22.06.2013 17:33, schrieb Thomas Bächler:
  Setting up Arch on a root server should be as easy as this:
  * Boot rescue system, make sure you have Linux 2.6.32 or later
  * Download tarball from Arch, extract to /tmp/root.x86_64/
  * Set up partitions and such, mount to /tmp/root.x86_64/mnt/
  * chroot /tmp/root.x86_64/ (well, also some bind-mounts)
  * pacman-key --populate archlinux
  * pacstrap /mnt base and follow the installation guide
 
  I'd like to generate such tarballs regularly (monthly like our ISOs?)
  and put them on our mirrors, unless there are objections.
 
  Good idea. I had something like this in mind for some time; I did not
  think of putting only pacstrap and deps into the tar though.

 I think I tested this once and it is sufficient. As a plus, it has all
 dependencies so you can use pacman to install more packages into the
chroot.

  I wonder if you could use arch-chroot isntead of just chroot here.

 It requires bash 4 - if that's not installed on the host, arch-chroot
 will not work. I would rather provide instructions involving manual
 bind-mounting and chroot.

If you think its worthwhile to make the install scripts bash 3 compat I can
look into doing this.


  You
  can also use the pacman.conf from the releng scripts.

 I pretty much used the default pacman.conf from our packages (also
 enabled Color, but that didn't do anything). Is the releng one different?

  And to be safe you
  should prefix pacstrap with a setarch call.

 Already done as per Gerardo's suggestion: https://paste.xinu.at/lNIrq/

  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.

[arch-dev-public] Fwd: [systemd-devel] [HEADSUP] systemd cgroup changes

[Dave Reisner]

FYI, for those not subscribed to systemd-devel. Doesn't seem like this
will affect too much, unless you've been heavily tweaking your services.

- Forwarded message from Lennart Poettering lenn...@poettering.net -

 Date: Mon, 17 Jun 2013 14:49:55 +0200
 From: Lennart Poettering lenn...@poettering.net
 To: systemd Mailing List systemd-de...@lists.freedesktop.org
 Cc: Tejun Heo t...@kernel.org
 Subject: [systemd-devel] [HEADSUP] systemd cgroup changes
 
 Heya,
 
 in the past weeks we have been sitting down with the cgroup maintainer
 in the kernel, Tejun Heo, at a number of conferences. During these
 discussions it became very clear to us that the way systemd currently
 exposes cgroups exposes too much of the guts of it, and is incompatible
 with how the kernel cgroup subsystem will be cleaned up in the near-term
 feature.
 
 Hence I'd like to let everybody in the systemd community know that the
 cgroup settings, commands and APIs in systemd will change soon. Please
 be aware of this when you make use of advanced cgroup functionality.
 
 - The functionality to define orthogonal cgroup trees for the various
   controllers will be removed. In fact we'll likely remove the entire
   API for setting abritrary per-controller paths for each unit. Instead
   we will introduce a new concept of Slices which will allow you to
   partition system resources in a tree and move units, users, and
   machines to arbitrary places in it. There will only be a single cgroup
   tree, but the various controllers may be enabled/disabled separately
   for each group, so that individual controllers might only see a
   subtree of the full tree, but not orthogonal trees anymore. The
   ConrolGroup= unit setting will go away, and be replaced by Slice= plus
   EnableControllers= or so.
 
 - ControlGroupPersistent= will likely go away, systemd will be the only
   component of the OS that sets up the cgroup tree.
 
 - ControlGroupAttribute= will most likely go away entirely. Instead we
   will introduce more high level controls like the existing CPUShares=,
   MemoryLimit= and so on. (BTW, if there's a specific attribute we currently 
 don't
   cover but which you really need let us know and we will see if we can
   add a high-level control for it.)
 
 - CPUShares=, MemoryLimit= and so on will continue to exist as before.
 
 - systemctl set-cgroup will go away, and be replaced by systemctl
   set-slice or something similar.
 
 - systemctl set-cgroup-attr will go away, and be replaced by
   systemctl set-attr or so, which only can set the high level
   attributes.
 
 - The (currently undocumented) bus APIs for cgroup controls will be
   replaced.
 
 Sorry for this disruption. Thankfully we have not documented these APIs
 yet and we haven't made the funcionality too widely known. We hate to
 make incompatible changes like this, but in this case it's probably
 better to clean this up early when it is not often used instead of late
 when everybody already uses this.
 
 This will remove a few bits of functionality but all in all give you a
 lot more back. For example, the slice functionality will provide you
 with a powerful and naturally built-in way to partition your resources
 in arbitrary ways, and can be used to not only assign resource limits to
 systemd units but also login users and machines.
 
 We haven't hashed out all the details yet, but expect this to land very
 soon in git.
 
 Thanks,
 
 Lennart
 
 -- 
 Lennart Poettering - Red Hat, Inc.
 ___
 systemd-devel mailing list
 systemd-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

- End forwarded message -

Re: [arch-dev-public] Integrity Check i686: core, extra, community 14-06-2013

[Dave Reisner]

On Fri, Jun 14, 2013 at 04:09:03PM +0200, Thomas Bächler wrote:
 Am 14.06.2013 16:04, schrieb repoma...@archlinux.org:
  Repo Hierarchy for Dependencies
  -
  core/grub-common depends on extra/freetype2 (488 extra (make)deps to pull)
  core/grub-common depends on extra/fuse (488 extra (make)deps to pull)
  core/grub-efi-i386 depends on extra/efibootmgr (488 extra (make)deps to 
  pull)
  core/grub-efi-x86_64 depends on extra/efibootmgr (488 extra (make)deps to 
  pull)
  core/nfs-utils depends on extra/sqlite (488 extra (make)deps to pull)
 
 What happened here? [core] was once self-contained, now it isn't - and
 fixing that would blow it up considerably. Do we no longer care?
 
 

Fuck it, move grub to extra. When your bootloader depends on a font
rendering package and FUSE, you have bigger problems than repository
bloat.

I'd also suggest we move sqlite to an optdep of nfs-utils, as well. It
appears that only nfsdcltrack links to sqlite, and this isn't something
that everyone needs to run. Even the manpage points out that the daemon
is essentially for working around edge cases. Epic fail, RedHat.

d

Re: [arch-dev-public] Junior Devs

[Dave Reisner]

On Mon, Jun 03, 2013 at 04:37:44PM +0200, Tom Gundersen wrote:
 Hi guys,
 
 This was brought up a few times, so I'd like some clarification.
 
 What restrictions (apart from the possibility of getting the boot, and
 no read-access to arch-dev) do we put on Junior devs? It used to be
 that they could not push packages, but that is no longer a technical
 limitation. Should we still enforce it? Is there a restriction with
 respect to [core]?

Junior devs do not have access to arch-dev, and they cannot write to
[core]. However, I think these same limitations apply to new devs as
well (at least, they applied to me and others).

 My preference would be to not have any limitation, but that they
 should be instructed to bring things up on ML / IRC when doing stuff
 for the first time to avoid problems.

Some random thoughts:

The only real difference that I can see between a full fledged dev and a
junior is the presence of a mentor. This is probably something we should
provide for all new devs, junior or not -- likely the same person who
proposed their recruitment, similar to how TUs operate.

Of course, I suspect that most people we hire wouldn't need such a
mentor -- they're all smart ponies who probably just need a nudge in the
right direction learning to grapple with the mess that is our SVN/repo
setup.

I tend to think I'm in support of getting rid of the junior dev title,
but I do think that we should retain some sort of small grace period for
all new devs.

d

Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

[Dave Reisner]

On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote:
 On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski
 bpiotrow...@nymeria.archlinux.org wrote:
  Date: Tuesday, May 14, 2013 @ 22:22:08
Author: bpiotrowski
  Revision: 90846
 
  upgpkg: fail2ban 0.8.8-3
 
  - correct path to sendmail due to migration to /usr/bin
 I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail.
 
 This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and
 all others  rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx,
 etc).
 
 By example,
 # mail -s toto se...@seblu.net
 test
 .
 EOT
 /usr/sbin/sendmail: No such file or directory
 /root/dead.letter 9/210
 . . . message not sent.
 
 I think we should do this correctly and rebuild /usr/sbin/sendmail in
 one shot, or include it in the global switch.

It's only hardcoded as /usr/sbin/sendmail for mailx because that's what
the PKGBUILD for heirloom-mailx sets it to. Other packages can be fixed
as well.

Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

[Dave Reisner]

On Tue, May 14, 2013 at 11:07:59PM +0200, Tom Gundersen wrote:
 On Tue, May 14, 2013 at 10:49 PM, Dave Reisner d...@falconindy.com wrote:
  On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote:
  On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski
  bpiotrow...@nymeria.archlinux.org wrote:
   Date: Tuesday, May 14, 2013 @ 22:22:08
 Author: bpiotrowski
   Revision: 90846
  
   upgpkg: fail2ban 0.8.8-3
  
   - correct path to sendmail due to migration to /usr/bin
  I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail.
 
  This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and
  all others  rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx,
  etc).
 
  By example,
  # mail -s toto se...@seblu.net
  test
  .
  EOT
  /usr/sbin/sendmail: No such file or directory
  /root/dead.letter 9/210
  . . . message not sent.
 
  I think we should do this correctly and rebuild /usr/sbin/sendmail in
  one shot, or include it in the global switch.
 
  It's only hardcoded as /usr/sbin/sendmail for mailx because that's what
  the PKGBUILD for heirloom-mailx sets it to. Other packages can be fixed
  as well.
 
 I'm not following. If this path is hardcoded in several packages (and
 presumably in lots of custom packages/scripts), isn't this precisely
 one of the cases where we should delay the move until we do the proper
 usrmove and create the compat symlinks?
 
 Cheers,
 
 Tom

Expanding on that logic, why aren't we just doing this all at once?

Re: [arch-dev-public] Merging the bin directories

[Dave Reisner]

On Sun, May 12, 2013 at 01:54:34PM +0200, Thomas Bächler wrote:
 Am 12.05.2013 13:13, schrieb Tom Gundersen:
  List of showstoppers:
 
  - Shells (with hardcoded paths in users' passwd)
  - fsck helpers (all hardcoded to be in /sbin)
  
  All mount and fsck helpers should be ok to move to /usr/bin. At least
  from mount and fsck's point of view, did you have something else in
  mind?.
 
 They used to be hardcoded to /sbin/mount.$FOO and /sbin/fsck.$FOO, has
 that changed?
 
 

It's okay to move helpers like fsck.ext4 -- fsck itself has a lookup
path which we can set to whatever we want. We currently append
/usr/bin:/usr/sbin to the default of /sbin:/sbin/fs.d:/sbin/fs.

It's not okay to move /sbin/fsck itself.

$ strings /usr/lib/systemd/systemd-fsck | grep -F /sbin/fsck
/sbin/fsck

[arch-dev-public] [mkinitcpio] Release 0.14.0

[Dave Reisner]

Hi all,

I've just released mkinitcpio 0.14.0 into the wild which is a mix of bug
fixes and new features[1]. I wanted to point out that because of a fix for
FS#34255, mkinitcpio will now report when *all* possible firmware cannot
be found for a module.

Users with the block hook in their HOOKS may see warnings show up for
missing firmware on some unfamiliar modules during creation of the
fallback image. Please note that these are warnings *only* and can
generally be ignored. Obviously, if you start seeing warnings about
missing firmware your modules you do use, you'll appreciate this change.

New bugs can always be reported on https://bugs.archlinux.org.

Cheers,
Dave

[1]https://projects.archlinux.org/mkinitcpio.git/log/?id=0.13.0..0.14.0


pgpFGs_bHpNTa.pgp
Description: PGP signature

Re: [arch-dev-public] [aur-general] Substitute nss_ldap/pam_ldap from [Extra] to nss-pam-ldapd

[Dave Reisner]

On Sat, Mar 02, 2013 at 01:32:48PM -0300, Thiago Kenji Okada wrote:
 nss-pam-ldapd is actively maintained while nss_ldap/pam_ldap are not
 updated in a while. nss-pam-ldapd is more robust too (I had a similar
 problem like https://bugs.archlinux.org/task/33672 that didn't occur with
 nss-pam-ldapd; and according to that bug report actually a
 nss_ldap/pam_ldap setup is simply broken). According to the author (
 http://arthurdejong.org/nss-pam-ldapd/) nss-pam-ldapd is faster and more
 easily to debug (I didn't measured performance, but indeed nss-pam-ldapd is
 easier to debug, since it's service nslcd have a nice log output). I think
 Fedora and Mageia uses nss-pam-ldapd for default instead nss_ldap/pam_ldap.
 Even our Wiki (https://wiki.archlinux.org/index.php/OpenLDAP_Authentication)
 is recommending nss-pam-ldapd instead of nss_ldap/pam_ldap (actually, if
 you follow our Wiki using nss_ldap/pam_ldap you will have a non-working
 LDAP setup).
 
 So I suggest to drop nss_ldap/pam_ldap to AUR and put nss-pam-ldapd on
 [Extra] repository.
 -- 
 Thiago Kenji Okada thiago.mas...@gmail.com
 PGP Key: EEC09705

Looks like there's already a feature request:

https://bugs.archlinux.org/task/32911

@Tom and Allan, you guys maintain the packages that would be replaced
here -- either of you have an interest in adopting this?

d

Re: [arch-dev-public] [aur-general] Substitute nss_ldap/pam_ldap from [Extra] to nss-pam-ldapd

[Dave Reisner]

On Sat, Mar 02, 2013 at 04:13:01PM -0500, Dave Reisner wrote:
 On Sat, Mar 02, 2013 at 01:32:48PM -0300, Thiago Kenji Okada wrote:
  nss-pam-ldapd is actively maintained while nss_ldap/pam_ldap are not
  updated in a while. nss-pam-ldapd is more robust too (I had a similar
  problem like https://bugs.archlinux.org/task/33672 that didn't occur with
  nss-pam-ldapd; and according to that bug report actually a
  nss_ldap/pam_ldap setup is simply broken). According to the author (
  http://arthurdejong.org/nss-pam-ldapd/) nss-pam-ldapd is faster and more
  easily to debug (I didn't measured performance, but indeed nss-pam-ldapd is
  easier to debug, since it's service nslcd have a nice log output). I think
  Fedora and Mageia uses nss-pam-ldapd for default instead nss_ldap/pam_ldap.
  Even our Wiki (https://wiki.archlinux.org/index.php/OpenLDAP_Authentication)
  is recommending nss-pam-ldapd instead of nss_ldap/pam_ldap (actually, if
  you follow our Wiki using nss_ldap/pam_ldap you will have a non-working
  LDAP setup).
  
  So I suggest to drop nss_ldap/pam_ldap to AUR and put nss-pam-ldapd on
  [Extra] repository.
  -- 
  Thiago Kenji Okada thiago.mas...@gmail.com
  PGP Key: EEC09705
 
 Looks like there's already a feature request:
 
 https://bugs.archlinux.org/task/32911
 
 @Tom and Allan, you guys maintain the packages that would be replaced
 here -- either of you have an interest in adopting this?
 
 d

Argh. Reading the wrong field... Definitely all Jan.

Re: [arch-dev-public] libarchive rebuild is on

[Dave Reisner]

On Thu, Feb 28, 2013 at 10:12:53PM +1000, Allan McRae wrote:
 On 28/02/13 08:01, Dave Reisner wrote:
  FYI for those involved in this,
  
  With the QT rebuild done, I've dropped libarchive.so.13 into [staging]
  along with a rebuilt pacman. Dan posted the todo list some time ago:
  
  https://www.archlinux.org/todo/libarchive-31x-rebuild/
  
  Enjoy!
 
 
 BAH!   You should have added pacman to base-devel too, as the other
 TODO list dictated...
 
 

Totally forgot about this, but it seems that I'm smarter than I thought:

$ expac -S %G staging/pacman
base  base-devel

I must have made the change locally some time ago and never committed
it.

d

[arch-dev-public] libarchive rebuild is on

[Dave Reisner]

FYI for those involved in this,

With the QT rebuild done, I've dropped libarchive.so.13 into [staging]
along with a rebuilt pacman. Dan posted the todo list some time ago:

https://www.archlinux.org/todo/libarchive-31x-rebuild/

Enjoy!

d

Re: [arch-dev-public] libarchive 3.1.1 upgrade

[Dave Reisner]

On Sun, Feb 03, 2013 at 07:57:14PM -0600, Dan McGee wrote:
 On Sun, Feb 3, 2013 at 7:31 PM, Dave Reisner d...@falconindy.com wrote:
  I noticed last week that we're a bit out of date on libarchive, and
  started looking into why. There's 3 things that immediately came up:
 
  1) There's a soname bump. The list isn't huge though (15 packages)
  2) bsdtar's mtree file generation explodes. This is relevant for pacman
  4.1. I've already filed a bug and proposed a patch[1].
  3) There's a test suite failure in bsdcpio for lzo extraction. This
  turned out to be a missing dep. libarchive now handles lzo via lzo2 so
  we'd need to add it to depends. No big deal as lzo2 is already in [core].
 
 4) They aren't releasing tarballs because they can't host them on
 Github anymore. Seriously? Please become a real project again and
 release a stable cut of code hosted somewhere else at least; I know
 their Google code page could still do this for him.
 

They ship build/autogen.sh which appropriately preps the build env. I
don't really mind since we're getting an autogenerated tarball from the
git tree.

  Other than this, I've been running 3.1.1 without problems for roughly a
  week now (logs say since 1/28) and haven't had any other issues. Mostly
  aiming this at Dan and Allan, but once we have an upstream fix for the
  legit bug here, is anyone opposed to doing this upgrade/rebuild? I know
  we want to release pacman 4.1 soon, and it'd be probably be good not to
  have these overlap too much.
 
  d
 
  [1] http://code.google.com/p/libarchive/issues/detail?id=301

Re: [arch-dev-public] libarchive 3.1.1 upgrade

[Dave Reisner]

On Sun, Feb 03, 2013 at 07:57:14PM -0600, Dan McGee wrote:
 On Sun, Feb 3, 2013 at 7:31 PM, Dave Reisner d...@falconindy.com wrote:
  I noticed last week that we're a bit out of date on libarchive, and
  started looking into why. There's 3 things that immediately came up:
 
  1) There's a soname bump. The list isn't huge though (15 packages)
  2) bsdtar's mtree file generation explodes. This is relevant for pacman
  4.1. I've already filed a bug and proposed a patch[1].
  3) There's a test suite failure in bsdcpio for lzo extraction. This
  turned out to be a missing dep. libarchive now handles lzo via lzo2 so
  we'd need to add it to depends. No big deal as lzo2 is already in [core].
 
 4) They aren't releasing tarballs because they can't host them on
 Github anymore. Seriously? Please become a real project again and
 release a stable cut of code hosted somewhere else at least; I know
 their Google code page could still do this for him.
 

Ah, nevermind. They've fixed themselves:

http://libarchive.org/downloads/

There was already a thread on libarchive-discuss:

https://groups.google.com/forum/?fromgroups=#!topic/libarchive-discuss/CX_EHfMeb68

  Other than this, I've been running 3.1.1 without problems for roughly a
  week now (logs say since 1/28) and haven't had any other issues. Mostly
  aiming this at Dan and Allan, but once we have an upstream fix for the
  legit bug here, is anyone opposed to doing this upgrade/rebuild? I know
  we want to release pacman 4.1 soon, and it'd be probably be good not to
  have these overlap too much.
 
  d
 
  [1] http://code.google.com/p/libarchive/issues/detail?id=301

Re: [arch-dev-public] [arch-general] Drop VI from [core] (was Re: Winter Cleanup of [community])

[Dave Reisner]

On Thu, Jan 24, 2013 at 11:27 AM, Paul Gideon Dann pdgid...@gmail.comwrote:

 On Thursday 24 Jan 2013 11:05:22 Stéphane Gaudreault wrote:
  +1 to drop vi. I cannot imagine why someone would want to use this crap
 ...
 
  We already have nano in [core], so I think that vim could stay in
  [extra] (do we really need 2 text editors in [core] ?).

 Vi is the standard UNIX text-editor.  Many admins rely on the fact that vi
 is
 available everywhere.  It really should be in core.

 Also, I know you might be referring to plain vi, which is a completely
 different beast to Vim, but the latter (which provides vi too) has a
 *huge*
 userbase.  Calling it crap is just bizarre...

 Paul


Incorrect -- ed is the standard unix editor.

http://www.gnu.org/fun/jokes/ed-msg.html

More seriously, POSIX says vi is optional for us:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html

Please remember that dropping it from [core] makes it in no way any less
available.

I've no problems with moving vi as long as it doesn't disappear from the
install media. It's useful to have around long enough until you can pacman
-S vim.

Re: [arch-dev-public] Toolchain changes

[Dave Reisner]

On Tue, Jan 22, 2013 at 1:22 AM, Allan McRae al...@archlinux.org wrote:

 In my ongoing quest to bring packages to being as vanilla as possible, I
 have made some adjustments to the toolchain.  These are nothing that
 anybody should notice, but I though it worth a post here.

 The changes:

 1) /lib and /lib64 symlinks have been moved from glibc to the filesystem
 package. Also a /usr/lib64 symlink has been added (see below).

 This will make updates more difficult (though not impossible) for those
 who do not have the /lib symlink yet.  But if you have not upgraded in
 over six months, why do you use a rolling release?   The workaround I
 provided of temporarily using a glibc-2.16 package without the lib
 symlink is in the process of dying anyway with packages build built with
 glibc-2.17.


 2) The pure64 patch has been removed from glibc.  Well, part of it.  I
 added a sed to keep the 64bit system library directory as /lib.  Even
 though /lib64 is effectively the same, pacman-4.0 can not handle that well.

 This changes the ELF interpreter on x86_64 from
 /lib/ld-linux-x86-64.so.2 to /lib64/ld-   Again, symlinks make this
 not matter.


 3) I do not adjust the paths in ldd any more - this required the
 /usr/lib64 for it to keep working.  The /lib64 symlink is not enough as
 I configure glibc to use /usr/lib as its system library directory.


 4) ldconfig gets a symlink in /usr/bin.  This will probably be helpful
 in the future when /sbin dies.  Also, I do not remove the default of
 ldconfig searching /usr/lib /usr/libx32 /usr/lib64, so ldconfig -v
 will complain about /usr/lib64 being given more than once as it is
 /usr/lib (and any other directory added in ld.so.conf) and about
 /usr/libx32 being absent.  I might see if this can be fixed through
 adding a configure option upstream, but given no-one will probably
 notice it is not worth fixing.


 Wouldn't it be great if everything was just ./configure; make; make
 install...

 tl:dr; things will get more difficult for those who have not updated in
 six months, but no-one should notice any other change.


And much harder for people who have already decided to play around with
/bin as a symlink. This all broke me pretty hard because I tried to upgrade
glibc by itself (I necessarily needed a different package which doesn't
have duplicate ldconfig files in it). My own fault, of course, but it
should be noted that anyone else could potentially run into this if glibc
isn't upgraded at the same time as the filesystem package.

Oh well, at least I'll be home tonight to fix it.

Re: [arch-dev-public] Toolchain changes

[Dave Reisner]

On Tue, Jan 22, 2013 at 3:22 PM, Christian Hesse l...@eworm.de wrote:

 Dave Reisner d...@falconindy.com on Tue, 2013/01/22 13:31:
  On Tue, Jan 22, 2013 at 1:22 AM, Allan McRae al...@archlinux.org
 wrote:
   In my ongoing quest to bring packages to being as vanilla as possible,
 I
   have made some adjustments to the toolchain.  These are nothing that
   anybody should notice, but I though it worth a post here.
   [...]
 
  And much harder for people who have already decided to play around with
  /bin as a symlink. This all broke me pretty hard because I tried to
 upgrade
  glibc by itself (I necessarily needed a different package which doesn't
  have duplicate ldconfig files in it). My own fault, of course, but it
  should be noted that anyone else could potentially run into this if glibc
  isn't upgraded at the same time as the filesystem package.
 
  Oh well, at least I'll be home tonight to fix it.

 You can fix it if you are still logged in. Something like the following
 should make the system happy again:

 $ LD_PRELOAD=/usr/lib/libc.so.6 /usr/bin/ln -s usr/lib /lib

 After that update filesystem package with force option to overwrite the
 symlink:

 $ pacman -Sf filesystem

 Good luck! ;)


I have no /lib and no /lib64, and therefore, no available linker. You can
LD_PRELOAD whatever you want -- the linker is never going to be invoked to
read this variable. I have no root shell to call the linker directly and
therefore have no fallback but to reboot and fix this from the initramfs.
And no, sudo and su won't work either because their setuid bits are
meaningless when they're called indirectly.

[arch-dev-public] file-5.12 pulled from [testing]

[Dave Reisner]

Hi all,

This seems to have come up a few times on IRC and on the bug tracker, so
I may as well mention it here. file-5.12 lived a very short life in
testing (only a few hours) before it was pulled due to a fairly nasty
bug, but it seems that a good number of people still managed to install
it. The bug manifests itself as the mkinitcpio error invalid kernel
specified due to kernel images being misidentified by file as x86 boot
sectors, instead of a legit kernel images.

If you still have file-5.12 installed, please start paying attention to
the pacman warnings about your version of file being newer than what's
in core, and revert to version 5.11:

I fully intend to push a version of mkinitcpio soon™ which no longer
depends on file and does identification of kernel images[1] and compression
methods[2] (for lsinitcpio) without the aid of file so that we don't run
into this again.

We should have posted about this at the time testing/file was pulled
from the repo, but it seems that didn't happen.

Cheers,
Dave

[1] https://projects.archlinux.org/mkinitcpio.git/commit/?id=f8ee357b2
[2] https://projects.archlinux.org/mkinitcpio.git/commit/?id=dae9fa199

Re: [arch-dev-public] systemd 197 - kdm fails

[Dave Reisner]

On Fri, Jan 11, 2013 at 07:10:54PM +0100, Lukas Jirkovsky wrote:
 On 11 January 2013 18:26, Tom Gundersen t...@jklm.no wrote:
  I'm using KDE as well, but have not been able to reproduce this
  problem. Any chance you could get some more debug info out of it?
  Sounds like something times out...
 
 Console timeouts on mounting remote filesystems.
 
 I remember I had this problem earlier which I solved by:
 systemctl disable remote-fs.target

Why would you want to do this? Just use noauto,x-systemd.automount on
your remote filesystems in fstab and they'll only be mounted on first
access.

 However, this update reenabled it for some reason. Is there a way to
 make these changes permanent?

The symlink is shipped by upstream and belongs to the systemd package.
If you're bent on disabling it, you'll need to use pacman's NoExtract.

 I have no idea why KDM starts longer than usual though. There's
 nothing unusual in any log. It seemed to me that I heard harddisk to
 be spinning more than usual when KDM is loading, but that's something
 I don't usually look for, so I may be wrong.
 
 Lukas

Re: [arch-dev-public] systemd 197 - kdm fails

[Dave Reisner]

On Fri, Jan 11, 2013 at 07:24:28PM +0100, Lukas Jirkovsky wrote:
 On 11 January 2013 19:14, Dave Reisner d...@falconindy.com wrote:
 
  Why would you want to do this? Just use noauto,x-systemd.automount on
  your remote filesystems in fstab and they'll only be mounted on first
  access.
 
 Thank you, I didn't know that.
 
 
  The symlink is shipped by upstream and belongs to the systemd package.
  If you're bent on disabling it, you'll need to use pacman's NoExtract.
 
 I see.
 
 On 11 January 2013 19:10, Lukas Jirkovsky l.jirkov...@gmail.com wrote:
  I have no idea why KDM starts longer than usual though. There's
  nothing unusual in any log. It seemed to me that I heard harddisk to
  be spinning more than usual when KDM is loading, but that's something
  I don't usually look for, so I may be wrong.
 
 Now I think I caught it. There's a quite long wait on:
 Starting Authorization Manager...

Which is polkit... Any joy with 0.107 instead of 0.109? You might have
had both upgraded at the same time (guessing based on build dates).

Re: [arch-dev-public] network interface naming with systemd 197

[Dave Reisner]

On Jan 7, 2013 2:23 AM, Andrea Scarpino and...@archlinux.org wrote:

 On Monday 07 January 2013 07:51:30 Allan McRae wrote:
  Upstream decision...  vanilla packages should follow it.

 I agree with Allan. We don't use to change the default behavior. Ship it
as
 default and add two lines on how to disable it.

 --
 Andrea
 Arch Linux Developer

Yep. And you're all correct. This will be enabled for new installs.

Thanks for the feedback.

Re: [arch-dev-public] network interface naming with systemd 197

[Dave Reisner]

If you don't care about interface renaming with systemd 197 or you
understand the change, you can stop reading here. I suggest everyone
read the first point, though.
--

Since 197 was just tagged and there still seems to be some confusion,
here's an FAQ:

*** What happens after installing systemd 197?

For existing installs: Nothing happens, and this is strictly opt-in.
A post_upgrade() message will mention the feature and add a dummy file
called /etc/udev/rules.d/80-net-name-slot.rules to mask the new rule
which performs the renaming. If you wish to opt-in, remove this dummy
file. Next reboot, the rule will take effect.

For new installs: You are opted-in to this change. The post_install()
will do nothing to mask the rule. If you wish to opt out, you can do 1
of 2 things:
1) mask the rule: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
2) provide your own udev rule that applies a NAME to the interface. As
   long as this rule is ordered lexically before 80-net-name-slot.rules,
   then the upstream rule will have no effect. For example, providing a
   file called 70-net-naming.rules will trump 80-net-name-slot.rules.


*** What will the interfaces be renamed to if I opt-in?

Run this as non-root:

  for i in /sys/class/net/*; do
echo ==$i
udevadm test-builtin net_id $i;
echo
  done 2/dev/null

Not all interfaces will have output for this command. No output means no
renaming.

For those that do, the below properties are capable of renaming the
device, with highest priority first.

- ID_NET_NAME_ONBOARD
- ID_NET_NAME_SLOT
- ID_NET_NAME_PATH

So for an interface with both ID_NET_NAME_ONBOARD and ID_NET_NAME_PATH,
the value of ID_NET_NAME_ONBOARD will be the new name of the interface.

If you see none of these properties for an interface, it will not be
renamed by /usr/lib/udev/rules.d/80-net-name-slot.rules.


*** How should I go about updating my network config?

I suggest figuring out what your device will be named in advance and
altering your config BEFORE rebooting. Consult the documentation for
your network provider on how to do this. If you don't want to do this,
read the next 2 questions.


*** I don't like this, or, I've never needed persistent names

You'll never be forced to use the new schema. Masking the rule as
explained above will always work, and you're still able to write a rule
of your own to provide names you're comfortable with if that's what
you're into.


*** Is there any way to alias the old kernel name to the new name?

No, the kernel does not support this.


*** Need more info?

Upstream wrote a wiki page with more detail. Some of this is redundant
with the above:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

The careful reader might notice that names are path based. Yes, this
does mean that USB devices or PCI devices which are physically moved to
another port will suddenly change names. That's the trade-off for this
scheme.


*** STILL not satisfied?

Code is the ultimate documentation, and has some examples of how various
paths translate into the new naming scheme:

http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c


*** Why are you still reading this?

If you made it this far, you might be as crazy as I am, so here's Pinkie
Pie dressed as a chicken:

http://i.imgur.com/DDukE.png


Cheers,
Dave

[arch-dev-public] network interface naming with systemd 197

[Dave Reisner]

Just an FYI:

Upstream pushed a commit[0] which gives network devices persistent, and
unique, names based on hardware attributes, avoiding the random kernel
names. While this solves a real problem, it's also a fairly jarring
change. For example:

$ udevadm info /sys/class/net/eth0
P: /devices/pci:00/:00:1c.2/:05:00.0/net/eth0
E: DEVPATH=/devices/pci:00/:00:1c.2/:05:00.0/net/eth0
E: ID_BUS=pci
E: ID_MODEL_ID=0x4364
E: ID_NET_NAME_MAC=enxbcaec50bfcc8
E: ID_NET_NAME_PATH=enp5s0
E: ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_PRODUCT_FROM_DATABASE=88E8056 PCI-E Gigabit Ethernet Controller
E: ID_VENDOR_FROM_DATABASE=Marvell Technology Group Ltd.
E: ID_VENDOR_ID=0x11ab
E: IFINDEX=2
E: INTERFACE=eth0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:
E: USEC_INITIALIZED=42063

If I were to reboot right now (systemd-git), eth0 would become enp5s0. I
tend to think that this is fairly extreme, and would throw off a lot of
people -- especially those who never needed to deal with interface
renaming.

For systemd 197, I plan on shipping this rule as documentation in
/usr/share/doc/systemd and _not_ enabling it by default. Those who want
to opt in can simply copy the rule to /etc/udev/rules.d. They can also,
of course, continue to use whatever MAC-based rules they might have, but
I would strongly recommend switching these rules to be triggered by
ID_NET_NAME_{SLOT,PATH,ONBOARD} instead.

Cheers,
Dave

[0] http://cgit.freedesktop.org/systemd/systemd/commit/?id=394e2938ff9

Re: [arch-dev-public] network interface naming with systemd 197

[Dave Reisner]

On Sun, Jan 06, 2013 at 01:38:03PM -0500, Dave Reisner wrote:
 Just an FYI:
 
 Upstream pushed a commit[0] which gives network devices persistent, and
 unique, names based on hardware attributes, avoiding the random kernel
 names. While this solves a real problem, it's also a fairly jarring
 change. For example:
 
 $ udevadm info /sys/class/net/eth0
 P: /devices/pci:00/:00:1c.2/:05:00.0/net/eth0
 E: DEVPATH=/devices/pci:00/:00:1c.2/:05:00.0/net/eth0
 E: ID_BUS=pci
 E: ID_MODEL_ID=0x4364
 E: ID_NET_NAME_MAC=enxbcaec50bfcc8
 E: ID_NET_NAME_PATH=enp5s0
 E: ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
 E: ID_PCI_CLASS_FROM_DATABASE=Network controller
 E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
 E: ID_PRODUCT_FROM_DATABASE=88E8056 PCI-E Gigabit Ethernet Controller
 E: ID_VENDOR_FROM_DATABASE=Marvell Technology Group Ltd.
 E: ID_VENDOR_ID=0x11ab
 E: IFINDEX=2
 E: INTERFACE=eth0
 E: SUBSYSTEM=net
 E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
 E: TAGS=:systemd:
 E: USEC_INITIALIZED=42063
 
 If I were to reboot right now (systemd-git), eth0 would become enp5s0. I
 tend to think that this is fairly extreme, and would throw off a lot of
 people -- especially those who never needed to deal with interface
 renaming.
 
 For systemd 197, I plan on shipping this rule as documentation in
 /usr/share/doc/systemd and _not_ enabling it by default. Those who want
 to opt in can simply copy the rule to /etc/udev/rules.d. They can also,
 of course, continue to use whatever MAC-based rules they might have, but
 I would strongly recommend switching these rules to be triggered by
 ID_NET_NAME_{SLOT,PATH,ONBOARD} instead.
 
 Cheers,
 Dave
 
 [0] http://cgit.freedesktop.org/systemd/systemd/commit/?id=394e2938ff9

Alternatively, we could simply write a symlink to /dev/null on post_upgrade
to 197 and post_install() if /etc/udev/rules.d/80-net-name-slot.rules
doesn't exist. I don't particularly care either way, since both methods
are a matter of documentation to enable it. I'll point out that masking
has the advantage of not needing to worry about changes to the upstream
rule when a user opts in to interface renaming.

d

Re: [arch-dev-public] network interface naming with systemd 197

[Dave Reisner]

On Sun, Jan 06, 2013 at 09:32:41PM +0100, Tom Gundersen wrote:
 On Jan 6, 2013 7:38 PM, Dave Reisner d...@falconindy.com wrote:
 
  Just an FYI:
 
  Upstream pushed a commit[0] which gives network devices persistent, and
  unique, names based on hardware attributes, avoiding the random kernel
  names. While this solves a real problem, it's also a fairly jarring
  change. For example:
 
  $ udevadm info /sys/class/net/eth0
  P: /devices/pci:00/:00:1c.2/:05:00.0/net/eth0
  E: DEVPATH=/devices/pci:00/:00:1c.2/:05:00.0/net/eth0
  E: ID_BUS=pci
  E: ID_MODEL_ID=0x4364
  E: ID_NET_NAME_MAC=enxbcaec50bfcc8
  E: ID_NET_NAME_PATH=enp5s0
  E: ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
  E: ID_PCI_CLASS_FROM_DATABASE=Network controller
  E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
  E: ID_PRODUCT_FROM_DATABASE=88E8056 PCI-E Gigabit Ethernet Controller
  E: ID_VENDOR_FROM_DATABASE=Marvell Technology Group Ltd.
  E: ID_VENDOR_ID=0x11ab
  E: IFINDEX=2
  E: INTERFACE=eth0
  E: SUBSYSTEM=net
  E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
  E: TAGS=:systemd:
  E: USEC_INITIALIZED=42063
 
  If I were to reboot right now (systemd-git), eth0 would become enp5s0. I
  tend to think that this is fairly extreme, and would throw off a lot of
  people -- especially those who never needed to deal with interface
  renaming.
 
  For systemd 197, I plan on shipping this rule as documentation in
  /usr/share/doc/systemd and _not_ enabling it by default. Those who want
  to opt in can simply copy the rule to /etc/udev/rules.d. They can also,
  of course, continue to use whatever MAC-based rules they might have, but
  I would strongly recommend switching these rules to be triggered by
  ID_NET_NAME_{SLOT,PATH,ONBOARD} instead.
 
  Cheers,
  Dave
 
  [0] http://cgit.freedesktop.org/systemd/systemd/commit/?id=394e2938ff9
 
 How about:
 
 1) follow upstream on fresh installs (i.e. ship the rule and don't mask it
 in post_instal).

Scary. I agree with upstream that this is wanted and that it solves real
problems, but I really see no reason that this should be opt-out, rather
than opt-in. We have the option of explaining why the dummy file exists
in /etc when we make things opt-in, but opt-out on install makes the
messaging easier to miss. Additionally, there'll be an awkward phase
where older install media uses older systemd (providing the classic
names), followed by a reboot into newer systemd with the new naming
scheme.

Anyone else have an opinion on this?

 2) stay backwards compatible on upgrade (i.e. mask the rule in
 post_upgrade).
 
 3) print a notice about the masking so people can unmask it.

Definitely planned.

 4) rather than a symlink to null, use an empty rules file with a comment
 explaining why it is there and what will happen if you delete it.

I like this. Done for the -git package, at least.

d

Re: [arch-dev-public] [signoff] linux-3.6.11-1

[Dave Reisner]

On Wed, Jan 02, 2013 at 05:51:18PM +0100, Tobias Powalowski wrote:
 Am 18.12.2012 14:47, schrieb Tobias Powalowski:
  Hi guys,
  please signoff 3.6.11 series for both arches.
  package is not in testing, please grab it from here:
  http://dev.archlinux.org/~tpowa/linux/
 
  This will move to [core] directly, because 3.7.1 is in [testing].
 
  greetings
  tpowa
 anyone interested in 3.6.11?
 please signoff.
 
 greetings
 tpowa
 
 -- 
 Tobias Powalowski
 Archlinux Developer  Package Maintainer (tpowa)
 http://www.archlinux.org
 tp...@archlinux.org
 
 

Works for me.

d

Re: [arch-dev-public] syslinux 5.00 in [testing]

[Dave Reisner]

On Sat, Dec 08, 2012 at 02:10:54PM +0100, Andrea Scarpino wrote:
 On Saturday 08 December 2012 14:07:16 Pierre Schmitz wrote:
  The syslinux modules like the menu are no longer working. Other more
  essential features like serial console might be broken as well. So it
  might be better to pull that pacakge if we cannot fix this asap. The
  install scripts needs to be adjusted as well; or better drop it
  entirely.
 
 I couldn't boot my system neither. I removed the package from [testing] until 
 we fix it properly.
 
 -- 
 Andrea
 Arch Linux Developer

Playing with this in a VM -- I'm able to boot, but yes, there's massive
module borkage. This is probably going to suck from a distro level, as,
at a minimum, we need to recopy over the *.c32 modules in use, as well
as locate dependencies. Boo.

The root of the problem with modules is things like this:

$ readelf -d /lib/syslinux/menu.c32 | grep NEEDED
 0x0001 (NEEDED) Shared library: 
[../../com32/libutil/libutil_com.c32]

I'm doubtful that this is intended. On a system without a separate
/boot, this means /com32 would need to exist as a toplevel dir. HPA
mentions the PATH directive for the location of the lib*.c32 files, but
that seems to have no effect here.

I'll keep playing with this, under the initial suspicion that perhaps
our build is baroque.

d

Re: [arch-dev-public] syslinux 5.00 in [testing]

[Dave Reisner]

On Sat, Dec 08, 2012 at 01:00:55PM -0500, Dave Reisner wrote:
 On Sat, Dec 08, 2012 at 02:10:54PM +0100, Andrea Scarpino wrote:
  On Saturday 08 December 2012 14:07:16 Pierre Schmitz wrote:
   The syslinux modules like the menu are no longer working. Other more
   essential features like serial console might be broken as well. So it
   might be better to pull that pacakge if we cannot fix this asap. The
   install scripts needs to be adjusted as well; or better drop it
   entirely.
  
  I couldn't boot my system neither. I removed the package from [testing] 
  until 
  we fix it properly.
  
  -- 
  Andrea
  Arch Linux Developer
 
 Playing with this in a VM -- I'm able to boot, but yes, there's massive
 module borkage. This is probably going to suck from a distro level, as,
 at a minimum, we need to recopy over the *.c32 modules in use, as well
 as locate dependencies. Boo.
 
 The root of the problem with modules is things like this:
 
 $ readelf -d /lib/syslinux/menu.c32 | grep NEEDED
  0x0001 (NEEDED) Shared library: 
 [../../com32/libutil/libutil_com.c32]
 
 I'm doubtful that this is intended. On a system without a separate
 /boot, this means /com32 would need to exist as a toplevel dir. HPA
 mentions the PATH directive for the location of the lib*.c32 files, but
 that seems to have no effect here.
 
 I'll keep playing with this, under the initial suspicion that perhaps
 our build is baroque.
 
 d

Okay I take it back -- the funky paths aren't relevant, and this works
just fine if I load my qemu VM using the SDL interface (rather than
serial). Need to figure out why the serial console isn't working
properly, but this isn't so bad after all.

summary: update all your .c32 files and make sure to also copy
libutil_com.c32 and libmenu.c32 to /boot/syslinux/ (assuming you use the
one of the menu c32 files).

d

Re: [arch-dev-public] [RFC] dbus cleanup

[Dave Reisner]

On Mon, Dec 03, 2012 at 10:07:06AM +0100, Jan de Groot wrote:
 On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:
  While we're touching the PKGBUILD, why do we fix the configuration
  file in the package function? Would be nice if we could cleanup the
  30-dbus file as well to simply use shell builtins rather than an
  external (yes, 'which' is in base, but it bothers me).
 
 Please don't fix that file, but just kill it. It's the xinitrc.d file
 right? Nowadays dbus autoloads itself, and for situations where dbus
 still needs to be launched by hand, you don't want to do that from a
 weird scriptlet but straight from ~/.xinitrc.
 I removed the file from my system a while ago, haven't seen any of the
 problems that it tried to solve in the past.
 

Good point, actually. I've been doing the same myself.

$ grep NoExtract /etc/pacman.conf
NoExtract= etc/X11/xinit/xinitrc.d/30-dbus
...

d

Re: [arch-dev-public] [RFC] dbus cleanup

[Dave Reisner]

On Dec 3, 2012 7:06 AM, Tom Gundersen t...@jklm.no wrote:

 On Mon, Dec 3, 2012 at 12:57 PM, Allan McRae al...@archlinux.org wrote:
  Some fun here...
 
  (1/1) removing dbus-core
  [##] 100%
  userdel: user dbus is currently used by process 336
  groupdel: cannot remove the primary group of user 'dbus'
  error: command failed to execute correctly
 
  Obviously nothing to be concerned about...

 Oh, nice... I don't know why I didn't get that message.

 Anyway, it is not a problem. If for some reason the removal should
 work, then the user/group will be added back immediately by the dbus
 upgrade.

 Any suggestions on how these messages can be avoided?

 -t

I do hate our filesystem upgrades since /sys was made RO and pacman tries
to remove it, but perhaps we should move the dbus user there. I think as a
general rule, packages in [core] should probably avoid creating users and
groups to avoid problems we've seen recently.

Re: [arch-dev-public] [RFC] dbus cleanup

[Dave Reisner]

On Sat, Dec 01, 2012 at 08:11:00PM +0100, Tom Gundersen wrote:
 Hi guys,
 
 I'd like to propose the following change to our two dbus packages:
 
  * make libx11 an optdep in dbus
  * merge dbus-core into dbus
  * move dbus to [core]
 
 This should not have much of an effect in practice, but should make
 things a bit clearer and especially the naming will be more in-line
 with upstream and other distros.
 
 We can see that the current naming has caused some confusion as most
 of the packages that depend on dbus should in fact be depending on
 dbus-core.
 
 What do you think?
 
 I put a suggested package here: https://dev.archlinux.org/~tomegun/.
 
 In addition to the above changes, I dropped a dep on systemd-tools as
 it was causing a cycle and added a patch requested by Thomas:
 https://bugs.archlinux.org/task/32902.
 
 Cheers,
 
 Tom

While we're touching the PKGBUILD, why do we fix the configuration
file in the package function? Would be nice if we could cleanup the
30-dbus file as well to simply use shell builtins rather than an
external (yes, 'which' is in base, but it bothers me).

I'd still like to know the history of why this was split in the first
place, and not just optdep'd...

d

Re: [arch-dev-public] adm and log groups

[Dave Reisner]

On Sat, Nov 10, 2012 at 07:46:24PM +0100, Jan Steffens wrote:
 The meaning of these two groups (adm and log) seems to be
 identical. Both allow read access to system logs, except adm is used
 by journald and log by syslogd (and tomcat, apparently).
 
 Wouldn't it make sense to do away with one?

If anything, I'd chip in a vote to keep log, mostly because of:

http://lists.fedoraproject.org/pipermail/devel/2012-October/172682.html

The value of the adm group will be largely diminished if wheel has
equivalent privileges.

d

Re: [arch-dev-public] moving ncftp to [community]

[Dave Reisner]

On Wed, Nov 07, 2012 at 06:05:09PM +0100, Timothy M. Redaelli wrote:
 Hi,
 I'd like to adopt ncftp package, but it's in [extra].

It's also up to date and has a maintainer.

 If there aren't objection and if some developer can move it to
 [community] I will adopt it.

Any particular reason?

d

Re: [arch-dev-public] moving ncftp to [community]

[Dave Reisner]

On Wed, Nov 07, 2012 at 12:34:08PM -0500, Dave Reisner wrote:
 On Wed, Nov 07, 2012 at 06:05:09PM +0100, Timothy M. Redaelli wrote:
  Hi,
  I'd like to adopt ncftp package, but it's in [extra].
 
 It's also up to date and has a maintainer.
 

Sigh. Ignore...

  If there aren't objection and if some developer can move it to
  [community] I will adopt it.
 
 Any particular reason?
 
 d

Re: [arch-dev-public] mdadm udev + initramfs (WAS: Re: Big changes to LVM2 in testing)

[Dave Reisner]

On Sun, Nov 04, 2012 at 05:07:59PM +0100, Thomas Bächler wrote:
 Am 03.11.2012 02:40, schrieb Eric Bélanger:
  If you use both RAID and LVM, make sure that you use the mdadm_udev
  hook instead of the mdadm one. I had to do this change to make my
  system boot with the lvm2 package in [testing].
 
 Okay, we figured this out by now:
 
 The 'mdadm' hook does not only disable the auto-assembly, it lacks any
 udev rules in initramfs - this means that udev will not know about file
 system type on the RAID contents and LVM auto-assembly fails.

I guess I knew this, as it caused problems in the past when we created
mdadm_udev:

https://bugs.archlinux.org/task/28067

 The solution would be to include the udev rules in the mdadm hook as
 well, and just disable auto-assembly.

This was always the sticking point -- is there a way to disable auto
assembly but keep the rule file as is? I'd rather we didn't duplicate
it.

 On another note: The mdadm_udev behaviour used to be the default for a
 while, but we had a lot of whining about it - none of the affected
 people had any interest in figuring out why auto-assembly failed for
 them. I'd really like to get rid of the non-udev based mdadm assembly,
 so if anyone has an idea why there were problems, feel free to share.
 
 While we're at it, I'd like to fix mdadm's udev rule to use
 BUILTIN+=blkid instead of manually calling blkid.

This is definitely needed. I think the -o udev output from blkid is
going away in u-l 2.23. The blkid builtin is already almost a year old
-- would make more sense to just convince upstream to make the change.

d

Re: [arch-dev-public] mdadm udev + initramfs (WAS: Re: Big changes to LVM2 in testing)

[Dave Reisner]

On Sun, Nov 04, 2012 at 05:25:22PM +0100, Thomas Bächler wrote:
 Am 04.11.2012 17:19, schrieb Dave Reisner:
  The solution would be to include the udev rules in the mdadm hook as
  well, and just disable auto-assembly.
  
  This was always the sticking point -- is there a way to disable auto
  assembly but keep the rule file as is? I'd rather we didn't duplicate
  it.
 
 There is, and it is incredibly stupid: The non-udev mdadm hook includes
 'mdassemble' and not 'mdadm', and the udev rule uses 'mdadm'. If we add
 the udev rule to the hook as it is, we're fine. Or we symlink mdadm to true.
 

Yeah that's pretty stupid =P. You'll miss out on some metadata being
added to the device nodes in the udev DB by doing this.. things like:

MD_LEVEL=raid0
MD_DEVICES=2
MD_METADATA=1.2
MD_UUID=edf34247:6a46d6e6:0b209b2c:a9b29539
MD_DEVNAME=0
MD_NAME=archiso:0

Though, I suppose this will just get added when udevadm trigger is
called later in userspace proper.

  While we're at it, I'd like to fix mdadm's udev rule to use
  BUILTIN+=blkid instead of manually calling blkid.
  
  This is definitely needed. I think the -o udev output from blkid is
  going away in u-l 2.23. The blkid builtin is already almost a year old
  -- would make more sense to just convince upstream to make the change.
 
 Yes, we should report it to them, but we should also patch our version
 of the rule.
 

The rule is showing signs of age elsewhere too -- things like $tempnode
should be replaced with $devnode instead (the former is a relic of
pre-devtmpfs).

d

Re: [arch-dev-public] Issues with kernel 3.6.4 on some AMD systems

[Dave Reisner]

On Fri, Nov 02, 2012 at 08:06:03PM +0100, Pierre Schmitz wrote:
 Hi all,
 
 turns out there was an issue with Linux 3.6.4 on some AMD systems with
 more than 4GB of RAM. 3.6.5 fixed this bug. Unfortunately this was a
 little too late for the recent ISO image.
 
 I was wondering what was the best way to handle issues like this. One
 of the benefits of monthly releases is that we have more than one image
 available which is recent enough to install your system. Instead of
 aiming for the perfect, bug free system I would prefer to update the
 download page with a known issues section and a link to the last two
 previous install images. I think it might be saner to solve the problem
 this way; for example 3.6.5 might fix this issue but as the changelog is
 quite long its possible new bugs were introduced at the same time.
 
 In this particular case a simple workaround exists by adding mem=3G
 to your boot parameters.
 
 PS: Maybe it's worth to post a dedicated news item about this issue; I
 assume while not a lot of people seem to be affected most probably got
 hit it via regular system updates.
 
 What do you think about this? In general and for this particular
 problem.
 
 Greetings,
 
 Pierre
 
 -- 
 Pierre Schmitz, https://pierre-schmitz.com

Given that:

- it doesn't affect everyone
- there's an easy enough workaround
- there's always last month's ISO
- there's always next month's ISO

I vote for a news post for the front page, and we just roll with it.

d

Re: [arch-dev-public] libotr-4.0.0-1 in [staging]

[Dave Reisner]

On Fri, Nov 02, 2012 at 10:42:40PM -0400, Eric Bélanger wrote:
 On Tue, Oct 30, 2012 at 11:31 PM, Eric Bélanger snowmanisc...@gmail.com 
 wrote:
  On Tue, Oct 30, 2012 at 3:27 PM, Andreas Radke andy...@archlinux.org 
  wrote:
  Am Tue, 16 Oct 2012 10:04:47 -0400
  schrieb Dave Reisner d...@falconindy.com:
 
  An an alternative, we could introduce libotr3 and do a rebuild for the
  applications which haven't been ported (as to not hold
  libpurple/pidgin back).
 
  Sounds good to me in this special case. We should do something to
  cleanup staging.
 
  -Andy
 
  I started working on a libotr3 package. I'll rename/move things around
  so it doesn't conflict with libotr.  Hopefully, packages will build
  against it with minor patching. I'll test that before pushing it to
  staging. It should be ready tomorrow. I'll let you know when it'll be
  done.
 
  Eric
 
 Hi,
 
 It took longer than I tough but there is now a libotr3 package in
 staging. The major changes that afffects building against it is:
 
 - the headers moved from /usr/include/libotr/ to /usr/include/libotr3/
 - the library was renamed from libotr.so to libotr3.so

Sounds reasonable.

 As a test, I tried rebuilding bitlbee against it and I only had to add
 2 small sed lines to make it work. We can now finish this todo list.

Great! Thanks for doing this.

d