[arch-dev-public] moving bridge-utils to [extra]

[Christian Hesse]

Hello everybody,

with the release of bridge-utils v1.7 the utility has been deprecated in
favor of iproute2 which supports even more features.

I would like to move it from [core] to [extra] if nobody raises concerns.

https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git/about/
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgprr61Jsd1rf.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Replacing bzr with breezy

[Christian Hesse]

Maxime Gauduin via arch-dev-public  on Mon,
2020/02/03 20:26:
> Any objection?

No.

Just updated etckeeper to opt-depend in breezy. Anybody using this
please test...
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpU45juC_Idc.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Package openvpn in [core]?

[Christian Hesse]

Christian Hesse  on Fri, 2020/01/24 11:27:
> Hello everybody,
> 
> currently the package openvpn is located in our [core] repository and it's
> like that since the beginning of time. [0]
> 
> Following a discussion on IRC and our definition for official repositories
> [1] we think there is no reason to have it there. Thus I would like to move
> it (and its dependency pkcs11-helper) to [extra].
> If you have any concern please raise your hand now!
> 
> [0]
> https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/openvpn=3eb4941a937f2e9dc47ca7273c299d968787a181
> [1] https://wiki.archlinux.org/index.php/Official_repositories#core

Moved.

https://git.archlinux.org/svntogit/packages.git/commit/?id=f32e8fb0f38564f1156ef2c7fffd8ff1598eb2f5
https://git.archlinux.org/svntogit/packages.git/commit/?id=2c5087602079e9ac9f2cefffc9be238d7075d483
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpF_xXSLE1bx.pgp
Description: OpenPGP digital signature

[arch-dev-public] Package openvpn in [core]?

[Christian Hesse]

Hello everybody,

currently the package openvpn is located in our [core] repository and it's
like that since the beginning of time. [0]

Following a discussion on IRC and our definition for official repositories
[1] we think there is no reason to have it there. Thus I would like to move
it (and its dependency pkcs11-helper) to [extra].
If you have any concern please raise your hand now!

[0] 
https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/openvpn=3eb4941a937f2e9dc47ca7273c299d968787a181
[1] https://wiki.archlinux.org/index.php/Official_repositories#core
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp781ifxrbi5.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] rsync & bundled zlib

[Christian Hesse]

Christian Hesse  on Wed, 2020/01/15 09:17:
> We had some feedback, so here is the updated proposal:
> 
> --- >8 ---
> rsync compatibility
> 
> Our `rsync` package was shipped with bundled `zlib` to provide compatibility
> with the old-style `--compress` option up to version 3.1.0. Version 3.1.1
> was released on 2014-06-22 and is shipped by all major distributions now.
> 
> So we decided to finally drop the bundled library and ship a package with
> system `zlib`. This also fixes security issues, actual ones and in future.
> Go and blame those running old versions if you encounter errors with `rsync
> 3.1.3-3`.
> --- >8 ---

Posted the news:

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


pgpLOD5Oe5Zvr.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] rsync & bundled zlib

[Christian Hesse]

Christian Hesse  on Mon, 2020/01/13 17:23:
> Hello everybody,
> 
> to date we ship rsync with bundled zlib to keep compatibility with rsync
> up to version 3.1.0 and it's old-style --compress option. This is no longer
> required with rsync 3.1.1, which was released on 2014-06-22 - nearly six
> years ago!
> The bundled zlib carries some security issues, so time to act - one way
> or another.
> 
> Even old-stable Debian Jessie [0] has rsync version 3.1.1. So any concern to
> finally drop bundled zlib and use system zlib?

I pushed the new package to [testing] yesterday.

> I would suggest to post a news item, feel free to give thoughts and
> feedback.

We had just one contra, but even with reasonable error message... I think
rsync is hidden in a lot of scripts, crontabs & what not. A short heads-up
may be of great help.

We had some feedback, so here is the updated proposal:

--- >8 ---  
rsync compatibility

Our `rsync` package was shipped with bundled `zlib` to provide compatibility
with the old-style `--compress` option up to version 3.1.0. Version 3.1.1 was
released on 2014-06-22 and is shipped by all major distributions now.

So we decided to finally drop the bundled library and ship a package with
system `zlib`. This also fixes security issues, actual ones and in future. Go
and blame those running old versions if you encounter errors with `rsync
3.1.3-3`.
--- >8 ---  
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpCAeVzKyHud.pgp
Description: OpenPGP digital signature

[arch-dev-public] rsync & bundled zlib

[Christian Hesse]

Hello everybody,

to date we ship rsync with bundled zlib to keep compatibility with rsync
up to version 3.1.0 and it's old-style --compress option. This is no longer
required with rsync 3.1.1, which was released on 2014-06-22 - nearly six
years ago!
The bundled zlib carries some security issues, so time to act - one way
or another.

Even old-stable Debian Jessie [0] has rsync version 3.1.1. So any concern to
finally drop bundled zlib and use system zlib?

I would suggest to post a news item, feel free to give thoughts and feedback.

--- >8 ---
rsync compatibility

Our `rsync` package was shipped with bundled `zlib` to provide compatibility
with old-style `--compress` option up to version 3.1.0. Version 3.1.1 was
released on 2014-06-22 and is shipped by all major distributions now.

So we decided to finally drop the bundled library and ship a package with
system `zlib`. Go and blame those running old versions if you encounter
errors with `rsync 3.1.3-3`.
--- >8 ---

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


pgpF6fL05LWKb.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Base group removal (was: Reproducible builds progress and the upcoming rebuild of [core])

[Christian Hesse]

Christian Hesse  on Wed, 2019/11/13 13:09:
> Allan McRae via arch-dev-public  on Wed,
> 2019/11/13 12:46:
> > So be prepared for almost the entire repo to hit [testing]
> > soon, and get your sign-off shoes on!  
> 
> Looks like this is a good opportunity to get rid of the base group. So have
> a look at the todo list 'base group removal' [0] if there are outstanding
> packages for you.
> 
> [0] https://www.archlinux.org/todo/base-group-removal/

Never mind... Just took some spare minutes and finished the list. :)
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpWm2tTeGiAH.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Base group removal (was: Reproducible builds progress and the upcoming rebuild of [core])

[Christian Hesse]

Allan McRae via arch-dev-public  on Wed,
2019/11/13 12:46:
> So be prepared for almost the entire repo to hit [testing]
> soon, and get your sign-off shoes on!

Looks like this is a good opportunity to get rid of the base group. So have a
look at the todo list 'base group removal' [0] if there are outstanding
packages for you.

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


pgpVTW5zSX5ue.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Jelle van der Waa  on Wed, 2019/09/11 21:37:
> - Signoff status has been moved up in the Developer Dashboard for more
>   attention

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


pgpaSNSEEmxoH.pgp
Description: OpenPGP digital signature

[arch-dev-public] Away until May 11

[Christian Hesse]

Hello everybody,

I am on vacation until May 11. I have my notebook and a lte router with me,
but I am not sure what my spare time and quality of internet connectivity
will look like. Feel free to touch my packages if required.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpU6zvGz4DDZ.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

[Christian Hesse]

Morten Linderud via arch-dev-public  on Mon,
2019/03/25 00:46:
> On Sun, Mar 24, 2019 at 04:39:54PM -0700, Andrew Gregory via
> arch-dev-public wrote:
> > I don't consider hoping that libarchive doesn't need a rebuild in the
> > near future a great strategy.  That being said, this is really
> > a question of how long of a period we need between libarchive v3.3.3
> > and us making the switch.  I'm not a packager, so I don't have much of
> > an opinion on that.  
> 
> Well, we pride ourselves with having competent users. I think waiting a
> year is conservative and safe. However, personally I think we can wait for
> the next pacman release and write an announcment. Then we give everyone a
> month to update and we can have a smooth transition. Assuming of course
> that everyone is on-board with this change. 

I am in with this. Who ever runs a rolling release distribution and does not
update within half a year did a bad decision. So let's go for it.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpjN1TcPDwRw.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Co-maintainers and less time for packaging

[Christian Hesse]

Morten Linderud via arch-dev-public  on Wed,
2019/03/20 14:02:
> hexedit
> minicom

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


pgpm0h8jKBVOH.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] A contrib repository

[Christian Hesse]

Morten Linderud via arch-dev-public  on Thu,
2019/03/14 01:02:
> This is why we have talked about adding gitolite to host these repositories

I've wanted to propose this a long time ago...

In fact you can give every user full access to it own area in every
repository, while important branches are still protected. I have several git
servers that use something like this:

repo devtools
RW+ = admin
RW+ personal/USER/ general/ = @all
RW  master$ develop$ refs/tags/ = @devtools
R   = @all

-> admin can do everything
-> random user 'foo' can do everything in personal/foo/ and general/
-> random user 'bar' can do everything in personal/bar/ and general/
-> members of group 'devtools' can push to master and develop and push tags,
   but forced push is denied
-> random (authenticated) user can read everything
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpXP18cAl9FK.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Python 2 modules

[Christian Hesse]

Allan McRae via arch-dev-public  on Sat,
2019/02/16 11:19:
> Below is a list of python2 modules that are a dependency for any other
> package. I did not check makedepends and I did not check recursively to
> build this list.

The list contains optional dependencies. How to handle these?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpCaC92oK4Nw.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] rename lcms -> lcms1

[Christian Hesse]

Antonio Rojas via arch-dev-public  on Tue,
2018/09/18 00:19:
> > +1 for removing lcms1. I fixed the packages in the [community] repository.
> > Someone else should fix packages in [extra], because I don't have access
> > to this repository:
> > - geeqie (FS#60091)
> > - gimp (FS#60092)
> > - xsane (FS#60090)  
> 
> All fixed. lcms (and its lib32- and python2- derivatives) can now be
> dropped.

Thanks a lot to anybody involved!

I did not expect this to be possible without bigger hassles. Good thing I
asked the mailing list. ;)
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpEYmElcaqz_.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Request to orphan Snowman's packages

[Christian Hesse]

Balló György via arch-dev-public  on Mon,
2018/09/17 11:15:
> Eric Bélanger (Snowman) was inactive as package maintainer in the past
> two years. [1][2] Is it possible to disown his packages on archweb? I
> think it would better to make it visible that his packages are actually
> orphan.
> 
> https://git.archlinux.org/svntogit/packages.git/log/?qt=author=eric
> https://git.archlinux.org/svntogit/community.git/log/?qt=author=eric

I did adopt some of his packages despite his maintainership some time ago...
So no objections.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpc5E6GpNehh.pgp
Description: OpenPGP digital signature

[arch-dev-public] rename lcms -> lcms1

[Christian Hesse]

Hello everybody,

we have packages lcms (which provides lcms 1.x) and lcms2. The former is
flagged out-of-date every now and then for version 2.x... I would like to
rename the package to lcms1 with replace and provide for lcms. Any concerns?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpsvFwZewP7U.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Replacing pkg-config with pkgconf

[Christian Hesse]

Jan Alexander Steffens via arch-dev-public  on
Thu, 2018/05/24 23:19:
> Any objections?

No, go for it!

Remember to add provides and replaces, and add it to the base-devel group.

We have a number of packages that list 'pkg-config' in makedepends. I
guess these should be touched any time soon.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpYBSbugKpKV.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] systemd, kernel keyring and pam_keyinit

[Christian Hesse]

Christian Hesse <l...@eworm.de> on Fri, 2017/09/29 16:30:
> Christian Hesse <l...@eworm.de> on Mon, 2017/09/18 14:29:
> > Hello everybody,
> > 
> > systemd v233 introduced code that makes use of the kernel keyring,
> > initializing a private keyring for every service and adding a protected
> > key named "invocation_id". This caused some trouble and we reverted it
> > since then.
> > 
> > Things will change with systemd v235, which adds a new option
> > "KeyringMode=" for units. The values are "inherit", "private" and
> > "shared". The commit [0] message and changes give the details. Now
> > cryptsetup units are generated with "KeyringMode=shared", which unbreaks
> > this use case. Other services that use the kernel keyring and want to
> > share secrets with other services have to add this as well.
> > 
> > However login sessions where user context is changed can not be handled by
> > systemd. Looks like we have to update our PAM configurations and add a
> > line for every service where session is expected to use the kernel
> > keyring:
> > 
> > session optional pam_keyinit.so force revoke
> > 
> > This is required for eCryptfs to function properly.
> > Any comments on this? Any concerns?
> > 
> > I would like to keep the upstream keyring behavior with release version
> > 235. Would be nice to have this sorted before.
> > 
> > [0]
> > https://github.com/systemd/systemd/commit/b1edf4456eabc5951d76b96bc7df2db3feebe669
> >   
> 
> So we have a flyspray ticket requesting the same [1] and a report from
> Mantas who is already using a setup with pam_keyinit.
> 
> As systemd upstream started preparing a release and milestone items are
> being resolved [2] I would like to see some progress. Who will do this?
> Dave, do you update pambase? Do we add a todo-list containing all packages
> with pam configuration files so maintainers can decide on their own whether
> or not this is feasible for the package?
> 
> [1] https://bugs.archlinux.org/task/54915
> [2] https://github.com/systemd/systemd/milestone/12

Pushed systemd 235.0-1 and pambase 20171006-1 to [testing]...
Let's wait for people to complain. :-p
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp5ydRP5nwEh.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] systemd, kernel keyring and pam_keyinit

[Christian Hesse]

Christian Hesse <l...@eworm.de> on Mon, 2017/09/18 14:29:
> Hello everybody,
> 
> systemd v233 introduced code that makes use of the kernel keyring,
> initializing a private keyring for every service and adding a protected key
> named "invocation_id". This caused some trouble and we reverted it since
> then.
> 
> Things will change with systemd v235, which adds a new option "KeyringMode="
> for units. The values are "inherit", "private" and "shared". The commit [0]
> message and changes give the details. Now cryptsetup units are generated
> with "KeyringMode=shared", which unbreaks this use case.
> Other services that use the kernel keyring and want to share secrets with
> other services have to add this as well.
> 
> However login sessions where user context is changed can not be handled by
> systemd. Looks like we have to update our PAM configurations and add a line
> for every service where session is expected to use the kernel keyring:
> 
> session optional pam_keyinit.so force revoke
> 
> This is required for eCryptfs to function properly.
> Any comments on this? Any concerns?
> 
> I would like to keep the upstream keyring behavior with release version 235.
> Would be nice to have this sorted before.
> 
> [0]
> https://github.com/systemd/systemd/commit/b1edf4456eabc5951d76b96bc7df2db3feebe669

So we have a flyspray ticket requesting the same [1] and a report from Mantas
who is already using a setup with pam_keyinit.

As systemd upstream started preparing a release and milestone items are being
resolved [2] I would like to see some progress. Who will do this? Dave, do you
update pambase? Do we add a todo-list containing all packages with pam
configuration files so maintainers can decide on their own whether or not
this is feasible for the package?

[1] https://bugs.archlinux.org/task/54915
[2] https://github.com/systemd/systemd/milestone/12
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpdDcPwlD2O5.pgp
Description: OpenPGP digital signature

[arch-dev-public] removed mariadb 10.1.27 from [testing]

[Christian Hesse]

Hello everybody,

after the release of 10.1.27 upstream was made aware of a regression, so
the release has been pulled from the downloads system. The fix will be
in 10.1.28.
I removed mariadb 10.1.27 packages from [testing].
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpf04B_Kx6a0.pgp
Description: OpenPGP digital signature

[arch-dev-public] systemd, kernel keyring and pam_keyinit

[Christian Hesse]

Hello everybody,

systemd v233 introduced code that makes use of the kernel keyring,
initializing a private keyring for every service and adding a protected key
named "invocation_id". This caused some trouble and we reverted it since then.

Things will change with systemd v235, which adds a new option "KeyringMode="
for units. The values are "inherit", "private" and "shared". The commit [0]
message and changes give the details. Now cryptsetup units are generated with
"KeyringMode=shared", which unbreaks this use case.
Other services that use the kernel keyring and want to share secrets with
other services have to add this as well.

However login sessions where user context is changed can not be handled by
systemd. Looks like we have to update our PAM configurations and add a line
for every service where session is expected to use the kernel keyring:

session optional pam_keyinit.so force revoke

This is required for eCryptfs to function properly.
Any comments on this? Any concerns?

I would like to keep the upstream keyring behavior with release version 235.
Would be nice to have this sorted before.

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


pgp0PNixW1ENj.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

andy...@archlinux.org on Wed, 2017/09/13 07:35:
> 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.

We could merge systemd-sysvcompat (why does it exist?) into systemd, but I
think we need a split libsystemd to prevent a number of circular dependencies.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpb0OtoKXubG.pgp
Description: OpenPGP digital signature

[arch-dev-public] vacation and travelling

[Christian Hesse]

Hello everybody,

I am on vacation for three weeks starting today - expect me to be absent from
IRC these days. I will try to keep packaging and fixing bugs, but feel free
to jump in for urgent things.

We are travelling for the first week. My notebook will be with me but I have
no idea what my internet connectivity will looks like. Do not panic if I am
even less responsive.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpDGe3VQjFWr.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

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

Just a little heads-up... systemd 233.75-1 landed in [testing]. So give it a
try! ;)

BTW, we had just one backported commit to be removed, so 74 new commits
landed in this package compared to 233-7. Let's hope this gives some benefit.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpy36k2JK5bB.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Dave Reisner  on Sat, 2017/07/01 13:22:
> Hey all,
> 
> This should be pretty much a no-brainer, but wanted to be sure I wasn't
> missing anything. Systemd upstream publishes a "systemd-stable" repo [1]
> which branches at each tag and cherry-picks backports. I'd like to
> switch our systemd package to this repo to avoid some of the duplication
> of work that Jan, Christian and myself have done in the past. The repo
> sees a bunch more activity than what our own backporting strategy has
> been, and I see that as a positive.
> 
> One potentially bikeshed-worthy question is versioning. Do we count
> commits and modify the pkgver every time we build from the repo, e.g.
> 233.23-1 (meaning pkgrel=1 of a v233 build containing 23 backports), or
> do we simply keep the base pkgver true to upstream and increment pkgrel
> every time we release, e.g. 233-5 (meaning pkgrel=5 of some build of the
> v233 stable branch).
>
> [1] https://github.com/systemd/systemd-stable

I like the versioning to indicate what the package contains... So voting for
the inclusion of commit count. The only downside will be that people will
flag the package out-of-date for every new commit in the stable branch. :-p
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp96SZMMiRNL.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] MariaDB 10.2.x

[Christian Hesse]

Christian Hesse <l...@eworm.de> on Tue, 2017/05/23 12:59:
> MariaDB 10.2.6 has just been released, being the latest stable release as of
> now. As we have API/ABI changes we need a rebuild of depending packages.

We had a lot of issue, some were resolved, some were not.

For now we decided to stick with MariaDB 10.1.x and hope for upstream to get
their issues fix.

The packages yate and freeradius were updated in staging, I already rebuilt
them and pushed to [community-testing]. If I missed anything... Feel free to
push your updates as usual.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp2vxeQpIF2f.pgp
Description: OpenPGP digital signature

[arch-dev-public] MariaDB 10.2.x

[Christian Hesse]

Hello everybody,

MariaDB 10.2.6 has just been released, being the latest stable release as of
now. As we have API/ABI changes we need a rebuild of depending packages.

The main change is the library rename from `libmysqlclient.so` to
`libmariadb.so`. I would like to rename our package from `libmariadbclient`
to just `libmariadb`. Any objections?
Additionally I will remove the provide for `libmysqlclient`, which is a
leftover from when we switched away from Oracle MySQL back in 2013.

Some programs and plugins move from `mariadb` package to `mariadb-clients`
package, but most users should not notice.

Looks like we have to wait for the boost rebuild to finish. After that... Do
we want a ToDo-List or can we use an automated rebuild tool? Foutrelis?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpmNmHv98d9k.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] FroSCon developer room

[Christian Hesse]

Jelle van der Waa  on Sat, 2017/05/20 21:03:
> Hi all,
> 
> I'm going to FroSCon and was there a few years ago when we had an Arch
> Linux room. I'm wondering if more archers are going and if we want to
> get a room again this year, the submission deadline is the 23rd. [1] [2]
> 
> 
> [1] https://www.froscon.de/1/home/
> [2] https://www.froscon.de/1/cfp/cfprojects/

Hey everybody,

looks like time has come to visit FroSCon again. I'm in if we have a room!
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpOqTXSQu9Aq.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] More packages for adoption

[Christian Hesse]

Pierre Schmitz  on Tue, 2017/04/18 09:33:
> * fcgi
> * rsync

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


pgphWWWXJlRIr.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] OpenSSL 1.1.0

[Christian Hesse]

Christian Hesse <l...@eworm.de> on Thu, 2017/02/23 22:29:
> I have a working version of openvpn, but it requires heavy patching. I will
> wait for version 2.4.1 which has a lot of preparation (and with some luck is
> ported completly). Will push an openssl rebuild then.
> If anybody is interested... Raise your hands and let me know, I can provide
> packages for testing.

I am not sure about the amount of spare time I will have in about two weeks.
So I decided to push the patches now...
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp9V_TCetAuQ.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] OpenSSL 1.1.0

[Christian Hesse]

Baptiste Jonglez  on Thu, 2017/02/23 23:36:
> > Mupdf is a burden to maintain due to build system, bundled libraries and
> > static linking. Looks like upstream is not yet interested in openssl
> > 1.1.0... As I do not use it currently this will move to [community] if no
> > one steps up.   
> 
> Can't you just drop the dependency on openssl?  What is it used for?
> As far as I can tell, Debian does not build mupdf against openssl:

Just did that and pushed to [community-testing].

With mupdf linked against openssl you have support for PKCS#7 which is used
for digital signatures in PDF documents.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp8G6w55ZFS2.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] OpenSSL 1.1.0

[Christian Hesse]

Christian Hesse <l...@eworm.de> on Fri, 2017/02/24 13:37:
> Antonio Rojas <aro...@archlinux.org> on Thu, 2017/02/23 21:42:
> > El Thu, 23 Feb 2017 22:29:17 +0100, Christian Hesse escribió:
> >   
> > > Mariadb is still unsolved. There is a ticket in upstream jira [0] but it
> > > does not carry anything useful. There's a reference for a review, but I
> > > could not find the patch in mail archive. Will try to contact the
> > > developers and express our interest...
> > 
> > In the meantime, is temporarily switching to internal yassl (as Debian 
> > does) an option? This is blocking all Qt rebuilds (which will also be a 
> > pain themselves), so it would be nice to have a build in staging
> > soonish.  
> 
> Ah, did not know this is a huge blocker. I will try.

I pushed mariadb 10.1.21-2 to [testing]. Please give it a try...
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpLInlQisKqG.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] OpenSSL 1.1.0

[Christian Hesse]

Antonio Rojas <aro...@archlinux.org> on Thu, 2017/02/23 21:42:
> El Thu, 23 Feb 2017 22:29:17 +0100, Christian Hesse escribió:
> 
> > Mariadb is still unsolved. There is a ticket in upstream jira [0] but it
> > does not carry anything useful. There's a reference for a review, but I
> > could not find the patch in mail archive. Will try to contact the
> > developers and express our interest...  
> 
> In the meantime, is temporarily switching to internal yassl (as Debian 
> does) an option? This is blocking all Qt rebuilds (which will also be a 
> pain themselves), so it would be nice to have a build in staging soonish.

Ah, did not know this is a huge blocker. I will try.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgppwMfWz_kEx.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] OpenSSL 1.1.0

[Christian Hesse]

Pierre Schmitz  on Sat, 2017/02/11 09:32:
> 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.

Are you interested in details?

I have a working version of openvpn, but it requires heavy patching. I will
wait for version 2.4.1 which has a lot of preparation (and with some luck is
ported completly). Will push an openssl rebuild then.
If anybody is interested... Raise your hands and let me know, I can provide
packages for testing.

Mariadb is still unsolved. There is a ticket in upstream jira [0] but it does
not carry anything useful. There's a reference for a review, but I could not
find the patch in mail archive. Will try to contact the developers and
express our interest...

Mupdf is a burden to maintain due to build system, bundled libraries and
static linking. Looks like upstream is not yet interested in openssl 1.1.0...
As I do not use it currently this will move to [community] if no one
steps up. 

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


pgpwfhRpfg3L2.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Away on business next week

[Christian Hesse]

Dave Reisner  on Thu, 2017/02/23 10:53:
> - core/curl: new release 7.53.0, but expect 7.53.1 in the next few days.
>   keep in mind there's an openssl rebuild in staging that complicates
>   this.

I took responsibility for this one.

> - core/systemd: expecting v233 to be released some time early next week.
>   I sort of don't want to be a part of this impending shitfest, even
>   after I return. As of right now, it's been 111 days and 1109 commits
>   since the last release. Expect bugs. I wouldn't package this right
>   away.

Yeah, let's see what breaks this time... :-P
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpsIPKmPBoNl.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Giancarlo Razzolini <grazzol...@archlinux.org> on Fri, 2016/12/02 13:52:
> Em dezembro 2, 2016 10:50 Christian Hesse escreveu:
> > Wondering if this is possible without hard coded interface names... You
> > would have to use %i in openvpn-unprivileged@.service:
> > 
> > ExecStartPre=-/usr/bin/openvpn --rmtun --dev %i
> > ExecStartPre=/usr/bin/openvpn --mktun %i ...
> > ExecStart=/usr/bin/openvpn --config %i.conf --dev %i ...
> > 
> > However... You should base your work on the new upstream systemd units.
> 
> Well, that would require calling the file with the same name as the
> interface being used, but it would definetely work. Since we now have a run
> dir, all that would be needed is this "unprivileged" systemd unit. I think
> the need for an unprivileged iproute could be easily addressed by the user
> itself, manually.

Well, you could provide a sudoers file, a wrapper with 'sudo /usr/bin/ip $@'
and add '--iproute /path/to/wrapper' in your unit file.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpgvMLlaKovq.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Giancarlo Razzolini <grazzol...@archlinux.org> on Fri, 2016/12/02 12:33:
> Em dezembro 2, 2016 10:25 Christian Hesse escreveu:
> > Giancarlo Razzolini <grazzol...@archlinux.org> on Tue, 2016/11/29 17:00:
> > 
> > Sure I do. :-p
> > 
> > But as the cause is known now... Why not just set a password with a
> > maximum length of 128 chars?  
> 
> Been doing that for a while now. In fact, Maxime, from PIA, told me they'd
> change their maximum password size to 128. I've been following the
> discussion on the OpenVPN list and it seems they didn't yet reached a
> conclusion. So, 2.4.0, will probably not have this fix yet (if they will do
> any fix).

The task [0] is still open und unfixed. I doubt a patch for this will make it
into final 2.4...

> And I'll make time to improve our wiki regarding running OpenVPN entirely
> unprivileged.

Wondering if this is possible without hard coded interface names... You would
have to use %i in openvpn-unprivileged@.service:

ExecStartPre=-/usr/bin/openvpn --rmtun --dev %i
ExecStartPre=/usr/bin/openvpn --mktun %i ...
ExecStart=/usr/bin/openvpn --config %i.conf --dev %i ...

However... You should base your work on the new upstream systemd units.

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


pgpW80PJLCohj.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Giancarlo Razzolini  on Tue, 2016/11/29 17:00:
> Personally I'm okay with all of this and I'll accommodate my
> setup, no matter how openvpn gets packaged. I had to compile
> openvpn for at least two release cycles because of a bug on it[0].
> I think you'll probably remember that one.

Sure I do. :-p

But as the cause is known now... Why not just set a password with a maximum
length of 128 chars?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpJmYFjfWsxU.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Sébastien Luttringer <se...@seblu.net> on Fri, 2016/12/02 03:09:
> 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!

Great!

This already made its way into the official repository and will be available
in version 2.4.0 (and our package).

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


pgpRLNr4g7EyQ.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Giancarlo Razzolini <grazzol...@archlinux.org> on Tue, 2016/11/29 16:14:
> Em novembro 26, 2016 10:38 Christian Hesse escreveu:
> > Hello everybody,
> > 
> > a new OpenVPN stable release is being prepared, namely version 2.4.0.
> > Currently we have 2.4_beta2. I think about making changes to our package
> > that require user intervention.
> > 
> > We shipped a systemd unit file before OpenVPN upstream had one. Upstream
> > now has unit files, but two (for server and client) instead of just one.
> > I did backport some security features for our unit, but refused to
> > migrate to the upstream solution within the 2.3.x branch.
> > 
> > That could change with 2.4.0. Instead of openvpn@.service we would have
> > openvpn-server@.service and openvpn-client@.service. Additionally the
> > 'daemon' option is no longer allowed with the upstream units.
> > 
> > Any opinion about this change? Who can post news about this on the
> > website?
> > 
> > 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?  
> 
> Well,
> 
> I think it is good upstream is (finally) caring about the actual
> deployment of their software. I always found openvpn packaging
> odd on all the systems I used. On some, a user is created for
> running unprivileged. On others, everything is created and taken
> care of, including logging.
> 
> I do not oppose using whatever upstream is deploying, if it's
> rationale. I just think that we could create a system user for
> openvpn, even if most users will deploy it using root.

We need root privileges at initialization phase, no? Privileges are dropped
to nobody/nobody when initialization sequence completed.

If we can make things work with non-root system user... Let me know how to do
that. :D

> In that
> sense we would also (probably) need a /run/openvpn directory.

The new systemd units create this automatically. (Well,
actually /run/openvpn-client and /run/openvpn-server.)

> I managed to make openvpn work entirely unprivileged here and
> I plan on changing our wiki[0] on the matter (it's missing some
> info) and also the official documentation[1] do not account for
> systemd nor ip netns exec, which is a clear venue for privilege
> escalation. What do you guys think?

Just followed the link from our wiki [2]. Probably you can make this work,
but I am not convinced this can be packaged to work smoothly.
Dynamic device naming, up/route-up/... scripts, ... There is lot of stuff
that can and will break.

Still, if you have some clues on how to package this...

> [0]
> https://wiki.archlinux.org/index.php/OpenVPN#Drop_root_privileges_after_connecting
> [1]
> https://openvpn.net/index.php/open-source/documentation/howto.html#security

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


pgpmXCJdK0kU7.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

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


pgpYtcdDYI0Un.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

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


pgpBSFzFRg_xQ.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

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.

So probably we will go with upstream and slit the units, but apply an
additional patch to unbreak things.

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

That's true...
We will definitely have a post-upgrade message, actually I tend to add a news
post as well.

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

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


pgpnnbhOp1Ebs.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Bartłomiej Piotrowski <bpiotrow...@archlinux.org> on Sat, 2016/11/26 21:55:
> On 2016-11-26 13:38, Christian Hesse wrote:
> > Hello everybody,
> > 
> > a new OpenVPN stable release is being prepared, namely version 2.4.0.
> > Currently we have 2.4_beta2. I think about making changes to our package
> > that require user intervention.
> > 
> > [...]
> > 
> > Any opinion about this change? Who can post news about this on the
> > website?
> 
> I don't really use OpenVPN outside NetworkManager nowadays.

Will have to test that... But I do not think anything breaks there.

> Your
> proposed changes sound reasonable even without a news item (I guess
> post_upgrade message would be sufficient; let's raise our cups for
> correct usage of that).

Thought about that already... and implemented locally. I think that is the
way to go. ;)
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpKSIxRatm8d.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Christian Hesse <l...@eworm.de> on Sat, 2016/11/26 13:38:
> That could change with 2.4.0. Instead of openvpn@.service we would have
> openvpn-server@.service and openvpn-client@.service. Additionally the
> 'daemon' option is no longer allowed with the upstream units.

Oh, and another change... Configuration moves to sub
directories /etc/openvpn/server and /etc/openvpn/client.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp3z1jqKX24r.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Hello everybody,

a new OpenVPN stable release is being prepared, namely version 2.4.0.
Currently we have 2.4_beta2. I think about making changes to our package that
require user intervention.

We shipped a systemd unit file before OpenVPN upstream had one. Upstream now
has unit files, but two (for server and client) instead of just one. I did
backport some security features for our unit, but refused to migrate to the
upstream solution within the 2.3.x branch.

That could change with 2.4.0. Instead of openvpn@.service we would have
openvpn-server@.service and openvpn-client@.service. Additionally the
'daemon' option is no longer allowed with the upstream units.

Any opinion about this change? Who can post news about this on the website?

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


pgpTBi5cHSFAN.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] libpsl support for wget and curl (moving libpsl to [core])

[Christian Hesse]

Levente Polyak  on Mon, 2016/11/14 12:39:
> Hi,
> 
> I would like to move libpsl[0] to [core] and, if no objections arise,
> rebuild wget and curl against it. Doing so will protect against some
> problems related to insufficient checking of TLDs (f.e. [1]).

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


pgpXatBeV997m.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Christian Hesse <l...@eworm.de> on Thu, 2016/10/20 14:42:
> Florian Pritz via arch-dev-public <arch-dev-public@archlinux.org> on Thu,
> 2016/10/20 14:25:
> > f2fs-tools  
> 
> Looks like f2fs-tools has a hard dependency on libselinux now... So we have
> to move libselinux from AUR to [extra] if we want to keep f2fs support.

I've sent a patch upstream that allows to build without selinux support.
Let's wait for the result before rushing a decision.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpanBOE8nGsw.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Florian Pritz via arch-dev-public  on Thu,
2016/10/20 14:25:
> f2fs-tools

Looks like f2fs-tools has a hard dependency on libselinux now... So we have
to move libselinux from AUR to [extra] if we want to keep f2fs support.

Tobias, are you going to handle this? Do you want me to do this? Any reason
not to do this?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpO99Zf8ePQG.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Shutting down celestia (old pkgbuild)

[Christian Hesse]

Florian Pritz via arch-dev-public  on Mon,
2016/09/26 11:06:
> Hi,
> 
> According to Jan, everything has been transferred to the new server
> (soyuz). I'll be shutting down celestia next weekend.

Some of us had zsh set to be the default shell. Can we have that back?
Thanks!
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp4cwSLAUzdt.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] i686 and SSE2

[Christian Hesse]

Allan McRae <al...@archlinux.org> on Mon, 2016/09/19 19:34:
> On 19/09/16 19:05, Christian Hesse wrote:
> > Bartłomiej Piotrowski <bpiotrow...@archlinux.org> on Fri, 2016/09/16
> > 21:44:  
> >> Actually, why don't raise the bar higher? SSE2 has been introduced in
> >> 2001 – that's 15 years to upgrade one's hardware and given my sad
> >> experiences with computers, I find it hard to believe anyone has that
> >> old PC that happens to run Arch.  
> > 
> > I do. Running Arch Linux on a bunch of informational room displays...
> > These are based on Geode CPUs and I am pretty sure no SSE2 is available.
> > (Taking a look at /proc/cpuinfo these devices do not even feature SSE...
> > The CPU identifies itself as i586.)

This is buggy hardware... SSE is available ('gcc -O3 -msse -mno-sse2'
produces functional output), SSE2 is not ('gcc -O3 -msse2' breaks with
illegal instruction).

> > That said I will be able to handle that myself. ;)
> > Possibly I will have to do local rebuilds of webkitgtk2 to make surf run
> > on these devices from time to time.  
> 
> If we adopt SSE2 in any form, you will need to rebuild your entire
> system to use it.  It will be used in optimizations everywhere.

Well, that could cause some headache for me... :-p

In the end it depends on what code is optimized by gcc. Would SSE2 code be
used by that much packages?

We could just keep i686 as-is for maximum compatibility. Let's take a
realistic look at the things: Most users run i686, so why bother and optimize
i686 - just to save some CPU cycles for a minority?
(I would even wast CPU cycle rebuilding a bunch of packages... pacman tells
me the effected boxes have 399 packages installed.)

So better raise requirements for x86_64. All x86_64 (and most overall) users
will benefit. Older AMD CPUs (or really old Intel ones?) without SSE4 could
still run i686 then - so nobody is forced to run anything else than Arch
Linux. ;)
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpPTh5r8KrqC.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] i686 and SSE2

[Christian Hesse]

Bartłomiej Piotrowski  on Fri, 2016/09/16 21:44:
> Actually, why don't raise the bar higher? SSE2 has been introduced in
> 2001 – that's 15 years to upgrade one's hardware and given my sad
> experiences with computers, I find it hard to believe anyone has that
> old PC that happens to run Arch.

I do. Running Arch Linux on a bunch of informational room displays...
These are based on Geode CPUs and I am pretty sure no SSE2 is available.
(Taking a look at /proc/cpuinfo these devices do not even feature SSE... The
CPU identifies itself as i586.)

That said I will be able to handle that myself. ;)
Possibly I will have to do local rebuilds of webkitgtk2 to make surf run on
these devices from time to time.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpBvmHcZB2qu.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Florian Pritz via arch-dev-public  on Wed,
2016/08/17 21:40:
> On Wednesday, August 17, 2016 9:35:02 PM CEST Bartłomiej Piotrowski wrote:
> > If there is a good
> > reason not to upgrade a package, put that information somewhere, instead
> > of letting it decay.  
> 
> Since I'm running into this with opencascade myself: Where would that be? 
> Should it be posted to this list?

Unflag the package, then flag it yourself with a comment of the details. At
least devs can find the information there.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpnvNFmVrBL1.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Tester accounts (was: signoffs are dead)

[Christian Hesse]

Florian Pritz via arch-dev-public  on Thu,
2016/08/11 11:04:
> On Monday, July 25, 2016 2:32:29 PM CEST Florian Pritz via arch-dev-public 
> wrote:
> > I've already received 4 responses to my initial mail about this so I'll
> > start by creating accounts for those first and see if everything works
> > as expected.  
> 
> Just a quick update:
> 
> I haven't received any (negative or positive) feedback from developers so
> far. I've sent a mail to the testers to see if everything is fine from
> their point of view. If the feedback I get is positive I will start
> creating accounts for the other ~10 applications I've received.

I have not received full signoffs (including i686) for any of my updated
packages. However there were more than before... So this is the right way to
go.

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


pgpsCFAQHjW8Q.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] FFmpeg 3.1.1 rebuild

[Christian Hesse]

"Maxime Gauduin"  on Thu, 2016/07/07 09:44:
> FFmpeg 3.1.1 and mpv are now respectively in [testing] and
> [community-testing] and will be moved to [extra] and [community] in a
> week's time. All other staging packages have been db-removed.

Do we have any show stoppers that prevent the move?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp_eRlxUXWBS.pgp
Description: OpenPGP digital signature

[arch-dev-public] mariadb 10.1.15-1 pulled out from testing

[Christian Hesse]

Hello everybody,

latest release of mariadb had serve issues and has been withdrawn upstream. A
new version has yet to be released. I removed mariadb 10.1.15-1 from [testing]
for now.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpTTWrlaYDrD.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] FFmpeg 3.1.1 rebuild

[Christian Hesse]

"Maxime Gauduin" <aluc...@archlinux.org> on Tue, 2016/07/05 19:37:
> July 5 2016 9:26 PM, "Christian Hesse" <l...@eworm.de> wrote:
> > "Maxime Gauduin" <aluc...@archlinux.org> on Tue, 2016/07/05 17:55:
> >   
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >> 
> >> July 5 2016 7:41 PM, "Maxime Gauduin" <aluc...@archlinux.org> wrote:  
> >>> Hi all,
> >>> 
> >>> A new 3.1.1 FFmpeg point release just came out, fixing the ABI issues
> >>> present in 3.1. This means we have to start the FFmpeg rebuild over,
> >>> apologies for the inconvenience.
> >>> 
> >>> I edited the 3.1 rebuild and passed everything back to incomplete,
> >>> please dedicate your CPU time to the greater good once more.
> >>> 
> >>> Cheers,
> >>> - --
> >>> Maxime  
> >> 
> >> Hi again,
> >> 
> >> Antonio pointed out to me that we could just drop the rebuild entirely
> >> since 3.1.1 should be ABI compatible with 3.0, and db-remove any rebuilt
> >> package from staging/community-staging.
> >> 
> >> I'll move 3.1.1 to testing (currently in staging) shortly so that
> >> everybody can check whether there are any incompatibilities left, and
> >> will db-remove the already rebuilt packages at the same time.  
> > 
> > I have to rebuild mpv anyway as it complains about the version bump (even
> > if everything works).
> > 
> > Should I wait for ffmpeg in [community-testing] or push a rebuild to
> > [community-staging] now? Will you do the final move to [community]?
> > --
> > main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH"
> > "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];)
> > putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}  
> 
> Feel free to push it to [community-staging],

Done.

> I will db-move it to
> [community-testing] when I move ffmpeg to [testing], and will also take
> care of the final move about a week later.
>
> Thanks,

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


pgpNeZAngNUpS.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] FFmpeg 3.1.1 rebuild

[Christian Hesse]

"Maxime Gauduin"  on Tue, 2016/07/05 17:55:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> July 5 2016 7:41 PM, "Maxime Gauduin"  wrote:
> > Hi all,
> >
> > A new 3.1.1 FFmpeg point release just came out, fixing the ABI issues
> > present in 3.1. This means we have to start the FFmpeg rebuild over,
> > apologies for the inconvenience.
> >
> > I edited the 3.1 rebuild and passed everything back to incomplete, please
> > dedicate your CPU time to the greater good once more.
> >
> > Cheers,
> > - --
> > Maxime  
> 
> Hi again,
> 
> Antonio pointed out to me that we could just drop the rebuild entirely
> since 3.1.1 should be ABI compatible with 3.0, and db-remove any rebuilt
> package from staging/community-staging.
> 
> I'll move 3.1.1 to testing (currently in staging) shortly so that everybody
> can check whether there are any incompatibilities left, and will db-remove
> the already rebuilt packages at the same time.

I have to rebuild mpv anyway as it complains about the version bump (even if
everything works).

Should I wait for ffmpeg in [community-testing] or push a rebuild to
[community-staging] now? Will you do the final move to [community]?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgp6u7_NTsNwd.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Gaetan Bisson  on Tue, 2016/06/28 08:09:
> For a while now packages in [testing] have gotten little to no signoffs
> and I've been moving mine to [core] after a week without feedback. I
> suspect many of you have been doing this too.

Yes, probably everybody does. ;)

I do not run a system with [testing] enabled by default. I need my main
system in production every day - stable and reliable.
Packages that I really do want and/or need end up in my personal repository
for testing, though. I do give spare signoffs, but that packages received
real testing then.

Possibly we should modify the process a bit: Expect a package to be fine
when it received enough signoffs - as is. Additionally add a NACK feature that
expresses something is (possibly) borked. If the package did not receive a
NACK within 48 or 72 hours it is expected to be fine as well.
Our bug wrangler Doug could have an eye on bugs that look critical and set
NACKs for the packages.

Increasing the number of people with signoff permission may help as well. How
about a new user group for signoffs?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpQFuAU3eeUm.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] chroot building broken

[Christian Hesse]

Tobias Powalowski via arch-dev-public  on Mon,
2016/05/23 15:12:
> Hi guys,
> 
> I cannot build packages anymore:
> 
> testing-x86_64-build
> 
> Failed to read machine ID from
> /var/lib/archbuild/testing-i686/root/etc/machine-id: No such file or
> directory
> 
> I guess this is systemd related.

Yes, it is. For now simply touch the file in your chroots to make things happy
again.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpfnHnM8EkjC.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Hooks!

[Christian Hesse]

Sébastien Luttringer <se...@seblu.net> on Thu, 2016/05/19 01:35:
> On jeu., 2016-04-28 at 23:14 +0200, Christian Hesse wrote:
> > Allan McRae <al...@archlinux.org> 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/

Just built and installed the packages. Your hooks' triggers have
a target 'usr/lib/kernel/vmlinuz-*', which does not exist on my system. What
changes are required to linux packages? Do you have linux packages that work
with your hooks?

And you should consider adding some more targets. For example updating
packages 'systemd' or 'lvm2' should trigger an initramfs rebuild as well.
That is why I added a target 'usr/lib/initcpio/*'.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgppXziBaPPhK.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

Sébastien Luttringer <se...@seblu.net> on Thu, 2016/05/19 01:20:
> On mer., 2016-05-18 at 13:55 +0200, Christian Hesse wrote:
> > From: Christian Hesse <m...@eworm.de>
> > 
> >    # 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.

+1 from me. I was about to suggest the same.

Actually we have zz-etckeeper-post-install.hook for package etckeeper to make
it run last and catch all changes in /etc... A numeric prefix would be very
useful.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgppiUaTVWo4d.pgp
Description: OpenPGP digital signature

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

[Christian Hesse]

From: Christian Hesse <m...@eworm.de>

Signed-off-by: Christian Hesse <m...@eworm.de>
---
 PKGBUILD |  5 +
 linux-initramfs.hook | 11 +++
 linux.install|  4 
 3 files changed, 16 insertions(+), 4 deletions(-)
 create mode 100644 linux-initramfs.hook

diff --git a/PKGBUILD b/PKGBUILD
index 1a40499..1ba2e60 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -20,6 +20,7 @@ 
source=("https://www.kernel.org/pub/linux/kernel/v4.x/${_srcname}.tar.xz;
 'config' 'config.x86_64'
 # standard config files for mkinitcpio ramdisk
 'linux.preset'
+'linux-initramfs.hook'
 'change-default-console-loglevel.patch')
 
 sha256sums=('a93771cd5a8ad27798f22e9240538dfea48d3a2bf2a6a6ab415de3f02d25d866'
@@ -27,6 +28,7 @@ 
sha256sums=('a93771cd5a8ad27798f22e9240538dfea48d3a2bf2a6a6ab415de3f02d25d866'
 'b32a4fbd92cf561bca86bb65319a16be853fb8ea7bdd5f12974bd0d054d4c1f9'
 'e91660a413baa66fb3269f03ceb85bda1df493b2fec404e9bb0269ad9a2d67a8'
 'f0d90e756f14533ee67afda280500511a62465b4f76adcc5effa95a40045179c'
+'2d4424928ae3c5f63ee618b4685580f4bd24faf1778553dbd961f85a88ea0910'
 '1256b241cd477b265a3c2d64bdc19ffe3c9bbcee82ea3994c590c2c76e767d99')
 validpgpkeys=(
   'ABAF11C65A2970B130ABE3C479BE3E4300411886' # Linus Torvalds
@@ -144,6 +146,9 @@ _package() {
 
   # 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"
 }
 
 _package-headers() {
diff --git a/linux-initramfs.hook b/linux-initramfs.hook
new file mode 100644
index 000..a32248e
--- /dev/null
+++ b/linux-initramfs.hook
@@ -0,0 +1,11 @@
+[Trigger]
+Type = File
+Operation = Install
+Operation = Upgrade
+Target = boot/vmlinuz-linux
+Target = usr/lib/initcpio/*
+
+[Action]
+Description = Updating Arch Linux initramfs image
+When = PostTransaction
+Exec = /usr/bin/mkinitcpio -p linux
diff --git a/linux.install b/linux.install
index dd2fa5c..15dc8b6 100644
--- a/linux.install
+++ b/linux.install
@@ -8,8 +8,6 @@ post_install () {
   # updating module dependencies
   echo ">>> Updating module dependencies. Please wait ..."
   depmod ${KERNEL_VERSION}
-  echo ">>> Generating initial ramdisk, using mkinitcpio. Please wait..."
-  mkinitcpio -p linux${KERNEL_NAME}
 }
 
 post_upgrade() {
@@ -20,8 +18,6 @@ post_upgrade() {
   # updating module dependencies
   echo ">>> Updating module dependencies. Please wait ..."
   depmod ${KERNEL_VERSION}
-  echo ">>> Generating initial ramdisk, using mkinitcpio. Please wait..."
-  mkinitcpio -p linux${KERNEL_NAME}
 
   if [ $(vercmp $2 3.13) -lt 0 ]; then
 echo ">>> WARNING: AT keyboard support is no longer built into the kernel."
-- 
2.8.2

Re: [arch-dev-public] Hooks!

[Christian Hesse]

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

Ah, did not notice, yet.

> in any case, rules are reloaded automagically (thanks to inotify).

Are you sure? Even attached strace to systemd-udevd and could not see any
activity when changing files in /usr/lib/udev/rules.d/.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpCCo4thWSx0.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Hooks!

[Christian Hesse]

Massimiliano Torromeo  on Fri, 2016/04/29
12:47:
> I was also wondering about a pacman hook ro run "systemctl daemon-reload"
> after systemd units installations/upgrades. This is something that was not
> done even in .install files but I don't know if there was a reason why.
> 
> Others distros do this automatically, even the ones that do not have the
> bad habit of restarting the services for you without asking. Eg: I never
> had to do daemon-reload on CentOS 7.
> 
> As far as I understand it shouldn't have any unintended side effects (and I
> certainly never experienced one). Thoughts?

Ah, and another one to reload udev rules:

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = File
Target = usr/lib/udev/rules.d/*

[Action]
Description = Reload udev rule files
When = PostTransaction
Exec = /usr/bin/udevadm control --reload-rules
Depends = systemd
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpEr5fGb0FYd.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Hooks!

[Christian Hesse]

Florian Pritz  on Fri, 2016/04/29 10:49:
> On 29.04.2016 10:20, Ike Devolder wrote:
> >> How about a hook that rebuilds kernel initramfs images? Something like:
> >>   
> > It only benefits one package, so seems pointless to move it in hooks. If
> > you have custom kernels installed you must run mkinitcpio anyway for all
> > of them.  
> 
> The current way of running mkinitcpio in the install scriptlet is
> broken. Some package that may be included in the initramfs might get
> updated after the script runs so their files in the initramfs may be the
> old versions. This has happened before and the only way to properly fix
> it is by using a hook to run the command at the very end of the update
> process. This is not pointless.

Yup, that's the point. Every kernel package shout ships its own hook.

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


pgpN4Td14nbIe.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Hooks!

[Christian Hesse]

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:

[Trigger]
Type = File
Operation = Install
Operation = Upgrade
Target = boot/vmlinuz-linux
Target = usr/lib/initcpio/*

[Action]
Description = Updating Arch Linux initramfs image
When = PostTransaction
Exec = /usr/bin/mkinitcpio -p linux
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpbAXWqrQ4CJ.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Hooks rebuild #1

[Christian Hesse]

Allan McRae  on Wed, 2016/04/27 22:36:
> We are ready to start the first hooks rebuild.  This rebuild covers
> packages using these hooks:
> 
> update-desktop-database
> update-mime-database
> install-info
> glib-compile-schemes
> gtk-update-icon-cacne/xdg-icon-resource

This one fails. You need to
install /usr/share/libalpm/scripts/gtk-update-icon-cache
with execute permission.

> gconf
> gio-querymodules
> 
> Each rebuild requires the install file updated to remove these commands.
> 
> No need to use staging/testing for this rebuild (except [core] packages).
> 
> GO!



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


pgpXHquvCFBcj.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Automated rebuild for ncurses 6.0 in progress

[Christian Hesse]

Evangelos Foutras  on Sun, 2015/09/06 20:02:
> You can follow the progress at: https://rebuilds.foutrelis.com/
> 
> If anyone wants to tackle a build failure, you can commit the fix in
> /trunk (without bumping pkgrel) and then click on the failing package
> and select "Retry build task".
> 
> Note: This rebuild is not listed on https://www.archlinux.org/todo/ in
> order to avoid any confusion.

Looks like this is stuck at the moment. An kind of dependency loop between
python and gdb?
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}


pgpE531gVo_ja.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] News item for openssh-7.0p1-1

[Christian Hesse]

Gaetan Bisson bis...@archlinux.org on Thu, 2015/08/13 00:03:
 Hi,
 
 I'd like to suggest the following piece of news to be posted when
 openssh-7.0p1-1 lands in [core]:
 
 
 The new openssh-7.0p1 release deprecates certain types of SSH keys that
 are now considered vulnerable. For details, see the
 [upstream
 announcement](http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html).
 
 Before updating and restarting sshd on remote hosts, if you rely on SSH
 keys for authentication, please make sure that you have a recent key
 pair set up, or alternative means of logging in (such as using password
 authentication).

This does not only apply for public key authentication but for host keys as
well. Do we want to add a note about that?

Old algorithms can be used when explicitly enabling them, though... ;)

The systemd unit sshdgenkeys.service still generates a dsa host key. Do we
want to change that?
-- 
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c  ./sig*/b/42*2-3)*42);}


pgpvErTMUl8p3.pgp
Description: OpenPGP digital signature