| infinity | tkamppeter: Component on that page lists the component from debian/control, which is a bit confusing. | 00:01 |
|---|---|---|
| infinity | tkamppeter: If you scroll down, you see it's in (universe) in the release pocket of vivid, etc. | 00:02 |
| tkamppeter_ | 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:26 |
| infinity | 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:27 |
| infinity | wgrant: What are the odds of making the Component field of +source/<package> either less confusing or not there at all? | 00:29 |
| wgrant | infinity: I think I filed a bug about that in 2006, let me see. | 00:29 |
| infinity | wgrant: This isn't the first time people have misinterpreted it. | 00:29 |
| infinity | Heh. | 00:29 |
| infinity | 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:30 |
| wgrant | Ah, not quite. | 00:31 |
| wgrant | https://bugs.launchpad.net/launchpad/+bug/93293 | 00:31 |
| ubottu | Launchpad bug 93293 in Launchpad itself "Details in source package portlet don't change without new upload" [Low,Fix released] | 00:31 |
| wgrant | Was nwhat I was thinking of. | 00:31 |
| wgrant | The portlet was fixed, but it made a reappearance in the main content, it seems. | 00:32 |
| infinity | wgrant: \o/ | 00:33 |
| infinity | wgrant: Hrm, it's not always wrong, either. That's even more confusing. | 00:34 |
| wgrant | infinity: It should usually be wrong. | 00:35 |
| infinity | wgrant: Looking at, say, poppassd, it displays universe, when I would have assumed it would say main (matching control). | 00:35 |
| infinity | wgrant: But I guess a poke at the code and where it's actually getting that value would be enlightening. | 00:35 |
| wgrant | infinity: Uploaded packages will show their original overrides. | 00:36 |
| infinity | wgrant: poppassd and openjpeg are both syncs, AFAICT. | 00:37 |
| infinity | wgrant: Oh, but poppassd predates syncs being a thing, so it's technically a manual upload. | 00:38 |
| wgrant | Yep. | 00:38 |
| infinity | s/syncs/copies/ | 00:38 |
| hallyn | 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:33 |
| infinity | hallyn: No. | 03:34 |
| sarnold | I thought that was default behaviour unless you set LD_BIND_NOW in your environment | 03:35 |
| infinity | hallyn: Unless by "linked" you mean "dlopened()". | 03:35 |
| sarnold | ohhh, that's just symbol resolution, not opening the libraries themselves. | 03:36 |
| infinity | sarnold: Yeah, I was in the middle of typing that, and my WiFi had a fit. | 03:36 |
| infinity | hallyn: ld.so loads all the objects it needs before jumping into the binary. | 03:37 |
| infinity | 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:38 |
| infinity | hallyn: Perhaps a real life example of the behaviour you think you're seeing and blaming on ld.so? | 03:39 |
| hallyn | 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 |
| hallyn | 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:44 |
| hallyn | and yeah we're not dlopening so that's not an issue | 03:45 |
| infinity | hallyn: /lib can't be a mount in any sane POSIX system. | 03:45 |
| infinity | 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:46 |
| hallyn | infinity: so long as initramfs mounts it i see no reason why it oculdn't | 03:47 |
| hallyn | 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 |
| hallyn | this is going into debian, so i expect to see all sorts of perverse setups :) | 03:48 |
| hallyn | infinity: thanks, so it sounds like i can ignore it. good news | 03:50 |
| infinity | 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) | 03:58 |
| hallyn | infinity: right, but cgmanager is going to umount anything it doesn't need (in a private namespace) after it starts | 04:00 |
| hallyn | 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 |
| hallyn | so the target can't be rmdir'd, and the source isn't totally freed | 04:01 |
| hallyn | so i'm thinking of doing https://github.com/hallyn/cgmanager/commit/cef2ea8d89ac329b9ce744266f235bad4d6151ed | 04:02 |
| infinity | hallyn: I guess you can't just stop cgmanager before the OS umounts at shutdown? :P | 04:04 |
| hallyn | there's actually a number of debian bugs open about this | 04:06 |
| infinity | hallyn: Or maybe I'm a bit confused about what's going on. | 04:06 |
| hallyn | aufs, xfce, onandon | 04:06 |
| hallyn | 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 <fail> | 04:07 |
| sarnold | hallyn: does that leak 'line' on the continue statements? | 04:07 |
| hallyn | sarnold: don't think so; getline will reuse it if len is large enough for the next line | 04:08 |
| sarnold | hallyn: aha, thanks | 04:08 |
| hallyn | oh, heh, but loop exit will | 04:08 |
| sarnold | hallyn: and, what's this "recursively umounted entries"? | 04:08 |
| infinity | hallyn: Err, kay, I clearly don't get why cgamanager is holding that mount open in the first place. | 04:08 |
| infinity | hallyn: Surely systemd doesn't have to do this same crazy "umount the world that I shouldn't have open anyway" thing? | 04:09 |
| hallyn | well, if /sys and /sys/fs/cgroup are both mounted and you umount -l /sys/, then /sys/fs/cgroup will be umounted | 04:09 |
| sarnold | hallyn: no kidding? :) cool. thanks. | 04:09 |
| hallyn | infinity: well systemd mounts / MS_SHARED. but yes it also had this problem | 04:10 |
| hallyn | 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:10 |
| hallyn | infinity: so anythhing which systemd spawns which then unshares mntns and mounte MS_PRIVATE wil hae the same problem | 04:11 |
| hallyn | (which cgmanager used to do; i switched it to MS_SLAVE for them; that doesnt' for sysvinit though0 | 04:11 |
| infinity | 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:12 |
| infinity | hallyn: Instead of worrying about if /lib might be on a USB stick on Joe User's weird setup. | 04:13 |
| hallyn | infinity: right that's basically what i do. walking through /proc/self/mountinfo and skipping anything i know i need | 04:13 |
| infinity | hallyn: But you don't necessarily even need / :P | 04:14 |
| infinity | hallyn: In a merged setup, you might need /usr and not / | 04:14 |
| infinity | hallyn: But if you just lazy umount them both, who cares. | 04:14 |
| hallyn | what is a merged setup? | 04:14 |
| infinity | hallyn: Merged-/usr, welcome to 5 years ago. | 04:14 |
| infinity | hallyn: Where /lib, /bin and /sbin are symlinks into /usr, and /usr can be (but usually isn't) a mountpoint. | 04:15 |
| hallyn | even so all i really need is /sys/fs/cgroup/cgmanager (which i created) and some target dirs for cgroup mounts, and /proc | 04:15 |
| hallyn | suppose i could create an empty dir, copy /sys/fs/cgroup/cgmanager into it, pivot, umount old_root, and proceed | 04:16 |
| hallyn | not sure whether that's better | 04:16 |
| infinity | 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:16 |
| hallyn | right, i'm doing lazy, cause i don't really care ,just don't want to pin it | 04:17 |
| * infinity nods. | 04:17 | |
| hallyn | (my inodes are pinning it already) | 04:17 |
| hallyn | hm | 04:17 |
| infinity | hallyn: A pivot chroot is probably cleaner than trying to umount everything systematically. | 04:17 |
| hallyn | grr but the other way is already coded : | 04:17 |
| infinity | hallyn: But if you go full chroot style, you end up with a duplicate libc in RAM, etc, which is less ideal. | 04:17 |
| hallyn | :) | 04:18 |
| hallyn | why would that happen? | 04:18 |
| hallyn | it's still the same inode, same page cache, no? | 04:18 |
| infinity | Or, you might. Depends on how smart we are about knowing that it's identical-but-from-elsewhere and deduping it. | 04:18 |
| infinity | hallyn: Oh, I'm thinking an old skool chroot, where it very much wouldn't be the same inode. :P | 04:18 |
| infinity | 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 |
| hallyn | yeah i don't need that | 04:19 |
| hallyn | cool, something to play with in the morning i think. | 04:19 |
| hallyn | thanks! | 04:19 |
| hallyn | ttyl | 04:19 |
| hyperair | what does upstart --user do that allows it to adopt orphaned childreN? | 04:20 |
| hyperair | i thought orphaned children just jump straight to pid1 | 04:20 |
| infinity | hyperair: Make a decent salary, and have no criminal record. | 04:20 |
| hyperair | infinity: :) | 04:21 |
| hyperair | that'll work | 04:21 |
| infinity | (no idea) | 04:21 |
| hyperair | lol | 04:21 |
| sarnold | hyperair: check out prctl(2), PR_SET_CHILD_SUBREAPER | 04:27 |
| hyperair | aha | 04:27 |
| hyperair | thanks | 04:27 |
| tmpRAOF | Bah. Kernel ppa doesn't have linux-tools builds :( | 04:32 |
| tmpRAOF | No perf for me until reboot. | 04:33 |
| RichiH | rbasak: ok, thanks | 05:10 |
| pitti | Good morning | 05:38 |
| pitti | 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:39 |
| pitti | cjwatson: ah, thanks anyway, in case we want to ever simplify this again | 05:40 |
| === work_alkisg is now known as alkisg | ||
| alkisg | 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:20 |
| infinity | 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:42 |
| infinity | tumbleweed: Before I kill it, this is the junk hanging around: http://paste.ubuntu.com/10169871/ | 07:43 |
| rbasak | pitti: no, I'm setting TMPDIR outside the test. "TMPDIR=... adt-run ...". That did work though. | 07:51 |
| pitti | rbasak: oh, you mean your host's /tmp is too small, not the testbed's? | 07:52 |
| rbasak | pitti: right. | 07:52 |
| rbasak | pitti: I'm on Canonistack. / is not that big. /mnt provides more space. | 07:52 |
| rbasak | Various things are symlinked to /mnt, but not /tmp. | 07:53 |
| pitti | *nod* | 07:53 |
| === liam_ is now known as Guest3630 | ||
| === kickinz1|afk is now known as kickinz1 | ||
| LocutusOfBorg1 | hi Laney can I try to merge inkscape from debian/eperimental? | 08:36 |
| rbasak | LocutusOfBorg1: there's already a merge bug on that. | 08:37 |
| rbasak | LocutusOfBorg1: bug 1416651. Looks like nobody's working on it right now though. | 08:38 |
| ubottu | bug 1416651 in inkscape (Ubuntu) "Please merge inkscape 0.91-2 from Debian unstable (main)" [Medium,Triaged] https://launchpad.net/bugs/1416651 | 08:38 |
| rbasak | 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 |
| LocutusOfBorg1 | wonderful | 08:38 |
| LocutusOfBorg1 | :) | 08:38 |
| LocutusOfBorg1 | thanks for the hint, I'll upload the debdiff here | 08:38 |
| rbasak | 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 |
| LocutusOfBorg1 | sure | 08:39 |
| LocutusOfBorg1 | :w | 08:39 |
| LocutusOfBorg1 | (damn focus) | 08:40 |
| === alkisg is now known as work_alkisg | ||
| LocutusOfBorg1 | now everybody knows I'm a VIM user, shame on me! :wq! | 08:42 |
| LocutusOfBorg1 | :) | 08:42 |
| infinity | LocutusOfBorg1: At least you're not a filthy Emacs user. | 08:43 |
| mlankhorst | or maybe he's doing an impersonation of a vim user to hide his emacsness | 08:43 |
| LocutusOfBorg1 | lol | 08:44 |
| LocutusOfBorg1 | I stopped using emacs after talking with its psychotherapist | 08:45 |
| LocutusOfBorg1 | :) | 08:45 |
| Laney | LocutusOfBorg1: yap | 09:04 |
| pitti | darkxst: uh, apparmor fails to start for you? | 09:55 |
| pitti | sudo journalctl -u apparmor | 09:55 |
| darkxst | pitti, apparently http://pastebin.com/zqBC4mtu | 09:58 |
| pitti | darkxst: hm, that means that it never reaches sysinit.target? | 09:59 |
| pitti | ah no, it's a Wants, not a Requires | 09:59 |
| darkxst | pitti, doesnt seem like something a glib update would trigger though ;( | 10:00 |
| pitti | darkxst: you have several hard disks/drives, would you mind adding your fstab? | 10:01 |
| darkxst | pitti fstab http://pastebin.com/Eddi1pia | 10:02 |
| darkxst | pitti, pretty sure ricotz hit this also | 10:04 |
| pitti | darkxst: I see something odd in the log indeed | 10:07 |
| pitti | /home gets mounted, then unmounted again | 10:08 |
| darkxst | pitti, why would it get unmounted? | 10:10 |
| darkxst | kernel? remounts ro, on errors, but nothing should unmount it? right? | 10:10 |
| pitti | 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:12 |
| darkxst | pitti, seems my laptop is not effected by this though it has a slightly simpler configuration | 10:16 |
| pitti | ok, we have some major kde uninstallability problem on i386 | 10:16 |
| pitti | ah, https://launchpad.net/ubuntu/+source/plasma-framework/5.7.0-0ubuntu1 FTBFS? | 10:18 |
| pitti | 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 |
| pitti | I think that's causing it | 10:19 |
| === work_alkisg is now known as alkisg | ||
| aeoril | 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:23 |
| aeoril | And apparently, I cannot type tonight | 10:24 |
| darkxst | aeoril, sbuild is great (I use it all the time) but not for tracking down bugs | 10:25 |
| Mirv | 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:25 |
| aeoril | darkxst why not? | 10:26 |
| darkxst | aeoril, its really slow for one | 10:26 |
| Riddell | pitti: I uploaded lots of kde frameworks yesterday | 10:26 |
| aeoril | 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:26 |
| Riddell | 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 |
| aeoril | darkxst yes, the logs on Launchpad show 20 minutes per build | 10:27 |
| pitti | Riddell: well, that'd be called "versioned build dependencies" to make it dep-wait properlY :) | 10:27 |
| pitti | Riddell: thanks | 10:27 |
| Riddell | pitti: we do version them | 10:28 |
| aeoril | darkxst do you think I should just manually change the build environment by altering the parameters passed to ./configure from the logs? | 10:29 |
| aeoril | *gleaned from the logs | 10:29 |
| darkxst | aeoril, that would be much faster! | 10:35 |
| aeoril | darkxst I am doing it now .... | 10:36 |
| darkxst | aeoril, and really just try what you think is right! | 10:37 |
| darkxst | no need to ask my approval ;) | 10:37 |
| aeoril | 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 |
| darkxst | sbuild is great for whats its designed for | 10:38 |
| Riddell | 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 |
| aeoril | darkxst what is it designed for? | 10:38 |
| pitti | Riddell: well, LP never retries failed buildss | 10:39 |
| darkxst | aeoril, bilding packages | 10:39 |
| pitti | Riddell: it only auto-retries depwaits | 10:39 |
| pitti | 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:39 |
| aeoril | 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 |
| darkxst | aeoril, I do all my dev work in git and jhbuild | 10:40 |
| pitti | Riddell: oh I see, it failed due to build dep uninstallability | 10:40 |
| Laney | jamespage: yo, is someone looking at the oslo/nova dep8 failures? | 10:40 |
| darkxst | then backport to the archive packages (and forward upstream where applicable) | 10:40 |
| jamespage | Laney, yes I am | 10:40 |
| jamespage | Laney, specifically nova | 10:41 |
| Laney | great! | 10:41 |
| aeoril | darkxst would jhbuild help me here? | 10:41 |
| jamespage | but will work through today | 10:41 |
| darkxst | aeoril, jhbuild doesnt work great outside of GNOME | 10:41 |
| Laney | thanks | 10:41 |
| aeoril | darkxst well, I am fiddling around with ./configure params for nwo - can't hurt - help me learn a bunch too ... | 10:42 |
| darkxst | aeoril, in fact it often doesnt work great under ubuntu at all, but they are bugs that need fixing anyway | 10:42 |
| darkxst | aeoril, wouldnt bother for a single package | 10:42 |
| aeoril | darkxst wouldn't bother doing what? | 10:43 |
| darkxst | jhbuild | 10:43 |
| aeoril | oh, ok | 10:43 |
| aeoril | darkxst thanks ... | 10:43 |
| Laney | I use jhbuild okay on ubuntu | 10:43 |
| Laney | recommend getting it from git instead of the package | 10:44 |
| darkxst | Laney, fedora don't link with --as-needed | 10:44 |
| Laney | so? | 10:44 |
| darkxst | that creates DSO errors | 10:45 |
| darkxst | and then there are usually other Ubuntu specific failures | 10:45 |
| Laney | not seen that | 10:45 |
| darkxst | but like I said these get fixed upstream | 10:45 |
| darkxst | since if not, they would just cause pain when doing the real packaging | 10:46 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| Riddell | 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 |
| pitti | Riddell: right, that's the most common case | 10:51 |
| pitti | 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 | 10:51 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| cjwatson | Mirv: done | 10:59 |
| cjwatson | 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:00 |
| Mirv | cjwatson: thanks! | 11:02 |
| === _salem is now known as salem_ | ||
| pitti | darkxst: do you happen to have a rough idea when this mount failure started? | 11:36 |
| pitti | darkxst: only with the recent glib update, or did it also happen earlier? | 11:36 |
| pitti | darkxst: I can't get this bug in a VM, but I do see it on my laptop indeed | 11:36 |
| darkxst | pitti, only with current ubuntu-desktop ppa | 11:37 |
| darkxst | goes away if I purge that | 11:37 |
| pitti | wow | 11:37 |
| pitti | well, it's a race condition, so anything could happen | 11:38 |
| darkxst | and/or gnome3-staging but alas that has the same packages copied from there | 11:38 |
| darkxst | pitti, not seen in a VM either but then they all have very standard configs parition wise | 11:44 |
| darkxst | where as my desktop has ~4 hdd's most with multiple partitions | 11:45 |
| pitti | darkxst: I created a VM with /home, /home/martin, and /srv on separate partitions, just like on the laptop | 11:49 |
| pitti | darkxst: anyway, I'll investigate with upstream, thanks | 11:50 |
| ypwong | 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 |
| ubottu | bug 1396429 in HWE Next "[Lenovo ThinkPad ?40 series] Wireless key cannot turn BT off" [High,Triaged] https://launchpad.net/bugs/1396429 | 11:50 |
| darkxst | pitti, ok, I'm off to bed | 11:51 |
| === MacSlow is now known as MacSlow|lunch | ||
| === marcusto_ is now known as marcustomlinson | ||
| aeoril | is there an easy way to tell the runtime dependencies of a particular binary? | 13:11 |
| aeoril | (google found nothing for me) | 13:11 |
| xnox | aeoril: ldd ? | 13:15 |
| xnox | 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 |
| aeoril | xnox ok, thanks | 13:16 |
| === MacSlow|lunch is now known as MacSlow | ||
| aeoril | xnox this also: objdump -p /path/to/program | grep NEEDED (from the ldd man page) | 13:39 |
| xnox | aeoril: same information, different representation. depends on your needs. | 13:40 |
| aeoril | xnox ok, thanks again ... | 13:41 |
| arges | alkisg: i'll review today | 13:46 |
| ogra_ | pitti, did one of your last systemd changes add a new user ? | 13:49 |
| pitti | ogra_: it added a new group ("input"); we talked about it the other day | 13:50 |
| pitti | no new user | 13:50 |
| ogra_ | pitti, right, i meant afterwards :) | 13:50 |
| ogra_ | P: Begin executing early chroot hooks... | 13:50 |
| ogra_ | /etc/group post-debootstrap hash doesn't match record | 13:50 |
| ogra_ | E: config/hooks/00-uid-gid-fix.chroot_early failed (exit non-zero). You should check for errors. | 13:50 |
| ogra_ | we have that on both, snappy and touch | 13:51 |
| ogra_ | one of the packages debootstrap installs has chnaged | 13:51 |
| pitti | ogra_: no, it's been ages since it added a new user | 13:51 |
| ogra_ | right | 13:51 |
| pitti | well, that'd be /etc/group again? | 13:51 |
| aeoril | what pasting website is preferred here? paste.ubuntu.com? | 13:51 |
| ogra_ | just wanted to make sure ... i usually trust your changelogs :) | 13:51 |
| ogra_ | i simply cant find anything on vivid-changes | 13:51 |
| pitti | ogra_: so that /etc/group change does sound like the "input" group? | 13:52 |
| pitti | or at least it could be? | 13:52 |
| ogra_ | it doesnt complain about /etc/group | 13:52 |
| pitti | ogra_: or do you get a mismatch on /etc/passwd too? (and is there a diff? | 13:52 |
| ogra_ | the input group change is long gone in :) | 13:52 |
| ogra_ | trhere is no diff at that point ... thats my issue | 13:52 |
| pitti | aeoril: kind of; it's what pastebinit defaults to in ubuntu; but it doesn't matter much really | 13:53 |
| ogra_ | (i'll add it but was hoping i could find the obvious change by looking at changes first) | 13:53 |
| pitti | ogra_: hm, what do you add then if there's no diff? | 13:53 |
| ogra_ | i mean there is no diff that gets dumped into the log :) | 13:53 |
| ogra_ | live-build/ubuntu-touch/hooks/99zz-check-uid-gid.chroot actually dumps a proper diff that shows what you need to change | 13:54 |
| ogra_ | but i never added the same code to live-build/ubuntu-touch/hooks/00-uid-gid-fix.chroot_early | 13:54 |
| ogra_ | which is where we fail atm | 13:54 |
| ogra_ | 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:55 |
| pitti | ah, I see; sorry, I'm not aware of a recent upload that added a new system user | 13:56 |
| pitti | but then again I stopped following -changes@ years ago | 13:56 |
| ogra_ | (i will add the diffing code there too, but that takes longer than i like :) ) | 13:56 |
| ogra_ | and sadly yesterday was KDE day ... -changes is spammed :P | 13:56 |
| === pgraner-afk is now known as pgraner | ||
| Riddell | how do you think I feel? I get all the build failures and I've been running retry --batch all day | 13:58 |
| pitti | whack-a-buildd | 13:59 |
| ogra_ | haha | 13:59 |
| aeoril | 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 |
| aeoril | 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:07 |
| aeoril | xterm does not exhibit the same problem in vim on trusty sarnold darkxst cjwatson | 14:28 |
| aeoril | rather, vim does not exhibit the same problem in xterm on trusty sarnold darkxst cjwatson | 14:36 |
| aeoril | 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:38 |
| cjwatson | 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 |
| aeoril | cjwatson sure, sorry to be a bother | 14:46 |
| rsalveti | ogra_: pitti: http://paste.ubuntu.com/10174068/ | 14:56 |
| rsalveti | it seems the systemd users got removed | 14:56 |
| rsalveti | was that expected? | 14:56 |
| pitti | no, it's not expected | 14:57 |
| pitti | /var/lib/dpkg/info/systemd.postinst creates them | 14:57 |
| rsalveti | hm | 14:58 |
| rsalveti | once the new livecd-rootfs gets published we will trigger another image and see | 15:05 |
| rsalveti | but that might be the difference | 15:05 |
| pitti | rbasak: so you discovered my s3kr1t way of checking whether anyone actually uses --timeout-factor :) | 15:14 |
| rbasak | :-) | 15:14 |
| rbasak | I do like the idea. | 15:14 |
| rbasak | Timeout -> moar time please | 15:15 |
| pitti | rbasak: while I'm at it, I should also add --warp-factor | 15:15 |
| rbasak | Don't really care what the previous timeouts wanted. | 15:15 |
| rbasak | So it's really tempting to use --timeout-factor over looking up default timeouts and then adjusting them. | 15:16 |
| rbasak | And thus I fell into your trap :) | 15:16 |
| ogra_ | rsalveti, i'm startin a build, seems livecd-rootfs is in | 15:17 |
| rsalveti | ogra_: great | 15:17 |
| rsalveti | ogra_: pitti: already failed: https://launchpadlibrarian.net/197314114/buildlog_ubuntu_vivid_i386_ubuntu-touch_FAILEDTOBUILD.txt.gz | 15:28 |
| rsalveti | and yeah, the same diff I got | 15:28 |
| rsalveti | no systemd users | 15:28 |
| pitti | 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 |
| rsalveti | yeah, systemd is gone in there indeed | 15:29 |
| pitti | (that'd be quite bad -- no logind and such) | 15:29 |
| ogra_ | rsalveti, but there is also a syslog user we dont have in the reference file | 15:30 |
| pitti | no libpam-systemd either | 15:30 |
| rsalveti | ogra_: oh, this is not in the end of the build | 15:30 |
| rsalveti | so I think systemd would be added later on | 15:31 |
| Laney | @pilot in | 15:31 |
| ogra_ | right | 15:31 |
| === 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 | ||
| rsalveti | the lack of the syslog user is probably what caused the failure | 15:31 |
| ogra_ | hmm, no, the order is just different | 15:31 |
| ogra_ | i guess we need more info :/ | 15:32 |
| ogra_ | the file created in 00-uid-gid-fix.chroot_early is not the one we md5sum | 15:33 |
| ogra_ | it is the file that needs to match *after* the build | 15:33 |
| ogra_ | aha | 15:35 |
| ogra_ | syslog:x:100:104::/home/syslog:/bin/false | 15:35 |
| ogra_ | vs syslog:x:100:103::/home/syslog:/bin/false | 15:35 |
| pitti | bah, just a 0.97% error :) | 15:36 |
| ogra_ | i assume we just want to update the md5sum | 15:36 |
| ogra_ | yeah | 15:38 |
| ogra_ | phablet@ubuntu-phablet:~$ md5sum foo | 15:39 |
| ogra_ | 9ebb1c3da5b0ad8f1d366528b32c97cb foo | 15:39 |
| ogra_ | thats what i get with the syslog user set to 103 | 15:39 |
| ogra_ | phablet@ubuntu-phablet:~$ md5sum foo | 15:39 |
| ogra_ | 5e8366ef9c178b62079468966f38ce5f foo | 15:39 |
| ogra_ | and that with it set to 104 | 15:39 |
| * ogra_ prepares a fix, but we'll need one more rebuild for /etc/group i guess | 15:40 | |
| xnox | kees: should chromeos switch to systemd? | 15:47 |
| * xnox is mostly done with porting ubuntu | 15:47 | |
| rsalveti | ogra_: yeah, that might be the issue | 15:47 |
| ogra_ | rsalveti, change uploaded ... lets see if thats sufficient ... but i guess /etc/group will need updating too | 15:49 |
| rsalveti | ogra_: we can keep going until we get a new image :-) | 15:52 |
| ogra_ | yeah | 15:52 |
| ogra_ | and improve the error output with each run | 15:52 |
| ogra_ | to make it easier next time | 15:52 |
| rsalveti | yeah | 15:52 |
| ogra_ | i guess i should also log the expected md5 | 15:52 |
| ogra_ | (i only added the computed one to this upload to be logged) | 15:53 |
| Odd_Bloke | 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 |
| ogra_ | but it might be moot since you have to edit the source anyway | 15:53 |
| Odd_Bloke | (If only so I don't have to rebuild the package in our PPA every time you bump the version :p) | 15:53 |
| ogra_ | juts make an MP :) | 15:54 |
| ogra_ | so someone can review :) | 15:54 |
| Odd_Bloke | ogra_: Cool, will do. | 15:56 |
| === alkisg is now known as work_alkisg | ||
| === Guest25083 is now known as rcj | ||
| didrocks | rsalveti: hey, how are you? | 16:21 |
| didrocks | 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:22 |
| rsalveti | didrocks: we're working on getting our kernels to be compatible with it still, ricmm is actively working on that | 16:23 |
| didrocks | rsalveti: do you think this will be done before Feature Freeze? | 16:23 |
| rsalveti | didrocks: what is the date for FF? | 16:24 |
| didrocks | rsalveti: Thursday 19th if I'm right | 16:25 |
| didrocks | rsalveti: so a week + 1 day :) | 16:25 |
| * didrocks rechecks the schedule | 16:25 | |
| rsalveti | didrocks: we hope so | 16:25 |
| rsalveti | we're actively working on it, so should know more by the beginning of next week | 16:25 |
| didrocks | rsalveti: mind if we sync up like next Tuesday then? | 16:25 |
| rsalveti | sure | 16:26 |
| didrocks | thanks a lot! good luck to you and ricmm :) | 16:26 |
| tumbleweed | infinity: urgh. I've seen that before | 17:15 |
| tumbleweed | I guess I could disable that test | 17:15 |
| === seb128_ is now known as seb128 | ||
| === willcooke_ is now known as willcooke | ||
| awe_ | cyphermox, hey could you give me a hand with a Debian packing problem I'm having? | 17:22 |
| cyphermox | awe_: sure, what's up? | 17:27 |
| cyphermox | if you describe the problem here, if I can't help then others surely will be able to :) | 17:27 |
| awe_ | cyphermox, one sec | 17:30 |
| awe_ | cyphermox, so I have a library package that also includes a binary | 17:31 |
| awe_ | debuild is failed on the shlibdeps step | 17:31 |
| awe_ | because it can't find the library bundled in the package, that the binary references | 17:31 |
| awe_ | so I added an override for dh_shlibdeps that specifies -l <dir> to try and pickup the library directly, but it's still failing | 17:32 |
| Mirv | mitya57: sure go ahead! | 17:33 |
| awe_ | cyphermox, http://pastebin.ubuntu.com/10175843/ | 17:33 |
| cyphermox | awe_: what's the exact error before you override dh_shlibdeps? | 17:34 |
| cyphermox | could that binary be split out to a -utils package or something? | 17:34 |
| awe_ | it's part of the -dev package | 17:34 |
| awe_ | here's the git tree: https://github.com/tonyespy/libiodata | 17:35 |
| awe_ | so context, this is a library pulled from Sailfish | 17:35 |
| awe_ | and originally part of MeeGo/Moblin/Maemo | 17:35 |
| awe_ | and it's debian dir was seriously out-of-date | 17:36 |
| awe_ | the error I get is can't find the libiodata.so.0 | 17:36 |
| cyphermox | what is /usr/bin/iodata-type-to-c++ used for? | 17:38 |
| cyphermox | assuming that's the c or c++ binary you're having trouble with | 17:39 |
| awe_ | it compiles .type files into C++ headers/code | 17:39 |
| awe_ | that allows C++ code to do structure io on pre-defined file types | 17:39 |
| awe_ | cyphermox, here's the build error: http://pastebin.ubuntu.com/10175926/ | 17:40 |
| awe_ | I'm pretty sure the dh_shlibdeps override is needed, and that I've just bungled the syntax in debian/rules | 17:42 |
| === pgraner is now known as pgraner-afk | ||
| cyphermox | 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:45 |
| awe_ | I'm not using patches | 17:46 |
| cyphermox | that has nothing to do with patches | 17:46 |
| awe_ | ok | 17:46 |
| awe_ | so the binary is only used for development, so that's why it's in the -dev pkg | 17:47 |
| Laney | I think one problem you have is that the library appears to be in /usr/lib/.../iodata/ instead of /usr/lib/.../ directly | 17:49 |
| Laney | also libiodata.so.0..0 is weird | 17:49 |
| cyphermox | there is that, yeah | 17:49 |
| awe_ | yes, I know... | 17:49 |
| awe_ | re: the so.0..0 | 17:49 |
| awe_ | there's more stuff to fix | 17:49 |
| awe_ | right now my goal for this sprint was to get this in good enough shape to drop into a PPA so that we use for testing | 17:50 |
| awe_ | there's definitely more cleanup to be done | 17:50 |
| awe_ | Laney, but that said... if I build on my desktop with the library package installed. The build works and shlibdep succeeds | 17:51 |
| awe_ | when I build a device without the library package installed it's failing | 17:51 |
| awe_ | which is why I assumed an override of dh_shlibdeps with -l specified was required... | 17:51 |
| awe_ | as I mentioned to cyphermox earlier, the debian dir that was part of this project dates from Moblin v2 days ( '07-08 ) | 17:52 |
| awe_ | s/I build a device/I build on a device/ | 17:52 |
| awe_ | ( note, I'm building on a device as qmake doesn't support cross-builds, and I don't want to deal with a cmake conversion just yet ) | 17:53 |
| bdmurray | cjwatson: any luck with that publisher bug? vivid's contents.gz is about four days old | 18:31 |
| cjwatson | bdmurray: erk, I totally forgot, sorry. added an asana task to remind myself | 18:37 |
| bdmurray | cjwatson: thanks! | 18:37 |
| arges | hallyn: tych0 : bug 1384751 would be good to verify at some point as its blocking any other lxc updates from utopic. | 18:39 |
| ubottu | bug 1384751 in lxc (Ubuntu Utopic) "checkpoint restore fails with /usr/lib/x86_64-linux-gnu/lxc/lxc-restore-net: not found" [High,Fix committed] https://launchpad.net/bugs/1384751 | 18:39 |
| tych0 | arges: ah ha. | 18:40 |
| tych0 | arges: will look right now, sorry about that | 18:41 |
| tych0 | i totally missed it | 18:41 |
| arges | tych0: its all good. figured I'd ping : ) | 18:41 |
| tych0 | arges: what do i do if it wroks? | 18:41 |
| tych0 | arges: i guess add some tag, but i'm not sure what that tag would be :) | 18:41 |
| arges | tych0: just change the tag to 'verification-done' | 18:42 |
| tych0 | arges: ok, will do | 18:42 |
| * tych0 boots a vm | 18:42 | |
| arges | tych0: then that lets us SRU-team people know if its ready to be released: http://people.canonical.com/~ubuntu-archive/pending-sru.html | 18:42 |
| Laney | @pilot out | 18:46 |
| === 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: | ||
| === pgraner-afk is now known as pgraner | ||
| smoser | is it just me or are other people seeing an increase in 'hash sum mismatch' | 19:06 |
| sarnold | smoser: seems no worse than usual | 19:07 |
| tych0 | i just saw one myself | 19:08 |
| cyphermox | awe_: drop the space between -l and the argument, and make the path $(CURDIR)/debian... etc. | 19:09 |
| smoser | i didn't know if it was just me, as my system now has i386 enabled, so i'm double as likely. | 19:09 |
| * awe_ trying | 19:09 | |
| cyphermox | awe_: still, feels to me like that binary doesn't belong with the development files | 19:09 |
| awe_ | cyphermox, sure... it *could* be split into another binary package; again I want to get over this hump first | 19:10 |
| cyphermox | sure | 19:10 |
| awe_ | the new package would probably the same exact failure | 19:10 |
| awe_ | thanks for the help! | 19:10 |
| tych0 | arges: ok, done. sorry about the delay :( | 19:14 |
| arges | tych0: nice. No problem, thanks | 19:14 |
| tych0 | smoser: nah, i just saw one in utopic-updates on amd64; i don't usually see them, either | 19:16 |
| === rickspencer3_ is now known as rickspencer3 | ||
| dupondje | https://bugs.launchpad.net/ubuntu/+source/armory/+bug/1388396 | 19:52 |
| ubottu | Launchpad bug 1388396 in armory (Ubuntu) "Delete armory package from ubuntu" [Undecided,New] | 19:52 |
| dupondje | can anyone give his optinion about this? | 19:52 |
| dupondje | also, armory recommands bitcoind, but bitcoind isn't even in ubuntu ... | 19:53 |
| dupondje | so it makes armory completely useless atm | 19:53 |
| arges | dupondje: that would be useful information to put into that bug. can you add that info there? | 19:58 |
| dupondje | vivid syncs from sid? And bitcoind is in sid? So why it isn't synced? | 20:01 |
| dupondje | blacklisted? | 20:01 |
| jtaylor | yes its blacklisted | 20:01 |
| arges | dupondje: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt | 20:01 |
| dupondje | guess we better kick armory also then | 20:04 |
| === roadmr is now known as roadmr_afk | ||
| awe_ | cyphermox, your suggestions plus an additional $(DEB_HOST_MULTIARCH) in the path did the trick | 20:17 |
| awe_ | thanks | 20:17 |
| cyphermox | right, it needs to be a full path | 20:17 |
| darkxst | aeoril, of the bug is in gnome-terminal, its like libvte | 20:27 |
| aeoril | darkxst here is my latest log: http://paste.ubuntu.com/10177137/ | 20:29 |
| === rickspencer3_ is now known as rickspencer3 | ||
| tkamppeter | caribou, trusty and utopic SRUs for CUPS are accepted now. | 21:06 |
| === roadmr_afk is now known as roadmr | ||
| chiluk | bdmurray, bug 1416906 should be ready for sponsorship now | 21:58 |
| ubottu | bug 1416906 in samba (Ubuntu Trusty) "force user no longer works" [Medium,In progress] https://launchpad.net/bugs/1416906 | 21:58 |
| === pgraner is now known as pgraner-afk | ||
| bdmurray | chiluk: there's a current samba SRU that needs verifying on trusty... | 22:03 |
| chiluk | bdmurray, bug num? | 22:03 |
| bdmurray | bug 1412909 | 22:05 |
| ubottu | bug 1412909 in samba (Ubuntu) "Please raise Suggests for lib{pam,nss}-winbind to Recommends in trusty" [Medium,Triaged] https://launchpad.net/bugs/1412909 | 22:05 |
| sladen | Ubuntu Font user of the day: http://www.weetabix.co.uk/ | 22:14 |
| Unit193 | sladen: I thought http://www.ubuntu.travel/ was pretty good. :P | 22:16 |
| robert_ancell | jsalisbury, thanks for your help with bug 1416277 - do you need any more information from me? | 22:17 |
| ubottu | bug 1416277 in linux (Ubuntu) "toshiba_acpi: Unknown key 158" [Medium,Confirmed] https://launchpad.net/bugs/1416277 | 22:17 |
| chiluk | bdmurray, .. I'm working on verifying it right now... | 22:25 |
| bdmurray | chiluk: alright, thanks | 22:27 |
| sladen | Unit193: Ubuntu *and* Ubuntu-Title | 22:41 |
| chiluk | bdmurray, looks like it's still broken | 22:45 |
| chiluk | I did this on canonistack n a precise system install samba and libpam-winbind | 22:46 |
| chiluk | Upgrade to trusty | 22:46 |
| chiluk | Observe that libnss-winbind is not installed | 22:46 |
| chiluk | bdmurray, I'm not sure if it was user error on my part, *(not having proposed archives enabled in the right places?).. I enabled the proposed archives while in precise, and it seems to have pulled the trusty-proposed package after the upgrade, but it didn't install libnss-winbind.. | 22:47 |
| === salem_ is now known as _salem | ||
| bdmurray | chiluk: how did you upgrade? what command | 22:51 |
| chiluk | do-release-upgrade | 22:52 |
| bdmurray | that'll disable propose I think you need to manually edit sources and run apt-get update then apt-get dist-upgade | 22:53 |
| chiluk | bdmurray, already tried. | 22:53 |
| chiluk | but the the upgrade did give me the right version of samba. | 22:54 |
| chiluk | bdmurray, it was real quick to check with canonistack. | 22:54 |
| bdmurray | chiluk: okay, I'll test it then | 22:55 |
| chiluk | I know it's not the news either of us wanted to hear | 22:55 |
| === iulian_ is now known as iulian | ||
| bdmurray | chiluk: works for me - http://pastebin.ubuntu.com/10179397/ | 22:58 |
| chiluk | bdmurray, did you start all the way from precise? | 23:00 |
| bdmurray | (precise-amd64)root@impulse | 23:01 |
| bdmurray | it's a precise chroot | 23:01 |
| chiluk | that's really odd. | 23:01 |
| chiluk | I'll try once more in case I'm just insane | 23:01 |
| bdmurray | to be clear I edited /etc/apt/sources.list and added proposed and s/precise/trusty/ | 23:02 |
| bdmurray | then ran apt-get update and apt-get dist-upgrade | 23:02 |
| chiluk | ah ... I did differently. | 23:03 |
| chiluk | bdmurray.. I edited sources to add proposed. | 23:03 |
| chiluk | but then simply ran do-release-upgrade | 23:03 |
| chiluk | maybe the do-release-upgrade is getting in the way somehow? | 23:03 |
| bdmurray | Yes, I believe ubuntu-release-upgrader disables -proposed. | 23:04 |
| chiluk | bdmurray, that's not what I'm seeing. | 23:07 |
| === bluesabre is now known as bluesabr3 | ||
| chiluk | it came up with the correct -proposed version of samba | 23:07 |
| === bluesabr3 is now known as b1uesabre | ||
| === b1uesabre is now known as bluesabre | ||
| chiluk | bdmurray, I'm running the test again on canonistack.. in case I'm insane.. | 23:09 |
| bdmurray | chiluk: okay, I'm testing it with do-release-upgrade myself | 23:09 |
| bdmurray | slangasek: bug 1412909 is strangely verifiable via apt-get dist-upgrade but not with do-release-upgrade. It'd seem to be a bug in the update-manager, right? | 23:15 |
| ubottu | bug 1412909 in samba (Ubuntu) "Please raise Suggests for lib{pam,nss}-winbind to Recommends in trusty" [Medium,Triaged] https://launchpad.net/bugs/1412909 | 23:15 |
| chiluk | bdmurray, I take it all back...it worked this time. | 23:17 |
| chiluk | I'm not sure what I could have done wrong. | 23:17 |
| chiluk | actually let me do the reboot. | 23:17 |
| chiluk | very odd. | 23:17 |
| chiluk | bdmurray .. well it worked this time.. | 23:18 |
| chiluk | I'm going to chalk that up to fat-fingering it the first time. | 23:19 |
| chiluk | sorry about the unwarranted fire drill bdmurray .. | 23:21 |
| chiluk | on that note I think I'm going to call it a day. | 23:21 |
| psusi | cjwatson, mind if I pester you a bit about ubiquity and partman? I'm investigating a bug where you get a pop up complaining about booting in efi mode but your disk looks like it is set up for bios mode. This happens because the init.d/efi script is run *after* the visual.d scripts which create the partitions, and the efi script sees the newly created partitions as not being an esp | 23:25 |
| sarnold | psusi: you were cut off at "being an esp" | 23:26 |
| psusi | sarnold, that was the last word ;) | 23:26 |
| sarnold | psusi: the entire last word? :) | 23:27 |
| psusi | yea.. ESP = EFI System Partition | 23:27 |
| sarnold | aha :) | 23:27 |
| psusi | the other problem seems to be that ubiquity is running partman in the background and so when the question pops up, ubiquity proceeds to the next screen after a few seconds and if you haven't clicked either ok or cancel in that time, the window hangs | 23:28 |
| psusi | so it feels almost like ubiquity is running different parts of partman in parallel or at the wrong time and its all racey | 23:28 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| jsalisbury | robert_ancell, I don't think I need any addition info for bug 1416277 . I just need to do some more research. | 23:34 |
| ubottu | bug 1416277 in linux (Ubuntu) "toshiba_acpi: Unknown key 158" [Medium,Confirmed] https://launchpad.net/bugs/1416277 | 23:34 |
| robert_ancell | jsalisbury, ok, thanks | 23:35 |
| cjwatson | psusi: I'm not really working on this at the moment, and I'm not in a place where I can look at code, but firstly visual.d scripts don't create partitions, and secondly ubiquity may just need an extra question handler there in its partman module - the way it runs some other things in parallel with partman is perfectly intentional | 23:41 |
| psusi | cjwatson, looking at the partman log it appeared to me that it ran the visual.d scripts, and they "created" the partitions ( sending the commands to parted_server ), but did not commit them to disk yet, and then init.d/efi runs and "finds" the newly created partitions | 23:43 |
| psusi | ( I threw a set -x into the efi script and can see it finding the partitions but they don't yet exist on disk, but partman's log clearly shows the create partition commands prior to init.d/efi ) | 23:44 |
| cjwatson | visual.d merely collects information. please investigate harder | 23:45 |
| aeoril | darkxst I took a shortcut and just copied the binaries from trusty to vivid and vice versa, then ran them. Here is the result: http://paste.ubuntu.com/10179845/ Any thoughts? | 23:46 |
| aeoril | darkxst Also, I was thinking of trying to run/compile then run using the vivid libvte on trusty and vice versa, but they have differnt filenames and versions so not sure how to accomplish that | 23:47 |
| cjwatson | I'm on a phone, though, this is ridiculously cumbersome. if you want me to investigate then please mail me an unedited log - it's easier than trying to guess here | 23:47 |
| psusi | sure | 23:47 |
| cjwatson | then I can explain the reasoning | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!