Re: [arch-dev-public] [arch-devops] New Archive Mirrors available

[Sébastien Luttringer via arch-dev-public]

On Thu, 2020-12-17 at 21:57 +0100, Jelle van der Waa wrote:
> I am happy to announce that thanks to Kake/PIA sponsoring us dedicated 
> servers, we now have three new Arch Linux Archive servers available at:
> 
> https://america.archive.pkgbuild.com/
> https://europe.archive.pkgbuild.com/
> https://asia.archive.pkgbuild.com/
> 

Great! Thanks you and Kake/PIA.

Regards,


Sébastien "Seblu" Luttringer



signature.asc
Description: This is a digitally signed message part

[arch-dev-public] Dropping arptables/ebtables

[Sébastien Luttringer via arch-dev-public]

Hello,

I would like stop maintaining arptables and ebtables and drop them in
[unsupported].
The future in the linux kernel is clearly nftables and keeping them in the
repository present is of little interest these days.

ebtables is still an hard dependency on others packages, but the iptables-nft
package ship a remplacement based on nftables. I have not tested the
compatibility, so if someone think it's not possible, please let me know.

If you have spare time, I suggest you take a look at the nftable package and
become a master in nft-fu. It is much more convenient and efficient than the
iptables / ipset / ebtables / arptables solution. For the less enthusiastic
about the command line, firewalld has an nftables backend.

Regards,

Sébastien "Seblu" Luttringer


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] News draft: libtraceevent>=5.9-1 update requires manual intervention

[Sébastien Luttringer via arch-dev-public]

On Sat, 2020-10-24 at 00:07 +0200, Jan Alexander Steffens wrote:
> On Wed, Oct 21, 2020 at 3:20 AM Sébastien Luttringer via
> arch-dev-public  wrote:
> 
> Was libtraceevent 5.9 never in [community-testing]?
No, like every release.

> 
> Next time, please release the affected package to [*testing] together
> with the draft.

Sure, I didn't know that rule. It's written somewhere or well known habit?

Regards,



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] mailman3/hyperkitty/postorius in the repos now

[Sébastien Luttringer via arch-dev-public]

On Sun, 2020-02-02 at 17:48 +0100, David Runge wrote:
> 
> Everyone, feel invited to install and test the applications and propose
> fixes and expansions to the documentation (or packages) as needed.
> 

Hello,

Great! So happy you moved forward. I'll test your work with my building 
co-owner mailing list.

For the record, the new mailman (3.x) ecosystem is split into several 
components (with different git and version),
while the current version (2.x) has all in one scm.
I remember you planned to name the package against the components names. Why 
did you named mailman-core to mailman3?

As soon as we don't require mailman 2.x on our infra, I plan to move mailman to 
AUR.

Cheers,


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Adding a "posix" metapackage

[Sébastien Luttringer via arch-dev-public]

On Sat, 2020-01-04 at 13:08 +1000, Allan McRae via arch-dev-public wrote:
> On 4/1/20 12:47 pm, Sébastien Luttringer via arch-dev-public wrote:
> > One unfortunate consequence could be to have packages rely on it to make
> > dependencies shorter, and make us pull cups or cronie.
> 
> What?!  That is like saying one unfortunate consequence of pamcan hooks
> is that packages can have no files and just download and compile the
> source in a hook.  It is a ridiculous consideration.
> 

Your extreme example seems, indeed, a ridiculous use of hooks.
I hadn't realized that adding posix as a dependency on a package will be as
extreme and ridiculous as the example that you have just gave.
My mistake.

Regards,

Sébastien "Seblu" Luttringer



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Adding a "posix" metapackage

[Sébastien Luttringer via arch-dev-public]

On Fri, 2020-01-03 at 11:11 -0500, Eli Schwartz via arch-dev-public wrote:
> On 1/3/20 10:48 AM, Sébastien Luttringer wrote:
> > On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote:
> > > ...
> > > 
> > > Thoughts?
> > 
> 
> I would argue that POSIX is a standard which people actually care about,
> and LSB is a standard which no one cares about.

I agree that few people are interested in LSB. I think it's barely the same for
POSIX.

Our scripts are not written POSIX compatible (i.e they rely on more tools than
the standard). Do you still know people writing POSIX compatible scripts
nowadays (students excluded)?
The GNU Operating System (our core rely on it) have disagreements with POSIX
and are de-facto non-POSIX (e.g df).
I'm not able to tell you something in Arch that rely on POSIX.2 (Shell and
Utilities).
What make you think people care about this standard?

I'm not opposed to add a posix metapackage. I'm just very reserved about its
usefulness.

One unfortunate consequence could be to have packages rely on it to make
dependencies shorter, and make us pull cups or cronie.

Cheers,

Sébastien "Seblu" Luttringer


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Adding a "posix" metapackage

[Sébastien Luttringer via arch-dev-public]

On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote:
> ...
> 
> Thoughts?

Posix is an old standard which fail to make a common ground to Unix systems.

If we think user needs meta packages to install their Arch, is the Linux
Standard Base more relevant to us?

Cheers,

Sébastien "Seblu" Luttringer


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] New kernel packages and mkinitcpio hooks

[Sébastien Luttringer via arch-dev-public]

On Mon, 2019-11-11 at 15:41 -0500, Eli Schwartz via arch-dev-public wrote:
> On 11/10/19 9:54 PM, Sébastien Luttringer via arch-dev-public wrote:
> As I said above, the documentation for kernel-install is pretty clear on
> its expected usage. It's a one-stop shop, it executes mkinitcpio or
> whatever other plugin you've installed for generating an initramfs, and
> it's totally 100% independent of the mkinitcpio hook.

Hi Eli,

Let me first agree on the clarity of kernel-install documentation. Its goal is
well summed in the man page NAME section: "Add and remove kernel and initramfs
images to and from /boot.

> ...
> 
> Also, yes, kernel-install mandates the use of systemd-boot. 
No, kernel-install doesn't mandate use of systemd-boot.
It's a modular framework to make your machine bootable.
The default plugin, install kernel for systemd-boot which is different.

Since 2014, I use kernel-install[1] to manage kernel upgrades on over than 300
Arch servers. There is regular Arch kernels, custom versioned kernels, some are
booted with grub (uefi or not) others with systemd-boot.

> Meanwhile, mkinitcpio's presets and the kernel file which was
> historically installed by the linux package install directly to:
> 
> /boot/vmlinuz-linux
> /boot/initramfs-linux.img
An Arch plugin of few lines could easily put the files in our historical
location. This are just examples [2][3].

> Under no circumstances can we unilaterally remove mkinitcpio presets and
> switch to kernel-install without a mandatory manual intervention for all
> (or most) archlinux users. 
We can easily switch to kernel-install, without user intervention, as it was
done with pacman hooks. Switching from mkinitcpio is another topic.

kernel-install runs a collection of scripts (hooks), with the systemd
overriding logic. There is no huge difference with the pacman hooks, except the
logic is cross distro, provided by systemd, and not tied to pacman.
Improvements can be shared. What it makes me prefer systemd kernel-install than
pacman hooks logic.

Regards,

[1] https://git.seblu.net/archlinux/kernel-install-poc/
[2] 
https://git.seblu.net/archlinux/kernel-install-poc/blob/master/90-loaderentry-compat.install
[3] 
https://git.seblu.net/archlinux/kernel-install-poc/blob/master/50-mkinitcpio-compat.install

-- 
Sébastien Luttringer


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] New kernel packages and mkinitcpio hooks

[Sébastien Luttringer via arch-dev-public]

On Sun, 2019-11-10 at 18:41 -0300, Giancarlo Razzolini via arch-dev-public
wrote:
> These changes were made after a lot of discussions between myself, Jen and
> the maintainers
> of the other kernels as well. We have spent a lot of time to arrive at this
> current format. [2]

Hello,

Nice to see that moving forward. It is a smart to move pacman installed kernel
out of /boot.
Why do you rely on mkinitcpio (or later dracut) to install them in /boot
instead of the systemd kernel-install logic?

Regards,


Sébastien "Seblu" Luttringer


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] new archweb release

[Sébastien Luttringer via arch-dev-public]

On Wed, 2019-09-11 at 21:37 +0200, Jelle van der Waa wrote:
> 
> - When enough signoffs are reached, archweb automatically sends a mail
>   to the packager that the package has reached the target signoffs! If
>   this is too spammy we can consider a "daily" report.
> 
So useful feature ! Thanks.

Regards,

-- 
Sébastien Luttringer


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Proposal for a new organisation structure

[Sébastien Luttringer via arch-dev-public]

On Sun, 2019-06-02 at 05:55 +0200, Christian Rebischke via arch-dev-public
wrote:
> On Sun, Jun 02, 2019 at 01:07:12PM +1000, Allan McRae wrote:
> > On 2/6/19 9:08 am, Christian Rebischke via arch-dev-public wrote:
> > > 1. Simplified repositories
> > > Currently we have [core], [extra] and [community]. These
> > > threerepositories are there, because they have grown to this structure
> > > overtime. At the moment I don't see any real meaning for the split of
> > > [core]and [extra]. So one suggestion would be to either:  - merge [extra]
> > > and [core]
> > 
> > I stopped reading here.   If you don't understand the difference
> > between[core] and [extra], you should ask.  Particularly before proposing
> > theremoval of [core].
> > Allan
> 
> Hi Allan,I didn't propose the removal of [core], I proposed a discussion
> aroundthe current repository and organisation structure. Merging [core]
> and[extra] is just one of many ideas. If you have something to say, pleasedo
> so and don't keep your secret. I would be glad if you could share it.
> chris

Hello,
[core] packages must land in [testing] and receive signoffs before reaching
[core].In other words, packages in [core] must receive positive feedback before
a wider diffusion.This introduce a latency to lower the risk of base components
breaking.
So, before merging [core] and [extra] we should have a way to flag packages
which requires signoffs.
Secretly,

Sébastien "Seblu" Luttringer


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Moving extra/radvd to [community] (to adopt it)

[Sébastien Luttringer]

Hi,
Package is not orphan. Did I miss a private request from you asking for
adoption?

Cheers,

On Wed, 2018-03-07 at 19:35 +0100, Thore Bödecker via arch-dev-public wrote:
> Hey,
> 
> currently the radvd package sits in extra with an open issue that is
> really annoying:
> 
> https://bugs.archlinux.org/task/57310
> 
> With this mail I'm offering to adopt and maintain this package if
> there are no objections.
> In order for me to do so it would need to moved from extra to
> community as I'm only a TU.
> 
> 
> Cheers,
> Thore
> 
Sébastien "Seblu" Luttringer

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [draft] The end of i686 support

[Sébastien Luttringer]

On Mon, 2017-11-06 at 09:30 -0600, Doug Newgard wrote:
> On Mon, 6 Nov 2017 21:25:49 +1000
> Allan McRae  wrote:
> 
> > In all my time here, I can remember one i686 bug that did not also
> > affect x86_64.  That suggests a common infrastructure is warranted.
> > 
> > A
> 
> I haven't been here nearly as long and remember far, far more than
> one.
> 
> Scimmia

Ceph is a living example; since two major versions, it doesn't build on
i686.
This put aside, I'm in favor to offer hosting to ports architectures
which need it.
Cheers,

Sébastien "Seblu" Luttringer



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] systemd - move to base group and expect it to be installed?

[Sébastien Luttringer]

On Thu, 2017-09-14 at 14:08 +0200, Bartłomiej Piotrowski wrote:
> My main problem with recent changes to filesystem package is that there
> is no clear benefits of using sysusers to do the job. Can anyone
> enlighten me, or is it a change for the sake of change?

- We move the definition of users/groups from 5 redundant files (4 data and 1
script) to 1 clean configuration file.That make the stuff easier to understand
and manage, so it's a benefits to me.- That make users/groups management
coherent between our packages. Filesystem is no more a special case.- Emptying
the passwd, shadow, group and gshadow will prevent future pacdiff on these
files. Whenever it happened, it was annoying for everyone for nothing.- This is
a step forward to have an Arch working with a transient /etc, as all required
users/groups will be created by systemd-sysusers.
I didn't find a good reason to refuse to implement this BR and with hindsight
it's a smart move.Ok, that's not a revolution, but « a change for the sake of
change»? You are harsh!
> From top of my head, it caused issues with pacstrapping with testing,
> dependency cycle,
> OpenSSH and cups, and I'm certain I missed something. 
You are mixing issues from several changes in filesystem and not related
systemd-sysusers.So far the solutions looks good to me. Do you want I sum them
up?Is there one in particular issue you want to discuss outside the bug report?
> If the gain is ditching few lines of bash from install scriplet, we have
> wrong priorities…
What was the gain to change ${CFLAGS} into $CFLAGS to our master plan to
control the universe?Seriously, what is the loss to move to systemd-sysusers?
That a step forward.I don't get why your are not happy that I prioritized this
over swimming with ponies.

Sébastien "Seblu" Luttringer

signature.asc
Description: This is a digitally signed message part

[arch-dev-public] Travel

[Sébastien Luttringer]

Hello,

I'm starting a trip in Malaysia for 3 weeks. I should have network access but
who knows.
So please excuse some jitter in my responses.

Cheers,


Sébastien "Seblu" Luttringer

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] systemd - move to base group and expect it to be installed?

[Sébastien Luttringer]

On Wed, 2017-09-13 at 07:35 +0200, andy...@archlinux.org wrote:
> I've cleaned systemd-sysvcompat long time ago from all my systems. I didn't
> know it is still alive and is meant to pull in main systemd.

pacstrap, the arch-bootstrap tarball and the Arch installation media already
have systemd pulled, so far, I didn't notice a change.

Since filesystem use systemd-sysusers to initialize our users/groups, it should
deps on systemd. It was suggested by Evangelos in FS#55492, but this create a
circular deps, because filesystem <- systemd <- glibc <-  filesystem.
Maybe it's a better solution to make gblic drop filesystem dep and add a
systemd dep to filesystem.

However, put systemd  in the base-devel make also sense like having glibc or
filesystem.

> Lately cups-filters failed to install when building in a clean chroot due to
> missing "lp" group. Having systemd-sysvcompat in base should have pulled in
> systemd and allow "lp" group creation. Maybe this is another trigger of the
> systemd bug.
> We should continue talking on the list. 

I don't think lp is a systemd bug, but a mistake from my side. I forgot to add
it or to ask for moving it like i did for mlocate (FS#53539) or rfkill
(FS#53525). It looks like the lp group is tied to cups and not multiple
packages; do you think it should be moved to cups package?

About the systemd bug, Lennart just pushed a fix which should land in v235. In
the mean time, I think to push a new version with root and nobody defined in
files to not have sshd segfault on new installations.

> Maybe we should stop splitting systemd and simply make it part of "base"
> group to make sure all Arch users have all its parts installed.

Groups are a shortcut to pull a collection of packages. They are not designed
to guarantee a set of packages remain installed. Your removal of systemd-
sysvcompat is one example. If we want to have a set of package installed on all
our Arch, we should use a base package which pull these packages.

Cheers,

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] systemd - move to base group and expect it to be installed?

[Sébastien Luttringer]

On Tue, 2017-09-12 at 22:09 +0200, Andreas Radke wrote:
> Am Tue, 12 Sep 2017 22:02:54 +0200
> schrieb Sébastien Luttringer <se...@seblu.net>:
> 
> > Hello,
> > 
> > Systemd is in the base group since October 2012. Not sure to
> > understand if your problem is about base or base-devel.
> > Most of our packages moved to systemd-sysusers. Would make sense to
> > not have filesystem do the same?
> > 
> > Regards,
> 
> It's in the core repo but not in "base" group.
> 
> root@laptop64:/root # LANG=C pacman -Qi systemd | grep Groups 
> Groups  : base-devel
> 
> And chroots and Arch installation media simply install the full base
> group. So far systemd is not included and we now have a problem with
> user/group creation.

systemd-sysvcompat is in base group, and it pulls systemd.Do a pacstrap, you
will see systemd installed.
Devtools use base-devel, which prevent linux or others non necessary packages
to be pulled to only build packages.

Sébastien "Seblu" Luttringer



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] systemd - move to base group and expect it to be installed?

[Sébastien Luttringer]

On Tue, 2017-09-12 at 19:58 +0200, Andreas Radke wrote:
> New filesystem/systemd packages in testing have changed the way we
> create system users/groups. That's done now via systemd itself or using
> a systemd hook. So every package that needs certain user/group existent
> or certain UID/GID to install its file will depend on systemd to be
> installed on the system.
> 
> Check https://bugs.archlinux.org/task/55492 - systemd is now part of
> base-devel.
> 
> I think it's not consequent not to move it to base group. It's the only
> init system we support and therefor should be expected to be installed
> on every Arch installation from now on. User/group creating packages
> will need it installed in any way.
> 

Hello,

Systemd is in the base group since October 2012. Not sure to understand if your
problem is about base or base-devel.
Most of our packages moved to systemd-sysusers. Would make sense to not have
filesystem do the same?

Regards,


signature.asc
Description: This is a digitally signed message part

[arch-dev-public] Orphaned packages

[Sébastien Luttringer]

Hello,

I orphaned several packages I don't use anymore. The following have no more
maintainer, so if nobody is interested, I will move them to AUR.
- unifi
- rxvt-unicode
- laptop-detect
- python-docutils
- quilt
- rblcheck
Cheers,


Sébastien "Seblu" Luttringer

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Kernel 4.11 status

[Sébastien Luttringer]

On Sun, 2017-05-07 at 21:54 +0200, Bartłomiej Piotrowski wrote:
> On 2017-05-06 08:28, Pierre Schmitz wrote:
> > On 05.05.2017 23:32, Bartłomiej Piotrowski wrote:
> > > On 2017-05-05 08:29, Tobias Powalowski via arch-dev-public wrote:
> > > > Your opinion on pushing this to [testing].
> > > 
> > > I can't care less about binary modules that keep causing problems. +1
> > > for having 4.11 in [testing].
> > > 
> > > Bartłomiej
> > 
> > I disagree. We should not break [testing] on purpose. We actually want
> > people to use [testing] to look for unknown bugs. If we want to drop
> > support for the nvidia module that would be a different discussion.
> > 
> > Greetings,
> > 
> > Pierre
> > 
> 
> There is a difference between intentional breakage caused by our
> laziness (we could fix the code, but we did not) and some proprietary
> blob that we don't control. The bug is the driver itself.
> 
> Bartłomiej

We should continue to make no difference between proprietary softwares and not
in our packaging quality as long as they are in our official repositories.

I didn't read a reason to rush on this before getting more feedback from
upstreams. Not to mention that the fix may finally land into the kernel
package, which is pretty open.

Cheers,


-- 
Sébastien "Seblu" Luttringer




signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] OpenSSL 1.1.0

[Sébastien Luttringer]

On Sat, 2017-02-11 at 09:32 +0100, Pierre Schmitz wrote:
> On 29.01.2017 21:49, Pierre Schmitz wrote:
> > Hi,
> > 
> > I'd like to propose a migration to OpenSSL 1.1. The update comes with
> > ABI and API changes. Every linked packages needs to be rebuild. There
> > will likely be broken packages. Once the protobuf* rebuild has left
> > the [staging] repo I would like to upload a first set of OpenSSL 1.1
> > packages.
> > 
> > I have created a todo list of packages that either have a direct
> > dependency on openssl or link to libssl.so.1.0.0 or
> > libcrypto.so.1.0.0:
> >   https://www.archlinux.org/todo/openssl-110-rebuild/
> 
> I will push the first set of packages to [staging]. Please avoid doing 
> other rebuilds until this one is done.
> 
> Greetings,
> 
> Pierre
> 
When do you plan to move openssl rebuild out of testing?

Cheers,


-- 
Sébastien "Seblu" Luttringer




signature.asc
Description: This is a digitally signed message part

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

[Sébastien Luttringer]

On Sun, 2017-03-05 at 14:35 +0100, Lukas Fleischer wrote:
> ***

To me,
- It make sense to have AUR RPC searchable for username;- Information
are already public, so the question is more about a proper api
interface vs crawling.- Solution should be available for every
registered users, not only for a researcher.
so, go on.
Regards,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [RFC] Send signoff reports somewhere else (or not at all)

[Sébastien Luttringer]

On Mon, 2017-01-02 at 15:50 +, Giancarlo Razzolini wrote:
> Hi All,
> 
>    With the recent archweb migration, some services stopped working.
>    We are just finishing migrating those services (and automating them
>    on ansible). One of these services is the signoff reports emails.
> 
>    For the past few days, the exact same e-mail was sent, from the old
>    setup, and nobody seem to have noticed. I guess most (all) filter
>    these emails out. Also, the service to populate the signoff's wasn't
>    running too, but this one will be kept running.
> 
>    Also, I have been pointed to this[0]. So, should we send signoff
>    reports somewhere else or, not at all?
> 
> Cheers,
> Giancarlo Razzolini
> 
Please drop them.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes

[Sébastien Luttringer]

On Fri, 2016-12-02 at 14:39 +, Giancarlo Razzolini wrote:
> Em dezembro 2, 2016 12:08 Christian Hesse escreveu:
> > 
> > Well, you could provide a sudoers file, a wrapper with 'sudo /usr/bin/ip
> > $@'
> > and add '--iproute /path/to/wrapper' in your unit file.
> 
> Sure. But I guess that the question we must ask is, do we want all this
> on our OpenVPN package? 

No.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes

[Sébastien Luttringer]

On Tue, 2016-11-29 at 16:36 +0100, Christian Hesse wrote:
> Christian Hesse <l...@eworm.de> on Tue, 2016/11/29 15:26:
> > Christian Hesse <l...@eworm.de> on Sun, 2016/11/27 13:20:
> > > Sébastien Luttringer <se...@seblu.net> on Sun, 2016/11/27 03:55:  
> > > > On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:
> > > > > 
> > > > > Any opinion about this change? Who can post news about this on the
> > > > > website?  
> > > > 
> > > > The switch from Type=forking to simple will break units which rely on
> > > > proper ordering of subnets added by that tunnel. That look as a
> > > > regression to me.
> > > 
> > > Can you give more detail on that?
> > > 
> > > For me route-up scripts broke... With Type=simple it is no longer allow
> > > to
> > > send dnsmasq a SIGHUP to flush its cache.  
> > 
> > Apparently the units do not have CAP_KILL, so my script failed sending
> > SIGHUP to dnsmasq. Probably this is just find...
> > I solved this by sending ClearCache command to dnsmasq via dbus.
> > 
> > So still interested in details of your issue...
> 
> And bonus question... Does this fix your issue?
> 
> https://sourceforge.net/p/openvpn/mailman/message/35521176/

Yes. Thanks Christian!

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes

[Sébastien Luttringer]

On Sat, 2016-11-26 at 13:38 +0100, Christian Hesse wrote:
> 
> Any opinion about this change? Who can post news about this on the website?
The switch from Type=forking to simple will break units which rely on proper
ordering of subnets added by that tunnel. That look as a regression to me.

I'm using openvpn on my hosts, few of them are only reachable via its tunnel.
There is other users doing so. I suggest to maximize our chance to warn them by
using both News and post upgrade message.

> 
> Stumbled about another fact... We define PLUGIN_LIBDIR, that allows to use
> relative paths from that directory in configuration to call the plugins. This
> path is '/usr/lib/openvpn' - plugins are installed to
> '/usr/lib/openvpn/plugins', though. Any reason for that?
Never understand that neither. As configuration need to be changed, that's a
good time for changing this path.

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

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

[Sébastien Luttringer]

On Sun, 2016-10-30 at 22:47 -0400, Dave Reisner wrote:
> 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:
> > 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.
> 
Over the time, I found a problem using $SRCDEST; it doesn't check if upstream
sources have been modified since. I've been tricked few times, releasing
packages with my local tarballs and not the one available to others.
Maybe it's something which can be improved directly in makepkg.

My point was to explain why I didn't already switched to https on all my
packages, and see if we have a place in our rules for letting this happen, or
if we want enforce the all case.
This, in some way, reduce the choice of the maintainer to select which sources
he prefers.

I didn't bring that as a show stopper for improving the source transport
security.


> > 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.
> 
I understand security is not binary.

TLS is about security of the transportation of sources, not the security of
sources themselves, that's why I asked, to know what you had in mind.

My definition of securing the sources, is a way to trust the sources at the
build time, no matter the way they were fetched. I want to be sure that my
sources are "correct" even if I get them by usb key, ftp, rsync or even if they
were not corrupted locally by a btrfs bug.
And when possible, I want to be sure that the server (mirror or not) was not
compromised (even at the first fetch).

Keeping that in mind, enforcing tls, doesn't improve much the source security.
In fact, it improves only security during the transportation of the sources at
the cost of the caching.
So, even though I a partisan of tls everywhere, I still balanced by the
caching.


Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

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

[Sébastien Luttringer]

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

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] New build server ordered

[Sébastien Luttringer]

On jeu., 2016-09-22 at 11:31 +0200, Florian Pritz via arch-dev-public wrote:
> Hi,
> 
> Just to let you know, I've just ordered a new build server.
> 
> After discussion with Jan, we went with a PX61 with HDDs instead of SSDs
> since disk space is always an issue on the old one.
> 

Hi,

I've no opinion on the choice of this new server, my question is more about the 
process. Why this discussion have not been done on the devops mailing list?

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Long out of date packages

[Sébastien Luttringer]

On jeu., 2016-08-18 at 11:29 +0200, Florian Pritz via arch-dev-public wrote:
> On 17.08.2016 23:30, Sébastien Luttringer wrote:
> > 
> > > 
> > > Is that really not enough?
> > Enough for what? If you really wanna help me, you just talk to me and offer
> > your help, but you don't send a rocket on the public list.
> 
> I'm not sure why you bring this up again here since I was under the
> impression we cleared up the misunderstanding an hour before on IRC.
Florian,

I understood you both feel ignored on IRC and you decided to post here to catch
my attention. We cleared that up. Mailing list is our primary way of
communication, that's fine.

«This week I'm going to rebuild dependent packages to disable Ceph support and
then move Ceph itself to AUR».

What would happen If I was in vacation, or for some reason was not able to
answer to this mail in a so short deadline? Imagine my reaction when I came
back to «work»? I'm an active developer since years now, and I never see a
developer treat another else to remove packages he maintains (even with MIA
developers).

When I asked Bartlomiej if that behavior was inappropriate on IRC, I got a yes.
This is why I posted here after the IRC discussion and asked to never do that
again.

So, if you find removing others packages is an appropriate leverage for
communicate, I need more explanation.


Regards,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Long out of date packages

[Sébastien Luttringer]

On mer., 2016-08-17 at 21:35 +0200, Bartłomiej Piotrowski wrote:
> On 2016-08-17 21:20, Sébastien Luttringer wrote:
> > 
> Even without my question on IRC, you at least got out-of-date
> notification and Florian's message about rotten packages.
I see Florian message (good initiative btw). It makes me review my flagged
packages and be happy to not have "more than one year" flagged packages.
It has remembered me that I have Ceph to update. I decided after that to
prioritize packaging updates over devops in the next weeks in order to fix this
(one package).

>  There is also a bug report stating that package is unusable, created in
> February. 
The jerasure code was not enabled in this package. It never works, the rest of
ceph yes. I've 300 hypervisors running Arch with this version. I see no big
deal.

> Is that really not enough?
Enough for what? If you really wanna help me, you just talk to me and offer
your help, but you don't send a rocket on the public list.

«Seb, I think we are providing a bad user experience to not updating Ceph since
so long» would be a better approach.
I get a user offering his help by mail few days ago about docker 1.12. A
stranger, not a guy I work with like you.

Moreover, I got the same issue with e2fsprogs (not a package like ceph used by
few braves) recently. Package was not updated since ~1 year and it prevented me
from upgrading my raid array to 30TB.
I sent a nice mail to the maintainer and asked him if I can upgrade the
package. He was ok. I did it[1]. End of story.

> 
> > 
> > This kind of threat is inappropriate.
> 
> Lack of communication on your side is inappropriate. If there is a good
> reason not to upgrade a package, put that information somewhere, instead
> of letting it decay.

I don't see much communication about why packages are not updated. Why are you
asking me think others don't do? Why are you targeting me where is this so much
package more out-of-date ?

You sent a resignation mail 1 year and half ago, since then I never see you as
active and not communication about that. That's lack of communication.

I'm spending enough hours by week to works on that projet to not have to
receive this kind of direct attack.
I say it again, this kind of threat are not acceptable between us. Please never
do that again.


[1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/e2f
sprogs=0da897c5e716cd201fc31307991cf875c2c90abd

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Long out of date packages

[Sébastien Luttringer]

On mer., 2016-08-17 at 20:52 +0200, Bartłomiej Piotrowski wrote:
> On 2016-08-06 10:18, Florian Pritz via arch-dev-public wrote:
> > 
> > 
> While I'm no saint either, Ceph package is out of date since November
> last year and received only minor upgrades despite newer releases
> availability. 2 weeks ago I asked Sebastien on #archlinux-devops why he
> didn't upgrade it despite his activity with other packages to no avail.

I didn't get your message on #archlinux-devops. You really didn't find any
other way to talk to me?

I have a working package since few weeks with the latest version. I needs to
check again some things. 

> 
> This week I'm going to rebuild dependent packages to disable Ceph
> support and then move Ceph itself to AUR.
> 
> 
What is this ? Seriously! A blackmail to upgrade package.

ceph was updated 8 months ago. We have flagged packages built in 2013.

You don't even know why I postpone the upgrade.

This kind of threat is inappropriate.


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Discussion about optional dependencies

[Sébastien Luttringer]

On mar., 2016-07-19 at 11:13 +1000, Allan McRae wrote:
> My opinion is the primary binary for a
package should run out of the box.  If you really need to reduce
dependencies, then a split package should be considered.

Comments/opinions?


I think we provide a bad user experience when a program refuse to start
because a shared library is missing. This sounds like a packaging issue
and I agree we should improve the current situation.

Keeping the proposed example, the binary which provides the primary
functions of virtualbox (understand start/stop/edit VM) is vboxmanage.
In fact "virtualbox" is the entry point to the Qt GUI. There is also an
SDL GUI (VBoxSDL) and a no-GUI (VBoxHeadless).
For a server usage (without screen) of virtualbox, the primary binary
runs out the box without the Qt5 deps.

Admin that Qt5 GUI is the primary binary/usage, what "run out of the
box" means? Only display the GUI interface or the features behind ?
When you create a VM (via this primary binary) with hostonly
networking, it will not works until you install net-tools (currently a
optdepds) and it's not obvious to figure out.

So "primary binary" and "run out of the box" not really help to make
the choice with no doubt.
My current opinion is to only use optional dependencies to provides
enhancement to the package which are not creating library dependency
issues.
Which means wherever the virtualbox binary is shiped, the deps to qt5
should be pulled with.

Regards,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] signoffs are dead

[Sébastien Luttringer]

On mar., 2016-07-05 at 20:33 +0200, Bartłomiej Piotrowski wrote:
> On 2016-07-04 22:07, Sébastien Luttringer wrote:
> > On ven., 2016-07-01 at 17:43 -1000, Gaetan Bisson wrote:
> > > [2016-07-01 21:24:47 +0200] Florian Pritz via arch-dev-public:
> > > > Am 2016-06-30 09:41, schrieb Johannes Löthberg via arch-dev-public:
> > > > > That has actually come up on IRC a lot of times over the last couple
> > > > > years, users asking how to sign-off packages / if they can help
> > > > > signing-off.
> > > > 
> > > > I've already got 4 people willing to help, but nobody here voiced an
> > > > opinion
> > > > on this matter yet. Do we want such tester from a dev/TU perspective?
> > > 
> > > That sounds like the best idea so far. It also gives users running
> > > [testing] some kind of a purpose besides the fun of the occasional
> > > breakage.
> > > 
> > 
> > I think we should not promote person as developer because their main work
> > is to
> > test packages. This seems more "support staff" position.
> > 
> > If we want to keep the explicit feedback, we could also open signoffs to
> > our
> > community. The feedbacks will be more representative as only few selected
> > people will test their own needs.
> > 
> > Cheers,
> > 
> 
> No one said anything about promoting such users to developers. That
> would be new role just with signoffs permissions.
> 
Ok. I misunderstood the "Do we want such tester from a dev/TU perspective?"

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] signoffs are dead

[Sébastien Luttringer]

On ven., 2016-07-01 at 17:43 -1000, Gaetan Bisson wrote:
> [2016-07-01 21:24:47 +0200] Florian Pritz via arch-dev-public:
> > Am 2016-06-30 09:41, schrieb Johannes Löthberg via arch-dev-public:
> > > That has actually come up on IRC a lot of times over the last couple
> > > years, users asking how to sign-off packages / if they can help
> > > signing-off.
> > 
> > I've already got 4 people willing to help, but nobody here voiced an
> > opinion
> > on this matter yet. Do we want such tester from a dev/TU perspective?
> 
> That sounds like the best idea so far. It also gives users running
> [testing] some kind of a purpose besides the fun of the occasional
> breakage.
> 

I think we should not promote person as developer because their main work is to
test packages. This seems more "support staff" position.

If we want to keep the explicit feedback, we could also open signoffs to our
community. The feedbacks will be more representative as only few selected
people will test their own needs.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] signoffs are dead

[Sébastien Luttringer]

On mar., 2016-06-28 at 08:09 -1000, Gaetan Bisson wrote:
> 
> Any comment, and especially any other idea to fix this situation, is
> welcome.
> 
I do something like that too but with little more time.
We can move from signoffs to "no blocker bug report" during a period go to
core.

Cheers,


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Hooks!

[Sébastien Luttringer]

On jeu., 2016-04-28 at 23:14 +0200, Christian Hesse wrote:
> Allan McRae  on Sat, 2016/04/23 17:03:
> > According to the news announcement, today is the day we can start using
> > hooks!  (as long as you live in the future like me - those of you in the
> > past will need to catch up a day).
> > 
> > I have started a wiki page to discuss which hooks to add [1]. 
> > [...]
> > 
> > [1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
> 
> I can not edit the wiki page, so discussing here.
> 
> How about a hook that rebuilds kernel initramfs images? Something like:
> 
> 
This is clearly better that the current situation, so +0.5!

But as we are on the topic, could we consider directly moving to kernel-install 
to manage programs used to make the system able to boot (initramfs, bootladers)
?

Initramfs rebuild logic is in a script in /usr/lib/kernel/install.d. Like grub
or others bootloaders.

I have a POC[1] here and I'm using it with good feedback since months.


[1] https://git.archlinux.org/users/seblu/kernel-install-poc.git/

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [PATCH 1/1] move initramfs generation from install script to pacman hook

[Sébastien Luttringer]

On mer., 2016-05-18 at 13:55 +0200, Christian Hesse wrote:
> From: Christian Hesse 
> 
>    # add vmlinux
>    install -D -m644 vmlinux
> "${pkgdir}/usr/lib/modules/${_kernver}/build/vmlinux" 
> +
> +  # install pacman hook
> +  install -D -m644 "${srcdir}/linux-initramfs.hook"
> "${pkgdir}/usr/share/libalpm/hooks/linux-initramfs.hook"
>  }
> 

Hello,

I didn't pay much attention to this, but except dkms, hooks are not ordered.

Could we use a prefix convention to order our hooks? It's usefull to build
modules before building initramfs and eventually run grub update at the end.

Something like:

50-XXX.hook - order doesn't matter
70-dkms.hook - ootm modules build
80-initramfs.hook - initramfs inclusion.

Cheers,


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Introducing git.archlinux.org

[Sébastien Luttringer]

On dim., 2016-04-24 at 16:32 +0200, Sébastien Luttringer wrote:
> I plan to do the switch on 29/4 10PM CEST. This let us one week to test.

This was done in due time but the DNS propagation could take some time
depending of your ISP.

I removed the write rights on the git repositories on gerolde to prevent
incorrect push.

Remember to change your remote in order to push.

Regards,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

[arch-dev-public] Introducing git.archlinux.org

[Sébastien Luttringer]

Hello,

As discussed on the devops list, we plan to move projects.archlinux.org to
git.archlinux.org. Behind this facial change, we will:
- move cgit web hosting from gudrun to luna;
- move git repositories from gerolde to luna;
- switch to the git.archlinux.org DNS.

The http(s):// URLs will be redirect (301) to the new ones and the git:// will
use the DNS CNAMing. So no break from this until we decide.

We could not redirect gerolde.archlinux.org ssh:// to luna, so, a manual update
is required for dev/tu/jouke who .

For example, you will have to set your remote from:
ssh://gerolde.archlinux.org/srv/projects/git/users/seblu/agetpkg.git
to
ssh://git.archlinux.org/srv/git/users/seblu/agetpkg.git
with sed: 's,gerolde,git,;s,projects/,,'

Git repositories are synchronised every hour from gerolde to luna until the
move is fully effective.
I plan to do the switch on 29/4 10PM CEST. This let us one week to test.

SSH access to luna have been created for TUs and Dev based on the ssh-key I
pushed here[1].

Send me an email you have any trouble regarding this.

Cheers,


[1] https://git.archlinux.org/users/seblu/ansible.git/tree/roles/base/vars/main
.yml

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Consensus: DKMS modules

[Sébastien Luttringer]

On jeu., 2016-04-14 at 18:54 +0200, Andreas Radke wrote:
> Am Thu, 14 Apr 2016 13:29:33 +0200
> schrieb Ike Devolder :
> 
> I'm for  binary modules for our -ARCH main kernel pkg. I see no real
> need for -lts modules but if there're a few people who find them
> useful I can handle the kernel rebuilds.
> 
> No opinion about dkms at all. DKMS could be useful if a foo-dkms pkg is
> able to detect all local kernels and build required modules without
> interaction. dkms packages for kernel for which we provide binary
> modules doesn't provide any more comfort for the user to me.
> 

So far, everybody wants (or accept we need) a binary package for -arch kernel.
So, I pushed a binary package for virtualbox -arch kernel modules.

I hope others dkms only packages (ndiswrapper, sysdig) will also provide a
binary version for the -arch kernel. This would be a step forward in a common
way of providing kernel modules.

Regarding binary modules for -lts,-zen,-grsec, I think we should either
provides them or not. But not stay in each packager do is own choice.

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Conclusion: DKMS modules

[Sébastien Luttringer]

On mer., 2016-03-23 at 18:51 -1000, Gaetan Bisson wrote:
> bla bla

> 
> I really wish you'd argue in good faith instead of simply trying to
> steer things your way.

I started promoting a way to manage o-o-t modules with only dkms.
During the discussion, providing binary modules make consensus. So, I made a
concession and moved to a position close to yours, which can be sum as, if we
provide binary modules, we should provides them for all kernels.

Despite this 180° move, you ask me to not steer things my way.

On the other things you wrote, even after a 2 weeks break from Arch, the only
discredit I see from the whole discussion is from you and directed to me.

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Conclusion: DKMS modules

[Sébastien Luttringer]

On jeu., 2016-03-24 at 08:29 +1000, Allan McRae wrote:
> On 24/03/16 07:28, Sébastien Luttringer wrote:
> > 
> > On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
> > 1) No one support that we should manage kernels differently because they
> > are under different repository.
> > ==> We must manage them all the same way.
> I did. 

> > Maxime said building modules for only linux and linux-lts is a
> good compromise. 
Maxime says exactly: "I feel that what Sebastien proposed, ie having built
modules only for linux and linux-lts, and DKMS everywhere else would be a
good compromise IMHO."

Unfortunately, I never proposed linux-lts, it was you.

So, I asked you the reason on IRC:

[2016-03-21 20:32:47]  amcrae: why do you want to manage core kernels
differently than others? And moreover, who cares of -lts nowdays?
[2016-03-21 23:50:44]  seblu: I don't want to manage core kernels
different - preferably all kernels are provided with binary modules

Reading this, and as you were behind the "core kernels" group, I was expecting
you conclude to binary module for the arch kernel, dkms for the rest.
Which is not coherent with the "we are a binary distro", but a common ground.

> > 4) No one object to having dkms available for all modules; It's even
> > supported
> > by several fellows and this is offering support for AUR and custom kernels
> > at
> > almost no maintenance cost.
> > ==> We must provides dkms build for all modules. Except those covered by 2.
> As I said, no-one objected to DKMS modules.  But no opinions were stated
> whether they must be provided.

I did, and

Maxime: "I am somehow biased and in favor of DKMS everywhere"
Florian: "Please go that route" (the route also refer to DKMS everywhere).
Bartłomiej: "IMHO we should have DKMS for all external modules"
Lukas: "I like the idea of having DKMS in the repo"


> > 5) There is no much discussion about which should be the default (a binary
> > flavor or dkms). I would propose a solution which let the user choose which
> > module he want needs by pulling a defined dep like module-$modulename. 
> > ==> Applications should pull a generic deps to let users decide which
> > module he
> > wants (flavored or dkms).
> REALLY?   You need to read that thread again.  Default binary was
> strongly supported.

Yes, binaries are preferred, that was not my point. The keyword was flavor.

For example, vbox was pulling the binary modules for the -arch kernel by
default, not the -lts one or others. As we don't have a way to select the
correct kernel version I find more elegant to pull a virtual name which is
provided.

But like point 6 and 7, I feel you'll claim that is not part of the discussion.
So, let's see that later.


Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Conclusion: DKMS modules

[Sébastien Luttringer]

On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
> Having given everyone time to reply (not that many did...), the
> consensus of those that replied is:
> 
> - Binary modules are to be provided at minimum of all kernels in [core],
> with preference to providing them for all supported kernels (noting that
> out-of-tree modules may not work with some patched kernels).
> 
> - There is no objection to providing DKMS modules in the repos, but this
> is secondary to binary modules.  No opinions were stated on whether we
> ensure all modules have DKMS variants in the repos.
> 
> I decree by the power invested in me through talking the loudest, that
> this is now our policy.
> 

Unexpectedly we got the most feedback from persons who are not dealing
currently with the burden of managing kernels and their modules. Like you I was
expecting more opinions.

Even I support your will of moving forward regarding all this discussion, I
don't share your conclusions nor the fact that one of us could speak lourder to
impose his will to others.
I have few more subjects to discuss altogether where
I hope we could take team directions by constructive discussions and not
decree.

==

I give a second read to all emails exchanged since my original one about o-o-t-
m at 19th February and I come to this:

1) No one support that we should manage kernels differently because they are
under different repository.
==> We must manage them all the same way.

2) No one object to a module exclusion from a specific kernel when it make no
sense Examples was provided with GRSEC.
==> We could exclude modules support for a kernel for technical reasons.

3) There is a consensus on having binary modules in our repositories.
==> We must provides binary modules for all kernels. Except those covered by 2.

4) No one object to having dkms available for all modules; It's even supported
by several fellows and this is offering support for AUR and custom kernels at
almost no maintenance cost.
==> We must provides dkms build for all modules. Except those covered by 2.

5) There is no much discussion about which should be the default (a binary
flavor or dkms). I would propose a solution which let the user choose which
module he want needs by pulling a defined dep like module-$modulename. 
==> Applications should pull a generic deps to let users decide which module he
wants (flavored or dkms).

6) Binary modules should be built from the dkms package. This was not discussed
earlier, but I see a benefits to have a common way of building modules and
testing the dkms package in one row. 

7) https://bugs.archlinux.org/task/48498
==> kernels packages should provides kernel=$version and kernel-
headers=$version in order to let dkms modules maintainers require at least a
kernel and its header to be installed.

This is the policy I propose we adopt.

Note that this policy is not defining who is responsible of what. We could keep
our current way of doing. I mean:
- When a kernel is upgraded, it's kernel maintainer responsibility to upgrade
all binary modules
- When a module is upgraded, it's the modules maintainer responsibility to
build the module for all kernels in stable and in testing (This is boring).

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] DKMS modules for virtualbox

[Sébastien Luttringer]

On mer., 2016-03-09 at 12:10 +1000, Allan McRae wrote:
> On 09/03/16 11:44, Sébastien Luttringer wrote:
> > 
> > On mer., 2016-03-09 at 10:19 +1000, Allan McRae wrote:
> > > 
> > > On 09/03/16 09:29, Sébastien Luttringer wrote:
> > > > 
> > > > 
> > > > On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
> > > > > 
> > > > >  
> > > > > 1) pre pacman-5.0 updates unsupported without any prior notification
> > > > Interesting. This issue will also be present if we move other stuff
> > > > like
> > > > update-desktop-database to hooks, right? Do we have a way to detect
> > > > pre-
> > > > pacman
> > > > 5 update to display a warning or handle it correctly?
> > > There needs to be a public announcement made that we expected everyone
> > > to have updated to pacman-5.0 by .  Then we start
> > > using hooks.
> > There is no way without breaking people updating their Arch from pacman 4.x
> > after that random date?
> > 
> That is the only way.  Joys of rolling release.

If pacman was able to update itself first, as it does before, this would,
rolling release or not, do the job?

> > > > As we currently not have the infrastructure to build binaries modules
> > > > each
> > > > time
> > > > a new kernel version (flavoured / versioned) is pushed, 
> > > Surely that is a five line script...
> > Please provide it. We are building all our kernel modules manually for
> > years.
> > 
> > How this will work? When I push a new version of virtualbox on svn a
> > builder
> > will pick the current kernel and build the modules from my dkms version and
> > push them to the repo? Which key will sign these packages? How this will be
> > synced with db-update?
> What has pushing a new version of virtualbox got to do with rebuilding
> modules when the kernel is updated?  Rebuilding modules on kernel update is:
> 
> for pkg in ; do
>    archco 
>    // awk/sed line to bump pkgrel
>    testing-x86_64-build && testing-i686-build
>    testingpkg "module rebuild"
> done
> 
> OK - I was wrong.  That is six lines (or seven if you count the line
> with && as two lines...).
> 
> > 
We are definitely not talking of the same thing. I was talking of an automated
way of building o-o-t modules when the dkms package is updated or the kernel is
bumped. Was you are proposing, is what I referred as manually.

==

Before going further, keep in mind that I'm open to bring back pre-built
modules for virtualbox. But currently there is no rules and no coherence
between our way of doing.

Let me summarise the situation with the following table:
| package name             | linux | linux-lts | dkms |
| acpi_call                | yes   | yes       | no   |
| bbswitch                 | yes   | yes       | no   |  
| nvidia                   | yes   | yes       | yes  |
| nvidia-340xx             | yes   | yes       | yes  |
| nvidia-304xx             | yes   | yes       | yes  |
| ndiswrapper-dkms         | no    | no        | yes  | 
| r8168                    | yes   | yes       | no   |
| rt3562sta                | yes   | no        | no   |
| sysdig                   | no    | no        | yes  |
| vhba-module              | yes   | no        | no   |
| virtualbox-host-modules  | no    | no        | yes  |
| virtualbox-guest-modules | no    | no        | yes  |

So, each maintainer do what he wants.

Please note that as an ideal target, I would have all our kernel modules
available via dkms _and_ via prebuilt modules for each kernel flavor we
provide. I read on the dev IRC that few modules could only be shipped from
sources. Not sure of that btw.

For example, we could, for simplicity says that we provide pre-built modules
only for the main kernel and dkms for all others kernels.

What I would like is a team consensus/decision on how we handle kernel oot
modules not complains directed on virtualbox only.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] DKMS modules for virtualbox

[Sébastien Luttringer]

On ven., 2016-03-11 at 07:49 +0100, Bartłomiej Piotrowski wrote:
> On 2016-03-09 02:44, Sébastien Luttringer wrote:
> > 
> > Debian provides its vbox modules only via dkms and it's not a source
> > distribution (as far I know).
> Sure, and as far as I know, we are not Debian.
> 
> 

No one doubts that. The point was we are not a source distribution because we
offer to build o-o-t-m from sources.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] DKMS modules for virtualbox

[Sébastien Luttringer]

On mer., 2016-03-09 at 10:19 +1000, Allan McRae wrote:
> On 09/03/16 09:29, Sébastien Luttringer wrote:
> > 
> > On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
> > > 
> > > 1) pre pacman-5.0 updates unsupported without any prior notification
> > Interesting. This issue will also be present if we move other stuff like
> > update-desktop-database to hooks, right? Do we have a way to detect pre-
> > pacman
> > 5 update to display a warning or handle it correctly?
> There needs to be a public announcement made that we expected everyone
> to have updated to pacman-5.0 by .  Then we start
> using hooks.
There is no way without breaking people updating their Arch from pacman 4.x
after that random date?

> > We are not a source based distribution.
Debian provides its vbox modules only via dkms and it's not a source
distribution (as far I know).

Not to mention, that we are not providing binary modules for all our kernels,
or all our modules in binary for months and we are stil not a source
distribution.

> > Binary packages should be the default.
It also elegant to default to a package which works with all kernels.

> > As we currently not have the infrastructure to build binaries modules each
> > time
> > a new kernel version (flavoured / versioned) is pushed, 
> Surely that is a five line script...
Please provide it. We are building all our kernel modules manually for years.

How this will work? When I push a new version of virtualbox on svn a builder
will pick the current kernel and build the modules from my dkms version and
push them to the repo? Which key will sign these packages? How this will be
synced with db-update?

We will even be able to provide binary modules for all kernel we have in core
and in cty without much effort.

Cheers,


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] DKMS modules for virtualbox

[Sébastien Luttringer]

On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
> 

Before going technical, I want to make a quick summary of what happened so far.
Earlier in February, I started a thread on this ml about improving our "out of
tree modules" management with dkms. My planned final step[1] was to let vbox
rely on this solution and so drop the binary modules. I pushed a vbox package
in testing and feedback was requested. 8 days later, the openssl rebuild came
up and moved vbox to community. This pushed vbox out of testing a bit too fast
(no message, no enough test). So we are now.

> What are the advantages from a user perspective? 
Have all its vbox modules the same way whatever kernel it uses (-arch, -lts,
-grsec, -zen-, -custom).

> Why are we no longer shipping virtualbox modules pre-build?
It removes the sync burden of kernel upgrades and its modules upgrades from the
maintainers.
Knowing that I have a 512Kbit/s connection at home, that not nothing to me.

> Is this happening for any other modules?
In my knowledge, there is no global plan. Even I would like have all our binary
modules have its -dkms counterpart to properly handle each kernel flavours.

Currently, we have both kind of modules in our repo. ndiswrapper is provided
with no binary and bbswitch is only binary. So both way seems acceptable.

> Bad things I see:
> 1) pre pacman-5.0 updates unsupported without any prior notification
Interesting. This issue will also be present if we move other stuff like
update-desktop-database to hooks, right? Do we have a way to detect pre-pacman
5 update to display a warning or handle it correctly?

> 2) notification of need for linux headers is only given (optional dep)
> in update that needs them for building.  There is no reason given why
> they are optional dependencies.  There is no notification that the build
> did not go ahead at the end of the transaction.
I agree, this is not good, but this is not something new for users of dkms
packages. dkms modules never pull a particular version of the kernel headers
because there is no reason to deps on linux-headers more than linux-lts-header, 
linux-zen-headers, linux-grsec-headers. What we want is to pull at least one
kernel header.

A bug report[2] was opened, and I hope we will find a solution with kernel
maintainers to request kernel headers to be present not depending on the
flavor.

I will add a message in the dkms alpm hook to notify when kernel headers are
missing and prevent module installation when only headers are present (causing
issue with later kernel installation).

> 3) Update is now a lot slower and this is repeated over a lot of users)
> 4) additional download/install size (linux headers + module source).
> 5) I don't want to have compiler or kernel headers installed.
> 
I acknowledge that.

I like the idea of having several flavor of the Linux kernel inside Arch Linux
and I would like we have a proper support of out-of-tree-modules for all of
them. Moreover, I hope we will introduce versioned kernel to fix the kernel
upgrade which remove the current running modules or break the boot.
All of this will multiply the complexity of the sync between binary modules and
the kernel release for packages maintainers.

As we currently not have the infrastructure to build binaries modules each time
a new kernel version (flavoured / versioned) is pushed, dkms seems a good
trade-off if we want to move forward this way.

So, even I think we should not, I'm not against having binary modules for vbox
in cty, but I would use dkms as default and let the maintainer of the binary
modules handle them.

Cheers,

[1] https://lists.archlinux.org/pipermail/arch-dev-public/2016-February/027770.
html
[2] https://bugs.archlinux.org/task/48498



-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] DKMS modules for virtualbox

[Sébastien Luttringer]

On March 8, 2016 11:16:55 AM GMT+01:00, Allan McRae  wrote:
>On 07/03/16 18:51, Andrea Scarpino wrote:
>> On Sun, Mar 6, 2016 at 12:44 PM, Bartłomiej Piotrowski <
>> bpiotrow...@archlinux.org> wrote:
>> 
>>> 5) As an end user, I don't want to have compiler or kernel headers
>>> installed.
>>>
>> 
>> ^ This.
>> 
>
>Is the virtualbox maintainer going to comment on this thread and
>justify
>the use of dkms?
>
>A

Yes he will. The early move of virtualbox from cty-testing to cty didn't 
schedule well with my free time.
Will answer this evening.

Cheers,
-- 
Sébastien "Seblu" Luttringer
Sent from my phone, please excuse typo and brevity. 

Re: [arch-dev-public] out of tree modules and alpm-hooks

[Sébastien Luttringer]

On ven., 2016-02-19 at 17:47 +0100, Maxime Gauduin wrote:
> On Fri, Feb 19, 2016 at 4:12 PM, Sébastien Luttringer <se...@seblu.net>
> wrote:
> 
> > I didn't tried them but I don't get how this can works when you
> > install/update
> > a dkms module.
> > 
> I'm aware of that, they were designed that way. That's why with those, and
> your hook triggered by dkms package transactions, every case will be
> covered. I guess it could be possible to handle both within a single hook
> by adding an additional trigger on "usr/src/*" and so on, but I think it's
> probably better to keep them separate.
> 
ok, you want to trigger dkms modules install/uninstall when a kernel is
added/upgraded/removed. Make sense. I completely rewrote the hook and the
script to manage all features you want in version 2.2.0.3+git151023-4.

So, with the last version of the dkms hooking system:
- When a kernel package (with headers) is installed, all DKMS modules are
installed for this kernel (means built and copied into the new kernel modules
tree). Detection is done via alpm-hooks Type=File on
/usr/lib/modules/*/build/include.

- When a kernel package (with headers) is removed, all DKMS modules are removed
for this kernel. Detection is done via alpm-hooks Type=File on
 /usr/lib/modules/*/build/include.

- When a DKMS module package is installed, its kernel modules are installed
(means registered in dkms, built, copied into the modules tree) for each kernel
with headers on the system. Detection is done via alpm-hooks Type=File on
/usr/src/*/dkms.conf

- When a DKMS module package is removed, its modules are removed (means
unregistered from dkms and removed  from the modules tree) of each kernel with
headers on the system. Detection is done via alpm-hooks Type=File on
/usr/src/*/dkms.conf

As dkms do automatically add and build modules when you install them, we don't
need anymore to register/unregister dkms modules in post_install/pre_remove. So
we'll be able to lighten our dkms modules packages. :)

Next steps:
- move dkms to extra, as it is pulled by packages in extra (e.g nvidia-dkms)
- Drop binary modules of virtualbox (and fix the wrong modules path in
/usr/src)

Testing and feedbacks of the dkms package in cty-testing is welcome.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] out of tree modules and alpm-hooks

[Sébastien Luttringer]

On ven., 2016-02-19 at 08:12 +0100, Maxime Gauduin wrote:
> On Fri, Feb 19, 2016 at 2:27 AM, Sébastien Luttringer <se...@seblu.net>
> wrote:
> What about when you remove a dkms package? Would be nice to remove the
> build modules as well.
This is done by post install scriplet[1] of each dkms module package (e.g it
calls "dkms remove vhosthost/${1%-*} --all").

Name and version of the dkms modules to remove is not easy to guess in a global
hook. Also note that a dkms module can build several kernel modules.

That's also why registering (dkms add) of the modules is done by install
scriplet.

Only the build/install of registered modules are done by the hook in order to
schedule them properly.

> With these hooks [1] designed for kernel transaction, we will have complete
> support of oot modules in pacman.
> 
I didn't tried them but I don't get how this can works when you install/update
a dkms module. 

Your dkms-install hook is triggered by files installation in /usr/lib/modules,
but dkms packages didn't do that at all. They write these files in
/usr/src/$foo and register the dkms module with dkms add.

Files are copied in /usr/lib/modules when you run "dkms install" (so not under
the watch of alpm), so it make no sense to call dkms install again when file
are here.


[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/nvidia-dkms
.install?h=packages/nvidia


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [RFC] archive.archlinux.org

[Sébastien Luttringer]

On ven., 2015-12-18 at 20:10 +0100, Sébastien Luttringer wrote:
> On sam., 2015-10-17 at 21:02 +0200, Sébastien Luttringer wrote:
> > More than one year ago[1] we started to discuss ...
> 
> I made a speech during our last Meetup in Paris about Arch Linux Archive and
> agetpkg.
> 
> Slides are available here: http://slides.com/seblu/arch-linux-archive
> 
> Cheers,
> 

Hello,

archive.archlinux.org is online.

I pushed a new release of agetpkg, with the new Archive URL.

I plan to move back agetpkg to extra next week if there is no objection.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] [RFC] archive.archlinux.org

[Sébastien Luttringer]

On dim., 2015-12-20 at 09:32 +1000, Allan McRae wrote:
> On 20/12/15 09:26, Sébastien Luttringer wrote:
> > I plan to move back agetpkg to extra next week if there is no objection.
> 
> I am assuming agetpkg is for dealing with archived packages (which are
> unsupported).  The reasonv for not including AUR helpers in the repos
> was that they give what appears like supported access to unsupported
> content.  Why should agetpkg be considered any different?
> 

I think there is a difference between outdated official packages and non-
official packages. The last may not have the level of quality, trust and be
harmful for a system. So preventing helpers to be in official repository make
sense.

In the other hand, agetpkg helps to retrieve previous official packages in
order to troubleshoot or rescue a broken system when they are missing in
/var/cache/pacman/pkg/X.

I think what is not supported is non-official packages and reporting issues
about non up-to-date packages, not downloading an outdated one.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] [RFC] archive.archlinux.org

[Sébastien Luttringer]

On sam., 2015-10-17 at 21:02 +0200, Sébastien Luttringer wrote:
> More than one year ago[1] we started to discuss ...

I made a speech during our last Meetup in Paris about Arch Linux Archive and
agetpkg.

Slides are available here: http://slides.com/seblu/arch-linux-archive

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

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

[Sébastien Luttringer]

On ven., 2015-12-18 at 14:57 -0500, Dave Reisner wrote:
> On Dec 18, 2015 14:43, "Sébastien Luttringer" <se...@archlinux.org> wrote:
> I assume this is a copy paste error... Seems like you're suggesting we use
> resolved by default?
Yes it is, the new hosts line will be:
hosts: files resolve mymachines myhostname

Yes too, I'm suggesting to use nss-resolve by default, as it switch to nss-dns
for configuration with systemd-resolved disabled.

> > 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.
> 
The idea behind this is to clean our default PATH from the useless difference
between sbin and bin.

--- profile (revision 256723)
+++ profile (working copy)
@@ -4,7 +4,7 @@
 umask 022
 
 # Set our default path
-PATH="/usr/local/sbin:/usr/local/bin:/usr/bin"
+PATH="/usr/local/bin:/usr/bin"
 export PATH

I'm fine with dropping the symlink, it will be easier and no announcement to
write.
I did that to not break the path search in that directory. Maybe using systemd-
tmpfiles to manage the symlink will offer best of the 2 approach?

Cheers,


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

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

[Sébastien Luttringer]

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

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.

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] discussion about a second arch-security mailinglist

[Sébastien Luttringer]

On sam., 2015-12-05 at 16:47 +0100, Christian Rebischke wrote:
> My other idea would be to close the mailinglist for most of the people
> and move all security related discussions to arch-general. I think
> arch-general is enough.
> 
> What do you think about this issue?
Your second proposal seems fine to me, we should keep arch-secur...@al.org for
ASA.

We have secur...@al.org for highly sensitive issues and arch-gene...@al.org is
fine for discussions (security/bugs/pebcak).

Regards,


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [RFC] archive.archlinux.org

[Sébastien Luttringer]

On Sat, 2015-10-17 at 15:49 -1000, Gaetan Bisson wrote:
> [2015-10-17 21:02:00 +0200] Sébastien Luttringer:
> I just have one question. What is "fsociety.archlinux.org" for? Could
> it
> follow our current naming scheme? Is it different from
> "archive.al.org"?

Currently we have our domains cnaming to real server name. www.al.org p
oints to gundrun. Same idea for archive.

fsociety was a name suggestion for the new server if we pick one.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] [RFC] archive.archlinux.org

[Sébastien Luttringer]

On Sat, 2015-10-17 at 21:26 -0500, Daniel Wallace wrote:
> On Sat, Oct 17, 2015 at 9:20 PM, Gaetan Bisson 
> wrote:
> My question about this is if we allow this into the repositories, an
> ability to go get unsupported package
> easily to install on your system even with a warning about the fact
> that
> they are not supported... can we
> put AUR helpers into the repositories?

There is an important difference between our outdated packages and
external packages, which may not have the level of quality and trust we
expect in official repositories.

Moreover, an AUR package is potentially harmful, where outdated package
aren't. 

AUR helpers you mention are used to get external contents, where
agetpkg helps to retrieve previous packages in order to troubleshoot
or rescue a broken system. There is nothing more allowed that you can
already do with pacman -U /var/cache/pacman/pkg/X.

So, in my opinion, adding AURs helpers it's a different topic.


Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] agetpkg in [extra]

[Sébastien Luttringer]

On Sat, 2015-10-17 at 13:08 +0200, Bartłomiej Piotrowski wrote:
> Sébastien,
> 
> is there any reason why agetpkg landed directly in [extra]? Your
> mirror
> isn't hosted as an official Arch project so far, despite our previous
> discussions on IRC. I don't mind its presence in [community], but
> [extra] is definitely too much for now.
> 
> Bartłomiej

Hi,

[extra] is where devs push their packages and maintain them. Likewise
with [community] and TUs. Nothing more.

I don't really care where agetpkg should land; both [extra] and
[community] are official repositories and they offer the same easy way
to users to get older packages.

Could you tell me where is the link between official arch project (btw
it's not a mirror) and [extra] repository. Almost all packages is in
this repository are not from an official Arch project. Could you be
more specific on the "too much for now"? 
My plan is to make the Archive[1] an official Arch project. I'm
focusing on making the technical parts ready for applying, and agetpkg
is part of this. Moving it to [community] and to moving it back to
[extra] looks like a waste of time, but I can do it.

Cheers,

[1] https://wiki.archlinux.org/index.php/Arch_Linux_Archive

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

[arch-dev-public] [RFC] archive.archlinux.org

[Sébastien Luttringer]

Hello,

More than one year ago[1] we started to discuss making the Arch
Rollback Machine more official. There were pros and cons and I would
give us the opportunity to move forward.

ARM was renamed to Archlinux Archive, following suggestions made
earlier. The ALA acronym is now preferred to avoid confusion with the
ARM architecture. AUR part was removed, the last/month/week links are
optional.

The Archive project is basically a daily snapshot of our official
repositories and ISOs. A description of it if available on our Wiki[2].
Of course this could be improved by anyone who want to help.

Today, this is used for hunting bugs (testing previous working package,
 bisecting at the system scale), rescue systems when broken package are
pushed. Tomorrow, this may provide a ground for reproductible builds.

The project code base[3] is really simple (it's one bash script) and
running a server don't need much maintenance. I was designed keeping
that in mind. I got few donations over the year to provide this service
and one request to create a mirror.

So far, the disk space used is:
# du -hcs iso packages repos/*
60G iso
2,0Gpackages
110Grepos/2013
254Grepos/2014
204Grepos/2015

Some concerns raised about the place of agetpkg[4] in our official
repository so I deleted it. agetpkg is a command line tool used to
easily download previous versions of packages for debugging purpose.
For example, with the new gnome 3.8 release, the VFS access to smb
shares was broken. It was really fast and easy to downgrade all gvfs
package to a previous version to confirm (e.g: agetpkg -i gvfs 1.26.0
3)

Let me share the questions I got about the project so far and my
answers.

Q: We will support old packages?
A: No. Nothing change. We already have to check when people report bugs
they upgraded their system to the last version.

Q: We will support partial upgrade?
A: No.

Q: User will become lazy and stop report bugs
A: I don't believe that providing more tools to test will make them
stop reporting. The local cache already stop them to report.

Q: This will add more unwanted works?
A: ARM exists for years. Users already use AUR packages, unofficial
repositories and non-stock kernels and this didn't change our way of
rejecting incorrect requests.

Q: This will lighten your sysadmin time. That's why you want to move it
as an Archlinux project.
A: Not at all. Firstly because I still plan to maintain the Archive for
the Arch project. Moreover, I started another Archive server for my
company.

Q: If you quit the Archlinux project, we will have to maintain it.
A: Even though I'm not leaving, as soon as nobody want to maintain a
service in arch, stopping it is easier than starting it.

The plan I propose for now:
- Add a new server[5][6] to our farm (fsociety.archlinux.org?).
- Move archivetools and agetpkg git repositories into project.al.org
- Add archive.al.org
- Adding agetpkg back to our repositories
- News announcement. With all the warnings about our policy about
downgrades.

Cheers,


[1] https://lists.archlinux.org/pipermail/arch-dev-public/2014-March/02
6011.html
[2] https://wiki.archlinux.org/index.php/Arch_Linux_Archive
[3] https://github.com/seblu/archivetools
[4] https://github.com/seblu/agetpkg
[5] http://www.online.net/en/dedicated-server/dedibox-md
[6] http://www.online.net/en/dedicated-server/dedibox-classic

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

[arch-dev-public] Moving ceph to extra

[Sébastien Luttringer]

Hello,

I plan to move ceph from AUR to extra in order to add rdb support to
qemu.

Plebiscite? Objections?

Regards,

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] Bug tracker permissions

[Sébastien Luttringer]

On 02/03/2015 14:10, Allan McRae wrote:
 
 The TUs can not see these requests to act on them.  All developers were
 given project manager permissions long time ago - should TUs also get
 this?  Or should we wait to see how the bug wrangler goes at reducing
 the queue?

Hi,

Make sense to open bug wrangling to TUs.

Moreover, is there some interest to not automatically reopen tasks ?
That would spread the load of closing them again to all packagers
instead to one bug wrangler.

Regards,

-- 
Sébastien Seblu Luttringer
Archlinux Developer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] user/group management in packages

[Sébastien Luttringer]

On 03/02/2015 17:16, Evangelos Foutras wrote:
 On 03/02/15 17:58, Andrew Gregory wrote:
 -1 for systemd-sysusers unless you can figure out a way to use it in
 pre_install.  In order for the dynamic user creation Allan mentioned
 to work, pacman will have to be changed to use symbolic user names for
 file ownership which requires the user to exist *before* the package
 is extracted.
 
 Yeah, it doesn't seem like systemd-sysusers can be used for that, since
 the user and group information is stored in a sysusers.d file.
 
 But for packages that use static (reserved) user/group IDs, it should
 work a treat. :)
 
Allan, could you clarify your rebuild consign regarding static
user/group to move to systemd-sysusers ?

Cheers,

-- 
Sébastien Seblu Luttringer
Archlinux Developer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] [arch-events] Arch Linux lanyards for FOSDEM

[Sébastien Luttringer]

On 08/01/2015 12:05, Andrea Scarpino wrote:
 I'd like to know how many AL devs/TUs will participate to FOSDEM so I can
 keep one for each official contributor at least.
 
I have not booked yet, but I plan to come.

Cheers,


-- 
Sébastien Seblu Luttringer
Archlinux Developer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

Re: [arch-dev-public] Mailinglist setup changes

[Sébastien Luttringer]

On 26/09/2014 18:44, Florian Pritz wrote:
 Hi,
 
 As discussed a couple months ago I've finally moved mailman from gudrun
 to luna.
 
 Creating new lists from the web interface will now work without admin
 intervention, but the new list will only be available via
 listn...@lists.archlinux.org, not listn...@archlinux.org as before.

Having two domains for the same mailing list is something we should
avoid. Even though we will not create mailing list every day, having new
mailing list in @lists.archlinux.org and old one in @archlinux.org is
not consistent, and it's not really improving the previous situation.

Why do you not setup all the mail stuff (postfix, mailman) on the same
server? Security concerns was around having frontends and packages on
the same server.

Side questions:
- we only have one mx server. Why not put a backup on another of our server?
- lists.archlinux.org currently redirect to bbs, should not be on mailman?

Cheers,

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] perf-trace missing due to a dependency on libaudit

[Sébastien Luttringer]

On 26/08/2014 11:18, Sébastien Luttringer wrote:
 On 05/05/2014 00:56, Daniel Micay wrote:
 The lesser evil seems to be adding only a libaudit package... but it's
 still not going to work if someone tries to use it for what it's
 intended to do. I'll probably go with this if there's no saner idea.

 I get a new request[1] about perf trace functionality.
 Are you going to add libaudit to community?
 
 Cheers,
 
 [1] https://bugs.archlinux.org/task/41690
 
Daniel may I have an answer?

Cheers,

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 16/07/2014 19:26, Sébastien Luttringer wrote:
 Last maintainer of virtualbox binary modules has resigned.
For the last releases of linux-lts[1], virtualbox-modules-lts[2] was not
rebuilt, resulting in bug reports[3][4] with nobody interested to fix.

 Is there a volunteer to take care of them and handle rebuilds ?
Nobody raised his hand so far.


Until recently we share rebuild
- I do a rebuild when I bump virtualbox (only major versions)
- Kernel maintainers do a rebuild when they bump (all version)

As confirmed in bug report[2], a simple fix is to use virtualbox dkms
modules, but Dave asked to wait next pacman release to manage rebuild
during pacman upgrade (with hooks) rather than dkms.service at boot.

Now, I think it's better to drop them and have built at boot time
instead of broken packages in the repo.


[1]
https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/linux-lts
[2]
https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/virtualbox-modules-lts
[3] https://bugs.archlinux.org/task/41602
[4] https://bugs.archlinux.org/task/41375

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Fosdem 2015

[Sébastien Luttringer]

On 28/08/2014 20:07, Jelle van der Waa wrote:
 If we want to organise something as Arch Linux we have
 to pay attention to the following dates:

I'll be there too. That would be great if we could use this European
event to spend some time together. I'm sure this will improve our way of
working together and share on ideas and upcoming projects.
We definitely lack of an ArchCon :)

Cheers,

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 20/08/2014 20:25, Dave Reisner wrote:
 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).
I'm enthused by this feature and systemd-sysusers can offer a more
standard way for managing system users across distro. Nevertheless, It
would be nice if we do not fall into the shortcut of not removing users
bound to a package when we remove it.
That avoid manual removing and I don't see a drawback for doing this.

Do you know why they don't implement the same logic (--create, --clean)
as systemd-tmpfiles in systemd-sysusers?

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

Sergej,


That's not *again* a smooth change! It breaks the logs and files upload
for person using the previous default config.

Why do not you put a message to inform that you will change paths?

Regards,


On 25/06/2014 19:06, Sergej Pupykin wrote:
 Date: Wednesday, June 25, 2014 @ 19:06:46
   Author: spupykin
 Revision: 113563
 
 upgpkg: roundcubemail 1.0.1-3
 
 upd
 
 Modified:
   roundcubemail/trunk/PKGBUILD
 
 --+
  PKGBUILD |   20 
  1 file changed, 12 insertions(+), 8 deletions(-)
 
 Modified: PKGBUILD
 ===
 --- PKGBUILD  2014-06-25 16:59:48 UTC (rev 113562)
 +++ PKGBUILD  2014-06-25 17:06:46 UTC (rev 113563)
 @@ -3,7 +3,7 @@
  
  pkgname=roundcubemail
  pkgver=1.0.1
 -pkgrel=2
 +pkgrel=3
  pkgdesc=A PHP web-based mail client
  arch=('any')
  url=http://www.roundcube.net;
 @@ -19,6 +19,15 @@
  md5sums=('2e1629ea21615005b0a991e591f36363'
   '9ef887b19632239911b287ce0e270ae8')
  
 +prepare() {
 +  cd ${srcdir}/roundcubemail-${pkgver/rc/-rc}
 +  sed -i \
 +-e s|RCUBE_INSTALL_PATH . 'temp.*|'/tmp/roundcubemail';| \
 +-e s|RCUBE_INSTALL_PATH . 'logs.*|'/var/log/roundcubemail';| \
 +config/defaults.inc.php \
 +program/lib/Roundcube/rcube_config.php
 +}
 +
  package() {
mkdir -p ${pkgdir}/etc/webapps/roundcubemail
mkdir -p ${pkgdir}/usr/share/webapps
 @@ -33,14 +42,9 @@
mv config $pkgdir/etc/webapps/roundcubemail/
ln -s /etc/webapps/roundcubemail/config config
  
 -  mv logs $pkgdir/var/log/roundcubemail
 -  ln -s /var/log/roundcubemail logs
 -
install -Dm0644 $srcdir/apache.conf 
 $pkgdir/etc/webapps/roundcubemail/apache.conf
  
 -  rm -rf temp
 -  ln -s /tmp/roundcube temp
 -
 +  rm -rf temp logs
install -dm0755 $pkgdir/usr/lib/tmpfiles.d
 -  echo d /tmp/roundcube 0770 http http - 
 $pkgdir/usr/lib/tmpfiles.d/roundcube.conf
 +  echo d /tmp/roundcubemail 0770 http http - 
 $pkgdir/usr/lib/tmpfiles.d/roundcube.conf
  }
 


-- 
Sébastien Seblu Luttringer
https://seblu.net
GPG: 0x2072D77A

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

[Sébastien Luttringer]

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.

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.

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?

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.

Cheers,

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

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 16/07/2014 22:13, Dave Reisner wrote:
 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:
 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. 

I am embarrassed I don't see why it's too late. I'm doing this for 3
years, maybe I'm a lucky idiot. We also have users who use vbox-dkms
package doing this without any bug report about a race condition.

 What about dkms-based modules which you're trying to build into the 
 initramfs? 
There is few reason to embed vbox modules inside the initramfs, but
anyway, I guess it's up to the initramfs software you use to trigger the
build of dkms managed modules (for the requested kernel) it wants to ship.

We can have an mkinitcpio hook which build all the dkms modules for the
targeted kernel.

However, the pacman ordering issue is back, until next release of
pacman... which is, fortunately, expected in august.

 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.
The build can continue far after your KDE desktop environment has
started. If you run virtualbox GUI before the build finish you will get
the message that modules are missing. I think our user are able to deal
with that.

 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.
I'm only suggesting this for virtualbox modules, but, you are right, we
can simplify our way of managing all external modules by using dkms.

I know there are pros and cons to this solution, that's a team decision,
not mine. I see this as a better simple stupid solution with our
currrent tools.

 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.
ok, you are talking of bug reports during the transition phase.

So, if we do that, we should handle the transition smartly. I think to
replaces/conflits and advertise in .install. We can even put a global
announce if you think it's necessary.

Don't believe that I'm in love with dkms. It's an helpful crap. I would
prefer have a brand new Lennart systemd glue[1] or anything more elegant
to manage out-of-tree modules. But it's currently the most spread solution.

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

Remember the title of my mail. I didn't start by Burn the vbox
modules. I'm looking for someone who want to be maintainer of these
packages to handle official kernels rebuild and deal with bug reports.

Of course, I would prefer to drop them, because I feel them unnecessary.
They slow down the release process (of the kernel and virtualbox) and
cause issues.

Cheers,

[1] With depends (and wait) on modules instead of using
systemd-modules-load.

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

Hi,

That's not a smooth change! Although that seems an easy way to
differentiate arpwatch traffic from root one, a small message in the
.install should be the minimum.

That break most users setup.

Regards,

On 06/06/2014 19:28, Sergej Pupykin wrote:
 Date: Friday, June 6, 2014 @ 19:28:18
   Author: spupykin
 Revision: 112774
 
 upgpkg: arpwatch 2.1a15-14
 
 upd
 
 Modified:
   arpwatch/trunk/PKGBUILD
 
 --+
  PKGBUILD |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 Modified: PKGBUILD
 ===You didn't notice that you change the mail target 
 of arpwatch mail.

 --- PKGBUILD  2014-06-06 17:16:15 UTC (rev 112773)
 +++ PKGBUILD  2014-06-06 17:28:18 UTC (rev 112774)
 @@ -4,7 +4,7 @@
  
  pkgname=arpwatch
  pkgver=2.1a15
 -pkgrel=13
 +pkgrel=14
  pkgdesc='Ethernet/FDDI station activity monitor'
  arch=('i686' 'x86_64')
  url='ftp://ftp.ee.lbl.gov/'
 @@ -28,6 +28,8 @@
sed -i 's/-\(o\|g\) bin/-\1 root/g' Makefile.in
# Update ethercodes with recent OUI. See gen_ethercodes.sh
cp -f $srcdir/ethercodes.dat ethercodes.dat
 +  # Do not spam root user
 +  sed -i 's|root|arpwatch|' addresses.h.in
  }
  
  build() {
 


-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Moving network stuff to extra

[Sébastien Luttringer]

Hello,

I plan to move netfilter libraries and tools to extra to have all the
basic kernel network tools into our first class repository :)

We currently have iptables in core but ebtables, arptables and the next
generation framework nftables into community.

I'm also thinking about moving some widely used network daemon like
bind, radvd, quaggua and bird.

Cheers,

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 25/06/2014 22:17, Florian Pritz wrote:
 On 23.06.2014 19:42, Florian Pritz wrote:
 I haven't yet look into also migrating mailman from gudrun to nymeria
 or maybe alderaan. 
 
 When I created aur-requests I had to edit 3 files on 2 hosts to get the
 list to work. I'd like to change that so adding a new list is as easy as
 just adding it via the mailman webui.
 
 Best way to do that would be to move the list addresses to a subdomain
 and simply forward all mail for that domain to mailman. (I do that on my
 server)
 
To me, best way include to not change our mailing lists addresses.

Put all the mail stuff on the same host, mx and mailman interface (which
has already his own hostname) would offer an easy mailing list addition.

I tend to think that a different machine than nymeria would be a better
option to isolate our mail functions from package management on our
infrastructure.

We also have the same synchronization issue with accounts and we could
easily save addition and removing time by adding an ldap server.

But you could also sync mailman aliases over 2 hosts to solve this
multiple edition and prevent to change our mailing lists addresses.

Cheers,

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]

[Sébastien Luttringer]

On 17/05/2014 14:57, Allan McRae wrote:
 On 17/05/14 22:40, Bartłomiej Piotrowski wrote:
 It's temporarily
 built using Clang, mainly because new gcc snapshot hasn't fixed
 segfaults for everyone.
 
 Please file bug reports for breakages caused by the gcc update.  I can
 not track/report/fix bugs that are not brought to my attention.

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

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] perf-trace missing due to a dependency on libaudit

[Sébastien Luttringer]

On 05/05/2014 00:56, Daniel Micay wrote:
 The lesser evil seems to be adding only a libaudit package... but it's
 still not going to work if someone tries to use it for what it's
 intended to do. I'll probably go with this if there's no saner idea.
I think it's a good thing to restore perf trace functionality.
Don't care if you add audit or libaudit.

Nevertheless, I think we could have discuss that inside a perf bug report.


-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 19/04/2014 01:21, Connor Behan wrote:
 On 18/04/14 04:09 AM, S?bastien Luttringer wrote:
 On 16/04/2014 06:09, Daniel Micay wrote:
 I don't think it makes sense to bother with the
 nvidia module because it would be a bit silly to mix it with grsecurity.

 Why user with nvidia cards should be deprived of grsec security enhancement?
 Because the use of closed-source kernel modules is inherently insecure
 anyway.
 
We use closed-source components on our computer everyday (BIOS,
firmwares) because we trust hardware provider like Nvidia.
I wouldn't says that people who have Nvidia cards and run Nvidia drivers
are in an inherently insecure situation.

There are features in grsec which can be useful even with an Nvidia
module (hide others users process, restricted ipc, etc).

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 18/04/2014 10:44, Daniel Micay wrote:
 On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
 On 16/04/2014 06:09, Daniel Micay wrote:
 I could build these myself when I push a new version, because there
 aren't many of them. 
When I will push a new version of Virtualbox, which currently provides
modules for linux and linux-lts. I will have to build a third external
package for linux-grsec, like every modules maintainer.

 I don't think it makes sense to bother with the
 nvidia module because it would be a bit silly to mix it with grsecurity.
 
Why user with nvidia cards should be deprived of grsec security enhancement?

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 18/04/2014 11:40, Massimiliano Torromeo wrote:
 In data venerdì 18 aprile 2014 11:34:14, Sébastien Luttringer ha scritto:
 On 18/04/2014 10:44, Daniel Micay wrote:
 On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
 On 16/04/2014 06:09, Daniel Micay wrote:
 I could build these myself when I push a new version, because there
 aren't many of them. 

 When I will push a new version of Virtualbox, which currently provides
 modules for linux and linux-lts. I will have to build a third external
 package for linux-grsec, like every modules maintainer.
 
 How about only using dkms for third-party modules for kernels outside of 
 [core]?
 
I love this idea :)

-- 
Sébastien Seblu Luttringer
https://seblu.net
GPG: 0x2072D77A

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

[Sébastien Luttringer]

On 18/04/2014 13:07, Daniel Micay wrote:
 On 18/04/14 05:34 AM, Sébastien Luttringer wrote:
 On 18/04/2014 10:44, Daniel Micay wrote:
 On 18/04/14 04:09 AM, Sébastien Luttringer wrote:
 On 16/04/2014 06:09, Daniel Micay wrote:
 There's no problem with simply not building a VirtualBox module for the
 linux-grsec kernel. 
Being not consistent is a problem to me. But nothing which I can overcome.

 You're not building one now, so there would be
 nothing gained or lost. 
I build 2 modules for each release[1]. Could be 3 tomorrow. I miss your
point.

 Supporting out-of-tree modules wasn't something
 I planned on considering at all right away.
Suggestion of Massimiliano is fine to me. If we all agree to get ride of
compiled modules, there is no burden to me to grsec kernel addition.
This even open the door to talk about versioned kernel :)


-- 
Sébastien Seblu Luttringer
https://seblu.net
GPG: 0x2072D77A

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

[Sébastien Luttringer]

On 25/03/2014 08:04, Thomas Bächler wrote:
 Am 24.03.2014 23:35, schrieb Sébastien Luttringer:
 Hello,

 As you may know I'm running ARM[1] since the last maintainer resign in
 August 2013. I would like to propose its addition into our official
 services.
 
 As a side not, may I point out that the name 'ARM' is poorly chosen for
 this service?
 
 
I kept it for legacy reason back in 2013. I share your concern and
that's why I suggest to rename it to archive / museum / rollback. Do you
feel confident with this renaming proposal?

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 22/03/2014 19:50, Florian Pritz wrote:
 Disclaimer: I have experience with multiple Hetzner boxes, their support
 work flow and they have a forum which has a good amount of insider info
 which I like a lot. Better the devil you know ...
The relation with your box provider is very important and I fully
understand that's a key choice. You don't choose your server only based
on price and technical specs.

 Not sure which OVH offers you are talking about. Those you linked are at
 best 16GiB RAM and and i5 and ofc no ecc ram.
I pointed out Kimsufi (OVH) boxes for their low cost because they allow
to split services between hosts instead of having all in a big expensive
server. Smaller boxes with dedicated CPU and unlimited bandwidth. For
example one for forums, one for wiki, etc. Maybe it's an option you
didn't consider for pricing reason.

 The cpu is weaker (e3-1270v3 vs e3-1240v3), 
100Mhz[1] :)

I'm feeling that you (and probably Pierre too) are more confident with
Hetzner service. Remember that Online.net has a challenging offer which
may interest you if we want diversify or we need a real unlimited
bandwidth, which come with higher storage (like backup or ...).

 we'd get HW raid (which
 is probably more trouble than it's worth with a 2 disk system) and the
 choice between 600gb 10k sas, 120gb ssd or 3tb sata disks.
I share your feeling with the HW RAID, but you could request to
disabling it and use the raid card as an HBA. What I do on this box.

Cheers,

[1] http://ark.intel.com/compare/75055,75056

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

Hello,

As you may know I'm running ARM[1] since the last maintainer resign in
August 2013. I would like to propose its addition into our official
services.

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
- move installer backups[2]
- add AUR
- backup them (by mirroring or others)

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



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

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.

 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.

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

Git is an awesome SCM, but it was not think to backup stuff, especially
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

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

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

Cheers,

[1] https://seblu.net/a/arm/2013/
[2] http://www.online.net/fr/serveur-dedie/dedibox-classic
[3] http://www.online.net/fr/serveur-dedie/dedibox-pro2k14

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 25/03/2014 01:44, Dave Reisner wrote:
 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.

I'm not expecting less sysadmin load, I could perfectly handle that for
the time to come. But maybe one day, younger guy will replace me or
worst if I met the bus factor.

 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.
I don't think we change anything about that. Partial upgrade are not
supported. We already have to handle users doing this, and we still
continue to kill them if there system is not up-to-date before they
report their issue.

I'm suggesting an archlinux archive, not changing our successful rolling
release model.


 And the SLA? This all seems reasonable at a glance, but I can't speak to
 how this would impact our budgeting.
http://www.online.net/en/dedicated-server/service-level

However, archive service is not a critical service, we can stay at basic
level.


 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.
I don't know how to do this, I'm interested!

Are you suggesting that storing the whole ARM archive into git is a good
idea?

 Having something with faster access and in a similar hierarchy may have
 use cases.
 
 How often do you use the git repo?
Everyday. Did you try to clone the aur-mirror repo?

$ time git clone http://pkgbuild.com/git/aur-mirror.git
Cloning into 'aur-mirror'...
^C
git clone http://pkgbuild.com/git/aur-mirror.git  0,00s user 0,01s
system 0% cpu 2:30,39 total

Not even started in 2m30s.


 Are you really suggesting that mirroring 300GB-3TB of data has no
 cost? 
Yes, no *extra* cost for us.

 Who's hosting the mirrors? 
Like for our current package mirrors. Everyone who offer its help.


 Have they agreed to shoulder the
 additional storage and bandwidth requirements?
You probably miss my suggestion to have separate archive mirrors.

 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
Impact is insignificant on my server.

Last week network graph:
- https://horus.seblu.net/~seblu/archive/if_eth0.png
- https://horus.seblu.net/~seblu/archive/fw_packets.png
- https://horus.seblu.net/~seblu/archive/fw_forwarded.png


-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 25/03/2014 02:02, Gaetan Bisson wrote:
 [2014-03-25 00:55:51 +0100] Sébastien Luttringer:
 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? 

 That'd take 200 GB of disk space. Would you have an estimate of the average 
 monthly
 bandwidth usage?
Not precisely, but I can dig trough the log files and do some math. Say
lesser than 10Mbit/s, as the bandwidth and traffic can be included in
the server price, that doesn't really matter.

 
 Personally, although I think the AUR is a valuable service and that you
 shouldn't be assuming its costs and maintenance alone,...
I guess you are speaking of ARM (Arch Rollback Machine) not AUR here.

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 25/03/2014 02:15, keenerd wrote:
 On 3/24/14, Sébastien Luttringer se...@seblu.net wrote:
 The Rollback Machine has a convenient CLI wrapper to access packages.
 Have you tried using the Rollback Machine with just a browser?  It is
 nearly impossible.  The CLI wrapper makes it much nicer.
I always use the web interface to get packages from ARM. No wrapper. The
unique CLI tool I used was pacman to rollback a whole system.

The ARM server latency is pretty good where pkgbuild.com is a nightmare.

$ time wget -qO/dev/null https://seblu.net/a/arm/2014
wget -qO/dev/null https://seblu.net/a/arm/2014  0,02s user 0,00s system
33% cpu 0,063 tot

$ time wget -qO/dev/null
http://pkgbuild.com/git/aur-mirror.git/tree/?id=0b2c85b0b252c9bab30df2c411d506bf3475a1ae
wget -qO/dev/null   0,17s user 0,74s system 18% cpu 4,970 total

 
 The aur.git backup has no such convenient wrapper.  Yes, it is painful
 to use.  About as painful as trying to navigate the Rollback Machine
 with a web browser.  
I'm not speaking of beauty, but speed and latency of answers.

 Write a front end instead of this vague, nebulous
 proposal.
I did not wish hurt you in any manner. Your aur-mirror.git is a good
initiative. Please don't take it personally.

 Just to clarify the Arch Linux ARM thing.  No one asked to incorporate
 ALARM into the Rollback Machine.  Someone did ask for assistance with
 setting up their own Rollback Machine.  And this guy was not from
 ArchARM, he was an ALARM mirror host.
Sorry if that was not clear in my first mail.

Cheers,

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 22/03/2014 18:15, Ionuț Bîru wrote:
 Update, they found nothing, that's not a surprise and we always had a
 problem with it (bit flip problem from time to time).
 
 I think is time to stop using this server and get a newer one.
 
 You guys mentioned that ecc it's a must. They have ex60 now with 32gb with
 intel xeon. for 69€/mo and for an additional ip we can have ipmi access as
 well but setup is 99€
 
 My idea is to move forums/wiki/aur on this on since we struggle a bit with
 ram on alderaan and use alderaan as build box.
 
 What do you guys think?

Offers from Online.net[1] and OVH[2] seems to be better.

For the same price at Online.net[3] you have:
- No traffic limitation (!!)
- 400 Mbit/s garanteed BP
- Dell iDrac (dell web ipmi) (no additional IP is required)
- Arbor AntiDDOS protection
- 2x3TB

I have one box hosted by them, and the service is good.

[1] http://www.online.net/en/dedicated-server
[2] http://www.kimsufi.com/uk/
[3] http://www.online.net/en/dedicated-server/dedibox-pro2k14

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Looking for maintainers for a few packages

[Sébastien Luttringer]

On 08/03/2014 04:59, Allan McRae wrote:
 I can spend more time dealing with pacman 
 (the patches pile up faster than I can deal with them and
 there are things I want to implement...).
Nice!


 Here is a list of what is on offer:


All these packages interest me, but I prefer only take care of:
coreutils
diffutils
file
less
gzip
patch
grep/pcre
sed
tar
which

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Moving packages into community

[Sébastien Luttringer]

On 11/02/2014 14:39, Bartłomiej Piotrowski wrote:
 On 02/11/2014 02:37 AM, Sébastien Luttringer wrote:
 - Send a message on aur-gene...@al.org
 - Write some lines in the AUR package comments
 - Open a BR for inclusion
 - Push his new package to community

This is a short list of well known places where you can find hints that
someone is already working on moving your package.
I did *not* suggest that you should do one of the previous examples.

I'm not telling you to open a BR before moving a package. I'm too lazy.
But if you move a package, it's a good idea to check if there is bug
report opened (or closed) about it. Like a feature request[1].

 - Test his modification
 - Start his communication with upstream
 - Request some feedback.

All these bullets was to justify, that sometimes, you need more time
than usual before pushing the binary package. That why we should check
the previous places before inclusion.

 Address your issues to TU who modified your package.
Be sure that was the first thing I have done.

However that's not the first time I see this happening during the
inclusion process, that motivated me to share this point on the list and
add this obvious recommendation in our guidelines.

Cheers,

[1] https://bugs.archlinux.org/task/38698

-- 
Sébastien Seblu Luttringer
https://seblu.net
GPG: 0x2072D77A

[arch-dev-public] Moving packages into community

[Sébastien Luttringer]

Hi,

Most of the time, when a TU is working on adding a new package to
community, he could:
- Send a message on aur-gene...@al.org
- Write some lines in the AUR package comments
- Open a BR for inclusion
- Push his new package to community.

This let him time to carefully:
- Test his modification
- Start his communication with upstream
- Warn the former AUR maintainers
- Request some feedback.

So, fellow TU, could you verify, before moving a package from AUR to
community, that it is not already in *and* not already in process of
being included.

I added some lines about that in our Guidelines[1].

Cheers,

[1] https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines

-- 
Sébastien Seblu Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 28/11/2013 07:22, Daniel Isenmann wrote:
 Am 28.11.2013 02:15, schrieb Sébastien Luttringer:
 On 27/11/2013 15:31, Sébastien Luttringer wrote:
 On 27/11/2013 14:57, Alexander Rødseth wrote:
 A bit sad to be starting out the new docker package with the mark of
 shame (epoch=1), but so be it. ;)
 
 That was the reason for the discussion about the way we should rename it
 and the epoch=1 solution which Alexander mentioned.  ;-)
 
I made tests with a local repository with a docker-tray[1] package and a
docker package with epoch set to 1.
It replaces docker version=1.5 and it conflicts with docker (because of
/usr/bin/docker). No need to provides, there is no reverse dep on
docker[2] and it will create issue in the future. It works well.

Daniel, could you handle the renaming and replacing of docker by
docker-tray[1] in extra (I cannot do it)? That let me push new docker as
soon as it's ready.

Cheers,

[1] https://horus.seblu.net/~seblu/docker-tray/PKGBUILD
[2] https://www.archlinux.org/packages/extra/x86_64/docker/
-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

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

[Sébastien Luttringer]

On 27/11/2013 11:35, Thomas Bächler wrote:
 Am 27.11.2013 11:29, schrieb Allan McRae:
 Please don't do this...   11 line output in post_install.   If you
 REALLY need this, use a single line pointing to the wiki page.

 Allan
 
 Usage instructions generally don't belong into install/upgrade messages.
 In the best case, there is no message at all.
 
 In this case, the install message contains basic systemctl commands and
 networking tips, none of this is specific to docker or urgent enough to
 be printed during pacman.
 
 
This package has been pushed to svn too quicly. A discussion has been
started in aur-general[1] and I stated that I'll managing addition.

After a quick talk with Allan, I sent a mail to Daniel, to see if we can
use the name docker for the new package instead of docker-io or
lxc-docker. Let time to Daniel to answer.

On the technical standpoint, this package needs refactoring, maybe build
the binary from the source and not use the binary provided by
dotcloud/docker inc. This needs more work to be done.

Cheers,

[1]
https://mailman.archlinux.org/pipermail/aur-general/2013-November/026223.html

-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A

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

[Sébastien Luttringer]

On 27/11/2013 14:57, Alexander Rødseth wrote:
 A bit sad to be starting out the new docker package with the mark of
 shame (epoch=1), but so be it. ;)
 
 Summary / suggsted plan:
 1. Rename docker (the old one) to docker-tray and add replaces=('docker=1.5')
 2. Upload and add epoch=1 to docker (the new one)
 
 I can do step 2 if someone can handle step 1.
 
To sum up the discution on IRC, there is no hurry to do that.

I'm waiting some answer before pushing this package in our repository.

Cheers,

-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A

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

[Sébastien Luttringer]

On 27/11/2013 15:31, Sébastien Luttringer wrote:
 On 27/11/2013 14:57, Alexander Rødseth wrote:
 A bit sad to be starting out the new docker package with the mark of
 shame (epoch=1), but so be it. ;)

 I'm waiting some answer before pushing this package in our repository.

I got answers/help from upstream. I want underline that they are really
nice and it's a pleasure to work with them.

So, I built a fresh new PKGBUILD[1] for 0.7.0.

Some notes on differences with AUR version:
- docker is built dynamically (and no more upstream blob)
- use upstream version for bash and zsh completions
- move of dockerinit from /usr/libexec to /usr/lib/docker [2]
- use improved systemd service file (e.g make-rpivate) [3]

Now I need to test this new package more deeply.

And we're waiting for Daniel words about renaming current docker
package. In case this is not possible, upstream advice to use lxc-docker[4].

Cheers,

[1] https://github.com/seblu/archpkg/blob/master/docker/PKGBUILD
[2] https://github.com/dotcloud/docker/pull/2924
[3] https://github.com/dotcloud/docker/pull/2925
[4] https://github.com/dotcloud/docker/blob/master/hack/PACKAGERS.md

-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Sébastien Luttringer]

On 04/11/2013 11:54, Alexander Rødseth wrote:
 gnome-commander was last updated 2011-12-10, is currently an orphan
 and no other package needs it.
 https://www.archlinux.org/packages/community/x86_64/gnome-commander/
 
 perl-config-ini was last updated 2013-10-28, is currently an orphan
 and no other package needs it.
 https://www.archlinux.org/packages/community/any/perl-config-ini/
 
 I'm planning to move these two from [community] to AUR.
 

I recently disowned perl-config-ini and perl-mixin-linewise to let a
perl addict TU the opportunity to adopt them. They are no more
dependency of a package I use.

Is there any reason to remove it? Are you hunting orphan packages?

-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] I do not wish to be a bug tracker webmaster

[Sébastien Luttringer]

On Wed, Sep 11, 2013 at 3:14 PM, Dan McGee dpmc...@gmail.com wrote:
 Hey guys,

 Since I don't know where to put this, please please PLEASE stop assigning
 me to bugs/feature requests/etc. related to the bugtracker. Just because I
 maintain the home page doesn't mean I maintain everything web related. I
 have 0% interest in maintaining Flyspray, migrating to a new platform, etc.
I found 4 bugs (15865, 20074, 24999, 36103) opened around
bugtracker/flyspray. Nothing really important in a day to day work.

The most controversial is FS#24999 as flyspray seems still under
development[1] and do job pretty well as far I know.

Jira is free for opensource[2], so we can use it at no software cost
(or even hosting cost). But it's closed source and a running in java.
I receive a lot of complain from engineers in charge of setuping our
company jira.

 It looks like we do need someone to do this; so if anyone knows someone
 that is willing to take a crack at getting us off the antiquated system we
 are using, I can at least help get some database dumps, etc.
As I previously stated, if sysadmin team needs help, I'd be pleased.
But the answer was we are already staffed.
By example, it would be interesting to add a kind of ARM[3] in our
official infrastructure.

Cheers,

[1] https://github.com/Flyspray/flyspray/
[2] https://www.atlassian.com/software/views/open-source-license-request
[3] https://seblu.net/a/arm/

-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A

Re: [arch-dev-public] Nginx

[Sébastien Luttringer]

On Fri, Aug 30, 2013 at 8:34 AM, Allan McRae al...@archlinux.org wrote:
 On 03/08/13 00:59, Pierre Schmitz wrote:
 Am 02.08.2013 15:38, schrieb Sébastien Luttringer:
 Nothing should block a nginx update, so if auth-pam is incompatible,
 it will be dropped.

 Passenger external module will be dropped as it causes too frequent rebuild.

 Yet the current post_upgrade message says it is still there...

 And if you are already envisioning that auth-pam will need to be dropped
 in the future, I'd have to agree with this:

 I'd say better drop all third-party modules even if you use it yourself.
 I don't see why this should be an exception on the contrary: it was not
 merged upstream and it was last updated in 2010. And dropping it in case
 of an issue also introduces unexpected regressions for those users who
 started using it.

 So my recommendation would still be to keep at least the nginx package
 minimal and vanilla.

 Agreed, only provide what upstream does.   The rest should be dealt with
 by ABS/AUR.

 Allan


I will follow the elders. I removed nginx-extra and nginx package in
testing is now purely vanilla modules.

Cheers,

-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A