Re: [arch-dev-public] Test repository with gcc8
On 2018-02-04 14:02, Bartłomiej Piotrowski via arch-dev-public wrote: > Hi all, > > I've prepared external repository with GCC 8 built from trunk (as there > is no stable release yet) that also contains glibc 2.27 and binutils 2.30. > > [gcc8] > Server = http://pkgbuild.com/~bpiotrowski/gcc8/ > > From less obvious packaging changes, glibc no longer ships with obsolete > rpc and nsl, which means that you should switch your packages to > libtirpc; also if your nsswitch.conf still contains "compat" instead of > "files", better fix it before reboot. If for some reason you still use > nsl, the repository also ships libnsl and libnsl_nis packages. > > As usually, simple things build, and colossi like LibreOffice don't, but > I haven't had time yet to check why. If you found some issue, the best > would be to reply either here or arch-general. > > Enjoy, > Bartłomiej > I have updated gcc in the repository to snapshot from 2018-02-11 (r257571). Additionally, if you have access to soyuz, the repo can be easily used in build chroots with 'gcc8-x86_64-build' command (which also enables [testing]). Bartłomiej
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] Test repository with gcc8
On 2018-02-13 15:19, Baptiste Jonglez wrote: > On 13-02-18, Bartłomiej Piotrowski via arch-dev-public wrote: >> On 2018-02-04 14:02, Bartłomiej Piotrowski via arch-dev-public wrote: >>> Hi all, >>> >>> I've prepared external repository with GCC 8 built from trunk (as there >>> is no stable release yet) that also contains glibc 2.27 and binutils 2.30. >>> >>> [gcc8] >>> Server = http://pkgbuild.com/~bpiotrowski/gcc8/ >>> >>> From less obvious packaging changes, glibc no longer ships with obsolete >>> rpc and nsl, which means that you should switch your packages to >>> libtirpc; also if your nsswitch.conf still contains "compat" instead of >>> "files", better fix it before reboot. If for some reason you still use >>> nsl, the repository also ships libnsl and libnsl_nis packages. >>> >>> As usually, simple things build, and colossi like LibreOffice don't, but >>> I haven't had time yet to check why. If you found some issue, the best >>> would be to reply either here or arch-general. >>> >>> Enjoy, >>> Bartłomiej >>> >> I have updated gcc in the repository to snapshot from 2018-02-11 >> (r257571). Additionally, if you have access to soyuz, the repo can be >> easily used in build chroots with 'gcc8-x86_64-build' command (which >> also enables [testing]). > > Nice, thanks! > > Could you enable the password-less rules for sudo that are already setup > for extra-x86_64-build? Currently gcc8-x86_64-build asks for a sudo > password, but most of us are not sudoers on soyuz (and don't need to be). > > Baptiste > Try now. My change may be overwritten as I didn't add it to our Ansible playbooks but I cross my fingers to see 8.1.0 soon. Bartłomiej
Re: [arch-dev-public] Test repository with gcc8
On 02/13/2018 09:29 AM, Bartłomiej Piotrowski via arch-dev-public wrote: >>> I have updated gcc in the repository to snapshot from 2018-02-11 >>> (r257571). Additionally, if you have access to soyuz, the repo can be >>> easily used in build chroots with 'gcc8-x86_64-build' command (which >>> also enables [testing]). >> >> Nice, thanks! >> >> Could you enable the password-less rules for sudo that are already setup >> for extra-x86_64-build? Currently gcc8-x86_64-build asks for a sudo >> password, but most of us are not sudoers on soyuz (and don't need to be). >> >> Baptiste >> > > Try now. My change may be overwritten as I didn't add it to our Ansible > playbooks but I cross my fingers to see 8.1.0 soon. Would it be worth adding a sudoers configuration that allows any /usr/bin/*-x86_64-build command? On the theory that that is a rather specific script suffix, and is exceedingly unlikely to be created in /usr/bin/ for any reason other than as a symlink to archbuild with a corresponding /usr/share/devtools/pacman-*.conf (which is presumably something that should always be allowed). -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Test repository with gcc8
On 2018-02-13 16:13, Eli Schwartz via arch-dev-public wrote: > On 02/13/2018 09:29 AM, Bartłomiej Piotrowski via arch-dev-public wrote: I have updated gcc in the repository to snapshot from 2018-02-11 (r257571). Additionally, if you have access to soyuz, the repo can be easily used in build chroots with 'gcc8-x86_64-build' command (which also enables [testing]). >>> >>> Nice, thanks! >>> >>> Could you enable the password-less rules for sudo that are already setup >>> for extra-x86_64-build? Currently gcc8-x86_64-build asks for a sudo >>> password, but most of us are not sudoers on soyuz (and don't need to be). >>> >>> Baptiste >>> >> >> Try now. My change may be overwritten as I didn't add it to our Ansible >> playbooks but I cross my fingers to see 8.1.0 soon. > > Would it be worth adding a sudoers configuration that allows any > /usr/bin/*-x86_64-build command? On the theory that that is a rather > specific script suffix, and is exceedingly unlikely to be created in > /usr/bin/ for any reason other than as a symlink to archbuild with a > corresponding /usr/share/devtools/pacman-*.conf (which is presumably > something that should always be allowed). > I'm not sure if it's worth it as the repo is only semi-official, and besides I've had time only for a band-aid today. Also you know where the infrastructure repo resides and I'll be more than happy to run 'git am' your patch if you share it on #archlinux-devops. Bartłomiej
[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] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
On Wed, 14 Feb 2018 00:56:33 +0100 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]. > > 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 saw the direct emails before this one, so I'll just quote part of my reply here: Replaces is for when packages are renamed, nothing more. That is NOT in any way what happened here, libxfont and libxfont2 are different libraries. Should GTK3 replace GTK2? Qt5 replace Qt4? pgpa82i2zPx5q.pgp Description: OpenPGP digital signature
Re: [arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
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 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. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
> Eli Schwartz via arch-dev-public hat am 14. > Februar 2018 um 01:48 geschrieben: > > > 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: > So, uh, how often does this happen that we need to make a big fuss on the matter? The last manual intervention was nearly a year ago with ca-certificates-utils. If anything we should argue why there was no news post on archlinux.org Alad
Re: [arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
On Wed, 14 Feb 2018 02:52:16 +0100 (CET) Alad Wenter via arch-dev-public wrote: > > Eli Schwartz via arch-dev-public hat am 14. > > Februar 2018 um 01:48 geschrieben: > > > > > > 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: > > > So, uh, how often does this happen that we need to make a big fuss on the > matter? The last manual intervention was nearly a year ago with > ca-certificates-utils. If anything we should argue why there was no news post > on archlinux.org > > Alad A news post for something completely routine? Has Arch become so boring that people don't know how to deal with the simplest conflict?
