| === maclin1 is now known as maclin | ||
| LocutusOfBorg | mitya57, what about a qtwebkit-opensource-src sync now? | 06:06 |
|---|---|---|
| LocutusOfBorg | hello, what is the plan for unity integration? e.g. I would sync geary from Debian, the delta was about libunity-dev and libmessaging-menu-dev | 06:11 |
| LocutusOfBorg | jbicha, ^^^ | 06:11 |
| sladen | madigens: ircnick@u.c | 06:52 |
| mitya57 | LocutusOfBorg, one thing that concerns me in new webkit is https://github.com/annulen/webkit/issues/573 | 10:48 |
| mitya57 | Or do you mean sync from unstable? If yes then it is mostly equal to the current upload, so I don’t see the point. | 10:48 |
| juliank | mitya57: I guess the point is: The diff is not needed anymore, so let's sync it. | 10:54 |
| juliank | So people like minimizing diffs *a lot* | 10:55 |
| LocutusOfBorg | exactly | 10:56 |
| mitya57 | Ok, feel free to sync it then :) | 10:57 |
| LocutusOfBorg | drop diff autosync FTW | 10:57 |
| mitya57 | For Qt autosyncs are bad because upgrades such as 5.9.1 → 5.9.2 need to be done through a transition, synced versions without rdeps rebuild will just get stuck in -proposed. | 10:59 |
| LocutusOfBorg | rbalint, thanks! sponsored | 11:05 |
| LocutusOfBorg | >For Qt autosyncs are bad because upgrades such as 5.9.1 → 5.9.2 need to be done through a transition, synced versions without rdeps rebuild will just get stuck in -proposed. | 11:08 |
| LocutusOfBorg | this is how transitions work usually | 11:08 |
| LocutusOfBorg | we can even ask to blacklist qt autosyncs and then use silo to transition | 11:08 |
| LocutusOfBorg | but having a delta just to avoid autosyncs is worse than having them blacklisted :) | 11:08 |
| atkinchris | Has anyone experimented with offering read-only mounts of snapshots/persistent with Casper, much like live-boot's "persistence-read-only"? | 11:55 |
| jbicha | LocutusOfBorg: I think our general thinking for 17.10 is that we shouldn't rip out Unity integration without a good reason (like if it's too much work to update a patch) | 13:02 |
| jbicha | if you disagree, you're welcome to start a conversation on the mailing lists about that approach (maybe when 18.04 development opens) | 13:20 |
| mitya57 | LocutusOfBorg, qtwebkit FTBFS on armhf, I am uploading a version with Ubuntu delta again | 13:29 |
| mitya57 | This is needed only once, the version in experimental builds fine without delta: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2922/+packages | 13:29 |
| === Guest72992 is now known as karstensrage | ||
| === karstensrage is now known as Guest14297 | ||
| === Guest14297 is now known as karstensrage | ||
| coreycb | bdmurray: good morning. if you have some cycles this week, i uploaded an ocata point release and a bug fix for python-oslo.middleware to the zesty review queue late last week. | 14:21 |
| cpaelzer | infinity: hi can I catch you at some point today to sync on the SLOF FFE testing to DTRT on it? | 15:17 |
| cpaelzer | what time would be good for you | 15:17 |
| sarnold | cpaelzer: note infinity's not at the rally | 15:19 |
| cpaelzer | sarnold: oh really I just searched the doc | 15:21 |
| cpaelzer | maybe he is at the not attending or cancel line | 15:21 |
| cpaelzer | I didn't check | 15:21 |
| cpaelzer | thanks sarnold | 15:21 |
| mwhudson | apw, sforshee: well so the making disk images hack worked but i lost all the setuid bits | 15:22 |
| cpaelzer | he is on the list sarnold, but you sound like you know as a fact - I hope nothing bad happened | 15:25 |
| slangasek | cpaelzer: yes, he's unavailable this week; can you point me at the FFe bug? | 15:28 |
| cpaelzer | slangasek: 1706248 | 15:35 |
| cpaelzer | slangasek: he was "kind of ok" but wanted a test - and I agree but wanted to check quickly what to test | 15:35 |
| cpaelzer | slangasek: I can come down and talk with you about it if you are ok? | 15:35 |
| cpaelzer | it is just to make sure not doing a verification that isn't worth anything in your POV | 15:36 |
| cpaelzer | slangasek: well you just entered our room, so I try to catch you when you leave :-) | 15:36 |
| slangasek | cpaelzer: let's sync on the way to lunch ;) | 16:04 |
| cpaelzer | ok slangasek | 16:08 |
| slangasek | cpaelzer: 'test' here can just be a smoketest, to make sure the new slof works with our existing qemu package in artful and boot an Ubuntu VM | 16:11 |
| slangasek | cpaelzer: does slof support netbooting? If so that would be gravy; AFAIK we don't rely on that functionality anywhere | 16:11 |
| cpaelzer | it does support pxe boot IIRC but I have no maas around to test drive that | 16:13 |
| cpaelzer | but I can certainly ensure that the usual guest lifecycle works | 16:13 |
| cpaelzer | unfortunately artful install seems to be broken again on my test system but I'll get some test going | 16:14 |
| slangasek | cpaelzer: since this is slof as we will only use in VMs, and we don't rely on VM netbooting, that's not critical to test | 16:15 |
| mwhudson | apw: i managed to hack something that mostly works, thanks for the tip | 16:24 |
| rbasak | cjwatson: on dep14 (git branch and tag names), we're importing and tagging our view of Launchpad's publication of Debian package uploads. That's outside the spec I think. It doesn't belong in debian/* as we'd expect the DD to own that namespace. But it doesn't belong in ubuntu/* either. | 16:25 |
| rbasak | So I'm not sure if what we're doing there matches your expectations. | 16:26 |
| rbasak | https://git.launchpad.net/~usd-import-team/ubuntu/+source/vim/refs/ is an example | 16:26 |
| nacc | we could shove all of that under launchpad/ if we wanted | 16:26 |
| nacc | but that's just more indirection | 16:26 |
| rbasak | We're also using upstream/* as specified by dep14, but those could collide with the DD's tree objects if there are minor import differences. | 16:27 |
| rbasak | cjwatson: so I said before to you that "we're following dep14" but I guess that's not really true :-/ | 16:28 |
| rbasak | Other edge cases are that we need two pristine-tar branches to accomodate orig tarball differences. | 16:28 |
| rbasak | Really we're only following dep14 substitution rules I think. | 16:28 |
| nacc | (after fixing them :) | 16:29 |
| rbasak | :) | 16:29 |
| rbasak | nacc: "Patch queue tags" is something I don't remember considering before. Should we use that for our applied tags? | 16:30 |
| rbasak | nacc: anyway, sorry, I'll let you get on with other things. We can discuss later. | 16:31 |
| nacc | rbasak: it doesn't feel well-defined in dep14. we do use gbp-pq annotation a la dgit | 16:32 |
| wxl | \ | 16:37 |
| === rosattig__ is now known as rosattig | ||
| LocutusOfBorg | jbicha, I agree ok | 17:04 |
| LocutusOfBorg | mitya57, thanks! | 17:04 |
| seb128 | bdmurray, hey, what's the right way to push a SRU forward if some bugs failed verification (the fix is not perfect but fixes some issues so the SRU is still an improvement and there is no regression so we would like to get it pushed) | 17:42 |
| seb128 | it's about https://launchpad.net/ubuntu/+source/pulseaudio/1:8.0-0ubuntu3.4 | 17:42 |
| bdmurray | seb128: talk to me or better talk to an SRU team member who is also an archive admin as they can fully phase the update | 17:43 |
| seb128 | bdmurray, well first that one needs to be moved out of proposed | 17:43 |
| seb128 | it's not in updates yet | 17:43 |
| bdmurray | seb128: Oh, okay then I can help with that. | 17:44 |
| seb128 | bdmurray, anyway I'm speaking to you there ... is there an alias that contact sru team people? | 17:44 |
| seb128 | rather than having to bother you directly (for next time) | 17:44 |
| bdmurray | seb128: No, I believe most SRU team members are subscribed to the ubuntu release mailing list so that should work. | 17:45 |
| seb128 | k | 17:45 |
| bdmurray | seb128: so the argument for getting it into updates is that one bug failed verification but the fix for that makes things better and the other bugs are verified? | 17:47 |
| seb128 | bdmurray, not exactly, the argument is that one fix is not working but 3 other issues are fixed and there are regressions | 17:49 |
| seb128 | well or rather the 2 fixes fixes 3 of the 4 issues we though they would fix | 17:49 |
| seb128 | and there is no regression | 17:49 |
| seb128 | so it's still an improvement | 17:49 |
| bdmurray | seb128: ack, will release it in a bit. | 17:50 |
| seb128 | bdmurray, thanks | 17:59 |
| smoser | cjwatson, what is the "syntax" in a git commit message for a debian bug. | 18:32 |
| smoser | akin to: | 18:32 |
| smoser | LP: #XXXXXX | 18:32 |
| nacc | smoser: do you mean Closes: # ? | 18:32 |
| smoser | no. | 18:33 |
| smoser | not restricted to debian/changelog. | 18:33 |
| smoser | in a git commit message, i reference a bug with new line then LP: #XXXXX | 18:33 |
| cjwatson | smoser: https://help.launchpad.net/Code/Git#Linking_to_bugs | 18:33 |
| cjwatson | oh a *Debian* bug | 18:33 |
| cjwatson | do what you like | 18:34 |
| cjwatson | I'd say "Debian: #nnn" | 18:34 |
| cjwatson | but it's up to you | 18:34 |
| smoser | right. thats what i was asking. if there was something in place already. | 18:34 |
| smoser | ok. i'll just use Debian: #nnn | 18:34 |
| smoser | thanks. | 18:34 |
| nacc | I mean, afaict, it doesn't link it to a Debian bug or anything (where it = Launchpad) | 18:35 |
| cjwatson | nothing in place, no - LP doesn't track that directly except by way of bugs that have been synced into LP | 18:35 |
| nacc | yep | 18:35 |
| === Guest76567 is now known as karstensrage | ||
| mwhudson | bladernr: hey, btw subiquity user testing is in shubert tomorrow morning, the event doesn't have a location and i can't add it | 20:25 |
| === klebers_ is now known as klebers | ||
| as2000 | how can I get the applications menu extension to work in 17.10? | 21:56 |
| nacc | as2000: i think you want #ubuntu+1 | 21:56 |
| as2000 | thanks | 21:57 |
| === zumbi is now known as Guest68013 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!