Project

General

Profile

Bug #2980

Can't fix broken packages on i686

GNUtoo - 19 days ago - . Updated 4 days ago.

Status:
in progress
Priority:
discussion
Assignee:
% Done:

100%

History

#1

Updated by GNUtoo 19 days ago

Hi,

It seems that:
  • 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.

I've never tried to do that, but:
  • 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?"

#2

Updated by bill-auger 19 days ago

it 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

#3

Updated by GNUtoo 18 days ago

bill-auger wrote:

it 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).

#4

Updated by GNUtoo 18 days ago

arch32 is just understaffed

My reasoning is also based on that. As I understand it:
  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.

#5

Updated by GNUtoo 12 days ago

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.

#6

Updated by GNUtoo 12 days ago

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.

#7

Updated by GNUtoo 4 days ago

  • % Done changed from 0 to 100
  • Priority changed from feature to discussion
  • Assignee set to GNUtoo
  • Status changed from unconfirmed to in progress

I wonder what to do with that bug, should we keep it open for reference? should we close it?

Also available in: Atom PDF