Re: [arch-dev-public] Add active Python versions to the repos

[Bartłomiej Piotrowski via arch-dev-public]

On 21/11/2020 18.48, Filipe Laíns via arch-dev-public wrote:
> I understand that. I am not asking to put all releases of Python on the
> repos, only the active ones, which people are using.

I presume you can back it up with numbers how widely 3.7 and 3.6 are
used by Arch users. All I can see is that both have less than 30 votes
in AUR. Even if I take into account how irrelevant AUR votes are, I
assume the problem is exaggerated.

> Why are we packaging software that is used by far less people but we
> can't package these Python interpreters which are being actively missed
> by people?

Our approach of "YOLO push random new packages to repos" is something I
never agreed with, for the record. Unfortunately it's a kingdom with
almost no rules.

BP

[arch-dev-public] Packages up for adoption

[Bartłomiej Piotrowski via arch-dev-public]

Hi,

Due to lack of free time, I've orphaned some packages I don't want to 
think about:


bash
bash-completion
chrome-gnome-shell
expat
gdbm
libcap
libffi
libunistring
libusb
networkmanager-fortisslvpn
ncurses
openfortivpn
readline
texinfo
wpa_supplicant

I've also disowned some packages I've been co-maintaining with other 
packagers but that's not so interesting.


Bart

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

[Bartłomiej Piotrowski via arch-dev-public]

On 20/04/2020 00.32, Morten Linderud via arch-dev-public wrote:
> I have also removed `-mod=vendor` from the default listing in `prepare()` as
> Anatol wasn't fond of the idea. I'm still unsure if we really want this as we
> would be willynilly downloading sources in `build()` and `check()` during
> packaging. Opinions welcome.

Ideally we don't, but practically it's irrelevant as long as devtools
run builds with network access.

Bart

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

[Bartłomiej Piotrowski via arch-dev-public]

On 13/01/2020 18.28, Christian Rebischke via arch-dev-public wrote:
> [testing] has been used and I wanted to test my packages, but the push
> from [testing] to [community] happened before my scheduled date for
> this.

Have you raised this on the TU or staff channels before the move
happened? Otherwise I don't find it surprising no one guessed your
personal testing plan. Documented procedures are surely nice, proper
communication is even better.

BP

Re: [arch-dev-public] Restricting ability to post news items

[Bartłomiej Piotrowski via arch-dev-public]

On 05/01/2020 23.04, Morten Linderud via arch-dev-public wrote:
> On Mon, Jan 06, 2020 at 07:53:21AM +1000, Allan McRae via arch-dev-public 
> wrote:
>> Following the roll out of the base metapackage, and its poorly written
>> news post, we agreed that all new posts should have a draft posted to
>> arch-dev-public.
> 
> Wait, where was this agreed? I heard something about all drafts should be 
> headed
> for arch-dev, but this hasn't been announced nor discussed anywhere.
> 
> Are the TUs missing from the loop here?
> 

If you look at the non-trivial news items, you can easily correlate them
with drafts posted to arch-dev-public.

The main page isn't a personal website. New posts should – and have been
– reviewed, and that's what this mailing list is for.

Bart

Re: [arch-dev-public] Information about the base meta-package

[Bartłomiej Piotrowski via arch-dev-public]

On 14/10/2019 23.11, Levente Polyak via arch-dev-public wrote:
> Q: Why has this been implemented so suddenly?
> A: That's a good question, while we have discussed this topic multiple
>times in the past and also issued a concrete proposal to arch-dev-
>public (plus its follow-up summary) no further steps were taken to
>get something testable. However, during arch-conf in Berlin, the
>general enthusiasm and acceleration of the group was so strong, that
>we have warp-10 driven this task. We acknowledge that this could have
>been handled more carefully, but in the spirit of arch-conf please
>excuse us and bear with us. For instance, we could have noticed
>during a test phase the consequences of not having systemd-
>sysvcompat. For the time being, we have added it to the base package
>as the implications were not explicitly desired and discussed
>beforehand, however that topic will be covered in a follow-up.


This e-mail is probably not needed at all now when the change has
already happened. The rationale really should have landed on the main
website when the new base package has been released to [testing].

I don't think gathering number of contributors physically can justify
total lack of communication with people who did not attend. I understand
the good intention and while I agree the change was already extensively
discussed, all it needed was just a summary what we're going with in the
near future instead of YOLO pushing the metapackage and news post during
conference.

What I would like to see in this Q is if that's how decision process
is going to look like from now on or you see what went wrong and won't
forget it in 2 or 3 months.

Bart

Re: [arch-dev-public] Semi-away till 2019

[Bartłomiej Piotrowski via arch-dev-public]

Damn calendars, how do they even work!?

Yes, I meant 2020.

On 03/09/2019 18.41, Alad Wenter via arch-dev-public wrote:
> ... 2020?
> 
> Time flies.
> 
> Alad
> 
> On 9/3/19 6:36 PM, Bartłomiej Piotrowski via arch-dev-public wrote:
>> Hi all,
>>
>> As I have free time shortage lately, I think it's fair to officially say
>> I will be in semi-away mode till 2019. I will try my best to keep up
>> with uncomplicated pkgver bumps for packages I maintain on my own and
>> make sure all keys are properly signed, but that's all I can promise.
>>
>> It also means I'm unable to give toolchain attention it deserves. Please
>> poke me somewhere if you happen to be interested in co-maintaining it.
>>
>> My responses on IRC or via e-mail may be also delayed so take that into
>> account before kicking me out.
>>
>> Bartłomiej

[arch-dev-public] Semi-away till 2019

[Bartłomiej Piotrowski via arch-dev-public]

Hi all,

As I have free time shortage lately, I think it's fair to officially say
I will be in semi-away mode till 2019. I will try my best to keep up
with uncomplicated pkgver bumps for packages I maintain on my own and
make sure all keys are properly signed, but that's all I can promise.

It also means I'm unable to give toolchain attention it deserves. Please
poke me somewhere if you happen to be interested in co-maintaining it.

My responses on IRC or via e-mail may be also delayed so take that into
account before kicking me out.

Bartłomiej

Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine

[Bartłomiej Piotrowski via arch-dev-public]

I'd go with updating all packages to ship the converted files.
Cluttering /usr with untracked files doesn't sound good.

BP

Re: [arch-dev-public] New ideas for notifying users about (minor) changes

[Bartłomiej Piotrowski via arch-dev-public]

On 30/07/2019 09.33, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 30/07/2019 02.44, Christian Rebischke via arch-dev-public wrote:
>> One problem I see with the News section is that it's Dev only. I
>> wouldn't even know who I need to ask (and I am TU for several years
>> now).
> 
> The list of developers is public. If after few years you don't know a
> single person to ask if they could proofread and publish something for
> you, or even can't send a draft yourself to arch-dev-public, introducing
> another tool won't help at all.
> 
> BP
> 

I have also changed TU permissions to include "add news" and "change
news" actions.

Re: [arch-dev-public] New ideas for notifying users about (minor) changes

[Bartłomiej Piotrowski via arch-dev-public]

On 30/07/2019 02.44, Christian Rebischke via arch-dev-public wrote:
> One problem I see with the News section is that it's Dev only. I
> wouldn't even know who I need to ask (and I am TU for several years
> now).

The list of developers is public. If after few years you don't know a
single person to ask if they could proofread and publish something for
you, or even can't send a draft yourself to arch-dev-public, introducing
another tool won't help at all.

BP

Re: [arch-dev-public] GCC 9 removed from [testing]

[Bartłomiej Piotrowski via arch-dev-public]

On 02/06/2019 09.37, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 26/05/2019 22.39, Eli Schwartz via arch-dev-public wrote:
>> Question: are you going to set up an archbuild alias on soyuz/dragon for
>> this, the way you did for gcc8? (Which reminds me, those archbuild
>> aliases still exist and could be deleted).
> 
> I can create it, sure.
> 
>> Also please bump the pkgrel for these packages as they were currently
>> just cp'ed from testing. dbscripts knows how to auto-reject uploaded
>> packages built with your repo, as long as the gcc/binutils/etc.
>> pkgver-pkgrel are new and thus do not appear in the archives.
> 
> I think packages built againt GCC9 with bumped pkgrel would be rejected
> anyway ("package does not appear in repositories" or something along
> this) but yeah, I don't plan to touch it for the time being.
> 

Ah, right, I forgot it also does some archive magic now. I guess I will
have to change it then… Likely today in the evening.

Re: [arch-dev-public] GCC 9 removed from [testing]

[Bartłomiej Piotrowski via arch-dev-public]

On 26/05/2019 22.39, Eli Schwartz via arch-dev-public wrote:
> Question: are you going to set up an archbuild alias on soyuz/dragon for
> this, the way you did for gcc8? (Which reminds me, those archbuild
> aliases still exist and could be deleted).

I can create it, sure.

> Also please bump the pkgrel for these packages as they were currently
> just cp'ed from testing. dbscripts knows how to auto-reject uploaded
> packages built with your repo, as long as the gcc/binutils/etc.
> pkgver-pkgrel are new and thus do not appear in the archives.

I think packages built againt GCC9 with bumped pkgrel would be rejected
anyway ("package does not appear in repositories" or something along
this) but yeah, I don't plan to touch it for the time being.

BP

Re: [arch-dev-public] GCC 9 removed from [testing]

[Bartłomiej Piotrowski via arch-dev-public]

On 26/05/2019 18.51, Bartłomiej Piotrowski via arch-dev-public wrote:
> Hi all,
> 
> I just deleted GCC 9 and related packages from [testing] due to the
> filesystem corruption bug when bcache is used[1]. You will have to -Syuu
> your systems.
> 
> People hungry for breakage can install it from [gcc9] repo I uploaded to
> pkgbuild.com:
> 
> [gcc9]
> Server = https://pkgbuild.com/~bpiotrowski/gcc9/
> 
> Bartłomiej
> 

[1] should be pointing to https://bugs.archlinux.org/task/62730

[arch-dev-public] GCC 9 removed from [testing]

[Bartłomiej Piotrowski via arch-dev-public]

Hi all,

I just deleted GCC 9 and related packages from [testing] due to the
filesystem corruption bug when bcache is used[1]. You will have to -Syuu
your systems.

People hungry for breakage can install it from [gcc9] repo I uploaded to
pkgbuild.com:

[gcc9]
Server = https://pkgbuild.com/~bpiotrowski/gcc9/

Bartłomiej

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

[Bartłomiej Piotrowski via arch-dev-public]

Adopted restic and pass-otp.

Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”

[Bartłomiej Piotrowski via arch-dev-public]

On 18/03/2019 09.18, Gaetan Bisson via arch-dev-public wrote:
> [2019-03-18 08:39:45 +0100] Bartłomiej Piotrowski via arch-dev-public:
>> I asked Bruno to start another round as previous thread is way too long
>> for people who missed the party to catch up.
> 
> So some of us have taken the time to discuss this issue just a month ago
> but because it's too much to read for you we must start all over again?

I am sorry for bringing forth an idea of recapping what we agree or not
agree upon after hearing that the thread could be too long for bystanders.

> We currently have a base group that you're not happy with. Levente and
> Bruno suggest to update its package list and/or maybe make it a meta-
> package. From your perspective that would be no better and no worse than
> the current situation, right? So I don't see why you are against this
> change but if you are please tell us what concretely you propose we do?
It will be later leveraged to vouch for implicit or transitive
dependencies. If you consider it independent topic then fine, I'm happy
to bring it up as "but that's unrelated" counterargument in the future.

Bartłomiej

Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”

[Bartłomiej Piotrowski via arch-dev-public]

On 17/03/2019 23.13, Gaetan Bisson via arch-dev-public wrote:
> [2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public:
>> This is a follow-up on the last month discussion about a “minimal base
>> system”.
> 
> Creating a new thread removed from the discussion we had a month ago
> just makes it so much harder for all of us to remember what everyone's
> arguments and counter-arguments were. Please do not do this. For my
> part, I thought we had reached consensus with Allan's message:

I asked Bruno to start another round as previous thread is way too long
for people who missed the party to catch up.

>   
> https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.html
> 
> Summary: You propose what you want your new group to be (metapackage,
>  list of dependencies, etc.) and we adopt this as the new base.
> 
> If that is not satisfactory to you, please reply to that specific
> message and say why. That would have been far more constructive than
> your present message which rehashes some of the discussion we've already
> had and adds new questions I have no idea where you're going with.

The previous discussion doesn't answer (or even if it does, I don't care
to re-read it at this point) if the idea behind the new metapackage is
to be implicit dependency of all packages or just optional thing like
base group always was.

Currently maintainers either put actual dependencies into depends=(),
including glibc if something dynamically links to libc.so or assume that
base is group expected to be present on every installation, which I
wholeheartedly disagree with, because I can just instead use Slackware
if I weren't caring about dependency system.

Bartłomiej

Re: [arch-dev-public] Proposal: minimal base system

[Bartłomiej Piotrowski via arch-dev-public]

On 18/03/2019 00.35, Gaetan Bisson via arch-dev-public wrote:
> [2019-03-18 00:25:09 +0100] Alad Wenter via arch-dev-public:
>> Assuming we implement this group or meta-package as something of policy, 
>> i.e. every repository package is assumed to depend on it. This would then 
>> make base similar to base-devel, except for depends() instead of 
>> makedepends(). 
>>
>> With base-devel, we've always encouraged people to remove the makedepends 
>> already in that group. Would we do the same for "base", i.e. remove 
>> dependencies that, beforehand, were explicit?
> 
> We've been doing this for as long as I can remember.
> 
> Only 156 packages have glibc in their depends array.
> 
> Cheers.
> 

We is very generic term. I'm not doing it. If your package links to
libc.so, put it into deps.

Bartłomiej

[arch-dev-public] Away until Feb 11

[Bartłomiej Piotrowski via arch-dev-public]

Hi all,

I'm trying to run away from winter so I'll be away starting Wednesday. I
will be partially available via IRC/e-mail but I don't plan to do any
packaging.

Bartłomiej

Re: [arch-dev-public] Proposal: minimal base system

[Bartłomiej Piotrowski via arch-dev-public]

On 22/01/2019 00.23, Allan McRae via arch-dev-public wrote:
> On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote:
>> Everything that won’t be part of base-system needs to be added as a
>> dependency to all requiring packages; alternatively don't omit any first
>> level runtime dependencies at all.
>>
>> This package should only depend on strictly required explicit packages
>> to get a working minimal Arch Linux system.
>>
>> The proposed end result is:
>> - base: convenient helper group for quickly getting a working system
>>   when installing, must include the new base-system package
>> - base-system: package defining the minimum dependencies for a working
>>   base runtime
> 
> I think the proposal is OK.  I'm not comfortable with our line about
> base group packages being required given how many of them I don't have
> installed.
> 
> However...  I don't like idea of the base group and base-system package
> existing together.  You definition of what base-system should be is much
> the same as what the base group was defined to be.  What package
> justifies itself in the base group, but would not be in base-system?  It
> seems we would have two very similar things where one would do.
> 
> Allan
> 

Maybe it's my reading comprehension failing me but I also don't really
understand the point of base-system, or rather why the base group can't
be simply stripped down to Levente's list.

Bartłomiej

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

[Bartłomiej Piotrowski via arch-dev-public]

On 16/12/2018 21.52, Dave Reisner wrote:
> Hi,
> 
> I'm finding myself lacking these days in both time and motivation to
> continue maintenance of both mkinitcpio and arch-install-scripts. Is
> anyone interested in taking these over? Both projects are fairly stable,
> but bugs do crop up as the rest of the OS evolves.
> 
> dR
> 

I can help with a-i-s; also with mkinitcpio for the time being, but I'd
prefer more hands with this one.

Bartłomiej

[arch-dev-public] Access to CNCF community cluster

[Bartłomiej Piotrowski via arch-dev-public]

Few months ago I asked on arch-dev whether we would like to ask for
access to Cloud Native Computing Foundation cluster, which we could use
to experiment with automated package builds (or anything else really).

Following no response I actually did so anyway[1] and I have been
invited to CNCF organization on packet.net, where we can spawn new
dedicated machines for fun and profit. Obvious caveat is that we are
guests and shouldn't abuse it; less obvious one is that packet.net does
not support Arch out-of-the-box but it can be achieved via PXE and
cloud-init (currently residing in AUR?).

I just realized I never communicated this properly so here it is. Let me
know if there's anything you would like to try.

Bartłomiej

[1] https://github.com/cncf/cluster/issues/85

Re: [arch-dev-public] TU application process

[Bartłomiej Piotrowski via arch-dev-public]

On 06/11/2018 12.13, Bruno Pagani via arch-dev-public wrote:
> Yeah, but [community] used to be something completely separated from
> [extra]. This is less and less the case (numerous packages were moved
> from [extra] to [community] so that TUs could maintain them for
> instance). The line between devs and TUs has become quite blurried, and
> in my opinion who we accept as TU is highly depending on the meaning we
> have for those repos and roles. I think devs should thus be concerned by
> the quality of what we have in [community].

Or we should start caring about repo hierarchy again, and keep [core]
and [extra] independent.

> Here again I would argue that they are devs that have [core] pushing
> rights, as well as devs that are Master Key holders. So even if you
> don’t want to write this black on white, this actually means a small
> group of people have the real control over the distro (technically,
> Master Key holders could revoke everyone else).

You can argue, but it's simply not true. Any developer has access to
[core]. Master key holders aren't considered any better than other
developers besides having more duties and no one has ever refused to
sign new TU; for every master key holder, there is someone else holding
revocation certificate. There is no hierarchy.

> Because you think Arch work, we (as some TUs/devs) think they are a
> number of issues.

Any sort of council would be a big turn-off for me not just now, but
also years ago when I joined TU ranks first.

> Thanks for your input, and this is the kind of opinions for which I said
> we should have this discussion here.

Personally I'm not interested in this either and I find it difficult to
find anything substantial in Christian's message indicating that
discussion should take place on arch-dev-public and not aur-general. I
know anthraxx is preparing actual outline but it's really bad way to
start off.

Bartłomiej

Re: [arch-dev-public] Meeting on dbscripts git repository layout and debug packages

[Bartłomiej Piotrowski via arch-dev-public]

On 15/09/2018 23.06, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 14/09/2018 18.46, Bartłomiej Piotrowski via arch-dev-public wrote:
>> Hi all,
>>
>> We would like to discuss design, issues and what is left to do about the
>> future dbscripts git migration and enabling debug packages by default.
>>
>> Please fill which time suits you best on Monday (17.09) or Tuesday
>> (18.09) here[1].
>>
>> The meeting will take place on #archlinux-devops on Freenode. It's a
>> public channel so anyone who's interested can join.
>>
>> I will send an update with final date till Sunday.
>>
>> Bartłomiej
>>
>> [1] https://doodle.com/poll/6hsbn8z3et8gazmi
>>
> 
> The meeting will take place on Monday, 7PM CEST. I will publish
> minutes/log after it's over.
> 
> Bartłomiej
>

It happened and according to some, it wasn't as terrible as I think!

Notes from the meeting can be found here[1]. I will migrate it to
DeveloperWiki later this week.

Bartłomiej

[1] https://etherpad.gnome.org/p/ArchDebugGitMeeting

Re: [arch-dev-public] Meeting on dbscripts git repository layout and debug packages

[Bartłomiej Piotrowski via arch-dev-public]

On 14/09/2018 18.46, Bartłomiej Piotrowski via arch-dev-public wrote:
> Hi all,
> 
> We would like to discuss design, issues and what is left to do about the
> future dbscripts git migration and enabling debug packages by default.
> 
> Please fill which time suits you best on Monday (17.09) or Tuesday
> (18.09) here[1].
> 
> The meeting will take place on #archlinux-devops on Freenode. It's a
> public channel so anyone who's interested can join.
> 
> I will send an update with final date till Sunday.
> 
> Bartłomiej
> 
> [1] https://doodle.com/poll/6hsbn8z3et8gazmi
> 

The meeting will take place on Monday, 7PM CEST. I will publish
minutes/log after it's over.

Bartłomiej

[arch-dev-public] Meeting on dbscripts git repository layout and debug packages

[Bartłomiej Piotrowski via arch-dev-public]

Hi all,

We would like to discuss design, issues and what is left to do about the
future dbscripts git migration and enabling debug packages by default.

Please fill which time suits you best on Monday (17.09) or Tuesday
(18.09) here[1].

The meeting will take place on #archlinux-devops on Freenode. It's a
public channel so anyone who's interested can join.

I will send an update with final date till Sunday.

Bartłomiej

[1] https://doodle.com/poll/6hsbn8z3et8gazmi

Re: [arch-dev-public] /r/linux AMA

[Bartłomiej Piotrowski via arch-dev-public]

On 09/08/2018 18.41, Morten Linderud via arch-dev-public wrote:
> Yo!
> 
> The subreddit /r/linux have started organizing AMA threads for relevant
> projects. Gentoo had one of these a few months ago and is an interesting read.
> 
> https://www.reddit.com/r/linux/comments/8nsdj0/we_are_gentoo_developers_ama/
> https://www.reddit.com/r/linux/comments/93qlow/established_project_developer_team_member_flairs/
> 
> I think it's a good idea Arch Linux does an AMA as it's might give users some
> incentive to help contributing to the project. I have chatted with a subreddit
> mod at /r/linux, and the AMA should preferably start on any Monday from 27th 
> and
> onwards. It will also run for a few days, so there is no need to be present 
> all
> the time, or when it starts.
> 
> 
> If you are interested participating please reply to the list with the 
> following
> information:
> 
> * Reddit username.
> * What you do.
> * What Monday fits for you?
> 
> I have also started handing out flairs on the /r/archlinux subreddit. It's not
> an official forum, but if developers and team members want flairs for their
> reddit accounts you can also reply to this mail or poke me on IRC :)
> 

I'd like to participate too, if time allows.

/u/barthalion, I'm a developer maintaining the toolchain, master key
holder and DevOps team member.

I'll be completely away for the first week of September, I should be
fine after that.

Bartłomiej

[arch-dev-public] Enforcing 2FA in GitHub organization

[Bartłomiej Piotrowski via arch-dev-public]

Hi all,

I want to enable mandatory two-factor authentication in our GitHub
organization. Few of you unfortunately don't use it and will be
effectively removed when I flip the switch, which I plan to do next
week, 6th July.

allanbrokeit
anthraxx
Atsutane
Bluewind
brain0
City-busz
djgera
eli-schwartz
foutrelis
lordheavy
phrakture
SantiagoTorres
seblu
shibumi
vesath
wonder

Bartłomiej

Re: [arch-dev-public] glibc 2.27 based toolchain in [staging]

[Bartłomiej Piotrowski via arch-dev-public]

New draft that includes pam_unix2 deprecation.

Title: glibc 2.27-2 and pam 1.3.0-2 may require manual intervention

The new version of glibc removes support for NIS and NIS+. The default
`/etc/nsswitch.conf` file provided by `filesystem` package already
reflects this change. Please make sure to merge pacnew file if it exists
prior to upgrade.

NIS functionality can still be enabled by installing `libnss_nis`
package. There is no replacement for NIS+ in the official repositories.

`pam 1.3.0-2` no longer ships pam_unix2 module and `pam_unix_*.so`
compatibility symlinks. Before upgrading, review PAM configuration files
in the `/etc/pam.d` directory and replace removed modules with
`pam_unix.so`. Users of pam_unix2 should also reset their passwords
after such change. Defaults provided by `pambase` package do not need
any modifications.

Re: [arch-dev-public] Deprecation of pam_unix2

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-04-16 13:02, Bartłomiej Piotrowski via arch-dev-public wrote:

Hi team,

During libnsl rebuild heftig pointed out that we are shipping pam_unix2 
that has been dead upstream for a long time (to the point that it's 
being built from our own mirror now). I'm also unwilling to spend time 
to fix its configure.ac to make it build with libnsl and libtirpc 
correctly.


Unless someone's life depends on it, I'd like to drop it from repositories.

Bartłomiej


(Note it's not packaged separately and ships as part of core/pam.)

While on it, I'm dropping pam_unix_{acct,auth_passwd,session}.so 
symlinks from pam package that are also relics of the distant past.


Bartłomiej

[arch-dev-public] Removing gksu

[Bartłomiej Piotrowski via arch-dev-public]

What a day!

gksu has been deprecated for years. Applications that require elevated 
privileges should use PolicyKit instead - and it seems that everything 
in our repositories do. I plan to remove gksu (and libgksu) from 
repositories this week.


Bartłomiej

[arch-dev-public] Deprecation of pam_unix2

[Bartłomiej Piotrowski via arch-dev-public]

Hi team,

During libnsl rebuild heftig pointed out that we are shipping pam_unix2 
that has been dead upstream for a long time (to the point that it's 
being built from our own mirror now). I'm also unwilling to spend time 
to fix its configure.ac to make it build with libnsl and libtirpc correctly.


Unless someone's life depends on it, I'd like to drop it from repositories.

Bartłomiej

Re: [arch-dev-public] Boost looking for new maintainer

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-03-20 18:45, Levente Polyak via arch-dev-public wrote:

On March 20, 2018 4:55:16 PM GMT+01:00, Robin Broda via arch-dev-public 
<arch-dev-public@archlinux.org> wrote:

On 03/20/2018 02:36 PM, Bartłomiej Piotrowski via arch-dev-public
wrote:

Hi team,

As I'm absolutely the worst with C++, none of my packages depend on
boost and I've spent enough nights terrified of its build system

quirks,

I'll be orphaning it soon. Feel free to adopt it in archweb.

Bartłomiej



If you're willing to drop it to [community] i'll gladly adopt it.

Rob


Well I pretty much love cpp and boost and have multiple packages depending on 
it, if nobody here feels butt hurt or robbed I would happily adopt it. I don't 
fear sleepless nights and I explicitly welcome everyone to propose sane changes 
now or in future, working together is key to success :D

Cheers
Levente



New version has been released yesterday so enjoy!

Bartłomiej

[arch-dev-public] glibc 2.27 based toolchain in [staging]

[Bartłomiej Piotrowski via arch-dev-public]

Hi,

I've had too much faith in GCC 8 release schedule. To sweeten the wait
(and catch some possible issues sooner), I'm going to push glibc 2.27
and binutils 2.30 to [staging] in the evening.

The new glibc doesn't ship libnss_nis{,plus} and RPC interface anymore.
Packages that require the last should switch to libtirpc; libnsl shared
library is still provided for backwards compatibility with old ABI, but
dependent packages should be rebuild against standalone libnsl package
(rebuild in archweb will follow soon).

As some users may have used NIS in their nsswitch.conf file, news post
wouldn't hurt. Here's a draft:

Title: glibc 2.27-2 removes support for NIS and NIS+

The new version of glibc removes support for NIS and NIS+. The default
`/etc/nsswitch.conf` file provided by `filesystem` package already
reflects this change. Please make sure to merge pacnew file if it exists
prior to upgrade.

NIS functionality can still be enabled by installing `libnss_nis`
package. There is no replacement for NIS+ in the official repositories.

Re: [arch-dev-public] New build server in Singapore

[Bartłomiej Piotrowski via arch-dev-public]

On 2017-10-22 13:13, Bartłomiej Piotrowski wrote:
> Hi all,
> 
> for those of you that are living closer to Asia than Europe, there is
> new build server available, located in Singapore. It is considerably
> less beefy than soyuz, but should be okay for regular builds.
> 
> All packagers should be able to ssh into it with username and the key
> used on other servers. The address is sgp.pkgbuild.com. You can compare
> fingerprints below:
> 
> SHA256:f9VrDpIpOHvgWk+OXXRG+VMvJlbs577YFZfyxPtXKqU (ED25519)
> SHA256:fDdeGInsD764tfnGCbNIPH69L4k7mNs98ttFpTOv01U (RSA)
> SHA256:MsoXUmTXowWcPb4gma3U60Po0/5sTT5Fg+oM8bWIIUE (ECDSA)
> 
> It also hosts a mirror available at https://sgp.mirror.pkgbuild.com
> 
> Enjoy,
> Bartłomiej
> 

For the record, the build server lives on at sgp.mirror.pkgbuild.com.

The old one that went done few months ago failed to boot after replacing
its system with Arch so I'm bailing out.

Bartłomiej

[arch-dev-public] Boost looking for new maintainer

[Bartłomiej Piotrowski via arch-dev-public]

Hi team,

As I'm absolutely the worst with C++, none of my packages depend on
boost and I've spent enough nights terrified of its build system quirks,
I'll be orphaning it soon. Feel free to adopt it in archweb.

Bartłomiej

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-03-13 15:32, Eli Schwartz via arch-dev-public wrote:
> This wrapper changes depending on which version of meson you have installed.

The wrapper is part of the package that changes.

> The fact that autoconf has weird bugs like needing to set localstatedir
> and sysconfdir to their defaults minus the /usr prefix, is an autoconf
> bug. Maybe we could work on having meson not require setting bizarre
> options just to get sane defaults?

Neither is a bug. It's just a convenience script. Do you propose to work
on upstreaming defaults that make sense for Arch, but not necessarily
for what other distributions do or aim for?

> (Setting the prefix automatically propagates to everything specified
> with relative paths, which is most things, and libexecdir and sbindir
> could just specify a *different* relative path.)

(Which is completely unrelated to our use case, even if you put this
between parentheses.)

> So other languages, which completely disregard our CFLAGS but which
> meson itself has magic wrappers for... and the solution is to add a
> magic script to use in the PKGBUILD which does not respect makepkg.conf
> but can add debug symbols only loosely related to what we were trying to
> get? A script which arbitrarily adds debug symbols to packages that were
> rebuilt with OPTIONS=(!debug) by users who wanted to make local
> modifications?

Other languages ignore CFLAGS (hint: these are CFLAGS after all) anyway.
Users wanting to make local modifications were always on their own.

> since apparently meson is so perfect we should do literally everything
> directly in meson.

A cheap hyperbole. Obviously unnecessary if you want to be taken seriously.

> Or we could at least make a *proper* wrapper which can talk to makepkg
> and determine if debug info is wanted.

Patches welcome. Would be more productive use of your time than making a
storm in the glass of water here.

Bartłomiej

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-03-13 14:40, Allan McRae via arch-dev-public wrote:
> On 13/03/18 21:22, Jan Alexander Steffens via arch-dev-public wrote:
>> For that matter, I'm all for putting an arch-configure helper into our
>> autoconf package.
> 
> Don't muck around with vanilla packages.  Put it in another package
> (devtools).
> 
> A
> 

Makes no sense unless devtools become part of base-devel. It's hardly
any meddling as it doesn't hinder possibility to use default configure
script or meson binary.

Bartłomiej

Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-03-12 05:33, Pierre Schmitz wrote:
> Thanks for digging this up again. You may use the github issue or
> project system to plan the different steps. Also (and please don't get
> it the wrong way) let's keep the purpose I intended for our Docker
> image intact.

No one has suggested changing "the purpose". I'm not sure what is
unclear in Santiago's mail.

Bartłomiej

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-03-10 11:34, Antonio Rojas via arch-dev-public wrote:
> Hi,
>  Currently most of our packages which use the cmake build system are built 
> with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to 
> upstream) set of C(XX)FLAGS defaults which are appended to and override our 
> default C(XX)FLAGS. So, for instance, our cmake packages are being built with 
> -O3 instead of our default -O2. Besides the inconsistency that this brings to 
> our binaries, IMO it's not a good idea to override our default C(XX)FLAGS 
> unless there's a good reason to. This will also cause issues once we start 
> building debug packages by default (-DCMAKE_BUILD_TYPE=Release also adds 
> DNDEBUG).
>  Therefore I'm proposing to drop -DCMAKE_BUILD_TYPE from all our cmake 
> packages, building them with our default C(XX)FLAGS as all other packages. 
> Comments?
> 

Sounds good. I'm also surprised that it's how it works, honestly. Are
LDFLAGS taken into account regardless of CMAKE_BUILD_TYPE? Will there a
to do list to track the progress?

Bartłomiej

Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-01-29 20:29, Pierre Schmitz wrote:
> * I did not look into the details of how we exactly need to proceed
> with making an "official" image. A few pull requests or some kind of
> setp-by-step plan (wiki or github) would help.

Necrobumping. You actually quoted the message from Santiago that
describes the process. I'm going to grant him and Christian write
permissions so they can start working on this on separate branch.

Bartłomiej

Re: [arch-dev-public] Test repository with gcc8

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-02-13 16:13, Eli Schwartz via arch-dev-public wrote:
> On 02/13/2018 09:29 AM, Bartłomiej Piotrowski via arch-dev-public wrote:
>>>> I have updated gcc in the repository to snapshot from 2018-02-11
>>>> (r257571). Additionally, if you have access to soyuz, the repo can be
>>>> easily used in build chroots with 'gcc8-x86_64-build' command (which
>>>> also enables [testing]).
>>>
>>> Nice, thanks!
>>>
>>> Could you enable the password-less rules for sudo that are already setup
>>> for extra-x86_64-build?  Currently gcc8-x86_64-build asks for a sudo
>>> password, but most of us are not sudoers on soyuz (and don't need to be).
>>>
>>> Baptiste
>>>
>>
>> Try now. My change may be overwritten as I didn't add it to our Ansible
>> playbooks but I cross my fingers to see 8.1.0 soon.
> 
> Would it be worth adding a sudoers configuration that allows any
> /usr/bin/*-x86_64-build command? On the theory that that is a rather
> specific script suffix, and is exceedingly unlikely to be created in
> /usr/bin/ for any reason other than as a symlink to archbuild with a
> corresponding /usr/share/devtools/pacman-*.conf (which is presumably
> something that should always be allowed).
> 

I'm not sure if it's worth it as the repo is only semi-official, and
besides I've had time only for a band-aid today. Also you know where the
infrastructure repo resides and I'll be more than happy to run 'git am'
your patch if you share it on #archlinux-devops.

Bartłomiej

Re: [arch-dev-public] Test repository with gcc8

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-02-13 15:19, Baptiste Jonglez wrote:
> On 13-02-18, Bartłomiej Piotrowski via arch-dev-public wrote:
>> On 2018-02-04 14:02, Bartłomiej Piotrowski via arch-dev-public wrote:
>>> Hi all,
>>>
>>> I've prepared external repository with GCC 8 built from trunk (as there
>>> is no stable release yet) that also contains glibc 2.27 and binutils 2.30.
>>>
>>> [gcc8]
>>> Server = http://pkgbuild.com/~bpiotrowski/gcc8/
>>>
>>> From less obvious packaging changes, glibc no longer ships with obsolete
>>> rpc and nsl, which means that you should switch your packages to
>>> libtirpc; also if your nsswitch.conf still contains "compat" instead of
>>> "files", better fix it before reboot. If for some reason you still use
>>> nsl, the repository also ships libnsl and libnsl_nis packages.
>>>
>>> As usually, simple things build, and colossi like LibreOffice don't, but
>>> I haven't had time yet to check why. If you found some issue, the best
>>> would be to reply either here or arch-general.
>>>
>>> Enjoy,
>>> Bartłomiej
>>>
>> I have updated gcc in the repository to snapshot from 2018-02-11
>> (r257571). Additionally, if you have access to soyuz, the repo can be
>> easily used in build chroots with 'gcc8-x86_64-build' command (which
>> also enables [testing]).
> 
> Nice, thanks!
> 
> Could you enable the password-less rules for sudo that are already setup
> for extra-x86_64-build?  Currently gcc8-x86_64-build asks for a sudo
> password, but most of us are not sudoers on soyuz (and don't need to be).
> 
> Baptiste
> 

Try now. My change may be overwritten as I didn't add it to our Ansible
playbooks but I cross my fingers to see 8.1.0 soon.

Bartłomiej

Re: [arch-dev-public] Test repository with gcc8

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-02-04 14:02, Bartłomiej Piotrowski via arch-dev-public wrote:
> Hi all,
> 
> I've prepared external repository with GCC 8 built from trunk (as there
> is no stable release yet) that also contains glibc 2.27 and binutils 2.30.
> 
> [gcc8]
> Server = http://pkgbuild.com/~bpiotrowski/gcc8/
> 
> From less obvious packaging changes, glibc no longer ships with obsolete
> rpc and nsl, which means that you should switch your packages to
> libtirpc; also if your nsswitch.conf still contains "compat" instead of
> "files", better fix it before reboot. If for some reason you still use
> nsl, the repository also ships libnsl and libnsl_nis packages.
> 
> As usually, simple things build, and colossi like LibreOffice don't, but
> I haven't had time yet to check why. If you found some issue, the best
> would be to reply either here or arch-general.
> 
> Enjoy,
> Bartłomiej
> 
I have updated gcc in the repository to snapshot from 2018-02-11
(r257571). Additionally, if you have access to soyuz, the repo can be
easily used in build chroots with 'gcc8-x86_64-build' command (which
also enables [testing]).

Bartłomiej

[arch-dev-public] Test repository with gcc8

[Bartłomiej Piotrowski via arch-dev-public]

Hi all,

I've prepared external repository with GCC 8 built from trunk (as there
is no stable release yet) that also contains glibc 2.27 and binutils 2.30.

[gcc8]
Server = http://pkgbuild.com/~bpiotrowski/gcc8/

From less obvious packaging changes, glibc no longer ships with obsolete
rpc and nsl, which means that you should switch your packages to
libtirpc; also if your nsswitch.conf still contains "compat" instead of
"files", better fix it before reboot. If for some reason you still use
nsl, the repository also ships libnsl and libnsl_nis packages.

As usually, simple things build, and colossi like LibreOffice don't, but
I haven't had time yet to check why. If you found some issue, the best
would be to reply either here or arch-general.

Enjoy,
Bartłomiej



signature.asc
Description: OpenPGP digital signature

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

[Bartłomiej Piotrowski via arch-dev-public]

Whoa, this is so good to bash that I can't decide where to begin.

Microsoft started noticing Linux (or rather stopped to fight it so
valiantly) when they realized where the money is. On this ground alone I
don't see a reason to help some corporation in putting our logo on their
website so they can brag how they love Linux now, especially when there
are no real gains for us in all of this.

If you want more technical angle, at least few months ago installing
Arch on WSL required patched glibc. I won't maintain such patches
because of something I completely don't care about. Even if it was
solved since, good luck with debugging all possible heisenbugs that can
be encountered due to sloppy implementation of Linux syscalls on
Windows. If the proposal gets through, I'm not going to spend time on
any of such reports at all, making heavy use of EWONTFIX.

I don't use Windows and I don't care about WSL. Having Docker image
makes sense as it can bring some value for people using different
distributions for development or testing purposes alone. That can't be
said about WSL.

Bartłomiej

Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-01-20 20:19, Christian Rebischke via arch-dev-public wrote:
> The Arch Linux Vagrant images are currently be build for libvirt and
> virtualbox. We have over 3800 downloads at the moment and slowly
> catching up to the community based arch linux vagrant images.[1]

It would be probably seen as more "official" if it was mentioned on our
website.

> My first goal has been to add some hypervisors, but due to
> the fact that we have only libvirt and virtualbox in our repositories I
> have dismissed this plan. The automated build process works fine so far
> (except some issues with qemu[2] and the dependency on punctual iso
> releases on soyuz. The latter should we definitly fix. Currently the iso
> images are build manually. Can we automate this somehow? I really rely
> on punctual releases otherwise the automated build will fail and
> somebody needs to trigger the build again manually. Happened about 1-2
> times..)

This is something that would require a virtually offline box to be fully
automated. For the time being, it sounds better to upgrade your vagrant
image after first week of the month.

Also, any plans to expand the scope to support OpenStack, AWS and GCE?
At the moment the scope sounds rather limited.

> Sangy/Santiago[3] was so nice to speak with the docker guys. They said
> they would approve our docker image and we could move it to the other
> official images[4]. But for this we need to do some changes on our
> docker repository on github. (As long I understood sangy correct it
> would be just some new branches).

Can you actually give more details how it's going to look like?

Bartłomiej

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

Hi team,

I've finished moving unneeded orphans to AUR. The only exceptions that
were simply removed are nvidia-304xx family (EOL'ed upstream) and
nautilus-open-terminal (seems to be built into nautilus these days).

You can find the list of (re)moved packages here[1]. Let's try not to
make such a mess this time!

Bartłomiej

[1] https://paste.xinu.at/VjGQ/

Re: [arch-dev-public] Package group between repositories

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-01-04 13:02, Balló György via arch-dev-public wrote:
> Currently the 'xfce4-goodies' package group[1] is in split between [extra]
> and [community]. Most of its packages are in [extra], but 'ristretto' and
> 'xfce4-whiskermenu-plugin' are in [community].
> 
> My question is: is it okay, or should we avoid it by removing these two
> packages from the 'xfce4-goodies' group or moving them to [extra]?
> 
> [1] https://www.archlinux.org/groups/x86_64/xfce4-goodies/
> 
> --
> György Balló
> Trusted User
> 

Groups are just for convenience and members don't have to be in the same
repository. The latter also applies to regular dependencies these days
as it's more practical to have a dependency maintained by a TU than left
rotten in [extra]. At least that's my view on it.

BP

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-01-04 12:17, Balló György via arch-dev-public wrote:
> The following packages should be kept too:
> - dvdauthor
> arojas: kdenlive
> fyan: kdenlive
> heftig: brasero
> jgc: brasero

The only two packages that really require it are unneeded orphans, so I
don't see the point.

> - sofia-sip
> heftig: empathy

Ditto. There is nothing special about unmaintained optdepends that are
providing completely optional functionality.

Bartłomiej

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-01-04 10:35, Rashif Ray Rahman via arch-dev-public wrote:
> 2018-01-03 21:05 GMT+06:00 Bartłomiej Piotrowski via arch-dev-public
> <arch-dev-public@archlinux.org>:
>>
>> Hi team,
>>
>> This is the final update before I start moving packages to AUR over this
>> week.
>>
>> List of orphans required by maintained packages:
>>
>> ...
> 
> Just to confirm, are these going to be dropped despite being required
> by maintained packages?

No, it's a list of orphans that could be adopted by maintainers of
packages that require them. Removal would mean broken dependencies, so
they're going to stay maintained or not.

BP

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-01-04 00:20, Balló György via arch-dev-public wrote:
> Please move the following packages from [extra] to [community], so I can
> adopt them:
> - gnome-icon-theme-extras
> - libgovirt
> - python2-telepathy
> 
> --
> György Balló
> Trusted User
> 

Moved, enjoy.

BP

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

On 2018-01-03 23:31, Balló György via arch-dev-public wrote:
> Please don't remove anything yet. I'll adopt some packages in the next 24
> hours.
> 
> You missed some optional and indirect dependencies. We should keep the
> following packages:

I explicitly said that I'm not taking optdepends into account. There are
some false positives on the list but I haven't said I'm going to drop
everything blindly either.

Bartłomiej

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

Hi team,

This is the final update before I start moving packages to AUR over this
week.

List of orphans required by maintained packages:

- autoconf-archive:
jgc: dbus, gspell, gnumeric
tomegun: dbus, dbus-docs, libimobiledevice
heftig: gst-plugins-base-libs, gstreamer, libgweather
zorun: ring-daemon
fyan: lib32-gst-plugins-good, lib32-gstreamer, deepin-metacity
alucryd: hexchat, lib32-polkit
faidoc: cinnamon-settings-daemon
eschwartz: cinnamon-settings-daemon
bgyorgy: budgie-desktop
andyrtr: fontconfig
lcarlier: lib32-dbus
eworm: packagekit
- bctoolbox:
arojas: mediastreamer
- bcunit:
arojas: mediastreamer
- blackbox:
jlichtblau: bbpager
- bmake:
spupykin: lua51-alt-getopt, lua-alt-getopt, lua52-alt-getopt
- bzrtp:
arojas: mediastreamer
- caja:
bgyorgy: filemanager-actions
eschwartz: xreader
- cd-discid:
schuay: abcde
- cddb_get:
jlichtblau: hacburn
- cinepaint:
eworm: gimp-ufraw
- classpath:
svenstaro: uwsgi-plugin-zabbix, uwsgi-plugin-jvm, uwsgi-plugin-pypy
fyan: uwsgi-plugin-zabbix, uwsgi-plugin-jvm, uwsgi-plugin-pypy
arodseth: clojure
- convertlit:
arojas: ebook-tools
- db:
pierre: php-imap, php-sqlite, php-odbc
tpowa: smbclient, libwbclient, samba
jgc: apr-util, evolution-data-server
anatolik: apr-util
bluewind: perl
spupykin: opendkim, opensips, postgrey
alucryd: lib32-db
andyrtr: bogofilter
schiv: jack
lfleischer: libical
bisson: postfix
- dvgrab:
bluewind: openshot
- ecryptfs-utils:
jsteel: clonezilla
- enca:
anthraxx: mplayer, mencoder
jlichtblau: ogmrip
- faenza-icon-theme:
alucryd: faience-icon-theme
- farstream:
foutrelis: libpurple, pidgin, finch
heftig: telepathy-farstream
- frei0r-plugins:
heftig: gnome-video-effects
arojas: mlt, mlt-python-bindings
- gamin:
schiv: snd
tpowa: smbclient, libwbclient, samba
- giblib:
anthraxx: scrot
- gnustep-base:
svenstaro: oolite
heftig: meson
anthraxx: meson
- gnustep-gui:
svenstaro: oolite
- gnustep-make:
svenstaro: oolite
- goocanvas:
bgyorgy: ocrfeeder
jgc: libgda
heftig: libgda
jlichtblau: goocanvasmm
- gpsbabel:
jlichtblau: gebabbel
- graphene:
heftig: gst-plugins-bad
- gwenhywfar:
jlichtblau: aqbanking
- hevea:
spupykin: ejabberd
zorun: coq, coqide, coq-doc
arojas: libgiac, xcas
- hunspell-hu:
heftig: ibus-typing-booster
- hunspell-it:
heftig: ibus-typing-booster
- hunspell-ro:
heftig: ibus-typing-booster
- hwloc:
anthraxx: openmpi
- idnkit:
seblu: bind-tools, bind
tpowa: archboot
- ifplugd:
tpowa: archboot
- imlib:
jlichtblau: kuickshow
- intel-tbb:
svenstaro: openimageio, opensubdiv, openshadinglanguage
ronald: suitesparse
kkeen: cryptominisat5
stativ: embree
schiv: opencv
- ispell:
andyrtr: hunspell-de
- jbigkit:
jelle: netpbm
eric: libtiff
- js185:
Archange: couchdb
- lasem:
jgc: goffice
- lcms:
fyan: lib32-lcms
eworm: gimp-ufraw, gimp
eric: geeqie
tpowa: xsane-gimp, xsane
arodseth: netsurf
anthraxx: gimp
lcarlier: devil
- lib32-libcdio:
schuay: pcsxr
- libantlr3c:
fyan: cvc4
- libcdaudio:
eric: epplet-base
- libdbi:
jsteel: monitoring-plugins
bisson: collectd
eric: syslog-ng
seblu: ulogd
- libdiscid:
lcarlier: kaudiocreator
xyne: cmus
bisson: python2-discid, python-discid
bgyorgy: goobox
jgc: sound-juicer
heftig: sound-juicer
- libdvbpsi:
anthraxx: vlc
- libfm-qt:
jleclanche: lxqt-qtplugin, pcmanfm-qt, lximage-qt
- libgadu:
foutrelis: libpurple, pidgin, finch
arojas: kopete
- libgme:
anthraxx: vlc
bisson: mpd
jlichtblau: qmmp
heftig: gst-plugins-bad
- libgoom2:
anthraxx: vlc
- libgovirt:
bgyorgy: gnome-boxes
- libkeybinder2:
bgyorgy: lxpanel
- liblouis:
andyrtr: cups-filters
jgc: orca
- liblqr:
ronald: digikam, kipi-plugins
arojas: digikam, kipi-plugins
heftig: libmagick6
eric: libmagick
stativ: gimp-plugin-lqr
- libnice:
arojas: telepathy-gabble
- libnids:
zorun: dsniff
- libnl1:
seblu: keepalived, ipvsadm
- libofa:
ronald: amarok
arojas: amarok
heftig: gst-plugins-bad
- libopenshot:
bluewind: openshot
- libraqm:
heftig: libmagick6
eric: libmagick
- libsidplayfp:
jlichtblau: qmmp
foutrelis: audacious-plugins
- libtiger:
anthraxx: vlc
heftig: gst-plugins-bad
- libtommath:
andyrtr: libreoffice-still, libreoffice-fresh, libreoffice-fresh-sdk
- libupnp:
zorun: ring-daemon
arojas: amule, mediastreamer
anthraxx: vlc
bisson: mpd
- live-media:
anthraxx: mplayer, vlc, mencoder
- lua51:
fyan: ibus-pinyin, uwsgi-plugin-zabbix, uwsgi-plugin-jvm
spupykin: lua-sec, lua51-sec, lua51-expat
svenstaro: uwsgi-plugin-zabbix, tolua++, uwsgi-plugin-jvm
eric: rrdtool
eworm: lua52-lpeg, lua51-lpeg, 

[arch-dev-public] gdbm 1.14 removed from [testing]

[Bartłomiej Piotrowski via arch-dev-public]

Hi all,

gdbm 1.14 introduced silent ABI breakage[1] so for now, I removed it
from [testing]. I contacted upstream about the issue and if the time
allows, I will prepare a fix today.

Bartłomiej



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

On 2017-12-18 23:51, Baptiste Jonglez wrote:
> On 18-12-17, Bartłomiej Piotrowski via arch-dev-public wrote:
>> On 2017-12-18 10:54, Bartłomiej Piotrowski via arch-dev-public wrote:
>>> Please look at both lists and adopt what your packages are using or
>>> you're personally interested in. I will drop whatever makes sense in
>>> January.
>>
>> And of course, if you are missing some permissions or need something
>> moved to [community], let me know.
> 
> Useful script, thanks!
> 
> Can you move fig2dev to [commmunity] so that I can adopt it?
> 
> I have also adopted a few unneeded orphans.
> 
> Baptiste
> 

Moved, enjoy.

BP

Re: [arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

On 2017-12-18 10:54, Bartłomiej Piotrowski via arch-dev-public wrote:
> Please look at both lists and adopt what your packages are using or
> you're personally interested in. I will drop whatever makes sense in
> January.

And of course, if you are missing some permissions or need something
moved to [community], let me know.

BP

[arch-dev-public] 2017 repository cleanup

[Bartłomiej Piotrowski via arch-dev-public]

Hi team,

Recently I've spent a bit of time on the train so I spent that on
writing a script (of questionable quality) for generating packages
cleanup list. The main difference from the "unneeded orphans" report is
that it also includes orphans that require only other orphans and
additionally generates possible maintainers for required but
unmaintained packages.

The script can be found here[1] and I will probably improve it a bit on
the next journey.

Note that it doesn't consider optdepends when checking if orphan is
needed only by other orphans. Max. 3 packages requiring given orphan are
listed next to possible maintainer. It also ignores repo hierarchy
because it's just a theater these days.

Please look at both lists and adopt what your packages are using or
you're personally interested in. I will drop whatever makes sense in
January.

Bartłomiej

[1] https://paste.xinu.at/Hsbt/

Orphans required by maintained packages:
- augeas:
shibumi: ruby-augeas
mtorromeo: python2-augeas
fyan: python-augeas
- autoconf-archive:
faidoc: cinnamon-settings-daemon
jgc: gnote, appstream-glib, dbus-docs
heftig: gst-plugins-bad, gtksourceview3, bijiben
fyan: lib32-gst-plugins-good, lib32-gst-plugins-base, lib32-gstreamer
tomegun: dbus-docs, libimobiledevice, dbus
alucryd: lib32-polkit, hexchat
andyrtr: fontconfig
lcarlier: lib32-dbus
eworm: packagekit
bgyorgy: budgie-desktop
- babl:
jgc: gnome-photos
heftig: gnome-photos
anthraxx: gimp
eworm: gimp
- bctoolbox:
arojas: mediastreamer
- bcunit:
arojas: mediastreamer
- blackbox:
jlichtblau: bbpager
- bmake:
spupykin: lua-alt-getopt, lua51-alt-getopt, lua52-alt-getopt
- bzrtp:
arojas: mediastreamer
- caja:
bgyorgy: filemanager-actions
- cd-discid:
schuay: abcde
- cddb_get:
jlichtblau: hacburn
- cimg:
svenstaro: wxcam
- cinepaint:
eworm: gimp-ufraw
- cinnamon-menus:
faidoc: cinnamon-control-center, cinnamon
- clamz:
ronald: amarok
arojas: amarok
- classpath:
svenstaro: uwsgi-plugin-rack, uwsgi, uwsgi-plugin-jvm
fyan: uwsgi-plugin-rack, uwsgi, uwsgi-plugin-jvm
arodseth: clojure
- convertlit:
arojas: ebook-tools
- cvc4:
fyan: maude
- dante:
fyan: shadowsocks
- db:
pierre: php-gd, php, php-imap
schiv: jack
jgc: evolution-data-server, apr-util
bluewind: perl
spupykin: opendkim, perl-berkeleydb, postgrey
tpowa: smbclient, samba, libwbclient
lfleischer: libical
bisson: postfix
alucryd: lib32-db
anatolik: apr-util
andyrtr: bogofilter
- dbus-c++:
schiv: libffado
dvzrv: libffado
fyan: kimtoy
- dev86:
eworm: virtualbox, virtualbox-sdk, virtualbox-guest-utils-nox
- dmenu:
kkeen: spectrwm
lcarlier: uzbl-browser
- docbook2x:
spupykin: moreutils, lxc
andyrtr: libcmis
seblu: nftables
guillaume: java-jsvc, java-commons-daemon
fyan: ibus-table
bisson: conky
- dotconf:
svenstaro: libspeechd, speech-dispatcher
- double-conversion:
fyan: qt5-base
arojas: qt5-base
- dvgrab:
bluewind: openshot
- ecryptfs-utils:
jsteel: clonezilla
- enca:
anthraxx: mencoder, mplayer
jlichtblau: ogmrip
- faenza-icon-theme:
alucryd: faience-icon-theme
- farstream:
foutrelis: pidgin, finch, libpurple
heftig: telepathy-farstream
- fig2dev:
zorun: coqide, coq, coq-doc
- flickcurl:
Archange: darktable
- fltk:
ronald: octave
schiv: alsa-tools
arojas: libgiac, xcas
arodseth: tuxpaint-config, monica
dvzrv: zynaddsubfx
kkeen: xdiskusage, dillo
lfleischer: lmms
spupykin: tigervnc
- freetds:
fyan: qt5-base, qt5-xcb-private-headers
arojas: qt5-base, qt5-xcb-private-headers
pierre: php-gd, php, php-imap
spupykin: perl-dbd-sybase
- frei0r-plugins:
heftig: gnome-video-effects
arojas: mlt-python-bindings, mlt
- fribidi:
eric: avidemux-qt, fvwm, avidemux-cli
anthraxx: avidemux-qt, avidemux-cli
alucryd: libass, ffmpeg2.8, ffmpeg
jlichtblau: glob2, fillets-ng
ronald: efl
svenstaro: wesnoth, supertuxkart
idevolder: kodi
bisson: m17n-lib
spupykin: fbreader
arodseth: tuxpaint
jgc: abiword
lcarlier: warzone2100
- ftjam:
eric: lincity-ng
jlichtblau: lincity-ng
svenstaro: megaglest
Archange: argyllcms
- gamin:
tpowa: smbclient, samba, libwbclient
schiv: snd
- gegl:
jgc: gnome-photos
heftig: gnome-photos
- gegl02:
anthraxx: gimp
eworm: gimp
- giblib:
anthraxx: scrot
- glyr:
Alad: pragha
- gnome-autoar:
jgc: nautilus, evolution
heftig: nautilus
bgyorgy: gnome-recipes
- gnome-icon-theme-symbolic:
jgc: gnome-icon-theme
- gnustep-base:
svenstaro: oolite
heftig: meson
anthraxx: meson
- gnustep-gui:
svenstaro: oolite
- gnustep-make:
svenstaro: oolite
- goocanvas:
jlichtblau: goocanvasmm
bgyorgy: ocrfeeder
jgc: libgda
heftig: libgda
- gpsbabel:
jlichtblau: gebabbel

[arch-dev-public] Merging multilib toolchain with [core]

[Bartłomiej Piotrowski]

Hi,

For a long time we have been maintaining multilib-enabled gcc package
separately under [multilib] repo. Compilation takes a lot and usually it
falls behind because I forget to keep it in sync with [core].

I propose to merge it with core/gcc instead and split lib32-gcc-libs.
The latter would be moved to [core] due to dbscripts inability to
maintain split packages in multiple repositories. On the same note, the
same would happen to lib32-glibc.

Any objections?
Bartłomiej

Re: [arch-dev-public] Switching the bugtracker to Bugzilla

[Bartłomiej Piotrowski]

On 2017-11-14 22:59, Allan McRae wrote:
> On 15/11/17 07:34, Bartłomiej Piotrowski wrote:
>>> There are several options for migrating the bug history to Bugzilla and a 
>>> few options are under
>>> debate. (input welcome)
>> As I said multiple times on IRC, I'm for starting from scratch. There
>> are way too many inactive or/and incorrect bugs open, and honestly any
>> effort to review that list is a waste of time. With no bugs open we can
>> 1) pretend everything works fine 2) hopefully avoid zombie-bugs
>> apocalypse that we have now. Flyspray could be mirrored with wget for
>> read-only version.
> 
> If you don't migrate pacman bugs, don't bother creating a pacman component.
> 
> A
> 

I mean packaging bugs here, not standalone projects.

Bartłomiej

Re: [arch-dev-public] Switching the bugtracker to Bugzilla

[Bartłomiej Piotrowski]

On 2017-11-14 20:30, Jelle van der Waa wrote:
> Used by several big projects such as Gnome, LLVM and Mozilla

GNOME will probably end up switching to Gitlab. (Not dismissing the fact
that bugzilla is rather popular choice.)

> # Migration
> 
> There are several options for migrating the bug history to Bugzilla and a few 
> options are under
> debate. (input welcome)

As I said multiple times on IRC, I'm for starting from scratch. There
are way too many inactive or/and incorrect bugs open, and honestly any
effort to review that list is a waste of time. With no bugs open we can
1) pretend everything works fine 2) hopefully avoid zombie-bugs
apocalypse that we have now. Flyspray could be mirrored with wget for
read-only version.

> Bugzilla has a concept of products with components, so for all our packages 
> we can create a
> component counterpart. It should be possible to auto-assign bugs with the 
> pkgname <-> maintainer
> information from archweb.

Packages come and go. Some never will have a bug reported because they
just work fine or nobody uses them. Component per package sounds
overboard unless it's going to be automated.

> * Arch packages (core/extra or split this up)
+1 for splitting.

> * Archweb (new)
> * Arch VM / Docker images (new)

These two are already primarily developed on GitHub and I think bugs
should be reported there as well.

Bartłomiej

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

[Bartłomiej Piotrowski]

On 2017-11-06 12:16, Eli Schwartz wrote:
> Well, I doubt they wanted to be caught by surprise and have nothing
> ready if we decided not to allow support requests for arch32...
> 
> But if we are willing to allow arch32 to be hosted under our umbrella,
> the presence of separate infrastructure should not IMHO cause us to go
> back on that and therefore cause additional fragmentation that we were
> initially okay with avoiding.

There is no umbrella as long as "archlinux.org" domain is not involved.
I'm not proposing sharing our master mirror from which every server
syncs packages from, but additional spare boxes that are in the areas of
the world where in general we had few mirrors.

(Re-)using our bug tracker is different subject than is unrelated for
now. Let's move away from flyspray before we start being an umbrella.

Bartłomiej

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

[Bartłomiej Piotrowski]

On 2017-11-06 11:36, Alad Wenter via arch-dev-public wrote:
>> Bartłomiej Piotrowski <bpiotrow...@archlinux.org> hat am 6. November 2017 um 
>> 11:21 geschrieben:
>>
>> Slightly changing the topic... We have plenty of space on our
>> PIA-sponsored mirrors. Given that said fork pretty strictly follows our
>> PKGBUILDs (much alike to ARM team), I'd like to host arch32 mirrors
>> there as well. What do you think?
>>
> I don't mind, but in the end it's up to those who pay for the mirrors. 
> 
> It does bring up the topic again on how the Arch community will support 
> arch32. Does hosting arch32 mirrors give the impression that we support the 
> fork through our channels, or is that unrelated? How will we otherwise react 
> on support requests for or from arch32? IMO, the announcement is vague on 
> that.
> 
> (Personally I would support the idea of having both projects under a common 
> umbrella. But by now arch32 has their own support infrastructure, including 
> forums).
> 
> Alad
> 

Some clarification. Our mirrors under pkgbuild.com domains shouldn't be
considered official or any better than other mirrors. We just happen to
maintain additional mirrors on these machines, nothing more. Donated
infrastructure can disappear tomorrow (or never) and is not considered
"core" for which we pay ourselves. Hosting any mirror there does not
show our endorsement.

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

[Bartłomiej Piotrowski]

On 2017-11-06 11:16, Bartłomiej Piotrowski wrote:
> Following 9 months of [deprecation period][1], support for the i686
> architecture effectively ends today. By the end of November, i686
> packages will be removed from our mirrors and later from the packages
> archive.
> 
> For users unable to upgrade their hardware to x86_64, an alternative is
> a community maintained fork named [Arch Linux 32][2]. See their website
> for details on migrating existing installations.
> 
> [1]: https://www.archlinux.org/news/phasing-out-i686-support/
> [2]: https://archlinux32.org/
> 

Slightly changing the topic... We have plenty of space on our
PIA-sponsored mirrors. Given that said fork pretty strictly follows our
PKGBUILDs (much alike to ARM team), I'd like to host arch32 mirrors
there as well. What do you think?

Bartłomiej

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

[Bartłomiej Piotrowski]

Following 9 months of [deprecation period][1], support for the i686
architecture effectively ends today. By the end of November, i686
packages will be removed from our mirrors and later from the packages
archive.

For users unable to upgrade their hardware to x86_64, an alternative is
a community maintained fork named [Arch Linux 32][2]. See their website
for details on migrating existing installations.

[1]: https://www.archlinux.org/news/phasing-out-i686-support/
[2]: https://archlinux32.org/

[arch-dev-public] Away 31.10 - 5.11

[Bartłomiej Piotrowski]

Hi all,

as I'll be traveling in the beginning of November, you will have to bear
building for i686 one week more. I'll prepare news draft before I'm gone
and changes to devtools are ready, so it won't take long after my return.

Bartłomiej

[arch-dev-public] New build server in Singapore

[Bartłomiej Piotrowski]

Hi all,

for those of you that are living closer to Asia than Europe, there is
new build server available, located in Singapore. It is considerably
less beefy than soyuz, but should be okay for regular builds.

All packagers should be able to ssh into it with username and the key
used on other servers. The address is sgp.pkgbuild.com. You can compare
fingerprints below:

SHA256:f9VrDpIpOHvgWk+OXXRG+VMvJlbs577YFZfyxPtXKqU (ED25519)
SHA256:fDdeGInsD764tfnGCbNIPH69L4k7mNs98ttFpTOv01U (RSA)
SHA256:MsoXUmTXowWcPb4gma3U60Po0/5sTT5Fg+oM8bWIIUE (ECDSA)

It also hosts a mirror available at https://sgp.mirror.pkgbuild.com

Enjoy,
Bartłomiej



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Away until October 9th

[Bartłomiej Piotrowski]

Hi,

FYI, I will be on vacation starting tomorrow. I don't plan to check
e-mails or IRC so if there's anything urgent to do with my packages, be
my guest.

Bartłomiej

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

[Bartłomiej Piotrowski]

On 2017-09-19 18:40, Sébastien Luttringer wrote:
> 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?
> 
> 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.

Do you plan to also fix ca. 1000 other packages in repositories that
ship files in /etc/?

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

It's a valid question though.

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

Because I'm talking about the general process of changes that have been
done and not particular revision. Even if everything looks fine now,
it's still something that should have been sent to arch-dev-public as a
heads up instead of discussing it here only because I expressed concerns
on the bug tracker after the party was over (especially given that you
are hard to catch on IRC).

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

Whatever you're trying to prove here.

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

[Bartłomiej Piotrowski]

On 2017-09-12 19:58, 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.
> 
> Opinions?
> 
> -Andy
> 

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? From top of my
head, it caused issues with pacstrapping with testing, dependency cycle,
OpenSSH and cups, and I'm certain I missed something. If the gain is
ditching few lines of bash from install scriplet, we have wrong priorities…

The fact that the base group is mostly irrelevant these days is another
subject. We should limit it to core utilities and systemd; also consider
making it a meta package. Assumption that JFS, logrotate or s-nail are
widely used on regular Arch systems is silly and because of the lack of
policy whether base is mandatory or not, it causes constant confusion on
the bug tracker.

Bartłomiej

Re: [arch-dev-public] Orphaned packages

[Bartłomiej Piotrowski]

On 2017-08-20 15:13, Sébastien Luttringer wrote:
> 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
> 

Adopted quilt.

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

[Bartłomiej Piotrowski]

On 2017-07-06 09:44, NicoHood wrote:
> On 07/06/2017 09:12 AM, Bartłomiej Piotrowski wrote:
>> On 2017-07-06 02:11, NicoHood wrote:
>>> On 07/05/2017 12:10 AM, Christian Hesse wrote:
>>>> Dave Reisner <d...@falconindy.com> 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.
>>>>
>>>
>>> Systemd still does not use https sources. Regarding the recent
>>> discussion about tricking git about wrong tags and other evil stuff it
>>> is highly recommended to switch to https. Please do it in favor for all
>>> ArchLinux users security.
>>>
>>> Once more the reference:
>>> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
>>>
>>
>> Regarding the recent discussion:
>>
>> https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028919.html
>>
>> I really hoped I don't have to put "NicoHood" on top to make you realize
>> it's addressed to you. Please do it in favor for all Arch Linux packagers.
>>
> 
> What are you blaming me for now? This is a package everyone must install
> and you are telling me we have other serious problems? Sure we have, but
> compared to the time it takes to add an "s" to "http" this is a simple
> excuse. And this is not about checksums man, this is about https where
> even gpg signatures by git can be tricked.

Just as it is possible that a plane will fall into your house. The
existence of a way doesn't imply probability.

> And yes, I am doing stuff in the background. I wrote a guide and a tool
> that simplifies source code signing[1] and I am doing a detailed
> security analysis on all ArchLinux packages. And once it is ready I will
> request gpg signatures from every upstream source, especially packages
> from [core].

Great, you are pushing another personal project as something we should
glorify. Finish what you started first, instead of jumping between
multiple things, mostly accomplishing hostility towards you or anything
you propose. (Hint: nobody is taking you seriously anymore.)

> So you can tell me discussing about this is bullshit, right. But just
> not reacting to obvious security problems that can be solved within
> seconds is just not a single time better. Please do it in favor for all
> Arch Linux User's Security.
> 

At this point I'm ready to just put you on moderation list. Trying to
make you less oblivious is a waste of time.

B

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

[Bartłomiej Piotrowski]

On 2017-07-06 02:11, NicoHood wrote:
> On 07/05/2017 12:10 AM, Christian Hesse wrote:
>> 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.
>>
> 
> Systemd still does not use https sources. Regarding the recent
> discussion about tricking git about wrong tags and other evil stuff it
> is highly recommended to switch to https. Please do it in favor for all
> ArchLinux users security.
> 
> Once more the reference:
> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
> 

Regarding the recent discussion:

https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028919.html

I really hoped I don't have to put "NicoHood" on top to make you realize
it's addressed to you. Please do it in favor for all Arch Linux packagers.

Re: [arch-dev-public] Changing compilation flags

[Bartłomiej Piotrowski]

On 2017-07-05 11:36, Evangelos Foutras wrote:
> On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public
>  wrote:
>> Using -fno-plt would be a nice tiny little performance boost at runtime
>> but then it's important to make sure everything is compiled with -Wl,-
>> z,now and there might be programs ignoring LDFLAGS but respecting
>> CFLAGS. Ideally -z now would be the default in the linker first. If we
>> aren't going to patch the default, then I think a configure flag for
>> that needs to land upstream.
> 
> It's also worth noting that clang does not support the -fno-plt option
> and I couldn't find any discussions about adding support for it.
> 
> If it's only a tiny performance improvement, I strongly believe we
> should skip it for now.
> 

Repeating what I said on IRC.

First, it's easy to workaround - there is no magic about using bash
substitution and re-exporting CFLAGS in the environment.

Second, enabling PIE and SSP by default is already a breaking change
that we make an exception for clang. Apparently you can patch clang to
reflect this, but you can't make it ignore -fno-plt too?

This is not a huge change that will cause everything to fall apart, and
less than 40 packages need clang. I can live with having to change them.

Bartłomiej

Re: [arch-dev-public] [arch-general] Sébastien Luttringer and Tobias Powalowski

[Bartłomiej Piotrowski]

On 2017-07-03 09:25, Bartłomiej Piotrowski wrote:
> In case you haven't noticed, despite being told this many times, every
> time you can't resist being an alerted meerkat about checksums, you make
> people care less about whatever you have to say.
> 
> We DO have EVEN MORE SERIOUS issues, not only about SECURITY, that we
> are not doing because we are wasting time responding to you or
> fnodeuser. I really feel inclined to moderate your messages as well.
> 
> Want to do something useful? Start from fixing remaining community and
> multilib packages from the todo[1] we created because of you. But don't
> be surprised if maintainers will revert your changes or CRC in general.
> 
> Sometimes I wonder if you aren't making all of this noise on purpose so
> we stop caring about it completely.
> 
> [1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
> 

And just to be clear, I'm sending it here for purpose, because you're
apparently having problems to understand that you have been asked to
stop. Let's do that again, not as random user shitstorming on
arch-general, but the developer of distribution: cut it.

Bartłomiej



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] [arch-general] Sébastien Luttringer and Tobias Powalowski

[Bartłomiej Piotrowski]

In case you haven't noticed, despite being told this many times, every
time you can't resist being an alerted meerkat about checksums, you make
people care less about whatever you have to say.

We DO have EVEN MORE SERIOUS issues, not only about SECURITY, that we
are not doing because we are wasting time responding to you or
fnodeuser. I really feel inclined to moderate your messages as well.

Want to do something useful? Start from fixing remaining community and
multilib packages from the todo[1] we created because of you. But don't
be surprised if maintainers will revert your changes or CRC in general.

Sometimes I wonder if you aren't making all of this noise on purpose so
we stop caring about it completely.

[1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Changing compilation flags

[Bartłomiej Piotrowski]

On 2017-07-02 00:32, Allan McRae wrote:
> On 02/07/17 06:51, Bartłomiej Piotrowski wrote:
>> On 2017-06-30 23:44, Allan McRae wrote:
>>> On 30/06/17 19:07, Bartłomiej Piotrowski wrote:
>>>> On 2016-10-24 05:56, Allan McRae wrote:
>>>>> 1) building gcc to enable PIE by default
>>>>
>>>> I am in the middle of rebuilding gcc with --enable-default-pie. When it
>>>> finishes, I will start a todo for rebuilding packages with static 
>>>> libraries.
>>>>
>>>> I also enabled --enable-default-ssp, which means that
>>>> -fstack-protector-strong will be dropped from our CFLAGS (as it will be
>>>> enforced by gcc) on the next opportunity.
>>>>
>>>
>>> Are you adding full RELRO + no-plt at the same time?
>>>
>>> A
>>>
>>
>> Yes, and -fstack-check=specific too, although I might drop no-plt if it
>> will cause too many builders.
>>
> 
> I thought the conclusion from the Stack Clash bugs was that the current
> -fstack-check was fundamentally flawed and was being completely
> rewritten for the next gcc.  Is the "=specific" version OK?
> 

Packages described in Qualys' analysis weren't affected if compiled with
'specific'. It's probably not perfect either, but better that than
nothing at all.

Bartłomiej

Re: [arch-dev-public] Changing compilation flags

[Bartłomiej Piotrowski]

On 2017-06-30 23:44, Allan McRae wrote:
> On 30/06/17 19:07, Bartłomiej Piotrowski wrote:
>> On 2016-10-24 05:56, Allan McRae wrote:
>>> 1) building gcc to enable PIE by default
>>
>> I am in the middle of rebuilding gcc with --enable-default-pie. When it
>> finishes, I will start a todo for rebuilding packages with static libraries.
>>
>> I also enabled --enable-default-ssp, which means that
>> -fstack-protector-strong will be dropped from our CFLAGS (as it will be
>> enforced by gcc) on the next opportunity.
>>
> 
> Are you adding full RELRO + no-plt at the same time?
> 
> A
> 

Yes, and -fstack-check=specific too, although I might drop no-plt if it
will cause too many builders.

Bartłomiej

Re: [arch-dev-public] Changing compilation flags

[Bartłomiej Piotrowski]

On 2016-10-24 05:56, Allan McRae wrote:
> 1) building gcc to enable PIE by default

I am in the middle of rebuilding gcc with --enable-default-pie. When it
finishes, I will start a todo for rebuilding packages with static libraries.

I also enabled --enable-default-ssp, which means that
-fstack-protector-strong will be dropped from our CFLAGS (as it will be
enforced by gcc) on the next opportunity.

Bartłomiej



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Maintenance window for luna

[Bartłomiej Piotrowski]

On 2017-06-17 00:58, Bartłomiej Piotrowski wrote:
> Hi all,
> 
> tomorrow around 22:00 CET, the server that hosts forums, wiki and AUR
> will be offline for planned maintenance. The downtime will take up to 2
> hours; the plan is to reboot it into linux-hardened, then see if it is
> possible to switch from Percona to MariaDB (and if the mysterious crash
> from the past still happens, gather debug data for reporting it upstream).
> 
> Sorry for the inconvenience,
> Bartłomiej
> 

All websites should be up now.

We haven't switched back to MariaDB due to not-so-easy path from
MySQL/Percona 5.7. I know what I did wrong though, and we're slowly
migrating services running on luna to another server which runs MariaDB
already - it's going to happen anyway.

Bartłomiej

[arch-dev-public] Maintenance window for luna

[Bartłomiej Piotrowski]

Hi all,

tomorrow around 22:00 CET, the server that hosts forums, wiki and AUR
will be offline for planned maintenance. The downtime will take up to 2
hours; the plan is to reboot it into linux-hardened, then see if it is
possible to switch from Percona to MariaDB (and if the mysterious crash
from the past still happens, gather debug data for reporting it upstream).

Sorry for the inconvenience,
Bartłomiej

Re: [arch-dev-public] Moving dbus-c++ from [extra] to [community]

[Bartłomiej Piotrowski]

On 06/11/2017 02:12 PM, Bartłomiej Piotrowski wrote:
> On 06/11/2017 01:44 PM, Baptiste Jonglez wrote:
>> On Tue, Jun 06, 2017 at 10:49:29PM +0200, Baptiste Jonglez wrote:
>>> dbus-c++ [1] is orphaned, but needs some love to work with GCC 7.
>>> Currently, it does not build, and also prevents its reverse dependencies
>>> [2,3,4] from building.  Apparently, Fedora has patches to fix this [5].
>>>
>>> I would be happy to maintain dbus-c++, however it would first need to be
>>> moved to [community] (as well as libffado [2]).  Is this ok?
>>
>> Is this possible, and if so, who has the right to move the packages from
>> [extra] to [community]?
>>
>> If somebody else wants to adopt dbus-c++ and fix it, that's be fine too :)
>>
>> Thanks,
>> Baptiste
>>
>>
>>> [1] https://www.archlinux.org/packages/extra/x86_64/dbus-c++/
>>> [2] https://www.archlinux.org/packages/extra/x86_64/libffado/
>>> [3] https://www.archlinux.org/packages/community/x86_64/kimtoy/
>>> [4] https://aur.archlinux.org/packages/ring-daemon/
>>> [5] http://pkgs.fedoraproject.org/cgit/rpms/dbus-c++.git/log/?h=f26
> 
> I'll move it tomorrow (unless someone beats me to it). We should
> probably give up on the self-contained [extra] rule as it causes more
> problems than it solves.
> 
> Bartłomiej
> 

Done. Have fun fixing it.

Re: [arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]

[Bartłomiej Piotrowski]

On 06/06/2017 10:58 PM, Baptiste Jonglez wrote:
> Hi again,
> 
> Since a few years, I maintain a variant of the linux kernel in the AUR [1]
> that adds support for Multipath TCP [2].  The most recent version is based
> on linux 4.4, and the package I maintain tries to follow the "linux"
> package from [core] as much as possible.
> 
> There is no short- or medium-term perspective to merge Multipath TCP
> upstream, so I would like to bring this package to [community].  There are
> already several kernel variants in the official repos, but I would like to
> get some feedback before adding another one.
> 
> Thanks,
> Baptiste
> 
> [1] https://aur.archlinux.org/packages/linux-mptcp/
> [2] http://www.multipath-tcp.org/
> 

Just to add what has been said already.

The fact that there is no perspective of having multipath upstreamed is
the exact reason why we should not have it in repositories. It is a
niche that Arch does not target.

-ARCH and -lts kernels are self-explanatory. -hardened replaced the
grsecurity kernel and combines KSPP efforts with enormous Daniel's
knowledge (and there is more business to it that's out of scope for this
mailing list), -zen is desktop oriented and also maintained "upstream"
by heftig. This covers everything that the majority of our community
might want and I can't see what else could fit there.

Bartłomiej

Re: [arch-dev-public] ArchLinux on Github

[Bartłomiej Piotrowski]

On 06/05/2017 03:27 PM, NicoHood wrote:
> Hi,
> we have an organization on Github:
> https://github.com/archlinux
> 
> Would it be possible to add my account (NicoHood) also to this
> organization? This would help other users to identify that i am also an
> ArchLinux TU Member.
> 
> Cheers,
> Nico
> 

The group has been more or less informal so far. I am slightly hesitant
to adding someone on the merit of proving someone is a TU. First, our
website and >3 master keys signature on your GPG key is already a proof.
Second, if you can't convince someone with substantive arguments, you
won't do that either by appealing to any membership.

But these are just my 5 cents, don't consider this as definitive no.

Bartłomiej

Re: [arch-dev-public] Arch Linux Container and Boxes

[Bartłomiej Piotrowski]

On 2017-06-01 18:12, Christian Rebischke wrote:
> On Wed, May 31, 2017 at 07:48:58PM +0200, Bartłomiej Piotrowski wrote:
>> On 2017-05-31 16:08, Christian Rebischke wrote:
>>> There is a dependency cycle, thats why systemd got pulled in.
>>> I got already some feedback to the container and the image and I am
>>> pretty sure we can reduce the size of the container a little bit more.
>>> Currently the docker container is 152mb big in compressed state and
>>> around 425mb or something uncompressed.
>>
>> I don't see a cycle here…
>>
> 
> Here is the cycle that I mean:
> 
> This are the first lines of output of `make docker-push`:
> 
> pacstrap -C /usr/share/devtools/pacman-extra.conf -c -d -G -M 
> /tmp/tmp.eKptMyKU0t diffutils gettext grep inetutils iproute2 iputils pacman 
> procps-ng psmisc sed tar util-linux which gzip
> ==> Creating install root at /tmp/tmp.eKptMyKU0t
> ==> Installing packages to /tmp/tmp.eKptMyKU0t
> :: Synchronizing package databases...
> ---> snip <---
> resolving dependencies...
> looking for conflicting packages...
> warning: dependency cycle detected:
> warning: systemd will be installed before its iptables dependency
> 
> This dependency cycle is pulling in 96 more packages including systemd.
> 
> 

Except removing it or not doesn't have much to do with this. Systemd is
completely pointless in a container, especially for Docker. As pactree
-r shows:

  iptables
  ├─iproute2
  └─systemd
└─libusb
  └─libpcap
└─iptables

So the problem is that iproute2 requires iptables. Personally I don't
see a use case for any of them in single-process containers, but I guess
it would be just faster to disable iptables support in iproute2.

Bartłomiej

Re: [arch-dev-public] Arch Linux Container and Boxes

[Bartłomiej Piotrowski]

On 2017-05-31 16:08, Christian Rebischke wrote:
> There is a dependency cycle, thats why systemd got pulled in.
> I got already some feedback to the container and the image and I am
> pretty sure we can reduce the size of the container a little bit more.
> Currently the docker container is 152mb big in compressed state and
> around 425mb or something uncompressed.

I don't see a cycle here…

> I would also like to have a second container repository with a container
> that has base and base-devel, for stuff like jenkins etc.
> 
>> Given yours and Pierre's involvement, it can already be considered official.
> 
> Ok I didn't know it's that easy

Just make sure to move the repo to git.archlinux.org and our GitHub
organization.

Re: [arch-dev-public] Arch Linux Container and Boxes

[Bartłomiej Piotrowski]

On 2017-05-31 01:05, Christian Rebischke wrote:
> Hello everybody,
> I am pleased to announce that pierre and me founded the 'Archlinux'
> Organisation on hub.docker.com and pierre pushed his awesome docker
> container to this repository. (Big thanks to pierre!). [1][2]

Can we give more people from the devops team admin access there? We
already have too many places that only 1 or 2 of us can access.

> His docker container is a huge improvement to the other docker
> containers in the hub. Most of them are insecure, ship private keys
> within the container or ship more applications as needed.

Any reason systemd is there? Recursive removal cuts off 30MB. The fact
that libldap depends on e2fsprogs also seems wrong. I know, "patches
welcome".

> Can we make this project official? Or do we even want to make this
> official? I would like to start a discussion with this questions.

Given yours and Pierre's involvement, it can already be considered official.

> In case of yes, I would like to have pierre and my project on
> projects.archlinux.org and would like to found the channel
> #archlinux-boxes on freenode.

Does it really needs a separate channel? Don't we have
#archlinux-projects for that?

Bartłomiej

Re: [arch-dev-public] Improving overall experience for contributors

[Bartłomiej Piotrowski]

On 2017-05-23 22:47, Gaetan Bisson wrote:
> In my opinion writing emails to strangers should be part of the
> application process. In my duties as packager maintainer I often find
> myself writing emails to various persons I've never met: other distro
> devs, upstream maintainers, etc. I'm sure the same goes for all of us.
> It's just basic communication skills.

I see a difference between writing emails on a specific topic, whether I
know the person I write to or not, and spamming people "sup sponsor me"
in hope of finding a sponsor. This is hardly basic. I have sponsored at
least 3 TUs and it was me who initiated the sponsorship; I wouldn't be
here either if I didn't know Mateusz Herych from Polish community
channel. I highly doubt anyone else would sponsor me.

We are open source distribution with pretty much closed development
model. It is unsustainable in the longer term. There are 413 orphan
packages in our repositories (excluding i686), some of the out-of-date
flags are unhandled since 2014. We updated archweb to the latest-1 LTS
Django only recently, the fact that our bug tracker hasn't been pwned
yet is a miracle and nothing but the wiki displays properly on
smartphones. Signoffs got a second breath thanks to recruiting some
testers, but there is no written procedure how to become one. We handle
PKGBUILD patches in the worst way possible - we just don't. It's not
even remotely hard to come up with examples.

How long do you expect people to be happy to send their changes to
/dev/null before they give up? Because I already met some people that
are more clever than me in every packaging related area that decided to
switch to a distribution where joining is easier.

> I don't understand what you mean. In the past when we've had specific
> needs in particular areas, ad-hoc recruitment processes were devised to
> fill those needs. Shouldn't that be good enough? What kind of new
> process would you like to see implemented?

We are at the point where we have needs in every area, and ad-hoc
recruitment is silly idea in 2017, where some distributions are
successfully having way smaller development team and are capable of
accepting tens of one-off contributions every week (been there, done
that). I do not propose to give up on sponsorship process entirely, I
mean that we need a place to communicate with contributors and that also
includes mentoring potential packagers.

Bartłomiej

[arch-dev-public] Improving overall experience for contributors

[Bartłomiej Piotrowski]

Hi all,

Spending some time outside the regular Arch circles, I realized that the
way we "outreach" potential contributors is at least imperfect.

One of the problems I keep hearing about is that there is no clear place
where potential contributors could start. Sure, some things seem obvious
to us: take care of some wiki article or adopt orphan AUR packages. It
isn't actually that easy. Not everyone is interested in editing or
maintaining random packages, and while there is plenty to do, how
someone new could know it? We could use help not only with existing
projects like archweb, pyalpm or namcap, but also with development of
new code (for example a maintainable rebuild automation) and
infrastructure side (which is in fact too generic term that could be
better described). I am totally in love with What can I do for
Mozilla?[1] which is open source, so why not steal this wonderful idea?
But it also means we need a way to communicate with people interested in
helping us: at least an IRC channel and new mailing list.

Another thing that I heard in last few months isthat it is actually hard
for potential TU candidates to find a sponsor. While I believe it is
perfectly fine to e-mail few potential sponsors to ask for opinion,
throwing random messages at people doesn't sound really appealing.
In my humble opinion, we should rethink the way we recruit people
and probably introduce fine-grained permissions to dbscripts that
would allow to limit new maintainers to limited set of packages.  We
should also lower our expectations towards candidates. At least once
we rejected one for some stupid reason (no fingerpointing here, I'm
not saint either), leaving packages they wanted to adopt virtually
orphan. It's better to help amn inexperienced packager gain
experience than voting no, really; to be brutally honest, quite a
lot of packaging work we are handling doesn't have much in common with
rocket science.

I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we
will tackle it another time.

Your thoughts?
Bartłomiej

[1] https://whatcanidoformozilla.org/



signature.asc
Description: OpenPGP digital signature

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

[Bartłomiej Piotrowski]

On 2017-05-23 12:59, Christian Hesse wrote:
> 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?

None from my side. I guess that SONAME field will be different from the
one provided by the latest MySQL/Percona?

> Additionally I will remove the provide for `libmysqlclient`, which is a
> leftover from when we switched away from Oracle MySQL back in 2013.

+1

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

That's just 45 packages, but it's up to Evangelos.

Bartłomiej



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] New master key

[Bartłomiej Piotrowski]

Hi all,

Due to many overdue signing requests, we have created a new master key.
The key is listed in archweb and will be included in the next
archlinux-keyring update.

DDB8 67B9 2AA7 89C1 65EE  FA79 9B72 9B06 A680 C281
Bartłomiej Piotrowski (Arch Linux Master Key)
<bpiotrow...@master-key.archlinux.org>

The key is signed with my personal one for verification. I will start
verifying packagers' keys soon.

Bartłomiej



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] OpenSSL 1.0 - take 3

[Bartłomiej Piotrowski]

On 2017-05-16 16:21, j...@jgc.homeip.net wrote:
> Since moving on to OpenSSL 1.1 and introducing a compatibility package
> openssl-1.0 (which isn't compatible), we still have FS#53836 [1] open.
> 
>  
> 
> I want to propose another openssl-1.0 rebuild that restores binary
> compatibility with non-free software and Debian Jessie (jessie-backports) by
> packaging OpenSSL 1.0.2 with 1.0.0 soname and 1.0.0 versioned symbols.
> 
> At this moment I don't care about an openssl-1.0.2 package that ships
> libssl.so.1.0.2 like Debian does in unstable/testing at the moment, when
> non-free software catches up with that we can introduce such a package
> later.
> 
>  
> 
> Any objections? If not, let's make a new rebuild list and fix this.
> 

Absolutely no objections from me, I'm more than happy to rebuild some.

Bartłomiej

Re: [arch-dev-public] [DRAFT] Deprecation of the ABS tool and rsync server

[Bartłomiej Piotrowski]

On 2017-05-09 11:59, Bartłomiej Piotrowski wrote:
> On 2017-05-09 11:36, Florian Pritz via arch-dev-public wrote:
>> On 09.05.2017 11:08, Bartłomiej Piotrowski wrote:
>>> There we go. Far from perfect, happy to hear suggestions from spirits of
>>> poetry.
>>>
>>> ---
>>>
>>
>> I'm not a poet, but let's try.
>>
>> Also I'm not entirely sure if there is only one rsync endpoint. When
>> running `rsync rsync://rsync.archlinux.org` I see core, extra,
>> community, .., *svn endpoints. Maybe those need cleanup too.
>>
> Yeah, sounds better, thanks. Looking at rsyncd.conf, core/extra/etc are
> exposing packages, {community,packages}svn allow IP that doesn't point
> to any server we use currently so I will just drop these them.
> 

I'm going to publish Florian's version tomorrow around the lunch.

Re: [arch-dev-public] Test repository with gcc7

[Bartłomiej Piotrowski]

On 2017-05-10 20:19, Bartłomiej Piotrowski wrote:
> I found some time today to make a test build of the latest GCC. I tested
> some "simple" projects like nginx and libtorrent-rasterbar and they do
> build, while MariaDB fails on linking for me.
> 
> Let me know if you encounter any problems, I'd rather not break too much
> by pushing it to repos.
> 
> [gcc7]
> SigLevel = Required
> Server = https://pkgbuild.com/~bpiotrowski/gcc7
> 
> No i686, embrace the future!
> 
> Bartłomiej
> 

Definitely there are issues with C++ projects, but I won't have time for
that until the weekend.

Bartłomiej

[arch-dev-public] Test repository with gcc7

[Bartłomiej Piotrowski]

I found some time today to make a test build of the latest GCC. I tested
some "simple" projects like nginx and libtorrent-rasterbar and they do
build, while MariaDB fails on linking for me.

Let me know if you encounter any problems, I'd rather not break too much
by pushing it to repos.

[gcc7]
SigLevel = Required
Server = https://pkgbuild.com/~bpiotrowski/gcc7

No i686, embrace the future!

Bartłomiej



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] [DRAFT] Deprecation of the ABS tool and rsync server

[Bartłomiej Piotrowski]

On 2017-05-10 04:27, Pablo Roberto Lezaeta Reyes via arch-general wrote:
> You should clarify if this affect user cloning the servers repos by
> rsync to set they non-tiered local repos (*.pkg.tag.xzs) or just the
> pkgbuilds repo clones (PKGBUILDs).
That's better phrased in Florian's revision, but both mention PKGBUILDs,
so I'm not sure if there is anything more to explain.

> Also mention devtools still depend on subversion despite you mention
> that for cloning one should use git, that intentional or
> inconsistenty?
devtools depending on svn has nothing to do with ABS; the paragraph you
refer to describes methods of obtaining full PKGBUILDs tree.

Bartłomiej



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] [DRAFT] Deprecation of the ABS tool and rsync server

[Bartłomiej Piotrowski]

On 2017-05-09 11:36, Florian Pritz via arch-dev-public wrote:
> On 09.05.2017 11:08, Bartłomiej Piotrowski wrote:
>> There we go. Far from perfect, happy to hear suggestions from spirits of
>> poetry.
>>
>> ---
>>
>
> I'm not a poet, but let's try.
>
> Also I'm not entirely sure if there is only one rsync endpoint. When
> running `rsync rsync://rsync.archlinux.org` I see core, extra,
> community, .., *svn endpoints. Maybe those need cleanup too.
>
Yeah, sounds better, thanks. Looking at rsyncd.conf, core/extra/etc are
exposing packages, {community,packages}svn allow IP that doesn't point
to any server we use currently so I will just drop these them.

[arch-dev-public] [DRAFT] Deprecation of the ABS tool and rsync server

[Bartłomiej Piotrowski]

There we go. Far from perfect, happy to hear suggestions from spirits of
poetry.

---

Due to high maintenance costs of rsync server and scripts related to
Arch Build System, we have decided to deprecate the `abs` tool and rsync
as endorsed way of obtaining PKGBUILDs tree.

The `asp` tool, available in [extra], provides similar functionality to
`abs`.  `asp export pkgname` can be used as direct alternative; more
information about usage can be found in [its documentation][asp].
Additionally Subversion sparse checkouts, as described [here][svn], can
be used to achieve similar effect.  For fetching all PKGBUILDs, the best
way is cloning [svntogit][git] mirrors.

While `extra/abs` package has been already dropped, rsync endpoint will
be disabled by the end of the month.

[asp]: https://github.com/falconindy/asp/blob/master/man/asp.1.txt
[svn]: https://www.archlinux.org/svn/
[git]: https://git.archlinux.org/svntogit/



signature.asc
Description: OpenPGP digital signature

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

[Bartłomiej Piotrowski]

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