| psusi | so I'm looking at a bug report that appears to be caused by an incorrect dependency in the ubuntu-mate-live package, only no such package appears to exist... how can this be? | 01:25 |
|---|---|---|
| ScottK | psusi: That's presumably the metapackage used for installing the live system from the installation ISO. It'd be controlled by the ubuntu-mate seeds. | 01:34 |
| psusi | ScottK, ahh... so why doesn't it show up in packages.ubuntu.com or apt-cache? | 01:45 |
| ScottK | Because it's only on the ISO, not in the archive. | 01:45 |
| psusi | so the package is actually built as part of the iso construction process, rather than being in the archive and just *installed* when building the iso? | 01:46 |
| psusi | seems like an odd thing to do... | 01:46 |
| BenC | Anyone around that handles @ubuntu.com mail forwarding? | 01:59 |
| BenC | infinity: Are you able to do that? | 02:00 |
| ScottK | BenC: AFAIK it's a launchpad thing. | 04:00 |
| infinity | BenC: ubuntu.com mail forwarding is determined by your launchpad status, in a few ways. What's the issue you're having? | 05:55 |
| mardy | mvo: hi! When you have some time, can you help me understand if bug 1393697 is still valid or if I'm doing something wrong? | 07:09 |
| ubottu | bug 1393697 in click (Ubuntu) "Cross qmake to the chroots" [High,Confirmed] https://launchpad.net/bugs/1393697 | 07:09 |
| === kickinz1|afk is now known as kickinz1 | ||
| infinity | didrocks: So, upstart split. I caught your messages on Friday, but wasn't sure what your concern was. | 07:37 |
| infinity | didrocks: FWIW, systemd's init-mangling binaries (reboot, etc) know how to talk to upstart. | 07:37 |
| infinity | didrocks: So, init=/path/to/upstart should work even with systemd-sysv installed. | 07:37 |
| infinity | mvo: Your apt testsuite fix didn't seem to fix the testsuite. | 07:38 |
| didrocks | infinity: oh really? I didn't know/look about this (I know that init=/sbin/upstart works, but didn't try init-mangling binaries). Ok then, no blocker thus, will work on this | 07:38 |
| infinity | didrocks: Kay. I'm here to help/review/advise/whatever. I want this in and tested to some degree before I freeze for Beta later today. | 07:38 |
| infinity | didrocks: I suspect (but haven't confirmed yet) that the broken split is also the reason why the first reboot after upgrade doesn't work. | 07:39 |
| infinity | didrocks: My guess is that upstart doesn't have enough upstart left to actually reboot itself. :P | 07:39 |
| didrocks | infinity: yeah, seems to match what we have seen with the autopkgtests | 07:39 |
| didrocks | infinity: finishing my morning backlog and then on this | 07:40 |
| infinity | didrocks: \o/ | 07:40 |
| infinity | didrocks: regarding the "systemd can talk to upstart" bit, the only caveat there that I know of is that "telinit u" intentionally refuses to talk to upstart because of an upstart bug pitti and I found a few weeks ago (upstart rexecs argv[0] instead of the upstart binary, which is HILARIOUS when /sbin/init becomes something else) | 07:41 |
| infinity | didrocks: But I think that's a wart we'll just have to live with if people want to install systemd-sysv+upstart and then run upstart as their base init. | 07:42 |
| mvo | infinity: I noticed it, hrm, hrm | 07:42 |
| mardy | mvo: Hi! I wrote you before, but then you client disconnected so I'm not sure if you've seen it: | 07:44 |
| mardy | mvo: hi! When you have some time, can you help me understand if bug 1393697 is still valid or if I'm doing something wrong? | 07:44 |
| ubottu | bug 1393697 in click (Ubuntu) "Cross qmake to the chroots" [High,Confirmed] https://launchpad.net/bugs/1393697 | 07:44 |
| didrocks | infinity: agreed (fun this eexec argv[0] when you are a symlink/alternative-like ;)) | 07:44 |
| mvo | mardy: aha, I have not seen this, thanks, let me check | 07:44 |
| infinity | mvo: If you tell me that test is basically just crap and inconsequential, I'm happy to let apt slip in. I'd like it in for the beta, so it gets wider testing/abuse. | 07:45 |
| infinity | mvo: Of course, fixing the testsuite would be better. | 07:45 |
| infinity | didrocks: I didn't bother hunting commit logs, but I assume (or hope) the reexec functionality was written before /sbin/init became a symlink. | 07:45 |
| infinity | didrocks: If not, then it's extra special, yes. :) | 07:45 |
| didrocks | heh, who knows… ;) | 07:46 |
| mvo | infinity: so the test is basicly "does it show download progress" (as we had a issue were no download progress was displayed for https). so the test needs to run long enough so that apt can generate data on that but not too long to not delay the test suite too much, looks like I need to tweak the value again :/ but yeah, its essentially a false positive as on other systems it works | 07:47 |
| infinity | mvo: Testsuites aren't mean to be fast, if you need to hitch up for 5 on 10 seconds to get good data, just do it. | 07:48 |
| infinity | s/5 on/5 or/ | 07:48 |
| mvo | infinity: I agree, its jsut that I also run it locally so I don't want it to be toooooo slow :) | 07:48 |
| mvo | infinity: but yeah, I will make it a bit slower and that should fix it | 07:49 |
| infinity | mvo: As a man who runs the glibc testuite regularly, I have something approaching zero sympathy. ;) | 07:49 |
| mvo | haha | 07:49 |
| infinity | Laney: Are you doing anything about the remmina component-mismatches? | 07:59 |
| infinity | Laney: Either an MIR for nxproxy/nxcomp or dropping the plugin deps from remmina-dbg or something. | 08:00 |
| seb128 | Laney is on vac this week | 08:15 |
| infinity | seb128: Oh. Any urge to look at his breakage? :P | 08:18 |
| seb128 | can't we just demote the -dbg? | 08:18 |
| infinity | seb128: We could do that too, yes. | 08:20 |
| seb128 | I would do that and let Laney do something else next week if he wants | 08:20 |
| infinity | seb128: I'll just commit that to the seeds. | 08:20 |
| seb128 | thanks | 08:20 |
| infinity | doko_: How close are gcc-4.9 in unstable and vivid? I'm trying to sort out some ppc64el glibc testsuite failures on Debian that don't show up in Ubuntu, and running out of people to blame. | 08:23 |
| didrocks | infinity: interestingly, there are some files shipped by both upstart and upstart-bin currently, package installation was saved by the Replaced version | 08:28 |
| infinity | seb128: Hrm, of course, that'll probably drop all the plugins too, so we might want to pick a few (or all but nx) to explicitly seed. | 08:29 |
| infinity | didrocks: Ew. | 08:29 |
| infinity | didrocks: Well, this should solve that screwup too, I hope. ;) | 08:30 |
| infinity | didrocks: I'd expect upstart-sysv to contain exactly the set of files that conflict with systemd-sysv, upstart-bin to be empty and depend on upstart, and the world to be a happier place. | 08:30 |
| infinity | didrocks: Oh, and whatever conflicts with sysvinit-core too, if that's a different intersection. | 08:30 |
| didrocks | infinity: yeah, it's what I'm doing. I'm still wondering about some man pages like inittab or control-alt-del | 08:31 |
| didrocks | should be in the upstart package, not upstart-sysv, but they are of no use if running under systemd | 08:31 |
| didrocks | and can puzzle some users… | 08:31 |
| infinity | didrocks: ./usr/share/man/man5/inittab.5.gz is in sysvinit-core, so that belongs in upstart-sysv. | 08:33 |
| infinity | didrocks: If control-alt-del is upstart-specific, use your best judgement? | 08:34 |
| dholbach | good morning | 08:34 |
| mlankhorst | hm where is the documentation about why static linking is bad? | 08:34 |
| infinity | didrocks: (sysvinit-core is only in Debian, so grab a copy of the unstable deb and list contents, should be helpful) | 08:34 |
| didrocks | infinity: ok, refilling coffee to try to optimize my judgement then :p | 08:34 |
| didrocks | infinity: thanks for the hint, doing this! | 08:34 |
| infinity | mlankhorst: In many people's heads. | 08:34 |
| mlankhorst | infinity: yeah but I need to get it in someone else's head | 08:35 |
| infinity | mlankhorst: And it's not as cut and dried as "static linking is bad", it's "static linking is bad if more than one component in the system can/will use the same library". | 08:35 |
| tjaalton | mlankhorst: the steam/mesa thread?-) | 08:47 |
| mlankhorst | yeah.. | 08:48 |
| === dholbach_ is now known as dholbach | ||
| LocutusOfBorg1 | good morning developers | 09:36 |
| rbasak | Can someone pull mysql-5.6 into main please? I presume no MIR needed as it supercedes mysql-5.5 that was already in main. | 09:36 |
| === doko_ is now known as doko | ||
| LocutusOfBorg1 | rbasak, I see it already in main | 09:38 |
| doko | infinity, debian has the state from December | 09:38 |
| LocutusOfBorg1 | https://launchpad.net/ubuntu/+source/mysql-5.6/5.6.23-1~exp1~ubuntu3 | 09:38 |
| LocutusOfBorg1 | the latest ubuntu3 is already in main :) | 09:39 |
| infinity | doko: Can ubuntu gcc binaries more or less install and run on unstable without breakage? That's probably my quickest path to seeing if that's the difference before I go bisecting. | 09:39 |
| rbasak | LocutusOfBorg1: oh, so it is, thanks. Looks like someone already acted on the email to ubuntu-release (I'd only just seen it) | 09:39 |
| zsombi | guys, a recent upgrade on vivid causes this https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1434547 | 09:43 |
| ubottu | Launchpad bug 1434547 in glibc (Ubuntu) "package libc6 2.21-0ubuntu1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 128" [High,Confirmed] | 09:43 |
| zsombi | the update-manager just hangs on libc6 upgrade | 09:43 |
| infinity | zsombi: Yes, I've seen the bug. I've not managed to reproduce it yet to figure out why it's happening for some people. | 09:44 |
| seb128 | you have somebody who gets the issue, that might help to get debug info? | 09:45 |
| zsombi | infinity: ok, maybe also it is worth to mention that my w510 with NVidia, latest driver simply kicks me back to teh login screen after I fixed the libc6 installation from terminal | 09:45 |
| zsombi | infinity: the same doesn't happen on VMWare Fusion, so perhaps this is related to the nvidia driver.. | 09:46 |
| infinity | doko: Also, dropping -m32 from gcc-4.9 breaks grub2. Can we please re-enable it for vivid? | 09:47 |
| infinity | doko: I'm not sure I see the motivation for dropping it if it breaks both the upstream kernel and grub. | 09:48 |
| infinity | doko: On ppc64el, that is. | 09:50 |
| doko | rbasak, I don't see it pulled in | 09:53 |
| infinity | zsombi: I'm the wrong person to complain to about nvidia drivers sucking. :) | 09:54 |
| zsombi | infinity: np, was just lamenting :D | 09:54 |
| doko | infinity, ok, re-enbling for vivid too :-/ | 09:54 |
| zsombi | infinity: btw it works wioth 3.19.0-7 kernel... | 09:54 |
| infinity | doko: Who was responsible for those upstream commits? amodra? | 09:54 |
| doko | him and msebor | 09:55 |
| infinity | doko: I might have a chat with him about it, since it broke both the upstream kernel defconfig (which is silly), and -m32 -mbig-endian, which I can't think was the intent. | 09:55 |
| doko | infinity, well, I thought cjwatson was using the powerpc cross compiler for that ... | 09:55 |
| infinity | doko: No, we switched from the cross to the native as soon as it was fixed to be able to build freestanding cross-endian binaries. | 09:56 |
| doko | gcc binaries, yes should be fine, but conflicts with the gcc man packages from non-free | 09:56 |
| doko | ahh | 09:56 |
| infinity | doko: And that seems like a rather useful feature, so disabling it makes little sense to me. | 09:56 |
| doko | anyway, I argued once upstream in the bug report, and it was closed as won't fix | 09:57 |
| infinity | doko: Noting also that, in the thread, amodra himself claims he's building his own compilers with -m32 turned on for debugging purposes, so... | 09:57 |
| infinity | doko: But yeah, I'll chat with him out of band about it. | 09:57 |
| infinity | doko: I don't disagree that being able to turn it off is a sane option, I just disagree with the default. | 09:57 |
| infinity | doko: Any chance you could get 4.9 uploaded ASAP, so the kernel team can get a kernel upload in before beta freeze? 4.8 and cross and such can trickle in later, less picky about those as long as we get -m32 before release. | 10:12 |
| Cimi | does anyone know why my /etc/pm/config.d/modules doesn't work anymore after systemd transition in vivid? | 10:13 |
| doko | infinity, currently preparing, yes | 10:16 |
| infinity | doko: \o/ | 10:17 |
| didrocks | infinity: ok, seems it works fine with my tests: transition without issue (thanks god, at least, no conffiles to migrate), systemd by default and starts upstart, upstart by default, upstart by default and starts systemd… | 10:37 |
| didrocks | infinity: did some additional fixes as well to always have the available entries available in grub + some transition not supported clenup | 10:37 |
| didrocks | cleanup* | 10:37 |
| didrocks | infinity: mind having a look? http://people.canonical.com/~didrocks/upstart_sysv/ | 10:37 |
| didrocks | will be that + the touch seed change to dep on upstart-sysv instead of upstart | 10:37 |
| ogra_ | didrocks, you coordinated that with QA ? | 10:38 |
| cjwatson | didrocks: /bin/sh scripts should use [ ... ] && [ ... ] rather than [ ... -a ... ] | 10:38 |
| didrocks | ogra_: didn't, only tried on my qemu | 10:38 |
| ogra_ | jibel, ^^^ | 10:38 |
| cjwatson | (TBH all scripts should, the -a/-o syntax rules are a nightmare) | 10:39 |
| cjwatson | also I think our usual is "which" rather than "type" for portability | 10:39 |
| didrocks | cjwatson: ok, I mirrored what we executes in systemd-sysv, happy to change though | 10:39 |
| infinity | didrocks: I'll have a look in an hour or so, avoiding a context switch. | 10:39 |
| didrocks | sure | 10:39 |
| cjwatson | it probably works in practice then and I'm just whining :) | 10:39 |
| infinity | didrocks: Conflicts in systemd will also need updating, and the dependencies of "init". | 10:39 |
| didrocks | infinity: see my 2 others patches in the same dir :) | 10:40 |
| infinity | didrocks: Shouldn't be much more than that, but a grep of Packages files wouldn't hurt. | 10:40 |
| infinity | didrocks: Ahh. :) | 10:40 |
| didrocks | cjwatson: no worry, better to get it right, as I'm doing a systemd upload at the same time, changing it as well | 10:40 |
| infinity | didrocks: I didn't load it yet. ;) | 10:40 |
| didrocks | :) | 10:40 |
| infinity | didrocks: Right, I'll get back to you in an hourish. But thanks in advance! | 10:41 |
| didrocks | infinity: no worry, just poke me once done (doing the samme update to address cjwatson's remarks) | 10:42 |
| didrocks | cjwatson: better now? http://people.canonical.com/~didrocks/upstart_sysv/upstart_sysvinit.debdiff (I'm updating systemd as well to that syntax) | 10:45 |
| kpcyrd_ | hello. I'm running ubuntu 14.04 and would like to report that httpie is currently broken | 11:02 |
| kpcyrd_ | it depends on python-requests, but it's incompatible to the latest version of python-requests | 11:02 |
| kpcyrd_ | requests.compat.is_windows and requests.compat.is_py26 have been removed, but are in use by httpie | 11:03 |
| kpcyrd_ | is this the right channel for this? | 11:05 |
| cjwatson | didrocks: yep, thanks | 11:06 |
| didrocks | thank you for the suggestion :) | 11:06 |
| mgedmin | kpcyrd_, I think the best thing to do is to report a bug (ubuntu-bug httpie) | 11:08 |
| tsdgeos | mysql 5.6 broken :/ | 11:08 |
| kpcyrd_ | mgedmin: I'm not that sure what's going on. is_windows and is_py26 still exist in reqeusts.compat, but I can't import them. Can somebody try to reproduce this? | 11:09 |
| kpcyrd_ | from requests.compat import is_windows | 11:10 |
| mgedmin | works fine in 14.10 | 11:10 |
| cjwatson | https://bugs.launchpad.net/ubuntu/+source/httpie/+bug/1213247 already exists | 11:12 |
| ubottu | Launchpad bug 1213247 in httpie (Ubuntu) "httpie requires requests < 1.0, raring ships with 1.1.0" [Undecided,Confirmed] | 11:12 |
| asac | cjwatson: infinity: cyphermox: anyone of you could help unblock our grub MP? https://code.launchpad.net/~jamesodhunt/snappy/bug-1412737/+merge/249976 | 11:12 |
| mgedmin | raring and saucy are out of support, aren't they? | 11:13 |
| mgedmin | is that the same bug? kpcyrd_? | 11:13 |
| kpcyrd_ | mgedmin: "reported on 2013-08-16" it was working on my box 1-2 weeks ago | 11:15 |
| kpcyrd_ | httpie and python-requests have been updated last week | 11:15 |
| mgedmin | a new bug report with steps to reproduce and the full error traceback would really be useful | 11:16 |
| kpcyrd_ | on the other hand, I've checked the source of compat.py and this should be working | 11:16 |
| cjwatson | asac: didn't realise that was blocked on me, I gave jodh a verbal ack ages ago ... | 11:16 |
| cjwatson | asac: I'll fill that in on the MP as well | 11:17 |
| kpcyrd_ | I'm not 100% sure this isn't just broken on my box | 11:17 |
| mgedmin | in that case pastebin the error please | 11:18 |
| asac | cjwatson: thanks! | 11:18 |
| kpcyrd_ | mgedmin: https://paste.debian.net/162701/ | 11:23 |
| mgedmin | kpcyrd_, can you tell me what you see if you do python -c 'import requests; print(requests.__file__)'? | 11:25 |
| kpcyrd_ | /usr/local/lib/python2.7/dist-packages/requests/__init__.pyc | 11:25 |
| mgedmin | kpcyrd_, /usr/local screams "user did a sudo pip install requests" to me; this can and will break things | 11:28 |
| kpcyrd_ | mgedmin: wups.. yeah, this could be the case. I installed something with pip on friday | 11:29 |
| kpcyrd_ | yeah, I think this is the reason. sorry and thanks for your help | 11:30 |
| doko | tjaalton the xauth MIR is still incomplete | 11:49 |
| tjaalton | doko: yes | 11:50 |
| tjaalton | i'll just drop the tests, too much effort | 11:51 |
| ejat | hi .. i got welcome to emergency mode after upgrade vivid | 11:53 |
| ejat | what should i do ? | 11:53 |
| infinity | didrocks: The systemd-sysv Conflicts might need to get a bit more messy. | 12:01 |
| infinity | didrocks: Some versioned conflicts on upstart/upstart-bin (<< split_fix) or similar. | 12:02 |
| mardy | mvo: did you have a chance to look into that qmake issue? | 12:02 |
| BenC | infinity: I feel like you responded, but my scrollback doesn’t show it… | 12:02 |
| infinity | BenC: What did I respond to? :) | 12:03 |
| infinity | BenC: Oh, ubuntu.com mail stuff. Yes, what's the issue you're having? | 12:03 |
| didrocks | infinity: hum, indeed, it needs to conflicts against upstart before the split (I don't think against upstart-bin, though?) | 12:04 |
| infinity | didrocks: Oh, not -bin, indeed. Just upstart before this current fix. | 12:04 |
| didrocks | agreed, doing | 12:04 |
| infinity | didrocks: Otherwise, systemd and i-s-h look fine, now slogging through the upstart diff. | 12:05 |
| didrocks | good luck! | 12:05 |
| BenC | infinity: I need it to point to my gmail instead of swissdisk | 12:05 |
| infinity | didrocks: What's with this lxcguest bit you dropped? | 12:08 |
| didrocks | infinity: did I drop it? /me looks | 12:09 |
| infinity | didrocks: No, I can't read. | 12:10 |
| didrocks | infinity: yeah, the diff isn't easy to read due to the new package | 12:10 |
| infinity | didrocks: Right, it was removal of upstart-compat-sysv from the conflict lines that broke my visual tracking. :P | 12:11 |
| infinity | didrocks: What was upstart-compat-sysv? Something short-lived in utopic? | 12:11 |
| didrocks | infinity: this was something pre-precise even | 12:12 |
| didrocks | the package doesn't exist anymore, hence the drop | 12:12 |
| infinity | Fair enough. | 12:12 |
| didrocks | (not in ubuntu nor debian) | 12:12 |
| didrocks | infinity: note that I'm sure we can clean up way more, I just did a few I found on the way | 12:12 |
| infinity | +Pre-Depends: upstart, | 12:13 |
| infinity | Trailing comma intentional? And also, was there a valid reason to make it a pre-dep instead of a dep? | 12:13 |
| infinity | On, in fact, it's both a pre-dep *and* a dep. :P | 12:14 |
| didrocks | infinity: I'm always using trailing coma to avoid future diff-noise (but I'm not that opinionated in a case like upstart, where all deps are one after another). For the predeps, there is a postinst calling update-grub | 12:15 |
| infinity | didrocks: Yeah, the pre-dep seems to match what systemd-sysv does too, but fair enough. | 12:15 |
| infinity | s/but/so/ | 12:16 |
| doko | that works now ... | 12:16 |
| doko | (gdb) compile code printf("Hello world\n"); | 12:16 |
| doko | Hello world | 12:16 |
| infinity | +sbin/telinit lib/sysvinit/ | 12:18 |
| infinity | That's just confusing, but matches what we have today. | 12:18 |
| didrocks | indeed, I kept the symlinks we have to not add confusion | 12:19 |
| infinity | didrocks: So, that all looks correct, as far as one can review something so large. | 12:19 |
| didrocks | infinity: good, I got requested to upload upstart to a silo to get a quick QA test (only upstart), then I start pushing that to -proposed | 12:20 |
| didrocks | first upstart | 12:20 |
| infinity | didrocks: Does the output of "dpkg -L upstart-sysv && dpkg -L upstart" match the old output of "dpkg -L upstart && dpkg -L upstart-bin"? | 12:20 |
| didrocks | then, once published, systemd (so that we don't get in the "debian" case with skipping autopkgtest for upstart boot) | 12:20 |
| infinity | didrocks: ie: did any files go missing? :) | 12:20 |
| ejat | didrocks: thanks | 12:20 |
| didrocks | infinity: yeah, I checked the numbers | 12:20 |
| didrocks | infinity: and run --list-missing | 12:20 |
| didrocks | ejat: yw! | 12:21 |
| infinity | didrocks: Excellent. Looks good to me, then. | 12:21 |
| ejat | didrocks: systemd boot faster \0/ | 12:21 |
| didrocks | infinity: let's hope we are not going to break the image build, fingers cross :) | 12:21 |
| ejat | btw .. any way to load vmhgfs on boot ? | 12:21 |
| infinity | didrocks: The silo tests may fail if they're not sure how to test. Though if they're just dist-upgrading and testing, that should work, thanks to the transitional upstart-bin. | 12:21 |
| didrocks | infinity: they need rather to apt-get install upstart-sysv on Touch | 12:21 |
| didrocks | (I detailed that) | 12:21 |
| infinity | Oh, right. And that. | 12:22 |
| infinity | So, if they know how to test, should all go fine. | 12:22 |
| didrocks | yeah, should be good, and then, I'll update their seed once all done | 12:22 |
| infinity | didrocks: I'm up all night (obviously), so give me a poke when it's all landing in proposed, and we can make sure the autopkgtest stuff is clearing up and life looks saner. | 12:22 |
| didrocks | infinity: will do, thanks for the review! | 12:22 |
| infinity | didrocks: No, no, thanks for doing the work. | 12:22 |
| didrocks | yw :) | 12:23 |
| didrocks | ejat: let me look in 5 minutes if there is any known bug about this | 12:23 |
| infinity | didrocks: Oh, and fix the systemd conflicts before you forget we had this conversation. :) | 12:23 |
| didrocks | infinity: done already :) | 12:23 |
| infinity | \o/ | 12:23 |
| ejat | didrocks: ok thanks a lot | 12:25 |
| didrocks | ogra_: around? Seems like I can't upload anymore to the silos… | 12:26 |
| cjwatson | didrocks: Depends are satisfied when the postinst runs; maintainer scripts are only a justification for Pre-Depends if it's the preinst | 12:26 |
| didrocks | sil2100: ? ^ | 12:26 |
| ogra_ | didrocks, which silos ? vivid ones should surely work for all core devs | 12:26 |
| ogra_ | (i would assume RTM too but am not sure) | 12:26 |
| didrocks | cjwatson: so, I don't see any reason to have the Pre-Depends in systemd-sysv then, I can clean up this one too | 12:27 |
| didrocks | ogra_: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012 | 12:27 |
| cjwatson | didrocks: (might be for some other reason, perhaps less risky to leave alone ...) | 12:27 |
| didrocks | cjwatson: yeah, let's handle in two steps maybe? Keeping it like that and I'll discuss this with pitti | 12:27 |
| infinity | didrocks: If it's working like this today, I'd leave it be. Pre-Depends make apt's resolver grumpy, but in a case like this that obviously has no loops, it should be fine. | 12:27 |
| didrocks | +1 | 12:27 |
| didrocks | ogra_: no core-dev in https://launchpad.net/~ci-train-ppa-service/+members#active? | 12:28 |
| infinity | s/grumpy/work harder/ | 12:28 |
| cjwatson | Doesn't necessarily have to be in members | 12:28 |
| cjwatson | You can use newComponentUploader on a PPA | 12:28 |
| ogra_ | didrocks, then i'll leave that to sil2100 | 12:28 |
| didrocks | ogra_: mind sponsoring otherwise? | 12:28 |
| cjwatson | And adding ubuntu-core-dev to ci-train-ppa-service which gets lots of mail spam might make people grumpy | 12:28 |
| infinity | Yeah, the FTBFS spam from silos is insane. | 12:28 |
| infinity | I lean on the delete key every morning. | 12:28 |
| cjwatson | oh, though ubuntu-core-dev has a team e-mail address set, so it might be passable, but still | 12:29 |
| didrocks | infinity: oh, you have rights to push there, mind doing it with the debdiff I gave you? (landing-012) | 12:29 |
| didrocks | let's not delay this on wrong permissions… | 12:29 |
| infinity | didrocks: Yeah, I'm pretty sure I have the powers to do that. | 12:30 |
| didrocks | you are in the list, so I guess you get the spam :) | 12:30 |
| infinity | didrocks: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012 ? | 12:30 |
| didrocks | infinity: correct | 12:30 |
| infinity | "You can upload packages to this PPA" sounds like LP saying I can do it. :P | 12:30 |
| infinity | I'll grab your diffs and send 'em up. | 12:30 |
| didrocks | thanks! | 12:31 |
| didrocks | infinity: well, only upstart | 12:31 |
| cjwatson | Perhaps an admin should do: for distro in ubuntu ubuntu-rtm; do for silo in $(seq -w 1 30); do edit-acl -A ppa:ci-train-ppa-service/$distro/landing-0$silo -p ubuntu-core-dev -t upload add; done; done | 12:31 |
| sil2100 | didrocks: huh? | 12:31 |
| didrocks | sil2100: can't upload to the silos | 12:31 |
| cjwatson | though it's another thing that has to be configured per-silo | 12:31 |
| sil2100 | wth | 12:31 |
| mvo | mardy: I reproduced it, does it help if you run "qt5-qmake-arm-linux-gnueabihf" in your build dir instead of qmake? or | 12:31 |
| infinity | didrocks: Just upstart? Kay. | 12:31 |
| didrocks | infinity: yeah, I plan to do manual uploads anyway (as I want the systemd autopkgtest to use the new upstart), so just for the QA team to test the upstart part which should be enough for me | 12:32 |
| sil2100 | didrocks: not sure why, but indeed the team doesn't have core-devs included in it, just single people | 12:32 |
| cjwatson | Anyone in ~ci-train-ppa-service could do the above, in fact | 12:32 |
| cjwatson | sil2100: ^- see what I said above | 12:33 |
| infinity | Dear patch, thanks for making all those 0-length files instead of deleting them. | 12:33 |
| infinity | Oh, because that's what the diff said. | 12:33 |
| infinity | Weird. | 12:33 |
| didrocks | hum? they are removed here | 12:33 |
| cjwatson | On the whole this would be better for people, although it would be convenient if I could remain a direct member so that I can admin your silos using launchpad-ppa-self-admins capability :) | 12:34 |
| didrocks | $ LANG=C ls debian/upstart-bin* | 12:34 |
| cjwatson | (same might go for infinity) | 12:34 |
| didrocks | ls: cannot access debian/upstart-bin*: No such file or directory | 12:34 |
| infinity | didrocks: Yeah, just a minor diff/patch bug, removing files is "hard". | 12:34 |
| sil2100 | I wonder why didrocks is not in ci-train-ppa-service in the first place | 12:34 |
| didrocks | sil2100: conspiracy obviously ;) | 12:34 |
| sil2100 | :| | 12:34 |
| sil2100 | ;) | 12:35 |
| sil2100 | eh | 12:35 |
| cjwatson | incidentally, implication of the above command line is that ppa:foo/bar/baz now works as a synonymous archive reference for ~foo/bar/baz in the LP API, as discussed here a week or two ago | 12:35 |
| didrocks | ejat: couldn't find any reference downstream or upstream (apart from an archlinux forum stating the same), mind opening a launchpad bug, and ideally, forwarding it upstream? | 12:37 |
| mvo | mardy: hm, nevermind, what is the project I can reproduce this with easiest? I'm not sure if this a chroot issues or something with the wrapper | 12:37 |
| infinity | didrocks: Uploaded. | 12:38 |
| didrocks | infinity: thanks! let's see how it goes :) | 12:38 |
| === _salem is now known as salem_ | ||
| mardy | mvo: anyone, really, but you can use this one: https://github.com/mardy/ttrss | 12:38 |
| === salem_ is now known as _salem | ||
| ejat | what title should i put ? please advise .. | 12:38 |
| ejat | under systemd ? | 12:39 |
| didrocks | ejat: yeah, under systemd, mention "vmhgfs" (vmware) fs type (and paste your fstab) | 12:39 |
| mardy | mvo: is qt5-qmake-arm-linux-gnueabihf something that gets installed in the chroot regardless of the framework version? My chroot is for 14.10 (I want to target the BQ devices first) | 12:40 |
| === kickinz1 is now known as kickinz1|afk | ||
| mvo | mardy: it gets installed on 15.04, I need to check on 14.10 - does it help if you manually install it? | 12:46 |
| === kickinz1|afk is now known as kickinz1 | ||
| mardy | mvo: I've tried to patch click and add that package to click/chroot.py, but when I create the chroot, it says that that package is not found | 12:48 |
| mardy | mvo: and searching in packages.ubuntu.com tells me that that package exists only in vivid | 12:48 |
| mvo | mardy: aha, then its probably best to discuss with bzoltan, I think he mentioned that this is in the sdk ppa(?) | 12:49 |
| mardy | mvo: OK; although, I'm using that ppa. But let's see... | 12:50 |
| infinity | doko: Okay, using Ubuntu GCC and binutils on unstable gets me the same failures, so you're off the hook, but now I'm even more confused. ;) | 12:52 |
| * infinity shelves that for now. | 12:53 | |
| === rickspencer3_ is now known as rickspencer3 | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| infinity | doko: That gcc-4.9 fixed both the kernel and grub, thanks. | 14:32 |
| Dvine | devils | 15:07 |
| sitter | didrocks, ogra_: hey, any news on bluez5? | 15:15 |
| * ogra_ isnt working on it | 15:15 | |
| didrocks | sitter: no, as told last time, it's on the phonefundation's team radar for touch support but I feel now that it has low chances to be ready in time… | 15:16 |
| didrocks | sitter: you can sync up with ricmm once he's around, he's working on it | 15:16 |
| didrocks | or ChickenCutlass maybe? ^ | 15:16 |
| ogra_ | ricmm is on vacation | 15:17 |
| roaksoax | doko: howdy! so we tested pythoon-django16. Seems to be working fine. We are gonna be looking into apparently unrelated issues, and move forward with it | 15:17 |
| ChickenCutlass | didrocks its on our list for this sprint | 15:17 |
| roaksoax | doko: do you need me to upload it, or will you one we are comfortable with it? | 15:17 |
| sitter | Riddell: ^ what do we do about bluetooth? | 15:17 |
| doko | roaksoax, no, please upload and git rid off my name in the changelog ;) | 15:18 |
| didrocks | ChickenCutlass: do you think it will land in vivid? (we are after beta now), I guess the kubuntu team is quite stuck (more than us on unity desktop, as we keep our ppa ready, but not blocked on it) | 15:18 |
| roaksoax | doko: haha ok | 15:18 |
| ChickenCutlass | didrocks not sure yet. will let you know soon | 15:18 |
| roaksoax | doko: so how do I go about getting it in Main? File an MIR? | 15:18 |
| didrocks | ChickenCutlass: sure! do you mind keeping sitter and Riddell in the loop as well for the kubuntu side? | 15:19 |
| ChickenCutlass | of course | 15:19 |
| didrocks | thanks :) | 15:19 |
| sitter | lovely thanks | 15:19 |
| doko | roaksoax, not needed, just another version which already was in main | 15:19 |
| roaksoax | doko: ok, cool | 15:20 |
| teward | hey i have a question, is there a reason we're all still on gnupg 1.x and not gnupg 2.x in the releases by default? | 15:25 |
| roaksoax | doko: done! uploaded | 15:41 |
| doko | roaksoax, accepted | 15:42 |
| doko | jamespage, are there standing FFes for the python-oslo.policy and python-semantic-version packages? | 15:43 |
| infinity | teward: Because we've not chosen to diverge from Debian, and their plan was to move post-jessie, I believe. | 15:43 |
| roaksoax | darkbasic: awesome! thanks! | 15:44 |
| roaksoax | err | 15:44 |
| roaksoax | doko: awesome! thanks! :) | 15:44 |
| jamespage | doko, yes - this bug: | 15:50 |
| jamespage | https://bugs.launchpad.net/ubuntu/+bug/1434526 | 15:50 |
| ubottu | Launchpad bug 1434526 in Ubuntu "[FFe] new packages to support OpenStack Kilo-3 milestone" [High,Triaged] | 15:50 |
| doko | jamespage, can python-semantic-version be synced? | 15:51 |
| jamespage | it has been | 15:52 |
| doko | so oslo not yet in debian | 15:53 |
| doko | tjaalton, please could you fix xauth today or tomorrow? | 15:53 |
| jamespage | doko, no - the oslo packages won't be in debian anytime soon | 15:54 |
| jamespage | doko, they are linked directly to the openstack release being packaged - we're on kilo, debian only has juno in experimental and icehouse in unstable/testing | 15:55 |
| jamespage | doko, hence the direct uploads to ubuntu for oslo.policy and oslo.log | 15:55 |
| jamespage | doko, semantic-version has been synced - its in the NEW queue as well | 15:55 |
| jamespage | doko, broadley the oslo-* packages fall under the general exception we have for openstack projects for feature freeze - upstream will bump and align as we move towards release -will settle down once we have kilo-3 in archive (hopefully this week) | 15:56 |
| doko | yes, but somebody has to review the sources first | 16:00 |
| tjaalton | doko: yep | 16:01 |
| jamespage | doko, yup | 16:03 |
| teward | infinity: OK - it caused problems with my enigmail plugin (which will no longer support anything earlier than gpg2 starting next update) in Thunderbird, hence my asking | 16:15 |
| teward | infinity: thankfully gpg2 is in the trusty repos so i'm relatively OK. thanks for the answer :) | 16:15 |
| infinity | teward: Really? That's a bold move on the part of enigmail upstream. | 16:15 |
| teward | infinity: let me see if i can get it to tell me the error again, and i'll screenshot | 16:16 |
| teward | infinity: ahh, okay, 1.9 is their transition - https://www.enigmail.net/support/transition_to_gnupg2.php | 16:17 |
| teward | but since enigmail 1.6 they've suggested gpg2 | 16:18 |
| teward | gpg 2.x * | 16:18 |
| teward | infinity: so it looks like enigmail 1.9 will cease support for gnupg < 2.0 | 16:20 |
| infinity | teward: Fun. | 16:20 |
| infinity | teward: Oh well, we have gnupg2 all the way back to lucid, so it should generally not be a big deal. | 16:21 |
| teward | infinity: except that it's not default installed, hence my concern users will be like "HOW DO I DO DIS" (sorry i have a low view of end users today after the flood I got in my email about a PPA this morning >.<) | 16:22 |
| teward | infinity: granted that's an issue for the next cycle but meh | 16:22 |
| infinity | teward: I hope that more users are using the enigmail package, which should just switch the dep when 1.9 ships. | 16:23 |
| infinity | s/more/most/ | 16:23 |
| teward | mmm | 16:24 |
| teward | infinity: we can only hope | 16:24 |
| teward | won't help us back on trusty, it's only 1.7 in there | 16:24 |
| infinity | teward: To be fair, the intersection of "people who install enigmail to GPG sign mail" and "people who know how to install packages" should be pretty high. | 16:24 |
| teward | mhm | 16:24 |
| infinity | teward: It's updated to match thunderbird updates. | 16:25 |
| teward | infinity: *is it*? | 16:25 |
| infinity | teward: So, when we update the enigmail package to 1.9, the dep switches, life goes on. | 16:25 |
| teward | ah | 16:25 |
| === _salem is now known as salem_ | ||
| rbasak | Is there a standard way to mention a bug in debian/changelog without causing it to auto-close? | 16:42 |
| rbasak | Do I just hack the changes file? | 16:42 |
| seb128 | rbasak, just use an invalid syntax to mention it? | 16:42 |
| infinity | mvo: It seems you really can't win with that test. | 16:43 |
| seb128 | like "bug #..." | 16:43 |
| seb128 | rather than "lp..." | 16:43 |
| seb128 | rbasak, or use the bug url | 16:43 |
| infinity | rbasak: I tend to use "LP: 123456" (ie: omit the #) | 16:43 |
| ubottu | Launchpad bug 123456 in xine-lib (Ubuntu) "podcast crashes amarok" [Undecided,Fix released] https://launchpad.net/bugs/123456 | 16:43 |
| infinity | rbasak: But anything that's invalid syntax works. | 16:43 |
| infinity | ubottu: Shut up. | 16:43 |
| infinity | rbasak: Just check your .changes to make sure it doesn't have the closure line in it. | 16:44 |
| Unit193 | ubottu: shaddap | 16:44 |
| ubottu | :X | 16:44 |
| * ogra_ usually writes "launchpad bug: #12345" | 16:44 | |
| ubottu | Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345 | 16:44 |
| rbasak | seb128, infinity, ogra_: OK, thanks. Seems a bit horrible, but I'll do it :() | 16:44 |
| cjwatson | I usually say "LP #nnnnnn" | 16:44 |
| rbasak | :) | 16:44 |
| rbasak | Hmm. Now I have to pick! :) | 16:44 |
| infinity | rbasak: Colin's a traitor, his opinion doesn't count anymore. | 16:45 |
| seb128 | rbasak, or get it to autoclose and reopen manually | 16:45 |
| seb128 | if you prefer | 16:45 |
| cjwatson | Ha | 16:45 |
| cjwatson | The regex is in /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm if you need to check against it | 16:45 |
| cjwatson | The reason I don't use LP: nnnnnn is that that pattern doesn't work in Debian with closes:; its syntax is a bit more permissive | 16:46 |
| infinity | mvo: I think I'm just going to let your apt in, despite the failure, but pretty please figure out how to fix that some day. :P | 16:46 |
| cjwatson | (the # is optional for closes:) | 16:47 |
| infinity | cjwatson: For Debian, I use s/closes/addresses/ (or whatever) for referencing-but-not-closing. | 16:47 |
| cjwatson | Yeah, that works too | 16:47 |
| infinity | I do want a reopens: or reverts: or something, though. | 16:48 |
| alex-k | 17:07 | |
| didrocks | infinity: hum, seems that the upstart autopkgtests failed | 17:10 |
| didrocks | infinity: the weird part is that the failure is passing during the test build, so I would feel it's something in the testbed environment not correctly setup by the autopkgtest itself | 17:11 |
| didrocks | not ok 54 - with single line command writing lots of data fast and exiting | 17:11 |
| infinity | didrocks: That's a nondeterministic test, I retried already. | 17:11 |
| didrocks | infinity: ah ok, "known one", good :) | 17:12 |
| dobey | init: invalid option: --user | 17:12 |
| dobey | hrmm :-/ | 17:12 |
| infinity | didrocks: And, indeed, build 98 passed. | 17:12 |
| didrocks | infinity: I'm waiting for upstart to be on the release pocket to rebuild ubuntu-touch-meta, then, I think we'll be good (of course, we'll need to transition rdepends on upstart-bin to upstart, but that can wait) | 17:12 |
| infinity | didrocks: Yeah, transitioned rdeps don't *need* to happen before vivid releases, but it would be nice. | 17:13 |
| infinity | didrocks: Also, upstart-bin should be seeded in supported so it doesn't fall out to universe before release. | 17:13 |
| infinity | didrocks: I'll do that now. | 17:13 |
| didrocks | infinity: if I have a window after beta freeze, I'll handle this, one thing less on the list | 17:13 |
| didrocks | infinity: indeed | 17:13 |
| didrocks | thanks | 17:13 |
| infinity | didrocks: Done, and upstart should migrate on the next britney pass. | 17:19 |
| infinity | didrocks: You might need init-system-helpers migrated too before you rebuild touch-meta, depending on how germinate decides to resolve everything. | 17:20 |
| * infinity gives it a pass, none of the failures looks related. | 17:20 | |
| didrocks | infinity: ok, waiting for the next britney pass + publisher run | 17:22 |
| infinity | didrocks: Just double-check the diff after you run the update script to make sure it didn't do something Very Stupid. :) | 17:23 |
| didrocks | infinity: sure, if the diff doesn't make sense, I'll directly pester you I guess :) | 17:24 |
| infinity | didrocks: Heh. | 17:24 |
| infinity | Bleh, the systemd autopkgtest seems very, very unhappy. | 17:24 |
| didrocks | hum, connecting to the internal one | 17:26 |
| didrocks | infinity: something went wrong with the test bed? seems like amd64 was more cooperative | 17:28 |
| infinity | didrocks: Maybe. I'll give it a kick. | 17:29 |
| * infinity is annoyed that we can't retry a single arch. | 17:29 | |
| flexiondotorg | When will the repos get frozen for the next beta? | 17:29 |
| * dobey is annoyed that vivid proposed apparently breaks "init --user" :-/ | 17:30 | |
| infinity | flexiondotorg: I sent an email that mentioned that not too long ago. :P | 17:30 |
| infinity | dobey: It does? | 17:30 |
| dobey | infinity: seems to. i'm using adt-run to run some autopkgtests, with a setup command which starts a user session with "init --user" and if i enabled the proposed pocket, it fails with "init: invalid option: --user" | 17:31 |
| didrocks | infinity: at least, they (amd64 and i386) both run with the same version of upstart, so not that | 17:31 |
| infinity | dobey: By "init", are you expecting "upstart"? | 17:32 |
| didrocks | dobey: well, init is systemd | 17:32 |
| didrocks | you should change it by the upstart path | 17:32 |
| infinity | dobey: And, if so, did your test depend on "upstart" to make that happen? | 17:32 |
| ginggs | hi, anyone from ubuntu-archive able to look at LP: #1432552 and LP: #1432576 please? | 17:33 |
| ubottu | Launchpad bug 1432552 in ants (Ubuntu) "Please remove armhf, powerpc and ppc64el binaries" [Undecided,Incomplete] https://launchpad.net/bugs/1432552 | 17:33 |
| ubottu | Launchpad bug 1432576 in kissplice (Ubuntu) "Please remove 32-bit (armhf, i386 and powerpc) binaries" [Undecided,New] https://launchpad.net/bugs/1432576 | 17:33 |
| infinity | dobey: Anyhow, two solutions to that. Either depend on upstart-sysv, or stop thinking "init --user" is a thing and call upstart directly for user sessions. | 17:33 |
| didrocks | infinity: yeah, we may have broke some of those tests :) | 17:33 |
| didrocks | broken* | 17:33 |
| dobey | infinity: it's not my test that depend son "init --user" | 17:33 |
| dobey | infinity: it's the "ubuntu-touch-session" script that is part of autopkgtest | 17:33 |
| dobey | hmm | 17:34 |
| infinity | dobey: Okay, that wasn't helpful debugging. How is "ubuntu-touch-session" expecting "init" to be upstart? That's what needs fixing. | 17:34 |
| dobey | infinity: i'm not sure. but if the packages were rearranged in vivid now, how can i make it work correctly for both vivid and utopic? | 17:36 |
| infinity | ginggs: No one really answered doko's question on that first bug. "The Debian maintainer arbitrarily restricted the arches" isn't the right answer. | 17:36 |
| didrocks | dobey: infinity: let me do a quick upload of ubuntu-touch-session to not break autopkgtests | 17:37 |
| didrocks | it already work on phone anyway as we install init, but let's ensure the script is using the upstart path | 17:37 |
| didrocks | and that will be compatible with utopic, if this needs backporting | 17:37 |
| dobey | didrocks: ubuntu-touch-session is a script in autopkgtest, not a separate package | 17:38 |
| dobey | at least, the one i'm referring to, is | 17:38 |
| didrocks | dobey: I'm talking about the ubuntu-touch-session script in ubuntu-touch-session package | 17:38 |
| doko | infinity, ginggs: well, they probably need some love | 17:38 |
| flexiondotorg | infinity, Heck. Tonight. Could you spin a new ubuntu-mate-meta package? There are a few minors changes that fix bugs. The seeds are up to date. | 17:38 |
| doko | infinity, and more disk space on the buildds ;-P | 17:38 |
| dobey | didrocks: yeah, that's something completely different | 17:38 |
| infinity | doko: Yeah, the disk space issue will be addressed this week. | 17:39 |
| didrocks | dobey: ok, not sure which one you are talking about then | 17:39 |
| dobey | didrocks: one second, i'll link you | 17:39 |
| infinity | dobey: So, how is upstart becoming the default init in your case? Are your tests depending on it, or is ubuntu-touch-session mangling things to make it so? | 17:40 |
| dobey | didrocks: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/autopkgtest/vivid/view/head:/setup-commands/ubuntu-touch-session | 17:40 |
| ginggs | doko, infinity: yeah and 4.4.2-1 fail on everything except i386 and amd64 ( https://buildd.debian.org/status/logs.php?pkg=insighttoolkit4&ver=4.4.2-1&suite=sid ) | 17:40 |
| didrocks | dobey: ok, let's fix it (and yeah, it will be backward compatible) | 17:40 |
| didrocks | not touching the -session one yet, only running on touch and no time for the additional QA tonight | 17:41 |
| cjwatson | infinity: I wonder how much of the disk issues are just ddebs. | 17:41 |
| infinity | ginggs: Why are logs from a year and a half ago interesting or relevant? | 17:42 |
| doko | could be. these is swig generated code | 17:42 |
| infinity | cjwatson: Not much. | 17:44 |
| infinity | cjwatson: For the two cases I know of, anyway, the build trees are just enormous. | 17:44 |
| infinity | cjwatson: generating ddebs doesn't help, but we can't be saved from that. | 17:44 |
| infinity | flexiondotorg: Lemme give it a kick. | 17:45 |
| flexiondotorg | infinity, Many thanks. | 17:45 |
| cjwatson | infinity: Hm, OK, I thought I'd looked and found a gigabyte plus of ddebs from the last few days due to things like Thunderbird uploads. | 17:45 |
| cjwatson | infinity: But maybe that isn't enough to matter. | 17:45 |
| infinity | cjwatson: When we're talking about a 50G root filesystem not being enough because a build needs 60G, yeah, a gig of ddebs doesn't matter. | 17:46 |
| * cjwatson nods | 17:46 | |
| infinity | cjwatson: Getting ddebs out of public_html will make the rootfs available space more deterministic, though, which is nice. | 17:46 |
| cjwatson | Right, that was my thought. | 17:47 |
| infinity | cjwatson: Like, the kernel is borderline, and cleaning the filesystem before build makes it juuuust fit. | 17:47 |
| infinity | cjwatson: Do you know if the scalingstack disk images are squishy sparse images of some sort or other? | 17:48 |
| infinity | cjwatson: Pondering how big we can get away with making them while making (perhaps faulty) assumptions that N giant builds won't happen at once on a compute node, where N is enough to ENOSPC the host. | 17:49 |
| didrocks | infinity: was I right that you did override the lcxfs and ofonophonesim autopkgtests for init-system-helpers? | 17:50 |
| didrocks | infinity: also, the lxc tests seem stuck (blocking as well init-system-helpers) | 17:52 |
| infinity | didrocks: init-system-helpers should migrate, I think I just missed the window for the last run. | 17:52 |
| cjwatson | infinity: I'm not totally certain, that's probably a pjdc kind of question. They're built by modifying the stock cloud images. | 17:53 |
| infinity | didrocks: And yeah, I'm aware of the lxc tests being wedged, but not entirely sure why. | 17:53 |
| didrocks | I guess that's why the adt queue is growing… | 17:53 |
| infinity | cjwatson: After asking the question, I realized it was a stupid question, of course the images are sparse, or they'd be massive. | 17:53 |
| ogra_ | "disk space is cheap" | 17:54 |
| ogra_ | :P | 17:54 |
| infinity | cjwatson: But still worth seeing if disk overscommit is plausible, if openstack has a good unwind strategy or if it would just wedge the world. | 17:54 |
| infinity | ogra_: It is, except when it's not. But yes, more disk is the better option. | 17:54 |
| ogra_ | :) | 17:54 |
| infinity | stgraber: Do you know what's up with the lxc and lxcfs autopkgtest failures? | 17:55 |
| infinity | flexiondotorg: ubuntu-mate-meta claims no changes found since the Mar 17 upload. | 17:56 |
| infinity | flexiondotorg: Are there pending commits to the seeds that haven't happened, or were you mistaken about it needing an update? | 17:56 |
| dobey | didrocks: so can you explain to me the solution for this init --user change (and why it broke)? | 17:56 |
| infinity | dobey: Fundamentally, assuming "init" is upstart on anything but a touch system is wrong. | 17:57 |
| infinity | dobey: And assuming that on touch is still not future proof. | 17:57 |
| stgraber | infinity: not really | 17:57 |
| stgraber | infinity: hallyn's looking into some of the lxc problems though. Short answer for both is systemd | 17:58 |
| infinity | stgraber: I figured you'd have a better chance at a guess than I would. :P | 17:58 |
| didrocks | dobey: I guess you test depends on upstart instead of upstart-sysv. Now init is in upstart-sysv and not upstart anymore. so "init" corresponds to systemd | 17:58 |
| dobey | infinity: ok, but why did it break exactly? the upstart packaging was rearranged, and so whatever provided that, is not being installed any longer? | 17:58 |
| didrocks | dobey: the change is just to replace init with upstart | 17:58 |
| stgraber | messed up cgroup config appear to break part of lxc and that may also affect lxcfs | 17:58 |
| flexiondotorg | infinity, Push a seed update 1 hour ago - http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid/revision/99 | 17:59 |
| dobey | didrocks: so just run "upstart --quiet --user" instead? and just require the "upstart" package to be installed? | 17:59 |
| infinity | dobey: The packaging was shuffled, yes. So if a test depends on "upstart" to make init==upstart, it should be depending on upstart-sysv. But if the test only needs upstart user sessions, not upstart as system init, it makes more sense to call "upstart --user". | 17:59 |
| didrocks | dobey: yeah, sounds like what your test want, so that will be the new relationship | 17:59 |
| dobey | ok, i'll tweak the script as installed and see if that works, real "quick" | 18:00 |
| didrocks | I guess apart from systemd and upstart tests, all other autopkgtests only cares about upstart as user session daemon | 18:00 |
| infinity | flexiondotorg: Ahh, that won't work until ubiquity-slideshow-ubuntu migrates to the release pocket. | 18:00 |
| didrocks | dobey: I'm building the autopkgtest locally before pushing (running the tests) | 18:00 |
| flexiondotorg | infinity, Ah, OK. | 18:00 |
| didrocks | infinity: shouldn't the override been taken into account now? (still not considered after 2 update_excuses generation) | 18:01 |
| dobey | didrocks: i don't know if the tests for the package do something that runs that script or not; i suspect not | 18:01 |
| infinity | didrocks: Hrm. Can I not spell? This is possible. | 18:02 |
| didrocks | autopkgtest builds fine with tests passing here, pushing | 18:02 |
| didrocks | infinity: dobey: ^ | 18:02 |
| dobey | didrocks: and i think it's probably better to ping pitti and get this fixed directly upstream, rather than just uploading a "fix" to the package | 18:02 |
| didrocks | dobey: yeah, working less though when pitti is on holidays | 18:03 |
| didrocks | dobey: but don't worry, he even has a git-format-patch waiting for him | 18:03 |
| dobey | ok | 18:03 |
| didrocks | (for this and a lot of other things) | 18:03 |
| infinity | flexiondotorg: Is that the only change you're waiting on? | 18:03 |
| infinity | flexiondotorg: (for your meta, I mean) | 18:03 |
| flexiondotorg | infinity, Yes, because I didn't realise someone had been good enough to update it on the 17th 😃 | 18:04 |
| infinity | didrocks: Oh, bah. It's the britney bug where it processes hints in order, and later ones win even if the versions are lower. | 18:05 |
| * infinity kills vorlon's hint. | 18:05 | |
| ogra_ | thats using the wrong namespace anyway :P | 18:06 |
| infinity | flexiondotorg: Alright, I'll kick it again once your slideshow exists. | 18:06 |
| didrocks | infinity: oh, indeed, easily trapped :p | 18:06 |
| flexiondotorg | infinity, Thank you very much. It may seem like a small thing, just that package. But... | 18:06 |
| flexiondotorg | infinity, Ubuntu MATE has been approached by an OEM. They want to test the next beta :) | 18:07 |
| infinity | flexiondotorg: No small thing, Ubuntu's always been about polish. Glad to see flavours living up to that. | 18:07 |
| ginggs | infinity: just wanted to show they haven't built in debian for a long time and we are about to release an old version because of this. | 18:09 |
| infinity | ginggs: Except that's not the version in Ubuntu, and ours fixed that bug. | 18:09 |
| ginggs | doko: i've only just seen your debian bug #780659 now | 18:10 |
| ubottu | Debian bug 780659 in src:insighttoolkit4 "insighttoolkit only built on amd64 and i386" [Normal,Open] http://bugs.debian.org/780659 | 18:10 |
| === kickinz1 is now known as kickinz1|afk | ||
| hallyn | stgraber: systemd is thwarting me: | 18:13 |
| hallyn | ubuntu@lxcv1:~$ sudo systemctl stop cgmanager | 18:13 |
| hallyn | Failed to get D-Bus connection: Operation not permitted | 18:13 |
| hallyn | ? | 18:14 |
| infinity | ginggs: The kissplice arch restriction looks just as suspect. Not sure why people don't fix bugs instead of papering over them. | 18:17 |
| infinity | ginggs: 10 to 1 odds say that fixing compiler warnings like "kissReads.c:359:19: warning: assignment makes pointer from integer without a cast" would magically make it work on 32-bit arches. | 18:17 |
| dobey | didrocks: oh, seems to work here for my tests too, btw | 18:18 |
| ginggs | infinity: ok, thanks for looking into those bugs. it is obviously better to try to get the builds to work on all arches | 18:20 |
| infinity | ginggs: Well, it's not always obviously better, but when the reason a build doesn't work is "upstream sucks at C", that's the maintainer's job to fix, not handwave and work around. :P | 18:21 |
| didrocks | dobey: phew, thanks for confirming | 18:24 |
| === Snow-Man_ is now known as Snow-Man | ||
| dobey | didrocks: now if i could just get autopilot to do the right thing with my actual tests :) | 18:25 |
| didrocks | dobey: ahah, that's another story! :) | 18:26 |
| infinity | didrocks: Hrm, I'm going to have to force systemd in without waiting on its tests, I guess. | 18:26 |
| infinity | didrocks: Cause the old systemd Conflict: upstart, and that's going to start horribly breaking computers shortly. | 18:27 |
| didrocks | infinity: yeah, they passed on amd64 anyway, and I wrote some of the failing tests, I can ensure there is nothing related to usptart in them | 18:27 |
| infinity | If people upgrade blindly. | 18:27 |
| dobey | infinity: true. unfortunately, sometimes the package maintainers suck at C and think they know better than they do, too. ran into that the last time i tried to use handbrake. had to fix the "security fix" patches that were actually causing crashes, remove some other patches, and rebuild, to get it remotely usable :-/ | 18:27 |
| didrocks | infinity: yeah, better to force | 18:27 |
| didrocks | infinity: proposed-migration didn't run for almost 15 minutes btw, I wonder if vorlon's override had some magic to not make it crash :p | 18:28 |
| infinity | didrocks: Or you're just impatient. ;) | 18:28 |
| didrocks | infinity: maybe because I'm waiting for the publisher cycle to rebuild ubuntu-touch-meta and call it a day, indeed :) | 18:28 |
| infinity | dobey: Turns out people in general suck, this is the joy of open source, we get to tell people they suck via submitting patches smugly! | 18:29 |
| infinity | didrocks: A watched ftpmaster never publishes. | 18:29 |
| dobey | infinity: that's why i'm a practicing misanthrope. | 18:29 |
| infinity | didrocks: Ooo, I think my systemd hint got in just under the wire. | 18:30 |
| infinity | timestamp: Mon 2015-03-23 12:28:25 -0600 | 18:31 |
| infinity | I: [Mon Mar 23 18:29:16 2015] - Loading hints list from data/vivid-proposed/Hints/adconrad | 18:31 |
| infinity | Here's hoping those clocks are aligned. | 18:31 |
| didrocks | infinity: ahah, let's cross fingers :) | 18:32 |
| infinity | final: byobu,init-system-helpers,psensor,systemd | 18:35 |
| infinity | \o/ | 18:35 |
| didrocks | sweet! | 18:39 |
| infinity | flexiondotorg: And, of course, after waiting for it to publish, I actually looked at the seeds you changed... | 18:47 |
| infinity | flexiondotorg: ship/ship-live don't affect metapackages, they just affect how CDs are built. | 18:47 |
| infinity | flexiondotorg: So, no upload needed, this will magically work on the next image build. | 18:47 |
| infinity | flexiondotorg: Err, except that it won't work. | 18:52 |
| infinity | flexiondotorg: oem-config only ever installs the ubuntu slideshow (you might note that no other flavour has an oem-config-slideshow) | 18:52 |
| infinity | flexiondotorg: You might want to revert those seed changed for now, and we can sort out what to do about it a bit later. | 18:55 |
| infinity | flexiondotorg: Cause, for now, you'll end up with the mate slideshow on the ISO, but ubiquity/oem-config will try to install the non-mate version, and the world will end in tears. | 18:56 |
| === salem_ is now known as _salem | ||
| kirkland | infinity: thanks | 19:02 |
| hallyn | stgraber: so seriously, i'm missing something about systemctl usage. as root i do 'systemctl list-units' and get "permission denied" | 19:04 |
| hallyn | have yo useen that happen? | 19:04 |
| hallyn | well, | 19:04 |
| hallyn | root@lxcv1:~# systemctl list-units | 19:04 |
| hallyn | Failed to get D-Bus connection: Operation not permitted | 19:04 |
| infinity | flexiondotorg: I reverted that seed change of yours. If you really want to be a unique snowflake with your own oem-config slideshow, we'll have to discuss how to make that work (or, ubiquity patches welcome). | 19:06 |
| infinity | flexiondotorg: But, for now, it would have broken your ISOs, so reverted to avoid that. | 19:06 |
| stgraber | hallyn: hmm, nope | 19:11 |
| hallyn | a reboot typically fixes it, but it's happened to me twice now | 19:12 |
| sarnold | hallyn,stgraber, quick Q re lxd images, how does one compute the sha256sum of a directory? | 19:14 |
| hallyn | ? | 19:15 |
| stgraber | sarnold: it's not a directory | 19:15 |
| hallyn | apparently we have some docs to clear up | 19:15 |
| elfy | mmm - why's an upgrade in vivid that's wanting to upgrade upstart-bin expecting to install a bunch of 32bit packages | 19:15 |
| stgraber | sarnold: lxd images are tarballs containing a rootfs/ directory and a metadata.yaml file. That compressed tarball is what we hash | 19:16 |
| sarnold | hallyn,stgraber, search for "unique" https://github.com/lxc/lxd/blob/master/specs/command-line-user-experience.md | 19:16 |
| stgraber | ah yeah, need to fix that one, good cach :) | 19:16 |
| stgraber | *catch | 19:16 |
| sarnold | want an issue? | 19:16 |
| stgraber | nah, I'll send a branch now | 19:16 |
| sarnold | okay, thankls | 19:16 |
| stgraber | hallyn: https://github.com/lxc/lxd/pull/427 | 19:18 |
| sarnold | stgraber: is that hash of the compressed tarball or uncompressed tarball? | 19:19 |
| stgraber | sarnold: it's a hash of the tarball as it was uploaded. So if it's an uncompressed tarball, then uncompressed, if it's compressed, then compressed. | 19:21 |
| infinity | elfy: It's confused. Let the archive settle. | 19:21 |
| sarnold | stgraber: okay, thanks | 19:21 |
| stgraber | sarnold: the idea being that sha256sum <file> will match the hash used to refer to it after you import it into lxd | 19:21 |
| elfy | infinity: ok - I did wonder, but also got asked - thanks | 19:22 |
| infinity | elfy: That's a remarkably weird behaviour on apt's part, though. I wouldn't have expected it to break differently. :P | 19:22 |
| infinity | elfy: Hrm, on mine, is just holds upstart-bin, which seems more sane. | 19:23 |
| infinity | s/is/it/ | 19:23 |
| elfy | infinity: apt seems to be doing it right, synaptic is playing games ... | 19:24 |
| infinity | elfy: Oh, wow, people still use synaptic? | 19:25 |
| elfy | infinity: they do ... | 19:25 |
| infinity | elfy: Anyhow, once the archive has settled to the point where apt appears to offer a sane upgrade, can you cancel that and see if synaptic is happier too? | 19:25 |
| infinity | elfy: Should be another 30m or so at most, I'd think. | 19:25 |
| elfy | infinity: will do | 19:25 |
| infinity | elfy: The sane upgrade, fwiw, should involve installing "upstart" as a new package, and otherwise just a bunch of upgraded packages. | 19:26 |
| infinity | elfy: Assuming it's a system with systemd-sysv installed. | 19:26 |
| elfy | infinity: it is | 19:26 |
| infinity | elfy: Right. So, that's what the upgrade should look like when the archive settles. Lots upgraded, and upstart new. | 19:27 |
| elfy | okey doke | 19:27 |
| hallyn | merged | 19:28 |
| === darkpt is now known as Hellper | ||
| infinity | didrocks: Did you want me to do the ubuntu-touch-meta update in a bit? It looks like I'll still be awake for another half hour or so anyway. | 19:37 |
| didrocks | infinity: no, that's fine, I see it through rmadison just now, so I guess it's just a question of 15 minutes, I can wait a little bit more | 19:38 |
| didrocks | I'll just update, if the diff is fine, I will dput and done | 19:39 |
| === Hellper is now known as darkPT | ||
| infinity | didrocks: Mirrors should be good. | 19:45 |
| didrocks | infinity: yeah, already building the metapackage + trying an upgrade path here | 19:47 |
| didrocks | infinity: \o/ upgrade path is what is expected (upstart installed, the rest upgraded), and the diff on ubuntu-touch-meta is what you would expect, no bad surprise here | 19:48 |
| didrocks | pushing | 19:48 |
| infinity | didrocks: Trying the upgrade with update-manager too. | 19:48 |
| === _salem is now known as salem_ | ||
| infinity | didrocks: update-manager seemed to DTRT too. | 19:52 |
| didrocks | infinity: good news to end the day (and you should go to bed) \o/ | 19:53 |
| didrocks | we may have some autopkgtest failures on the "expect init to be upstart if upstart bin is installed" | 19:53 |
| didrocks | but let's handle that as they come (if any) | 19:53 |
| infinity | didrocks: Might be a few, but I do hope that's not a common thing to do. | 19:53 |
| didrocks | I hope too | 19:54 |
| didrocks | infinity: ok, with that, have a good night and see you tomorrow :) | 19:54 |
| infinity | didrocks: Thanks again, and g'night. | 19:54 |
| didrocks | yw! thanks for your review and getting the packages passing by | 19:54 |
| Noskcaj | Do anyone want to sync libssh2 before we freeze? It fixes 0003-CVE-2015-1782 | 20:16 |
| ubottu | The kex_agree_methods function in libssh2 before 1.5.0 allows remote servers to cause a denial of service (crash) or have other unspecified impact via crafted length values in an SSH_MSG_KEXINIT packet. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1782) | 20:16 |
| Noskcaj | And no other changes | 20:16 |
| infinity | Noskcaj: Done. | 20:18 |
| Noskcaj | :) | 20:18 |
| mdeslaur | roaksoax: can you please merge in the utopic security update into your vivid django package: https://launchpad.net/ubuntu/+source/python-django/1.6.6-1ubuntu2.2 | 20:23 |
| Noskcaj | Riddell, Do you have a few minutes to help me fix libgit2-glib? | 20:24 |
| === olli_ is now known as olli | ||
| doko | barry, can python3-enum34 be removed in vivid? | 20:37 |
| barry | doko: probably, given that python3.4 has it. not sure what the effects would be for virtualenvs or systems that have been upgraded (and would have older python3's). but then maybe pip is good enough. so probably yes, but i don't want to commit to "yes" ;) | 20:39 |
| doko | I'm too tired, making too many mistakes. good night | 20:43 |
| roaksoax | mdeslaur: will do! thanks | 20:46 |
| _habnabit | not sure if this is the right channel, but it seems more correct than #ubuntu, at least. i'm trying to find the source for avahi 0.6.31-4ubuntu4; http://packages.ubuntu.com/source/vivid/avahi links to https://code.launchpad.net/~ubuntu-desktop/avahi/ubuntu which only appears to be 0.6.31-1ubuntu1. https://code.launchpad.net/avahi doesn't seem to list any other ubuntu branches, either | 20:57 |
| tarpman | _habnabit: https://launchpad.net/ubuntu/+source/avahi/0.6.31-4ubuntu4 | 20:57 |
| _habnabit | tarpman, oh okay thanks | 20:58 |
| _habnabit | tarpman, how did you know where that was? | 20:58 |
| dobey | _habnabit: https://launchpad.net/ubuntu/+source/avahi ? | 20:59 |
| _habnabit | dobey, yeah, but the package.ubunutu.com page doesn't link there? | 21:00 |
| tarpman | _habnabit: I don't remember where I learned it... :/ if you search for "avahi" on LP, dobey's link is near the top; also bug pages have links to different source pages at the top | 21:01 |
| dobey | _habnabit: well, the branch it links to *should* have it, but it looks like the branch import broke at some point, so it's out of date | 21:02 |
| _habnabit | okay | 21:02 |
| _habnabit | anyway thanks | 21:02 |
| micahg | you can also use pull-lp-source from ubuntu-dev-tools | 21:02 |
| _habnabit | oh, okay | 21:02 |
| _habnabit | that will pull from the right place always? | 21:03 |
| micahg | well, that'll get you the latest tarball | 21:03 |
| _habnabit | ah | 21:03 |
| micahg | debcheckout should DTRT most of the time for VCS as well (except in cases like this where it's not up to date) | 21:03 |
| _habnabit | i wanted the bzr repo because i'm making an internal fork; avahi-daemon interacts oddly with unprivileged containers, and i need to patch it for now | 21:04 |
| elfy | infinity: so yea - everything is happy now | 21:04 |
| _habnabit | relatedly, if i was going to do that, is there a particular versioning scheme i should use so that my own packages somehow supersede ubuntu's? this isn't something i've had to do before | 21:05 |
| tarpman | _habnabit: generally, tack on your own version after the ubuntuN, see dch(1)'s -l/--local argument | 21:06 |
| _habnabit | tarpman, does -l have a default prefix it adds? afaict from the manpage it just suffixes whatever you want | 21:08 |
| _habnabit | tarpman, the 'backport creation' page suggests using a ~ delimiter | 21:08 |
| _habnabit | er, prefix = delimiter | 21:09 |
| dobey | you should just append ".0~youridentifier1" to the version for example | 21:09 |
| _habnabit | okay | 21:10 |
| tarpman | _habnabit: ~ makes it sort earlier, backports use it so that upgrading to a new stable works later | 21:10 |
| tarpman | _habnabit: dch -l local → turns 0.6.31-4ubuntu4 into 0.6.31-4ubuntu4local1 (for example) | 21:10 |
| _habnabit | so if i then make avahi 0.6.31-4ubuntu4.0~habnabit1 it'll supersede, say, -4ubuntu5 ? | 21:10 |
| tarpman | dobey: just curious, what's the purpose of the .0~ part? | 21:11 |
| tarpman | _habnabit: no, but you can avoid that via pinning, see apt_preferences(5) | 21:12 |
| _habnabit | ah okay | 21:12 |
| tarpman | _habnabit: generally if the ubuntu package gets e.g. a security update, you'd probably want to rebase on that (IMO) | 21:12 |
| _habnabit | true | 21:12 |
| tarpman | that's how I manage my local repo, anyway. dch -l, pinning so I don't get caught by surprise, and rebasing asap when security updates happen | 21:13 |
| tarpman | others have their own workflows :) | 21:13 |
| dobey | tarpman: .0 makes it newer than current version, ~foo makes it older than next version | 21:15 |
| dobey | so if a security update comes, that will get preferred, if it's not pinned or such | 21:15 |
| micahg | well, technically, ~ makes it less than whatever is before it, so in this case, the .0 | 21:17 |
| dobey | micahg: well right, but the .0 is in case the next version becomes N.1 or such, rather than N+1 | 21:18 |
| dobey | ie, the same reason ubuntu packages often are 0ubuntu1 when they are newer than what's in debian | 21:18 |
| micahg | right, so, technically, .0 is superseding the current version and making it lower than the next :), the ~foo part is commonly used for distro versioning (i.e. ~ubuntu15.04) | 21:19 |
| micahg | or for branding...~avahipatch15.04 | 21:20 |
| _habnabit | another versioning question: if the avahi in 14.04 is 0.6.31-4ubuntu1, and there was a security fix released, what would the version used be? 0.6.31-4ubuntu3 is the version that's in 14.10, so presumably you can't reuse that version | 21:20 |
| micahg | 0.6.31-4ubuntu1.1 | 21:21 |
| _habnabit | ah okay | 21:21 |
| _habnabit | that makes sense then | 21:21 |
| tarpman | i've also seen some done with the release version, e.g. ubuntuN.14.04.1 | 21:21 |
| micahg | that would be for a new upstream | 21:22 |
| tarpman | ah, ok | 21:23 |
| micahg | you can see examples here: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging | 21:24 |
| === rww is now known as rwwbuntu | ||
| === rwwbuntu is now known as rww | ||
| sheap | Is there a reason as to why the Release file for the ddeb precise-security on http://ddebs.ubuntu.com/ is broken? | 22:41 |
| sarnold | sheap: broken in what way? it validates against the Releases.gpg file.. | 22:43 |
| sheap | sarnold: there's no architecture or component list | 22:45 |
| sheap | it also hasnt been updated since august 2014 | 22:46 |
| sarnold | sheap: aha, I see. I don't know enough about ddebs to know if those shuold be present or not. | 22:47 |
| sarnold | .. trusty-security has them though. I wonder why precise-security doesn't. | 22:48 |
| sheap | sarnold: does it? | 22:49 |
| sheap | I see that same issue on all the security repos... | 22:49 |
| sarnold | sheap: sigh, no, yhou're right, I was still looking at the archive.ubuntu.com rather than ddebs. can't rad. | 22:51 |
| sarnold | read either. | 22:51 |
| sheap | yea none of those security repos have been updated, very curious | 22:52 |
| bschaefer | does ubuntu sync from debain experimental? | 23:06 |
| hallyn | oh no, my cgmanager fix wasn't quite right... | 23:06 |
| ari-tczew | bschaefer: nope. only on sync request | 23:06 |
| bschaefer | ari-tczew, thanks! | 23:07 |
| ari-tczew | (automatically - no) | 23:07 |
| hallyn | anyone here know how to tell system to not to create a slice for a daemon? | 23:18 |
| sarnold | hmm, no pitti online; who else should get poked when the apport retracers seem missing? | 23:21 |
| hallyn | (hm, i guess my last commit was ok, just untidy) | 23:27 |
| * hallyn bbl | 23:27 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!