/srv/irclogs.ubuntu.com/2016/10/17/#ubuntu-devel.txt

pittiGood morning03:49
sladenpitti: Morgen04:04
=== Anja_ is now known as Anja
pittihappyaron: hey, how are you?06:17
pittihappyaron: 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 term06:18
pittihappyaron: I'll forward the "config from /run" ones to upstream today06:18
cpaelzergood morning06:25
=== King_InuYasha is now known as Son_Goku
=== Mirv_ is now known as Mirv
=== geser_ is now known as geser
xnoxgatwick is stuck cleaning06:59
happyaronpitti: yes of course I want to merge with Debian07:16
happyaronty for forwarding it!07:17
pittihappyaron: great, thanks07:17
pittihappyaron: looking forward to losing the giant ofono patches :)07:17
happyaronpitti: yup, :)07:41
=== _salem is now known as salem_
=== salem_ is now known as _salem
tjaaltondoes errors.ubuntu.com force logging in before seeing the trace?08:48
tjaaltontrying it out on a blank browser profile would suggest so08:49
tjaaltonmakes it useless for upstreams08:49
pittitjaalton: we collect/upload these on a wide scale mostly automatically, they might contain private information08:50
tjaaltonok, well pastebin isn't far away.. so nevermind08:50
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
tjaaltonhmm, wonder if there could be a way to not send crashes to errors.u.c if ppa's are being used, or mainline kernels09:54
=== caribou_ is now known as caribou
pavlushkacpaelzer: ping10:35
pittia10:37
cpaelzerpavlushka: üong10:51
cpaelzerpavlushka: ü is too close to p when coming back from lunch - should have been pong :-/10:51
pavlushkacpaelzer: I have added the details needed to LP bug 1629038, please take a look.10:52
ubottuLaunchpad 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/162903810:52
pavlushkacpaelzer: ok I should have pinged you in #ubuntu-bugs, next time :)10:53
cpaelzerpavlushka: fine for me - I have the tab open and will take a look before EOD10:54
cpaelzerpavlushka: how long would you be around in case I have further questions?10:54
pavlushkacpaelzer: can't assure about power/Internet-link (if it goes down), otherwise I will be available :)10:56
pittihappyaron: 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 those11:17
=== 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
happyaronpitti: wow great!13:57
BlackJohnnyhi14:01
BlackJohnnyi have a problem with ubuntu skd after upgrading to 16.10 ... if anyone can help with the following pls let me know14:02
BlackJohnnyit seems that this command fails usdk-target autosetup -y14:03
BlackJohnnywith the error rror: open /etc/default/lxd-bridge: no such file or directory14:03
BlackJohnnythis command is executed when I try to start the IDE14:03
BlackJohnnyprobably some initial configuration scripts14:04
=== josepht` is now known as josepht
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest56218
=== _salem is now known as salem_
smoserare we able to upload to zesty yet ?15:22
infinitysmoser: No.15:34
=== salem_ is now known as _salem
=== Guest56218 is now known as mfisch
=== mfisch is now known as Guest8770
=== Guest8770 is now known as mfisch
naccrbasak: is LP: #1632907 a known mysql issue?16:30
ubottuLaunchpad 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/163290716:30
* rbasak looks16:32
naccrbasak: thanks16:33
rbasaknacc: 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
rbasakI've certainly never seen that, anyway. Need steps to reproduce to consider it not a misconfiguration, IMHO.16:33
naccrbasak: ack, thanks16:34
naccsarnold: 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:35
rbasakyakkety-proposed still contains 1.7~git20160703+dfsg-1 that never migrated for good reasons.16:37
rbasakBut users may now have -proposed enabled because Yakkety is released.16:37
rbasakThat sounds like a problem to me, unless I'm mistaken? Should we be clearing out -proposed before release?16:37
rbasak(my example is src:heimdal, sorry)16:38
cjwatsonrbasak: 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
cjwatsonI think just deleting would make it hard to keep track.16:38
rbasakcjwatson: thanks, but isn't that a problem with the process then?16:39
rbasakBecause 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
ubottubug 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/163365316:40
cjwatsonrbasak: I find it hard to care, given that having -proposed enabled is always for the adventurous.16:41
cjwatsonMaybe there's some way to improve it, I just don't see it as especially urgent.16:41
cjwatsonIt might be possible to delete, but somebody would have to keep a list ...16:42
mapreria 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
rbasakI'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:42
rbasakOtherwise we'll put people off testing proposed, and I want the opposite.16:43
naccsmb: cpaelzer: any chance you could peek at LP: #1633207? Should that be supported?16:46
ubottuError: Could not gather data from Launchpad for bug #1633207 (https://launchpad.net/bugs/1633207). The error has been logged16:46
rbasakI filed bug 163420116:49
ubottubug 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/163420116:49
rbasakpowersj: do you want to dupe those into this bug?16:50
powersjrbasak: shoot I already merged them into the one you called out.16:50
rbasakAh, 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:50
powersjrbasak: shall I move them to that one?16:51
rbasakPlease, if they filed after Yakkety was released.16:51
powersjall submitted on the 14th, so I will16:51
rbasakThanks!16:52
cpaelzernacc: out of the blue I don't know16:54
cpaelzernacc: would have to check the doc/sources to answer that16:54
nacccpaelzer: thanks16:59
infinityrbasak: I think we can improve on this for next time, actually, based on a tool Andy's working on for me.17:02
infinityrbasak: Not much I can do about it this time, though. :P17:03
rbasakThat 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:03
naccsmoser: have you seen LP: #1633453 ?17:05
ubottuLaunchpad bug 1633453 in cloud-init (Ubuntu) "ssh is started before cloud-init completed" [Undecided,New] https://launchpad.net/bugs/163345317:05
naccrbasak: smoser: https://git.launchpad.net/~nacc/ubuntu/+source/memcached18:14
naccjust re-pusehd there, with changelog entries on each import18:14
nacce.g. https://git.launchpad.net/~nacc/ubuntu/+source/memcached/commit/?h=ubuntu/devel18:14
smosernacc, i think that looks good.18:16
smoseri responded to that bug18:16
naccsmoser: thanks18:17
smoseri have a question on importer18:17
smosernacc,18:17
smoserso maybe im'just missing something18:17
smoserbut you seem to really, really want to never change things to break shas18:17
smoser(ie, you want to get this change in before "settling")18:17
smoseris there a big reason behind that ?18:18
naccreproducible imports18:18
smoseri think it inevitable that at some point you'll want to change something and future imports will nto be identical18:18
smoseri agree with the goal for sure.18:18
naccsmoser: we're discussing move to ubuntu-server-dev18:19
naccsmoser: right, and if we do that, we re-import everything18:19
naccsmoser: i'm tryign to minimize how often we'd do that :)18:19
smoserwhy would you re-import everything?18:19
naccso that a new user would be able to push if they did a local import18:20
naccthe shas need to match for that tow ork18:20
nacc*work18:20
smoserbut what is that use case ?18:21
smoseryou 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:21
smoseri think i'd just not do that.18:22
nacci believe the primary use case was for packages we had not imported18:22
naccit was never in scope to replace UDD fully18:22
naccso this will only ever cover the small set of packages the server team cares about18:22
naccat least officially18:22
smoseri'm confused for sure.18:23
smoseri suspect i'm just missing something.18:23
naccso let's say you're joe user and want to import locally some package that's not been imported to ubuntu-server-dev18:23
nacci guess we don't need to re-import, necessarily18:23
naccsmoser: i'm mostly trying to minimize how often the shas can change18:24
naccsmoser: you're right, there may be future cases where they will, we'll need to consider that then18:24
smoserand that makes sense18:24
naccsmoser: but changing all the import/ commit messages was a pretty obvious broad change, and was a godo fix18:24
nacc*good18:25
smoserbut 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
naccsmoser: right, that's why ntohing is publisehd to ubuntu-server-dev yet :)18:25
smoserso i'd suggest that in that scenario, we basically continue on with what was originally in ubuntu-server-dev18:26
naccsmoser: i'm willing to concede we won't need to rewrite published git trees18:26
smoserunless it is deemed more important to fix that tree than to break users.18:26
naccsmoser: we use teh tree contents everywhere, and right now, nothing changes those18:26
naccsmoser: 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 pacakges18:26
smoseryeah.  changing hashes is a pita for sure.18:26
smoserok. i just wanted to make sure i wasn't missing something more intrinsic than i thought.18:27
naccsmoser: no, it's nothing intrinsic, afaict -- it was a requirement from the sprint docs, mostly18:27
naccrbasak may be able to speak to it better18:27
rbasaksmoser: 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:45
rbasaksmoser: 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:46
smoserrbasak, right.18:50
smoserbut 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.18:50
=== alexisb is now known as alexisb-afk
rbasaksmoser: agreed.19:01
smosergood.19:01
smoserso since we'r'e here...19:01
smoserthe goal is to drop the usd-import-team repos ?19:02
smoseris that right?19:02
rbasaksmoser: 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 history19:02
rbasakI believe so, yes.19:02
smoserok. cool19:02
rbasakIf nacc agrees?19:02
rbasakThat's my understanding, anyway.19:02
* rbasak needs to go19:03
=== alexisb-afk is now known as alexisb
naccrbasak: smoser: yes, hopefully very soon19:45
naccrbasak: smoser: and import fresh into ubuntu-server-dev19:45
naccjgrimm: fyi, running a test import of the pacakges from your list with the newest importer20:23
naccrbasak: 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:23
jgrimmnacc, great!20:24
naccsmoser: given the importer isn't really running as a real user, it doesn't make sense to sign annotated tags, does it?20:30
smosernacc, well i dont think that "as a real user" indicates "should not sign"20:31
smoseras lots of machines sign things.20:31
=== _salem is now known as salem_
smoserif 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
naccsmoser: what e-mail address is the key tied to in those cases?20:31
smoserwell, an example is the ubuntu-cloudimage-keyring20:32
smoserhttp://paste.ubuntu.com/23340540/20:33
naccah a -noreply address?20:35
naccsmoser: so e-mails sent there, in theory, get bounced?20:35
naccsmoser: 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 something20:36
smoseri think probably jsut dev/null20:37
smoseri dont know.20:37
naccsmoser: and where did you generate that key, etc?20:37
smoseri 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
smoseri believe we could add that later though, right ?20:38
smoser(especially given a reproducible hash mechanism :)20:38
rbasakWhat if we sign (as an option) by the user who ran the command?20:39
naccsmoser: yeah, but we want to sign tags, i believe, which would change all the tags20:40
naccrbasak: yeah, i was thinking of adding a -k option20:40
naccrbasak: then we can figure out what key to use at runtime (or decide later)20:40
naccrbasak: are we ok with historical tags being unsigned?20:40
rbasakThen when pushing to an official place, sign yourself, even if just our individual keys.20:40
smoseri think signing does not actually change hashes20:40
rbasakThen the only open question is what cron should do20:40
smoserdoes it?20:40
smoseryou can sign stuff later20:40
rbasakOnly of the tag itself.20:40
naccsmoser: it creates a different tag object, aiui20:41
smoserah. right.20:41
rbasakIf 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
smoserright.20:41
naccrbasak: that's true, the pointed-to object is the same20:41
naccsorry, i'm being overly cautious about any changes :)20:41
rbasakIf 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
naccthat's a good point20:42
rbasakI wonder if that needs a chain of signed tags for full trust though, in which case perhaps signed commits would work better.20:42
utlemming smoser: correct, that key was generated by hand and then I got it signed20:43
utlemmingsmoser: I don't really remember all the details other than that is what I was told to do20:44
naccheh20:44
naccrbasak: 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, etc20:45
naccrbasak: 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:52
naccrbasak: as this feels like a policy decision, on some level20:53
rbasaknacc: that sounds fine. If we decided that commits should be signed, then we'd need to add support for that separately I think.21:04
=== salem_ is now known as _salem
slangaseksmoser, 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 mail22:23
naccrbasak: ack, do we still want to annotate them unsigned?22:26
naccslangasek: ok, thanks!22:26
=== tsimonq2 is now known as simon-says
=== simon-says is now known as tsimonq2

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!