[08:51] <paride> thanks rafaeldtinoco
[09:41] <Unit193> kanashiro: FWIW, I just got an email that my "upload" is stuck because ruby-zip is still stuck in -proposed.
[11:17] <xnox> seb128:  added debugging tips on https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1865161
[11:19] <seb128> xnox, thx
[12:20] <kanashiro> Unit193, yes, I think ruby-zip is the last package needing a fix
[12:24] <AsciiWolf> kenvandine, I have recently added some details to https://bugs.launchpad.net/snap-store/+bug/1866998 about how it could be fixed... not sure if you got an email about it (you don't seem to be subscribed to the bug, however you are assigned to it)
[13:07] <caravena> Hello users of Ubuntu (:
[13:07] <caravena> I'm bug with browser
[13:08] <caravena> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1868999
[13:16] <mantas-baltix> Hi, are any ubuntu developers online ? ;)
[13:16] <kenvandine> AsciiWolf: i'm planning on fixing that along with the update to 3.36.1
[13:22] <mantas-baltix> Could someone accept simple patch for console-setup, see bug #1863001
[14:28] <seb128> xnox, plymouth/fsck integration does show for me in focal with spinner, I would be interested to know how you tested?
[14:28] <seb128> xnox, the message handling is a bit buggy but it does display
[14:28] <seb128> xnox, https://people.canonical.com/~seb128/plymouth/diskcheck.jpg
[14:29] <xnox> seb128:  where is the message that 1 out 1 device check is in progress (XX% percent)?
[14:29] <seb128> xnox, that's the "is a bit buggy" part :)
[14:29] <xnox> seb128:  during fsck i should see at least 2 messages (one with progress %, one with key codes) simultaniously
[14:29] <seb128> xnox, it looks like spinner doesn't handle multi-line messages correctly, which we will fix
[14:29] <xnox> and during casper-md5check there whould be 3 messages simultaniously
[14:29] <xnox> it is not a single message
[14:29] <seb128> xnox, but that's a different bug from "doesn't has itnegration"
[14:29] <xnox> it is a separate status message
[14:30] <seb128> right
[14:30] <seb128> that's a bug, I confirm and we will fix
[14:30] <seb128> but you report was not about the message being buggy, but about the integration being missing
[14:30] <seb128> so I wonder if you hit another problem maybe?
[14:30] <xnox> which is handled specially, i.e. keycode ones, updates the keycode line; status updates the status message; and the fsck one updates the % line; and update of any one of those three, doesn't wipe the other two
[14:31] <seb128> xnox, right, again that's a confirmed problem and we can act on it
[14:31] <seb128> xnox, now I'm wondering if when you said 'doesn't support fsckd progress messages ' you meant you had the same that I had on my screenshot
[14:31] <xnox> seb128:  the original bug report was based on users saying "no progress output visible" and hence i filed a bug report. because the spinner theme, is not processing "fsck:*" messages and is not displaying 1 of 1 fsck in progress (10% done)
[14:31] <xnox> seb128:  that screenshot is not showing the "fsck:" % complete.
[14:31] <xnox> that is my bug report.
[14:31] <seb128> xnox, again, I'm not discussing that
[14:32] <seb128> k, thanks
[14:32] <seb128> that's just what I wanted, make sure it's the same issue you were having, the description was not very specific
[14:32] <xnox> you can do it from plymouth cmdline too, by simply sending 'fsck:sda1:10' as a message with plymouth client
[14:33] <seb128> xnox, thanks
[14:33] <xnox> seb128:  ok. I assumed "everyone" knows about 'fsck:LABEL:0..100' special status messages =)
[14:33] <xnox> but maybe it is just me =(
[14:33] <seb128> we don't have anyone knowing about plymouth in desktop at this point
[14:33] <seb128> but we are learning now :p
[14:33] <cpaelzer> rbasak: FYI the new importer code on diglett is able to import gpsd fine
[14:34] <rbasak> \o/
[14:34] <rbasak> Thank you for testing
[14:39] <niedbalski> rbasak: sil2100 hey guys o/ , any chance for you to check sru(s) on https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=python-barbicanclient and https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=containerd ?
[14:39] <niedbalski> thanks!
[14:41] <ahasenack> hi, I managed to get an NBS binary in my own ppa, i.e., a previous source package was building bin:libcbor0, but I changed that to bin:libcbor0.6. Now bin:libcbor0 is lingering there. How can I delete it?
[14:41] <ahasenack> maybe best asked in #launchpad
[14:41] <rbasak> niedbalski: I'm occupied right now, but I'll try and look in an hour or two. I'm not sure I'll get to it though.
[14:43] <niedbalski> rbasak: thank you, robie. I appreciate it.
[15:10] <cpaelzer> rbasak: what is the rule on MPs that are "not for us" do we want/need to make anyone else aware of https://code.launchpad.net/~alkisg/ubuntu/+source/wpa/+git/wpa/+merge/381089 ?
[15:13] <rbasak> alkisg: ^
[15:13] <cpaelzer> well he opened it
[15:13] <rbasak> Thank you for the MP, but please note that the git workflow is still experimental and currently won't automatically end up on any review queue
[15:13] <cpaelzer> the question is who to target with it
[15:14] <cpaelzer> ah yeah, you were about to write something :-)
[15:15]  * rbasak has adjusted the bug
[15:32] <rafaeldtinoco> rbasak: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1866119
[15:32] <rafaeldtinoco> rbasak: https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1865523
[15:32] <rafaeldtinoco> those 2 for bionic
[15:32] <rafaeldtinoco> thanks for this, pls ping me if you need info
[15:33] <doko> tkamppeter: please could you have a look at https://launchpadlibrarian.net/470639931/buildlog_ubuntu-focal-amd64.ppl_1%3A1.2-7build1_BUILDING.txt.gz ?  ghostscript error. Debian has a newer upstream
[15:34] <doko> tkamppeter: and if you update, please re-instate building with -O2 on ppc64el
[15:38] <coreycb> xnox: can I get your opinion on something? upstream pyscss and django-pyscss were lacking maintenance so have been forked upstream to pyscss2 and django-pyscss2. would require new source package or if we could just re-use the existing one? reverse-depends are minimal to update to the new binary package.
[15:39] <coreycb> (sorry that question doesn't read well)
[15:40] <xnox> coreycb:  did they break the api/abi/classes?
[15:40] <xnox> coreycb:  if yes, you will need new binary packages, you can use the existing source package, but then all of our bug trackers and CVE trackers will be off
[15:41] <xnox> coreycb:  it's best to use a new source and binary package name
[15:41] <xnox> and remove the other one.
[15:41] <coreycb> xnox: ok so new source either way would be your suggestion regardless of api/abi/class breakage.
[15:41] <coreycb> xnox: makes sense, thanks
[15:46] <xnox> yeah, unfortunately
[15:46] <xnox> it should be quick to review/accept.
[15:47] <xnox> i.e. i do new source package for each new boost update
[15:58] <kanashiro> Unit193, I think I have a fix for ruby-zip in s390x, I'll submit a patch soon
[16:00] <alkisg> cpaelzer, rbasak, hi, the debian maintainer committed the fix for lp bug #1867908 in unstable, and suggests a sync from debian; I don't know how I can help there, but I guess my merge request isn't appropriate now; if you think I can somehow help, tell me how
[16:02] <cpaelzer> well, wpa is mostly under the desktop teams watch
[16:02] <cpaelzer> recent upload were mostly security fixes but still it would be desktop
[16:03] <cpaelzer> lets tag is for them to be more visible
[16:03] <rbasak> Any uploader should be able to review/sponsor this though
[16:03] <rbasak> If I have time today I'll take a look.
[16:03] <seb128> sil2100, ckb langpacks failed upload,
[16:03] <seb128> The signer of this package is lacking the upload rights for the source package, component or package set in question.
[16:03] <cpaelzer> rbasak: but you know how easy it is to sponsor a package you never changed before
[16:03] <seb128> sil2100, is that a new language that needs to be added to a set?
[16:03] <rbasak> cpaelzer: this looks like a cherry-pick for a bug fix. Those ones should be fine?
[16:04] <cpaelzer> oh is it just that?
[16:04] <sil2100> seb128: yeah, see my message on -release
[16:04] <sil2100> seb128: I knew and re-uploaded a while ago
[16:04] <sil2100> All good now
[16:04] <sil2100> seb128: btw. is it possible for me to get those e-mails as well somehow?
[16:04] <seb128> sil2100, k
[16:12] <oSoMoN> juliank, I could use your help with an apt problem: I have snapcraft.yaml part definition that runs "apt download 'language-pack-gnome-*-base'" in its override-pull phase, and it's working in my local tests (downloading all the packages matching the wildcard expression), but it's silently failing on an upstream CI system (return code 100), and I don't know why
[16:12] <oSoMoN> how can I instruct apt to be more verbose about what's not working?
[16:13] <oSoMoN> I've tried "apt -o Debug::pkgAcquire::Worker=true download 'language-pack-gnome-*-base'", but no luck
[16:22] <tkamppeter> doko, which package is that which does not build?
[16:23] <tkamppeter> doko, current Ghostscript in focal is 9.50 is there a known bug in 9.50 which makes this build fail and 9.52 (current of Debian) would make it succeed?
[16:24] <rbasak> niedbalski: for next time, it would help me review quicker if you included dep3 headers like Origin:
[16:24] <tkamppeter> Would this rectify a FFe for Ghostscript?
[16:26] <juliank> oSoMoN: so that's running on bionic, then i guess
[16:26] <oSoMoN> yes
[16:26] <juliank> oSoMoN: because in eoan, or focal, that would not be a valid package name :)
[16:26] <rbasak> niedbalski: in bug 1867676, could you flesh out the impact statement please? I don't understand why the code not falling back into the legacy mode would cause a problem. What's the actual use case that's a problem here?
[16:27] <juliank> oSoMoN: but pkgacquire::worker should give you some information at least, debug::acquire::http maybe more
[16:27] <rbasak> niedbalski: and Regression Potential needs to consider what areas of testing would find a regression if there is one please. See https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[16:31] <oSoMoN> juliank, it doesn't. all I get is: https://paste.ubuntu.com/p/cJjdyYPBJg/
[16:31] <doko> tkamppeter: the package name is seen in the URL ;p
[16:32] <tkamppeter> doko, is it "ppl"
[16:36] <juliank> oSoMoN: now that's useful
[16:36] <juliank> Handler silently failed
[16:38] <niedbalski> rbasak: ack, reviewing that section
[16:39] <tkamppeter> doko, I have located it now.
[16:39] <rbasak> niedbalski: thanks. I commented in the bug so my request wouldn't get lost.
[16:40] <tkamppeter> doko, current Ghostscript in focal is 9.50. Is there a known bug in 9.50 which makes ppl's build fail and 9.52 (current of Debian) would make it succeed?
[16:43] <rbasak> niedbalski: it's the same with bug 1867398, if you could fix that too please.
[16:43] <doko> tkamppeter: I don't know
[16:43] <rbasak> niedbalski: since during SRU review I'm trying to weigh the benefit of making the change vs. the risk of making it, I really need to understand the user story that is broken.
[16:44] <rbasak> I hope that makes sense. If it's not clear what I'm after, happy to chat more.
[16:44] <oSoMoN> juliank, that doesn't sound very helpful, as an error message. any clue how i can debug further?
[16:44] <niedbalski> rbasak: i undertsand, i think is contained in different pieces, will make sure to organize the impact section so you can clearly understand it.
[16:45] <rbasak> niedbalski: thanks! Same for regression potential for containerd please.
[16:46] <juliank> oSoMoN: it means that DoDownload() returned false w/o setting an errorr
[16:47] <juliank> oSoMoN: now I'm afraid the only way to go further is to run gdb
[16:47] <juliank> and see where it returns
[16:48] <juliank> because it means we are not logging an error
[16:48] <juliank> Maybe handler silently failed should be renamed to "The command implementation returned a failure, but did not produce any error messages"
[16:49] <tkamppeter> doko, the update of Ghostscript to versions 9.51 and 9.52 came both after our FFFFF therefore Focal has version 9.50. And I think an FFe to update to 9.52 at this time for building the documentation of a Universe package is too much.
[16:49] <oSoMoN> juliank, not an option, this is on a CI system I don't control, and it's working in my local tests
[16:51] <juliank> oSoMoN: Well, you gotta figure out the gdb commands then and run it non-interactively :)
[16:51] <doko> tkamppeter: it's a failing autopkg test blocking a package in main
[16:53] <juliank> oSoMoN: also try -o APT::Get::Print-URIs=1 (or I guess --print-uris) to see if it gets that far, maybe
[16:55] <tkamppeter> doko, as the problem happens only on amd64 and not on the other platforms there is perhaps a probability that repeating this build could pass. Have you already tried this?
[16:56] <rbasak> rafaeldtinoco: fence-agents looks very non-trivial :-/
[16:56] <rafaeldtinoco> rbasak: yep, it is
[16:56] <rafaeldtinoco> rbasak: if you go through merge request comments
[16:56] <rafaeldtinoco> it will be more clear I suppose
[16:56] <rbasak> Thanks
[16:56] <doko> tkamppeter: yes
[16:58] <tkamppeter> Could you perhaps run this test locally to find out which file gets fed into Ghostscript and which Ghostscript command line gets called? With this I could report an upstream bug.
[16:58] <tkamppeter> doko, ^
[17:15] <rbasak> rafaeldtinoco: rather than get into it now, I'm going to set aside at least a couple of hours for this.
[17:15] <rbasak> (which won't be today)
[17:16] <zyga> hey
[17:16] <zyga> who can I talk to about  azure.archive.ubuntu.com
[17:17] <zyga> it's quite unreliable
[17:17] <zyga> (from github actions)
[17:18] <rafaeldtinoco> rbasak: no problem!
[17:18] <rafaeldtinoco> rbasak: thanks for tackle it whenever u can!
[17:18] <rafaeldtinoco> tacke/tackling
[17:23] <Eickmeyer> rbalint, teward, xnox, juliank: We've been moved here by Laney.
[17:23] <juliank> Oh I did not notice we were in #buuntu-release before
[17:23] <juliank> :D
[17:23] <juliank> sorry Laney
[17:24] <rbalint> Eickmeyer, were not totally off-topic :-)
[17:25] <Eickmeyer> rbalint: I agree, but Laney wants us here.
[17:26]  * Laney resists arguing with you all :)
[17:26] <rbalint> so my question/offer still stands, but i need to do a bit of preparations because git-remote-bzr is broken in focal and i use it for verification
[17:27] <rbalint> Laney, at least on #ubuntu-release ;-)
[17:27] <Eickmeyer> rbalint: Yeah, if you could do it, you'd do it faster. I converted a ton of stuff in ~ubuntustudio-dev, but that was about two years ago and the method I used is broken, hence the python errors.
[17:28] <rbalint> Eickmeyer, ok, i wanted to convert a few other repos, too
[17:29] <oSoMoN> juliank, "Handler silently failed" with --print-uris too
[17:29] <juliank> nuce
[17:30] <teward> *pours firewater on Laney for reasons*
[17:30] <teward> :P
[17:31] <cjwatson> zyga: I'd start with IS though I'm not completely sure they operate the cloud mirrors
[17:31] <teward> s/firewater/liquid fire/
[17:31] <zyga> thanks cjwatson
[17:42] <Eickmeyer> juliank: So, basically, you have a commit in ubiquity that supposedly fixes the problem? It really comes down to the automatic deselection of entire metapackages based on one package which, in turn, autoremoves everything that metapackage depends on.
[17:44] <juliank> Eickmeyer:   * When removing packages, also remove automatically installed packages that
[17:44] <juliank>     are no longer required (LP: #1798992)
[17:44] <juliank> Eickmeyer: that was the last thing I did
[17:44] <juliank> Eickmeyer: I
[17:44] <juliank> Eickmeyer: I would not call that a fix, as it does not sound like what you want
[17:46] <Eickmeyer> juliank: Not entirely..? I'd say it's related, however. Seems the problem happens at the end of the installation where anything that is deselected at the end of the installation is removed, but then it marks its metapackage for autoremoval, which then marks everything in the metapackage as "no longer needed" which gets removed during autoremoval.
[17:49] <juliank> Anyhow, it's too late for today
[17:50] <Eickmeyer> juliank: Understandable. FYI, I'm on the US West Coast, so it's still morning for me. :)
[18:53] <arunpyasi> Hi everyone, is it mandatory to setup a local repository in order to install local packages as dependency for a new package ?
[18:53] <arunpyasi> for sbuild
[19:00] <jphilips> bdmurray: i had submitted a few patches to the manual tests. are you the one handling approving them?
[19:13] <bdmurray> jphilips: I can
[19:14] <jphilips> thanks
[19:14] <jphilips> this is my branch https://code.launchpad.net/~philipz85/ubuntu-manual-tests/ubuntu-manual-tests
[19:15] <jphilips> and guiverc also has some https://code.launchpad.net/~guiverc/ubuntu-manual-tests/ubuntu-manual-tests
[19:16] <jphilips> i have another round of patches, but want to know that i'm doing it right before continuing :D
[19:30] <bdmurray> jphilips: generally speaking it looks right but I have one question I'll ask in the MP
[19:31] <bdmurray> jphilips: currently updating the test cases on the server is a manual process so I'd prefer to do them en masse if you have multiple updates
[19:32] <jphilips> how can i make it easiest for you
[19:34] <bdmurray> if you are making multiple changes to the same test number e.g. 1300_Install... just do them all at once
[19:48] <seb128> xnox, do you know how to trigger the end of install/screen that should display the 'press a key to reboot" from a liveCD session without having to go through the install?
[19:50] <jphilips> bdmurray: okay and then should i send it to launchpad or how should i pass it long to you
[19:53] <bdmurray> jphilips: The Launchpad MP is the right way, my point was more about if I change 1300 on the server today and have to do it again tomorrow that wouldn't be efficient.
[19:53] <bdmurray> jphilips: So if you have multiple changes do them all at once. ;-) Thanks for improving the quality of the test cases!
[19:55] <jphilips> bdmurray: okay. i'll work on one complete file at a time.
[19:56] <jphilips> i'm new to bzr, so is there a means for me to reset the branch to the master
[20:02] <seb128> bdmurray, you might know as well about the question I just asked. Do you know how to trigger the end of install screen from a live session? the plymouth screen that shows the 'press a key to reboot now'
[20:02] <bdmurray> seb128: I don't, sorry!
[20:03] <seb128> bdmurray, no worry, thanks for replying anyway :)
[20:03] <mwhudson> seb128: it's one of the casper bits that does that
[20:03] <mwhudson> trying to find it
[20:03] <seb128> mwhudson, thanks
[20:03] <mwhudson> casper-stop
[20:03] <cjwatson> arunpyasi: No, you can use --extra-package
[20:04] <seb128> mwhudson, I tried to sudo casper-stop from the live session but it didn't seem to do anything ... should I also call reboot/close the session manually?
[20:04] <Unit193> kanashiro: Nice!
[20:05] <mwhudson> seb128: yeah i don't know what environment this expects to run in, probably one without the DE running though
[20:05] <mwhudson> seb128: if you look in the file it has all sorts of reasons why it might exit without doing anything
[20:05] <mwhudson> i also can't remember how it's hooked into the shutdown process
[20:06] <seb128> mwhudson, I will poke around, thanks
[20:06] <mwhudson> ah casper.service which is WantedBy=final.target
[20:06] <seb128> debugging those plymouth integration problems is no fun :/
[20:06] <mwhudson> yeah i can only imagine
[20:07] <kanashiro> Unit193, uploaded version 2.0.0-2 to Debian and I'll request a sync as soon as it lands in unstable
[21:34] <xnox> seb128:  every shutdown should show it
[21:34] <xnox> seb128:  so just shutdown....
[21:34] <xnox> but like can do systemctl start debug-shell
[21:34] <xnox> to have a tty bash on tty9
[21:35] <seb128> xnox, thx
[21:36] <seb128> xnox, so I've no idea how to debug those problems, having someone from foundation (you?) poking would be nice
[21:37] <seb128> xnox, the casper-md5check script on an installed system does lead to text being displayed on the plymouth screen (incorrect layout/just one  line) and I've no idea why that doesn't work  on the livecd
[21:37] <xnox> fun