[06:05] <nacc> slangasek: xnox: what would be the right way for me to esnure i have the most recnet ubuntu and debian keyrings in git-ubuntu (for gpg verifying the archive files current and historical)?
[06:05] <nacc> dpb1: --^ fyi reimport on hold until i resolve that
[06:21] <nacc> slangasek: xnox: to be clear, in a snap, so 'run bionic' isn't an answer (yet)
[06:44] <rbalint> mvo: imo -updates should be enabled in u-u for Ubuntu as well
[06:50] <rbalint> mvo: otherwise updates from -security may fail to install or may be stuck due to missing dependencies
[06:51] <rbalint> mvo: filed the PR, it may even fix Travis check
[07:08] <rbalint> mvo: u-u changes are in limbo, i'm trying to fix travis checks
[07:08] <rbalint> mvo: you can wait with the review till i update changelog again
[07:13] <mvo> rbalint: hm, I remember this, iirc we allow dependencies now even from non whitelisted sources, no?
[07:13] <mvo> rbalint: for exactly this reason
[07:13]  * mvo needs to step out for a little bit
[07:15] <rbalint> mvo: you seem to be right, the config file is a bit misleading
[07:24] <mvo> rbalint: yeah, interessting error in travis, maybe apt.apt_pkg.config.set("Debug::pkgProblemResolver","1") will help
[07:24] <mvo> rbalint: also "debug::pkgDepcache::marker","1" - not sure if we automatically add this with --debug
[07:24] <mvo> rbalint: maybe we should :)
[07:26] <rbalint> mvo: python3 (python-apt) is also crashing in https://travis-ci.org/mvo5/unattended-upgrades/builds/347636065
[07:26] <rbalint> juliank: ^
[07:26] <rbalint> (python-apt is just a suspect)
[07:30] <rbalint> mvo: for today i planned only tagging 1.0 and happily uploading it to Debian & Ubuntu, but that escalated quickly :-)
[07:38] <mvo> rbalint: heh, yeah, the joy of software development :/
[07:39] <slangasek> nacc: not sure I understand the question; the ubuntu-keyring package is authoritative
[07:39] <slangasek> nacc: so you probably need to be pulling it into your snap?
[08:59] <rbalint> mvo: ok, now i finalized u-u's changelog, too
[09:04] <mvo> rbalint: cool, did you figure out the travis error?
[09:07] <rbalint> i found several ones :-\
[09:08] <rbalint> mvo: it is hopeless to gate the PRs with an upgrade test running on crashing python/dependencies + with 3rd-party packages
[09:08] <rbalint> u-u correctly fails on apt resolver error in the best case
[09:09] <rbalint> the python-apt crash is already tracked: LP: #1737441
[09:11] <mvo> rbalint: agreed if the test case includes 3rd part packages, I though it was a vanilla ubuntu
[09:26] <rbalint> mvo: one more little change, please check the PR and it it is good i'm prepping the release
[09:46] <mvo> rbalint: sure, let me look.
[10:20] <mvo> rbalint: looks great now, is it ready to be merged? if so I am happy to press the button
[10:22] <rbalint> ready! :-)
[10:23]  * mvo hugs rbalint 
[10:25] <rbalint> mvo: hugs mvo :-)
[10:25]  * rbalint hugs mvo :-)
[13:29] <tkamppeter> Hi, I need sponsoring for an upload of brlaser before the FF today. It is the new version 4: https://bugs.launchpad.net/ubuntu/+source/brlaser/+bug/1752579
[13:57] <ahasenack> sil2100: hi there,
[13:57] <ahasenack> sil2100: about #1717040, xenial doesn't have the updated zstd package yet
[13:57] <ahasenack> sil2100: just wondering if you missed it, or if you really just wanted to work on the artful update?
[13:58] <ahasenack> bug #1717040
[13:58] <ahasenack> thanks ubottu
[13:58] <sil2100> ahasenack: hey! I didn't want to publish it as we're still in .4 freeze, and from what I know it's seeded in the ubuntustudio flavour
[13:59] <ahasenack> ah
[13:59] <ahasenack> sil2100: so what do we do now, wait for .4 to be out, then publish it? Is there a trigger so we don't forget?
[14:00] <sil2100> ahasenack: well, it's marked as ready so the SRU members see it as ready, and once we're done with .4 it'll just get published like any other marked SRU
[14:00] <ahasenack> ah, ok. The std comment that was added hinted that it would not be looked at anymore
[14:00] <ahasenack> but that might be about the artful task then
[14:02] <sil2100> Yes :)
[14:04] <ahasenack> ok, thanks
[16:06] <nacc> slangasek: you can't pull from not the version you're building on without lots of hacks
[16:06] <nacc> slangasek: and the xenial debian-archive-keyring package (apparnetly) does not have latest Debian keyrings
[16:07] <nacc> I'm checking now
[16:07] <nacc> slangasek: yeah, that's the problem, i think
[16:08] <nacc> (possibly true for the ubuntu keyring too, but perhaps it hasn't changed enough to be noticed)
[16:28] <nacc> slangasek: i can rephrase my question if that will make it clearer :)
[16:30] <xnox> nacc, what are you verifying? and how did you get those files?
[16:32] <nacc> xnox: https://git.launchpad.net/usd-importer/commit/?id=48249b21607fdfbb80af9d53e8d0b1375d8778c1 -- basically, we are using the archive to determine what files are in which components in releases so that we can phase correctly.
[16:32] <nacc> xnox: those files need to be verified using the archive keys
[16:32] <xnox> nacc, specifically which files / and signatures.
[16:32] <xnox> nacc, sorry =) i don't want to read source code....
[16:33] <xnox> nacc, are you trying to verify signatures of .dsc? cause we do not ship keyrings to verify that.
[16:33] <nacc> xnox: Release files
[16:33] <nacc> xnox: no
[16:33] <nacc> xnox: we implicitly trust LP to give us good data
[16:36] <xnox> nacc, so ubuntu-keyring should have all the keys in /usr/share/keyrings/ubuntu-archive-keyring.gpg and /usr/share/keyrings/ubuntu-archive-removed-keys.gpg
[16:36] <xnox> for all the releases / archives.
[16:36] <nacc> xnox: even on xenial?
[16:36] <xnox> nacc, yes.
[16:36] <nacc> xnox: ok, i can leave that as-is; what about the debian keys?
[16:36] <xnox> nacc, debian-keyring too... but they rotate keys too often. I guess we could SRU debian-keyring to update keys there.
[16:37] <nacc> xnox: yeah, i'm seeing it fail right now for something in debian (i can figure out which in a moment)
[16:41] <nacc> xnox: so ... while the SRU will take ~ 7 days; what should I do in the meanwhile? I can't generally wait on that delay (we get gpg failures)
[16:42] <xnox> nacc, you can download and install newer debian-keyring on the machine you need at.....
[16:42] <nacc> xnox: from ... ?
[16:42] <xnox> nacc, or you can be a normal person, and use chroots to get the right keyrings.
[16:42] <nacc> xnox: you want me to use chroots in a snap?
[16:42] <xnox> nacc, if you don't know how to install debian-keyring package from a different release?
[16:43] <nacc> xnox: snaps don't make it easy
[16:43] <xnox> nacc, it's in the archive....
[16:43] <nacc> xnox: so i'd need to manually download a fixed URL
[16:43] <xnox> nacc, this is #ubuntu-devel; i guess you need #snapcraft?! </troll>
[16:43] <nacc> xnox: :)
[16:43] <nacc> xnox: the typical answer for snaps is 'build it yourself'
[16:43] <nacc> i don't know that i can for a native package
[16:43] <xnox> O_o
[16:44] <nacc> well, i mean i can, i meant i'm not sure i should
[16:44] <xnox> nacc, it's just a file.... you can grab them from commit in your git repo.... no?!
[16:44] <nacc> xnox: and even so, i'm not sure where the 'source' is ... i found debian-keyring on salsa; is ubuntu-keyring on LP?
[16:44] <nacc> xnox: a file i have to keep up to date all the time?
[16:44] <xnox> nacc, you should use $ pull-lp-source debian-keyring
[16:44] <xnox> nacc, you said you can't wait for sru
[16:45] <xnox> nacc, please contact somebody else, there is nothing that requires foundations involvement here.
[16:45] <nacc> xnox: i am just asking for suggestions
[16:45] <nacc> xnox: if you don't want to help, please don't.
[16:47] <slangasek> nacc: so perhaps this should be an SRU of the keyring package?
[16:47] <ddstreet> nacc is pull-lp-source failing, or code in usd-importer?
[16:48] <nacc> slangasek: i think that would solve it this time; but i am not sure it solves it long-term
[16:48] <nacc> ddstreet: context?
[16:48] <ddstreet> nacc i don't have context for your discussion ^
[16:48] <nacc> ddstreet: oh it's about git-ubuntu trying to verify archive files with gpg
[16:48] <ddstreet> ok so it's not using pull- then
[16:48] <ddstreet> directly trying to verify sig
[16:48] <nacc> ddstreet: right, this is for the Release file itself
[16:48] <nacc> ddstreet: not for source packages
[16:49] <ddstreet> ah ok cool
[16:49] <slangasek> nacc: surely it's an issue for the keyring packages in a stable release to not have up-to-date info about the archives
[16:49] <nacc> slangasek: oh yes, i agree
[16:49] <slangasek> nacc: and ISTM that your concern is derivative of this
[16:49] <nacc> slangasek: i guess i meant we probably need to do that at all times
[16:49] <nacc> slangasek: so it's both do it now, and commit to doing it in the future :)
[16:49] <slangasek> yeah
[16:50] <ddstreet> nacc how far back are you importing from? stopping at precise or going farther than that?
[16:50] <nacc> ddstreet: as far back as LP goes
[16:50] <nacc> ddstreet: inclusive of debian
[16:51] <ddstreet> sweet, that'll be a big old git repo for each pkg :)
[16:51] <nacc> ddstreet: yeah :)
[16:53] <nacc> slangasek: i can file a bug
[16:55] <nacc> meanwhile have to go figure out this regression in snapcraft :
[16:59] <nacc> slangasek: LP: #1752656 i'll fix the tasks in a bit
[17:00] <ddstreet> nacc i noticed some older packages used keys that were no longer in newer releases, but were in older releases...is that what you're addressing in ^
[17:01] <nacc> ddstreet: which key do you mean? the uploader's? or the archive key?
[17:01] <ddstreet> uploader's
[17:01] <nacc> ddstreet: the old keys are in the 'old' keyrings, usually
[17:01] <ddstreet> sorry, nm - you're talking about the archive key
[17:01] <nacc> ddstreet: we don't store uploader's keys in any of the keyrings afaict
[17:01] <nacc> ddstreet: yeah
[17:01] <ddstreet> yep sorry :)
[17:01] <ddstreet> different keys, nm me :)
[17:01] <nacc> np, it's easy to mix them up
[17:31] <nacc> ddstreet: did you try using ubuntu-archive-removed-keys.gpg ?
[17:31] <nacc> ddstreet: RE: LP: #1700846
[17:32] <ddstreet> nacc i haven't, no
[17:32] <nacc> ddstreet: that probably would fix it for you
[17:32] <nacc> ddstreet: that's what git-ubuntu is ahving to do, use both old and new keyrings, since we don't which will work
[17:33] <ddstreet> cool i'll try it, but as pull-*-source can be used by anyone it still probably needs to default to continue if there's no pub key...i can update the warning msg tho
[17:33] <nacc> ddstreet: ack
[17:34] <ddstreet> would be great if my ubuntu-dev-tools changes could get merged one of these days...been waiting for quite a long time now, i think people are getting tired of me bugging them to review it
[17:34] <ddstreet> anyway
[18:27] <ddstreet> nacc sorry for another q about git-ubuntu; any plan for it to handle source/changes of snaps?  for example, 'git ubuntu clone git-ubuntu' does not work :(
[18:28] <ddstreet> in fact i'm not entirely sure how snap sources/changes are tracked/available...
[18:28] <nacc> ddstreet: not possible, afaik
[18:28] <ddstreet> pull-snap-source maybe...
[18:28] <nacc> ddstreet: and no :)
[18:28] <ddstreet> :)
[18:28] <nacc> ddstreet: i believe this is something the snap team is working on (reproducible snaps, getting source for snaps)
[18:28] <nacc> but i have no intention of importing them
[18:29] <ddstreet> ack
[18:29] <nacc> usually, they are already in an external git repository
[18:29] <nacc> so the benefit is lower, i'd think
[18:29] <ddstreet> yeah, and IIUC not all snaps even make source public
[18:30] <nacc> nor should they, depending, i guess
[18:30] <nacc> ddstreet: we are only concerned with 'the archive' in git-ubuntu
[18:31] <nacc> ddstreet: technically, snaps are not ubuntu specific :)
[18:31] <ddstreet> true, right
[18:31] <ddstreet> good point :)
[18:34] <nacc> ddstreet: feels like it should be a snapcraft or snap subcommand (I guess)
[19:19] <xevious> Is there an archive of previous Bionic packages? It seems like a change in mysql-server-5.7's postinst script broke my image building script.
[19:20] <nacc> xevious: you can download them from the archive
[19:21] <nacc> err from LP
[19:21] <nacc> https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.21-1ubuntu1/+build/14311288
[19:21] <nacc> https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.20-1ubuntu1/+build/13855476
[19:28] <bdmurray> xevious: Its not asking for a password for the mysql user anymore
[19:29] <bdmurray> bug 1752215
[19:30] <xevious> The error I'm getting is "Error: Unable to shut down server with process id 2796"
[19:30] <bdmurray> Okay, maybe its not that issue then. ;-)
[19:31] <nacc> powersj: --^ you may want to subscribe to that
[19:31] <nacc> rbasak: as well
[19:32] <powersj> nacc: thx
[19:45] <wxl> does anyone have any idea where the upstream code of debian-installer is? i can't find it on salsa.debian.org
[19:49] <sladen> wxl: https://wiki.debian.org/DebianInstaller/Git  suggests it is still at  https://anonscm.debian.org/cgit/d-i/
[19:50] <wxl> thanks sladen. the project in launchpad was pointing to anonscm but a different location, and it was failing, so i figrued it SHOULD have been on salsa, but i guess everything hasn't been moved over.
[20:05] <nacc> xevious: i got to those links via the publishing history of mysql-5.7 fwiw
[20:06] <xevious> nacc: Yeah, thanks for pointing that out. I'm trimming my image creation process down to the bare minimum steps to reproduce the issue I'm seeing.
[20:06] <nacc> xevious: np
[20:15] <xevious> bdmurray: I created a bug about the issue I'm seeing: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1752705
[20:24] <xevious> bdmurray: Does anything look wrong in those steps to reproduce?
[20:24] <nacc> xevious: have you tried running the postinst manually (possibly with -x ) ?
[20:24] <xevious> That'll be my first step after I get back from meeting with my dad for coffee/tea.
[20:25] <nacc> xevious: ack
[20:25] <xevious> I'll be back in a half hour or 45.
[20:50] <sunweaver> nacc: gosa has been uploaded to Debian unstable today. gosa 2.7.4+reloaded3-2 is your friend.
[20:50] <sunweaver> Can you make sure it lands in Ubuntu bionic?
[20:50] <nacc> sunweaver: yep
[20:51] <sunweaver> nacc: thx!!!
[20:51] <nacc> sunweaver: thank you!
[20:51] <sunweaver> welcome!
[20:51] <sunweaver> was a pressing issue on the Debian side, too.
[20:52] <nacc> sunweaver: yep
[21:03] <nacc> sunweaver: LP: #1752713 I'll sync once Launchpad can see it
[21:42] <xevious> Clearly, I meant a half hour *plus* 45.
[21:42] <roadmr> microsoft minutes, I guess
[22:05] <flooood> hey folks! i tried to modify hid.ko (hid-core.c), i therefore inserted some printk's and replaced the module
[22:05] <flooood> but the messages never appear on dmesg
[22:05] <flooood> dbus[607]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.1" (uid=0 pid=613 comm="/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" ...
[22:05] <nacc> flooood: i think you want #ubuntu
[22:05] <flooood> is what i get
[22:06] <nacc> flooood: although not really ontopic there either :)
[22:06] <flooood> are you sure? i think ubuntu-devel fits best, isn't it? since i try to debug some strange behaviour in ubuntu
[22:07] <xevious> nacc: I logged into the container after the failed install, added `set -x` to mysql-server-5.7.postinst, and ran `dpkg --configure -a` and it ran the configure script successfully. I'm testing dropping a postinst with `set -x` in it and setting its immutable bit before installing the package.
[22:07] <xevious> I'm not sure how dpkg will react to that.
[22:08] <nacc> flooood: this is for development *of* ubuntu
[22:14] <xevious> Well, as I suspected, dpkg didn't like being unable to unpack the package.
[22:16] <nacc> xevious: :)
[22:16] <nacc> xevious: is it possible the postinst always works when run twice?
[22:16] <nacc> (as opposed to being related to set +x ) ?
[22:16] <xevious> That's what I expect. I'll confirm now.
[22:17] <flooood> hm, i would expect that debugging *of* ubuntu *is* development of ubuntu, but okay...
[22:18] <nacc> flooood: you're debugging some module you modified, right?
[22:19] <flooood> nope, i modified it TO debug it
[22:19] <flooood> my modification is "insert printk's"
[22:19] <nacc> flooood: i don't see how dbus is relevant to printk
[22:19] <nacc> flooood: those go into the kernel log buffer
[22:20] <flooood> me too, but that's the only message i get in the moment when i would expect the kernel message - anyhow, have to reboot. c ya
[22:20] <nacc> flooood: also, how did you 'replace themodule'
[22:21] <nacc> flooood: i'm really fairly sure this is the wrong channel, in any case
[22:54] <flooood> okay, spooky... i deleted hid.ko from /lib/modules/..., rebooted and it  _still_ gets loaded, according to modules.builtin, it is _not_ builtin
[22:55] <flooood> according to modinfo "there is no such ..."
[22:55] <nacc> flooood: still wrong channel, it's in the initrd almost certainly
[22:55] <nacc> flooood: you need to rebuild the initrd if you want different modules
[22:56] <flooood> nacc: where is the right channel then, #ubuntu-debug? ;D
[22:56] <flooood> thanks!
[22:58] <nacc> flooood: afaict, you are doing normal kernel stuff, so a kernel channel