| === salem_ is now known as _salem | ||
| hallyn | bug 1292234 | 03:54 |
|---|---|---|
| ubottu | bug 1292234 in qemu (Ubuntu) "qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)" [High,Confirmed] https://launchpad.net/bugs/1292234 | 03:54 |
| hallyn | arges: yeah, sure, that'd be good. if you end up giving up you can alwyas assign it back to me. | 03:55 |
| hallyn | ogra_: wedensday is my only day on keyboard this week. what's up? | 03:55 |
| arges | hallyn: yea, i ran 15 iterations of the reproducer today on my x220 with ext3/lvm and no luck, will try some other approaches here soon | 04:33 |
| arges | hallyn: assigned myself | 04:37 |
| hallyn | arges: gah! | 04:38 |
| hallyn | arges: thanks | 04:38 |
| ScottK | Nice to see Randall's blog given over to advertising now. | 05:27 |
| darkxst | mitya57, http://pastebin.com/ayU04vHz | 05:58 |
| dholbach | good morning | 07:52 |
| LocutusOfBorg1 | hi dholbach :) | 08:22 |
| dholbach | hi LocutusOfBorg1 | 08:22 |
| MasterPiece | !help | 08:24 |
| ubottu | Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience | 08:24 |
| darkxst | MasterPiece, sometimes people say hi to others they know ;) guess it a social thing ;) | 08:36 |
| MasterPiece | darkxst, I know, my purpose of command was detecting the bot | 08:37 |
| MasterPiece | Hi all :) | 08:37 |
| darkxst | the bot is always here, except when he breaks ;) | 08:38 |
| LocutusOfBorg1 | I like to say "hi" to dholbach, because I should never stop to thank him for all the merges he does for me :) | 08:43 |
| * dholbach hugs LocutusOfBorg1 | 08:50 | |
| dholbach | thanks a lot for all your hard work! | 08:50 |
| LocutusOfBorg1 | s/hard/easy :) | 08:51 |
| LocutusOfBorg1 | I hope to become soon a DD, to become after an ubuntu developer :) | 08:51 |
| dholbach | all the best! :) | 08:57 |
| xnox | Guten Morgen! | 09:15 |
| highvoltage | guten morgen xnox | 09:20 |
| LocutusOfBorg1 | xnox, too difficult :) morning to you too :D | 09:24 |
| frechdachs69 | anyone who knows how to check for installed Qt5 plugins using cmake with Ubuntu 14.04? e.g. Qt5Gui_PLUGINS is just empty | 09:24 |
| frechdachs69 | according to cmake no plugins are available at all | 09:26 |
| LocutusOfBorg1 | frechdachs69, do you have your find_package issued correctly? | 09:27 |
| LocutusOfBorg1 | sorry I usually use .pro files with qt | 09:27 |
| LocutusOfBorg1 | anyway, I encoundered some cmake 3.0 problems about a bad "find_package" | 09:28 |
| LocutusOfBorg1 | http://qt-project.org/doc/qt-5/cmake-manual.html | 09:28 |
| frechdachs69 | LocutusOfBorg1: I've checked the installed cmake files: the referenced Qt5Gui_*.cmake files are missing inside package 'qtbase5-dev' | 09:41 |
| frechdachs69 | which package do I have to install to get 'Qt5Gui_QGifPlugin.cmake' ? | 09:44 |
| LocutusOfBorg1 | I don't think you need it, why you think you should have one? | 09:48 |
| LocutusOfBorg1 | you use the find_package and it fills the vars for you | 09:48 |
| pitti | stgraber: I'm confused by bug 1346734 -- I now have the cgroups writable for "ubuntu" in all controllers, but it still complains with some weird rmdir errors | 09:53 |
| ubottu | bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Medium,Triaged] https://launchpad.net/bugs/1346734 | 09:53 |
| pitti | stgraber: I followed up to the bug with some details; would be nice if you could have a look? | 09:54 |
| pitti | stgraber: ah, the old "got the solution only after asking" effect again, unping | 09:58 |
| pitti | stgraber: yay, I have my first user container running under systemd :) | 09:58 |
| ogra_ | crazy talk | 09:58 |
| === doko_ is now known as doko | ||
| mitya57 | darkxst, thanks, I got it. Will try to include this in Debian upload. | 10:36 |
| mitya57 | darkxst, or, maybe it'll be better to just depend on mutter-common. | 10:41 |
| darkxst | mitya57, don't add dependencies for retarded code | 10:42 |
| mitya57 | Well, mutter-common is just 4MB and doesn't depend on anything else | 10:43 |
| darkxst | mitya57, it really should be fixed upstream, but apparently they don't care | 10:46 |
| mitya57 | I still think that it would be better to add dependency than carry a patch never-accepted-upstream | 10:47 |
| darkxst | mitya57, sure, and I am still shocked how that code could make it into a release | 10:54 |
| === _salem is now known as salem_ | ||
| darkxst | its up there with the most convulted piece of python code I have ever seen in a real project | 10:55 |
| darkxst | convoluted | 10:55 |
| darkxst | and certainly my intention of patching was for them to fix it, not ignore it | 10:57 |
| pitti | doko: wrt. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#binutils, the new binutils indeed changes/breaks the lintian test for "apparently-corrupted-elf-binary"; I suppose the lintian test needs to be adjusted | 10:57 |
| doko | pitti, have't looked yet, wasn't that eager to get it migrated | 10:59 |
| pitti | doko: there's no change in Debian's git yet (http://anonscm.debian.org/cgit/lintian/lintian.git/log/t/tests/binaries-from-other-arch) | 10:59 |
| pitti | doko: oh, ok, I thought you were; I'll file a Debian bug then, the lintian guys are usually very fast | 10:59 |
| mitya57 | darkxst, I have seen Python code that is a *lot* worse | 10:59 |
| mitya57 | So, for now I'll add the mutter-common dependency in Debian, and will remove it when/if they accept your patch | 11:00 |
| darkxst | mitya57, I have as well, but not under the GNOME umbrella, although admittly not much python there | 11:00 |
| mitya57 | (and I am going to upload it when debian #770969 is approved) | 11:00 |
| ubottu | Debian bug 770969 in release.debian.org "unblock: gnome-tweak-tool/3.14.2-1 (pre-approval)" [Normal,Open] http://bugs.debian.org/770969 | 11:00 |
| darkxst | mitya57, ok, doubt it will ever be approved anyway | 11:02 |
| darkxst | I was never able to even get a review, even after pinging relevent people on IRC | 11:05 |
| mitya57 | :-( | 11:06 |
| jamespage | didrocks, apologies - I thought I'd covered you update to docker but apparently not | 11:07 |
| didrocks | jamespage: no worry, I was just wondering if this was on purpose. Once your package moves out from -proposed, I'll readd this :) | 11:10 |
| jamespage | didrocks, let me sort that out now so next time I merge it I know what I'm mean't to be doing | 11:11 |
| didrocks | jamespage: sure! | 11:13 |
| jamespage | didrocks, you fix was the ensure_socket_activation_only.patch right? | 11:15 |
| didrocks | jamespage: yeah | 11:16 |
| didrocks | jamespage: newer packages ships a WantedBy= target | 11:16 |
| didrocks | you need to remove it | 11:16 |
| didrocks | (in docker.service) | 11:17 |
| didrocks | as the pointed targeted (multi-user.target) is started as part of the boot process | 11:17 |
| didrocks | and so, this is starting docker.io at boot | 11:17 |
| jamespage | didrocks, sorry for the dumb questions but why don't we want it to start on boot? | 11:18 |
| didrocks | jamespage: because it's socket activatable | 11:19 |
| didrocks | jamespage: so, if you call docker <something>, it will start the service | 11:20 |
| didrocks | only when needed then | 11:20 |
| jamespage | didrocks, that seems related to https://github.com/docker/docker/commit/053c3557b3198466ecfbe066fefdbab2a78771d5 | 11:22 |
| jamespage | if we don't start it on boot, the --restart=always flag can't be obeyed? | 11:22 |
| cjwatson | rbasak: \o/ I tracked down bug 1393832 | 11:24 |
| ubottu | bug 1393832 in dpkg (Ubuntu) "Modules fail to enable when configured after apache2 is configured" [Undecided,New] https://launchpad.net/bugs/1393832 | 11:24 |
| cjwatson | will update bug shortly :) | 11:24 |
| didrocks | jamespage: hum, indeed, that one seems sensible (the second should be fixed with something else) | 11:24 |
| didrocks | jamespage: is there any flags on the file system to know which containers have --restart=always flag? | 11:25 |
| jamespage | didrocks, hostconfig.json contains the restart policy for a container | 11:28 |
| jamespage | /var/lib/docker/containers/uuid/hostconfig.json | 11:28 |
| didrocks | jamespage: ok, let it that way then, but I think we should investigate to only start the unit if there are some with those flags | 11:29 |
| jamespage | didrocks, that sounds efficient | 11:30 |
| didrocks | thanks for digging in! | 11:30 |
| jamespage | np | 11:30 |
| pitti | doko: I sent debian bug 771054 FYI | 11:37 |
| ubottu | Debian bug 771054 in lintian "lintian: FTBFS: binaries-from-other-arch fails with latest binutils" [Serious,Open] http://bugs.debian.org/771054 | 11:37 |
| doko | pitti, did you have a look which input file has this warning emitted? | 12:19 |
| pitti | doko: it's generated by "sh t/tests/binaries-from-other-arch/debian/debian/dumpobj > /tmp/elfobj" | 12:22 |
| pitti | doko: the binary-from-other-architecture is correctly determined, and "file" confirms that it's an ARM binary; not sure why it's a "corrupted" binary (it's just a base64 dump of something) | 12:23 |
| === frechdachs69_ is now known as frechdachs69 | ||
| === MacSlow is now known as MacSlow|lunch | ||
| fabbione | ivoks: ping | 12:52 |
| fabbione | ivoks: not sure who is in charge of pcmk your side, but if you are not looking at the upstream ml, we will have a HA Summit in Feb in brno | 12:53 |
| fabbione | ivoks: might want to consider having your maintainer there | 12:53 |
| ogra_ | hey, the godfather is around ... | 12:53 |
| fabbione | hey ogra_ | 12:54 |
| ogra_ | how is life ? | 12:54 |
| fabbione | yeah they didn't kill me yet | 12:54 |
| fabbione | not too bad, you? | 12:54 |
| ogra_ | great ... phones everywhere | 12:54 |
| ogra_ | :) | 12:54 |
| fabbione | nerd :) | 12:55 |
| ogra_ | haha | 12:55 |
| ivoks | fabbione: hey, how are you? :) | 12:59 |
| fabbione | ivoks: usual man, usual :) | 13:00 |
| ivoks | fabbione: i'll pass on the information, thanks | 13:01 |
| ivoks | i'm personally not that much invovled anymore | 13:01 |
| fabbione | ivoks: wfm | 13:02 |
| cjwatson | rbasak: ... and that fixed the broken autopkgtests that I noticed (mod-wsgi and puppet); excellent | 13:48 |
| === salem_ is now known as _salem | ||
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | stgraber: I added some debugging, and attaching a process to /user.slice/user-1000.slice in the "cpuset" controller fails with "No space left on device"; does that happen to ring a bell? | 14:15 |
| pitti | hallyn: ^ or to you, from your cgmanager work? I get that when trying to attach a pid to a cgroup in cpuset; it works for all other controllers | 14:15 |
| pitti | but it seems LXC is quite insistant on getting that controller, too | 14:16 |
| pitti | in the interwebs I found "Cpuset always require initializing cpuset.cpus and cpuset.mems, | 14:17 |
| pitti | because they are empty by default, this fact block task attaching with -ENOSPC" | 14:17 |
| pitti | indeed /sys/fs/cgroup/cpuset/cpuset.mems is "0-3" on my workstation (where it works), and "0" in my test VM (where it fails) | 14:18 |
| === Guest68049 is now known as rcj | ||
| hallyn | pitti: if you get no space left ondevice, it sounds like your cpuset.cpus or cpuset.mems is unset | 14:20 |
| hallyn | pitti: '0' would be ok. that means you get '0'. | 14:20 |
| hallyn | (cpu 0, not 0 cpus) | 14:20 |
| pitti | hallyn: cpuset.mems is "0" in both situations, so I guess it's the "0" in cpuset.cpus? | 14:20 |
| hallyn | what is cpuset.cpus? | 14:20 |
| === rcj is now known as Guest36844 | ||
| hallyn | no that sounds fine actually | 14:21 |
| pitti | hallyn: oh, but /sys/fs/cgroup/cpuset/user.slice/user-1000.slice/cpuset.cpus is indeed empty | 14:22 |
| pitti | (where I want to attach to) | 14:22 |
| hallyn | pitti: oh, ok, then yes that needs to be initialized. if you set clone_children=1 you'll be fine | 14:23 |
| hallyn | cgmangaer would do that for you, but doesn't when systemd is running | 14:23 |
| pitti | hallyn: ah, thanks | 14:24 |
| pitti | hallyn: indeed /sys/fs/cgroup/cpuset/cgroup.clone_children is "1" on my workstation and "0" in my VM | 14:25 |
| pitti | hallyn: I don't know what set that, might that be LXC or so? I don't have cgmanager running, and systemd doesn't touch it either | 14:25 |
| hallyn | lxc does also set it | 14:26 |
| hallyn | just on /lxc | 14:26 |
| hallyn | hm, or maybe not just on lcx, but i thought so | 14:26 |
| pitti | the fun thing is that lxc-checkconfig says "Cgroup clone_children flag: enabled" when it's not | 14:26 |
| pitti | that's the only hit that grep find | 14:26 |
| pitti | hallyn: anyway, so in order to do that "attach to all controllers" thing, I need to set clone_children to 1 during startup; do you know if that could negatively affect anything else? | 14:27 |
| pitti | according to what https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt says about it it seems fairly harmless | 14:27 |
| pitti | hallyn: and I guess that's what we've done until now anyway, so it wouldn't be a regression either way, right? | 14:28 |
| hallyn | pitti: rihgt, the only thing i tmight do is upset systemd at some point | 14:30 |
| hallyn | pitti: i know of nothing that depends on those not being initialized | 14:30 |
| hallyn | anything that does, could set it lcoally for the workloads it's trying ot confine | 14:31 |
| pitti | hallyn: not really; systemd upstream does not touch any controller except the custom "systemd" one | 14:31 |
| pitti | I'm just patching all that in :) | 14:31 |
| hallyn | doesn't it handle other controllers contingent on a /etc/systemd/logind.conf setting? | 14:32 |
| didrocks | pitti: yeah, cpu controller is 0 by default, it's weird because lennart's blog post told that he's using at least the cpu one by default | 14:32 |
| pitti | hallyn: that was <= 204 | 14:32 |
| pitti | didrocks: indeed, "0" is the first one; empty file means "none" | 14:32 |
| hallyn | oh. i'm behind the times as usual | 14:32 |
| pitti | hallyn: and indeed my login shell is now in all controllers including cpuset \o/ | 14:33 |
| pitti | blimey! my container starts! | 14:33 |
| pitti | ♩ rock'n'roll tune ♪ ♫ | 14:33 |
| pitti | hallyn: thanks for your help! | 14:33 |
| * pitti aims a spear towards bug 1346734 | 14:34 | |
| hallyn | np - hopefully we get al lthis straightened out this cycle | 14:34 |
| ubottu | bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Medium,In progress] https://launchpad.net/bugs/1346734 | 14:34 |
| hallyn | excellent | 14:34 |
| hallyn | thanks - ttyl | 14:34 |
| === roadmr is now known as roadmr_afk | ||
| xnox | doko++ hammerhead - BOOM! =) | 14:57 |
| === charles_ is now known as charles | ||
| === cmagina_ is now known as cmagina | ||
| stgraber | pitti: actually, it does | 15:25 |
| pitti | stgraber: hallyn already responded, we figured it out (cpuset's cgroup.clone_children) | 15:26 |
| stgraber | pitti: oh, looks like hallyn answered | 15:26 |
| pitti | stgraber: it's working now with the patch set in http://people.canonical.com/~pitti/tmp/systemd-unpriv-lxc/ | 15:26 |
| pitti | stgraber: I'm backporting them to our 215 package as we speak | 15:26 |
| === roadmr_afk is now known as roadmr | ||
| === _salem is now known as salem_ | ||
| cjwatson | Could somebody have a look at https://launchpad.net/ubuntu/+source/glib2.0/2.43.1-1/+build/6596956 ? It's causing collateral damage further up the build stack. | 15:47 |
| cjwatson | I've already retried it once. | 15:47 |
| pitti | Laney: ^ that's the thing you are currently discussing with desrt in #u-desktop, right? | 15:47 |
| Laney | yes | 15:47 |
| cjwatson | OK, cool, thanks | 15:47 |
| Laney | He's about to pop up in #is to get porter access, so if you want it fixed get them to action it quickly ;-) | 15:47 |
| stgraber | pitti: on the other side of the story, I just sent an e-mail to lxc-devel detailling our plan for systemd container support. I actually got an almost working container here using a very hackish prototype. | 15:59 |
| pitti | stgraber: oh, nice! you mean for systemd as pid 1 in the guest? what's actually missing there? | 15:59 |
| pitti | stgraber: or do you mean for unprivileged containers? | 16:00 |
| pitti | stgraber: as they seem to work reasonably well with root containers | 16:00 |
| stgraber | pitti: systemd as pid1 in a lxc container, both privileged and unprivileged | 16:00 |
| stgraber | and without having to turn off any crazy apparmor option (like allowing cgroupfs mounts or anything like that) | 16:00 |
| pitti | stgraber: hm, that's bug 1347020? | 16:01 |
| ubottu | bug 1347020 in lxc (Ubuntu) "systemd does not boot in a container" [High,Triaged] https://launchpad.net/bugs/1347020 | 16:01 |
| stgraber | I guess so | 16:01 |
| stgraber | we also have a dozen more on github | 16:01 |
| pitti | stgraber: ah right, I had to weaken apparmor for the cgroup mounting | 16:01 |
| stgraber | so the current plan is to write lxfs (fuse filesystem) to take care of the cgroup part, implement unprivileged lxc.autodev, implement init system detection code so we can turn on autodev, turn off kmsg redirect and set lxc.mount.auto appropriately if the container's init system is systemd and also add a new lxc.init_cmd option so you can set a different init path in there. | 16:02 |
| cjwatson | bdmurray: Where's the best place to get package-team-mapping in a machine-readable form? | 16:03 |
| cjwatson | bdmurray: I've found https://bazaar.launchpad.net/~bryce/arsenal/2.x/view/head:/reports/package-team-mapping.csv, but not exactly current | 16:11 |
| cjwatson | bdmurray: Or is there a version that comes out of bug subscriptions now? | 16:12 |
| bdmurray | cjwatson: there are teams that should be subscribd to packages for which they are responsible, although I haven't looked at it in a bit, e.g. foundations-bugs, desktop-packages, ... | 16:13 |
| cjwatson | bdmurray: Right, so what I'm trying to do is work out how we might generate subdivided reports from things like proposed-migration, component-mismatches, etc. that are divided down by teams | 16:14 |
| bdmurray | cjwatson: this report should cover most of teams - http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-u-tracking-bug-tasks.html | 16:14 |
| cjwatson | bdmurray: Intersecting those with the team mapping seems like the right first step | 16:14 |
| cjwatson | bdmurray: But I don't really want to have to scan through for the mapping every time | 16:14 |
| bdmurray | cjwatson: I'm looking around. fwiw unsubscribed-packages in ubuntu-archive-tools has the team names | 16:16 |
| cjwatson | bdmurray: I guess I kind of want https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/package-sub-json/+merge/193321 except not limited to main and restricted? | 16:16 |
| bdmurray | cjwatson: oh yeah, that'd make sense | 16:17 |
| cjwatson | bdmurray: Are you particularly attached to that being limited to main/restricted (and the output file prefixed with m-r-)? I know you probably don't want to scan through every source package in the archive, but it should be possible to just dump out the subscriptions of those teams | 16:18 |
| bdmurray | cjwatson: No, having it include the archive seems fine. | 16:19 |
| cjwatson | bdmurray: cool, I'll sort that out and have it dump regularly to somewhere under ~ubuntu-archive, then | 16:20 |
| cjwatson | thanks | 16:21 |
| bdmurray | no problem | 16:22 |
| cjwatson | "unsubscribed" will still just be main and restricted, I guess that's OK | 16:23 |
| cjwatson | it's the other entries I care about :) | 16:23 |
| pitti | bdmurray: I salvaged the ddebs tarball for now; indeed the two binary packges don't get published for some reason, I'll investigate this more closely tomorrow morning | 16:30 |
| cjwatson | bdmurray: http://people.canonical.com/~ubuntu-archive/package-team-mapping.json is now updated hourly | 16:47 |
| === happyaron is now known as Guest11916 | ||
| rbasak | cjwatson: thanks! I had just assumed that not matching the grep meant it was not installed and never considered actually checking the output. | 18:34 |
| rbasak | Nice one :) | 18:35 |
| === Guest36844 is now known as rcj | ||
| === rcj is now known as Guest84698 | ||
| === Guest84698 is now known as rcj_ghost | ||
| mdeslaur | xnox: I could have wrapped it with a few gtk version checks, but then would have had to modify autoconf to support being called with the gtk version as a parameter | 20:40 |
| mdeslaur | and then being built twice | 20:40 |
| ScottK | Much better. Thanks. | 20:40 |
| xnox | mdeslaur: yeah yeah. | 20:40 |
| xnox | mdeslaur: i'll twiddle with it a bit and check things. | 20:41 |
| === salem_ is now known as _salem | ||
| mdeslaur | xnox: and it sucks to have to test it twice for every gtk3 fix :P | 20:44 |
| mdeslaur | in fact, I wonder why we package this separately at all, maybe we should just add the plugin to the xchat/xchat-gnome packages directly | 20:45 |
| mdeslaur | hrm, dependencies on non-unity desktops maybe | 20:45 |
| xnox | mdeslaur: upstream build-system supports drop-in plugins, however that would make it non-syncable package (w.r.t. new upstream releases) | 20:55 |
| xnox | mdeslaur: i ponder if indicator plugin would be accepted e.g. hexchat upstream. | 20:56 |
| xnox | jdstrand: slangasek: i would like to build ia32 & x64 OVMF images, from that same package | 20:56 |
| * xnox rolls up his sleeves. | 20:56 | |
| mdeslaur | xnox: oh, maybe | 20:56 |
| slangasek | xnox: yes; I'm not sure the right way to do this, fwiw I've already received requests for ARM OVMF images to be installable on x86 which makes it more fun to figure out multiarch co-installability vs. cross-build all-in-one | 21:02 |
| slangasek | xnox: would native-build-everywhere, apt-get install ovmf:i386 ovmf:amd64 work, you think? | 21:02 |
| xnox | slangasek: i believe the current procedure to resolve that is to open more bug reports for technical comittee. | 21:02 |
| xnox | slangasek: i think "apt-get install ovmf:i386 ovmf:amd64 " etc is an excellent idea! | 21:03 |
| xnox | slangasek: and makes the build machinery so much easier. | 21:03 |
| slangasek | xnox: what's the right way to arch-qualify the filenames on disk? have you worked that part out? | 21:04 |
| slangasek | for compatibility I guess amd64 should keep /usr/share/ovmf/OVMF.fd and /usr/share/qemu/OVMF.fd | 21:04 |
| xnox | slangasek: yes. I'd follow the UEFI boot/ naming convention that is suffix the name with the uefi-arch tag? | 21:05 |
| === roadmr is now known as roadmr_afk | ||
| xnox | and then OVMF.fd can become a symlink to OVMFX64.fd or some such. | 21:05 |
| slangasek | can we put some separator char in there too, please? :) | 21:06 |
| stgraber | please | 21:06 |
| stgraber | otherwise I'm going to get very very confused when I've got both X64 and AARCH64 (or whatever abreviation we end up with) :) | 21:06 |
| slangasek | xnox: and yeah, that's a reasonable convention, but I'm more concerned that the things which consume ovmf know about it | 21:06 |
| xnox | because you'll sick of grubx64.efi & shimx64.efi ?! =) | 21:06 |
| slangasek | no, because having it in all caps makes it hard to read | 21:07 |
| xnox | for a long time, i though it was "shim - mex" rather than just "shim" | 21:07 |
| jrwren | is anyone aware of an sbuild like tool which uses cloudimg as its base and lxc ? | 21:08 |
| xnox | jrwren: you can boot cloudimages in lxc, in the cloud-init config preseed to install sbuild & mk-sbuild, and make post-script setup chroots you want. | 21:15 |
| xnox | jrwren: you still want to jump into lxc -> jump into sbuild chroot. As cloud-image has more things installed, than a minimal build chroot. | 21:16 |
| xnox | jrwren: we have juju charms to deploy "sbuild" ready units -> but after deployment these are ready for interractive use. | 21:16 |
| xnox | jrwren: rather than spin up, build this dsc, copy artifacts / buildlog & tear down. | 21:17 |
| xnox | slangasek: hallyn: edk2 git repository is behind packaging..... | 21:18 |
| xnox | hm.... | 21:18 |
| xnox | maybe this is not repository i'm looking for | 21:19 |
| xnox | slangasek: $ git ls-remote git://anonscm.debian.org/pkg-qemu/edk2.git HEAD | 21:21 |
| xnox | cc8fa1208f3e4e945c2549658fb40aa745c62aeeHEAD | 21:21 |
| xnox | $ git ls-remote https://anonscm.debian.org/git/pkg-qemu/edk2.git HEAD | 21:21 |
| xnox | 4e443c07ba6f2c7f4363e30ff8b3699ce1126f1eHEAD | 21:21 |
| xnox | ... the two hashes no match.... | 21:22 |
| jrwren | xnox: thanks. I'm going to have to study what you just wrote for a bit :) | 21:24 |
| xnox | jrwren: ok =) | 21:32 |
| === roadmr_afk is now known as roadmr | ||
| hallyn | xnox: with apologies to slangasek, i've horribly neglected edk2 | 21:57 |
| jrwren | xnox: my thought was more to use lxc instead of schroot. | 22:05 |
| xnox | jrwren: ok, but why cloud-image as well? | 22:06 |
| jrwren | xnox: no reason. its my go to minimal. | 22:06 |
| xnox | jrwren: you'd then want to construct lxc container with (a) unpacked debian source package (b) build-dependencies installed (c) do something like lxc-start -- dpkg-buildpackage -b | 22:07 |
| jrwren | xnox: I was trying sbuild-createchroot and having issues and hence thinking of alternatives. Now that I've switched to mk-sbuild and not having issues, I think I'll be fine with the schroot | 22:07 |
| xnox | jrwren: cloud-image is small, but it's huge compared to a minimal build-chroot as used for official builds. | 22:07 |
| xnox | jrwren: yeah, mk-sbuild is awesome. | 22:07 |
| xnox | jrwren: schroot is enough protection. | 22:08 |
| jrwren | xnox: I'll keep using mk-sbuild and sbuild and forget what I said about lxc :) | 22:08 |
| xnox | stgraber: have you though of making launchpad-sbuild thing use lxc containers? or possibly does it already do that? | 22:08 |
| xnox | jrwren: ;-) | 22:08 |
| stgraber | xnox: thought of it, yes, had time to do it, no | 22:09 |
| jrwren | calling sbuild-createchroot directly complained about debootstrap, and had a warning mounting proc. I think the proc warning was a red herring. It made me think lxc wouldn't have the proc mount issue. | 22:11 |
| jrwren | now that I've moved passed that, by using mk-sbuild, I no longer think I need lxc :) | 22:11 |
| jrwren | xnox: huge thanks for the quick response. | 22:11 |
| === rcj_ghost is now known as rcj | ||
| xnox | doko: edk2 writes crazy c which no longer builds with gcc-4.9 =( | 23:33 |
| xnox | doko: do you want to see crazy C or do you want an extra package hard-code using gcc-4.8? | 23:33 |
| sarnold | my curiosity is piqued to discover what kind of crazy C won't build with newer gcc but builds fine with newish gcc... :) | 23:34 |
| robert_ancell | blr, hey, nice to have another person online in the quiet timezone! | 23:36 |
| slangasek | xnox: is that true for upstream trunk as well? | 23:37 |
| xnox | slangasek: i believe so, yes. I'll test that out. | 23:38 |
| blr | robert_ancell: hi from Dunedin! thanks :) | 23:40 |
| xnox | slangasek: and EfiShellLib fails to build for 32bit =( | 23:41 |
| slangasek | well, that's fun | 23:44 |
| xnox | slangasek: i think build machinery expects "Ia32" subdirs for arch specific things, and it's using "IA32" in a couple of places. | 23:55 |
| xnox | slangasek: clearly this all just works on case-agnostic filesystems..... | 23:56 |
| slangasek | xnox: no problem, please build depend on mtools + lxc | 23:56 |
| xnox | slangasek: i'll try to fudge it. | 23:57 |
| slangasek | xnox: I think I hit a similar problem before for the amd64 build, that got fixed upstream before it became a problem for me | 23:57 |
| slangasek | unless I'm still carrying bletcherous case-fixing patches somewhere | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!