=== diddledan6 is now known as diddledan
[05:18] <mwhudson> kanashiro: congrats!
[05:26] <Unit193> Dang, he was quick to get coredev, I'm still only a MOTU after 6 years. :3
=== helio|afk is now known as heliocastro
[06:28] <cpaelzer> If a bug is in the postrm of the current package, has the new update any way to flag that so that it is not run?
[06:29] <cpaelzer> I mean obviously the new package will have a fixed postrm, but is there any way to avoid running oldver->postrm on upgrade?
[06:36] <wgrant> cpaelzer: If the old postrm fails then failed-upgrade is called on the new one instead. But if the old postrm does the wrong thing before it fails, or doesn't fail, I think you're out of luck.
[06:38] <cpaelzer> wgrant: no it does not fail, it does things it should not do
[06:38] <cpaelzer> yeah out of luck is hwo I feel for this one ...
[06:39] <Unit193> One can personally fix it, but as far as the package goes...
[06:39] <cpaelzer> thanks for confirming, I wanted to make sure before I pick a path to go on this
[07:06] <RAOF> cpaelzer: From https://www.debian.org/doc/debian-policy/ap-flowcharts.html, it looks like you *could* wedge something in to the new preinst script?
[07:06] <RAOF> As long as it's the postrm script of the existing package that's failing, your new preinst gets a chance to be run before it.
=== balloons3 is now known as balloons
[07:47] <Unit193> xnox: You seem to have done a lot of opencryptoki uploads, have you considered going the ITS route in Debian?
[08:23] <xnox> Unit193:  ITS?
[08:24] <Unit193> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging 'Package Salvaging' process, a polite way to take over if the maintainer is MIA.
[08:25] <xnox> Unit193:  i am mostly interested around z13/z14/z15 support on s390x. Debian targets z196 but i don't have access to that hardware to test it there. So I don't know if my uploads at all work on Debian / for Debian. But they do on Ubuntu / for Ubuntu.
[08:25] <xnox> Unit193: And I can only setup Ubuntu on the mainframes i have access to with the crypto hardware.
[08:26] <xnox> Unit193:  so i'm not in a position to takeover the package in Debian, nor deal with Debian Bugs about it unfortunately.
[08:26] <Unit193> I see.
[09:14] <seb128> doko, the python-all B-D tricks didn't work, dh --with python2 is still not calling setup.py ... any idea how to debug? DH_VERBOSE if of no help there
[10:07] <xnox> seb128:  which package, and which buildsystem is detected?
[10:08] <xnox> seb128:  maybe you need --buildsystem=pybuild ?
=== paride9 is now known as paride
[10:49] <seb128> xnox, mailnag, the packaging is outdated but it built fine before focal, now it's empty, dh_auto_build doesn't call setup.py
[10:49] <seb128> xnox, https://launchpadlibrarian.net/460064000/buildlog_ubuntu-focal-amd64.mailnag_1.2.1-1.1ubuntu2_BUILDING.txt.gz
[10:50] <seb128> xnox, doko pointed to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949372 and suggested to build-depends on python-all as a workarund but that doesn't work ... and yes, pybuild would probably work but it's disturbing that a valid package build stop building, it's still a supported tool even if deprecated and should still work, other packages might be impacted
[10:50] <ubottu> Debian bug 949372 in src:dh-python "dh-python doesn't accept python2 or python2.7 in the build dependencies" [Important,Open]
[10:53] <doko> seb128: yes, pybuild is required
[10:53] <seb128> doko, but that's a regression still and should be fixed, the same package builds fine and give a working deb in 19.10
[10:53] <seb128> without using pybuild
[10:53] <xnox> seb128:  non-pybuild has been deprecated for years now.
[10:54] <seb128> also if pybuild is requied then dh should error out when it's not enabled
[10:54] <seb128> xnox, right, deprecated != broken
[10:54] <seb128> either it's deprecated and works or not surported  and removed
[10:56] <xnox> seb128: it says it will be removed, and when, and it is removed when it was said it will be removed.
[10:56] <xnox> seb128:  anyway, this is python2 package, why do we care?
[10:57] <seb128> xnox, I'm not sure to parse correctly what you said, my point is that if it's not surported it should error out and not just do nothing, successful finish the build and give an empty deb
[10:57] <xnox> seb128:  if you want old things to work, use old debhelper, on an older release.
[10:57] <seb128> that's just error prone and misleading
[10:57] <xnox> seb128:  debhlper does not provide backwards compat.
[10:57] <seb128> that's an old package, synced for debian
[10:57] <xnox> seb128: so the "should error out, instead of doing something odd" => is a bug in debhelper, it does that with all the things all the time.
[10:58] <xnox> it pisses me off too
[10:58] <seb128> glad we agree it's a bug/annoying, you seemed to argue it's fine to just silently give the wrong result
[10:58] <xnox> seb128:  i don't think that's pybuild/dist-utils specific issue, that implicit build-systems go MIA
[10:59] <xnox> seb128:  i'm saying that it was wrong to rely on implicit distutils behaviour for years now, and the transition to pybuild has been ongoing in debian, and i thought was complete.
[10:59] <seb128> xnox, anyway, it's an old universe package, so not worth the effort
[10:59] <xnox> it's not in testing
[10:59] <seb128> right, it got recently removed because ti's still using python2
[10:59] <xnox> RC buggy, we shouldn't have it either
[10:59] <xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936981
[10:59] <ubottu> Debian bug 936981 in src:mailnag "mailnag: Python2 removal in sid/bullseye" [Serious,Open]
[10:59] <seb128> well, we have it in focal
[10:59] <xnox> and blocking dbus / pygobject removals
[10:59] <seb128> and the deb is empty
[11:00] <seb128> do we do removal in released archived?
[11:00] <seb128> archives
[11:00]  * xnox still believes we should have just dropped python2 all the things
[11:00] <xnox> seb128:  no, it's frozen.
[11:00] <seb128> so I would prefer to see it fixes
[11:00] <seb128> which is why I was looking at it
[11:00] <xnox> seb128:  you can only upload SRU of a package that is empty, and fails to install.
[11:00] <xnox> seb128:  "to see it fixes" => as in fix FTBFS in focal-sru?
[11:00] <seb128> fixed
[11:01] <seb128> it doesn't ftfbs
[11:01] <xnox> i'm not sure we would be doing that for this package.
[11:01] <xnox> oh in groovy?
[11:01] <xnox> in groovy we should just RM remove it
[11:01] <seb128> https://launchpad.net/ubuntu/+source/mailnag/1.2.1-1.1ubuntu2/+build/18546104
[11:01] <seb128> no, focal
[11:01] <seb128> xnox, bug #1874275 is what I was after fixing
[11:01] <ubottu> bug 1874275 in mailnag (Ubuntu) "focal package doesn't contain executables, only manpages" [High,Confirmed] https://launchpad.net/bugs/1874275
[11:02] <xnox> hahahhahahahhaha
[11:02] <seb128> and yes, for groovy we can remove it
[11:02] <xnox> so it's empty in focal good
[11:02] <seb128> yes
[11:02] <seb128> as said, dh_auto_build silently does nothing
[11:02] <xnox> that looks perfect to me =))))))))))))))))
[11:02] <seb128> :p
[11:02] <xnox> yeah, you should have had an autopkgtest
[11:02] <xnox> seb128:  so you are saying that most of our python2 packages in focal are empty?! that's great!
[11:02] <seb128> troll mode on?
[11:03] <seb128> I'm stopping there, I was looking at fixing a practical issue, we wasted more time in discussion that the issue is worth now
[11:03] <xnox> =)))))))))))
[11:03] <seb128> thanks for not helping me with a suggestion on how to get the actual problem resolved
[11:03] <xnox> seb128:  do you want to open a bugreport against debhelper? i guess a task on https://bugs.launchpad.net/ubuntu/+source/mailnag/+bug/1874275 ?
[11:03] <ubottu> Launchpad bug 1874275 in mailnag (Ubuntu) "focal package doesn't contain executables, only manpages" [High,Confirmed]
[11:03] <seb128> I will still try pybuild
[11:04] <xnox> maybe we can do soemthing to focal's debhelper/distutils/pybuild to figure out why distutils "is as if active"
[11:04] <seb128> xnox, is it debhelper or dh-python?
[11:04] <xnox> yet "clearly does nothing at all"
[11:05] <xnox> seb128:  debhelper
[11:05] <xnox> $ dpkg -S python_distutils.pm
[11:05] <xnox> libdebhelper-perl: /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm
[11:05] <xnox> seb128:  dh-python ships pybuild buildsystem, which is not active/used in this build at all.
[11:05] <xnox> (but should be used, but must be manually activated with --buildsystem=pybuild)
[11:05] <seb128> k, right
[11:06] <seb128> xnox, thanks for the reply, I will do that after lunch
[11:06] <xnox> seb128:  see https://wiki.debian.org/Python/Pybuild
[11:06] <xnox> on how to move to pybuild
[11:06] <xnox> pybuild was the preffered/default python build system since 2013 it seems *sigh*
[11:06] <seb128> right, I was trying to avoid doing more work and updating the packaging but I guess that's the right way to fix it
[11:06] <xnox> yeah
[11:07] <xnox> seb128:  it's like me rewritting packaging in dh, instead of piles of manual debhelper calls interviened with cdbs and dpatch all of which stopped working because bugs got fixed.
[11:07] <xnox> =/
[11:07] <xnox> cause ain't nobody will fix that pile of things
=== balloons4 is now known as balloons
[12:31] <seb128> LocutusOfBorg, hey, what does '  * Rebuild against bootstrapped gdk-pixbuf' means in https://launchpad.net/ubuntu/+source/gdk-pixbuf/2.40.0+dfsg-4build3 ? it seems to have made it unhappy, http://autopkgtest.ubuntu.com/packages/g/gdk-pixbuf/groovy/amd64
[12:32] <seb128> ERROR:../tests/pixbuf-jpeg.c:46:test_inverted_cmyk_jpeg: assertion failed (error == NULL): has 4 channels but should have 3 (gdk-pixbuf-error-quark, 0)
[12:40] <wgrant> seb128: gdk-pixbuf has a very tight build-dep loop with itself, which means that it's impossible to build it if its arch-indep and arch-dep binaries are out of sync at all (e.g. amd64 finishes before riscv64 starts). That version was built in a silo against the version in -release
[12:41] <kanashiro> thanks mwhudson :)
[12:42] <seb128> wgrant, k, thanks, looks like the tests are in fact new and started failing with -4 but due to the hackery the -4, build1 and build2 uploads never got tested
[12:42] <wgrant> Ah, makes sense.
[12:42] <wgrant> (also it's a really really gross loop)
[13:03] <ahasenack> cjwatson: hi, just a ping that I finally updated https://salsa.debian.org/auth-team/libfido2/-/merge_requests/4
[13:03] <LocutusOfBorg> seb128, you can see tests for build1 and build2 probably on bileto!
[13:04] <seb128> LocutusOfBorg, it's not easy to jump back from launchpad ubuntu page to there: )
[13:18] <cjwatson> ahasenack: ah, thanks, queueing up
[13:18] <ahasenack> cool
[13:41] <ogra> tjaalton, seems there is some strange behaviour left with using fullscreen apps when using the modesetting driver ... looks like all apps i switch to fullscreen cause several iterations through possible frambuffer resolutions with re-scales of the screen
[13:41] <ogra> tjaalton, i.e. this is my journal when i swithc vlc to fullscreen: https://paste.ubuntu.com/p/VnRGRgcxJx/
[13:42] <ogra> each of these "Allocate new frame buffer ***** stride" causes a re-scale and flash of the screen ... eventually it finds a proper resolution and stays there ... but the experience is rather odd ... i see the same using i.e. stellarium ..
[13:43] <tjaalton> ogra: using fractional scaling?
[13:43] <ogra> yes
[13:43] <tjaalton> blame that then
[13:43] <tjaalton> .)
[13:43] <ogra> 4k 13" screen :)
[13:43] <tjaalton> :)
[13:43] <ogra> ok
[13:43] <tjaalton> well, use a non-fractional scaling value
[13:43] <tjaalton> does it still suffer from it with that?
[13:43] <ogra> then i need to turn the touchscreen back on to manage the buttons with my palm :P
[13:44] <ogra> non-fractional has really no usable values ... but i can try later with it to see if that behaves differenty
[13:44] <tjaalton> how about '2'?
[13:44] <ogra> giant :)
[13:44] <tjaalton> okay
[13:45] <ogra> 10 is perfect :)
[13:45] <ogra> err
[13:45] <ogra> 150
[13:45] <tjaalton> try wayland?
[13:45] <ogra> yep, 200 causes no scaling or flashing ... i'll go and blame duflu then
[13:45] <ogra> :)
[13:46] <tjaalton> not saying there isn't a bug in the X stack.. but it's caused by FS
[13:46] <ogra> yep, it definitely is
[14:43] <Trevinho> wgrant: hey, thanks for the riscv patches for the shell stack, however please next time we would appreicate if you could update also the vcs (in debian's salsa as per https://discourse.ubuntu.com/t/psa-ubuntu-gnome-packages-development-moved-to-debian-salsa/14900)
[14:59] <rharper> smoser: for cloud-utils, I'm planning to branch ubuntu/devel -> ubuntu/focal and then push in the deb/control changes for fdisk/gdisk into ubuntu/devel ;  similar to our new series process, that sound good ?
[15:43] <smoser> https://code.launchpad.net/~smoser/cloud-utils/+git/cloud-utils/+merge/383431
[15:43] <smoser> rharper: ^
[15:43] <rharper> ok
[15:44] <smoser> but as far as a branch goes.. yeah, the intent is to do the same general workflow as cloud-init does.
[15:45] <rharper> smoser: ok
[16:30] <bdmurray> marcustomlinson: could you please stop setting apport bugs to incomplete?
[16:52] <bdmurray> marcustomlinson: Oh, those emails are from March my bad
=== ijohnson is now known as ijohnson|lunch
=== heliocastro is now known as helio|afk
=== helio|afk is now known as heliocastro
=== ijohnson|lunch is now known as ijohnson
[18:53]  * Eickmeyer is once again trying to figure out why Ubuntu Studio's groovy iso failed, and can't blame Inkscape
[18:53] <Eickmeyer> I could really use some help on this one.
[18:53] <Eickmeyer> Bad timing: I am trying to change the DE but something unrelated has caused the ISO to FTB.
=== ben_r_ is now known as ben_r
[19:53] <Trevinho> anyone in the SRU team, could please reject mutter with version   3.28.4+git20200505-0ubuntu20.04.1 in the bionic queue? I've re-uploaded it with the right version :/
[21:00] <xevious> bryce: Congrats on Inkscape 1.0!
[21:00] <bryce> xevious, thanks :-)
[21:00] <xevious> I'm very excitedly downloading the Mac version now.