=== TheMaster is now known as Unit193 [06:05] 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] dpb1: --^ fyi reimport on hold until i resolve that [06:21] slangasek: xnox: to be clear, in a snap, so 'run bionic' isn't an answer (yet) [06:44] mvo: imo -updates should be enabled in u-u for Ubuntu as well [06:50] mvo: otherwise updates from -security may fail to install or may be stuck due to missing dependencies [06:51] mvo: filed the PR, it may even fix Travis check === mwsb is now known as chu [07:08] mvo: u-u changes are in limbo, i'm trying to fix travis checks [07:08] mvo: you can wait with the review till i update changelog again [07:13] rbalint: hm, I remember this, iirc we allow dependencies now even from non whitelisted sources, no? [07:13] rbalint: for exactly this reason [07:13] * mvo needs to step out for a little bit [07:15] mvo: you seem to be right, the config file is a bit misleading [07:24] rbalint: yeah, interessting error in travis, maybe apt.apt_pkg.config.set("Debug::pkgProblemResolver","1") will help [07:24] rbalint: also "debug::pkgDepcache::marker","1" - not sure if we automatically add this with --debug [07:24] rbalint: maybe we should :) [07:26] mvo: python3 (python-apt) is also crashing in https://travis-ci.org/mvo5/unattended-upgrades/builds/347636065 [07:26] juliank: ^ [07:26] (python-apt is just a suspect) [07:30] mvo: for today i planned only tagging 1.0 and happily uploading it to Debian & Ubuntu, but that escalated quickly :-) [07:38] rbalint: heh, yeah, the joy of software development :/ [07:39] nacc: not sure I understand the question; the ubuntu-keyring package is authoritative [07:39] nacc: so you probably need to be pulling it into your snap? === ubott2 is now known as ubottu === ricotz_ is now known as ricotz === LtWorf_ is now known as LtWorf [08:59] mvo: ok, now i finalized u-u's changelog, too [09:04] rbalint: cool, did you figure out the travis error? [09:07] i found several ones :-\ [09:08] mvo: it is hopeless to gate the PRs with an upgrade test running on crashing python/dependencies + with 3rd-party packages [09:08] u-u correctly fails on apt resolver error in the best case [09:09] the python-apt crash is already tracked: LP: #1737441 [09:09] Launchpad bug 1737441 in python-apt (Ubuntu Bionic) "/usr/bin/unattended-upgrade:11:__GI___libc_free:operator:__gnu_cxx::new_allocator:std::allocator_traits:std::__cxx11::basic_string" [Undecided,Confirmed] https://launchpad.net/bugs/1737441 [09:11] rbalint: agreed if the test case includes 3rd part packages, I though it was a vanilla ubuntu [09:26] mvo: one more little change, please check the PR and it it is good i'm prepping the release [09:46] rbalint: sure, let me look. [10:20] rbalint: looks great now, is it ready to be merged? if so I am happy to press the button [10:22] ready! :-) [10:23] * mvo hugs rbalint [10:25] mvo: hugs mvo :-) [10:25] * rbalint hugs mvo :-) === Sir_Gallantmon is now known as Son_Goku === lyarwood is now known as lyarwood_ === lyarwood_ is now known as lyarwood === Nafallo_ is now known as Nafallo [13:29] 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:29] Launchpad bug 1752579 in brlaser (Ubuntu) "Needs sponsoring: Upload brlaser 4" [High,New] [13:57] sil2100: hi there, [13:57] sil2100: about #1717040, xenial doesn't have the updated zstd package yet [13:57] sil2100: just wondering if you missed it, or if you really just wanted to work on the artful update? [13:58] bug #1717040 [13:58] bug 1717040 in libzstd (Ubuntu Xenial) "Please backport libzstd 1.3.1+dfsg-1 (universe) from artful" [Undecided,Fix committed] https://launchpad.net/bugs/1717040 [13:58] thanks ubottu [13:58] 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] ah [13:59] 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] 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] ah, ok. The std comment that was added hinted that it would not be looked at anymore [14:00] but that might be about the artful task then [14:02] Yes :) [14:04] ok, thanks === caravena_ is now known as caravena [16:06] slangasek: you can't pull from not the version you're building on without lots of hacks [16:06] slangasek: and the xenial debian-archive-keyring package (apparnetly) does not have latest Debian keyrings [16:07] I'm checking now [16:07] slangasek: yeah, that's the problem, i think [16:08] (possibly true for the ubuntu keyring too, but perhaps it hasn't changed enough to be noticed) [16:28] slangasek: i can rephrase my question if that will make it clearer :) [16:30] nacc, what are you verifying? and how did you get those files? [16:32] 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] xnox: those files need to be verified using the archive keys [16:32] nacc, specifically which files / and signatures. [16:32] nacc, sorry =) i don't want to read source code.... [16:33] nacc, are you trying to verify signatures of .dsc? cause we do not ship keyrings to verify that. [16:33] xnox: Release files [16:33] xnox: no [16:33] xnox: we implicitly trust LP to give us good data [16:36] 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] for all the releases / archives. [16:36] xnox: even on xenial? [16:36] nacc, yes. [16:36] xnox: ok, i can leave that as-is; what about the debian keys? [16:36] nacc, debian-keyring too... but they rotate keys too often. I guess we could SRU debian-keyring to update keys there. [16:37] xnox: yeah, i'm seeing it fail right now for something in debian (i can figure out which in a moment) [16:41] 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] nacc, you can download and install newer debian-keyring on the machine you need at..... [16:42] xnox: from ... ? [16:42] nacc, or you can be a normal person, and use chroots to get the right keyrings. [16:42] xnox: you want me to use chroots in a snap? [16:42] nacc, if you don't know how to install debian-keyring package from a different release? [16:43] xnox: snaps don't make it easy [16:43] nacc, it's in the archive.... [16:43] xnox: so i'd need to manually download a fixed URL [16:43] nacc, this is #ubuntu-devel; i guess you need #snapcraft?! [16:43] xnox: :) [16:43] xnox: the typical answer for snaps is 'build it yourself' [16:43] i don't know that i can for a native package [16:43] O_o [16:44] well, i mean i can, i meant i'm not sure i should [16:44] nacc, it's just a file.... you can grab them from commit in your git repo.... no?! [16:44] 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] xnox: a file i have to keep up to date all the time? [16:44] nacc, you should use $ pull-lp-source debian-keyring [16:44] nacc, you said you can't wait for sru [16:45] nacc, please contact somebody else, there is nothing that requires foundations involvement here. [16:45] xnox: i am just asking for suggestions [16:45] xnox: if you don't want to help, please don't. [16:47] nacc: so perhaps this should be an SRU of the keyring package? [16:47] nacc is pull-lp-source failing, or code in usd-importer? [16:48] slangasek: i think that would solve it this time; but i am not sure it solves it long-term [16:48] ddstreet: context? [16:48] nacc i don't have context for your discussion ^ [16:48] ddstreet: oh it's about git-ubuntu trying to verify archive files with gpg [16:48] ok so it's not using pull- then [16:48] directly trying to verify sig [16:48] ddstreet: right, this is for the Release file itself [16:48] ddstreet: not for source packages [16:49] ah ok cool [16:49] 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] slangasek: oh yes, i agree [16:49] nacc: and ISTM that your concern is derivative of this [16:49] slangasek: i guess i meant we probably need to do that at all times [16:49] slangasek: so it's both do it now, and commit to doing it in the future :) [16:49] yeah [16:50] nacc how far back are you importing from? stopping at precise or going farther than that? [16:50] ddstreet: as far back as LP goes [16:50] ddstreet: inclusive of debian [16:51] sweet, that'll be a big old git repo for each pkg :) [16:51] ddstreet: yeah :) [16:53] slangasek: i can file a bug [16:55] meanwhile have to go figure out this regression in snapcraft : [16:59] slangasek: LP: #1752656 i'll fix the tasks in a bit [16:59] Launchpad bug 1752656 in ubuntu-keyring (Ubuntu) "Please SRU archive keyrings to older releases" [Undecided,New] https://launchpad.net/bugs/1752656 [17:00] 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] ddstreet: which key do you mean? the uploader's? or the archive key? [17:01] uploader's [17:01] ddstreet: the old keys are in the 'old' keyrings, usually [17:01] sorry, nm - you're talking about the archive key [17:01] ddstreet: we don't store uploader's keys in any of the keyrings afaict [17:01] ddstreet: yeah [17:01] yep sorry :) [17:01] different keys, nm me :) [17:01] np, it's easy to mix them up === smoser1 is now known as smoser [17:31] ddstreet: did you try using ubuntu-archive-removed-keys.gpg ? [17:31] ddstreet: RE: LP: #1700846 [17:31] Launchpad bug 1700846 in ubuntu-dev-tools (Ubuntu) "src:texinfo fails to import (importer) or download (pull-debian-source) with ASCII decoding issue" [Undecided,In progress] https://launchpad.net/bugs/1700846 [17:32] nacc i haven't, no [17:32] ddstreet: that probably would fix it for you [17:32] 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] 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] ddstreet: ack [17:34] 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] anyway === alan_g is now known as alan_g|EOD [18:27] 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] in fact i'm not entirely sure how snap sources/changes are tracked/available... [18:28] ddstreet: not possible, afaik [18:28] pull-snap-source maybe... [18:28] ddstreet: and no :) [18:28] :) [18:28] ddstreet: i believe this is something the snap team is working on (reproducible snaps, getting source for snaps) [18:28] but i have no intention of importing them [18:29] ack [18:29] usually, they are already in an external git repository [18:29] so the benefit is lower, i'd think [18:29] yeah, and IIUC not all snaps even make source public [18:30] nor should they, depending, i guess [18:30] ddstreet: we are only concerned with 'the archive' in git-ubuntu [18:31] ddstreet: technically, snaps are not ubuntu specific :) [18:31] true, right [18:31] good point :) [18:34] ddstreet: feels like it should be a snapcraft or snap subcommand (I guess) [19:19] 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] xevious: you can download them from the archive [19:21] err from LP [19:21] https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.21-1ubuntu1/+build/14311288 [19:21] https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.20-1ubuntu1/+build/13855476 [19:28] xevious: Its not asking for a password for the mysql user anymore [19:29] bug 1752215 [19:29] bug 1752215 in mysql-5.7 (Ubuntu) "Server - LAMP installation no longer asks for a mysql password" [Undecided,New] https://launchpad.net/bugs/1752215 [19:30] The error I'm getting is "Error: Unable to shut down server with process id 2796" [19:30] Okay, maybe its not that issue then. ;-) [19:31] powersj: --^ you may want to subscribe to that [19:31] rbasak: as well [19:32] nacc: thx [19:45] does anyone have any idea where the upstream code of debian-installer is? i can't find it on salsa.debian.org [19:49] wxl: https://wiki.debian.org/DebianInstaller/Git suggests it is still at https://anonscm.debian.org/cgit/d-i/ === fossfreedom_ is now known as fossfreedom [19:50] 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] xevious: i got to those links via the publishing history of mysql-5.7 fwiw [20:06] 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] xevious: np [20:15] bdmurray: I created a bug about the issue I'm seeing: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1752705 [20:16] Launchpad bug 1752705 in mysql-5.7 (Ubuntu) "installation of mysql-server fails because postinst fails to shut down server" [Undecided,New] [20:24] bdmurray: Does anything look wrong in those steps to reproduce? [20:24] xevious: have you tried running the postinst manually (possibly with -x ) ? [20:24] That'll be my first step after I get back from meeting with my dad for coffee/tea. [20:25] xevious: ack [20:25] I'll be back in a half hour or 45. [20:50] nacc: gosa has been uploaded to Debian unstable today. gosa 2.7.4+reloaded3-2 is your friend. [20:50] Can you make sure it lands in Ubuntu bionic? [20:50] sunweaver: yep [20:51] nacc: thx!!! [20:51] sunweaver: thank you! [20:51] welcome! [20:51] was a pressing issue on the Debian side, too. [20:52] sunweaver: yep [21:03] sunweaver: LP: #1752713 I'll sync once Launchpad can see it [21:03] Launchpad bug 1752713 in gosa (Ubuntu) "Please sync gosa 2.7.4+reloaded3-2 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1752713 [21:42] Clearly, I meant a half hour *plus* 45. [21:42] microsoft minutes, I guess [22:05] hey folks! i tried to modify hid.ko (hid-core.c), i therefore inserted some printk's and replaced the module [22:05] but the messages never appear on dmesg [22:05] 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] flooood: i think you want #ubuntu [22:05] is what i get [22:06] flooood: although not really ontopic there either :) [22:06] are you sure? i think ubuntu-devel fits best, isn't it? since i try to debug some strange behaviour in ubuntu [22:07] 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] I'm not sure how dpkg will react to that. [22:08] flooood: this is for development *of* ubuntu [22:14] Well, as I suspected, dpkg didn't like being unable to unpack the package. [22:16] xevious: :) [22:16] xevious: is it possible the postinst always works when run twice? [22:16] (as opposed to being related to set +x ) ? [22:16] That's what I expect. I'll confirm now. [22:17] hm, i would expect that debugging *of* ubuntu *is* development of ubuntu, but okay... [22:18] flooood: you're debugging some module you modified, right? [22:19] nope, i modified it TO debug it [22:19] my modification is "insert printk's" [22:19] flooood: i don't see how dbus is relevant to printk [22:19] flooood: those go into the kernel log buffer [22:20] 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] flooood: also, how did you 'replace themodule' [22:21] flooood: i'm really fairly sure this is the wrong channel, in any case [22:54] 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] according to modinfo "there is no such ..." [22:55] flooood: still wrong channel, it's in the initrd almost certainly [22:55] flooood: you need to rebuild the initrd if you want different modules [22:56] nacc: where is the right channel then, #ubuntu-debug? ;D [22:56] thanks! [22:58] flooood: afaict, you are doing normal kernel stuff, so a kernel channel