[00:01] tkamppeter: Component on that page lists the component from debian/control, which is a bit confusing. [00:02] tkamppeter: If you scroll down, you see it's in (universe) in the release pocket of vivid, etc. [00:26] infinity, thanks, it is all in universe. So the "Component: Main" on Launchpad means perhaps that in Debian it is in Main? Has this an advantage for a MIR for Ubuntu? [00:27] tkamppeter_: It's just that, yes. It's in main in Debian (or, in the control file). That has no bearing on an MIR. [00:29] wgrant: What are the odds of making the Component field of +source/ either less confusing or not there at all? [00:29] infinity: I think I filed a bug about that in 2006, let me see. [00:29] wgrant: This isn't the first time people have misinterpreted it. [00:29] Heh. [00:30] wgrant: I guess I would argue that the package info up there should all represent current reality and overrides in the current devel series, or just not be shown at all. [00:31] Ah, not quite. [00:31] https://bugs.launchpad.net/launchpad/+bug/93293 [00:31] Launchpad bug 93293 in Launchpad itself "Details in source package portlet don't change without new upload" [Low,Fix released] [00:31] Was nwhat I was thinking of. [00:32] The portlet was fixed, but it made a reappearance in the main content, it seems. [00:33] wgrant: \o/ [00:34] wgrant: Hrm, it's not always wrong, either. That's even more confusing. [00:35] infinity: It should usually be wrong. [00:35] wgrant: Looking at, say, poppassd, it displays universe, when I would have assumed it would say main (matching control). [00:35] wgrant: But I guess a poke at the code and where it's actually getting that value would be enlightening. [00:36] infinity: Uploaded packages will show their original overrides. [00:37] wgrant: poppassd and openjpeg are both syncs, AFAICT. [00:38] wgrant: Oh, but poppassd predates syncs being a thing, so it's technically a manual upload. [00:38] Yep. [00:38] s/syncs/copies/ [03:33] infinity: hey, perhaps stupid question - are there cases (funky ld.so) where, when /sbin/foo is linked against libwhozit, libwhozit won't actually be read until it's needed? [03:34] hallyn: No. [03:35] I thought that was default behaviour unless you set LD_BIND_NOW in your environment [03:35] hallyn: Unless by "linked" you mean "dlopened()". [03:36] ohhh, that's just symbol resolution, not opening the libraries themselves. [03:36] sarnold: Yeah, I was in the middle of typing that, and my WiFi had a fit. [03:37] hallyn: ld.so loads all the objects it needs before jumping into the binary. [03:38] hallyn: Key word being "needs", if there's no NEEDED entry in your ELF header (ie: your binary is incorrectly linked, or underlinked, or whatever), then no load for you. [03:39] hallyn: Perhaps a real life example of the behaviour you think you're seeing and blaming on ld.so? [03:44] infinity: oh no i'm not seeing anything. cgmanager needs to umount any dirs it doesn't need. I'm trying to tell whether there's any reason to fight umounting /lib (if anyone has it as a mount) [03:44] i was worried someone might have a custom ld.so that loaded on-demand. Though I guess I'm not sure how it *could* possibly do it [03:45] and yeah we're not dlopening so that's not an issue [03:45] hallyn: /lib can't be a mount in any sane POSIX system. [03:46] hallyn: Except in the case of a merged /usr, where it can be a symlink into /usr/lib, but then /usr/{lib,bin,sbin} need to follow the same "all on one FS or you're a moron" rule that / classically did. [03:47] infinity: so long as initramfs mounts it i see no reason why it oculdn't [03:48] i'm not sure wht "merged /usr" means. in caes of separate /usr, i'd expect if anything /usr/lib -> /lib, not ht eother way around ,else you couldn't boot :) [03:48] this is going into debian, so i expect to see all sorts of perverse setups :) [03:50] infinity: thanks, so it sounds like i can ignore it. good news [03:58] hallyn: Sure, you could have an initrd that mounts /lib, /sbin, /bin, which is perverse, but you'd also not umount them until post-shutdown either (ie: by pivoting back into the initrd, or just doing a remount-ro and ignoring them) [04:00] infinity: right, but cgmanager is going to umount anything it doesn't need (in a private namespace) after it starts [04:01] problem is if the host is MS_PRIVATE, cgmanager starts a new mount namespace and runs in it. if host then umounts something, cgmanager keeps it mounted in its ns [04:01] so the target can't be rmdir'd, and the source isn't totally freed [04:02] so i'm thinking of doing https://github.com/hallyn/cgmanager/commit/cef2ea8d89ac329b9ce744266f235bad4d6151ed [04:04] hallyn: I guess you can't just stop cgmanager before the OS umounts at shutdown? :P [04:06] there's actually a number of debian bugs open about this [04:06] hallyn: Or maybe I'm a bit confused about what's going on. [04:06] aufs, xfce, onandon [04:07] example: sudo stop cgmanager. sudo mdir /tmp/serge; sudo mount -t tmpfs tmpfs /tmp/serge; sudo start cgmanager; sudo umount /tmp/serge; sudo rmdir /tmp/serge [04:07] hallyn: does that leak 'line' on the continue statements? [04:08] sarnold: don't think so; getline will reuse it if len is large enough for the next line [04:08] hallyn: aha, thanks [04:08] oh, heh, but loop exit will [04:08] hallyn: and, what's this "recursively umounted entries"? [04:08] hallyn: Err, kay, I clearly don't get why cgamanager is holding that mount open in the first place. [04:09] hallyn: Surely systemd doesn't have to do this same crazy "umount the world that I shouldn't have open anyway" thing? [04:09] well, if /sys and /sys/fs/cgroup are both mounted and you umount -l /sys/, then /sys/fs/cgroup will be umounted [04:09] hallyn: no kidding? :) cool. thanks. [04:10] infinity: well systemd mounts / MS_SHARED. but yes it also had this problem [04:10] sarnold: so it'd be no big deal, but i just want to avoid the failure on attempting to umount /sys/fs/cgroup later [04:11] infinity: so anythhing which systemd spawns which then unshares mntns and mounte MS_PRIVATE wil hae the same problem [04:11] (which cgmanager used to do; i switched it to MS_SLAVE for them; that doesnt' for sysvinit though0 [04:12] hallyn: So, you could probably just lazily umount $world in your private namespace, minus the proc/sys bits you know you need, and just let the kernel sort it from there. [04:13] hallyn: Instead of worrying about if /lib might be on a USB stick on Joe User's weird setup. [04:13] infinity: right that's basically what i do. walking through /proc/self/mountinfo and skipping anything i know i need [04:14] hallyn: But you don't necessarily even need / :P [04:14] hallyn: In a merged setup, you might need /usr and not / [04:14] hallyn: But if you just lazy umount them both, who cares. [04:14] what is a merged setup? [04:14] hallyn: Merged-/usr, welcome to 5 years ago. [04:15] hallyn: Where /lib, /bin and /sbin are symlinks into /usr, and /usr can be (but usually isn't) a mountpoint. [04:15] even so all i really need is /sys/fs/cgroup/cgmanager (which i created) and some target dirs for cgroup mounts, and /proc [04:16] suppose i could create an empty dir, copy /sys/fs/cgroup/cgmanager into it, pivot, umount old_root, and proceed [04:16] not sure whether that's better [04:16] hallyn: Right. And the kernel may or may not let you umount the bits where your libraries came from, depending on its mood and phase of the moon, but lazy solves that. Well, "solves". [04:17] right, i'm doing lazy, cause i don't really care ,just don't want to pin it [04:17] * infinity nods. [04:17] (my inodes are pinning it already) [04:17] hm [04:17] hallyn: A pivot chroot is probably cleaner than trying to umount everything systematically. [04:17] grr but the other way is already coded : [04:17] hallyn: But if you go full chroot style, you end up with a duplicate libc in RAM, etc, which is less ideal. [04:18] :) [04:18] why would that happen? [04:18] it's still the same inode, same page cache, no? [04:18] Or, you might. Depends on how smart we are about knowing that it's identical-but-from-elsewhere and deduping it. [04:18] hallyn: Oh, I'm thinking an old skool chroot, where it very much wouldn't be the same inode. :P [04:19] hallyn: If you can sort out something more clever that still frees up /, but gives me the same paged library, you win. Do that! [04:19] yeah i don't need that [04:19] cool, something to play with in the morning i think. [04:19] thanks! [04:19] ttyl [04:20] what does upstart --user do that allows it to adopt orphaned childreN? [04:20] i thought orphaned children just jump straight to pid1 [04:20] hyperair: Make a decent salary, and have no criminal record. [04:21] infinity: :) [04:21] that'll work [04:21] (no idea) [04:21] lol [04:27] hyperair: check out prctl(2), PR_SET_CHILD_SUBREAPER [04:27] aha [04:27] thanks [04:32] Bah. Kernel ppa doesn't have linux-tools builds :( [04:33] No perf for me until reboot. [05:10] rbasak: ok, thanks [05:38] Good morning [05:39] rbasak: /tmp overflow> ah, you are just setting $TMPDIR in the test itself? (that's a bit ugly indeed); I'm not opposed to adding an option for this [05:40] cjwatson: ah, thanks anyway, in case we want to ever simplify this again === work_alkisg is now known as alkisg [07:20] arges: good morning, could I ping you about putting an update-manager SRU in precise-proposed, if you happen to have some time today? https://launchpad.net/ubuntu/precise/+queue?queue_state=1 and https://wiki.ubuntu.com/StableReleaseUpdates#Publishing [07:42] tumbleweed: On a couple of arches, pypy seems to be leaving testsuite cruft lying around in the background, despite the build being complete. This makes the buildds amazingly unhappy (and I'm going to kill the builds). [07:43] tumbleweed: Before I kill it, this is the junk hanging around: http://paste.ubuntu.com/10169871/ [07:51] pitti: no, I'm setting TMPDIR outside the test. "TMPDIR=... adt-run ...". That did work though. [07:52] rbasak: oh, you mean your host's /tmp is too small, not the testbed's? [07:52] pitti: right. [07:52] pitti: I'm on Canonistack. / is not that big. /mnt provides more space. [07:53] Various things are symlinked to /mnt, but not /tmp. [07:53] *nod* === liam_ is now known as Guest3630 === kickinz1|afk is now known as kickinz1 [08:36] hi Laney can I try to merge inkscape from debian/eperimental? [08:37] LocutusOfBorg1: there's already a merge bug on that. [08:38] LocutusOfBorg1: bug 1416651. Looks like nobody's working on it right now though. [08:38] bug 1416651 in inkscape (Ubuntu) "Please merge inkscape 0.91-2 from Debian unstable (main)" [Medium,Triaged] https://launchpad.net/bugs/1416651 [08:38] I was going to take a look myself next week if nobody gets to it first, because I'd like the newer Inkscape on my desktop :) [08:38] wonderful [08:38] :) [08:38] thanks for the hint, I'll upload the debdiff here [08:39] Although I wouldn't do it without checking with someone from the desktop team first, as I'm not so familiar with the desktop side of things. [08:39] sure [08:39] :w [08:40] (damn focus) === alkisg is now known as work_alkisg [08:42] now everybody knows I'm a VIM user, shame on me! :wq! [08:42] :) [08:43] LocutusOfBorg1: At least you're not a filthy Emacs user. [08:43] or maybe he's doing an impersonation of a vim user to hide his emacsness [08:44] lol [08:45] I stopped using emacs after talking with its psychotherapist [08:45] :) [09:04] LocutusOfBorg1: yap [09:55] darkxst: uh, apparmor fails to start for you? [09:55] sudo journalctl -u apparmor [09:58] pitti, apparently http://pastebin.com/zqBC4mtu [09:59] darkxst: hm, that means that it never reaches sysinit.target? [09:59] ah no, it's a Wants, not a Requires [10:00] pitti, doesnt seem like something a glib update would trigger though ;( [10:01] darkxst: you have several hard disks/drives, would you mind adding your fstab? [10:02] pitti fstab http://pastebin.com/Eddi1pia [10:04] pitti, pretty sure ricotz hit this also [10:07] darkxst: I see something odd in the log indeed [10:08] /home gets mounted, then unmounted again [10:10] pitti, why would it get unmounted? [10:10] kernel? remounts ro, on errors, but nothing should unmount it? right? [10:12] darkxst: I don't know yet; I wrote the interesting log excerpt to the bug for now, but I don't fully understand this yet either [10:16] pitti, seems my laptop is not effected by this though it has a slightly simpler configuration [10:16] ok, we have some major kde uninstallability problem on i386 [10:18] ah, https://launchpad.net/ubuntu/+source/plasma-framework/5.7.0-0ubuntu1 FTBFS? [10:19] and https://launchpad.net/ubuntu/+source/knotifications/5.7.0-0ubuntu1 finished on amd64 but failed on i386 (or rather, is currently rebuilding) [10:19] I think that's causing it === work_alkisg is now known as alkisg [10:23] darkxst sarnold suggested I intall and Sbuild environment then alter the debian/rules file to try to find the nail down the bug in vim ... [10:24] And apparently, I cannot type tonight [10:25] aeoril, sbuild is great (I use it all the time) but not for tracking down bugs [10:25] hey! could a core-dev run: syncpackage -d experimental -r vivid-proposed suomi-malaga (and yes, I should probably ask for upload rights for my own Debian packages) [10:26] darkxst why not? [10:26] aeoril, its really slow for one [10:26] pitti: I uploaded lots of kde frameworks yesterday [10:26] darkxst he was suggesting I use it to build, then alter debian/rules to build a little different, kind of manually "bisecting" until I figured out the bug [10:27] pitti: as usual launchpad doesn't seem to be clever enough to do the required retries but I'm running ubuntu-build retry in a while true loop [10:27] darkxst yes, the logs on Launchpad show 20 minutes per build [10:27] Riddell: well, that'd be called "versioned build dependencies" to make it dep-wait properlY :) [10:27] Riddell: thanks [10:28] pitti: we do version them [10:29] darkxst do you think I should just manually change the build environment by altering the parameters passed to ./configure from the logs? [10:29] *gleaned from the logs [10:35] aeoril, that would be much faster! [10:36] darkxst I am doing it now .... [10:37] aeoril, and really just try what you think is right! [10:37] no need to ask my approval ;) [10:38] darkxst well, sbuild seems rather daunting right now, so I am going to fiddle with the vivid ./configure command line parameters for now. See how that goes. If need be, I can always do sbuild later [10:38] sbuild is great for whats its designed for [10:38] pitti: if you can offer any insight into why it doesn't know it needs to rebuild them that would be useful, it's a bit nuts that I have to run retry in a while loop [10:38] darkxst what is it designed for? [10:39] Riddell: well, LP never retries failed buildss [10:39] aeoril, bilding packages [10:39] Riddell: it only auto-retries depwaits [10:39] Riddell: i. e. if your build deps aren't tight enough and your build fails because it's building against a too old -dev package, there's not much you can do on the LP side [10:40] darkxst yes, that is why it may be important? I may need to replicate the Launchpad build processes as closely as possible for this bug troubleshooting ... but twiddle with it as well to nail down the problem ... [10:40] aeoril, I do all my dev work in git and jhbuild [10:40] Riddell: oh I see, it failed due to build dep uninstallability [10:40] jamespage: yo, is someone looking at the oslo/nova dep8 failures? [10:40] then backport to the archive packages (and forward upstream where applicable) [10:40] Laney, yes I am [10:41] Laney, specifically nova [10:41] great! [10:41] darkxst would jhbuild help me here? [10:41] but will work through today [10:41] aeoril, jhbuild doesnt work great outside of GNOME [10:41] thanks [10:42] darkxst well, I am fiddling around with ./configure params for nwo - can't hurt - help me learn a bunch too ... [10:42] aeoril, in fact it often doesnt work great under ubuntu at all, but they are bugs that need fixing anyway [10:42] aeoril, wouldnt bother for a single package [10:43] darkxst wouldn't bother doing what? [10:43] jhbuild [10:43] oh, ok [10:43] darkxst thanks ... [10:43] I use jhbuild okay on ubuntu [10:44] recommend getting it from git instead of the package [10:44] Laney, fedora don't link with --as-needed [10:44] so? [10:45] that creates DSO errors [10:45] and then there are usually other Ubuntu specific failures [10:45] not seen that [10:45] but like I said these get fixed upstream [10:46] since if not, they would just cause pain when doing the real packaging === kickinz1 is now known as kickinz1|afk === kickinz1|afk is now known as kickinz1 [10:51] pitti: presumably the build dep uninstallability is due to the arch:all data packages being built on 1 arch and not the others? [10:51] Riddell: right, that's the most common case [10:51] Riddell: I think infinity has had some auto-detection/retry of this situation on his todo for a long time, but for now there's indeed just the retry button === kickinz1 is now known as kickinz1|afk === kickinz1|afk is now known as kickinz1 [10:59] Mirv: done [11:00] pitti,Riddell: I'd like to move to using dose-builddebcheck for this kind of analysis, but need to figure out whether it's sensible to put it on the master or the slave end, and how it interacts with PPAs etc. [11:02] cjwatson: thanks! === _salem is now known as salem_ [11:36] darkxst: do you happen to have a rough idea when this mount failure started? [11:36] darkxst: only with the recent glib update, or did it also happen earlier? [11:36] darkxst: I can't get this bug in a VM, but I do see it on my laptop indeed [11:37] pitti, only with current ubuntu-desktop ppa [11:37] goes away if I purge that [11:37] wow [11:38] well, it's a race condition, so anything could happen [11:38] and/or gnome3-staging but alas that has the same packages copied from there [11:44] pitti, not seen in a VM either but then they all have very standard configs parition wise [11:45] where as my desktop has ~4 hdd's most with multiple partitions [11:49] darkxst: I created a VM with /home, /home/martin, and /srv on separate partitions, just like on the laptop [11:50] darkxst: anyway, I'll investigate with upstream, thanks [11:50] slangasek, could your team help to take a look at Adam's acpi-support patch in bug 1396429? It is affecting some lenovo machines we enable, thanks. [11:50] bug 1396429 in HWE Next "[Lenovo ThinkPad ?40 series] Wireless key cannot turn BT off" [High,Triaged] https://launchpad.net/bugs/1396429 [11:51] pitti, ok, I'm off to bed === MacSlow is now known as MacSlow|lunch === marcusto_ is now known as marcustomlinson [13:11] is there an easy way to tell the runtime dependencies of a particular binary? [13:11] (google found nothing for me) [13:15] aeoril: ldd ? [13:16] however it's part of the story, if it e.g. does system() call to some other dependency that would not be listed. [13:16] xnox ok, thanks === MacSlow|lunch is now known as MacSlow [13:39] xnox this also: objdump -p /path/to/program | grep NEEDED (from the ldd man page) [13:40] aeoril: same information, different representation. depends on your needs. [13:41] xnox ok, thanks again ... [13:46] alkisg: i'll review today [13:49] pitti, did one of your last systemd changes add a new user ? [13:50] ogra_: it added a new group ("input"); we talked about it the other day [13:50] no new user [13:50] pitti, right, i meant afterwards :) [13:50] P: Begin executing early chroot hooks... [13:50] /etc/group post-debootstrap hash doesn't match record [13:50] E: config/hooks/00-uid-gid-fix.chroot_early failed (exit non-zero). You should check for errors. [13:51] we have that on both, snappy and touch [13:51] one of the packages debootstrap installs has chnaged [13:51] ogra_: no, it's been ages since it added a new user [13:51] right [13:51] well, that'd be /etc/group again? [13:51] what pasting website is preferred here? paste.ubuntu.com? [13:51] just wanted to make sure ... i usually trust your changelogs :) [13:51] i simply cant find anything on vivid-changes [13:52] ogra_: so that /etc/group change does sound like the "input" group? [13:52] or at least it could be? [13:52] it doesnt complain about /etc/group [13:52] ogra_: or do you get a mismatch on /etc/passwd too? (and is there a diff? [13:52] the input group change is long gone in :) [13:52] trhere is no diff at that point ... thats my issue [13:53] aeoril: kind of; it's what pastebinit defaults to in ubuntu; but it doesn't matter much really [13:53] (i'll add it but was hoping i could find the obvious change by looking at changes first) [13:53] ogra_: hm, what do you add then if there's no diff? [13:53] i mean there is no diff that gets dumped into the log :) [13:54] live-build/ubuntu-touch/hooks/99zz-check-uid-gid.chroot actually dumps a proper diff that shows what you need to change [13:54] but i never added the same code to live-build/ubuntu-touch/hooks/00-uid-gid-fix.chroot_early [13:54] which is where we fail atm [13:55] and before diving into livecd-rootfs to add that code to the 00 script too and do a bunch of image rebuilds to find the issue, i was hoping to find it quicker via changelog entries on vivid-changes [13:56] ah, I see; sorry, I'm not aware of a recent upload that added a new system user [13:56] but then again I stopped following -changes@ years ago [13:56] (i will add the diffing code there too, but that takes longer than i like :) ) [13:56] and sadly yesterday was KDE day ... -changes is spammed :P === pgraner-afk is now known as pgraner [13:58] how do you think I feel? I get all the build failures and I've been running retry --batch all day [13:59] whack-a-buildd [13:59] haha [14:07] darkxst sarnold cjwatson Ok, so I went back to square one and seem to have made mistakes before. Please look at this log of my activities since I started re-troubleshooting the vim bug: http://paste.ubuntu.com/10173428/ I am thinking that this activity and their results point toward vim not being the problem but either something vim relies on or gnome-terminal. I am not exactly sure [14:07] what I did wrong before, but have been very careful this time to do each step in my troubleshooting correctly. Not sure what my next step should be. [14:28] xterm does not exhibit the same problem in vim on trusty sarnold darkxst cjwatson [14:36] rather, vim does not exhibit the same problem in xterm on trusty sarnold darkxst cjwatson [14:38] sarnold darkxst cjwatson I think I need to bisect gnome-terminal at this point on trusty to try to see if it is the problem [14:46] aeoril: I'm sorry, I don't think I'll have time to help you with this; could you please not highlight me? [14:46] cjwatson sure, sorry to be a bother [14:56] ogra_: pitti: http://paste.ubuntu.com/10174068/ [14:56] it seems the systemd users got removed [14:56] was that expected? [14:57] no, it's not expected [14:57] /var/lib/dpkg/info/systemd.postinst creates them [14:58] hm [15:05] once the new livecd-rootfs gets published we will trigger another image and see [15:05] but that might be the difference [15:14] rbasak: so you discovered my s3kr1t way of checking whether anyone actually uses --timeout-factor :) [15:14] :-) [15:14] I do like the idea. [15:15] Timeout -> moar time please [15:15] rbasak: while I'm at it, I should also add --warp-factor [15:15] Don't really care what the previous timeouts wanted. [15:16] So it's really tempting to use --timeout-factor over looking up default timeouts and then adjusting them. [15:16] And thus I fell into your trap :) [15:17] rsalveti, i'm startin a build, seems livecd-rootfs is in [15:17] ogra_: great [15:28] ogra_: pitti: already failed: https://launchpadlibrarian.net/197314114/buildlog_ubuntu_vivid_i386_ubuntu-touch_FAILEDTOBUILD.txt.gz [15:28] and yeah, the same diff I got [15:28] no systemd users [15:29] rsalveti: what's curious there is that this does upgrade libsystemd-*, but not the systemd package itself; did that perhaps fall off the image? [15:29] yeah, systemd is gone in there indeed [15:29] (that'd be quite bad -- no logind and such) [15:30] rsalveti, but there is also a syslog user we dont have in the reference file [15:30] no libpam-systemd either [15:30] ogra_: oh, this is not in the end of the build [15:31] so I think systemd would be added later on [15:31] @pilot in [15:31] right === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney [15:31] the lack of the syslog user is probably what caused the failure [15:31] hmm, no, the order is just different [15:32] i guess we need more info :/ [15:33] the file created in 00-uid-gid-fix.chroot_early is not the one we md5sum [15:33] it is the file that needs to match *after* the build [15:35] aha [15:35] syslog:x:100:104::/home/syslog:/bin/false [15:35] vs syslog:x:100:103::/home/syslog:/bin/false [15:36] bah, just a 0.97% error :) [15:36] i assume we just want to update the md5sum [15:38] yeah [15:39] phablet@ubuntu-phablet:~$ md5sum foo [15:39] 9ebb1c3da5b0ad8f1d366528b32c97cb foo [15:39] thats what i get with the syslog user set to 103 [15:39] phablet@ubuntu-phablet:~$ md5sum foo [15:39] 5e8366ef9c178b62079468966f38ce5f foo [15:39] and that with it set to 104 [15:40] * ogra_ prepares a fix, but we'll need one more rebuild for /etc/group i guess [15:47] kees: should chromeos switch to systemd? [15:47] * xnox is mostly done with porting ubuntu [15:47] ogra_: yeah, that might be the issue [15:49] rsalveti, change uploaded ... lets see if thats sufficient ... but i guess /etc/group will need updating too [15:52] ogra_: we can keep going until we get a new image :-) [15:52] yeah [15:52] and improve the error output with each run [15:52] to make it easier next time [15:52] yeah [15:52] i guess i should also log the expected md5 [15:53] (i only added the computed one to this upload to be logged) [15:53] ogra_: I've been making changes to livecd-rootfs for our CPC builds; it would be good to get those changes merged in. [15:53] but it might be moot since you have to edit the source anyway [15:53] (If only so I don't have to rebuild the package in our PPA every time you bump the version :p) [15:54] juts make an MP :) [15:54] so someone can review :) [15:56] ogra_: Cool, will do. === alkisg is now known as work_alkisg === Guest25083 is now known as rcj [16:21] rsalveti: hey, how are you? [16:22] rsalveti: I was coming to the new about the bluez5 Touch enablement. We are mostly done on the desktop side and don't want to miss FF. I saw that it's in your team scrum cycle iteration, but can I get some more details so that we are aligned? [16:23] didrocks: we're working on getting our kernels to be compatible with it still, ricmm is actively working on that [16:23] rsalveti: do you think this will be done before Feature Freeze? [16:24] didrocks: what is the date for FF? [16:25] rsalveti: Thursday 19th if I'm right [16:25] rsalveti: so a week + 1 day :) [16:25] * didrocks rechecks the schedule [16:25] didrocks: we hope so [16:25] we're actively working on it, so should know more by the beginning of next week [16:25] rsalveti: mind if we sync up like next Tuesday then? [16:26] sure [16:26] thanks a lot! good luck to you and ricmm :) [17:15] infinity: urgh. I've seen that before [17:15] I guess I could disable that test === seb128_ is now known as seb128 === willcooke_ is now known as willcooke [17:22] cyphermox, hey could you give me a hand with a Debian packing problem I'm having? [17:27] awe_: sure, what's up? [17:27] if you describe the problem here, if I can't help then others surely will be able to :) [17:30] cyphermox, one sec [17:31] cyphermox, so I have a library package that also includes a binary [17:31] debuild is failed on the shlibdeps step [17:31] because it can't find the library bundled in the package, that the binary references [17:32] so I added an override for dh_shlibdeps that specifies -l to try and pickup the library directly, but it's still failing [17:33] mitya57: sure go ahead! [17:33] cyphermox, http://pastebin.ubuntu.com/10175843/ [17:34] awe_: what's the exact error before you override dh_shlibdeps? [17:34] could that binary be split out to a -utils package or something? [17:34] it's part of the -dev package [17:35] here's the git tree: https://github.com/tonyespy/libiodata [17:35] so context, this is a library pulled from Sailfish [17:35] and originally part of MeeGo/Moblin/Maemo [17:36] and it's debian dir was seriously out-of-date [17:36] the error I get is can't find the libiodata.so.0 [17:38] what is /usr/bin/iodata-type-to-c++ used for? [17:39] assuming that's the c or c++ binary you're having trouble with [17:39] it compiles .type files into C++ headers/code [17:39] that allows C++ code to do structure io on pre-defined file types [17:40] cyphermox, here's the build error: http://pastebin.ubuntu.com/10175926/ [17:42] I'm pretty sure the dh_shlibdeps override is needed, and that I've just bungled the syntax in debian/rules === pgraner is now known as pgraner-afk [17:45] it seems to me like you would probably want to get that out of the -dev package completely, put it into a patch with the architecture it's built for, so that you can install just one -dev and multiple copies of the binary to be able to cross-compile things, that's probably going to help making where libiodata.so.0 is more evident to dh_shlibdeps. [17:46] I'm not using patches [17:46] that has nothing to do with patches [17:46] ok [17:47] so the binary is only used for development, so that's why it's in the -dev pkg [17:49] I think one problem you have is that the library appears to be in /usr/lib/.../iodata/ instead of /usr/lib/.../ directly [17:49] also libiodata.so.0..0 is weird [17:49] there is that, yeah [17:49] yes, I know... [17:49] re: the so.0..0 [17:49]