Re: [arch-dev-public] Speaking of OCaml: willing to orphan merlin + deps

[Bruno Pagani via arch-dev-public]

Le 18/08/2019 à 08:16, Jürgen Hötzel a écrit :
> Hi,
>
> Bruno Pagani via arch-dev-public writes:
>
>> orphan merlin (OCaml smart auto-completion for emacs/vim) and its
>> dependency tree as I’m no longer using any of those and don’t expect to
>> use them again:
>>
>> – cppo
>> – dune
> 
>
> I'd take maintainership of dune. More and more OCaml projects switch from
> ocamlbuild and other legacy build system to dune:
> It is very likely that in the future all important OCaml-based
> applications will (make)depend on it.

OK great, just adopt it in ArchWeb then. ;) Also please be aware that
upstream almost always retag releases (their process is tagging, trying
to upload to opam, fix issues, retag and so on until it works), so you
should wait for new releases to appear in opam and not just for them to
be tagged as such in GitHub (for instance, 1.11.0 was tagged three
times, first on 18/07/2019 at 08:02 UTC, last on 22/07/2019 at 17:16 UTC).

>> – menhir
>> – merlin
>> – ocaml-biniou
>> – ocaml-easy-format
>> – ocaml-yojson
> +1
>
> OCaml developers will have a better experience using the standard OCaml
> package manager "opam" anyway (I'm using merlin-lsp via "opam pin"
> instead of merlin).

OK, then I will just plainly remove them, and if someone think they can
still be useful outside of opam, they are free to re-upload them to the AUR.

Regards,
Bruno

[arch-dev-public] Speaking of OCaml: willing to orphan merlin + deps

[Bruno Pagani via arch-dev-public]

Hi there,

I’m riding on the train of OCaml e-mails to announce that I’m going to
orphan merlin (OCaml smart auto-completion for emacs/vim) and its
dependency tree as I’m no longer using any of those and don’t expect to
use them again:

– cppo
– dune
– menhir
– merlin
– ocaml-biniou
– ocaml-easy-format
– ocaml-yojson

Note that merlin was recently upgraded to 3.3.2 by Jürgen (thanks for
that), but rather than using Opam the new dependency should be added to
the repo if someone is willing to maintain this stack. I had started
with menhir, but some other were required IIRC.

Please let me know if you are interested, adopt them and I’ll disown
right after. Else, I’ll drop all of them to the AUR in ~1 week.

Regards,
Bruno/Archange

Re: [arch-dev-public] Create guidelines regarding SIMD instructions/x86 extensions

[Bruno Pagani via arch-dev-public]

Le 25/05/2019 à 13:27, Allan McRae via arch-dev-public a écrit :
> On 25/5/19 9:19 pm, Bruno Pagani via arch-dev-public wrote:
>> Hi,
>>
>> Le 25/05/2019 à 02:17, Filipe Laíns via arch-dev-public a écrit :
>>> I would also like to explore the idea of adding an "high performance"
>>> architecture which would be able to make use of SSE{,2,3,4,4.1,4.2} and
>>> AVX, which seem to be the standard for newer processors (>=2013). This
>>> would only be available for packages that do high performance computing
>>> (ex. openblas, sdrangel, etc.). Any thoughts on this?
>> As said on IRC, they have been discussions before on having multiple
>> targets and corresponding repos, but the starting point is that we need
>> automated build before going into such a direction, and this in turn has
>> several requirements. I’ve linked to you the pad where we put our ideas
>> together regarding this.
>>
>> In the meantime, we had the case before of whether we should package
>> e.g. $pkgname-{sse4,avx} in a case where it mattered a lot, but it
>> turned out the software in question (embree) is able to do runtime
>> detection of available ISA. Maybe some other packages are doing this
>> too, else we could discuss whether allowing such flavours as a temporary
>> measure would be acceptable for selected packages.
> glibc detects available instruction sets and uses the best for many
> functions.

Great!

> I'd be very, very, very much against providing multiple variants of a
> package in our repos.  Using asp and makepkg are is a hard solution for
> those who really need a few packages rebuilt.

I’m fine with that possibility too.

> PS - I rebuilt [core] with -march=haswell recently as a test.  Automated
> building is not an issue.  Unattended package/database signing is the
> major stumbling block.

Yes, in our discussions it boiled down to “Automated rebuilds” →
“Unattented signing” → “Reproducible builds”.

Out of curiosity, what did you rebuild of [core] lead to?

Bruno




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Create guidelines regarding SIMD instructions/x86 extensions

[Bruno Pagani via arch-dev-public]

Hi,

Le 25/05/2019 à 02:17, Filipe Laíns via arch-dev-public a écrit :
> I would also like to explore the idea of adding an "high performance"
> architecture which would be able to make use of SSE{,2,3,4,4.1,4.2} and
> AVX, which seem to be the standard for newer processors (>=2013). This
> would only be available for packages that do high performance computing
> (ex. openblas, sdrangel, etc.). Any thoughts on this?

As said on IRC, they have been discussions before on having multiple
targets and corresponding repos, but the starting point is that we need
automated build before going into such a direction, and this in turn has
several requirements. I’ve linked to you the pad where we put our ideas
together regarding this.

In the meantime, we had the case before of whether we should package
e.g. $pkgname-{sse4,avx} in a case where it mattered a lot, but it
turned out the software in question (embree) is able to do runtime
detection of available ISA. Maybe some other packages are doing this
too, else we could discuss whether allowing such flavours as a temporary
measure would be acceptable for selected packages.

Regards,
Bruno





signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 17/03/2019 à 23:13, Gaetan Bisson via arch-dev-public a écrit :
> [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.

Well, people on IRC advised me to do the exact opposite of what you said
(a.k.a. starting a new thread with a TL;DR of the previous one), so…

> For my
> part, I thought we had reached consensus with Allan's message:
>
>   
> 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.

I was satisfied with the consensus we reached, but when I asked on IRC
how I should revive the thread so that we move on with that proposal to
an actual implementation, I faced concerns about this proposal from
several persons. The conclusion of our discussions was that we
apparently didn’t even agree on the premises, so that the discussion
should restart at a more fundamental level.

>> From this discussion and parallel ones that happened on IRC,
> Not everyone is awake all the time, which is why decisions are made on
> this very list, not on IRC. New arguments should have been posted to the
> previous thread.

And I hope they will, since I was asked to resend a new e-mail with the
base line-up of the matter at hand.

>> Before going further on any proposal in those directions, I’ve thought
>> it surely requires more input, and not only from the ~10 people at most
>> that already participated in those discussions
> It's probably safe to guess that people who haven't participated so far
> just aren't interesting in participating. Besides, I think you'd have
> more feedback and clear answers to a concrete proposal.

I actually thought the same, but that was before I got more feedback on
IRC (of either people that missed the thread, or had their concerns
unadressed because not understood by others in the way they were meant
to be expressed for instance). I’ll let this thread in this way for some
days on move-on with a concrete proposal depending on the output.

People seem concerned about implicit dependencies at all, and also
wonder about group vs metapackage. All of this is related, for instance
we don’t need a metapackage if we go the no implicit deps way, and I
don’t really care either about the content of the base-whatever in this
case.

In my case, I don’t have strong opinions about implicit deps from a
reasonably small metapackage (i.e. previous proposal) or no implicit
deps at all (someone else proposal), but I’m strongly against transitive
deps in any case. So I’m not decided yet on which proposal to push
forward on.

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Hi there,

This is a follow-up on the last month discussion about a “minimal base
system”.

# Reminder of the starting statement

> There is no strict definition of what a minimal Arch Linux system
installation must contain. However in reality we mostly don’t add any
packages that are in the base group as a dependency to other packages,
which basically makes it a hard requirement.

The corollary being that, since we don’t actually enforce `base` as a
policy, some breakage might (and does) happen when people remove part of
it from their system.

Following on that, the discussion was about implementing a metapackage
with a stricter set of packages to be required as installed on any Arch
system, and whether or not to keep the `base` group in addition. From
this discussion and parallel ones that happened on IRC, I can summarize
three important questions (that are, notice, actually independent of the
exact content of base-whatever):

1. There is a disagreement on the `base` group purpose: should it just
be a convenient helper to bootstrap an Arch system quickly and/or also
be used as a set of assumed installed dependencies?

2. Are people actually wanting to be able to assume some installed
dependencies at all, and if so, what are they argument(s) for not
listing some, e.g. `glibc`? I haven’t seen many apart from “don’t want
to list tons of dependency in my PKGBUILD” or “no sane system wouldn’t
have it”, and we can discuss whether those are valid one or not, but
since the discussion wasn’t happening on that point particularly, there
may also be some others that have escaped me.

3. Although it could seems not deeply related at first, what about
transitive dependencies (e.g. package A depending on B and C, but only
listing B because this one already depends on C)? Here again, breakage
happens because of this (when B stop depending on C, which A maintainer
cannot be reasonably expected to track), and I’ve only heard “don’t want
to list tons of dependency in my PKGBUILD”.

Before going further on any proposal in those directions, I’ve thought
it surely requires more input, and not only from the ~10 people at most
that already participated in those discussions (but still should,
because points have changed a bit) since we are discussing distro-wide
policy on dependencies here.

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 12/02/2019 à 19:16, Gaetan Bisson a écrit :
> [2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
>> Just in case it wasn’t clear, my answer would have been mostly the same
>> as Eli’s.
>>
>> So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do
>> you have further comments/questions regarding this, does the existence
>> of the base group alongside the arch/minimal-system now makes sense or
>> would you still prefer to go without it?
> Allan and I have both stated that we don't want to introduce a new group
> since we believe it would be highly redundant with base.
>
> Nothing new has been said since our last messages except Eli's post
> which argues that the base group is largely inadequate in its current
> state. This further supports our proposal that base should be improved
> instead of introducing a new group.
>
> So I really don't see what arguments could have changed our minds...
> It's also strange to me how you can concur with Eli's post without
> agreeing with our conclusions.

We did not read Eli the same way apparently. To me, Eli was answering
what should be in the base group but not in the arch/minimal-system
metapackage. And then I agree with what he listed. So my question is:
given what we propose for the minimal metapackage (see below) and what
Eli listed as being useful in a base group when seeing this one as a
convenient helper, do you still think that keeping the base group is
problematic? If so, then I propose we just move on with removing the
base group and implementing the metapackage, I care much more for
getting this one set up than for keeping base.

> To go forward I suggest you propose a clear definition of the perfect
> "minimal system" group you'd want to have, along with a proposed list of
> packages.

The list is available in the very first post (by Levente) of this thread. ;)

> When consensus is reached, we adopt this list of packages for
> base and put this definition on the wiki.

As later clarified by Levente, not for base, but for a new metapackage
with a different name to avoid confusion (whether we keep the base group
or not I think).

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 06/02/2019 à 00:26, Eli Schwartz via arch-dev-public a écrit :
> On 2/5/19 4:31 PM, Gaetan Bisson via arch-dev-public wrote:
>> Bruno,
>>
>> We all seem to agree that [base] plays no satisfactory role in its
>> current state, so I think Allan definitely has a point: let us first
>> turn [base] into something useful, and only then wonder if we need
>> something more.
>>
>>
>> [2019-02-05 14:38:26 +0100] Bruno Pagani via arch-dev-public:
>>> Le 05/02/2019 à 12:54, Allan McRae a écrit :
>>>> If someone knows they want to set up logical volumes and drive
>>>> encryption, then they know enough to install lvm and cryptsetup.  Same
>>>> with jfsutils, xfsutils.   So I don't think they should be in the base
>>>> group (e.g. I would not call jfsutils a standard tool).
>>> Maybe. As I said in my answer to Bartłomiej, I don’t know if beginners
>>> know enough things to install what they need beyond the minimum system,
>>> or if they just read the wiki about doing this or that, which might
>>> assume they have the current base group installed.
>> Then the wiki should just be updated to say: "first, install jfsutils."
>> It's up to the wiki to document the project, not up to the project to
>> follow the wiki's rule.
>>
>>>> If we remove the excess from base, then we are down to a very small
>>>> difference between that and archlinux-system.  Only e2fsprogs, man, and
>>>> an editor different?
>>>>
>>>> So I see the proposed archlinux-system group being essentially what base
>>>> should be.
>>> That is because you see base as the minimal system.
>>> So I’ll turn this
>>> differently: do you have objections against having, outside of the
>>> minimal meta-package described in our proposal, a packages group of
>>> “relatively standard” tools, that is purposed at beginner wanting to
>>> have only one simple pacstrap command to issue in order to get started?
>> Yes because those two things seem the same to me. Or at any rate their
>> difference is too small to be worth the distinction. Perhaps I'm not
>> understanding what exact roles you envision for [base] and [minimal-
>> system]; it would help to know exactly what packages you would put in
>> the former and not the latter. Allan suggested e2fsprogs, man, and vim.
>> We can certainly agree that three is too few to warrant creating two
>> distinct groups.
> less, because I cannot imagine an interactive console without a pager
>
> texinfo, for the same reason one would want man-db. (Also, GNU tools
> tend to have terrible manpages, so you kind of need texinfo even if you
> just pipe it to less).
>
> man-pages, to get a good starting collection of things to use man-db to
> read (section 3, 4, 5, 7, and 1p will be quite bare otherwise).
>
> systemd-sysvcompat to simplify the kernel command line.
>
>
> s-nail, because some people apparently assume a complete system should
> include the "mail" binary for completeness' sake.
>
> dhcpcd and netctl, commonly used for networking by people who don't
> understand the glories of NetworkManager. (Also the archiso.)
>
> which, because too many things on the internet recommend using it to
> find out whether/where a program is installed, and muscle memory
> therefore means people will instinctively try that instead of using
> command -v/type -a
>
> ...
>
> In fact, most of the base group, with the grievous exception of:
>
> - jfsutils/reiserfsprogs/xfsprogs which assume quite odd things about
>   non-default and usually exotic filesystems, and
>
> - lvm2/mdadm which offend my soul due to things like
>   https://bugs.archlinux.org/task/61040 screwing up the system even for
>   people who will never touch lvm
>
> are reasonable things to suggest to people by default. It is simply that
> there is also a lot of those, which people rightly don't want to be
> *forced* to install. I don't want or use which, nano, vi, or mailx for
> example. Does that mean most people won't? I venture to say more users
> than not, will feel grateful for a group that recommends at least the
> first three to them.
>
> It is just that the utility of the base group as a recommendation is
> hindered by lack of something to define the minimum.
>
> ...
>
> We already have more than a few sets of packages that are defined by
> both a group and a metapackage for user convenience, e.g.
> https://wiki.archlinux.org/index.php/KDE#Installation
>
> So if it was really super inefficient to have both base and base-system
> then we could clean up lots of o

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

[Bruno Pagani via arch-dev-public]

Le 05/02/2019 à 12:54, Allan McRae a écrit :
> On 5/2/19 9:06 pm, Bruno Pagani wrote:
>> Le 22/01/2019 à 00:59, Allan McRae a écrit :
>>> On 22/1/19 9:41 am, Bruno Pagani wrote:
 Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
> 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
 In the proposal, base would really just be a convenient helper for e.g.
 beginners installing their system, so they could get all tools that are
 often used during install (e.g. cryptsetup, lvm2, various FS/network
 tools, etc.) or (POSIX) tools people coming from other distros would
 expect to be here by default (man pages, nano/vi…) but that are
 interactive ones and thus not really required for operating.

 Anyone knowing their stuff could just install base-system + what they
 actually need (e.g., I would install cryptsetup and vim, and not care
 about netctl, xfsprogs or lvm2).
>>> "Anyone knowing their stuff" is the essentially the stated Arch target
>>> audience.
>> So apparently we did not answer all concerns here. I don’t expect Arch
>> users to know thing so well that they know exactly what tools are in
>> which packages when they install Arch for the first time. I think we
>> should not mistake Arch Power Users, people that have a level of
>> knowledge above Arch Users, that are just generic Linux Power Users.
>>
>>> So, the definitions of the sets of packages are:
>>>
>>> base-system - essential packages we assume everyone has installed
>>> (previous definition of base...)
>> To be clearer, the new proposition would be to call this arch-system to
>> avoid confusion with base. However, note that this “previous definition
>> of base” is definitively not that clear: when I installed Arch, I read
>> things as “base is a convenient helper to get almost every standard
>> tools you could need to do your install”.
>>
>>> base group - base-system plus other packages some people probably
>>> want/expect and support packages for filesystem types most people don't
>>> actually need.
>> For me, base will be what it has ever been: a fast way to get started as
>> an Arch beginner.
>>> Maybe slightly facetious on that last one, but I don't see a clear need
>>> for the base group once base-system exists.
>> Because, as an Arch dev, you definitively qualify as an Arch Power
>> Users. I wouldn’t use base either for myself, but I firmly believe most
>> Arch beginners would.
>>
>> Does that make sense to you, or do you still think every new Arch User
>> should already know exactly what is required to get started?
>>
> If someone knows they want to set up logical volumes and drive
> encryption, then they know enough to install lvm and cryptsetup.  Same
> with jfsutils, xfsutils.   So I don't think they should be in the base
> group (e.g. I would not call jfsutils a standard tool).

Maybe. As I said in my answer to Bartłomiej, I don’t know if beginners
know enough things to install what they need beyond the minimum system,
or if they just read the wiki about doing this or that, which might
assume they have the current base group installed.

> If we remove the excess from base, then we are down to a very small
> difference between that and archlinux-system.  Only e2fsprogs, man, and
> an editor different?
>
> So I see the proposed archlinux-system group being essentially what base
> should be.

That is because you see base as the minimal system. So I’ll turn this
differently: do you have objections against having, outside of the
minimal meta-package described in our proposal, a packages group of
“relatively standard” tools, that is purposed at beginner wanting to
have only one simple pacstrap command to issue in order to get started?

Or put it yet another way: outside of this base group, does our 

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

[Bruno Pagani via arch-dev-public]

Le 22/01/2019 à 14:44, Bartłomiej Piotrowski via arch-dev-public a écrit :
> 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.

So they are two aspect to that:

1. From a technical point of view, a group is less convenient than a
metapackage if we ever intend to modify the list. So just trimming down
the base group wouldn’t do it.

2. Regarding what is more likely the real content of your message, they
are already some people that never considered the base group as what
must be installed (especially since a group cannot enforce that
conveniently because of 1), but as a convenient helper for Arch
beginners doing their first install. I, like other, still think the base
group could keep this value, while the base-system/arch-system package
would fill the role other people intended for base, but in better ways.

I, at a personal level, don’t care about a base group that I wouldn’t
use at all (just like you or likely any other Arch staff for that
regard). But I have to think on a larger scope, and if having this
package helps new users getting started with Arch, then I think it’s
worth having it. Not because I want Arch to be used by the largest
number of people, but because I believe that some of those people will
be tomorrow TUs and devs, after becoming more acquainted with Linux and
Arch internals thanks to their use of a distro that try to teach them
about all this.

Would the absence of a base group be a too high barrier for some? I
don’t know. Maybe not, especially since our wiki is amazing and maybe
most installation cases requiring a non base-system/arch-system tool
that are currently in base already tells to install this tool. Or maybe
not, because those wiki page currently assume that people either have
base installed, or know exactly what they are doing?

Now my question to both you and Allan (or other that might have the same
concern): you seem to agree with our base-system/arch-system proposal,
but are wondering about the current base group. Would you actually be
bothered by the existence of this group in addition of the
*-system/minimal/whatever metapackage and if so why (for instance Gaetan
had a relevant concern about the naming, hence the idea or
arch-system/minimal —renaming the base group could be doable to though,
but would require more work), or is it just that you don’t see a point
in keeping it, so why not remove it altogether?

In any case, I hope we can address your concerns and move forward with
this proposal.

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 22/01/2019 à 00:59, Allan McRae a écrit :
> On 22/1/19 9:41 am, Bruno Pagani wrote:
>> Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
>>> 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
>> In the proposal, base would really just be a convenient helper for e.g.
>> beginners installing their system, so they could get all tools that are
>> often used during install (e.g. cryptsetup, lvm2, various FS/network
>> tools, etc.) or (POSIX) tools people coming from other distros would
>> expect to be here by default (man pages, nano/vi…) but that are
>> interactive ones and thus not really required for operating.
>>
>> Anyone knowing their stuff could just install base-system + what they
>> actually need (e.g., I would install cryptsetup and vim, and not care
>> about netctl, xfsprogs or lvm2).
> "Anyone knowing their stuff" is the essentially the stated Arch target
> audience.

So apparently we did not answer all concerns here. I don’t expect Arch
users to know thing so well that they know exactly what tools are in
which packages when they install Arch for the first time. I think we
should not mistake Arch Power Users, people that have a level of
knowledge above Arch Users, that are just generic Linux Power Users.

> So, the definitions of the sets of packages are:
>
> base-system - essential packages we assume everyone has installed
> (previous definition of base...)

To be clearer, the new proposition would be to call this arch-system to
avoid confusion with base. However, note that this “previous definition
of base” is definitively not that clear: when I installed Arch, I read
things as “base is a convenient helper to get almost every standard
tools you could need to do your install”.

> base group - base-system plus other packages some people probably
> want/expect and support packages for filesystem types most people don't
> actually need.
For me, base will be what it has ever been: a fast way to get started as
an Arch beginner.
> Maybe slightly facetious on that last one, but I don't see a clear need
> for the base group once base-system exists.

Because, as an Arch dev, you definitively qualify as an Arch Power
Users. I wouldn’t use base either for myself, but I firmly believe most
Arch beginners would.

Does that make sense to you, or do you still think every new Arch User
should already know exactly what is required to get started?

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 22/01/2019 à 03:25, Gaetan Bisson via arch-dev-public a écrit :
> [2019-01-21 18:58:54 -0500] Eli Schwartz via arch-dev-public:
>> On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote:
>>> I agree with this package list. It's missing mkinitcpio though.
>> No it is not, mkinitcpio is definitively not needed.
>>
>> It's only required in order to execute the pacman hooks for a linux
>> kernel package (or do so manually). And core/linux is not required to
>> use archlinux, although it is required to boot it on bare metal.
>>
>> The most recent version of my PKGBUILD draft for this "base-system"
>> PKGBUILD (which I shared with Levente during the planning stages of this
>> proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/
> That sounds good to me but I think the name of this new virtual group
> needs to really emphasize its difference to the current (and future)
> base group more clearly. Perhaps something like `minimal-system` or
> anything else somebody clever than me can think of, so long as it does
> not include the words `base` or `core` to avoid confusion.
>
> Apart from this important bikeshedding issue, I'm all in favor of this.
>
> Cheers.

What about `arch-system` instead then?

Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
> 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

In the proposal, base would really just be a convenient helper for e.g.
beginners installing their system, so they could get all tools that are
often used during install (e.g. cryptsetup, lvm2, various FS/network
tools, etc.) or (POSIX) tools people coming from other distros would
expect to be here by default (man pages, nano/vi…) but that are
interactive ones and thus not really required for operating.

Anyone knowing their stuff could just install base-system + what they
actually need (e.g., I would install cryptsetup and vim, and not care
about netctl, xfsprogs or lvm2).

Does that make sense to you?

Bruno




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Orphaning some more packages

[Bruno Pagani via arch-dev-public]

Le 26/11/2018 à 15:08, Bruno Pagani a écrit :
> Hi there,
>
> I’m orphaning two set of packages that I no longer use:
>
> – adapta-kde/kvantum-theme-adapta split package: very low maintenance,
> especially since upstream Adapta is stalled;
>
> – merlin and its dependencies: cppo, dune, merlin, ocaml-biniou,
> ocaml-easyformat, ocaml-yojson. Those have required some time to publish
> and maintain, but things are stabilizing on dune side and for instance
> DESTDIR is now supported so all those PKGBUILD can now be simplified.
>
> Please let me know if you are interested, else I will consider dropping
> them back to AUR.

Some more packages:

– thermald;

– pesign & fwupdate (do not mistake it for fwupd).

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Orphaning adapta-kde and merlin tree

[Bruno Pagani via arch-dev-public]

Hi there,

I’m orphaning two set of packages that I no longer use:

– adapta-kde/kvantum-theme-adapta split package: very low maintenance,
especially since upstream Adapta is stalled;

– merlin and its dependencies: cppo, dune, merlin, ocaml-biniou,
ocaml-easyformat, ocaml-yojson. Those have required some time to publish
and maintain, but things are stabilizing on dune side and for instance
DESTDIR is now supported so all those PKGBUILD can now be simplified.

Please let me know if you are interested, else I will consider dropping
them back to AUR.

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 06/11/2018 à 11:37, Allan McRae a écrit :
> On 6/11/18 8:15 pm, Bruno Pagani wrote:
>> Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit :
>>> On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote:
 On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote:
> Hello everybody,
>
> First of all, the following mail has nothing to do with the last two TU
> applications, it's a general view on the current TU application process.
>
> I would like to propose a new process for TU applications due to several
> reasons:
>
 Read the TU bylaws.  It has specific instructions of where proposals
 must be posted (hint: not here...).

 A
>>> Hi Allan,
>>>
>>> This mail wasn't meant as proposal. It's just a general discussion about
>>> this topic and people said in the TU IRC channel yesterday, that 
>>> arch-dev-public would be the
>>> right mailinglist for such discussion.
>>>
>>> chris
>> Specifically, we are also interested in the input of devs, not just TUs.
> Strange, given TUs are set-up to be an independently governed group from
> developers...
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].
> But because you asked my opinion, I think a TU council is
> a really, really, really bad idea.  No need to set some TUs above
> others.
Well some already are, because they are devs too.
> We have never had a formal hierarchy in the developers (apart
> from our glorious leader),
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).
> and are instead run by those who step up to
> lead what needs done. I believe that this is what makes Arch work, and
> governance would be detrimental to the distribution as a whole.
Because you think Arch work, we (as some TUs/devs) think they are a
number of issues.
> Personally, I'd get rid of all quorum for electing a TU, and make
> inactive TUs be measured purely on the basis of package updating.  Most
> TU application discussions are inane beyond the customary package
> review.  And when someone applies and their packages are very bad, their
> sponsor should be held in shame.
>
> Finally, I don't want to hear what the minions are up to!  Get back to
> your own mailing list. :)

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

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit :
> On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote:
>> On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote:
>>> Hello everybody,
>>>
>>> First of all, the following mail has nothing to do with the last two TU
>>> applications, it's a general view on the current TU application process.
>>>
>>> I would like to propose a new process for TU applications due to several
>>> reasons:
>>>
>> Read the TU bylaws.  It has specific instructions of where proposals
>> must be posted (hint: not here...).
>>
>> A
> Hi Allan,
>
> This mail wasn't meant as proposal. It's just a general discussion about
> this topic and people said in the TU IRC channel yesterday, that 
> arch-dev-public would be the
> right mailinglist for such discussion.
>
> chris

Specifically, we are also interested in the input of devs, not just TUs.

Regards,
Bruno





signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Dropping KDE4 libs

[Bruno Pagani via arch-dev-public]

Le 25/08/2018 à 01:31, Gaetan Bisson a écrit :
> [2018-08-24 18:45:33 +0200] Bruno Pagani:
>> I have a ready PKGBUILD
>> (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel)
>> that I can push (after changing the pkgname) if scribus is moved to
>> [community]. And we can co-maintain it there, co-maintaining is the new
>> sexy. ;)
> It's already in [community]. :)
>
>> I can build into [community-testing] first so that people can check they
>> don’t have issue with it (I don’t, but once again I only work on a small
>> project, so I did not test everything).
> Sounds good to me! Feel free to go ahead with your proposed changes.
>
> Cheers.


Just a small heads up, scribus 1.5.4 has been in testing for the past 10
days. ;) Not sure if we want to wait for signoffs or anything before moving.

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Dropping KDE4 libs

[Bruno Pagani via arch-dev-public]

Le 24/08/2018 à 18:38, Gaetan Bisson via arch-dev-public a écrit :

> [2018-08-24 11:51:30 +0200] Bruno Pagani via arch-dev-public:
>>> scribus
>> The develop branch (1.5.x), available as scribus-devel in the AUR (and
>> maintained by myself), is Qt5. It has been in development for the past 3
>> years already, and still no ETA AFAIK… I’ve been using it instead of
>> scribus from repo for the past 2 years with no issue, but my use case is
>> limited w.r.t. all the possibilities this software offers. Last time I
>> asked about even packaging the -devel version in [community], fellow TUs
>> were not fond of the idea. So about replacing the repo version with it…
> Great idea. I have no objection and can get to it as soon as I'm back
> from holidays. Or if you're happy to maintain scribus in [community]
> yourself please do push a suitably-tested development snapshot and I'll
> transfer ownership of the package to you.
>
> Cheers.

I have a ready PKGBUILD
(https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel)
that I can push (after changing the pkgname) if scribus is moved to
[community]. And we can co-maintain it there, co-maintaining is the new
sexy. ;)

I can build into [community-testing] first so that people can check they
don’t have issue with it (I don’t, but once again I only work on a small
project, so I did not test everything).

Regards,
Bruno




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Dropping KDE4 libs

[Bruno Pagani via arch-dev-public]

Le 24/08/2018 à 11:10, Antonio Rojas via arch-dev-public a écrit :

> fcitx-qt4
> ibus-qt

The first one will be useless once Qt4 apps are gone, the second one can
be rebuild without Qt4 support when that happens too.

> keepassx
> keepassx2

I think both should be dropped as replaced by keepassxc. Upstream is
quite dead (well keepassx is even the old 0.4.x branch, so definitively
dead), if you really want to keep keepassx2 then the master branch has
Qt5 support.

> scribus

The develop branch (1.5.x), available as scribus-devel in the AUR (and
maintained by myself), is Qt5. It has been in development for the past 3
years already, and still no ETA AFAIK… I’ve been using it instead of
scribus from repo for the past 2 years with no issue, but my use case is
limited w.r.t. all the possibilities this software offers. Last time I
asked about even packaging the -devel version in [community], fellow TUs
were not fond of the idea. So about replacing the repo version with it…

Bruno




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Dropping KDE4 libs

[Bruno Pagani via arch-dev-public]

Le 17/08/2018 à 20:53, Antonio Rojas via arch-dev-public a écrit :

>  I think it's time to drop the KDE4 libraries. They were EOL months ago and 
> most stuff that isn't yet ported to KF5 is dead upstream. This would allow 
> dropping a number of qt4 libraries and reduce the qt4 reverse dependencies 
> (qt4 has been EOL for 3 years now). Affected packages are:
>  - recorditnow (there are many alternatives available)
>  - ligthdm-kde-greeter (dead upstream, no signs of KF5 porting)
>  - krecipes (dead upstream, no signs of KF5 porting)
>  - kdiff3 (has been ported to KF5 for a while, just needs a release. Could be 
> updated to a snapshot)
>  - pidgin-kwallet (uses kwallet dbus API, so should work with the KF5 version 
> without any modification)
>  - libreoffice-still (would lose the KDE4 VCL, which is quite buggy anyway. 
> LO-fresh has a new VCL that uses KF5 file dialog)
>  - amarok: it has a WIP KF5 port, but it's not quite ready and development is 
> stalled. IMO we should let it rest in peace - I can keep a KF5 snapshot in 
> kde-unstable for a while but it doesn't look like it's going anywhere any 
> time soon at the current development pace. There are a few alternatives in 
> the repos.
>
>  Comments?

Well, I think all of those can go away. Amarok has seen so few activity
over the past years that I would also consider it dead. Plus it’s quite
an huge app, so porting is a lot of work, which will never happen at the
current pace for sure. And KDE has been developing a new music player to
replace it as the default KDE experience music player. ;)

Bruno




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Dropping pyqt4/pyside1

[Bruno Pagani via arch-dev-public]

Le 17/08/2018 à 20:39, Antonio Rojas via arch-dev-public a écrit :

> Hi all,
>  The latest pyqt4 release makes packaging more complex due to upstream's 
> decision of requiring a private namespaced sip (for mysterious reasons). It 
> is also the last release, so pyqt4 is now officially EOL. I would like to 
> drop it from our repos. It's mostly used as an optional dependency of python 
> packages that also support a pyqt5 backend, so it shouldn't cause much 
> trouble. Other packages that require it (gnuradio, hgview) have alternative 
> UIs (wxwidgets and ncurses respectively). And in any case, pyqt4 is not a 
> build-time dependency, so the pyqt4 UI would still work by installing pyqt4 
> from AUR. Besides these, the only package that still needs it is ninja-ide. 
> It is ported to PyQt5 in git, so it could be updated to a snapshot.
>  I'd also like to drop pyside1, for the same reasons (unused/EOL). This would 
> reduce the number of reverse qt4 dependencies, and bring us closer to 
> dropping it. Any comments or objections?

Please go ahead! I’ve personally removed qt4 from my system 1 year and a
half ago, I’d be glad to see it go away from our repos. ;)

Bruno




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] dropping luxrender packages

[Bruno Pagani via arch-dev-public]

Le 27/07/2018 à 19:59, Lukas Jirkovsky via arch-dev-public a écrit :

> Hi,
> I'd like to drop the luxrays, luxrender and luxblend25 packages from
> [community]. They have always required continuous attention to keep
> working which I can no longer provide with sufficient quality and
> right now the luxrender package is blocking the Python 3.7 rebuild.
>
> Moreover, the luxrender project has been abandoned and it was
> superseded by LuxCoreRender which has an active maintainer in AUR.
>
> If nobody steps in, I will remove them tomorrow.
>
> Lukas

Please drop embree2 at the same time then, since luxrender was the only
remaining user. ;)

Bruno



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Removing 'orphan' python2 modules

[Bruno Pagani via arch-dev-public]

Le 27/06/2018 à 21:51, Antonio Rojas via arch-dev-public a écrit :

>> Please reply if you have objections.
>> A list of modules / programs can be obtained as following or viewed here
> That list doesn't take makedepends/optdepends into account. There are a few 
> optdepends of sagemath there (pkgconfig, pynormaliz)

That, as well as actual program (sonata). I did not go through the whole
list, they were too many false positives from the start.



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Automatic Signing of ISOs, pacman databases and everything else (was: Arch Linux Cloud Images (virtualbox and Qemu))

[Bruno Pagani via arch-dev-public]

Le 15/05/2018 à 17:25, Florian Pritz via arch-dev-public a écrit :

> On 13.05.2018 22:47, Christian Rebischke via arch-dev-public wrote:
>> We could just generate an automated cloud image signing key (only for
>> this purpose) of course and automatically sign the images with that key.
>> Problem with this is: If our build server ever get pwned the person will
>> have these keys for signing cloud images as well. Any opinion about
>> this?
> We had that discussion some years ago about signing our pacman
> databases. I mostly remember that we didn't reach a consensus, but you
> might want to search the archives for details. At some point there was a
> proposal to have a dedicated signing host that is well protected and
> receives files and then returns the signature. I'm not sure if that was
> turned down or if there was simply nobody to work on this. Does anyone
> remember that?
>
> I think this would be a viable option for us. We could also implement
> some form of rate limiting and sanity checks to ensure we only sign
> things that we want to sign. For example, only one ISO can be signed per
> month and the request must come from a specific IP. I probably won't do
> any implementation, but I'd offer to provide feedback and design help if
> someone wants to work on this. Assuming we first agree that we want to
> do it this way.

To me this is quite a good idea. :)

I had a bit more sophisticated design in mind, where the signing host
/retrieves/ the file to be signed (so that the connection is initiated
from it, not toward it) by having the filename added to some text file
on an other (almost?) dedicated host (so that having access to the hosts
where the DB/iso/whatever are built is not enough and vice-versa, see
just after), text file that the signing host would be watching a way or
another (but should be in an authenticated way). Of course you need to
restrict what kind of files can be retrieved from what host (like you
proposed for the request coming from a specified IP).

The goal of this setup is to have no open port on the signing host,
requiring physical/IPMI access to it to make any change.

But maybe that does not bring much more than your setup, while adding
much more complexity…

Just as you, I cannot help on implementing, but I can offer ideas and
design feedback if anyone want to take this task in charge.

Regards,
Bruno



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 13/03/2018 à 13:42, Antonio Rojas via arch-dev-public a écrit :

> El martes, 13 de marzo de 2018 11:23:07 (CET) Bruno Pagani via 
> arch-dev-public escribió:
>> Some projects seems to default to Debug instead of None… So should we
>> specify a BUILD_TYPE of None instead of Release?
>>
> Not sure if it's a good idea to systematically override the build type when 
> it has been explicitely set by upstream. Some projects may be doing so for 
> good reasons. Although explicitely setting it to Debug in a release tarball 
> seems odd, do you have any example of such a project? 

The one I had in mind:
https://github.com/Unidata/netcdf-c/blob/master/CMakeLists.txt#L122

Release tarball is the same, they don’t change anything w.r.t. CMake in
release tarball. Maybe it’s just one project and all other Arch Linux
packages are not affected, but dropping BUILD_TYPE automatically at repo
scale does not seems a good idea. I would prefer a todo list with
instructions on checking what BUILD_TYPE and more importantly FLAGS
where actually used by the build, even if I know you would rather have
avoided one.



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 11/03/2018 à 10:00, Antonio Rojas via arch-dev-public a écrit :

> El domingo, 11 de marzo de 2018 1:44:07 (CET) Eli Schwartz via 
> arch-dev-public escribió:
>> This theoretically sounds like a fantastic idea, but I'm not really sure
>> what CMake's deal with build flags are in the first place. What is the
>> default build type, and does CMake even look at build flags from the
>> environment at all (at least in a sane manner)?
> This is very poorly documented, so you have to dig into the cmake code to 
> figure it out. The default build type is None, which means CMAKE_C(XX)_FLAGS 
> is used (see /usr/share/cmake-3.10/Modules/CMakeCInformation.cmake:117), 
> whose value is taken from the environment C(XX)FLAGS (see 
> /usr/share/cmake-3.10/Modules/CMakeCXXInformation.cmake:198). So yes, not 
> setting CMAKE_BUILD_TYPE will simply use the build flags from C(XX)FLAGS. If 
> you want to test yourself, run cmake with the -LAH flag and check the output 
> for CMAKE_C(XX)_FLAGS.

Some projects seems to default to Debug instead of None… So should we
specify a BUILD_TYPE of None instead of Release?



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 10/03/2018 à 11:34, Antonio Rojas via arch-dev-public a écrit :

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

As long as you accept exceptions to this (I have scientific stuff in
mind, like NetCDF — currently not built with CMake but will be in next
release), I’m fine with this.



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 03/01/2018 à 23:31, Balló György via arch-dev-public a écrit :

> You missed some optional and indirect dependencies.

TBH, he explicitly stated not having included optional dependencies. But
I agree that missing them is an issue. ;)

Regards,
Bruno



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 18/12/2017 à 10:54, Bartłomiej Piotrowski via arch-dev-public a écrit :

> - flickcurl:
> Archange: darktable

Took it.

> - ftjam:
> eric: lincity-ng
> jlichtblau: lincity-ng
> svenstaro: megaglest
> Archange: argyllcms
> - js185:
> Archange: couchdb

Erm… Took them, even if those are (very) outdated softwares (last ftjam
release in… 2006?).

> - osm-gps-map:
> Archange: darktable

Yet another outdated software. But eh…

> - pugixml:
> Archange: darktable
> - vigra:
> Archange: enblend-enfuse

Adopted.

Thanks for this repo check!

Bruno



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 18/12/2017 à 21:48, Jelle van der Waa a écrit :

> On 12/18/17 at 10:47am, Gaetan Bisson via arch-dev-public wrote:
>> [2017-12-18 10:54:37 +0100] Bartłomiej Piotrowski via arch-dev-public:
>>> - tclap:
>>> bisson: hugin
>> I've just orphaned hugin too. Happy adopting! :)
> Gotta catch them all!

I’m taking it too. ;) But I can’t take tclap since it’s in extra, though
this could be easily moved to [community] since hugin is the only
package depending on it.



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 12/09/2017 à 21:27, Giancarlo Razzolini a écrit :

> Em setembro 12, 2017 14:58 Andreas Radke escreveu:
>> 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?
>>
> Hi Andreas,
>
> We have discussed this on IRC and this has been a recurring theme over
> the
> years.

So this finally made it to adp one way. Let’s start the official
discussion about it.

> I see two main things that derive from this:
>
> 1) base is assumed or not? I know some developers don't assume base
> and list
> it on their packages dependencies.
>
> We have been telling our users that base is assumed since at least
> 2009 [0]

Yes, but in fact most of us do not assume base as installed indeed. Even
Andreas just proved us that he doesn’t have base installed on its system
(at least systemd-sysvcompat is missing). As far as I’m concerned, I
have at least 6 different machines, and none of them have the full base.
Also, it’s not assumed by devtools in contrary to base-devel.

Finally, I would say that the base group, as well as most other groups,
are helpers to get things done at install time. But those should not be
assumed.

>
> 2) The second thing that arises from the first is a broader question
> which is
> what do we consider a minimal arch installation?
>
> If the answer to this question is base, then we certainly *must* have
> systemd
> on it. And we can discuss trimming it down, because I think that base
> has some
> packages that shouldn't be there such as, netctl and dhcpcd (I use both).
>
> If the answer is not base, then we should have something like a
> base-system
> group which contains the bare minimum, like linux, glibc, pacman,
> systemd and
> its dependencies.

That. We don’t need to list dependencies in the group itself (we don’t
do that for base), especially because you don’t want to track
dependencies changes of systemd also in the group.

Or as per Sebastien idea, we could have a `base` or `arch` or -system
package depending on the required packages. Bonus: you can change what’s
in the minimal installation without having to tell users that this
package is now in the group or this one isn’t anymore, pacman will
handle that. ;)

Regards,
Bruno



signature.asc
Description: OpenPGP digital signature

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

[Bruno Pagani via arch-dev-public]

Le 01/07/2017 à 20:15, Laurent Carlier via arch-dev-public a écrit :

> Le samedi 1 juillet 2017, 19:59:49 CEST Christian Hesse a écrit :
>> Dave Reisner  on Sat, 2017/07/01 13:22:
>>> One potentially bikeshed-worthy question is versioning. Do we count
>>> commits and modify the pkgver every time we build from the repo, e.g.
>>> 233.23-1 (meaning pkgrel=1 of a v233 build containing 23 backports), or
>>> do we simply keep the base pkgver true to upstream and increment pkgrel
>>> every time we release, e.g. 233-5 (meaning pkgrel=5 of some build of the
>>> v233 stable branch).
>>>
>>> [1] https://github.com/systemd/systemd-stable
>> I like the versioning to indicate what the package contains... So voting for
>> the inclusion of commit count. The only downside will be that people will
>> flag the package out-of-date for every new commit in the stable branch. :-p
> I agree, commit count is the best choice.

Just in case more voices matter, I agree too. ;)

Bruno



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Mesa, Nvidia and libglvnd (the good, the bad and the ugly) :)

[Bruno Pagani via arch-dev-public]

Hi,

Thanks for thinking about libglvnd support in Arch. ;)

Le 12/02/2017 à 19:22, Laurent Carlier via arch-dev-public a écrit :

> Bumblebee will not work anymore with Nvidia and Mesa, but only with prime (1).

This sentence doesn’t really make sense. Bumblebee doesn’t work with
PRIME, they are two different solutions to Optimus support under Linux.
Some more correct statements:

– Bumblebee will still work with VirtualGL, but some changes will be
required for primus [1] (I’m not sure since I did not have time to test
it yet, but it could be as simple as patching bumblebee/primusrun for
exporting __GLVND_DISALLOW_PATCHING=1 when running optirun with primus
or primusrun, anyway I asked the person who fixed it in Fedora what
changes this has required);

– what will change with Nvidia PRIME support is that it would be easier
to switch from a X server running on Intel to a one running on Nvidia,
like nvidia-prime allows on Ubuntu, because you won’t have to switch
libgl packages on-the-fly. That’s a big win from an usability POV.

> Nvidia-340xx driver will still work with bumblebee but will need a specific 
> (non libglvnd?) Mesa version.

Hum… What makes nvidia-340xx situation different from nvidia-304xx, and
without even talking of Bumblebee, does it even work with libglvnd?
AFAIK, the support was introduced in 361 series, and wasn’t backported
to the 340xx branch.

Regarding Bumblebee, I don’t think it would require anything specific,
but I should be able to test that and work around once everything will
have landed. ;)

Regards,
Bruno

[1] https://github.com/amonakov/primus/issues/193



signature.asc
Description: OpenPGP digital signature