[00:58] tdaitx, hey, are you working on bug 1503450 at the moment? I didn't see your branch [00:58] bug 1503450 in Mir "mesa FTBFS due to missing Requires in mirclient" [High,Triaged] https://launchpad.net/bugs/1503450 [01:17] robert_ancell, yeah, I made a mistake fetched ubuntu/mir/, thus the merge had a lot of differenced and conflicts, I'm redoing it for lp:mir now [01:17] tdaitx, ok, I'll delete my branch - I added some comments on the bug. [01:19] robert_ancell, nice! just saw your comments, thanks for the help =) [01:19] tdaitx, np, thanks for finding the issue :) [01:20] robert_ancell, I had a feeling that Requires.private might be better, but I'm not that familiar with pkgconfig [01:20] Requires.private is super confusing [01:26] robert_ancell, I saw your commit now, go ahead with it... I'm acquiring experience and evidence to apply for ubuntu dev, but your commit is way better, so go ahead =) [01:27] tdaitx, ok [01:27] robert_ancell, btw, your commit still uses Requires instead of Requires.private [01:28] tdaitx, ah, I forgot the last commit! [01:28] =) === Ursinha_ is now known as Ursinha === _salem is now known as salem_ === salem_ is now known as _salem [04:23] slangasek: If the python3.4 regression made it to updates, shouldn't another SRU be uploaded that reverts the regression? Simply removing it from updates doesn't get the regression off the systems where it was installed. [04:24] ScottK: yes, but as the SRU was a new upstream version I've not been eager to initiate the 3.4.3.really.a.ball.of.lint dance. I will do so if there's no progress in a day or so [04:24] OK. [04:25] I'm a bit surprised Ubuntu is doing full version updates of Python. I'm not particularly surprised it didn't end well. [04:51] pitti: http://autopkgtest.ubuntu.com/packages/k/kdevelop/wily/armhf/ probably needs a retry? Temporary failure resolving 'ftpmaster.internal' [05:16] bdmurray: I'll look in the bug and reply there, but it seems cjwatson already responded with the reason [05:17] sitter: yes, retrying [05:17] Good morning === Malsasa_ is now known as Malsasa [07:14] good morning [07:16] hey dholbach [07:16] salut seb128 [07:18] seb128, dpm: https://translations.launchpad.net/ubuntu/ says translation focus is vivid - is that right? [07:19] dholbach, I guess that should be changed to wily [07:19] dholbach, seb128, done, well spotted [07:19] thanks [07:19] thanks [07:24] Any thoughts on an eventual SRU for bug 525674? Appropriate? Patch too invasive? [07:24] bug 525674 in update-notifier (Ubuntu) "apt-check hangs, preventing login via SSH" [Medium,Confirmed] https://launchpad.net/bugs/525674 [07:24] infinity: ^ [07:26] rbasak: oh my, please [07:26] rbasak: it doesn't seem very invasive to me, it merely runs the apt-check bits in the background, no? [07:26] i. e. ( existing code ) & [07:27] (and yes, agreed that it is really annoying) [07:32] the only other than the ( existing code ) & is the try to fix concurrent updates [07:32] this became more obvious with the async version, but was broken before as well for multi logins [07:33] cpaelzer: ah, by redirecting into $tmpfile first, and atomically moving to $stamp [07:33] pitti: that was the idea [07:34] pitti: and a cleanup added on rbasak first review to avoid stale files in /tmp [07:34] for stable SRUs this seems fine; for wily and upstream, coud this perhaps move into /etc/cron.daily/apt or a similar daily cronjob? [07:34] running this check on every login seems like a waste [07:35] pitti: I wanted to keep the update policy as close to the original as possible - anyone can later on move the check somewhere else [07:35] but for the given update I'd keep it small [07:35] it is a first step to move the updating somewhere else, but for now just tries to fix the immediate issue [07:36] ack [07:37] pitti: yeah it just moves things to the background, but though I like the approach and I can't find anything wrong with it, it feels like it's ripe for odd bugs to crop up to me. IOW I wouldn't be surprised if something came up. [07:38] I guess a cronjob is reasonable, given that it's always going to be out of date on first login. [07:38] the obvious change in behaviour is that the first time that you log in it won't show up, but that seems fine [07:38] it's almost certainly right after a fresh install [07:38] right [07:39] the cronjob avoids concurrency and blocking login at the same time, so structurally it seems even easier to me [07:39] What's almost certainly right? cpaelzer's patch? [07:39] but this is running as user, so it doesn't take an apt lock, does it? [07:39] It does run as root. [07:40] rbasak: I mean the first login is almost certainly after a fresh install, i. e. it doesn't matter if it doesn't do the check there [07:40] Ah [07:40] I meant "right after" -> immediately after, not "it is right" [07:40] I meant first login after a while, ie. when it's slow. [07:40] still it takes no apt lock [07:40] yay language ambiguities :) [07:40] the call to apt-check runs fine as user, so no apt lock involved [07:41] On a default system, what runs apt-get update to keep that up to date? [07:41] rbasak: yeah this would be the right place to update the file ... [07:41] rbasak: supposedly /etc/cron.daily/apt ? [07:41] ie. is installing unattended-upgrades or similar required to keep this updated, or are we running regular apt-get updates already? [07:42] ah, is that being called through PAM? otherwise, how can it run as root when you log in as user? [07:42] rbasak: we've done for many years [07:42] Yeah update-motd is a PAM module [07:47] actually in /etc/cron.daily/apt is even already a function that updates a marker update_stamp in case anytihng interesting had changed [07:47] it updates various timestamps after autoclean, unattended-upgrade, dist-upgrade, ... [07:48] pitti: rbasak: that would be just the spot to update the info for the motd [07:48] so again not very invasive ... [07:48] it would also avoid having to create a new daily cron and so on [07:49] Crossing an abstraction boundary here. [07:49] rbasak: between packages? [07:49] Which is OK, but maybe quite a bit of this functionality needs to move into the package supplying /etc/cron.daily/apt [07:49] cpaelzer: right [07:49] Or maybe all of the logic even [07:50] rbasak: but you are right and it would be an issue - the apt-check command is part of update-notifier and not apt (despite its name) [07:50] Ah [07:50] And we can't really have apt depend on update-notifier [07:50] so it would force everybody (apt is always there) to have update-notifier :-/ not what I want [07:51] OK so the logic has to stay in update-notifier [07:51] yes [07:51] What's the cleanest way to cross the boundary? [07:51] update_stamp [07:51] mvo: ^^ any opinion? [07:52] rbasak: the cleanest is probably to use as few dependencies as possible and just do a bi-daily update or so [07:52] Maybe have an update-notifier cron.daily job check update_stamp as left by apt's cron job, and if it is newer than the cached motd then update it? [07:52] no hooks or relying on knowing another packages file names [07:52] cpaelzer: that sounds reasonable [07:53] I think we prefer to use cron.daily where possible, so everything runs at once [07:53] rbasak: to bad there is no ordering in there [07:53] rbasak: running AFTER each cron.daily/apt would be great [07:54] wait a second [07:54] there is a /etc/cron.daily/update-notifier-common - WTF [07:56] oh, I'm in the news! http://lwn.net/Articles/657345/ [07:56] rbasak: sorry, wasn't following - if apt-check needs to move e.g. into apt itself we can consider that. I need double check if its a good fit [07:56] pitti: woah! [07:57] mvo: I'm not sure apt-check itself needs to move, but we want to change the logic around when the update-motd stuff happens [07:57] mvo: so it doesn't block login. So from cron maybe, but not sure where the best fit is. [07:57] Preferably after apt-get update runs [07:57] brb [07:58] pitti: with a great smile, as usual :) [07:58] and one of my favourite T-shirts :) [07:58] pitti: classic Monkey Island ;) [07:59] rbasak: if we want to be "just after" updates we would need to move apt-check to the package "apt" [08:00] rbasak: but if we want to keep it simle we can just hook into the already existing /etc/cron.daily/update-notifier-common [08:00] rbasak, cpaelzer: we could add apt-check --human-readable as a hook into APT::Update::Post-Invoke-Success [08:00] rbasak: still for now keeping the fix as simple as it is might be ok - on the other hand nothing stays longer than a good workaround :-/ [08:00] and make it write the data to a file that is just cat on login [08:01] this way its always up-to-date and can still be part of u-m-common [08:01] the downside is a lightly slowe apt-get update, but then the cache is hot so it should be fine [08:01] (unless I miss something) [08:02] mvo: ah so one could hook just after an update with APT::Update::Post-Invoke-Success without a reverse dependency [08:02] yet I see a small fix getting more and mre complex :-) [08:03] pitti: seems to be monkey island day - just got this refferred this morning https://chinstrap.canonical.com/~smb/askme-2.png [08:04] cpaelzer: you fight like a cow! [08:04] I am shuddering :-P [08:05] oh the times -- I can't be grateful enough to the makers of ScummVM [08:06] cpaelzer: yeah, exactly. this might actually reduce complexity but yeah, its different from what was done before [08:06] mvo: well /etc/apt/apt.conf.d/ seems rather clear - just looked into that [08:06] mvo: do you know how the new numbers are made up there - just pick one for ordering? [08:06] cpaelzer: as I said, I think this fix is still good for stables; it's just not very elegant [08:06] (for the future, I mean) [08:07] not elegant> the whole current architecture I mean, not the fix in particular [08:07] pitti: I can read your shirt's text - so I'm obliged to like to over-engineer [08:08] and I like the APT::Update::Post-Invoke-Success approach mvo suggested [08:08] cpaelzer: yeah, just one for ordering [08:09] hi, i've rebuild a ubuntu dvd with a new kernel version (taken from ubuntu source) but i'm unable to boot in uefi mode -i've got (initramfs) error-, but i'm able only to boot in bios mode. Whats' wrong? [08:09] rbasak: maybe the fix as is for SRU (if we want it as SRU) and the more complex but eventually cleaner one for wily&upstream ... [08:18] mvo: regarding slower apt-get update - we can still keep it asynchronous, so it shouldn't add a reasonable delay [08:28] * mvo nods === Malsasa_ is now known as Malsasa [08:52] cpaelzer, mvo: I like the APT::Update::Post-Invoke-Success idea. You're suggesting the update-notifier packaging dropping something into /etc/apt/apt.conf.d/ that sets it, right? And the script will just cache the result for the update-motd script later? [08:52] So cpaelzer's patch for the SRUs, and this for Wily/Wily+1? [08:52] that sounds wonderful [08:53] rbasak: yes [08:53] +1 [08:53] rbasak: ok, that sounds like an agreement - I'll come up with some code for that [08:53] then it would run exactly once, exactly when needed, and there's no collision from multiple logins, or delays of those [08:53] It's really elegant. The cache should be hot (and we could background it if needed as cpaelzer says), and then the cached output will always be current. [08:53] Right. [08:54] If backgrounding then need to be careful about collisions. [08:54] I find the "watershed" program really handy for this. IMHO it should be somewhere more common. [08:56] mvo: would multiple things that set APT::Update::Post-Invoke-Success in apt.conf.d add to the list or override? [08:56] Ah, nm. I think the manpage is telling me that it will append. [08:56] rbasak: there are already 4 in my current system [09:06] rbasak: flock from util-linux? it's okay to just fail if it's already running [09:07] watershed seems like a very rare corner case -- ISTM that either you only ever want one run (potentially triggered several times), or serialize all triggered runs [09:07] watershed runs the program once or twice, which I find a bit odd? [09:08] ah, this is to "mop up" the extra requests with just one extra run, I see [09:08] nevermind [09:09] but in this case flock is better [09:11] pitti: say I run apt-get update twice, and we async the apt-check. If apt-check hasn't finished by the time my apt-get update finishes, I want to run it again to get it up to date. [09:12] pitti: so I think watershed is the correct logic here ideally. But it's not worth pulling in a dependency just for that. [09:12] running apt-check twice in a row sounds like a waste, isn't it? [09:13] Not if the first one started too early to produce up-to-date results [09:14] As another example I use watershed + rsync to trigger an rsync when a new file arrives. [09:14] Cheap and nasty 1-way realtime replication [09:59] infinity: Thanks, fixing and taking that as an approve vote. [10:03] cjwatson: I didn't look at it with context. Is that limited to dirty suites, or will it magically create InRelease files for all old suites on first run? [10:04] infinity: All of them. [10:04] Which I think is what we want? [10:04] It does end up changing ordinarily immutable stable suites, but only to the tune of creating that file [10:05] cjwatson: yeah, that's fine. Lemme just quickly look at context. [10:06] cjwatson: Okay, gpg_opts is responsible for key-picking, shiny. Have you tested that the double-signing trick works for InRelease as well as detached sigs? [10:06] (Don't see why it wouldn't, but would be nice to make sure apt won't barf, since it'll suddenly favour InRelease as soon as it leaps into existence) [10:07] Not specifically, but let me try. [10:08] arges: your core-dev membership is expiring in 9h [10:08] Which reminds me, I need to cargo-cult that bit for ubuntu-cdimage and re-sign some history. [10:10] soren and james_w expired =( oh well. [10:12] I usually check the mail to see if expired people were active [10:14] infinity: OK, after signing wily's Release file with both my old and new personal keys: http://paste.ubuntu.com/12703167/ [10:14] which looks fine to me [10:15] Let me just try with trusty and precise to make certain [10:16] I think precise has InRelease support disabled [10:16] pitti, are you able to get a ps listing out of one of the lxc hangers, as the logs are not complete (according to stgraber) [10:18] cjwatson: Huh. Does apt warn about a single missing key on the detached sigs too? [10:18] trusty behaves the same way except that I have to use a short key ID to apt-key del [10:18] infinity: Pretty sure I remember it doing that [10:18] cjwatson: That seems kinda crap, as retiring one from the keyring entirely would make double-signed suites throw warnings. [10:18] cjwatson: But if it behaves the same for both, that's not a problem for today. [10:18] Yep, it sure does. [10:19] (schroot -c trusty-amd64 -u root, apt-key del 437D05B5, apt-get update) [10:19] cjwatson: Speaking of. Can we drop the old sig (and key) for 16.04? Pretty sure we can. [10:19] I assume we'd stop double-signing if we were doing that. [10:19] infinity: Should be able to. [10:19] infinity: Let's do it when we open? [10:20] And yeah, we should stop double-signing and drop the key together, given the warning being otherwise very scary. :P [10:20] cjwatson: Is there any argument for rotating a new key in, rather than just dropping the old one? [10:20] Possibly, but we'd need to generate one. [10:20] Well, yes. [10:21] But I think Bluefin has nearly enough shards to do that. [10:21] I think we would have three at the release sprint, if we warn a couple of sysadmins. [10:23] Right, and precise ignores InRelease, as I remembered. [10:23] So this looks fine. [10:23] cjwatson: Excellent. +1 from me, then. [10:24] Let's blow stuff up while I have plenty of day left. :-) [10:25] * infinity is going to go grab a bit of food, since sleep has completely eluded him. [10:25] cjwatson: I'll be back in time to see the world burn. [10:25] why do you think there'll be any world left to burn? [10:26] Deployed. [10:29] Ahh, a quick proposed-only run too. [10:29] Handy. [10:29] * infinity watches. [10:32] Haha it's resigning dapper [10:32] pepo FTW [10:32] (not that it matters, it won't be mirrored) [10:32] Yeah. ;) [10:33] cjwatson: Throwing stuff at a PPA to see how apt loves the new ftpmaster. [10:33] It'll be fiiiine. [10:34] cjwatson: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages [10:34] Looking good so far. [10:35] That really shrinks the apt-get update output. [10:35] cjwatson: I don't see precise ignoring it at all... [10:36] cjwatson: It totally favoured InRelease. [10:36] (But also seems to have worked) [10:36] Definitely ignored it here, but OK. [10:36] https://launchpadlibrarian.net/220504260/buildlog_ubuntu-precise-amd64.hello_2.7-2_BUILDING.txt.gz [10:36] Oh [10:36] Baseline precise [10:36] It was disabled in precise-security [10:37] Ahh, cute. [10:37] Not that I care, as we implicitly trusty ftpmaster.internal. [10:37] But a bit entertaining that we're using, I assume, an insecure codepath. [10:39] Yeah, I think it's not particularly worse than before, AIUI it's not like the natty thing where any signed material anywhere can be used to construct a compromise. [10:39] Now I wonder how many layers of caching are between me and archive.u.c [10:40] cjwatson: Looks happy across the board. [10:41] Great. An update here hasn't spotted it yet, but I guess syncproxy will take a while to catch up. [10:41] Thanks for the test. [10:41] syncproxy runs in < 2m, IIRC, but frontends are a little more slack. [10:42] apw: yes, I can start the test and then lxc-attach to it to do anything you (or stgraber) likes [10:43] pitti, i think there are two existing ones jammed right now (well were last i looked) [10:43] pitti, but i think the ones which are working are the lxc ones, it is the proper instance ones which are jamming [10:44] apw: lxc-in-cloud-instance (i386, amd64) work fine; lxc-in-lxc (armhf, ppc64el) hang indeed [10:44] infinity: There was a lot of mirroring infrastructure to fix up. Hopefully I got it all. [10:44] apw: running the test locally fails fast, so I guess it's trying to download something and fails on the proxy or something such [10:45] cjwatson: Oh. Balls. You did fix all the 2-stage scripts to exclude InRelease, I hope? [10:45] infinity: Yes [10:45] Or at least I certainly tried [10:45] infinity: See the enormous pile of private MPs attached to the bug for misc deployment stuff [10:45] cjwatson: Including ports, which doesn't use the one from the charm because reasons. Or was that us.ports? [10:46] infinity: Yes, I got ports [10:46] And us.ports [10:47] us.ports is the weird one, I think. [10:47] cjwatson: So, they worked around the juju issue that wasn't allowing them to actually deploy to mirror frontends before? :P [10:47] infinity: https://rt.admin.canonical.com/Ticket/Display.html?id=84674 [10:47] cjwatson: Yeah, ports itself is a syncproxy (so, magicmirror), us.ports uses a fork of the 2-stage mirror script instead of the generic one, for some reason or other. [10:47] I think they may have done it by hand again. [10:48] Get:1 http://archive.ubuntu.com wily InRelease [218 kB] [10:48] aha [10:48] http://archive.ubuntu.com/ubuntu/dists/wily/ shows differing timestamps though, why [10:49] I guess rsync doesn't update them if the file contents haven't changed [10:49] magicmirror resets some timestamps. [10:49] Because lamont. [10:49] Oh, I removed that but maybe it hasn't been deployed [10:50] https://code.launchpad.net/~cjwatson/canonical-magic-mirror/remove-timestamp-hacking/+merge/272718 [10:50] ... [10:50] How is InRelease *older* than Release? [10:51] Because magic-mirror knows to touch Release/Release.gpg but not InRelease [10:51] Oh, right. So, it is the lamont bit. [10:51] Gross. [10:51] We fixed that on the publisher side ages ago, right? [10:51] Except I thought I'd got a magic-mirror change deployed to touch InRelease, actually [10:51] So that's a bit weird [10:52] infinity: I did the last bit of the fix quite recently. [10:52] your removal is unmerged [10:53] It is, but it should be touching InRelease, looking at the current code. [10:53] So a bit WTF. [10:54] Oh, but that was recent too. So maybe never actually deployed. [10:54] apw: Right, I know the removal is unmerged but indeed the previous allegedly-deployed version touched InRelease [10:54] Chasing that up [10:56] pitti: is there anything I can do to help expedite the dbusmock stuff? write the release notes, perhaps? I've checked the tests with pep8, pyflakes, etc already [10:57] pitti: ping! Hey, we didn't seem to get langpack-o-matic translations yesterday uploaded to the overlay [10:57] pitti: did anything happen to those? [11:03] cjwatson: So, I'm kinda hoping this is coincidence, but we also seem to have blown up the frontends. :P [11:03] ? [11:04] apt-get update is now downloading at a snail's pace. Or not at all. Undecided. [11:04] I thought it was a local thing, but another user just complained. [11:04] Maybe they're remirroring lots or something? [11:05] Or deleting half the archive. [11:07] cjwatson: Can you reproduce, or am I and said user just going insane? [11:07] I can [11:08] Though I wouldn't normally put much stock in a network problem visible from behind my ADSL [11:08] (Or what could easily be a network problem) === Malsasa_ is now known as Malsasa [11:08] Okay, load must be through the roof. telnet just took 10s to get apache to say hi on one of them. [11:08] This seems like a bad sign. [11:09] See #is-outage [11:27] pitti, please override node-srs's autopkg test again (triggered by gdal) [11:34] infinity, or you ^^^ [11:55] sil2100: I rebuilt the -base packages manually to fix the desktop translations, so the cronjob didn't run again [11:55] sil2100: I can run it manually if needed [11:56] pitti: yes, please :) [11:56] sil2100: running [11:56] We're in freeze so we want to build out image candidate [11:56] Thanks! [11:56] pitti: Cool, thanks! [11:57] slangasek: doko: shouldn't we rather upload a revert for bug #1500768 matching the previous content of -security as the faulty SRU has been released for quite a while (and so most of people upgraded to it) and there is no assignee anymore working on it? [11:57] doko: done [11:57] bug 1500768 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU break requests" [High,Triaged] https://launchpad.net/bugs/1500768 [11:58] barry: ^ [12:10] didrocks, I'm looking at it, and I think we should not yet [12:11] doko: can you assign yourself to this bug please? The regression is already around for a couple of weeks [12:11] didrocks, nobody told me until recently [12:12] doko: last week was my first ping for you about it [12:12] "couple of weeks" != last week [12:13] doko: the issue started when python3.4 hit -updates, so a couple of weeks [12:13] doko: then, time for me to debug it (didn't want to blame python before checking it's not my side), I did debug it when I could [12:13] and found the exact interaction issue last Tuesday (so a week ago) [12:14] but people DO experience it for a couple of weeks [12:14] which is what matters here IMHO === _salem is now known as salem_ [13:08] jibel, pitti, Laney, apw: Can you guys reply to that release sprint email, so clan knows what's up? [13:08] jibel: You especially, since I wasn't sure if you wanted to come, or send a minion, or both. [13:08] when/where is it? [13:09] seb128: London, release week. Unless you meant where's the mail, in which case, it was sent to the people mentioned. :P [13:09] no, just curious [13:09] desktop team is in London next week [13:09] but that's one week before [13:09] so maybe Laney wins the right to have another week in the office ;-) === jamespag` is now known as jamespage [13:13] infinity: not quite sure yet; I've been/will be travel quite a lot these days, and at the weekend before we have a big family event in Dresden [13:14] replied, ta for the reminder [13:14] pitti: Sure. If you think it's not going to work for you, cyphermox might be a better choice. [13:14] pitti: But he's also a more expensive choice, so I need to make that call soon. ;) [13:14] oi [13:27] infinity: the lamont bit was just updating it to be faster at merging all of hte stay of execution files [13:27] stay of execution predates me\ [13:28] lamont: I think the lamont thing I was blaming you for was the timestamp mangling in magicmirror. Which was totally you. [13:28] lamont: But that was hours ago, and I blame you for a lot of things, so maybe I'm mistaken. :P [13:28] infinity: I have no memory of that action. [13:28] lamont: There's a bug log that has memory on your behalf. ;) [13:29] I'll believe that [13:29] lamont: https://bugs.launchpad.net/launchpad/+bug/1033581 [13:29] Launchpad bug 1033581 in ubuntu-archive-publishing "Publisher should set modification times on Releases et al" [Low,Fix released] [13:35] barry: 3.5 not default? [13:36] =( [13:37] xnox: it will be for xnoxian xenomorph [13:37] barry: but i need it now =) to reproduce openstack bugs which modify ordereddicts whilst interating it ;-) [13:37] fine, i can fille with it. [13:37] =) [13:38] :) it is supported for wily, so just `python3.5` [13:43] mvo: pitti: rbasak: you were such a great help this morning - FYI on the bug https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674 is the fix as discussed. Any review is welcome [13:43] Launchpad bug 525674 in update-notifier (Ubuntu) "apt-check hangs, preventing login via SSH" [Medium,Confirmed] [13:45] bdmurray: seb128 told me you're the one who can add me to the bugsquad team :) [13:51] cpaelzer: thanks! Based on your comment this sounds good. I'll review the patch. [13:53] cpaelzer: replied [13:56] piiti: thanks will, read it and agree to you - I'll come with a modified version the next days [13:57] cpaelzer: it's pretty much bikeshedding at this point; I don't like that indirection/new script particularly much, but it's not at all wrong [13:57] so if you prefer having it, keep it :) [14:00] pitti: I have removed one indirection on my own, just missed the other opportunity [14:01] pitti: and all that is training in packaging and versioning to me :-) [14:18] pitti: thanks very much for the work on dbusmock! :) [14:21] * pete-woods watch rmadison python-dbusmock now ;) [14:22] pete-woods: I didn't upload it yet (sorry, being over-pinged) [14:23] I understand [14:23] pete-woods: if it's urgent, you can always cherry-pick and directly upload to the overlay, no? [14:23] I can see you're really busy just from this channel [14:23] I have no power, so can't upload to the overlay [14:23] kinda wish I could operate dbusmock via the citrain [14:23] but I guess that makes having it in debian harder? [14:25] barry: hey hey! I'm slowly tackling some python-* FTBFS from the wily test rebuild if you don't mind :) [14:25] barry: https://bugs.launchpad.net/ubuntu/+source/python-pysaml2/+bug/1503698 is on my plate once I'm finished with some touch tasks [14:25] Launchpad bug 1503698 in python-pysaml2 (Ubuntu) "FTBFS due to broken unit tests" [Undecided,In progress] [14:26] sil2100: excellent! ping me if you need review/sponsorship [14:27] pete-woods: I uploaded a cherry-pick to the overlay, that's the fastest way [14:28] pitti: awesome, this is very much appreciated! [14:31] pitti: it'd be super awesome to be able to pass template parameters in through the main command line when you do python -m dbusmock -t mytemplate ???? [14:31] but my python-fu isn't so great [14:31] I'd be happy to work on the feature [14:31] if you had a suggestion of how to encapsulate the parameters [14:32] maybe as json? [14:32] pete-woods: there's no proper data types with plain strings, so only strings would work properly; JSON is also not typed [14:33] it's not? [14:33] pete-woods: ah, it can tell apart ints and strings indeed [14:33] I thought it had all the types of javascript [14:33] bool, string, array, number, etc [14:33] and also dict [14:34] it might not be perfect [14:34] pete-woods: so I guess it's one of json (ugly to type), gvariant-ish like "gdbus", or just live with strings and int only [14:34] most properties are simple, after all [14:35] pete-woods: but in the end it seems easier to change them after instantiation via some d-bus calls? [14:37] pitti: that involves standing up separate comms channels, right? e.g. to remove some of the default setup [14:37] I saw this as a way of supporting the existing parameters mechanism that is already supported by most of the modules [14:37] sorry, templates [14:38] without the need to modify all of the templates, to add the capability to remove the default setup [14:38] e.g. in the case of ofono, it adds a modem by default [14:38] which you don't always want [14:40] but it already has a parameter to avoid it adding the default modem [14:41] rbasak, any updates on the squid3 merge? === rickspencer3_ is now known as rickspencer3 [14:57] cyphermox: got another one of these plymouth bugs from a friend who bought a brand new thinkpad x1. first update (14.04) broke it :S https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1503716 [14:57] Launchpad bug 1503716 in plymouth (Ubuntu) "Display corruption during boot process" [Undecided,New] [14:59] something as simple as this? https://github.com/pete-woods/python-dbusmock/commit/b511c1d98c09e054816544b7aa52be0dec4b615c [15:00] popey: ok [15:00] I think I have a fix for your bug from yesterday, I'm going to try it here now and upload [15:01] this new one will probably take more time, plymouth doesn't change much, and lots of issues are really graphical display driver problems [15:02] popey: do you know if it is optimus [15:02] no, pure Intel I believe [15:11] pete-woods: seems okay to me (just needs a test case) [15:13] pitti: cool (and also to work ;) ) [15:14] pete-woods: and please also a test case for ill-formatted params; I guess it should make clear somewhere that it needs to be a dictionary, etc. [15:14] pitti: yeah, will add tests as thorough as I can manage [15:14] might need some pointers where my python is lacking [15:15] pete-woods: well for a start you are not hissing enough [15:15]