[aur-general] TU resignation

[Baptiste Jonglez]

Hi,

I have been less active in Arch for some time.  I'm involved in many other
projects that end up taking lots of time, and as a result I don't have the
required time / energy / interest for Arch anymore.  When my last Arch
machine died recently after 10 years of loyal Arch service, it was a good
sign that I should make this official.

With that being said, I am resigning as a TU.  I've had some, let's say,
"disagreements" with a few members of the team over the years, but overall
it was a positive experience.  Keep up the good work, and take care of
this delicate balance between technical excellence and community-minded
approach.

Now for practical matters, here are my packages in [community]:

auto-multiple-choice
babeld
camlp5
confuse
coq
coq-doc
coqide
dia
dune
fastd
fig2dev
gephi
gobby
hevea
horst
icmake
ipv6calc
kea
kea-devel-docs
lablgtk3
lesspipe
libinfinity
libuecc
msgpack-c
ocaml-cairo
ocaml-num
perl-locale-codes
python-antlr4
python-latexcodec
python-oset
python-pybtex
python-pybtex-docutils
python-sphinxcontrib-bibtex
python-sphinx-testing
quilt
radcli
remake
tcptrace
xplot
yodl

Feel free to adopt them in [community], and I can also move some to the
AUR if somebody is interested to maintain them.

I also have a few packages in the AUR that I am going to orphan:

  https://aur.archlinux.org/packages/?O=0=M=zorun

Regards,
Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] [arch-dev-public] AUR migration

[Baptiste Jonglez]

On 27-07-20, Giancarlo Razzolini via aur-general wrote:
> Em julho 27, 2020 21:03 Gaetan Bisson escreveu:
> > 
> > It's quite unsettling that we seem to be rushing to write a news post
> > while this very reasonable suggestion remains completely ignored.
> > 
> 
> It wasn't ignored. They keys were deliberately changed in the process.

Ok, thanks, now I know it was intended and not just an oversight.

The root issue is of course the host / service confusion, but there's not
much that can be done about it if everything runs on port 22.

From a user perspective, it's the same service running under the same name
(aur.archlinux.org), so it should keep using the same key after the migration.

From an sysadmin perspective, these are two different hosts, so they
should use different keys.

When thinking service first, it's not a problem to have the same key on
multiple machines.  Think about github.com or gitlab.com: they must have
tens of machines with the same host key.  If a single one is compromised,
they lose the key, but all machines likely have the same attack surface
anyway.

Anyway, in the end, it's not surprising you chose the sysadmin
perspective, and the old/new servers don't seem to have the same attack
surface.

Baptiste

PS: I didn't know about UpdateHostKeys and it looks really useful, thanks
for pointing it out!


signature.asc
Description: PGP signature

Re: [aur-general] [arch-dev-public] AUR migration

[Baptiste Jonglez]

Hi,

On 24-07-20, Giancarlo Razzolini via arch-dev-public wrote:
> The migration is almost done. Since we are moving to a new machine, it will
> have new host keys. They are:
> 
>Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4
>ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8
>RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI
> 
> They are also be available on the home page when logged out.

Can't you just copy the SSH host keys from the old machines?

It's the same service as before and (presumably) the host private keys
were not compromised, so there is no reason to change keys.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] AUR migration

[Baptiste Jonglez]

On 24-07-20, Giancarlo Razzolini via aur-general wrote:
> Em julho 23, 2020 19:45 Sven-Hendrik Haase via aur-general escreveu:
> > 
> > Thanks for taking the time! I hope there won't be any weird unforeseen
> > problems.
> > 
> > 
> 
> Sure. I wrote a checklist for the migration [0], to try to avoid issues. I 
> could've
> missed soemthing, if you spot anything, please edit the page.
> 
> [0] 
> https://gitlab.archlinux.org/archlinux/infrastructure/-/wikis/migrations/aur

FYI, the  record still points to the old server (luna), while the A
record has already been switched to the new server.

Baptiste


signature.asc
Description: PGP signature

[aur-general] Auto-generated Github tarballs format change (Was: TU Application: Daniel M. Capella)

[Baptiste Jonglez]

On 15-11-18, Eli Schwartz via aur-general wrote:
> On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
> > Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
> >> - tests are awesome <3 run them whenever possible! more is better!
> >>   pulling sources from github is favorable when you get free tests
> >>   and sometimes manpages/docs
> > 
> > Will work with the upstreams to distribute these. I prefer to use published
> > offerings as they are what the authors intend to be used. GitHub 
> > autogenerated
> > tarballs are also subject to change:
> > https://marc.info/?l=openbsd-ports=151973450514279=2
> 
> I've seen the occasional *claim* that this happens, but I've yet to see
> any actual case where this happens and it isn't because of upstream
> force-pushing a tag.

See https://bugs.archlinux.org/task/60382 for an example.

I still had the old archive around so I spent some time comparing it with
the new one:

- I compared the checksum of each individual file in the archives, and
  they were all identical

- I compared the raw tar files after decompressing, and there were just a
  few bytes that were moved around

This really suggests a slight format change in the way the tarball was
generated (could be file ordering).

If you want to double check, here they are:

- old archive from May 2017: 
https://files.polyno.me/arch/kashmir-20150805-20170525.tar.gz

- new archive: https://files.polyno.me/arch/kashmir-20150805.tar.gz

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] On TU application, TU participation and community/ package quality

[Baptiste Jonglez]

On 11-11-18, Santiago Torres-Arias via aur-general wrote:
> On TU applications, TU participation and package quality:
> =
> 
> Many Trusted Users have brought up their concerns regarding the lack
> of proper vetting of packages put forward by new TU's, the small
> participation of TUs in their duties* and the declining quality of
> packages in the community/ repository. As a consequence, we've decided
> to bring forward proposals to tackle the following issues:

Before diving in on the proposed solutions, let's make sure we all agree
on whether there is a problem and what is the problem exactly:

> ## Issues
> 
> * Existing Trusted Users are not followed closely in their actions

Well, that's why it's called *Trusted* Users, right?  Most of the issues
you mention are actually issues about trust.

I've made some packaging mistakes in the past, and there was always
somebody to yell at me.  I wasn't happy at the time and maybe I didn't
react appropriately, but most of the time the "yeller" was right, and I
learned from these mistakes so as not to repeat them.

If we want to increase the level of trust in terms of packaging quality, I
like the suggestion of a "probation" period in which new TUs have all
their changes reviewed by their sponsor and/or another TU.

This seems much more productive and reasonable than a "council of trusted
Trusted Users" that either acts as a gatekeeper or assesses the
"performance" of their fellow TUs, whatever that means...

> * New applications are not carefully reviewed, and a several TUs seem to
>   just vote “Yes” by default.

Do you have any data backing up this claim about voting "Yes" by default?
Do you mean that some TUs vote "Yes" without reading the TU application thread?

I find this unlikely, we even rejected some TU applications in the past
(one in 2014, one in 2016 and another in 2017).

The most likely explanation for the successful applications is that they
just didn't raise any serious issue worth a rejection.

> * The implication of some TUs in the distribution is very limited
>   outside of packaging.

You can't expect everybody to dedicate all their time to Arch: we all live
different lives and are already involved in various projects.  Let's just
accept that there are several ways of contributing and that's fine.

On a more practical note: when some people are so active that they reply
to any question on [aur-general] almost immediately, you just can't be
faster unless you watch your Arch emails all day long.  So maybe some TUs
need to participate more, but conversely some TUs might also need to leave
a bit of room for the others!

One area where more contributions would be welcome is handling AUR requests [1].
But as far as I can tell, we currently don't even advertise this to new TUs [2].

Baptiste

[1] https://aur.archlinux.org/requests/
[2] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines


signature.asc
Description: PGP signature

Re: [aur-general] Vote closed for TU Application - Konstantin Gizdov

[Baptiste Jonglez]

On 29-10-18, Baptiste Jonglez wrote:
> On 14-10-18, Konstantin Gizdov wrote:
> > Hello,
> > 
> > I am Konstantin Gizdov [1] [2],
> > (`kgizdov`, `a...@kge.pw`, `kgiz...@gmail.com`)
> > 
> > I would like to apply to be a Trusted User under Baptiste Jonglez's
> > sponsorship.
> 
> The discussion period is over, the vote is now open:
> 
>   https://aur.archlinux.org/tu/?id=110
> 
> Please cast your ballot until next Monday!

The vote is over and the result is positive, congratulations Konstantin!

I have upgraded your AUR account to TU status, please read this page
carefully and proceed with the TODO list:

  
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users

I am sure you will make a good addition to the team and that you deserve
the trust we (as a group) place in you.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] About bullying in our community (Was: TU Application)

[Baptiste Jonglez]

Hi,

On 30-10-18, Giancarlo Razzolini via aur-general wrote:
> Em outubro 30, 2018 16:07 Ralf Mardorf escreveu:
> > Apparently this TU has got special rights. That he could behave like
> > this again and again does strengthen him to continue doing it.
> > 
> This thread has lived much longer than it's purpose. Let's stop this right 
> now.
> 
> I'm placing this list into emergency moderation if this continues. I'm 
> confident
> all the parties understood what happened by now and how to avoid this in the 
> future.

It was not my intention to start a debate on whether we should call what
happened "bullying" or "violent".  Let's call that "problematic behaviour"
if that is easier.  Given that several people (including TUs) expressed
that it was inappropriate, the problem is real -- and recurring.

My intention was to expose the problem and start discussing ways to ensure
that it will not happen again.  If the matter is to be "handled
internally" and it is handled successfully, then both goals are fulfilled
and the subject is closed for me.

Anyway, I'm off for vacations so I won't monitor the list until next week.

Baptiste


signature.asc
Description: PGP signature

[aur-general] About bullying in our community (Was: TU Application)

[Baptiste Jonglez]

Hi Santiago,

Now that the discussion period is over, I am taking time to fully answer
this, since it's much more general and important than the TU application
itself.

On 28-10-18, Santiago Torres-Arias wrote:
> I've been following this email thread quite closely and without
> participating as I was hoping to keep opinions to myself --- I don't
> think I have much questions other than what's already asked for
> Konstantin --- and make up my mind for voting.
> 
> It's clear that it is time to take a step back and stop fanning the
> flames. We are all passionate people, and sometimes this passion leads
> us to the type of arguments we are having right now. I agree with Eli,
> this is not a toy operating system and there are things at stake.
> However, I'm completely convinced that no ill intention is coming from
> everyone involved, and that, if we consider this optic, it's clear that
> this is just a non-technical quarrel that should've been shelved a while
> ago.
> 
> Personally, I think this is a good opportunity to tone it down for a
> second, leave the 10+ emails behind us and try to go back to the things
> that make this community friendly and welcoming.
> 
> Baptiste, Konstantin, Eli, and Doug. Please take a deep breath and
> extend a friendly handshake. I'm sure everyone else following this
> exchnage thinks this is the reasonable way to move forward.

I understand that you want to calm things down and the intention is good,
but you make it appear as if the animosity is symmetrical.  But the
situation is actually not: we have two bullies ganging up violently on a
newcomer, who has so far kept a very cool head and stayed polite where
most people would have gotten angry.  On my side I reacted more angrily
because I am getting fed up with this kind of repeated toxic attitude, and
other people expressed dismay at the violent personal attacks we
witnessed.

Note that here I am not making any judgement on the validity of the
arguments in the various technical debates: this is important but it is
not the point here.  The point is precisely to be able to have interesting
discussions and debates, without resorting to personal attacks, insults or
abusing a dominating position, as both Doug and Eli have repeatedly done
in the past and now again:

https://lists.archlinux.org/pipermail/aur-general/2018-September/034287.html
https://lists.archlinux.org/pipermail/aur-general/2018-October/034402.html
https://lists.archlinux.org/pipermail/aur-general/2018-October/034408.html
https://lists.archlinux.org/pipermail/aur-general/2018-October/034411.html

This is not a witch-hunt: Doug and Eli, this discussion does *not*
question your attachment to this community, the quality of your work or
the quality of your technical opinions in general.  In fact your are both
much more knowledgeable and active in Arch than most people including me.
But that is certainly not a valid reason to start bullying people around,
or else I am grossly mistaken about this whole community.

As a general rule, when nobody stands up publicly against a bully, the
bully will just continue bullying people the same way in the future,
perhaps even more confidently.

Of course, we can also bury our head in the sand and pride ourselves that
our community is "friendly and welcoming" (I think this is still true on
the whole btw) while leaving the bullies act unchecked.  Santiago, I don't
mean this as a personal attack on you, I just think that it's a bad idea
to sweep such unacceptable personal behaviour under the carpet as if
nothing happened.

Quite frankly, in the future I am considering taking whatever actions are
necessary to make sure that this kind of hurtful behaviour doesn't happen
again, including asking for the bully's resignation or resigning myself.
I hope that we will find ways to work things out without having to resort
to such extremes.

Discussing these problems seems like a good start :)

Baptiste


signature.asc
Description: PGP signature

[aur-general] Vote open for TU Application - Konstantin Gizdov

[Baptiste Jonglez]

Hi,

On 14-10-18, Konstantin Gizdov wrote:
> Hello,
> 
> I am Konstantin Gizdov [1] [2],
> (`kgizdov`, `a...@kge.pw`, `kgiz...@gmail.com`)
> 
> I would like to apply to be a Trusted User under Baptiste Jonglez's
> sponsorship.

The discussion period is over, the vote is now open:

  https://aur.archlinux.org/tu/?id=110

Please cast your ballot until next Monday!

Baptiste


signature.asc
Description: PGP signature

[aur-general] Code of conduct (Was: TU Application - Konstantin Gizdov)

[Baptiste Jonglez]

On 28-10-18, Daniel M. Capella wrote:
> On October 28, 2018 2:42:31 PM EDT, Baptiste Jonglez 
>  wrote:
> >On 28-10-18, Eli Schwartz via aur-general wrote:
> >> (endless rambling)
> >
> >Can we please stop this futile bike-shedding exercise?  It does little
> >outside of discrediting you and the Arch community as a whole.
> >
> >I already said so in previous discussions, but I am still dismayed at
> >your
> >and Doug's tendency to aggressively gang up on anybody crossing your
> >way,
> >assuming from the start that they are lying bastards with devious
> >motives,
> >without ever questioning your own assumptions or actions.  You
> >desperately
> >want to always be right and to always have the final word, but I'm
> >sorry
> >to say that life does not work this way.
> >
> >Regarding the TU application itself, the discussion period is nearly
> >over.
> >Since the bylaws mention that the period lasts 14 "full days", I will
> >open
> >the vote tomorrow morning.
> >
> >Baptiste
> 
> It's upsetting and embarrassing that the only staffer to stand against this 
> behavior directly in the ML is the applicant's sponsor. This disrespectful 
> behavior occurs all the time. Can we enforce our Code of Conduct or is it 
> just for show?

Thank you Daniel -- I actually discover that we *do* have a code of
conduct, this is good news:

  https://wiki.archlinux.org/index.php/Code_of_conduct#Code_of_conduct

It seems to me that these three rules in particular are relevant in this
case and were not respected: "Respect other users", "Do not flame" and "Be
responsible".

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application - Konstantin Gizdov

[Baptiste Jonglez]

On 28-10-18, Eli Schwartz via aur-general wrote:
> (endless rambling)

Can we please stop this futile bike-shedding exercise?  It does little
outside of discrediting you and the Arch community as a whole.

I already said so in previous discussions, but I am still dismayed at your
and Doug's tendency to aggressively gang up on anybody crossing your way,
assuming from the start that they are lying bastards with devious motives,
without ever questioning your own assumptions or actions.  You desperately
want to always be right and to always have the final word, but I'm sorry
to say that life does not work this way.

Regarding the TU application itself, the discussion period is nearly over.
Since the bylaws mention that the period lasts 14 "full days", I will open
the vote tomorrow morning.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Daniel Bermond (dbermond)

[Baptiste Jonglez]

On 15-10-18, Levente Polyak via aur-general wrote:
> On 10/14/18 11:35 PM, Daniel Bermond via aur-general wrote:
> >
> > I usually don't use pgp on my aur packages because people tend to
> > complain a lot about building issues. They fail to handle the keys and
> > start complaining to the packager, and this is a big stress. When
> > dealing with repository packages this is another story, of course. Since
> > this was raised as a main issue, I'll be adding the pgp checks back again.
> > 
> 
> So let me summarize what you are saying, correct me if im wrong:
> 
> You fully know whats all the gizzle with gpg. Instead of acting like a
> trustable user who follows best practice and spreads good advice and
> helps teaching people about how all this works properly you prefere to
> pull the lazy card because its what? big stress? Serious?
> I don't even find words to describe how untrustworthy this is to the
> community to prefer to remove GPG signatures instead of educating users?

What a warm way to welcome people.  A bit of fact-checking doesn't hurt:

$ pkgver=4.16.1
$ wget 
"https://www.apache.org/dist/flex/${pkgver}/binaries/apache-flex-sdk-${pkgver}-bin.tar.gz"{,.asc}
$ gpg --verify apache-flex-sdk-4.16.1-bin.tar.gz.asc 
gpg: assuming signed data in 'apache-flex-sdk-4.16.1-bin.tar.gz'
gpg: Signature made mer. 15 nov. 2017 09:44:37 CET
gpg:using RSA key 44998F3E242727E94C4BADEB6B0A7EC905061FC8
gpg: Can't check signature: No public key

$ gpg --search-keys 44998F3E242727E94C4BADEB6B0A7EC905061FC8
gpg: data source: http://192.146.137.99:11371
(1)  Piotr Zarzycki (CODE SIGNING KEY) 
   4096 bit RSA key 6B0A7EC905061FC8, created: 2017-06-17 (revoked)
Keys 1-1 of 1 for "44998F3E242727E94C4BADEB6B0A7EC905061FC8".  Enter number(s), 
N)ext, or Q)uit > 


Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Daniel Bermond (dbermond)

[Baptiste Jonglez]

Hi,

On 14-10-18, Doug Newgard via aur-general wrote:
> Decided to take a quick look at your PKGBUILDs, and just a few spot checks
> makes me wonder. The first one I click on is apache-flex-sdk, I see that you
> aren't the original submitter, so I look at the git log and see that the first
> thing you did when taking over this was to remove pgp checks from the source.
> WTF. Look at the PKGBUILD, see a totally useless prepare function, ok, not a
> big thing. Let's check another one, clicked on flif, see msg2s being used for
> no reason and bad conflicts. Click on a couple more, see that those issues
> aren't mistakes, they're a fundamental misunderstanding.
> 
> Maybe my perception was colored by that really bad decision to remove the pgp
> checks, and while the PKGBUILDs are mostly fine, there seems to be things 
> about
> packaging that you don't understand yet. Is it time to become a TU already?

Well, as always, you could start by not being immediately aggressive
towards people.

Judging from the handful of PKGBUILDs I've read, the quality is really
high overall, they don't even have most of the "classical" small mistakes
(there is source renaming when needed, etc).  We don't require new TUs to
do everything perfectly, and nothing is ever perfect anyway.  There's
always something new to learn.

Regarding the PGP checks, there is no question that they are very useful
and desirable for packages in our repositories.  I am sure that Daniel
will make efforts to add PGP checks wherever possible when he moves
packages to [community].  But for the AUR, the situation is a bit
different (in my opinion) because I know it throws some people off when
they don't know that they have to import a PGP key to build the package.
I tend to include them anyway now, but I would understand that somebody
would like not to.

Anyway, for the specific case of apache-flex-sdk, look at the comments:
the signing key simply seemed to have expired.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Daniel Bermond (dbermond)

[Baptiste Jonglez]

Hi,

On 14-10-18, Daniel Bermond via aur-general wrote:
> My name is Daniel Bermond and my alias on the AUR and forums is
> dbermond[1][3].
> 
> Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User 
> application. I would like to highly thank Bruno for accepting to be my 
> sponsor.

Welcome here!

I see that you maintain a fair number of useful and popular packages,
thanks for the work it represents.

I had a look at some of your packages (including the ones you mention
below), and they are in pretty good shape.

> I would like to bring the following packages into [community]:
> - advancecomp
> - kvazaar
> - intel-media-sdk
> - libmysofa
> - openh264
> - shine
> - vmaf

Out of curiosity, do you plan to only bring these 7 packages to
[community], or is it just a highlight?  Out of those 7, only 4 are
currently maintained by you (unless I'm being tricked by the new
co-maintainer feature), and they are not the most popular packages you
have.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application - Konstantin Gizdov

[Baptiste Jonglez]

Hi,

On 14-10-18, Konstantin Gizdov wrote:
> I am Konstantin Gizdov [1] [2],
> (`kgizdov`, `a...@kge.pw`, `kgiz...@gmail.com`)
> 
> I would like to apply to be a Trusted User under Baptiste Jonglez's
> sponsorship.

I confirm my sponsorship of Konstantin.  Let the discussion period begin,
it seems to be a good day to apply to become a TU!

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU application: Ivy Foster

[Baptiste Jonglez]

On 10-02-18, Alad Wenter via aur-general wrote:
> On Sat, Feb 03, 2018 at 12:12:44AM +0100, Alad Wenter via aur-general wrote:
> > On Fri, Jan 26, 2018 at 03:53:07PM -0600, Ivy Foster wrote:
> > > On 26 Jan 2018, at 10:31  +0100, Alad Wenter via aur-general wrote:
> > > > Note: If possible please add a short reply with a GPG signature.
> > > 
> > > My mistake! Here's my official, signed reply.
> > > 
> > The discussion period is over. Let the votes begin!
> > 
> > https://aur.archlinux.org/tu/?id=103
> >
> The voting period has ended, with the following results:
> 
> Yes:33
> No: 3
> Abstain:3
> Total:  39
> 
> As such, the proposal has been accepted. Congratulations!

Congrats, and welcome to the team!

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] Should "base" packages be listed as dependencies?

[Baptiste Jonglez]

So, I didn't think such a technical question would spark so much passion!
Maybe this discussion should indeed go to arch-dev-public.

In the meantime, I see 4 positions emerge from the discussion:

1) packages in "base" *should* be explicitely listed as dependencies
   (either for mere "technical correctness", or because of bloat, i.e. not
   everyone wants/needs all packages from "base")
  
2) packages in "base" *should not* be listed as dependencies (because it
   is assumed that all Arch Linux systems have all packages from "base"
   already installed)

3) it depends on the maintainer (i.e. there are no guidelines on this question)

4) it depends on the base package in question (e.g. it would be acceptable
   to depend on glibc, but not on systemd)


I get the impression that 3) is the current status quo.  I find 4) to be
quite strange and subjective, but it could be done (e.g. only allow
library dependency such as glibc, or allow all dependencies except a few
like systemd).

I have two more arguments in favour of 1) or 4), related to technical
correctness:

- when a new version of glibc is released, which packages should be
  rebuilt?  Without complete dependency information, I don't see how it's
  possible to know.

- Assume that all "base" packages are supposed to already be installed,
  and thus no other package depends on "base" packages.  When a new
  package X is added to "base", how is an already-running system supposed
  to pick it up if no dependency pulls it in?

Baptiste

On Wed, Mar 22, 2017 at 09:45:13PM +0100, Baptiste Jonglez wrote:
> Hi,
> 
> I was pretty confident that "base" packages should be listed as
> dependencies in PKGBUILDs, i.e. they are not assumed to be installed (as
> opposed to "base-devel" for build dependencies).
> 
> This belief is reinforced by the fact that namcap gives dependencies error
> about packages such as glibc (which is in "base"):
> 
> E: Dependency glibc detected and not included (libraries 
> ['usr/lib/libc.so.6', 'usr/lib/libcrypt.so.1'] needed in files 
> ['usr/lib/libcli.so.1.9.7'])
> 
> But I could not find any documentation about this.  On the contrary, this
> wiki page [1] says the opposite:
> 
> In addition, the base group is assumed to be installed on *all* Arch
> systems.
> 
> Am I missing something obvious?
> 
> Thanks,
> Baptiste
> 
> [1] https://wiki.archlinux.org/index.php/Makepkg#Usage




signature.asc
Description: PGP signature

[aur-general] Should "base" packages be listed as dependencies?

[Baptiste Jonglez]

Hi,

I was pretty confident that "base" packages should be listed as
dependencies in PKGBUILDs, i.e. they are not assumed to be installed (as
opposed to "base-devel" for build dependencies).

This belief is reinforced by the fact that namcap gives dependencies error
about packages such as glibc (which is in "base"):

E: Dependency glibc detected and not included (libraries 
['usr/lib/libc.so.6', 'usr/lib/libcrypt.so.1'] needed in files 
['usr/lib/libcli.so.1.9.7'])

But I could not find any documentation about this.  On the contrary, this
wiki page [1] says the opposite:

In addition, the base group is assumed to be installed on *all* Arch
systems.

Am I missing something obvious?

Thanks,
Baptiste

[1] https://wiki.archlinux.org/index.php/Makepkg#Usage


signature.asc
Description: PGP signature

Re: [aur-general] Voting Results (was: TU Application: Baptiste Jonglez)

[Baptiste Jonglez]

On Wed, Dec 14, 2016 at 08:16:39AM +0100, Lukas Fleischer wrote:
> The voting period has ended. The results are:
> 
> * Yes: 24
> * No: 4
> * Abstain: 11
> 
> This means that the proposal has been accepted.
> 
> Congratulations, Baptiste, and welcome aboard!

Great news, thanks everyone!

> I already upgraded your AUR account. Please go through the TODO list for
> new Trusted Users [1] to learn about the next steps.

Ok, I will do that as soon as possible.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hi Nicohood,

On Thu, Dec 01, 2016 at 04:23:27PM +0100, NicoHood wrote:
> you do not need to move the packages as fast as possible into
> community. I became TU month ago and arduino is still not in community
> because some issues needed to be solved first. So quality and security
> is more important here.

Agreed.

> About all this https discussion:
> I think we should all confirm with the gpg and https standards we made
> recently (and the string hashes that i suggested) and we should also try
> to increase the quality of AUR in general and especially as TU to advise
> other people to do so too.
> Packaging a secure chat program and being so lazy about https makes me
> wonder.
> 
> I think it'd be good for you to rethink the https (and gpg, hash) topic,
> because (especially) as secure chat messenger packager it'd be extremely
> important to me that you try to achieve the best security as possible.

You almost sound like I'm opposing all forms of "security" (whatever you
mean by that).  Of course we should promote the use of TLS and HTTPS on
the Internet, even though the trust model is flawed and implementations
are bloated/bugged.

My point is that in the context of packaging, we have different
requirements than for web browsing.  HTTPS does not provide authenticity
and integrity of the sources themselves, which is what we are interested
in.  PGP (preferably) and strong hash algorithms (as a substitute) should
be used for that.

To avoid repeating the same arguments, I agree with what seblu said on
arch-dev-public:

On Tue, Nov 01, 2016 at 04:03:04PM +0100, Sébastien Luttringer wrote:
> TLS is about security of the transportation of sources, not the security
> of sources themselves, that's why I asked, to know what you had in mind.
> 
> My definition of securing the sources, is a way to trust the sources at
> the build time, no matter the way they were fetched. I want to be sure
> that my sources are "correct" even if I get them by usb key, ftp, rsync
> or even if they were not corrupted locally by a btrfs bug.  And when
> possible, I want to be sure that the server (mirror or not) was not
> compromised (even at the first fetch).
> 
> Keeping that in mind, enforcing tls, doesn't improve much the source
> security.  In fact, it improves only security during the transportation
> of the sources at the cost of the caching.

Besides this issue, I already mentioned another drawback of using HTTPS:
untrusted certificates (either expired, self-signed, or just signed by an
untrusted CA) will cause build failure.  This was a real issue for
OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to
avoid build failures.  Sources are already validated with a checksum.

Anyway, some of my packages do not use HTTPS, and this is indeed mostly
because of laziness.  I consider this is a low priority task.
It does not mean that I am fundamentally opposed to the use of HTTPS,
especially for "big" providers like github which are not very likely to
have expired certs.

I had a look at the sources for my AUR packages, and here is the result:

- 5 fetched over HTTPS
- 7 fetched over git+https://

- 5 fetched over HTTP, with no HTTPS available
- 1 fetched over FTP, with no HTTPS available

- 5 fetched over HTTP while HTTPS is available (including 1 with a PGP 
signature)
- 6 fetched over git:// while git+https:// is available

So, less than half of them needed to be "fixed".  I just switched to HTTPS
for 10 out of the 11 fixable packages.  The only remaining one is
linux-mptcp, because I plan to move it away from git soon anyway.

Baptiste

[1] 
https://git.lede-project.org/?p=openwrt/source.git;a=blobdiff;f=scripts/download.pl;h=633a4f6f7d;hp=fe27df5e8f;hb=65fad8645d;hpb=5884b43b51


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

On Tue, Nov 29, 2016 at 08:11:39PM +0100, Lukas Fleischer wrote:
> I confirm that I sponsor Baptiste.
> 
> I have worked with him several times in the past; among other things he
> contributed several patches to calcurse back in 2012 [1]. He is
> knowledgable and I think he will be a great addition to the team!
> 
> Let the discussion period begin!

Thanks Lukas!

There are some points that I feel could be worth discussing (besides TLS…):

1) Would linux-mptcp [1] have its place in [community]?  From what I read
   about linux-zen and linux-grsec [2], there does not seem to be strong
   objections, especially since most (or even all?) third-party kernel
   modules now use DKMS.

2) Some dependencies of my packages are orphaned in [community], such as
   msgpack-c [3].  As a TU, I guess it would make sense to adopt them.

3) ring-daemon requires non-released versions of restbed [4] and asio [5].
   Is it better to wait for upstream to release a version of these libs,
   or is it acceptable to package a snapshot in [community]?


Baptiste

[1] https://aur.archlinux.org/packages/linux-mptcp/
[2] https://lists.archlinux.org/pipermail/arch-dev-public/2015-July/027311.html
[3] https://www.archlinux.org/packages/community/x86_64/msgpack-c/
[4] https://aur.archlinux.org/packages/restbed-latest/
[5] https://aur.archlinux.org/packages/asio-latest/


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

On Tue, Nov 29, 2016 at 01:04:47AM +0100, Levente Polyak wrote:
> On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
> >> - you should use git+https:// instead of plain git:// even through the
> >>   CA world is a bit wonky it still authenticates the server and at the
> >>   very bare minimum adds confidentiality.
> > 
> > I don't like the "everything-over-HTTP(S)" approach in general, especially
> > when there is a dedicated protocol that works (yes, I know, this is basic 
> > ranting).
> > 
> > Assuming the git revision is identified by a commit hash, I see no value
> > in using HTTPS for authentication or verification.  I agree it is useful
> > however when building from a tag or a branch, as you correctly pointed out
> > for another package.
> > 
> > On the other hand, if one day the TLS certificate becomes invalid (expired
> > certificate, untrusted CA, etc), the package would fail to build.  I see
> > this as a significant drawback of using git+https://.
> 
> Well pulling over TLS was discussed over and over and over and over
> again and we ended up that we just do it for all of our packages if
> available...
> Thats why this came up in the first place:
> https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

Yes, I saw the discussion on arch-dev-public (but obviously could not
participate).

> I quote dave: "Security is not a binary thing".
> It adds another layer of security, if you like it or not. It
> authenticates the server (yes there may be untrusted CA, so? *shrug*)
> and i repeat again: at the very bare minimum adds confidentiality. Feel
> free to re-read the arch-dev-public thread, the outcome was the
> mentioned todo list.
> 
> I heard a lot of opinions and some of them are understandable... but
> saying that its a significant drawback as the certificate could possible
> be invalid/expired is certainly nothing i would _ever_ consider as such.

For a package in [community], an expired certificate for the upstream
tarball is not a big deal, since it does not directly affect the Arch user
installing the package.  As a packager, you can just get the tarball by
some other means, or wait a few days so that somebody renews the cert.

But for the AUR, an expired certificate would be annoying, as any user
trying to build the package (e.g. using an AUR helper) would encounter an
error.

> I never get why people always make such a big fuzz in not pulling over TLS.
> The same argumentation could be used for the regular tarballs and I
> repeat, the outcome is simple: use https, easy as that.

Well, I agree with the outcome of the discussion, which was basically "One
way or the other does not change much security-wise, so let's switch to
HTTPS if doing so does not require significant efforts".

> >> ring-gnome-git
> >> - a VCS package should always provide its non-VCS package variant like
> >>   'ring-gnome'
> > 
> > Actually, the missing "provides" is intended.  The Ring components are
> > interdependent and get updated quite frequently, so at any given time
> > `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
> > 
> > More practically, when the "provides" was here, I had issues with AUR
> > users mixing -git and non-git ring packages and complaining of building
> > errors.
> > 
> 
> This could be the case for literally _any_ library f.e. and still all of
> them have their corresponding provides. If there would be anything
> depending on ring-gnome you created an unresolvable hell be just
> conflicting it because it may have API changes.
> 
> 
> >> libringclient-git
> >> - a VCS package should always provide its non-VCS package variant like
> >>   'libringclient'
> >> - If there is no strong reason to depend on a git variant, always depend
> >>   on the non VCS, in this case ring-daemon instead of ring-daemon-git
> > 
> > See the above comment on gnome-ring-git.
> 
> And here is the -git hell I describes, either take all -git or none...
> that's not how it should be. Think how it would be if every library
> would be like that, that would mean you need to use -git for the whole
> system just because you switch a single package. Don't enforce it just
> because... if such happens people will figure.

Again, the constraints are a bit different on the AUR and on a binary
repository.  What I try to ensure is that somebody running e.g. "yaourt -S
ring-gnome-git" will not have compilation issues.  If ring-gnome-git
depends on libringclient, then the former will not build if the API
provided by libringclient has changed recently.

But you're right, it's a mess.  I updated the *ring*-git packages so that
they only depend on non-git packages, and they now all provide their
non-git version.

Anyway, I was thinking of orphaning all those -git Ring packages, since I
don't use them anymore and they take time to maintain.

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hi,

On Mon, Nov 28, 2016 at 12:20:40PM +0100, Levente Polyak wrote:
> > Don't hesitate if you have any questions, or comments on my AUR packages!
> 
> Sure, I always take a look at all packages of an applicant and suggest
> changes before I decide how to vote... so here we go :P

Yes, I was expecting this :)

> pjproject
> - if you must use -j1 for every make call, you can simply add
>   !makeflags to the options instead.

Good catch, this was actually copied unchanged from the pjproject package
.

I just tested building in parallel on a 16-core machine, and it works
fine, so I removed the -j1.  The original issue must have been fixed
upstream.

> linux-mptcp
> - #tag= should never be used for git packages, instead store the commit
>   hash for the tag and always use the #tag= prefix. A named tag does not
>   mean much and you won't even notice when upstream changes such.
>   This is especially bad when using plain git:// :-)

Interesting, I had never thought about this issue.

I think I will switch to a tarball as suggested by Eli, I didn't know that
github provides tarballs for each commit.  The downside is that $pkgver
will no longer be computed automatically, I will have to update it
manually.

> - You should add an initramfs post transaction hook like in the regular
>   kernel [0] to avoid problems like described in #51818.

Thanks for the hint, will do.

> ring-daemon:
> - just a feeling but a description with 202 chars feels quite long :P

Is there a hard limit somewhere, maybe in the AUR?

Anyway, upstream has changed its description to a shorter one, so I used
that instead.  It's now "only" 130 chars.

> - you should use git+https:// instead of plain git:// even through the
>   CA world is a bit wonky it still authenticates the server and at the
>   very bare minimum adds confidentiality.

I don't like the "everything-over-HTTP(S)" approach in general, especially
when there is a dedicated protocol that works (yes, I know, this is basic 
ranting).

Assuming the git revision is identified by a commit hash, I see no value
in using HTTPS for authentication or verification.  I agree it is useful
however when building from a tag or a branch, as you correctly pointed out
for another package.

On the other hand, if one day the TLS certificate becomes invalid (expired
certificate, untrusted CA, etc), the package would fail to build.  I see
this as a significant drawback of using git+https://.

> pius
> - documentation, or hint to documentations inside .install files always
>   feels like the wrong place. If there is documentation in
>   /usr/share/doc/pius then people will find it.

I generally agree with this.  In this case, however, the suggested
configuration option is really needed on Arch when using the new Gnupg key
format, and this is not explicitely documented upstream.

I think I will send a patch upstream to fix the issue (auto-detect the
keyring format) and remove the .install file altogether with the next
release.

> ring-gnome-git
> - a VCS package should always provide its non-VCS package variant like
>   'ring-gnome'

Actually, the missing "provides" is intended.  The Ring components are
interdependent and get updated quite frequently, so at any given time
`ring-foo` and `ring-foo-git` are likely offer a different API/ABI.

More practically, when the "provides" was here, I had issues with AUR
users mixing -git and non-git ring packages and complaining of building
errors.

> libringclient-git
> - a VCS package should always provide its non-VCS package variant like
>   'libringclient'
> - If there is no strong reason to depend on a git variant, always depend
>   on the non VCS, in this case ring-daemon instead of ring-daemon-git

See the above comment on gnome-ring-git.

> - the pkgver() function doesn't sound specific enough, it just returns
>   a simple date without anything else (f.e. 20161110) which means
>   building on the same date can result in the same package version while
>   being built from quite different source states.

Good point, I can switch to the `git describe` method used by most of my
other git packages.

> udrawgraph
> - just a bit of style, but we have arch specific depends like
>   depends_x86_64 which looks better :P

Fixed.  This package long predates arch-specific depends.

> tsocks-ipv6
> - this looks like it should also provide tsocks as it just adds
>   additional v6 support

Indeed, fixed.

> coq-doc
> - the sources must be prefixed with the version as otherwise older
>   tarballs will "conflict". on top of that "stdlib.tar.gz" sounds
>   a bit too generic and may overlap with another package, conisder
>   also including the package name into the prefix to avoid such
>   situation.

Fixed.

> - sources that are not unique (like "/v$pkgver.tar.gz" from github)
>   should be prefixed with the package name (+ of cause pkgver) to
>   be unique. This is important if you configures shared SRCDEST to
>   avoid conflicts.

[aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hello,

I would like to apply to become a TU.  Lukas Fleischer has kindly accepted
to sponsor my application.

I am currently a PhD student in France, doing research on networking.  I
am also involved in several projects, in particular DIY ISPs [1], the FDN
Federation in France [2], OpenWRT/LEDE [3], etc.  The common motivation is
to work towards a more open and decentralised Internet.

I have been using Arch Linux on my personal laptops since around 2010.
I think I have never had to reinstall Arch Linux on my main laptop since
then!  In the past, I was also running Arch Linux on my servers, but I
since switched to Debian for all my servers.

By the way, I am not very active on the mailing lists, but I read most
threads on aur-general and arch-dev-public.

In the AUR, I maintain 33 packages [4], of which the most noteworthy are:

- ring: a secure and distributed voice/video/chat communication software
  (Ring is the successor of SFLphone, basically using a DHT to find
  contacts instead of relying on SIP servers, and tons of other
  improvements)

- coq: a formal proof assistant written in Ocaml

- linux-mptcp: the linux kernel with support for Multipath TCP, from
  Université Catholique de Louvain

The other packages I maintain are either dependencies of the above, or
small software tools that I packaged when I needed them.  I regularly use
about 2/3 of these packages, but I still try to maintain the other ones.

I mostly want to become a TU to push ring, coq and linux-mptcp to the
[community] binary repository.  These packages all take a fairly long time
to build, and additionally the Ring packages are a dependency nightmare.
It is often necessary for users to rebuild all dependencies simultaneously
because of API/ABI changes, and this is impractical and time-consuming
when using the AUR, especially given the number of dependencies.

Regarding linux-mptcp, it is not popular enough at the moment, and there
are few kernel packages in binary repositories.  I would wait for the
package to obtain 10 votes (and confirmation that another kernel package
is indeed welcome in the repositories) before pushing it to [community].

As a final note, I am already using the devtools to test-build my AUR
packages in clean chroots on a server.  This provides some form of
"continuous integration" of my AUR packages, although it is not completely
satisfying right now.

Don't hesitate if you have any questions, or comments on my AUR packages!

Baptiste

[1] https://diyisp.org/dokuwiki/doku.php
[2] https://www.ffdn.org/en
[3] https://lede-project.org/
[4] https://aur.archlinux.org/packages/?O=0=m=zorun=v=d


signature.asc
Description: PGP signature

Re: [aur-general] Upstream version numbers that break pacman version comparison

[Baptiste Jonglez]

On Tue, Nov 22, 2016 at 11:28:40AM +, Giancarlo Razzolini wrote:
> Em novembro 22, 2016 6:35 Baptiste Jonglez escreveu:
> >Interesting, thanks.  However, upstream starts each new minor version at
> >p1, so it looks like:
> >
> >7.2p1 → 7.2p2 → 7.3p1 → etc
> >
> 
> Worth nothing that OpenSSH releases the so called "portable" versions. Hence
> the 'p'.

You're right, it's not the same semantic.

> >which works fine for pacman.  The problematic behaviour for pacman would
> >be:
> >
> >7.2p1 → 7.2p2 → 7.3 → 7.3p1 → etc
> >
> >In the case of coq, I guess this is something that should ideally be fixed
> >upstream.
> >
> 
> What a horrible, ugly way to version packages. If they could fix it upstream,
> its better. And it might even benefit other distributions.

Totally agreed.

I reported the bug upstream [1], and it turns out the maintainers have
already planned a more reasonable versioning scheme for the next version.
So, problem (most likely) solved!

Thanks,
Baptiste

[1] https://coq.inria.fr/bugs/show_bug.cgi?id=5221


signature.asc
Description: PGP signature

Re: [aur-general] Upstream version numbers that break pacman version comparison

[Baptiste Jonglez]

On Tue, Nov 22, 2016 at 03:12:58AM -0500, brent timothy saner via aur-general 
wrote:
> It's worth noting openssh uses the same versioning naming (though i
> don't see what's so hard to mentally replace the last minor with a p in
> front).
> 
> Here's the PKGBUILD:
> 
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/openssh

Interesting, thanks.  However, upstream starts each new minor version at
p1, so it looks like:

7.2p1 → 7.2p2 → 7.3p1 → etc

which works fine for pacman.  The problematic behaviour for pacman would
be:

7.2p1 → 7.2p2 → 7.3 → 7.3p1 → etc

In the case of coq, I guess this is something that should ideally be fixed
upstream.

Baptiste


signature.asc
Description: PGP signature

[aur-general] Upstream version numbers that break pacman version comparison

[Baptiste Jonglez]

Hi,

I maintain a package in the AUR [1], coq [2], whose upstream versioning
scheme is a bit strange.

Basically, they release versions in the following order:

8.4 → 8.4pl1 → 8.4pl2 → 8.5 → 8.5pl1 → etc

This breaks pacman's comparison function.  For instance, with a local
repo, pacman does not consider that the new version 8.5pl3-1 is newer than
the old 8.5-1:

# pacman -Syu
warning: coq: local (8.5-1) is newer than repo (8.5pl3-1)

This makes sense given the documented behaviour of pacman(8):

When upgrading, pacman performs version comparison to determine which
packages need upgrading. This behavior operates as follows:

Alphanumeric:
  1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc < 1.0 < 1.0.a < 1.0.1
Numeric:
  1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0

What is the best solution to deal with this?  I think I can either map the
scheme to a more reasonable one (e.g. "8.5.pl3" instead of "8.5pl3"), or
bump the epoch when needed.

Thanks,
Baptiste

[1] https://aur.archlinux.org/packages/coq/
[2] https://coq.inria.fr/


signature.asc
Description: PGP signature

Re: [aur-general] Trusted User application

[Baptiste Jonglez]

On Sun, Jul 24, 2016 at 05:51:52PM +0900, Nicola Squartini via aur-general 
wrote:
> Evolution shows "Good signature" to me.
> 
> On Sun, 2016-07-24 at 09:00 +0530, Pierre Neidhardt via aur-general
> wrote:
> > Don't want to sound picky, but it seems like the PGP signature of your 
> > e-mail is
> wrong :p

Same as Pierre here.  For your second mail from today:

gpg: Signature made Sun 24 Jul 2016 10:51:52 AM CEST
gpg:using RSA key C847B6AEB0544167
gpg: BAD signature from "Nicola Squartini " [unknown]


signature.asc
Description: PGP signature

Re: [aur-general] PKGBUILD for GnuSocialShell

[Baptiste Jonglez]

On Wed, Jul 13, 2016 at 12:30:53PM -0400, Storm Dragon via aur-general wrote:
> Howdy,
> I have no clue how it got set to crlf. I made this in Vim on Arch lol. I 
> guess the original was from a template with the wrong format. This is fixed 
> now, however.
> I also think I have a working fix for the version issue.
> This really does compile on any architecture, including ARMv7 etc.

'any' is for packages that can be installed unchanged on any architecture
(think of python or perl scripts, or just data with no binary program).

A compiled program must use an explicit array of architectures, not 'any'.

> I applied your patch and did a pull request, thanks so much for providing 
> that. Also, thank you for the tips.
> Storm
> 
> On Tue, Jul 12, 2016 at 08:05:43PM -0300, Rafael Fontenelle wrote:
> >2016-07-12 19:55 GMT-03:00 Rafael Fontenelle :
> >
> >>
> >>2016-07-12 13:01 GMT-03:00 Storm Dragon via aur-general <
> >>aur-general@archlinux.org>:
> >>
> >>>Howdy,
> >>>I am working on a PKGBUILD for a new GNU Social client called
> >>>GnuSocialShell. I made one for the git version, because this is being
> >>>rapidly developed, and I don't believe there is an actual release yet
> >>>anyway. The problem is, it haults with an error when trying to copy files
> >>>in place, and I'm not sure why. I have gone over this file and can't find
> >>>anything wrong with it. It's probably something simple I'm just overlooking
> >>>though.
> >>>Thanks for any help :)
> >>>Storm
> >>>
> >>
> >>Hello there.
> >>
> >>My comments on this situation and your PKGBUILD:
> >>
> >>1st - The PKGBUILD has CRLF. You need to format it to Unix (use 'dos2unix'
> >>command)
> >>
> >>2nd - Your command line to get version doesn't seem to be correct.
> >>'Main.c' reports current version 0.8, just like 'git shortlog' history
> >>shows. But you've got '1' from what doesn't look to be a version. Please
> >>review that.
> >>
> >>3rd - Not the main issue, but remember to set arch (don't use 'any')
> >>
> >>4th - Makefile is copying files to directly to '/etc' and '/usr', instead
> >>of allowing fakeroot to work with a variable like $(DESTDIR) before that
> >>path. That's an upstream bug, that can be fixed with the attached patch
> >>
> >>5th - Makefile tries to copy to directories without making sure they
> >>exist. Again, upstream bug fixed with my patch.
> >>
> >>My suggestion is to fix yourself the first 3 issues and file a bug report
> >>for the last 2.
> >>
> >>Best regards,
> >>Rafael Fontenelle
> >>
> >
> >Now with attachment.
> >
> >Rafael Fontenelle




signature.asc
Description: PGP signature

Re: [aur-general] PKGBUILD: depends vs. makedepends and namcap warning

[Baptiste Jonglez]

On Mon, Jul 11, 2016 at 11:28:25AM +0200, Lukas Böger wrote:
> Next question: should compiler requirements be part of a PKGBUILD?

No, all packages in base-devel are assumed to be already installed when
using makepkg.

> In this case, when compiling with gcc, version >=4.9 is necessary.

gcc is currently at 6.1.1, so version>=4.9 is already statisfied.  We are
a rolling release, remember :)

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] PKGBUILD: depends vs. makedepends and namcap warning

[Baptiste Jonglez]

On Mon, Jul 11, 2016 at 10:18:32AM +0200, Lukas Böger wrote:
> Dear AUR list,
> 
> simple question about dependencies in PKGBUILDs:
> 
> Package A provides some header files and build scripts. Package B
> provides additional headers, and their usage only work out if A's
> headers are in place. Additionaly, package B can only be compiled using
> A's build scripts.
> 
> 1) Is it correct to have package A in B's depends AND makedepends arrays?

In general, no.  If you need a dependency both at compile time and at
runtime, you should put it in depends only.

> 2) Am I supposed to ignore namcap's warning 'Dependency included and not
> neede' because it doesn't take header dependencies into account?

It seems similar to this situation: https://bugs.archlinux.org/task/48277

Basically, your package B looks like a library.  B should only makedepends
on A, and any package depending on B should also makedepends on A.

The rationale is that header files and build scripts are not needed to run
a program, so they should not be installed as dependencies.  They should
only be installed as makedepends, for every package that needs them (even
indirectly).

One such example is boost:

  https://www.archlinux.org/packages/extra/x86_64/boost/

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] Cannot push changes on a PKGBUILD.

[Baptiste Jonglez]

On Sun, Jul 03, 2016 at 01:34:16PM +0200, fredbezies via aur-general wrote:
> Hello.
> 
> Is there a problem with AUR servers ? I tried to upgrade my PKGBUILD
> for easytag git, and here is the error I get :
> 
> fatal: unable to access 'https://aur.archlinux.org/easytag-git.git/':
> The requested URL returned error: 403
> 
> Any idea ? Thanks !

You need to use SSH for git access, not HTTPS.


signature.asc
Description: PGP signature

Re: [aur-general] PKGBUILDs for monkeysphere feedback

[Baptiste Jonglez]

On Wed, Jun 22, 2016 at 02:47:09PM +0200, Valo wrote:
> Il 22/06/2016 12:12, Baptiste Jonglez ha scritto:
> > That is, can it be used and be useful without monkeysphere?  If so, it
> > could make sense to provide it as a separate package, 
> As for package description:  "|Copy a secret key from GnuPG's gpg-agent
> to OpenSSH's ssh-agent|"
> 
> It *can* be used outsite of monkeysphere but I don't know if it *will* :)
> > but I think you
> > should implement it as a split package then (since both monkeysphere and
> > agent-transfer "build" from the same source).
> I thought about it but I wasn't able to understand from the wiki how I
> should proceed aside from the array of package names, can you point me
> to a good PKGBUILD I cant learn from?

Look at "man PKGBUILD", section "PACKAGE SPLITTING"

> > Of course, to avoid over-engineering, you could just have a single package
> > bundling both monkeysphere and agent-transfer.  Judging from [2], this is
> > what is intended by upstream.
> Yup, I thought it as well but couldn't figure out how to resolve the
> checkdependency on agent-transfer of monkeysphere without packaging it
> on it's own. As the software is about security I feel like running the
> tests upstream provide is very important and during the tests
> agent-transfer is called, without it tests will not succeed.

Ah, ok, I misunderstood your problem.  So, the split package idea will
definitely not help, because build() and check() are called before running
package_foo() and installing the packages.  This means that agent-transfer
will not be available in $PATH.

> > - I'm not sure about the convention for adding users/groups [5].  Looking
> >   at a few packages [6,7,8], it seems that UID and GID are hard-coded, but I
> >   don't know if there is a registry.  At the very least, you should create
> >   a system user (-r option to useradd), because otherwise the UID will
> >   fall into the user range 1000+.
> Great! I'll add the -r option as I don't feel like hardcoding a UID and GID.

Yes, I don't think there actually is a convention for this.

That being said, don't you think you should remove the user/group when
uninstalling the package?

  
https://aur.archlinux.org/cgit/aur.git/tree/monkeysphere.install?h=monkeysphere

Baptiste


signature.asc
Description: PGP signature

Re: [aur-general] PKGBUILDs for monkeysphere feedback

[Baptiste Jonglez]

Hi Valo,

On Wed, Jun 22, 2016 at 11:30:57AM +0200, Valo wrote:
> As gnupg 2.1.13 is now available in core I'd like to update monkeysphere
> to 0.38, here are the PKGBUILDs for monkeysphere[2] and for
> agent-transfer[1], a new monkeysphere checkdependency.
> 
> Agent-transfer is included in the monkeysphere source code but it's a
> checkdependency and so I choose to create a separate package for it, is
> it correct? How can I make it better?

Do you think that agent-transfer is a useful package in its own right?
That is, can it be used and be useful without monkeysphere?  If so, it
could make sense to provide it as a separate package, but I think you
should implement it as a split package then (since both monkeysphere and
agent-transfer "build" from the same source).

Of course, to avoid over-engineering, you could just have a single package
bundling both monkeysphere and agent-transfer.  Judging from [2], this is
what is intended by upstream.

Also, some minor nitpicks:

- you have a small typo in agent-transfer ("makedepens")

- the "gcc" makedepends is not needed, because it is in base-devel [1]

- as you have apparently figured out, installing in /usr/sbin/ is not
  recommended [3], but I don't think it's worth patching the source [4].
  /usr/sbin is a symbolic link to /usr/bin anyway.

- I'm not sure about the convention for adding users/groups [5].  Looking
  at a few packages [6,7,8], it seems that UID and GID are hard-coded, but I
  don't know if there is a registry.  At the very least, you should create
  a system user (-r option to useradd), because otherwise the UID will
  fall into the user range 1000+.

Thanks for maintaining the package!
Baptiste

[1] https://wiki.archlinux.org/index.php/PKGBUILD#makedepends
[2] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/exclude-agent.patch
[3] https://wiki.archlinux.org/index.php/Arch_packaging_standards#Directories
[4] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/binmerge.patch
[5] https://git.eigenlab.org/svalo/monkeysphere/blob/0.38/monkeysphere.install
[6] 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/ntp.install?h=packages/ntp
[7] 
https://git.archlinux.org/svntogit/community.git/tree/trunk/tor.install?h=packages/tor
[8] 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=packages/mpd


signature.asc
Description: PGP signature

Re: [aur-general] Continuous integration of AUR packages

[Baptiste Jonglez]

Hi,

On Thu, Feb 18, 2016 at 12:25:53PM +, Justin Dray wrote:
> I actually have a Jenkins setup for my packages that does almost exactly
> that, I have a job generator build that I give an AUR package name to and
> that's all the config for new packages, and it builds them in a docker
> container.
> 
> You can obviously set up dependencies between the jobs to build in order,
> but that part isn't automatic yet. Its been pretty reliable for me over the
> past year or so since I last really changed anything.
> 
> If you're interested, let me know and I can share the scripts and stuff.
> Just on my phone at the moment or I would link them here.

Yes, I would be interested!

Out of curiosity, why do you use docker containers instead of the
"official" method with chroots?

  https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot


> Cheers,
> Justin
> 
> On Thu, Feb 18, 2016, 9:51 PM Baptiste Jonglez <bapti...@bitsofnetworks.org>
> wrote:
> 
> > Hi,
> >
> > I would like to run some kind of continuous integration of my AUR
> > packages.  The goal is to know when a package I maintain fails to build
> > because either:
> >
> > 1/ its dependencies have been updated (new API, new incompatible version
> >of GCC, ...)
> >
> > 2/ for -git packages, changes made upstream broke something (new
> >dependency needed, new build system...)
> >
> > The scripts in devtools [1] look like they should work just fine to
> > automate these kind of builds.  After all, they are used to build the
> > official Archlinux packages.
> >
> > However, I found that the build scripts do not really handle dependencies.
> > When building a given package, they just install deps and makedeps from
> > the existing Archlinux repositories.  This is an issue when AUR packages
> > depend on each other, because then dependencies cannot be installed from
> > the Archlinux repositories...
> >
> > It *is* possible to manually pass packages to install in the chroot before
> > building, but this is far from convenient.  For instance, ring-daemon
> > depends on opendht, so I would need to do this:
> >
> > cd opendht
> > extra-x86_64-build
> > cd ../ring-daemon
> > extra-x86_64-build -- -I ../opendht/opendht-0.5.1-1-x86_64.pkg.tar.xz
> >
> > When there are multiple dependencies, it quickly becomes a nightmare to
> > automate (especially because dependencies need to be passed in the right
> > order).
> >
> > Is there any script that automates dependency handling when building?
> > Basically, it would probably need to perform a topological sort, build
> > packages in this order, and push them to a local repository to be able to
> > build later packages.
> > Or did I take the wrong approach entirely?
> >
> > Thanks,
> > Baptiste
> >
> > [1] https://projects.archlinux.org/devtools.git/
> >
> > PS : Some existing efforts I found about CI with Arch:
> >
> > -
> > https://lists.archlinux.org/pipermail/arch-dev-public/2014-November/026757.html
> >   https://jenkins.arch-ci.org/
> >   No script provided, site appears to be down
> >
> > - http://openbuildservice.org/2012/09/10/arch-linux-support/
> >   Source code is unreadable (enormous Perl scripts, no modularity)
> >
> >


signature.asc
Description: PGP signature

[aur-general] Continuous integration of AUR packages

[Baptiste Jonglez]

Hi,

I would like to run some kind of continuous integration of my AUR
packages.  The goal is to know when a package I maintain fails to build
because either:

1/ its dependencies have been updated (new API, new incompatible version
   of GCC, ...)

2/ for -git packages, changes made upstream broke something (new
   dependency needed, new build system...)

The scripts in devtools [1] look like they should work just fine to
automate these kind of builds.  After all, they are used to build the
official Archlinux packages.

However, I found that the build scripts do not really handle dependencies.
When building a given package, they just install deps and makedeps from
the existing Archlinux repositories.  This is an issue when AUR packages
depend on each other, because then dependencies cannot be installed from
the Archlinux repositories...

It *is* possible to manually pass packages to install in the chroot before
building, but this is far from convenient.  For instance, ring-daemon
depends on opendht, so I would need to do this:

cd opendht
extra-x86_64-build
cd ../ring-daemon
extra-x86_64-build -- -I ../opendht/opendht-0.5.1-1-x86_64.pkg.tar.xz

When there are multiple dependencies, it quickly becomes a nightmare to
automate (especially because dependencies need to be passed in the right
order).

Is there any script that automates dependency handling when building?
Basically, it would probably need to perform a topological sort, build
packages in this order, and push them to a local repository to be able to
build later packages.
Or did I take the wrong approach entirely?

Thanks,
Baptiste

[1] https://projects.archlinux.org/devtools.git/

PS : Some existing efforts I found about CI with Arch:

- 
https://lists.archlinux.org/pipermail/arch-dev-public/2014-November/026757.html
  https://jenkins.arch-ci.org/ 
  No script provided, site appears to be down

- http://openbuildservice.org/2012/09/10/arch-linux-support/
  Source code is unreadable (enormous Perl scripts, no modularity)



signature.asc
Description: PGP signature