Re: [arch-dev-public] [aur-general] AUR migration
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: [arch-dev-public] [aur-general] AUR migration
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: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
Hi, On 29-06-20, Andreas Radke via arch-dev-public wrote: > I'm going to remove the unneeded dependency on xorg-fonts-alias package > from various font packages where it doesn't belong. FYI, I had old font packages on my system that (obviously) still have this dependency, causing upgrade to fail: :: xorg-fonts-alias-100dpi and xorg-fonts-alias are in conflict. Remove xorg-fonts-alias? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: removing xorg-fonts-alias breaks dependency 'xorg-fonts-alias' required by fonts-tlwg :: removing xorg-fonts-alias breaks dependency 'xorg-fonts-alias' required by ttf-cheapskate :: removing xorg-fonts-alias breaks dependency 'xorg-fonts-alias' required by ttf-mph-2b-damase :: removing xorg-fonts-alias breaks dependency 'xorg-fonts-alias' required by ttf-ubraille This is only midly annoying because I should have cleaned those up long ago, but maybe put a notice on the website about this change? Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Disowning the Kea DHCP server package
On 05-06-20, Baptiste Jonglez wrote: > Hi, > > I don't use Kea on Arch anymore, and I don't have the time and energy to > maintain it in [community]. > > It's currently stuck at 1.5.0. Kea 1.6 came out 9 months ago, but it > moved some files around and would require extensive testing to make sure > everything still works as expected. In case somebody wants to adopt it straight away, here is the upstream doc about the changes in Kea 1.6: https://gitlab.isc.org/isc-projects/kea/-/wikis/migrating-to-kea-1.6 > If somebody is interested in maintaining it, please adopt the package, > otherwise I will move it to the AUR this summer. > > FYI, it has a quite low usage according to pkgstats: > https://pkgstats.archlinux.de/packages#query=kea > > Baptiste signature.asc Description: PGP signature
[arch-dev-public] Disowning the Kea DHCP server package
Hi, I don't use Kea on Arch anymore, and I don't have the time and energy to maintain it in [community]. It's currently stuck at 1.5.0. Kea 1.6 came out 9 months ago, but it moved some files around and would require extensive testing to make sure everything still works as expected. If somebody is interested in maintaining it, please adopt the package, otherwise I will move it to the AUR this summer. FYI, it has a quite low usage according to pkgstats: https://pkgstats.archlinux.de/packages#query=kea Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Orphaning crypto++
Hi, On 06-12-19, Maxime Gauduin via arch-dev-public wrote: > Hi Baptiste, > > Since I have 2 packages depending on it, I may have to take it off your > hands. Thanks for the proposal, having a maintainer that actually uses the package will be a real improvement over the current situation! > That said, I've been considering dropping clementine to AUR for a > while. It needs a lot of patching, is built from an unstable qt5 > branch, and has a lot of better alternatives, including a fully > featured qt5 fork named strawberry. > > rbutil is another beast, they release once every 10 years and crypto++ > was introduced in the very latest that was released less than a month > ago. I don't think there's a solution for this one. I had a look and indeed, rbutil really needs crypto++: https://git.rockbox.org/?p=rockbox.git;a=commit;h=dbeb6db1b55a50dedf17e7d78ddb6fe9eebc2a63 https://git.rockbox.org/?p=rockbox.git;a=commit;h=8b3f5a8ad7434850804a4a664d2b07c6ffa9b1c7 https://git.rockbox.org/?p=rockbox.git;a=commit;h=759a78e5dff134f2632875f61aae60815eea6f5b So, if you want to keep rbutil, crypto++ should indeed stay in our repositories as well. Baptiste signature.asc Description: PGP signature
[arch-dev-public] Orphaning crypto++
Hi, I plan to orphan crypto++ [1] soon: I don't maintain any package that depends on it anymore, and it's becoming annoying to maintain. For instance, there was a significant security issue on July 2019 [2], and 5 months later there is still no upstream release even though a patch is available [3]. I just patched the Arch package but it raises the question of whether we want to have such a crypto library in our repositories. Here are the packages that currently depend on crypto++: - amule - clementine - kvazaar - rbutil - ceph (makedepends) If nobody steps up to adopt it before December 20th, I will drop it to the AUR. In that case, I will send a reminder to find a solution for the above packages. Thanks, Baptiste [1] https://www.archlinux.org/packages/community/x86_64/crypto++/ [2] https://security.archlinux.org/CVE-2019-14318 [3] https://github.com/weidai11/cryptopp/issues/869 signature.asc Description: PGP signature
Re: [arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
Hi, On 06-08-19, Jürgen Hötzel wrote: > Hi, > > Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08. In the meantime, camlp4 got a (last) update to build with OCaml 4.08: https://github.com/ocaml/camlp4/issues/151#issuecomment-519074190 https://github.com/ocaml/camlp4/releases As the ticket says, this is the final update for camlp4, so we have to be prepared for OCaml 4.09 and beyond. > But some well known packages depend on this preprocessor. E.g. :Haxe, > lablgtk2 (therefore also: Unison and Coq). Eli is right here, camlp4 is not needed for release versions of lablgtk2. From http://lablgtk.forge.ocamlcore.org/changes2.txt : 2016.03.06 [Jacques] * remove build dependency on camlp4 (still needed for tree version) On a slightly related note, lablgtk3 seems to be progressing nicely, and support has been recently added to Coq (it will be part of the upcoming 8.10 release): http://lablgtk.forge.ocamlcore.org/ https://github.com/coq/coq/pull/9279 > I don't see that these projects will be migrated to camlp5 or ppx in the > near future. Therefore there are only 2 options from my point of view: > > 1. OCaml-4.07 and Ocaml >= 4.08 in [EXTRA]. > 2. removal of Haxe, lablgtk2, Unison and Coq. > > I prefer 1. What do you think? > > Same issue discussed on Debian Bug Tracker: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933722 So, now the situation has unblocked. Feel free to rebuild my OCaml packages, or open a TODO list and I will rebuild them. Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
Hi, On 24-03-19, Robin Broda via arch-dev-public wrote: > So, TL;DR, the benefits of `zstd -c -T0 -18 -` over `xz -c -z -` are: > - Massive speed gain in compression > - Massive speed gain in decompression > - Stable, reproducible multithreading > The speed gain in decompression substantially increases pacman's package > installation speed. Interesting results, thanks! Just one detail: your results for -19, -20 and -21 are identical because apparently zstd needs an additional flag (--ultra) to "unlock" the higher compression levels: zstd -c -T0 -20 - Warning : compression level higher than max, reduced to 19 Also, I see you did not test zstd with a small number of cores: can you add e.g. -T1, -T2 and -T4 to the comparison? It would give a more realistic idea of what to expect when building on a typical machine, as opposed to dragon ;) In my tests, using less threads also decreased memory usage when compressing (35% less memory when switching from -T2 to -T1). For decompression, it seems that both xz and zstd run single-threaded, so there's not much to think about (zstd is just incredibly fast). In any case, I support this change! Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Uploading old packages on archive.org (Was: Archive cleanup)
Hi, Archival of all packages between September 2013 and December 2016 is finished: https://archive.org/details/archlinuxarchive Here is some documentation on this "Historical Archive" hosted on archive.org: https://wiki.archlinux.org/index.php/Arch_Linux_Archive#Historical_Archive Happily, we were able to provide download redirection from orion to this Historical Archive. This means that e.g. https://archive.archlinux.org/repos/2013/09/01/ should continue to work fine, even though the actual packages are served from archive.org. To provide this, we only need to keep an archive of the database files on orion. This represents around 50 files per day of archive, while the packages themselves represent about 25k hardlinks and symlinks per day of archive. So that's a real saving of inodes! Please test things out and let me know if you encounter any issue! (other than "downloading from archive.org is slow", because it indeed is) If everything works well, Florian will delete the old packages on orion in a few days. Thanks, Baptiste signature.asc Description: PGP signature
[arch-dev-public] Alioth retirement and tarball archive
Hi, There is some good news about the retirement of Alioth [1]: the Debian people have finally decided to keep an archive of all the tarballs! They are available at [2]. I've updated the TODO description: with this archive and the new gitlab for -git projects, it should cover all of our packages that depended on Alioth. Baptiste [1] https://www.archlinux.org/todo/alioth-retirement/ [2] https://alioth-archive.debian.org/releases/ signature.asc Description: PGP signature
[arch-dev-public] Uploading old packages on archive.org (Was: Archive cleanup)
Hi, Here is the progress on the upload of old packages to archive.org. I uploaded a few packages to test if my script works: https://archive.org/details/archlinux_pkg_babeld https://archive.org/details/archlinux_pkg_kde-l10n-ca_valencia https://archive.org/details/archlinux_pkg_lucene__ There is one identifier for each package, and then all versions of the package + their signatures are contained under this identifier (see "Show all" on the right). Now, to finish this, I have a few questions: - does the devops team have a place to store passwords? I would like to create an "Arch Linux" account, so that I'm not the only one to have access. I also need an email address for the account, maybe something like internetarchive at archlinux.org or just the devops mailing list address? - is that OK to upload ~2 TB from orion? Is the server on an limited data plan? - I'm still waiting on a final confirmation from archive.org, whether they are OK with this amount of data. The upload process itself is quite slow latency-wise, it takes 5-10 seconds to upload a file whatever its size. For packages from 2013 to 2015 there's 250k files to upload, I estimate it will take a few days if I run 32 upload threads in parallel. By the way, we could even keep the year/month/day symlink hierarchy on orion for old packages, and redirect downloads to archive.org. There is just a small issue with packages that have "+", "@" or "." in their name, because that's not allowed as identifiers in archive.org (see the second and third examples above, where my script replaced the "@" with "_") Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Archive cleanup (2013, 2014, 2015)
On 30-05-18, Florian Pritz wrote: > On 30.05.2018 17:49, Baptiste Jonglez wrote: > > What about sending previous years to the Internet Archive before deleting > > them locally? > > I myself am not interested enough in keeping the old packages to figure > out what rules the Internet Archive has and how I could upload all this > data to them. If you are interested in this, please check with them if > they are ok with adding this much data and if so, feel free to go to > /srv/archive/ on orion and upload the files. If you do that I'll wait > with deleting things until you are done. If you need any tools installed > on the server to do this, tell me. Ok, thanks, I will give it a shot in the next few days then! Their software [1] is written in python, so can you please install these packages: python-pip python-args python-clint python-docopt python-jsonpointer python-jsonpatch python-yaml It should be enough to allow me to install the client locally. Baptiste [1] https://github.com/jjjake/internetarchive signature.asc Description: PGP signature
Re: [arch-dev-public] Archive cleanup (2013, 2014, 2015)
Hi, On 30-05-18, Florian Pritz via arch-dev-public wrote: > So far we haven't ever cleaned up the archive > (https://archive.archlinux.org/), but it's getting too big and I don't > think we have any use for packages from years ago. You never know what useful things people could do with this historical data. What about sending previous years to the Internet Archive before deleting them locally? They already host quite a lot of software: https://archive.org/details/software Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] New build server in the US?
Hi, My proposal was basically « here is a possibly cheap opportunity for a nice new build server ». If it turns out that it requires more work to support and that we can afford renting a commercial server, or that we actually don't need a new build server, it's fine. On 19-04-18, Florian Pritz via arch-dev-public wrote: > We already have a second build server (sgp.pkgbuild.com) which is hardly > used. I always thought that sgp would be much slower because of I/O (soyuz builds everything in a ramfs, while sgp.pkgbuild.com does not). But after testing, it turns out that the difference is not that big: for community/coq, it takes around 7 minutes to build on soyuz and around 8 minutes on sgp.pkgbuild.com. > Souyz is really used quite a bit, but in general it has quite some > resources left to spare. I guess it depends on what you want and when. > Do you want to get builds done quickly (like on a local machine) or are > you happy with waiting until the machine is free? Maybe someone wants to > work on a system that allows to pause builds if people don't care when > they finish so that those that want them done quickly get priority? That > way we could possibly use our available resources better. Maybe it's > even as simple as queuing builds, but I don't know how long the builds > that people run on soyuz take. If a single build takes an hour, queuing > won't really work. Running several builds simultaneously is often not an issue, because many build steps are sequential (installing dependencies, final compression...). So simultaneous builds of small packages won't slow each other down. It becomes an issue when one of the package being built is huge and well parallelised (chromium, llvm, libreoffice...). In that case, a second package build is really slowed down. The new machine with 32 threads would be nice on that perspective, because we could build each package with e.g. -j20 and still get good performance with simultaneous builds. > Some feedback on how people use soyuz would probably help a lot here. > What are your build times, how quickly do you want the result, do you > need to see live output, does the latency to the machine matter > (interactive usage?), ...? I use soyuz mostly interactively: I have a script that copies the sources to soyuz, builds through SSH, then copies back the built packages. I do often look at the output, and I expect a build to take a couple of minutes at most. Maybe we should just nice our builds when they are big and we don't care about the extra runtime: nice -n10 extra-x86_64-build > Regarding the OSUOSL idea: I'm slightly against getting machines from > yet another organisation. While it doesn't matter much during normal > operation, fixing problems is usually more difficult because things like > getting a live system booted, getting serial console access or even just > getting support are often not easily possible when servers are hosted at > companies that don't see hosting as a core goal. We've had this happen > before and it's not great. I don't know what the situation is for this > offer, but let's not rush into creating even more work for us. Good point, support is often a pain, especially if you're not in the same timezone. In this case, hosting is a core goal of OSUOSL, and they generally provide good support (they pay students to provide support, and in my experience they are really helpful). But of course it's always possible to have bad luck. > > I honestly have no idea about Arch's financial situation, or how soyuz is > > paid for in practice. > > Soyuz is a rented server at hetzner.de (like all our other important > servers) and payed for with donation funds. > > Looking at a recent treasury report from SPI[1] we have around $47k > right now and looking back a few months, it seems to be growing. > > [1] http://lists.spi-inc.org/pipermail/spi-general/2018-April/003845.html Ok, so there is no financial issue then. Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Unit tests for python packages
On 18-04-18, Levente Polyak wrote: > On April 18, 2018 11:53:01 AM GMT+02:00, Baptiste Jonglez > wrote: > >So far, the only working solution I found is playing with PYTHONPATH: > > > >cd "$srcdir/$pkgname-$pkgver/tests" > >export PYTHONPATH="$srcdir/$pkgname-$pkgver/src" > >python -m unittest discover > > > > If you use a build function there shouldn't be any problems like 2to3 > while running tests, everything should be converted / build and > generated for the use of tests. I do use a build function: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-pybtex The problem is that this package is written in python2 and relies on 2to3. If I just run the tests with python3 in the source directory, like this: cd "$srcdir/pybtex-$pkgver" export PYTHONPATH="$srcdir/pybtex-$pkgver" nosetests it fails with lots of syntax errors, because the code is python2. I tried to run the tests in the build directory, where 2to3 has been applied: cd "$srcdir/pybtex-$pkgver/build/lib" export PYTHONPATH="$srcdir/pybtex-$pkgver/build/lib" nosetests It works better, but a lot of tests fail because they can't load some stuff from the package: https://paste.aliens-lyon.fr/vam The same tests with python2 work fine in the source dir, and fail in the build/lib dir. So there's something strange going on with the build dir. > For certain upstream test setups there won't be much you can do other then > PYTHONPATH but as mentioned with a build function it should always work. > You can give python-pytest-runner a go, it does proper resolution while > running "python setup.py test" but requires certain ways the whole test > suites are wired. It looks like this will only work for packages that use pytest? Thanks, Baptiste signature.asc Description: PGP signature
[arch-dev-public] New build server in the US?
Hi, OSUOSL [1] in the US has several "new" refurb servers with dual Xeon E5-2660. Each machine has a total of 16 cores / 32 threads and 140 GB RAM, so that would make nice build machines. Would this be useful to the dev community? Soyuz is a bit overloaded at times, and people in the US/Canada might appreciate the lower latency. The hosting conditions are described here: http://osuosl.org/services/hosting/ Regarding money, OSUOSL works through donation: if we ask for a server and we have money, it would be nice to support them financially. I honestly have no idea about Arch's financial situation, or how soyuz is paid for in practice. Let's discuss this! Baptiste [1] http://osuosl.org signature.asc Description: PGP signature
[arch-dev-public] Unit tests for python packages
Hi, Does anyone have experience with unit tests for python packages? It's really useful to spot missing runtime dependencies, but it's a pain to get to work. Here is what I saw: 1) just running "python -m unittest discover" or "nosetests" or equivalent in the check() function does not work, because the package is not yet installed (so all imports will fail) 2) setuptools is supposed to have a unittest integration such that "python setup.py test" should work out of the box, but in my case it never finds any tests to run 3) I've seen some more... "creative" solutions :) https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-coverage#n28 So far, the only working solution I found is playing with PYTHONPATH: cd "$srcdir/$pkgname-$pkgver/tests" export PYTHONPATH="$srcdir/$pkgname-$pkgver/src" python -m unittest discover But it's a hack, and it probably won't work with things like 2to3. Any better ideas? Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
Hi, On 10-03-18, Antonio Rojas via arch-dev-public wrote: > 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? This sounds like a good idea, with a small caveat: I have seen a few projects implement some form of: if (NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE Release) endif () That is, for these projects, CMAKE_BUILD_TYPE defaults to "Release" if not set. Thus, I suggest we explicitely set the build type to "None" instead. Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
On 14-02-18, Allan McRae via arch-dev-public wrote:
> Just because I had to look up the details of this
>
>
> - xorgproto replaces a lot of packages, including fontsproto:
> :: Replace fontsproto with extra/xorgproto? [Y/n]
>
> - libxfont requires fontsproto, so this causes the following:
> :: libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'
>
>
> - people with systems older than 2016-11-16, may have libxfont as
> xorg-server depended on it until that time. Now xorg-server depends on
> libxfont2.
>
> - libxfont2 does not replace libxfont, as it is a completely different API.
>
> - libxfont was removed from the Arch repos somewhere in April or May
> 2017. So nothing official depends on libxfont.
>
>
> I don't think it is unreasonable to expect people to run "pacman -Qi
> libxfont", see it was installed as a dependency and no package depends
> on it and remove it. There also does not seem to be a correct way of us
> to handle this - joys of rolling release!
Thanks for the detailed analysis with the dates. I see now that using the
replaces() field in this case is technically incorrect.
I was annoyed by this issue which seemed simple to fix, and consequently
pissed off by Eli's violent and insulting reaction on the bug tracker.
I still think it is wholly inappropriate to treat people this way
(whatever the reasons, eleventh reopen request or not), but Eli, please
accept my apologies for rounding up on you based on murky assumptions.
> Funny thing... people using yaourt probably removed this package as I
> believe it highlights dependencies that are no longer needed after an
> upgrade!
> On 14/02/18 22:28, Florian Pritz via arch-dev-public wrote:
> > How about having this feature in pacman, maybe with an indicator if the
> > package is still in a repository?
>
> pacman -Qtd
For the same list, but filtered on packages that are not in any repository
("foreign" packages):
pacman -Qtdm
signature.asc
Description: PGP signature
Re: [arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
On 13-02-18, Eli Schwartz via arch-dev-public wrote: > On 02/13/2018 06:56 PM, Baptiste Jonglez wrote: > > Hi, > > > > Eli and I disagree about how dependency conflicts should be handled when > > packaging. This was prompted by the libxfont dependency conflict arising > > from recent xorgproto changes [1]. > > > > [...] > > > > [1] https://bugs.archlinux.org/task/57495 > > Is there a reason you took a private disagreement to the public mailing > lists: > > - regarding which you have confused me for the primary person > disagreeing with you > - when in fact there are three people who directly disagree with you on > that very issue, as I told you in that private discussion > - regarding which this public post seems to essentially exist in order > to, I dunno, shame me into responding in view of the world at large, > again despite my not being the only or indeed the primary person who > you are actually disagreeing with? I'm sorry if you feel offended, but I'm not sure what I am shaming you into exactly. - I initially thought I had a disagreement with you, because you were the one I saw closing bug reports about the issue. This is why I emailed you directly. - your answer made it clear that we *do* disagree, but you also said that your position is shared with other members of the community: what you called "a longstanding tradition of not considering these type of issues to be valid bugs", and the fact that Doug and arojas also closed bug reports about the issue. - so, I decided to start a public discussion about the issue, with the starting point that we *do* indeed disagree about it. Quite frankly, the packaging issue itself is minor, I was just surprised of the way it was handled: spending time to close several bug reports about the issue and telling people that they are stupid [2], instead of just fixing the issue in the first place. It goes against (my idea of) common sense. Now, the point of this email on arch-dev-public was to discuss the packaging issue and whether it is a policy *not* to fix these kind of issues. I'm fine either way, I'll know for next time. Baptiste [2] https://bugs.archlinux.org/task/57393#comment166572 > I would like to register my formal objection to your treating this as a > personal disagreement between the two of us. I explained why this was > not an "Eli Schwartz thinks so" thing in that private email -- you > disliked my explanation and asked for more proof, while *simultanously* > CC'ing arch-dev-public with claims about how I "and possibly others" > disagree with you. > > You did not give me a chance to respond to your new question before > CC'ing arch-dev-public. signature.asc Description: PGP signature
[arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
Hi, Eli and I disagree about how dependency conflicts should be handled when packaging. This was prompted by the libxfont dependency conflict arising from recent xorgproto changes [1]. My position in this case: it would be really easy to avoid this conflict, by adding libxfont to the Replaces() array of xorgproto. This would cause libxfont to be automatically uninstalled upon sysupgrade, which is nice because it's an obsolete and now-useless package. I think this kind of automatic handling of dependencies and obsolete packages is desirable whenever possible, precisely because it is *automated*. On the contrary, with the current libxfont/xorgproto situation, every Arch user has to spend time to *manually* fix the dependency issue (by removing libxfont). As packagers, I believe we have better things to do than purposefully waste the time of Arch users. Especially for dependency conflicts like this one, which is so trivial and boring: libxfont should clearly be deleted, and an Arch user will learn nothing interesting by having to manually fix the dependency issue. But it seems that this position is not shared by Eli (and possibly others), who thinks that Arch users should be able to figure out this kind of issues by themselves. I agree, but this is not a reason to force boring tasks on them, while we could have easily avoided the issue in the first place. If there are some existing rules or "traditions" that address this question, please provide pointers. Otherwise, I would like to know if there is a consensus one way or the other. Thanks, Baptiste [1] https://bugs.archlinux.org/task/57495 signature.asc Description: PGP signature
Re: [arch-dev-public] Test repository with gcc8
On 13-02-18, Bartłomiej Piotrowski via arch-dev-public wrote: > On 2018-02-04 14:02, Bartłomiej Piotrowski via arch-dev-public wrote: > > Hi all, > > > > I've prepared external repository with GCC 8 built from trunk (as there > > is no stable release yet) that also contains glibc 2.27 and binutils 2.30. > > > > [gcc8] > > Server = http://pkgbuild.com/~bpiotrowski/gcc8/ > > > > From less obvious packaging changes, glibc no longer ships with obsolete > > rpc and nsl, which means that you should switch your packages to > > libtirpc; also if your nsswitch.conf still contains "compat" instead of > > "files", better fix it before reboot. If for some reason you still use > > nsl, the repository also ships libnsl and libnsl_nis packages. > > > > As usually, simple things build, and colossi like LibreOffice don't, but > > I haven't had time yet to check why. If you found some issue, the best > > would be to reply either here or arch-general. > > > > Enjoy, > > Bartłomiej > > > I have updated gcc in the repository to snapshot from 2018-02-11 > (r257571). Additionally, if you have access to soyuz, the repo can be > easily used in build chroots with 'gcc8-x86_64-build' command (which > also enables [testing]). Nice, thanks! Could you enable the password-less rules for sudo that are already setup for extra-x86_64-build? Currently gcc8-x86_64-build asks for a sudo password, but most of us are not sudoers on soyuz (and don't need to be). Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Packages sometimes fail to build: "Failed to attach XXXX to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory"
On 14-01-18, Eli Schwartz via arch-dev-public wrote: > Try logging out and in again, and you should be able to use nspawn again > once your user session is using the updated systemd version. Thanks, it does work again after logging out! But unfortunately, only for one build, the second one still fails... By the way, I rebooted since upgrading the kernel and systemd, so I am certain that my session uses the newer version of systemd. Is there an open bug report? Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Packages sometimes fail to build: "Failed to attach XXXX to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory"
On 14-01-18, Baptiste Jonglez wrote: > $ extra-x86_64-build -- -I ../../another-package/trunk/foo.pkg.tar.xz > (...) > ==> Making package: ring-gnome 3:20180112.2.d0bda53-1 (Sun Jan 14 > 16:06:22 CET 2018) > ==> Retrieving sources... > -> Updating ring-client-gnome git repo... > Fetching origin > ==> Validating source files with sha256sums... > ring-client-gnome ... Skipped > Failed to attach 9683 to compat systemd cgroup > /user.slice/user-1000.slice/session-c1.scope/payload: No such file or > directory > Failed to attach 9661 to compat systemd cgroup > /user.slice/user-1000.slice/session-c1.scope/supervisor: No such file or > directory > Failed to chown() cgroup > /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-c1.scope/payload: > No such file or directory > Parent died too early > ==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/zorun/build > > Full log : https://paste.aliens-lyon.fr/gD0 > > This is the ring-gnome package in [community] but I had this issue with > another one. It's not 100% reproducible, but when it happens, all > subsequent builds of the same package exhibit the issue. > > My system is fully up-to-date, with kernel 4.14.13-1-ARCH and systemd > 236.0-3. It looks like a bug in systemd, or in the interaction with the > devtools. This may be caused by the systemd update a few days ago. Some more information: it seems to happen when a package installed with -I pulls systemd as a dependency. Without -I, even if systemd is a dependency of the package being built, everything works fine. With -I to install a package that does *not* depend on system, it also works fine. Any help appreciated! Baptiste signature.asc Description: PGP signature
[arch-dev-public] Packages sometimes fail to build: "Failed to attach XXXX to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory"
Hi, Today I am experiencing build failures of several packages when using the devtools: $ extra-x86_64-build -- -I ../../another-package/trunk/foo.pkg.tar.xz (...) ==> Making package: ring-gnome 3:20180112.2.d0bda53-1 (Sun Jan 14 16:06:22 CET 2018) ==> Retrieving sources... -> Updating ring-client-gnome git repo... Fetching origin ==> Validating source files with sha256sums... ring-client-gnome ... Skipped Failed to attach 9683 to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory Failed to attach 9661 to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/supervisor: No such file or directory Failed to chown() cgroup /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory Parent died too early ==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/zorun/build Full log : https://paste.aliens-lyon.fr/gD0 This is the ring-gnome package in [community] but I had this issue with another one. It's not 100% reproducible, but when it happens, all subsequent builds of the same package exhibit the issue. My system is fully up-to-date, with kernel 4.14.13-1-ARCH and systemd 236.0-3. It looks like a bug in systemd, or in the interaction with the devtools. This may be caused by the systemd update a few days ago. Any idea? Baptiste signature.asc Description: PGP signature
[arch-dev-public] Delaying the boost-1.66 rebuild
Hi, Kea [1] fails to build with boost 1.66.0, so please keep the rebuild in staging for a few more days. It does not seem like a big issue, but I won't be able to look into it before January. Thanks, Baptiste [1] https://www.archlinux.org/packages/community/x86_64/kea/ signature.asc Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
On 18-12-17, Bartłomiej Piotrowski via arch-dev-public wrote: > On 2017-12-18 10:54, Bartłomiej Piotrowski via arch-dev-public wrote: > > Please look at both lists and adopt what your packages are using or > > you're personally interested in. I will drop whatever makes sense in > > January. > > And of course, if you are missing some permissions or need something > moved to [community], let me know. Useful script, thanks! Can you move fig2dev to [commmunity] so that I can adopt it? I have also adopted a few unneeded orphans. Baptiste signature.asc Description: PGP signature
Re: [arch-dev-public] Moving dbus-c++ from [extra] to [community]
On Tue, Jun 06, 2017 at 10:49:29PM +0200, Baptiste Jonglez wrote: > dbus-c++ [1] is orphaned, but needs some love to work with GCC 7. > Currently, it does not build, and also prevents its reverse dependencies > [2,3,4] from building. Apparently, Fedora has patches to fix this [5]. > > I would be happy to maintain dbus-c++, however it would first need to be > moved to [community] (as well as libffado [2]). Is this ok? Is this possible, and if so, who has the right to move the packages from [extra] to [community]? If somebody else wants to adopt dbus-c++ and fix it, that's be fine too :) Thanks, Baptiste > [1] https://www.archlinux.org/packages/extra/x86_64/dbus-c++/ > [2] https://www.archlinux.org/packages/extra/x86_64/libffado/ > [3] https://www.archlinux.org/packages/community/x86_64/kimtoy/ > [4] https://aur.archlinux.org/packages/ring-daemon/ > [5] http://pkgs.fedoraproject.org/cgit/rpms/dbus-c++.git/log/?h=f26 signature.asc Description: PGP signature
Re: [arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]
Hi Gaetan, On Wed, Jun 07, 2017 at 08:55:15AM -1000, Gaetan Bisson wrote: > [2017-06-06 22:58:01 +0200] Baptiste Jonglez: > > Since a few years, I maintain a variant of the linux kernel in the AUR [1] > > that adds support for Multipath TCP [2]. The most recent version is based > > on linux 4.4, and the package I maintain tries to follow the "linux" > > package from [core] as much as possible. > > > > There is no short- or medium-term perspective to merge Multipath TCP > > upstream, so I would like to bring this package to [community]. There are > > already several kernel variants in the official repos, but I would like to > > get some feedback before adding another one. > > We already have an official linux package in [core] which is very well > maintained and works great for 99% of our users, so I'd really like if > you tried to explain why we need another variant and why the AUR is not > suitable for it anymore. At that point, Multipath TCP is mostly useful to researchers and tinkerers, because both ends of a TCP connection need to run the modified kernel (otherwise, it just falls back to regular TCP). However, I still think it would be useful in [community]: 1) One nice use-case is link aggregation, where you basically tunnel traffic over a Multipath TCP connection. You may want to build such a tunnelling system with Arch. 2) Not everybody has the resources to build a kernel (time, CPU, memory, disk...) 3) It is good to have kernel diversity in our repositories. For instance, I had a laptop that couldn't go to sleep with the kernels from [core] (either linux or linux-lts), but it worked with linux-mptcp. This is really not the main goal of having linux-mptcp in [community], but it's a nice side-effect. By the way, the kernel is completely stable, I have been using it on a daily basis (on my laptop) since a few years. At the beginning of the project in ~2014, there were occasional kernel panics, but not anymore. > As you're aware, we've had another package (linux-grsec) with a user > base certainly much larger than linux-multipath come and go because > upstream went another direction and nobody had the resources to fork it. > I'd really like our packages to enjoy some level of support and not just > go to [community] "because they can" and get dropped just as fast. What > could you tell us about linux-multipath on that front? When talking about "some level of support", do you mean whether the upstream project is active? The project has one main developer, 2 to 3 additional developers, and several small contributors (including myself). I think nobody is working full-time on it, though. Regarding activity, major releases happen when the project is rebased on a more recent kernel version and sufficiently tested: - v0.86 released 2013-03-07, based on linux 3.5 - v0.87 released 2013-07-25, based on linux 3.10 - v0.88 released 2013-10-30, based on linux 3.11 - v0.89 released 2014-10-12, based on linux 3.14 - v0.90 released 2015-09-02, based on linux 3.18 - v0.91 released 2016-06-21, based on linux 4.1 - v0.92 released 2017-06-04, based on linux 4.4 So, I would say the project is active and focused on the long term. There have been minor releases in-between these major releases, to integrate bugfixes and update to latest stable kernel. For instance, v0.91.2 was based on linux 4.1.35. Baptiste signature.asc Description: PGP signature
[arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]
Hi again, Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible. There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one. Thanks, Baptiste [1] https://aur.archlinux.org/packages/linux-mptcp/ [2] http://www.multipath-tcp.org/ signature.asc Description: PGP signature
[arch-dev-public] Moving dbus-c++ from [extra] to [community]
Hi, dbus-c++ [1] is orphaned, but needs some love to work with GCC 7. Currently, it does not build, and also prevents its reverse dependencies [2,3,4] from building. Apparently, Fedora has patches to fix this [5]. I would be happy to maintain dbus-c++, however it would first need to be moved to [community] (as well as libffado [2]). Is this ok? Baptiste [1] https://www.archlinux.org/packages/extra/x86_64/dbus-c++/ [2] https://www.archlinux.org/packages/extra/x86_64/libffado/ [3] https://www.archlinux.org/packages/community/x86_64/kimtoy/ [4] https://aur.archlinux.org/packages/ring-daemon/ [5] http://pkgs.fedoraproject.org/cgit/rpms/dbus-c++.git/log/?h=f26 signature.asc Description: PGP signature
Re: [arch-dev-public] OpenSSL 1.1.0
On Thu, Feb 23, 2017 at 10:29:17PM +0100, Christian Hesse wrote: > > I will push the first set of packages to [staging]. Please avoid doing > > other rebuilds until this one is done. > > Are you interested in details? FWIW, Debian stretch has openssl 1.1.0, so I guess they had to adapt lots of packages. > Mariadb is still unsolved. There is a ticket in upstream jira [0] but it does > not carry anything useful. There's a reference for a review, but I could not > find the patch in mail archive. Will try to contact the developers and > express our interest... The debian package uses `-DWITH_SSL=bundled` [1] to avoid linking with the system-wide openssl. Not a great solution, though. > Mupdf is a burden to maintain due to build system, bundled libraries and > static linking. Looks like upstream is not yet interested in openssl 1.1.0... > As I do not use it currently this will move to [community] if no one > steps up. Can't you just drop the dependency on openssl? What is it used for? As far as I can tell, Debian does not build mupdf against openssl: root@stretch:~# apt show mupdf Package: mupdf Version: 1.9a+ds1-4 Depends: libc6 (>= 2.15), libfreetype6 (>= 2.6), libharfbuzz0b (>= 0.9.11), libjbig2dec0 (>= 0.11), libjpeg62-turbo (>= 1.3.1), libopenjp2-7 (>= 2.0.0), libx11-6, libxext6, zlib1g (>= 1:1.2.0) root@stretch:~# ldd /usr/lib/mupdf/mupdf-x11 | grep ssl root@stretch:~# ldd /usr/lib/mupdf/mupdf-x11 | grep crypto root@stretch:~# I just tested building the package without openssl support (I had to patch out references to openssl and libcrypto from Makerules, since openssl is part of the base chroot when building), and it seems to work fine. Baptiste [1] https://packages.debian.org/stretch/libmariadbclient18 signature.asc Description: PGP signature
