=== tmpRAOF is now known as RAOF [03:45] Good morning [03:45] Howdy. [03:49] wgrant: hm, seeing all the -dbgsyms in https://launchpad.net/ubuntu/wily/+queue?queue_state=0 is moderately confusing [03:54] pitti: Hm, indeed. +queue has its own special way of determining what is new, and it clearly doesn't work properly here. [03:54] (but the calculation for when things should be held in new is correct) [03:54] Can you file a bug? [03:54] wgrant: yep, will do [03:55] mwahahahaha [03:55] spread the good news- PostgreSQL now has UPSERT. [04:29] Snow-Man: that sounds like someone was interrupted by a phone call when writing SQL.. [04:30] hahaha [06:19] wgrant: filed bug 1452996 (should be "low" importance I guess, mostly just a visual distraction) [06:19] bug 1452996 in Launchpad itself "NEW queue shows -dbgsym packages" [Undecided,New] https://launchpad.net/bugs/1452996 [06:23] pitti: Thanks. [07:01] good morning [07:02] morning bach [07:15] hey dholbach [07:17] hey pitti [07:19] hey dholbach & pitti [07:20] hey seb128 :) [07:27] * mgedmin wonders if pitti'll be interested in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1453011 [07:27] Launchpad bug 1453011 in apport (Ubuntu) "SegvAnalysis: Failure: invalid literal for int() with base 16: '='" [Undecided,New] [07:44] hi folks, now that the builders are somewhat idle, can anybody please retry this build? https://launchpad.net/ubuntu/+source/hedgewars/0.9.21.1-5 [07:44] seems that locally it is building correctly now [07:45] (at least the haskell stuff seems to be fine on amd64) [07:47] LocutusOfBorg1: amd64 still seems full of sadness. [07:50] can you please explain me why in my local wily pbuilder-dist environment it doesn't behave like that? I'm lost [07:50] LocutusOfBorg1: did you try building with wily-proposed enabled in your local builder? [07:50] LocutusOfBorg1: What he said. [07:51] I tought proposed was enabled by default [07:51] bad me, I didn't check [07:52] how can I enable them in pbuilder-dist? [07:52] I see from the man page they should be enabled by default [07:53] No idea, don't use pbuilder. [07:53] anyway, I'll sort it out, sorry for the noise [07:54] thanks [07:55] anyway, seems that there is a bug in pbuilder, I see them [07:55] http://paste.ubuntu.com/11022144/ [07:55] LocutusOfBorg1: not sure if there is an easier way, but login into your pbuilder (don't forget to add --save-after-login), edit /etc/apt/sources.list, logout (your changes will get preserved) [07:55] (bad css is bad) [07:55] geser, this is what I usually do, wondering if there is a better way :) [08:00] infinity, I use proposed, but my apt seems to be smarter and discarding them [08:01] http://paste.ubuntu.com/11022226/ [08:01] this is funny enough [08:02] LocutusOfBorg1: I've only got up to about the third layer of of Haskell [08:03] Snow-Man: yay, maybe http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/17402 can be less messy at some point [08:03] LocutusOfBorg1: http://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html , hedgewars is at level 6 [08:03] cjwatson, the question is, why pbuilder-dist just discards the new haskell stuff and picks the release one? [08:03] LocutusOfBorg1: don't know, don't care :) [08:04] LocutusOfBorg1: Because pbuilder is erring on the side of "always make it build" instead of "do the right thing". :P [08:04] geser: and it's more complicated than that, because the transition order we actually want to follow is Debian's [08:04] which makes it hard enough to keep track without people jumping in and randomly retrying builds in the middle of it :) [08:04] yeah, I think so, I should make it behave more correctly [08:05] LocutusOfBorg1: And that's aptitude, not apt. The aptitude resolver is particularly silly in some cases. [08:05] (Granted that silliness is probably exactly what a "normal user" wants, but it's the exact opposite of what a buildd wants) [08:05] yes, it is! [08:05] pbuilder-dist should use apt then, not aptitude. [08:06] I don't see any benefit in building something in the wrong way (at least in a developer tool) [08:06] LocutusOfBorg1: you could use sbuild then [08:06] ^ [08:07] if you don't see any benefit in doing things wrong :) [08:07] LocutusOfBorg1: check your pbuilderrc what is configured as build-dependency resolver [08:08] I just never learned sbuild [08:09] when a tool works flawlessly I don't see a need to change, but a bad resolver might be a good reason [08:09] geser, yes, I need to check that too [08:37] seb128: hi! do you happen to be on the samba merge already? it currently causes a lot of uninstallability [08:38] (samba-libs in particular, needs to build against current libldb1) [08:39] pitti, hey, no I'm not, do I own that? I just did a bugfix upload, I was expecting zul or one of the usual samba maintainers to do that [08:39] technically you are the one who owns the merge due your upload from yesterday :p [08:39] seb128: right now, yes (TIL); I can look into it too, but indeed I've earned way too many merges due to doing archive fixes :) [08:39] pitti, I can have a look if you want [08:40] seb128: (no-change upload this morning, but it does feel like yesterday :) ) [08:40] pitti, the TIL doesn't make much sense on complexe packages which have an usual maintainer and where somebody else do a tiny change upload [08:40] seb128: yeah, I know; I just don't think that samba has a "maintainer" [08:40] seb128: either way, just didn't want to step on your toes [08:40] I didn't start on it [08:41] I can have a look if you want though [08:42] seb128: doesn't look too hard; ok, I'll merge it [08:43] pitti, thanks [09:09] bdmurray: FYI, I committed http://bazaar.launchpad.net/~ubuntu-archive/apport/lp-retracer-config/revision/22 and rolled out to the LP retracers; we need the same for daisy [09:11] cjwatson, wgrant: I did some spot checks, and ddebs.u.c./ seems to get all the dbgsyms for wily \o/ [09:22] pitti: excellent [09:33] pitti: Great. [09:44] Got a question about editing "initrd.lz". According to this tutorial http://pastebin.com/qSkAXJdX I made some changes successfully and repacked the file initrd.lz [09:45] But when copying it to /remasteredisofolder/capsper/ it has no effect...... something that I am doing wrong? [09:45] doko_: hm, the new version of python2.7/i386 consistently fails, this looks like a real regression? [09:45] doko_: (http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-python2.7/4/ARCH=i386,label=adt/console) [09:54] pitti: silly question but what sets ADT_REBOOT_MARK in the snappy-selftes? is that outside of the selftest? I was looking into some simple upgrade test fakeing [09:55] mvo: adt sets it in the tests' environment, yes [09:55] pitti: cool, thanks [09:55] mvo: is the test losing it somehow? perhaps calling something through sudo which prunes the env? [09:58] mvo: (see https://lists.ubuntu.com/archives/snappy-devel/2015-January/000057.html for how to run them with autopkgtest, BTW) [10:08] pitti: no, all good, I was just curious how it works as I want to extend it === MacSlow is now known as MacSlow|lunch [11:25] * LocutusOfBorg1 wonders how many packages can be syncd from unstable now that xorg is transitioning [11:25] * LocutusOfBorg1 looks at https://release.debian.org/transitions/html/xserver1.17.html [11:26] Mirv: do you know if someone is working on qtcreator update to 3.2 / 3.3 / 3.4? [11:27] The current old qtcreator has conflicting files with QBS, while a newer one can be built against our packaged QBS. [11:45] mitya57: zbenjamin has probably the best estimate. he has been working on upstreaming a lot of the Ubuntu SDK modified parts like the whole CMake stuff, and the update relies on getting to some sort of state where eg. 3.4 or 3.5 is such that it makes sense to update the rest of the patches to it while dropping the upstreamed parts [12:10] Mirv: ok. 3.4 was just released so maybe it's a good time to port the patches. === doko_ is now known as doko [12:23] pitti: can you retry? [12:23] doko: I can, but it didn't look flaky [12:23] I don't see it upstream on the build bots [12:23] http://buildbot.python.org/all/waterfall?category=2.7.stable === MacSlow|lunch is now known as MacSlow [12:24] doko: running again (4th try) [12:24] amd64 is okay, i386 broken [12:24] (consistently) [12:25] Mirv: i have a branch compiling against the current QtC master branch . [12:25] ahh, i386 only? [12:25] Mirv: so i would like to use that one [12:29] zbenjamin: master is 3.5? [12:29] mitya57: i think so [12:30] mitya57: it has all our patches we need [12:30] zbenjamin: Should be fine then. Can you include a change from Debian that makes it build against packaged qbs? [12:31] mitya57: is that patch already done for QtCreator in the archive? [12:32] Only in experimental. [12:33] http://anonscm.debian.org/cgit/pkg-kde/qt/qtcreator.git/commit/?id=e885d186c540cc12a875640ca3d719d88d6ff1aa [12:33] mitya57: not sure , can we Mirv? [12:35] zbenjamin: yes please we can take preferably as much as possible from Debian's qtcreator packaging :) [12:35] zbenjamin: we're pretty far out of sync unlike with Qt itself, but we don't necessarily need to yet to fully sync up [12:36] zbenjamin: so your thought is to package 3.5 git snapshot to wily? [12:37] Mirv: what is the release schedule for QtC? [12:38] i hoped we get 3.5 in this cycle [12:40] zbenjamin: it seems only in August https://wiki.qt.io/Qt_Creator_Releases [12:40] so yes this cycle but it'd mean we're stuck with 3.1 until then [12:46] Mirv: until then i'm fine with a snapshot i guess [12:46] Mirv: important part is that we get a release before we do one :D [12:47] zbenjamin: well wily is a development version so yes it'd be possible. as long as it like, you know, actually works :) [12:47] Mirv: well it seems they will feature freeze in june [12:47] zbenjamin: if we have that sprint we could hack on it together [12:48] Mirv: +10000 === _salem is now known as salem_ === anthonyf is now known as Guest11644 [13:57] pitti: is there a way to see the qemu terminal while adt runs? when it tries to ssh connect (I simulate a boot failure right now and would love to get some more info what is going on) [13:59] mvo: you mean the output during boot? yes, adt-run --- qemu --show-boot myvm.img [13:59] mvo: ah sorry, snappy runner, right? [14:00] mvo: hm, /usr/share/autopkgtest/ssh-setup/snappy calls -serial none [14:01] mvo: you could copy the script somewhere, change -serial none to e. g. -serial unix:/tmp//ttyS0,server,nowait [14:01] pitti: yeah, the snappy runner [14:01] pitti: aha, nice, let me try that [14:01] mvo: and then nc -U /tmp/ttyS0 while you run [14:02] mvo: that sounds like an useful option to add to the snappy setup script anyway, so bug report appreciated [14:02] pitti: can I haz this by default? maybe not with a predictable name, but as a option or something? [14:02] pitti: thanks :) [14:02] mvo: yeah, probably just to stdout? [14:02] +1 [14:02] mvo: i. e. a --show-boot option? [14:02] (like qemu) [14:02] yes [14:10] pitti: added bug #1453154 [14:10] bug 1453154 in autopkgtest (Ubuntu) "please support --show-boot option in snappy runner" [Undecided,New] https://launchpad.net/bugs/1453154 [14:18] mvo: ah, thanks === adrian is now known as alvesadrian === JanC_ is now known as JanC === oSoMoN__ is now known as oSoMoN === mhall119 is now known as mhall119|afk [19:11] hi [19:11] ¿can I ask here about lxc - linux containers? [19:14] aitiba: #ubuntu-server might be the better place I think [19:15] doing a "lxc exec d1 -- /bin/bash" I get "websocket: bad handshake" error ¿any ideas? [19:15] sorry === anthonyf is now known as Guest82825 === mhall119|afk is now known as mhall119 === salem_ is now known as _salem