[03:49] Good morning [04:04] pitti: Morgen === Anja_ is now known as Anja [06:17] happyaron: hey, how are you? [06:18] happyaron: are you planning on merging NM with Debian? updating to 1.4 should get us rid of our biggest patches, and then we should review the Ubuntu patches to see which we can get rid of in the long term [06:18] happyaron: I'll forward the "config from /run" ones to upstream today [06:25] good morning === King_InuYasha is now known as Son_Goku === Mirv_ is now known as Mirv === geser_ is now known as geser [06:59] gatwick is stuck cleaning [07:16] pitti: yes of course I want to merge with Debian [07:17] ty for forwarding it! [07:17] happyaron: great, thanks [07:17] happyaron: looking forward to losing the giant ofono patches :) [07:41] pitti: yup, :) === _salem is now known as salem_ === salem_ is now known as _salem [08:48] does errors.ubuntu.com force logging in before seeing the trace? [08:49] trying it out on a blank browser profile would suggest so [08:49] makes it useless for upstreams [08:50] tjaalton: we collect/upload these on a wide scale mostly automatically, they might contain private information [08:50] ok, well pastebin isn't far away.. so nevermind === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [09:54] hmm, wonder if there could be a way to not send crashes to errors.u.c if ppa's are being used, or mainline kernels === caribou_ is now known as caribou [10:35] cpaelzer: ping [10:37] a [10:51] pavlushka: üong [10:51] pavlushka: ü is too close to p when coming back from lunch - should have been pong :-/ [10:52] cpaelzer: I have added the details needed to LP bug 1629038, please take a look. [10:52] Launchpad bug 1629038 in samba (Ubuntu) "package samba 2:4.3.11+dfsg-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,New] https://launchpad.net/bugs/1629038 [10:53] cpaelzer: ok I should have pinged you in #ubuntu-bugs, next time :) [10:54] pavlushka: fine for me - I have the tab open and will take a look before EOD [10:54] pavlushka: how long would you be around in case I have further questions? [10:56] cpaelzer: can't assure about power/Internet-link (if it goes down), otherwise I will be available :) [11:17] happyaron: btw, the two debian/patches/Read-* patches won't apply to 1.4; I have them ported to 1.4 on the upstream patch already, so please don't waste time on those === Guest23990 is now known as zigo === ara is now known as Guest69211 === SotK_ is now known as SotK === RAOF_ is now known as RAOF === coreycb` is now known as coreycb [13:57] pitti: wow great! [14:01] hi [14:02] i have a problem with ubuntu skd after upgrading to 16.10 ... if anyone can help with the following pls let me know [14:03] it seems that this command fails usdk-target autosetup -y [14:03] with the error rror: open /etc/default/lxd-bridge: no such file or directory [14:03] this command is executed when I try to start the IDE [14:04] probably some initial configuration scripts === josepht` is now known as josepht === mfisch` is now known as mfisch === mfisch is now known as Guest56218 === _salem is now known as salem_ [15:22] are we able to upload to zesty yet ? [15:34] smoser: No. === salem_ is now known as _salem === Guest56218 is now known as mfisch === mfisch is now known as Guest8770 === Guest8770 is now known as mfisch [16:30] rbasak: is LP: #1632907 a known mysql issue? [16:30] Launchpad bug 1632907 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 5.7.15-0ubuntu0.16.04.1 failed to install/upgrade: 子进程已安装 post-installation 脚本返回错误状态 1" [Undecided,New] https://launchpad.net/bugs/1632907 [16:32] * rbasak looks [16:33] rbasak: thanks [16:33] nacc: I think that's a system misconfiguration. The postinst failed because update-rc.d failed, because insserv failed complaining about "insserv: script mysql: service mysql already provided!". [16:33] I've certainly never seen that, anyway. Need steps to reproduce to consider it not a misconfiguration, IMHO. [16:34] rbasak: ack, thanks [16:35] sarnold: is there a preferred launchpad method to bring a bug to the attention of the security team in case of a regression due to a CVE fix? [16:37] yakkety-proposed still contains 1.7~git20160703+dfsg-1 that never migrated for good reasons. [16:37] But users may now have -proposed enabled because Yakkety is released. [16:37] That sounds like a problem to me, unless I'm mistaken? Should we be clearing out -proposed before release? [16:38] (my example is src:heimdal, sorry) [16:38] rbasak: The usual practice is that once we have a usable zesty-proposed (etc.) then we copy everything to that and delete from yakkety-proposed. [16:38] I think just deleting would make it hard to keep track. [16:39] cjwatson: thanks, but isn't that a problem with the process then? [16:40] Because that then leads to bug 1633653, for example, where a user who has proposed enabled is upgrading from Xenial to Yakkety. And we want to encourage that. [16:40] bug 1633653 in heimdal (Ubuntu) "package libhcrypto4-heimdal:amd64 1.7~git20160703+dfsg-1 failed to install/upgrade: package libhcrypto4-heimdal:amd64 1.7~git20160703+dfsg-1 cannot be configured because libhcrypto4-heimdal:i386 is at a different version (1.7~git20150920+dfsg-4ubuntu1)" [Undecided,Confirmed] https://launchpad.net/bugs/1633653 [16:41] rbasak: I find it hard to care, given that having -proposed enabled is always for the adventurous. [16:41] Maybe there's some way to improve it, I just don't see it as especially urgent. [16:42] It might be possible to delete, but somebody would have to keep a list ... [16:42] a way to improve it would be for sabdfl to announce the new series name before the release, so they can be copied at release time? [16:42] I'd like to encourage people to volunteer to test proposed and report bugs in it (for stable releases). That helps us with SRU verification. But in that case, we should ensure (IMHO) that our processes don't leave them broken unnecessarily. [16:43] Otherwise we'll put people off testing proposed, and I want the opposite. [16:46] smb: cpaelzer: any chance you could peek at LP: #1633207? Should that be supported? [16:46] Error: Could not gather data from Launchpad for bug #1633207 (https://launchpad.net/bugs/1633207). The error has been logged [16:49] I filed bug 1634201 [16:49] bug 1634201 in Ubuntu "Release process leaves stable -proposed with broken packages, breaking users who volunteer to test stable -proposed for SRU verification purposes" [Undecided,New] https://launchpad.net/bugs/1634201 [16:50] powersj: do you want to dupe those into this bug? [16:50] rbasak: shoot I already merged them into the one you called out. [16:50] Ah, sorry. That's slightly different possibly, because users shouldn't have proposed enabled in a development release at all, but may have it enabled in a stable release for testing pending SRUs. [16:51] rbasak: shall I move them to that one? [16:51] Please, if they filed after Yakkety was released. [16:51] all submitted on the 14th, so I will [16:52] Thanks! [16:54] nacc: out of the blue I don't know [16:54] nacc: would have to check the doc/sources to answer that [16:59] cpaelzer: thanks [17:02] rbasak: I think we can improve on this for next time, actually, based on a tool Andy's working on for me. [17:03] rbasak: Not much I can do about it this time, though. :P [17:03] That sounds good. Yeah sure, this time it's clearly easiest to clear out proposed the usual way once the new series is ready. I'm only raising it because it seems like a recurring broken thing, rather than a one-off. [17:05] smoser: have you seen LP: #1633453 ? [17:05] Launchpad bug 1633453 in cloud-init (Ubuntu) "ssh is started before cloud-init completed" [Undecided,New] https://launchpad.net/bugs/1633453 [18:14] rbasak: smoser: https://git.launchpad.net/~nacc/ubuntu/+source/memcached [18:14] just re-pusehd there, with changelog entries on each import [18:14] e.g. https://git.launchpad.net/~nacc/ubuntu/+source/memcached/commit/?h=ubuntu/devel [18:16] nacc, i think that looks good. [18:16] i responded to that bug [18:17] smoser: thanks [18:17] i have a question on importer [18:17] nacc, [18:17] so maybe im'just missing something [18:17] but you seem to really, really want to never change things to break shas [18:17] (ie, you want to get this change in before "settling") [18:18] is there a big reason behind that ? [18:18] reproducible imports [18:18] i think it inevitable that at some point you'll want to change something and future imports will nto be identical [18:18] i agree with the goal for sure. [18:19] smoser: we're discussing move to ubuntu-server-dev [18:19] smoser: right, and if we do that, we re-import everything [18:19] smoser: i'm tryign to minimize how often we'd do that :) [18:19] why would you re-import everything? [18:20] so that a new user would be able to push if they did a local import [18:20] the shas need to match for that tow ork [18:20] *work [18:21] but what is that use case ? [18:21] you want to have no access to the previously-imported tree, and run your import and then push over the previously improted tree that others have used for things. [18:22] i think i'd just not do that. [18:22] i believe the primary use case was for packages we had not imported [18:22] it was never in scope to replace UDD fully [18:22] so this will only ever cover the small set of packages the server team cares about [18:22] at least officially [18:23] i'm confused for sure. [18:23] i suspect i'm just missing something. [18:23] so let's say you're joe user and want to import locally some package that's not been imported to ubuntu-server-dev [18:23] i guess we don't need to re-import, necessarily [18:24] smoser: i'm mostly trying to minimize how often the shas can change [18:24] smoser: you're right, there may be future cases where they will, we'll need to consider that then [18:24] and that makes sense [18:24] smoser: but changing all the import/ commit messages was a pretty obvious broad change, and was a godo fix [18:25] *good [18:25] but i just think at the point in which you publish to anywhere (ubuntu-server-dev) then i clone, i make a change locally.... if you re-import at that point, i'm broken. [18:25] smoser: right, that's why ntohing is publisehd to ubuntu-server-dev yet :) [18:26] so i'd suggest that in that scenario, we basically continue on with what was originally in ubuntu-server-dev [18:26] smoser: i'm willing to concede we won't need to rewrite published git trees [18:26] unless it is deemed more important to fix that tree than to break users. [18:26] smoser: we use teh tree contents everywhere, and right now, nothing changes those [18:26] smoser: so the only time we'd need to re-import, i think, is if all the tree hashes were to change, which seems unlikely as they come from the source pacakges [18:26] yeah. changing hashes is a pita for sure. [18:27] ok. i just wanted to make sure i wasn't missing something more intrinsic than i thought. [18:27] smoser: no, it's nothing intrinsic, afaict -- it was a requirement from the sprint docs, mostly [18:27] rbasak may be able to speak to it better [18:45] smoser: I think it's a nice property that the imports are reproducible. It allows, for example, for a third party to prepare something locally, then submit an MP, and then to official import it, and then it'd just merge in. [18:46] smoser: however, I accept that we may need to break it at some point. Then in that scenario you'd have to rebase. That's just something that would be nice to avoid if possible, that's all. Not the end of the world if we can't maintain the property, but everything is cleaner if we can. Sort of like epochs in version numbers. [18:50] rbasak, right. [18:50] but in the event that you've published something publicly , it seems more likely that you'd want to keep the published thing than re-import it. === alexisb is now known as alexisb-afk [19:01] smoser: agreed. [19:01] good. [19:01] so since we'r'e here... [19:02] the goal is to drop the usd-import-team repos ? [19:02] is that right? [19:02] smoser: if we made a note of when this happened though, we might even be able to keep the public trees reproducible by using previous importer revisions from git history [19:02] I believe so, yes. [19:02] ok. cool [19:02] If nacc agrees? [19:02] That's my understanding, anyway. [19:03] * rbasak needs to go === alexisb-afk is now known as alexisb [19:45] rbasak: smoser: yes, hopefully very soon [19:45] rbasak: smoser: and import fresh into ubuntu-server-dev [20:23] jgrimm: fyi, running a test import of the pacakges from your list with the newest importer [20:23] rbasak: i think, if these imports go through w/o error, i'm ready to mark this as 1.0 and switch to annoted tags? [20:24] nacc, great! [20:30] smoser: given the importer isn't really running as a real user, it doesn't make sense to sign annotated tags, does it? [20:31] nacc, well i dont think that "as a real user" indicates "should not sign" [20:31] as lots of machines sign things. === _salem is now known as salem_ [20:31] if the importer were running on a system and ahd access to a key we wanted to let it sign things with, it might make sense. [20:31] smoser: what e-mail address is the key tied to in those cases? [20:32] well, an example is the ubuntu-cloudimage-keyring [20:33] http://paste.ubuntu.com/23340540/ [20:35] ah a -noreply address? [20:35] smoser: so e-mails sent there, in theory, get bounced? [20:36] smoser: probably not a big deal for us either way, i'm just wondering if we want to direct importer queries always to the server ML or something [20:37] i think probably jsut dev/null [20:37] i dont know. [20:37] smoser: and where did you generate that key, etc? [20:38] i dont know how that particular key got generated, i think probalby utlemming did it... i might ask slangasek or cjwatson about best practices on such a thing. [20:38] i believe we could add that later though, right ? [20:38] (especially given a reproducible hash mechanism :) [20:39] What if we sign (as an option) by the user who ran the command? [20:40] smoser: yeah, but we want to sign tags, i believe, which would change all the tags [20:40] rbasak: yeah, i was thinking of adding a -k option [20:40] rbasak: then we can figure out what key to use at runtime (or decide later) [20:40] rbasak: are we ok with historical tags being unsigned? [20:40] Then when pushing to an official place, sign yourself, even if just our individual keys. [20:40] i think signing does not actually change hashes [20:40] Then the only open question is what cron should do [20:40] does it? [20:40] you can sign stuff later [20:40] Only of the tag itself. [20:41] smoser: it creates a different tag object, aiui [20:41] ah. right. [20:41] If you replaced a tag (eg. by signing it) then the tag would change, but I don't see how that would break anything for anyone. [20:41] right. [20:41] rbasak: that's true, the pointed-to object is the same [20:41] sorry, i'm being overly cautious about any changes :) [20:42] If the annotation said what version importer was used (eg. git describe output), then a tag signed by an Ubuntu uploader would be nice. Other uploaders would perhaps be able to trust that rather than having to check against the archive. [20:42] that's a good point [20:42] I wonder if that needs a chain of signed tags for full trust though, in which case perhaps signed commits would work better. [20:43] smoser: correct, that key was generated by hand and then I got it signed [20:44] smoser: I don't really remember all the details other than that is what I was told to do [20:44] heh [20:45] rbasak: yeah, i'll admit my key-knowledge is limited, so i'm not sure if there is already a trusted chain we should be using (by default) in the importer to recognize keys, etc [20:52] rbasak: so i think we're ok with not signing the tags for now, i can add the functionality to pass a key down to git-tag (-u option)? [20:53] rbasak: as this feels like a policy decision, on some level [21:04] nacc: that sounds fine. If we decided that commits should be signed, then we'd need to add support for that separately I think. === salem_ is now known as _salem [22:23] smoser, nacc: I don't know about best practices, you'll find that the Ubuntu archive key lists 'ftpmaster@ubuntu.com' but I'm not sure if anyone currently receives/reads that mail [22:26] rbasak: ack, do we still want to annotate them unsigned? [22:26] slangasek: ok, thanks! === tsimonq2 is now known as simon-says === simon-says is now known as tsimonq2