| === wedgwood is now known as wedgwood_away | ||
| === vibhav is now known as Guest48005 | ||
| === Guest48005 is now known as vibhav | ||
| === jono is now known as Guest19637 | ||
| psusi | cjwatson, last time uds was in Orlando and I met you in person you were on a laptop, but watching the videos this uds, I wonder... do you use a "real fucking keyboard"? I keep hearing loud key clicks and it seems to be you. | 03:36 |
|---|---|---|
| infinity | psusi: He just types very violently. | 03:44 |
| === marrusl is now known as marrusl_afk | ||
| m4n1sh | ev: ping, have a question related to whoopsie | 04:14 |
| pitti | Good morning | 05:48 |
| pitti | Good morning | 05:49 |
| doko | slangasek, online? | 06:10 |
| slangasek | doko: heya | 06:10 |
| pitti | slangasek: AFAIK the pkexec patch in http://launchpadlibrarian.net/105173889/policykit-1_0.104-2_0.104-2ubuntu1.diff.gz should be upstreamed, too, right? | 06:17 |
| pitti | or is that Debian/Ubuntu specific somehow? | 06:17 |
| slangasek | pitti: hmm, I can't think of any way that it's Debian/Ubuntu-specific. I'd say it should be upstreamed, yeah | 06:18 |
| pitti | slangasek: do you want to send that bugs.fd.o-wards with some background, or shall I file it and CC you in case there's further questions? | 06:23 |
| pitti | slangasek, stgraber: what did you do to make logind create the user cgroups properly? when I install logind and the pam module, logind errors wit "Failed to create cgroup name=systemd:/user/joe: No such file or directory", and passes that error to the PAM module which then aborts, too | 06:56 |
| pitti | (I don't see any relevant failure in strace) | 06:58 |
| dholbach | good morning | 07:44 |
| YokoZar | Can someone illuminate how gstreamer0.10-plugins-ugly managed to get multiarched before one of its dependencies? (libcdio) From what I can tell it's never been coinstallable, and I'm wondering how such a thing could get past -proposed | 07:53 |
| SunStar | the -ugly | 07:58 |
| === tkamppeter_ is now known as tkamppeter | ||
| tjaalton | tkamppeter_: hey, cups is not cleaning up it's old conffiles, like with the introduction of cups-daemon I now have two logrotate files for cups, and cron is spamming me because of that. there's also /etc/pam.d/cups left over | 08:13 |
| OdyX | tjaalton: please report a bug against cups-daemon on Debian/experimental, that's certainly valid there. | 08:20 |
| OdyX | tjaalton: ah, wait, that's handled by 666367fc1d9fcdf18b71abf2254f8c12edc67f6b already, by tkamppeter | 08:23 |
| tjaalton | OdyX: oh, cool | 08:25 |
| === slacker_1l is now known as slacker_nl | ||
| OdyX | tjaalton: the problem I guess is that Ubuntu got intermediary versions | 08:45 |
| pabs3 | anyone know why the samba update hasn't been accepted into precise-updates? its two weeks past the date on https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=samba | 08:49 |
| === smb` is now known as smb | ||
| oly | hi, can anyone tell me if there is a way to test why webapp icons are not loaded ? | 09:00 |
| oly | it a common problem i have hit, where i put .png files on the system but just get a placeholder image on the left bar, | 09:01 |
| oly | i have no idea why, or if this is logged some where from what i can tell the paths are all correct, and i have compared against other webapps like the bbc one but mine does not work | 09:02 |
| pitti | stgraber, slangasek: ah, we need to mount a tmpfs on /sys/fs/cgroup, so that logind can write into it | 09:03 |
| pitti | stgraber, slangasek: I guess that woudl go into /lib/init/fstab ? | 09:03 |
| infinity | pabs3: I was about to apologize for not reviewing it, then realized I uploaded it. | 09:05 |
| pabs3 | infinity: yeah, its uploaded but not accepted | 09:07 |
| tjaalton | looks like the hotkey for enabling wifi on a dell laptop I have doesn't work on raring, and it defaults to being off. is there a way to fake the key so I could enable wifi again? | 09:43 |
| tjaalton | hmm according to dmesg the key works.. | 09:44 |
| tjaalton | oh hell, now it's working :P | 09:45 |
| tjaalton | i'll get me coat.. | 09:45 |
| pitti | slangasek, stgraber: with http://paste.ubuntu.com/5592725/ it works OOTB, but needs a fix to udev to suppress udev-acl; we could also add /sys/fs/cgroup/ mounting to /lib/init/fstab, WDYT? | 10:01 |
| mbiebl | # systemd replaces udev-acl entirely, skip if active | 10:08 |
| mbiebl | TEST=="/sys/fs/cgroup/systemd", TAG=="uaccess", GOTO="acl_end" | 10:08 |
| mbiebl | pitti: that's in the latest 70-udev-acl.rules | 10:09 |
| pitti | mbiebl: yes I know, but with above dynamic mounting in logind's upstart job /sys/fs/cgroup/ appears too late | 10:09 |
| pitti | mbiebl: that's what I mean: if we mount it in /lib/init/fstab, it's early enough and that rule works | 10:09 |
| pitti | mbiebl: and if we keep the late mounting, I'll drop the TEST from that rules | 10:09 |
| mbiebl | couldn't you just mount the cgroups in logind itself | 10:10 |
| pitti | same thing -- udev coldplugging happens before, and coldplugged devices get tagged with both | 10:10 |
| pitti | also, systemd already mounts it, I don't want to create incompatibilities; so that patch only mounts it if it isn't already | 10:11 |
| mbiebl | pitti: maybe we could convince rleigh to add similar bits to mountkernfs.sh | 10:28 |
| jamespage | Laney, thanks for fixing oslo-config | 10:28 |
| Laney | nps | 10:28 |
| pitti | mbiebl: systemd mounts that directory by itself, though | 10:28 |
| mbiebl | sure | 10:28 |
| pitti | mbiebl: so it only becomes relevant with a split, and then we need to check that systemd's mounting doesn't collide with that | 10:29 |
| mbiebl | im talking about the sysvinit+logind part | 10:29 |
| pitti | mbiebl: oh, mountkernfs.sh wouldn't be run by systemd I guess | 10:29 |
| mbiebl | correct | 10:29 |
| mbiebl | so if upstart does the mount in /lib/init/fstab | 10:29 |
| mbiebl | sysvinit in mountkernfs.sh | 10:29 |
| pitti | then everything should work indeed | 10:30 |
| mbiebl | and systemd itself | 10:30 |
| mbiebl | all should be fine | 10:30 |
| mbiebl | (in theory) | 10:30 |
| yofel | cjwatson: hi, I just did a sanity check on the kubuntu packageset and noticed that nepomuk-widgets is missing there even though it's on our images (libnepomukwidgets4). Does that need a manual override? | 10:40 |
| yofel | I also added plasmate to supported if you could refresh the set | 10:40 |
| cjwatson | it's in desktop-core, presumably bindings | 10:41 |
| cjwatson | I guess both that and nepomuk-widgets are functionally maintained by Kubuntu so should be overridden | 10:41 |
| yofel | it's part of the KDE SC, so it is maintained by us | 10:42 |
| cjwatson | s/nepomuk-widgets/nepomuk-core/ - but that's actually already overridden | 10:43 |
| yofel | no, those are 2 different things | 10:43 |
| cjwatson | er yes I know | 10:43 |
| cjwatson | I was saying that both belong in the kubuntu packageset | 10:43 |
| yofel | hm, I got the set with "./edit-acl -P kubuntu -S raring query" | 10:44 |
| yofel | and that doesn't show nepomuk-widgets | 10:44 |
| cjwatson | sorry I'm being confusing due to not enough coffee and unfamiliar keyboard | 10:44 |
| cjwatson | I understand your request and am acting on it | 10:44 |
| yofel | hehe | 10:44 |
| cjwatson | nepomuk-widgets moved | 10:45 |
| yofel | thanks! | 10:45 |
| cjwatson | and I'll refresh the autogenerated data now | 10:45 |
| xnox | "your call is important to us, please hold the line, while we familiarise ourself with a new keyboard." =))))))))))) | 10:51 |
| cjwatson | at least it isn't French layout :-P | 10:53 |
| seb128 | \o/ azerty :p | 10:53 |
| seb128 | you guys just don't know what you are missing ;-) | 10:54 |
| cjwatson | the ability not to type numbers? | 10:54 |
| seb128 | that's what the keypad is for :p | 10:54 |
| cjwatson | I'd use UK layout on this US keyboard except of course it has one fewer key and it's kind of useful to be able to type \| | 10:55 |
| ogra_ | so french people dont use laptops ? or are french laptops extra wide to fi a numpad on ? | 10:58 |
| didrocks | on an US keyboard with an azerty layout, you are missing * and µ. The latter, well, don't really used it since I finished my study. The first one is more worrying :) | 10:58 |
| ogra_ | *fit | 10:58 |
| didrocks | ogra_: I always use "shift" | 10:58 |
| seb128 | ogra_, numbers are overrated :p | 10:58 |
| ogra_ | and then a numpad magically slides out of the side of your laptop ? | 10:59 |
| ogra_ | :) | 10:59 |
| === Sweetsha1k is now known as Sweetshark | ||
| cjwatson | ogra_: subscribe | 11:00 |
| xnox | ogra_: it's in the cd-tray ;-) | 11:02 |
| ogra_ | haha | 11:04 |
| ev | m4n1sh: pong | 11:06 |
| zequence | I'm having some trouble debugging why the Ubuntu Studio ISO is not building. Was wondering if anyone could take a look, and perhaps point me in the right direction. Ever since I edited the seeds (I did some restructuring - and I'm new at this) we get these type of build logs http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntustudio-dvd/20130306/livecd-20130306-amd64.out | 11:15 |
| zequence | the seeds are at lp:~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.raring | 11:16 |
| cjwatson | odd. easiest way to debug it is probably going to be to attempt a matching local build | 11:19 |
| cjwatson | I'll have a go at that | 11:19 |
| yofel | cjwatson: hm, did the auto-refresh finish? nepomuk-widgets got added fine (and emacs24 for some reason), but plasmate not and if I did a mistake I don't see it. | 11:20 |
| zequence | cjwatson: Thanks a bunch | 11:21 |
| cjwatson | yofel: the data generation did, but actually putting it into LP needs another step | 11:21 |
| * cjwatson runs that | 11:22 | |
| yofel | ah ok, sorry for impatient then ^^ | 11:22 |
| yofel | *for being | 11:22 |
| pabs3 | infinity: so, who should I ping about the samba update? | 11:23 |
| cjwatson | yofel: done now | 11:26 |
| yofel | cjwatson: perfect, thanks a lot! | 11:28 |
| infinity | pabs3: Someone in ubuntu-sru who isn't me, since we don't self-review our own uploads. | 11:29 |
| infinity | pabs3: But I'll work on the queue tomorrow to shrink it, so the ones left over become more obvious to others. :P | 11:29 |
| mlankhorst | :D | 11:29 |
| pabs3 | infinity: cool, thanks :) | 11:29 |
| zequence | cjwatson: Do you have some nice resources on how to set up a local build system, that matches Ubuntus'? | 12:14 |
| cjwatson | https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html | 12:14 |
| zequence | cjwatson: Ah, great! | 12:14 |
| === MacSlow is now known as MacSlow|lunch | ||
| === _salem is now known as salem_ | ||
| zequence | cjwatson: I suspect that /usr/share/livecd-rootfs/live-build/auto/config has something to with it. Didn't realize that needed to be adjusted in case of a restructuring of the seeds. | 13:20 |
| zequence | I've removed some seed files, and restructured | 13:20 |
| zequence | Also changed the metas | 13:21 |
| zequence | All though.. I've kept the old metas as transitional | 13:22 |
| zequence | So, I guess that was not it then.. | 13:22 |
| zequence | Forgot about the transitional metas | 13:23 |
| cjwatson | zequence: It'll be about task names rather than metapackages. I'll take care of it | 13:25 |
| cjwatson | It's trying to look up the ubuntustudio-audio-plugins task and failing | 13:25 |
| zequence | cjwatson: Aha. Ok. Yes, I removed it as a task. | 13:26 |
| cjwatson | Micah half-fixed it but didn't quite do it all | 13:26 |
| jdstrand | xnox: re consolekit> ack. search started, though it'll take a while | 13:27 |
| zequence | cjwatson: What I was trying to do was to make sure ubuntustudio-audio-plugins did not show up on the alternate installer as a task | 13:27 |
| xnox | jdstrand: awesome, thanks. | 13:27 |
| cjwatson | zequence: Yes, I updated tasksel the other day to match your changes | 13:27 |
| zequence | cjwatson: So, the seeds are correct then? Where is the error? | 13:28 |
| xnox | jdstrand: do we not have hadoop cluster of the unpacked sources? | 13:28 |
| cjwatson | zequence: livecd-rootfs 2.110 (just uploaded) should fix it | 13:28 |
| zequence | cjwatson: Thanks. | 13:28 |
| xnox | jdstrand: i recompressed all debs of all the archive in about 8 hours using tiny instances and juju. | 13:29 |
| xnox | i guess it would still take a while for grepping. | 13:29 |
| jdstrand | xnox: not that I'm aware of | 13:29 |
| xnox | ok. and spinning one up just for consolekit sounds a bit over-engineered =) | 13:30 |
| jdstrand | it has been a goal to have the ability for anyone to do this sort of grep without a local mirror, but alas, long todo list | 13:30 |
| xnox | jdstrand: well in the cloud one does have almost infinite bandwidth to a mirror on the same network. So in my case I was doing `apt-get download` well one could be doing `apt-get source` and do a grep. | 13:31 |
| === MacSlow|lunch is now known as MacSlow | ||
| xnox | and then it's just a question of how many instances one has available and partitioning the job between them. | 13:32 |
| * jdstrand nods | 13:32 | |
| jdstrand | it would probably be fun to work on (please refer to previous said long todo list :) | 13:33 |
| xnox | =)))))) | 13:33 |
| pitti | slangasek, stgraber: FYI, these systemd modifications plus my embarassing hack, plus a logind-ified polkit are in https://launchpad.net/~ubuntu-core-dev/+archive/logind | 13:33 |
| * xnox ELOOPDETECTED | 13:33 | |
| jdstrand | hehe | 13:33 |
| ogra_ | yay embarassing hacks ! | 13:35 |
| zul | didrocks: ping | 13:45 |
| njin | xnox, are you working on the new ubiquity ? | 13:53 |
| njin | hallo, sorry ^^ | 13:54 |
| xnox | njin: i'm hacking on ubiquity, what's up? =) | 13:57 |
| njin | I'm writing the testcase for upgrade ubuntu step from cd , but when I run it , it requre everything (timezone, layout,ecc.) are you planning to adjust this step ' | 13:59 |
| njin | xnox:^^ | 13:59 |
| njin | hmmm, it require password too | 14:00 |
| njin | * '/? | 14:00 |
| xnox | njin: yes, it does at the moment. Since you are reinstalling afresh, while preserving some data. | 14:02 |
| njin | xnox, then is not planned any modification on these steps ? | 14:03 |
| xnox | njin: i'm not working on that part of the installer at the moment. Our preffered way to upgrade people is via upgrade-manager / do-release-upgrade. | 14:05 |
| xnox | and it's not high priority at the moment either for others on the installer team. | 14:05 |
| xnox | njin: do you have thoughts on how to improve it? | 14:05 |
| njin | xnox: jump directly to the upgrade without asking nothing , but well, if it is not an urgent thing i can write down the testcase without problems, Thanks | 14:09 |
| xnox | njin: ok. | 14:09 |
| infinity | xnox: All that data should be easily scrapable from the installed system with minimal effort. user/password being the only sticky one, but surely in-place upgrades preserve passwd/shadow/group/gshadow anyway, or it's not much of an "upgrade"... | 14:14 |
| stgraber | pitti: ah right, here I've got cgroup-lite installed so /sys/fs/cgroup is already a tmpfs as cgroup-lite mounts it as one | 14:15 |
| pitti | stgraber: ah, that explains it | 14:15 |
| stgraber | pitti: if we decide to mount a tmpfs on /sys/fs/cgroup from mountall, we'd need to make sure we don't break cgroup-lite in the process | 14:15 |
| stgraber | (which may try to double-mount the path) | 14:16 |
| pitti | right, we need to avoid that | 14:16 |
| * xnox we have volunteer to fix up ubiquity-ugprade. Thanks a lot infinity =))))) | 14:16 | |
| pitti | stgraber: but we need to check that also if logind mounts it in the upstart job | 14:16 |
| pitti | stgraber: i. e. if logind's job starts before cgroup-lite's | 14:16 |
| pitti | stgraber: I take it it mounts it in cgroup-lite's upstart/init script? | 14:16 |
| xnox | infinity: true, but there are tweaks and bugfixes needed, apperantly we were wiping mythtv mysql database on in-place upgrade and other similar bugs. | 14:16 |
| xnox | it is fragile at the moment. | 14:17 |
| infinity | xnox: Yeah, the "fix" for the mythtv bug highlighted a massive design flaw, really. | 14:17 |
| pitti | stgraber: it's a race condition either way, of course | 14:17 |
| infinity | xnox: The assumption that none of /var is valuable, except a few whitelisted directories is bound to be very fragile. | 14:17 |
| xnox | infinity: i haven't looked into it to be honest. Where was the fix? Oh =) | 14:18 |
| infinity | xnox: Honestly, I'd be happier if we just removed the option from the installer, but others may disagree. | 14:18 |
| xnox | bdmurray wants to remove it =) | 14:18 |
| stgraber | pitti: I think both should check if /sys/fs/cgroup is already mounted and only mount it if it's not. There still could be a race if both check+mount run at the exact same time, but that should be very unlikely | 14:19 |
| xnox | infinity: i'd be happy to remove it, if we have a way to preseed "keep /home partition unformatted" and or "wipe everything, but preserve /home" but it's more or less same can of warms. | 14:19 |
| xnox | s/warms/worms/ | 14:19 |
| infinity | xnox: Of course, the irony is that, for all the reasons it's an awful way to upgrade a complex desktop system, code very very similar to that may be an ideal way to upgrade phone/tablet installations. | 14:19 |
| stgraber | pitti: though I'm not opposed to having this part of our default mountpoints, configured as a very small tmpfs (similar to /run/lock) and mounted by mountall (/lib/init/fstab) so that it's done before anything else | 14:19 |
| pitti | if [ -n "`grep /sys/fs/cgroup /proc/mounts`" ]; then | 14:20 |
| pitti | urgh | 14:20 |
| xnox | infinity: well at the single-image-update session we are leaning to limit our self and make the core-os image read-only, that is less fragile to update, yet still can break the rest of the user-space. | 14:20 |
| pitti | stgraber: ^ that's what /bin/cgroups-mount does | 14:20 |
| pitti | stgraber: mountpoint -q would certainly be more efficient, but it does the job | 14:20 |
| stgraber | pitti: ah good, so cgroup-lite DTRT. So we could simply copy/paste that to the pre-start for logind I guess | 14:21 |
| infinity | xnox: Hrm? Running a union filesystem, then? | 14:21 |
| pitti | stgraber: see the pastebin, I do something liek that | 14:21 |
| infinity | xnox: That brings in a bunch of other bugs. | 14:21 |
| xnox | infinity: no, no unions. But the handwaving technology will teach dpkg about multiple databases of installed packages such that it all just works (tm) | 14:23 |
| xnox | ps. duct tape sold separately. | 14:23 |
| infinity | xnox: That doesn't instill confidence. But, uhm. Okay. | 14:23 |
| stgraber | pitti: I remember having some weirdness happening with mountpoint disagreeing on whether something was actually a mountpoint, but /sys/fs/cgroup isn't one of those weird cases, so it's definitely cleaner than the grep | 14:23 |
| xnox | infinity: stgraber is assignee, so expect lxc technology and edubuntu logo to sneak in. | 14:24 |
| * infinity notes that having UDS double-booked with another conference on the other side of the planet was less than ideal for him. | 14:25 | |
| infinity | I'll catch up next week, I guess. | 14:25 |
| psusi | say, who do you talk to about the single signon service being broken? even when I click the support link and select problems logging on, I just get a submit link that doesn't take any information and just goes straight to thanks, we'll be in touch shortly... wtf? | 14:29 |
| dobey | psusi: #canonical-isd | 14:30 |
| mitya57 | Laney: for the record, pyxdg cannot be in sync with Debian because don't have set_default_menu.diff, but Debian should have it | 14:45 |
| mitya57 | *we don't have | 14:46 |
| === wedgwood_away is now known as wedgwood | ||
| * mitya57 wonders if we are freezing today | 14:50 | |
| xnox | mitya57: i believe we are. standard time. | 14:51 |
| Laney | mitya57: hmm, its dropping wasn't mentioned in the merge - that's weird | 14:51 |
| Laney | I can't see why that patch would cause Ubuntu any problems though | 14:51 |
| mitya57 | Laney: it is mentioned in seb128's earlier changelog entry | 14:52 |
| Laney | so the "remaining changes" missed that one | 14:52 |
| mitya57 | yes | 14:52 |
| mitya57 | looks like you are right, it just adds a fallback so shouldn't cause any harm | 14:53 |
| Laney | but the menu-xdg dep is gone now | 14:53 |
| Laney | in Debian | 14:53 |
| mitya57 | dholbach: looks like we missed the chance to upload the new ubuntu-packaging-guide :) | 14:55 |
| mitya57 | apart from that, I'm ready to the freeze | 14:55 |
| mitya57 | ah, and I also have bug 1152007 ... | 14:55 |
| ubottu | bug 1152007 in python-secretstorage (Ubuntu) "Sync python-secretstorage 0.9.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1152007 | 14:55 |
| seb128 | Laney, mitya57: sorry, I tend to copy the previous merge's summary as a start point, I must have forgotten to update it with the extra diff added in between | 14:56 |
| tumbleweed | mitya57: you have until 8pm | 14:57 |
| Laney | mitya57: I generally tend to like it when sync requests say /why/ the sync is being requested | 14:58 |
| Laney | like some compelling new features / bug fixes / ... | 14:58 |
| ev | bdmurray: heads up: https://bugs.launchpad.net/daisy/+bug/1152206 | 14:58 |
| ubottu | Launchpad bug 1152206 in Daisy "Repair overcounts" [Undecided,New] | 14:58 |
| mitya57 | tumbleweed: it has NEW binaries, so we missed it | 14:59 |
| tumbleweed | mitya57: in the queue before freeze is ok (historically) | 14:59 |
| Laney | yeah, should be fine | 14:59 |
| tumbleweed | oh, debian New queue. historically, that was OK too | 14:59 |
| tumbleweed | but of course, the debian new queue is MASSIVE atm | 14:59 |
| mitya57 | tumbleweed: we can upload it to Ubuntu, and later make a Debian upload | 15:00 |
| Laney | s/later/simultaneously/ | 15:00 |
| xnox | yeah, I'd like boost1.53 =) | 15:00 |
| tumbleweed | buy your favorite ftp-master beer :P | 15:00 |
| mitya57 | Laney: s/simultaneously/when I finish the Python 3 port/ | 15:01 |
| Laney | is that more of a blocker for debian than us? | 15:01 |
| === chuck_ is now known as zul | ||
| === kentb-out is now known as kentb | ||
| mitya57 | Laney: it's a blocker for "upstream" release, but yes, we can upload it to Debian if we find Andrew SB | 15:02 |
| * Laney decides to try sponsor-patch again (does it work for syncs?) | 15:02 | |
| tumbleweed | yes | 15:02 |
| * mitya57 is updating the bug description | 15:02 | |
| * tumbleweed debates uploading a pypy pre-2.0 snapshot (it gained ARM JIT support) | 15:04 | |
| * mitya57 updated the description | 15:08 | |
| Laney | merci | 15:09 |
| === marrusl_afk is now known as marrusl | ||
| mitya57 | Laney: thanks! | 15:10 |
| zul | mterry: hey | 15:10 |
| cjwatson | psusi: keyboard> I have a new laptop that has a rather clickier keyboard than the previous one | 15:21 |
| psusi | lol | 15:21 |
| cjwatson | and yeah, I'm not the most delicate of typists :-) | 15:22 |
| mterry | zul, hi | 15:25 |
| zul | mterry: we should be good for python-json-patch now | 15:25 |
| mterry | zul, I thought we were already good (I approved it yesterday) | 15:28 |
| zul | mterry: cool thanks | 15:30 |
| mitya57 | Laney: thanks again, and enjoy http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/?view=log | 15:39 |
| Laney | I *do* enjoy! | 15:39 |
| bdmurray | barry: did you ever look at bug 1094218? the most recent comment is interesting. | 15:43 |
| ubottu | bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes" [Medium,Confirmed] https://launchpad.net/bugs/1094218 | 15:43 |
| sforshee | slangasek, cjwatson: do either of you have any idea why we'd hang while booting when efivarfs fails to mount? | 15:48 |
| barry | bdmurray: i'll take a look now | 15:59 |
| mitya57 | dholbach: I've ported add-languages to Python 3, feel free to upload :) | 16:10 |
| barry | mitya57: \o/ | 16:10 |
| dholbach | mitya57, good work! :) | 16:11 |
| dholbach | mitya57, I'm in the middle of 5 things right now - mind pinging somebody else to sponsor it? | 16:11 |
| * dholbach hugs mitya57 | 16:11 | |
| mitya57 | anybody able to upload ubuntu-packaging-guide? ^^ | 16:15 |
| * mitya57 hugs dholbach back | 16:16 | |
| mitya57 | bdrung ^^ | 16:16 |
| === Tonio__ is now known as Tonio_aw | ||
| barry | bdmurray: comments added | 16:32 |
| bdmurray | barry: thanks | 16:42 |
| barry | bdmurray: let's see what they say ;) | 16:42 |
| brendand | do we not patch dch to allow specifying launchpad bugs for --closes? | 16:45 |
| brendand | or is there an alternative version available? like 'uch', heh | 16:46 |
| * tumbleweed has a shell wrapper around dch, called uch :P | 16:51 | |
| user99999 | hello | 17:29 |
| BenC | cyphermox: Re: NM bug, the driver is not at fault | 17:42 |
| BenC | It is a static 10G connection, doesn't support auto-negotiation, not does it report link status (if it's up, it's carrier is reported as linked) | 17:42 |
| BenC | Many other drivers also do this because the underlying hardware doesn't have link detection | 17:42 |
| xnox | BenC: we love powerpc =) would you want to push for lts hwe? or are you interested in raring only? | 17:44 |
| BenC | xnox: If raring releases next month, I'm not too concerned about back-porting :) | 17:44 |
| xnox | BenC: =) heh, touche. | 17:45 |
| BenC | xnox: precise would need lots of extras (qemu, installer, cdimage updates) to be worth it, and I'm not sure the effort is warranted | 17:45 |
| === stokachu_ is now known as stokachu | ||
| xnox | sure. | 17:45 |
| BenC | xnox: but I appreciate the support | 17:46 |
| === directhe` is now known as directhex | ||
| xnox | BenC: =) np, yw. | 17:47 |
| slangasek | sforshee: because a missing mount point for an optional mount is ignorable, but a failed mount is an error; mountall doesn't know which virtual mounts are "important" or not, and indeed if you're booting under efi and you don't mount efivarfs, bootloader installs / upgrades won't DTRT | 18:03 |
| slangasek | sforshee: what made the mount fail for you? | 18:03 |
| sforshee | slangasek, it's a kernel bug in 3.9 that also got into 3.8 stable | 18:05 |
| * slangasek nods | 18:05 | |
| sforshee | there's a fix coming down the pipe, just wondered why the machines couldn't continue booting | 18:05 |
| slangasek | sforshee: because mountall doesn't presume to know which mounts are important; consider if /proc failed to mount and it carried on booting | 18:06 |
| slangasek | /proc is more important than efivarfs, but they're both important and mountall doesn't play favorites | 18:06 |
| sforshee | slangasek, okay. When this happened to me I got nothing but a blank screen. Shouldn't we at least display some kind of error message? | 18:06 |
| slangasek | (TBH, if you told me that we *should* play favorites, I'm not sure I have a way to do that in mountall today; but if you think efivarfs failures should be non-fatal, I could look into that) | 18:08 |
| slangasek | sforshee: well, that's tricky, because the dependency chain for showing prompts to the user is virtualfs -> udev -> plymouth | 18:08 |
| slangasek | we probably *should* say something on console too | 18:08 |
| sforshee | slangasek, I definitely think what happens now isn't very good | 18:09 |
| sforshee | I don't feel qualified to say whether or not efivarfs is critical, but it seems to me like it wouldn't be | 18:10 |
| slangasek | for comparison, here's the full list of 'optional' filesystems that mountall deals with in this particular way; none of which have been reported as a problem before now: http://paste.ubuntu.com/5593851/ | 18:10 |
| slangasek | I do think we want a message on console. Can you file a bug against mountall for this? | 18:11 |
| sforshee | slangasek, sure | 18:11 |
| cjwatson | As slangasek says, there are some hidden issues if you then try to upgrade the boot loader - in particular if you're running in secure boot mode the lack of efivarfs will (currently) have the effect that a boot loader upgrade will silently install an unsigned boot loader and your *next* attempt to boot will crash and burn | 18:12 |
| sforshee | cjwatson, yeah that would be a problem | 18:12 |
| cjwatson | I say "currently" because this is something we've agreed to change anyway, but ... | 18:12 |
| slangasek | sforshee: related bug: bug #610869 | 18:14 |
| ubottu | bug 610869 in mountall (Ubuntu) "mountall ignores nofail mount option" [Medium,Triaged] https://launchpad.net/bugs/610869 | 18:14 |
| slangasek | (so, if we really wanted to ignore the failure, we would need to fix that bug first) | 18:15 |
| slangasek | pitti: polkit forwarding to bugs.fd.o> I would be grateful if you would file that bug and CC me | 18:16 |
| sforshee | slangasek, bug #1152274 | 18:17 |
| ubottu | bug 1152274 in mountall (Ubuntu) "filesystem mount failures during boot halt boot with a blank screen" [Undecided,New] https://launchpad.net/bugs/1152274 | 18:17 |
| slangasek | sforshee: cheers | 18:17 |
| === deryck is now known as deryck[lunch] | ||
| === zyga_ is now known as zyga | ||
| smoser | psusi, ping. | 18:36 |
| psusi | smoser: pong | 18:37 |
| smoser | hey. | 18:37 |
| smoser | my query today is reguarding your comments on eatmydata | 18:37 |
| smoser | do you have that work collected anywhere? | 18:37 |
| psusi | I filed a bug report... let me see | 18:38 |
| smoser | my interest is for use in cloud-images. when a stock cloud-image is booted, quite often the first thing that is done is a slew of packages installed... | 18:38 |
| psusi | bug #1126314 | 18:38 |
| ubottu | bug 1126314 in debootstrap (Ubuntu) "Debootstrap is very slow. Please use eatmydata to fix this." [Undecided,New] https://launchpad.net/bugs/1126314 | 18:38 |
| smoser | and often that is orchestrated by cloud-init. if it was easy to do, cloud-init could utilize that path to make that initial install happen faster (as nothing user-data worrysome has happened at that point) | 18:39 |
| psusi | yep, that's the idea | 18:39 |
| smoser | at very least, i guess cloud-init should invoke apt-get update with --force-unsafe-io | 18:39 |
| slangasek | I thought we were using dpkg --force-unsafe-io for install/bootstrap? | 18:39 |
| slangasek | ah, for apt-get | 18:39 |
| psusi | we do, but that does very little | 18:39 |
| jtaylor | its less effective | 18:39 |
| smoser | we do for install and bootstrap. | 18:39 |
| mlankhorst | even with --force-unsafe-io it still flushes some updates synchronously | 18:40 |
| psusi | still flushes /most/... that option gets rid of rather few syncs | 18:40 |
| slangasek | hmm | 18:40 |
| cyphermox | BenC: ok, then with the logs you added to the bug I'll circle back and send it upstream for fixin' | 18:41 |
| smoser | psusi, did you (or is there already) a obvious/easy way to use eatmydata? | 18:41 |
| psusi | I tried to post a patch a year or two back to fix it and it was rejected by the dpkg maintainers and they said to use eatmydata instead, since that would also get rid of any syncs that happen as a result of the maintainer scripts | 18:41 |
| slangasek | well, that's true, but dpkg is the main offender :P | 18:41 |
| smoser | ah. i see more data in debian bug | 18:42 |
| slangasek | I guess cjwatson may weigh in on the bug | 18:42 |
| psusi | I'm not sure what you mean... I patched debootstrap to forcibly add the package to the required list so it gets unpacked right away, then set the LD_PRELOAD environment variable so it gets used during the rest of the bootstrap | 18:42 |
| psusi | cjwatson suggested adding the LD_PRELOAD to in-target for the rest of d-i to leverage it | 18:42 |
| * smoser chuckles at the idea of filing MIR for eatmydata, but that would be necessary for cloud-image usage. | 18:43 | |
| jtaylor | I use eatmydata for all my installs since its available, it significantly reduces the time, usually takes longer to type in your credentials and stuff | 18:43 |
| psusi | also required for the debootstrap patch | 18:44 |
| psusi | to be priority:required ( or forced there by debootstrap ) it has to be in main | 18:45 |
| smoser | ok. so heres an opportunity for everyone to laugh at the ignorance of smoser. | 18:46 |
| smoser | but if i have an install and have data i care about on a different filesystem than my OS (where dpkg is writing to) | 18:47 |
| smoser | then why would i want or care for dpkg to call fsync for me. | 18:47 |
| smoser | mostly its just ensuring that 100% reproducible data gets written to its target in that case. | 18:47 |
| psusi | the idea is that if the power goes out while you are installing or upgrading, you don't corrupt your dpkg database, or end up with packages that are partially upgraded and thus, horribly broken | 18:48 |
| smoser | yeah, that makes sense. but if i've separated OS data (extremely reproducible) from non-OS data, i have increased risk of data i cannot reproduce by using eatmydata for apt. | 18:50 |
| psusi | that reminds me, I guess the next step to that MIR is to add it to a seed | 18:51 |
| psusi | I'm not following | 18:52 |
| marrusl | hello! i have a question about old gnome libraries (specifically: libgnome-desktop-2-17 and libgnomeprint (and printui)). Can one safely assume they'll at least be in the archives (if not main) for a very long time? | 18:52 |
| psusi | what does apt have to do with your music and video collection? ;) | 18:52 |
| smoser | psusi, it has nothing to do with it. thats what i'm saying. | 18:53 |
| lifeless | psusi: if this is for image creation why not do it on tmpfs? | 18:53 |
| smoser | i dont really care about fsync() on data that i can reproduce. | 18:53 |
| psusi | lifeless: this is for normal installation in my case, and cloud images in smoser's | 18:53 |
| smoser | outside of time recovering, i dont lose anything. | 18:53 |
| psusi | you can't readily reproduce the dpkg status database without reinstalling, and a half upgraded package can leave the system unbootable, so your average user wants to make sure those don't happen... | 18:54 |
| smoser | lifeless, interesting comment at http://glandium.org/blog/?p=1169 | 18:56 |
| smoser | " It might just be btrfs. And the best part yet is that since sync() is global, even when running pbuilder over, say, tmpfs, it doesn’t change a damn thing." | 18:56 |
| smoser | but i think that might be wrong. | 18:57 |
| psusi | dpkg doesn't yse sync()... it uses fsync() and sync_file_range() | 18:58 |
| smoser | psusi, yeah, thats what iw oudl have thought | 18:58 |
| lifeless | so something else might be calling sync | 18:58 |
| lifeless | it only takes on maintainer script :) | 18:59 |
| lifeless | or say updating a database that calls sync | 18:59 |
| psusi | I think someone at some point a few years back suggested having it use one sync() instead of a dozen fsyncs() and the response to that was no, since sync() is global it would flush a bunch of unrelated writes | 18:59 |
| lifeless | probably want to instrument it and find out where it is coming from | 18:59 |
| psusi | it's coming from dpkg ;) | 18:59 |
| lifeless | what dpkg actually needs is barriers | 18:59 |
| psusi | right, but there's no user space api for them | 18:59 |
| lifeless | yeah. sadface. | 19:00 |
| lifeless | psusi: I thought dpkg uses fsync and sync_file_range. | 19:00 |
| lifeless | psusi: so I'm saying that that blog author is on crack, or has something *else* calling sync() :) | 19:00 |
| smoser | lifeless, thats what i think too. | 19:01 |
| psusi | lifeless: or it may have been written when they were trying to use sync() in dpkg instead of fsync and sync_file_range | 19:01 |
| lifeless | psusi: 2010-10, we can check that | 19:06 |
| psusi | I also found a kernel bug the other day that is hurting things too... iirc, dpkg uses sync_file_range to attempt to initiate background writeout early, then calls it later with the flag to wait until the writeout has finished... seems the kernel implementation was still doing a synchronous write without the wait flag | 19:06 |
| psusi | I think the hope was that it could unpack all of the files in a single pakcage, initiating writeout on each file, then doing one wait at the end, and this was supposed to be the best way to get both speed and safety... but with the kernel treating every individual file's non blocking sync_file_range as a blocking sync, that's got to hurt the performance considerably | 19:08 |
| psusi | let's see here, what seed should eatmydata be added to? | 19:10 |
| slangasek | psusi, lifeless: or we could just declare the kernel filesystem designers to be on crack, and require data=ordered semantics for all filesystems we support in Ubuntu? :) | 19:18 |
| psusi | data=ordered *is* the default | 19:21 |
| lifeless | slangasek: its metadata out of order that hurts isn't it? | 19:22 |
| slangasek | psusi: data=ordered is the *default*, but all the stupid tricks that userspace software is using these days to enforce syncing (including dpkg, and firefox) is effectively a workaround for filesystems *not* using that default | 19:23 |
| slangasek | lifeless: data=ordered is what ensures that the data is written before the metadata | 19:23 |
| slangasek | (in ext4 terminology) | 19:23 |
| psusi | slangasek: no... filesystems do use that default, and the workarounds are to deal with the fact that there is no api to express to the kernel that this file should be synced first, *then* renamed | 19:24 |
| slangasek | but this is only a default for ext4, users have the ability to change it; and xfs and btrfs don't give this guarantee | 19:24 |
| slangasek | psusi: you don't *need* to express "sync, then rename" if data=ordered is in effect | 19:24 |
| slangasek | which is why I'm saying we should renegotiate this contract with the kernel | 19:24 |
| psusi | yea, you do, that's why dpkg is doing so much syncing | 19:25 |
| slangasek | no, it's not | 19:25 |
| slangasek | dpkg is doing this *because it can't rely on the default filesystem options* | 19:25 |
| lifeless | ping, pong, ping, pong | 19:25 |
| lifeless | so did ext4, during the terror release, not have that default? | 19:25 |
| psusi | there are no nfilesystem options to fix it | 19:25 |
| lifeless | what was with the 0 length files... | 19:25 |
| lifeless | IIRC it was directory content being considered not file metadata, and not being ordered. | 19:26 |
| psusi | the zero length files happened when people were using data=writeback | 19:26 |
| slangasek | so what we should do, instead of making this the userspace's problem and making everything slower as a result, is to enforce data=ordered as an architecture requirement for the OS and homedir filesystem | 19:26 |
| slangasek | lifeless: correct; for a brief period, data=ordered was not the default | 19:26 |
| psusi | no slangasek, data=ordered does not fix the problem | 19:27 |
| psusi | now I would argue that it *should*, but it doesn't... | 19:27 |
| slangasek | psusi: you admit that dpkg is trying to ensure that the data is written to disk before the rename. This is exactly what data=ordered gives you, with no further userspace acrobatics. | 19:28 |
| psusi | nope, it doesn't | 19:28 |
| slangasek | psusi: that is the DEFINITION of data=ordered. Prove otherwise. | 19:29 |
| psusi | see the big huge arguments between ted tso and the dpkg maintainers 2 years back ;) | 19:29 |
| SunStar | nothing you can paste? | 19:29 |
| slangasek | I was there for the argument; I'm not going to waste my time rereading it | 19:30 |
| slangasek | I'm quoting the definition of data=ordered from the manpage, the burden of proof is yours | 19:30 |
| * SpamapS wonders if the solution isn't just "cheaper SSDs" | 19:31 | |
| slangasek | SpamapS: that's a bandaid | 19:31 |
| psusi | slangasek: I agree that it how it should work, but the reason they added all the syncing to dpkg is because it doesn't | 19:31 |
| slangasek | psusi: citation needed. | 19:32 |
| SpamapS | slangasek: a pretty good one :) | 19:32 |
| lifeless | psusi: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt | 19:32 |
| lifeless | psusi: auto_da_alloc | 19:32 |
| slangasek | SpamapS: except for all the cases where an SSD isn't fit for purpose, or you have so much data that the I/O itself (rather than the disk write) becomes a bottleneck | 19:33 |
| lifeless | psusi: thats the thing ted added | 19:33 |
| lifeless | psusi: after every developer everywhere called ext4 crack :) | 19:33 |
| slangasek | SpamapS: and "cheaper" != "free"; it's still a crap situation for all your existing hardware | 19:33 |
| psusi | lifeless: yea, and then the dpkg devs complained because it didn't work, and ted told them they were doing it wrong, add more syncs | 19:34 |
| SpamapS | one might view existing hardware as a liability if it complicates one's software. | 19:34 |
| lifeless | psusi: I don't recall that; can you point me at the thread? | 19:34 |
| psusi | looking for it now... | 19:34 |
| slangasek | SpamapS: we don't need to complicate the software, we just need to get a sane contract for userspace | 19:36 |
| slangasek | data=ordered, which Linux userspace had assumed for over a decade *was* that contract because it was the only behavior ext{2,3} provided, would be sane | 19:36 |
| slangasek | leave data=$other for domain-specific usage, but keep it the heck away from the OS filesystem | 19:37 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| === ajmitch_ is now known as ajmitch | ||
| === deryck[lunch] is now known as deryck | ||
| frafu | Hi, I am a member of the onboard development team. We just released an update of Onboard, the onscreen keyboard shipping by default with Ubuntu, that includes new features also targeted to the nexus 7. I have packaged it for raring. Could anybody with the necessary upload rights please put it into main before feature freeze kicks in? The necessary files are all available here: | 19:50 |
| frafu | https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1152282 | 19:50 |
| ubottu | Launchpad bug 1152282 in onboard (Ubuntu) "Onboard update (version 0.99~alpha2~tr1371) available for raring" [Undecided,New] | 19:50 |
| micahg | frafu: I was going to ask, any reason why you're not at beta since today is feature freeze, or is the alpha effectively feature frozen? | 19:51 |
| frafu | We are calling it alpha because it still misses a few features like the possibility to select a different language than the system language. | 19:54 |
| frafu | But you can consider it as feature frozen, as we intend to provide updates to it without adding new features. | 19:56 |
| micahg | frafu: ok, I was just concerned with someone not release quality ending up in raring | 19:57 |
| psusi | slangasek, lifeless: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009#147 | 19:58 |
| ubottu | Debian bug 605009 in dpkg "serious performance regression with ext4" [Important,Fixed] | 19:58 |
| slangasek | psusi: he's not talking about data=ordered. | 19:59 |
| slangasek | he's *explicitly* talking about things that aren't data=ordered. | 19:59 |
| psusi | no, he's saying that no matter what mount option you use, you can not rely on rename() to leave you with either before or after file over a crash, unless you fsync first, which is why that's what dpkg does now... a fwe comments above, the dpkg maintainer was hoping to just make nodelalloc the default and take all the syncs back out | 20:00 |
| slangasek | "fsync() has always been the only guarantee that files would be on disk" - absolutely correct, and absolutely irrelevant to the question at hand. | 20:01 |
| psusi | the question at hand is how to make sure rename doesn't leave you with the new, empty file | 20:01 |
| psusi | the answer is you fsync, not you use data=ordered | 20:01 |
| slangasek | yes, and *data=ordered does that* | 20:01 |
| slangasek | and nothing in the mail you link to contradicts this | 20:01 |
| psusi | the mail is ted saying you have to use fsync, full stop... not use data=ordered | 20:02 |
| slangasek | NO | 20:02 |
| slangasek | you have to use fsync IF YOU WANT TO ENSURE THE DATA IS WRITTEN TO DISK | 20:02 |
| slangasek | which is NOT what we are trying to ensure | 20:03 |
| slangasek | we are trying to ensure that the metadata is not changed BEFORE the data is written to disk | 20:03 |
| slangasek | this is exactly what Ted has gotten wrong - he's failed to understand what userspace apps actually need in the common case | 20:04 |
| psusi | a few comments up from there, the dpk gmaintanier said what we require is that after a crash, the file is either the old version, or the new version... not the new version, but with all zeros because the data has not been flushed yet | 20:04 |
| slangasek | correct | 20:05 |
| slangasek | fulfilling this requirement in no way involves a guarantee that the file has been written to disk | 20:05 |
| slangasek | it only involves a guarantee of the *order* of writing things to disk | 20:05 |
| psusi | right... that's all dpkg cares about... but according to ted, there is no way to do that other than to fsync | 20:06 |
| micahg | frafu: I"ll try to upload it if no one beats me to it, but I have 4 things in my queue ahead of it | 20:06 |
| slangasek | psusi: no, that's not what Ted said | 20:06 |
| psusi | i.e. data=ordered doesn't take care of it | 20:06 |
| frafu | <micahg> There are still a few points that might be a bit rough, like the Small layout, that needs a bit of rework to call it really ready for release, but generally, this release represents a good improvement compared to the version currently available in main. | 20:06 |
| slangasek | fsync() is a guarantee that the file gets written to disk, which we explicitly /don't/ care about | 20:07 |
| psusi | slangasek: right.. so you get more than you want with fsync()... ted's saying too bad... a rename() without the fsync does NOT give the required behavior, except as an accident on ext3... | 20:07 |
| micahg | frafu: ok, well, keep in mind that you still have about 6 weeks for polish before final freeze | 20:08 |
| slangasek | psusi: "except as an accident on ext3 because ext3 had data=ordered semantics" | 20:08 |
| slangasek | this is the key point | 20:08 |
| psusi | and so does ext4, yet you still have to fsync | 20:08 |
| slangasek | Ted doesn't *want* to give a data=ordered guarantee, therefore he's discounting that in the argument | 20:08 |
| slangasek | no, you don't have to fsync if you have ext4 with data=ordered | 20:09 |
| slangasek | but you have to fsync because you don't *know* if you have data=ordered | 20:09 |
| psusi | then why did ted not say you either have to fsync, OR use data=ordered? he said you have to fsync, period. on any fs, with any mount options. | 20:09 |
| slangasek | no, he said "you have to use fsync, period" because he doesn't want userspace apps making assumptions about filesystem options | 20:10 |
| slangasek | which is a reasonable position for him to take | 20:11 |
| slangasek | provided that we actually agree on what the baseline filesystem semantics should be, which we do not. :) | 20:11 |
| psusi | then why did the dpkg maintainers not just say to hell with it, if people use data=writeback, that's their problem? | 20:11 |
| slangasek | because the dpkg maintainers are equally conservative | 20:11 |
| slangasek | and it's not the dpkg maintainers' purview to try to make that decision | 20:12 |
| psusi | he sure seemed to want to just set the default mount options to sane values and take out the syncs | 20:12 |
| slangasek | it needs to be a system-level decision, not an application-level decision | 20:12 |
| lifeless | psusi: thats what the option I pointed you at is for, it's the 'workaround' Ted put in. | 20:12 |
| psusi | lifeless: nodelalloc just makes sure you don't end up with a zero byte file... you still end up with a file full of garbage | 20:13 |
| lifeless | psusi: thats not the option | 20:13 |
| psusi | whihc one are you talking about then? | 20:13 |
| lifeless | psusi: auto_da_alloc is the option | 20:13 |
| lifeless | psusi: its the one that ties rename + file contents together. | 20:14 |
| lifeless | psusi: that + data=ordered gives you file data + rename or no file data and no rename | 20:14 |
| lifeless | psusi: as a logical consequence | 20:14 |
| psusi | I seem to rmeember some discussion about it not being reliable | 20:15 |
| psusi | i.e. didn't always work | 20:15 |
| slangasek | and AIUI from that, auto_da_alloc is the default | 20:15 |
| lifeless | slangasek: that is my understanding too | 20:17 |
| frafu | <micahg> Sorry, we just found a bug entering the password in unity-greeter for the nexus. If you have not uploaded it already, it might be better to wait and try to get it in through a feature freeze exception. | 20:20 |
| smoser | psusi, so with eatmydata... | 20:20 |
| psusi | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009#157 | 20:20 |
| ubottu | Debian bug 605009 in dpkg "serious performance regression with ext4" [Important,Fixed] | 20:20 |
| smoser | if i: eatmydata apt-get install postgres | 20:20 |
| psusi | he seemed to interpret ted the way I did... thuogh there was no reply to that... | 20:20 |
| smoser | postgres will start on installation, right? and be running with eatmydata preload. right? | 20:20 |
| frafu | Sorry for any inconvenience. | 20:20 |
| micahg | frafu: up to you, if you can make it feature frozen in a day or two might be worth waiting for the exception (I'm down to 3 ahead of it ATM) | 20:20 |
| psusi | smoser: hrm... the postinst doesn't spawn the daemon directly thoguh right? it has upstart do it | 20:21 |
| smoser | and startstopdaemon probably does similar | 20:21 |
| smoser | oh wait. | 20:22 |
| smoser | hm.. | 20:22 |
| psusi | though I guess the old sysv init scripts did directly spawn the daemon didn't they? | 20:22 |
| frafu | <micahg> What do you mean by waiting for the exception? That is better going through the exception process in one or two days? | 20:23 |
| micahg | frafu: I mean requesting an exception if you're close in a few days rather than waiting weeks to request it | 20:24 |
| micahg | IANA release team member, but they said they'd be more strict this time around since feature freeze was much later, but the closer to feature freeze you are, the better the chance you have of an approval | 20:25 |
| slangasek | smoser: right... any long-running services spawned by a postinst would have eatdata in the preload environment | 20:25 |
| slangasek | smoser: so this would be ok for bootstrapping where you know you're rebooting before you actually start services, but not so great for apt-get on a prod system | 20:25 |
| slangasek | (but upstart magically avoids this problem, yay ;) | 20:26 |
| ScottK | micahg: Personally, I'm more inclined to go easy this time than I had planned on since I think the whole "rolling" discussion threw things off plan for many people. | 20:26 |
| slangasek | ScottK: I think that's a good position to take, though if we're going to get to 13.04 we will still need to get the freeze formally instated to get back on track | 20:27 |
| frafu | <micahg> Ok; cancel the upload. We will try to fix the bug and request an exception in the next days. Sorry for any inconvenience. | 20:27 |
| psusi | that does seem to be a pretty good argument against using eatmydata for upgrades though, and instead having dpkg get the --i-really-mean-no-bloody-syncs type option I proposed a while back | 20:28 |
| ScottK | slangasek: Agreed. I think no formal decision has been made to change the plan, FF is still today. | 20:28 |
| ScottK | frafu: If it's just fixing a bug, it can go in much later. | 20:28 |
| micahg | frafu: sure, no problem, as Xubuntu uses onboard, I'd prefer a more solid version anyways | 20:29 |
| psusi | smoser: did you get around to the growfs thing yet? | 20:32 |
| smoser | psusi, i'm about to land it... | 20:33 |
| psusi | smoser: did you end up using parted, or sfdisk? | 20:33 |
| smoser | cloud-init should have support for using growpart *or* parted partresize | 20:33 |
| slangasek | barry: bug #1094218> I suspected the -Es problem myself, but having looked in the teamviewer package, upstream isn't providing any python stuff that would override. Also, from the errors.u.c page this is definitely being hit with -Es: https://errors.ubuntu.com/oops/3bdeab54-8766-11e2-b117-e4115b0f8a4a | 20:33 |
| ubottu | bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes" [Medium,Confirmed] https://launchpad.net/bugs/1094218 | 20:33 |
| smoser | whichever it finds. | 20:33 |
| barry | slangasek: ack | 20:34 |
| barry | slangasek: okay, i'll look into it again | 20:34 |
| psusi | smoser: so you got around the sfdisk complaining about BLKRRPART problem? | 20:35 |
| smoser | with that ugly hack that i showed you | 20:35 |
| psusi | ahh | 20:36 |
| frafu | <micahg> The problem we found just occurs at the login screen on the nexus in portrait mode. But, it might nevertheless be better to wait and test a few more days. So we decided to ask you cancel the upload. | 20:37 |
| micahg | frafu: ok, just mark the bug accordingly, I see sponsors was already unsubscribed | 20:37 |
| frafu | <micahg> done | 20:42 |
| === salem_` is now known as _salem | ||
| dobey | /usr/lib/x86_64-linux-gnu/qt5/bin/qmake <- what a weird path for the qmake bin to be installed to. why is it in there and not installed as /usr/bin/qmake-qt5 ? | 20:50 |
| xnox | dobey: that is wrong. no-preference on the name, but yeah it should be under /usr/bin/ | 20:54 |
| dobey | xnox: oh, it seems this weird 'qtchooser' thing is a wrapper | 20:57 |
| dobey | xnox: only after i installed ubuntu-sdk did it do anything useful though, so i wonder what specifically was missing there :( | 20:57 |
| slangasek | dobey, xnox: the 'qtchooser' only affects /usr/bin/qmake, AFAIK; at least for qt4-qmake, /usr/bin/qmake-qt4 exists, though it's also a symlink into /usr/lib/aardvark | 21:06 |
| slangasek | I don't know why the files are shipped under /usr/lib, that seems pointless to me | 21:07 |
| slangasek | this is a recent change; as of quantal, /usr/bin/qmake-qt4 was a real file | 21:13 |
| YokoZar | slangasek: Do you know the rough amount of default install library packages still waiting on multi-arch transition? | 21:29 |
| slangasek | YokoZar: not at all | 21:30 |
| YokoZar | slangasek: does libcdio count? | 21:30 |
| slangasek | YokoZar: you could test by grabbing a default install, and looking at /lib/*.so.* /usr/lib/*.so.*? | 21:30 |
| YokoZar | mmm yeah | 21:30 |
| slangasek | YokoZar: however, I've never considered "all libs in the default install converted to multiarch" to be an interesting target; being installed by default says little about whether you need to cross-install it | 21:31 |
| YokoZar | slangasek: I suppose because the default install packages depending on them doesn't really mean that there's another package that might depend on a cross-arch version | 21:31 |
| slangasek | more interesting targets are "all the common libs used by binary-only software that we know about", and "being able to cross-build everything in the default system with multiarch (no self-conflicts in the build-deps) | 21:32 |
| slangasek | " | 21:32 |
| slangasek | YokoZar: exactly | 21:32 |
| slangasek | for instance, the only libs left in /lib on my system are libcryptsetup, and libraries internal to iptables | 21:32 |
| slangasek | not terribly interesting targets | 21:33 |
| YokoZar | Yeah that makes sense | 21:33 |
| YokoZar | I stumbled on https://bugs.launchpad.net/ubuntu/+source/libcdio/+bug/1151565 recently (needed -ugly plugins for a wine game) | 21:34 |
| ubottu | Launchpad bug 1151565 in libcdio (Ubuntu) "Please transition libcdio to multi-arch" [Undecided,New] | 21:34 |
| slangasek | oh -ugly, always living up to your name | 21:35 |
| slangasek | YokoZar: so my recollection was that we had previously multiarched all the libs used by all of good, bad, and ugly in support of wine; I'm guessing this is a recently added library dependency? | 21:36 |
| YokoZar | slangasek: http://packages.ubuntu.com/precise/gstreamer0.10-plugins-ugly seems to say precise depended on it | 21:37 |
| YokoZar | did software center depend on it in precise? | 21:37 |
| slangasek | did software center depend on what? | 21:37 |
| slangasek | -ugly is in universe and always has been | 21:38 |
| YokoZar | did software center depend on libcdio I mean | 21:39 |
| slangasek | no idea | 21:40 |
| YokoZar | we might not have noticed if it didn't, I mean, because installing foreign -ugly wouldn't have removed software center. | 21:42 |
| YokoZar | It seems like precise software-center doesn't pull in libcdio13 but raring does | 21:43 |
| slangasek | I'm struggling with the idea of software center requiring libcdio | 21:43 |
| YokoZar | It's a transitive dependency | 21:44 |
| slangasek | ah, via gvfs-backends; yes, that dep was there in precise too | 21:45 |
| YokoZar | Precise software center didn't depend on gvfs-backends | 21:46 |
| roaksoax | slangasek: still around? | 22:18 |
| roaksoax | slangasek: i was wondering if you could help me out with an upgrade issue described here: http://pastebin.ubuntu.com/5594451/ | 22:18 |
| === Laney changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| barry | slangasek: bug 1152359 | 22:38 |
| ubottu | bug 1152359 in zeroinstall-injector (Ubuntu) "[FFe] sync 2.0-1 from debian/sid" [Undecided,New] https://launchpad.net/bugs/1152359 | 22:38 |
| tkamppeter | slangasek, hi | 22:43 |
| slangasek | roaksoax: can you post the output when running apt-get with -oDebug::pkgProblemResolver=1? | 22:44 |
| ogra_ | stgraber, you dont inspect real snapshot capable filesystems for the single-image-update spec ? | 22:45 |
| roaksoax | slangasek: sure, give me just one sec | 22:45 |
| slangasek | tkamppeter: hi | 22:45 |
| roaksoax | slangasek: btw.. I uploaded again the python-django changes for maas as ubuntu1.7, sinced the previous upload got rejected because a security fix landed with ubuntu1.6 | 22:45 |
| stgraber | ogra_: it was mentioned during the session but cjwatson and some others expressed concern regarding the reliability of using snapshotting (block snapshotting with LVM at least) | 22:46 |
| ogra_ | well, i was referring to nilfs2 | 22:46 |
| slangasek | roaksoax: ok, thanks for the info - and sorry for not getting to that one yet | 22:47 |
| ogra_ | which additionally gives a massive performance boots on mmc | 22:47 |
| tkamppeter | slangasek, due to all the discussion about rolling release, the UDS placed a day before FF, I was not counting on the FF actually taking place and so I missed FF with some important packages. HPLIP 3.13.2 and an update of foomatic-db. Could there be made an exception for these? They are mainly about updated hardware support. | 22:47 |
| roaksoax | slangasek: no worries :) | 22:47 |
| slangasek | xnox did some nilfs2 investigation previously, IIRC | 22:47 |
| ogra_ | yep i pushed for that as well :) | 22:48 |
| ogra_ | for the nexus7 ... but thats was only to make sure it works as rootfs | 22:48 |
| ScottK | slangasek: I took care of python-django. You can mark that off you list. | 22:48 |
| ogra_ | (there were initrd hooks not working etc) | 22:48 |
| slangasek | ScottK: ah, alrighty then | 22:48 |
| slangasek | tkamppeter: if the packages are ready to go today or tomorrow, then that's fine | 22:49 |
| slangasek | tkamppeter: if it's going to be next week, we may want to dig into the details more | 22:50 |
| tkamppeter | slangasek, hplip is nearly ready and foomatic-db is trivial. | 22:50 |
| xnox | ogra_: explain what part of the job you envision to use fs snapshoting for? (as in nilfs2 for example) | 22:51 |
| xnox | ogra_: in nil2fs you cannot remove the base snapshot, nor replace it with something else, nor merge them to recover space. | 22:51 |
| xnox | if files are deleted one needs to garbage collect. The assumptions so far was that we will not have space for two base images. | 22:52 |
| stgraber | ogra_: seems interesting. Only shortcoming that may be problematic is the lack of extended attribute support. IIRC we now have some software (I recall gnome-keyring at least) using those to store capabilities | 22:52 |
| ogra_ | oh, yeah, that would need to be added | 22:53 |
| xnox | stgraber: so we did start using extended attributes?! =) nice. i was still under the assumption that nothing yet uses extended attributes on linux. | 22:54 |
| ogra_ | xnox, well, would btrfs offer that we pull in a newer snapshot ? | 22:54 |
| stgraber | xnox: pretty much nothing is as tarballs can't store them (in a format compatible way anyway), but I know that gnome-keyring uses maintainer script to set some capabilities as xattr | 22:54 |
| ogra_ | to actually apply a system update in one file | 22:55 |
| stgraber | stgraber@castiana:~/data/code/lxc/stgraber-lxc-git$ getcap /usr/bin/gnome-keyring-daemon | 22:55 |
| stgraber | /usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep | 22:55 |
| ogra_ | (i thought nilfs2 actually handles snapshots in userspace ... i would expect that to be modifyable to support what we need) | 22:55 |
| xnox | ogra_: i still don't understand what are you after. I have base image, create snapshot, update all files in the snapshot, then what? | 22:56 |
| xnox | ogra_: nil2fs can mount older snapshots readonly, up to the point where it's past the log horizon. | 22:57 |
| ogra_ | xnox, send a zipped snapshot to the user to apply as system update | 22:57 |
| roaksoax | slangasek: ok here's the output: http://pastebin.ubuntu.com/5594529/ | 22:57 |
| xnox | ogra_: since there is no block level deduplication it will be same as sending a zip of any files that have changed + filesystem overhead. | 22:58 |
| xnox | (for nil2fs) | 22:58 |
| ogra_ | right | 22:58 |
| xnox | ogra_: for btrfs, it might be smaller than sending a zip of any files that have changed. | 22:59 |
| ogra_ | well, essentially we woudl want it to be a diff indeed | 22:59 |
| ogra_ | between original install and update1 | 22:59 |
| xnox | ogra_: btrfs has file-level deduplication only as well (but that's from 3.6 kernel info, things may have changed) | 23:00 |
| xnox | ogra_: a zip of xdeltas ;-) | 23:00 |
| ogra_ | well, btrfs is sadly extremely underperforming on MMCs | 23:00 |
| ogra_ | unless that recently changed | 23:00 |
| xnox | ogra_: somebody on github was working on a delta format for binaries that are encapsulated in an fs image. but it sounded very experimental. | 23:01 |
| ogra_ | hmm | 23:01 |
| ogra_ | the prob is that i dont think btrfs is well suited for our usecase ... and the fact that we cant really rely on a kernel version | 23:02 |
| ogra_ | all tests that i have seen with btrfs on MMC had very bad results ... like twice as slow as ext4 | 23:03 |
| === kentb is now known as kentb-out | ||
| RAOF | It's somewhat a pitty that btrfs isn't more mature; it's got all sorts of fancypants things that would make our lives easier (snapshots, the ability to btrfs-send filesystem images, dedupability…) | 23:09 |
| ogra_ | b in btrfs stands for buzzword right ? | 23:11 |
| ogra_ | or was it bling ? | 23:11 |
| ogra_ | its like the duke nukem of filesystems :) | 23:12 |
| xnox | i like how it doesn't loose data during defragmentation if snapshots are present.... from linux kernel 3.9rc1 and up | 23:13 |
| RAOF | I was under the impression that it doesn't lose *deduplication* during defragmentation in that case? | 23:18 |
| RAOF | For all my annoyances with it, btrfs hasn't actually lost any of my data for a good long while. | 23:19 |
| xnox | RAOF: hm, then it's not that bad, unless one runs out of disk-space while performing defrag =) | 23:20 |
| xnox | RAOF: on my current machine I don't have btrfs, but I am planning to use it on my desktop, which was suppose to be here today. Oh well maybe tomorrow? | 23:20 |
| RAOF | xnox: Right. I'd guess the defrag would fail in that case rather than losing data. | 23:20 |
| RAOF | xnox: With an SSD, or rotating rust? I've found that it bogs down pretty quickly on rotating rust. | 23:21 |
| xnox | RAOF: well, all defrags can fail if there is not enough space to shuffle bits about. | 23:21 |
| RAOF | Well, yeah :) | 23:22 |
| tkamppeter | slangasek, hplip 3.13.2-0ubuntu1 uploaded. | 23:24 |
| xnox | RAOF: 4x1TB of rotating rust with Intel Rapid/Matrix RAID or Marvell raid controllers. I have both ;-) | 23:25 |
| gaara_akash | "For qmake projects, use the QML_IMPORT_PATH variable to add import paths." - thats an error i keep getting, anyone know what to do? | 23:38 |
| mdeslaur | xnox: I was just about to upload an openssl to -proposed for 1066032 :P | 23:54 |
| * mdeslaur shakes fist at xnox :) | 23:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!