Hi,

• Bug reporting broken packages on IRC doesn't get them fixed at least for weeks. Example: I bugreported community/prjtrellis being broken on IRC and it was not fixed yet for archlinux32 on i686.
• Older accounts don't work anymore (I got That user does not exist on this Flyspray installation for both GNUtoo and gnutoo while trying to recover my password and/or login)
• Creating newer accounts fails due to the captcha.

It takes me way less time to fix things by recompiling PKGBUILDS.

At beast it takes the compilation time + running librestage + librerelease.

At worst when uploading fails, I could need to rebuild the package again and to fix the upload by deleting the package from the db (with db-remove), and from /srv/repo (with find -iname "<package>*i686" to confirm it won't delete other stuff and find -iname "<package>*i686" -delete for the deletion) and then to re-upload them.

Practically speaking, rebuilding the package can avoid many more weeks / months of broken packages.

The issue is then how to handle that. Assuming that Arch Linux 32 will fix it doesn't work as well as it should and some packages can need fixing.

So enabling to upload newer Arch Linux 32 packages could be an option.

• Would uploading a core/ or community/ package work with librestage + librerelease ? Can I try?
• Should we keep them package as-is not to pollute abslibre with packages that are temporary? This way if Arch 32 uploads newer packages at some point the Arch 32 ones will take precedence.

edit1: added "Can I try?"

if we manually put anything into core/extra/community, it is
likely to get clobbered on the next daily import - i think
over-ride packages need to go in [libre], then removed later,
when the upstream move ahead - it wont be forgotten; because the
repo linter reports duplicates - i would keep a bug report open
for the duration, just so that the rationale is not forgotten

if you go through the trouble of fixing something yourself, the
best thing to do is offer the changes to arch32 - they will not
ignore it - arch32 is just understaffed - we really need to work
with them as much as possible - the last time i asked on IRC for
a package rebuild, they rebuilt it within an hour - but bug
reports on IRC are always at risk of being forgotten or missed
entirely

IIRC they did need to create a new instance of the bug tracker;
and older accounts were lost - i would just create a new account

bill-auger wrote:

if we manually put anything into core/extra/community, it is
likely to get clobbered on the next daily import

I see. What about adding a new repo just for fixes like that?

- i think over-ride packages need to go in [libre], then removed later,
when the upstream move ahead - it wont be forgotten; because the
repo linter reports duplicates - i would keep a bug report open
for the duration, just so that the rationale is not forgotten

if you go through the trouble of fixing something yourself, the
best thing to do is offer the changes to arch32

Arch 32 do accept patches on their mailing list, so it's pretty
simple to send them changes, at least for me. It's just a little
more work than git push and probably less work or equivalent to
git push + libremakepkg + librestage + librerelease.

However this is not related to the issue I'm trying to describe here.

So far I didn't come accross a single case where I could fix the issue by sending a patch, so I could not even test the process I just mentioned (sending patches).

The issue here is that all the fixes I could have done only required to recompile the PKGBUILD. It didn't even need a package revision bump as Arch Linux 32's upstream (Arch Linux for x86_64) revisions were newer.

All that needed to be done was a recompilation with 0 changes.

Now the issue is that I don't want to either have to install Arch Linux 32 or force people to do that to fix that kind of bugs. So I can't simply become an Arch Linux 32 developer as-is and start pushing packages.

However Parabola has a blacklist package, so maybe there would be a way to install Arch Linux or any of its variants (Arch Linux 32, Arch Linux ARM) and be sure that what we are installing would be FSDG compliant if it had its own website or if it was officially supported by Parabola, and once that's done build packages for Arch 32 and contribute them.

The other issue with that approach would be to find a way to make Arch Linux 32 trust at least a subset of the Parabola hackers, as we wouldn't be able to be accepted as Arch Linux 32 developers in the regular way as we probably would have 0 code contribution.

- they will not ignore it - arch32 is just understaffed - we really need to work
with them as much as possible - the last time i asked on IRC for
a package rebuild, they rebuilt it within an hour - but bug
reports on IRC are always at risk of being forgotten or missed
entirely

I'd really like to, I'm trying to push things as much as possible upstream: Most or all the packages that I created are in Aur too, and I'm also trying to push things in upstream projects as well, for instance I tried to upstream most of the configuration changes in u-boot itself (which takes way more time than just shipping a config in Parabola) and some of them are now upstream.

Ideally if we could drop most of non upstream patches for patches that aren't related to what a GNU/Linux distribution or FSDG compliant GNU/Linux distribution is doing that would be great.

For instance in the linux-libre package we have many patches that could be completely dropped:

• 0001-ARM-atags-add-support-for-Marvell-s-u-boot.patch

• 0001-CHROMIUM-block-partitions-efi-Add-support-for-IGNORE.patch

• 0001-ZEN-Add-sysctl-and-CONFIG-to-disallow-unprivileged-C.patch

• 0002-ARM-atags-fdt-retrieve-MAC-addresses-from-Marvell-bo.patch

• 0002-fix-Atmel-maXTouch-touchscreen-support.patch

• 0002-HID-quirks-Add-Apple-Magic-Trackpad-2-to-hid_have_sp.patch

• 0003-iwlwifi-Fix-regression-from-UDP-segmentation-support.patch

• 0003-SMILE-Plug-device-tree-file.patch

• 0004-btrfs-fix-deadlock-when-cloning-inline-extent-and-lo.patch

• 0004-fix-mvsdio-eMMC-timing.patch

• 0005-btrfs-shrink-delalloc-pages-instead-of-full-inodes.patch

• 0005-net-smsc95xx-Allow-mac-address-to-be-set-as-a-parame.patch

• 0006-set-default-cubietruck-led-triggers.patch

• 0007-exynos4412-odroid-set-higher-minimum-buck2-regulator.patch

• 0008-ARM-dove-enable-ethernet-on-D3Plug.patch

• 0009-USB-Armory-MkII-support.patch

As they can be upstreamed ideally they should be, else we end up in a situation where, because Arch Linux and Parabola by extension is supposed to not customize too much the packages configuration, users will assume that all that code is upstream because it works. And they will also expect all other GNU/Linux distribution to also work as well in the same way.

IIRC they did need to create a new instance of the bug tracker;
and older accounts were lost - i would just create a new account

It didn't work for me. Though maybe I should retry and contact them to see how to best solve that (hoping not to make them spend too much time on it).

arch32 is just understaffed

1. The best way is to fix it ourselves directly in arch32, this way they spend 0 time handling the thing, or a very minimal amount of time (like reading a ChangeLog). Unfortunately the way to do that is not obvious at all for me.
2. The next way would be to fix it ourselves in Parabola to not increase their workload (they'd have to handle bugreports and so on otherwise)
3. And the next way would be to notify them but have them fix it (which takes time for them)

Some of the breakages are very visible (broken KDE, broken xfce4, etc) so I guess they are somehow aware of it unless not many people run the i686 version of arch32 but use other versions like pentium4 for instance.

From #archlinux32

< GNUtoo> hi,
< GNUtoo> does it help to report packages that needs to be recompiled?
< [propabably an archlinux 32 developer]> yes :-)
< GNUtoo> ok, thanks, I'll do that

So it seems that bugreporting is the right way to do it and that I assumed something wrong.

Since I can't register I was told that I needed to ping deep42thought or abaumann to add packages in the list of packages to be rebuilt.

there seems to be two issues in this ticket - the issue of upstreaming patches doesnt need any discussion - that is always desirable, if possible - i try to contact upstream whenever i can - im registered on many bug trackers, gnome, kde, gitlab, github, wherever the upstreams take bug reports

i dont see the arch32 issue as particularly "bug-worthy"; more of a mailing list discussion - it is a problem for sure; but the problem is that arch32 is under-staffed, and there is not a large user-base reporting bugs - parabola has relatively few i686 users, or bug reports also - i probably find and report more bugs in arch32 than any single parabola or arch32 user - supporting retro arches is "the other bleeding edge"; and is more painful and laborious - added to that, there are fewer people doing the work, and fewer bug reports

the most usual situation, when anything is broken on parabola i686, is that it is also broken on the arch32 system - dependency issues are almost always lurking somewhere in the main repos; but the fix (or a good approximation of one) is usually in testing or staging

i keep an arch32 VM ready at all times, and verify the bugs, then report them (same for arch; but i need it much less rarely) - i usually try on IRC first; because they are often aware of the bug, and/or can fix it very quickly (moving something out of testing, for example) - if no one is around at the time, i open a bug report

i would suggest to make yourself familiar with (and to) abaumann and deep42thought (aka: girls), get yourself registered on the bug tracker or mailing list, and keep an arch32 VM ready for triaging - abaumann and deep42thought are the only two devs; so whatever channel you can reach them on, is as good as any other

if you need to fix an arch32 package in parabola immediately, just build it with pkgrel+=.parabola1, librerelease it into [libre], and try to get the changes into arch32 - then follow their progress, so that you will remember to delete the emergency package eventually - even if you forget, the repo-linter should catch it as 'package-not-in-abslibre' - that may be better; because if you do add it abslibre, then forget it, the repos-linter may not complain if the orphan remains forever