| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === beisner- is now known as beisner | ||
| aeoril | darkxst something came up and I will be unable to fix bug 1315442. I wanted to let you know because I said I would get it in today. Sorry. Thanks for all the help. | 04:26 |
|---|---|---|
| ubottu | bug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442 | 04:26 |
| pitti | Good morning | 04:28 |
| pitti | bdmurray: oh sorry, must have missed that mail then | 04:28 |
| Noskcaj | infinity, ok. For some reason i was under the impression it wasn't a package for all arches. I just keep seeing it on the ftbfs list, but it's not a real issue | 06:02 |
| Mirv | doko_: seen in qtwebkit, not tested in qttools.. but you may try to add to debian/rules echo "CONFIG -= precompile_header" >> .qmake.conf | 06:17 |
| Mirv | doko_: I'm seeing hints it'd be globally available, so it could just work | 06:18 |
| jpds | Noskcaj: Feel free to do it if you want. | 06:57 |
| === marcusto_ is now known as marcustomlinson | ||
| dholbach | good morning | 07:31 |
| === marcusto_ is now known as marcustomlinson_ | ||
| === marcustomlinson_ is now known as marcustomlinson | ||
| === rcj is now known as Guest41677 | ||
| pitti | didrocks: FYI, bug 1312976 updated with pointer to PPA and TODO list | 08:10 |
| ubottu | bug 1312976 in nfs-utils (Ubuntu) "Make NFS client/server work under systemd" [High,In progress] https://launchpad.net/bugs/1312976 | 08:10 |
| didrocks | pitti: great! setting up :) | 08:14 |
| pitti | didrocks: note that you need at least rpcbind from -proposed | 08:14 |
| pitti | didrocks: https://launchpad.net/ubuntu/+source/rpcbind/0.2.1-6ubuntu2/+build/7027472 | 08:14 |
| pitti | didrocks: apparmor and console-setup will not be started with current vivid packages (see bug), but you can ignore those for a first test | 08:15 |
| didrocks | pitti: I can grab them from -proposed anyway, clean vm install in progress :) | 08:17 |
| pitti | didrocks: oh, you do a new install for that? | 08:30 |
| didrocks | pitti: yeah, an independant vm with another disk | 08:31 |
| pitti | didrocks: I usually just start (with -snapshot) adt-vivid-amd64-cloud.img | 08:31 |
| didrocks | well, if I can get vivid to start… :/ | 08:31 |
| didrocks | seems no unity in the daily | 08:31 |
| pitti | didrocks: err? | 08:31 |
| pitti | didrocks: oh, you mean the desktop image | 08:31 |
| didrocks | yeah | 08:31 |
| pitti | didrocks: the above is the standard autopkgtest VM, i. e. just minimal stuff | 08:32 |
| === marcusto_ is now known as marcustomlinson | ||
| didrocks | well, screw this for now, manual qemu with the autopkgtest vm then and snaphotting | 08:32 |
| pitti | and redirecting port 22 to not go crazy :) | 08:32 |
| didrocks | yeah ;) | 08:32 |
| pitti | maybe my crappy little "vm" script is worth a G+ post, /me does | 08:33 |
| didrocks | pitti: I'm sure it worthes it :) | 08:34 |
| * didrocks wonders with -snapshot where to specify the file to write to | 08:35 | |
| didrocks | yeah, so only temporary, I guess until we stop the vm | 08:36 |
| pitti | didrocks: ok, done | 08:41 |
| pitti | didrocks: you don't, qemu creates a temp overlay in /var/tmp/ | 08:41 |
| didrocks | pitti: yeah, so if you want an overlay which can survive host reboot… | 08:41 |
| pitti | didrocks: if you want to keep the changes, rather make an explicit snapshot (qemu-img snapshot -c clean-install foo.vm) | 08:41 |
| pitti | didrocks: right, or create a new image with your original VM as a base | 08:41 |
| pitti | didrocks: most often I don't care, so I don't know that one by heart | 08:42 |
| pitti | didrocks: I just record the shell commands to do what I want in the VM, and paste them into ssh | 08:42 |
| didrocks | oh, I wasn't using the -net nic | 08:42 |
| * didrocks looks | 08:42 | |
| didrocks | pitti: ok, making sense :) | 08:43 |
| pitti | didrocks: qemu-img create -f qcow2 -o backing_file=youroriginalvm.img overlay.img | 08:43 |
| * didrocks logs this | 08:44 | |
| didrocks | thanks pitti, upgrading my adt machine and installing from the ppa | 08:44 |
| didrocks | pitti: ok, updated, working here, with the hang you noted on shutdown of course (and so using system_reset to restart it) | 09:05 |
| pitti | didrocks: this could just be because nfs-server shuts down before the unmounts | 09:06 |
| mitya57 | Mirv: I added sip4 to your FFe (as new PyQt5 needs new sip4, and old PyQt5 doesn't support Qt 5.4.1), and also added changelog links for sip/PyQt5 | 09:07 |
| pitti | cyphermox, slangasek: FYI: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#console-setup | 09:09 |
| didrocks | pitti: even if shutdown.target will conflicts against it, maybe we can use some dep on umount.target | 09:10 |
| pitti | cyphermox, slangasek: two missing dependencies | 09:10 |
| Mirv | mitya57: oh, thanks, I didn't realize pyqt5 5.4.1 would have such a change | 09:14 |
| Mirv | sip4 release mentions being required for new pyqt5, but the pyqt5 release notes I read do not mention that. | 09:15 |
| pitti | didrocks: fixed | 09:19 |
| didrocks | pitti: waow, already, how did you deal with this? | 09:19 |
| pitti | didrocks: I added Before=remote-fs-pre.target to /lib/systemd/system/nfs-server.service | 09:20 |
| pitti | didrocks: i. e. if you have server and client on the same machine, start the server first, then the NFS mounts (client) | 09:20 |
| pitti | didrocks: and conversely on shutdown, stop the NFS mounts first, then the server | 09:20 |
| pitti | it's certainly a corner case, but as that's merely ordering without adding deps, it should be okay | 09:20 |
| didrocks | pitti: hum, but it means we starts the nfs server before having any network? I guess nfs copes with it | 09:21 |
| pitti | didrocks: is that bad? | 09:22 |
| pitti | didrocks: nfs-server still Requires: network.target | 09:22 |
| pitti | didrocks: (not network-online.target) | 09:22 |
| didrocks | systemd.special(7) doesn't seem to note anything wrong about it | 09:24 |
| didrocks | so yeah, nice trick for that corner case! | 09:24 |
| pitti | didrocks: hm, for testing server and client separately, we would now need two QEMUs which talk to each other | 09:29 |
| pitti | didrocks: do you happen to know the magic -net invocation for that? I naïvely tried -net bridge,br=lxcbr0 (wanting to piggy-back on LXC's) but that doesn't work | 09:29 |
| pitti | didrocks: I'd like to verify whether 24-systemd-modprobes.patch is still actually required (upstream/fedora doesn't have it) | 09:30 |
| infinity | pitti: Here's an example of tun/tap bridged networking from a buildd: http://paste.ubuntu.com/10513248/ | 09:35 |
| pitti | infinity: oh cool, thanks | 09:36 |
| infinity | pitti: notably, the -net nic -net tap,script stuff, and then the script itself. Which might exist on Ubuntu in a cleaner form in /etc/qemu but doesn't on this awful Fedora base system I'm using. :P | 09:36 |
| didrocks | pitti: I would have used the bridge option as well, just tried but without any success either | 09:36 |
| infinity | Bonus points to the first person who recognizes the MAC address space our buildds are using. :P | 09:38 |
| pitti | infinity: haha, Atari!? | 09:40 |
| pitti | infinity: so Atari:leet:40, no idea about the 40 | 09:41 |
| infinity | pitti: The odds of clashing on the same physical segment with a real computer seem slim. ;) | 09:41 |
| infinity | pitti: The last byte is assigned by the order I spun the VMs up in and assigned IP addresses, I think. | 09:42 |
| infinity | pitti: But the real question is, did you have to look up 000036, or was that strange nugget of knowlegde stored away in that part of your memory that really shouldn't know such things? | 09:43 |
| pitti | infinity: nah, I looked it up | 09:43 |
| pitti | infinity: I remember a few from maintaining udev's 75-persistent-net-generator.rules, but for some strange reason I never ran into the Atari prefix :) | 09:44 |
| infinity | pitti: Sadly, unlike PCI IDs, MACs seem to be less gimmicky, and thus harder to remember. | 09:46 |
| infinity | (Though, there is 8086:F2, and 3C0000) | 09:47 |
| infinity | 3C0000 being particularly cute, since that's 3C0M | 09:47 |
| pitti | oh, nice! I would have missed the Roman numeral hint | 09:48 |
| cjwatson | pitti: So ... we're probably at most weeks away from being able to flip the real-ddebs switch in Launchpad | 10:00 |
| === doko_ is now known as doko | ||
| cjwatson | pitti: But we don't want to inject the existing ddebs back into Launchpad, since we're not certain enough of their provenance in all cases, so the plan per William is to make ddebs.ubuntu.com slurp from Launchpad proper rather than the buildds after we flip the switch, until such time as we've rebuilt everything (say, after 16.04) and can publish a proper full archive from LP | 10:02 |
| cjwatson | pitti: Are you likely to have a bit of time to make the necessary ddeb-retriever changes? | 10:02 |
| === Malsasa_ is now known as Malsasa | ||
| pitti | cjwatson: good to hear! | 10:02 |
| pitti | cjwatson: I'm on VAC from March 16 to 25, but I don't expect this to be more work than a day or so; so as soon as we have some ddebs in LP (or staging) to test against, I can carve out some time | 10:03 |
| cjwatson | pitti: I could probably do some in dogfood for you | 10:04 |
| infinity | Could test against a PPA with ddebs. | 10:05 |
| cjwatson | Or that | 10:05 |
| infinity | But the primary archive is a better final test, yes. | 10:05 |
| cjwatson | pitti: The main trick is how to do the catch-up thing; I was thinking that you could use Archive.getPublishedBinaries(created_since_date=), and remember the latest ddeb you've successfully fetched | 10:05 |
| cjwatson | Perhaps | 10:05 |
| cjwatson | pitti: But if you need extra stuff on the webservice, that can be arranged - we just need to know what sort of shape of thing you need | 10:06 |
| infinity | cjwatson: I was thinking one would walk Packages.gz and map back, and keep a note of ones you've already fetched, so future runs are only getting deltas. | 10:06 |
| cjwatson | created_since_date would achieve deltas too ... | 10:06 |
| pitti | cjwatson: yes, that's what I was going to do; wgrant and I discussed that before, I think | 10:06 |
| cjwatson | The problem with walking Packages is that you don't know which ones *need* ddebs. You could certainly keep a note of the ones that fail, but the first run would be exceedingly slow | 10:07 |
| pitti | ddeb-retriever already walks Packages.gz and creates an archive map (it has to right now), but I think created_since is fine | 10:07 |
| wgrant | Not *fatally* slow. | 10:07 |
| cjwatson | I don't have enough of a feel for ddeb-retriever to know which approach is best/easiest, though. | 10:08 |
| pitti | iterating over a hundred builds a day is certainly faster than iterating over 30.000 packages | 10:08 |
| wgrant | created_since with a bit of a fudge factor probably makes sense, but it would need care around eg. series initialisation to avoid making $lots of requests. | 10:08 |
| wgrant | So it would probably want to keep a record locally of what it already had. | 10:08 |
| cjwatson | Yeah | 10:08 |
| pitti | the current approach is queue based, too -- i. e. "Fetch all ddebs from $given_day", then sort them in | 10:08 |
| cjwatson | Damnit why is *_debug_symbols on archives a state secret | 10:08 |
| cjwatson | Aha, ppa-self-admins to the rescue | 10:09 |
| cjwatson | wgrant: So ubuntu.main_archive will get build_debug_symbols=True but publish_debug_symbols=False (until we have enough of the archive to do a real publisher), is that right? | 10:10 |
| infinity | cjwatson: Unless we do a "screw old binaries, let's rebuild the world" flag day, that real publisher thing may never come. | 10:11 |
| wgrant | cjwatson: Well, enough of the archive and archive views, really. | 10:12 |
| infinity | I guess a gina-like import of old ddebs to glue them to the build records where they belong was just deemed too hard/dangerous? | 10:12 |
| wgrant | Unless we want a few terabytes on $new_pepo | 10:12 |
| wgrant | infinity: Yes, I do not want to do that unless we have no option. | 10:12 |
| wgrant | Because we know that ddeb-retriever is fallible. | 10:12 |
| wgrant | And the Launchpad database is a rough approximation of infallibility. | 10:12 |
| infinity | Yeah, there may be cases where ddeb-retriever accidentally published a PPA version instead of a PRIMARY version, etc. | 10:13 |
| wgrant | Uploading ddebs to random builds is not hugely helpful. | 10:13 |
| wgrant | Yep, exactly. | 10:13 |
| wgrant | So the plan is that we have a clean break and pretend that we'll rebuild everything before 16.04. | 10:13 |
| infinity | Which we won't. | 10:14 |
| infinity | But maybe we'll rebuild everything that matters. | 10:14 |
| wgrant | Yep. | 10:14 |
| infinity | Once we have an archive implementation that finally doesn't suck, I might try to find motivation to make the actual generation less hackish and contribute it back to Debian. | 10:15 |
| infinity | Since every conversation there has just spun in circles and given them exactly nothing to show for it. | 10:15 |
| wgrant | In the immediate term the archive generation will continue to be ddebs.ubuntu.com, as today. | 10:15 |
| mgedmin | any thoughts about replacing ddebs with symbol servers indexed by build-id (as described in https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/)? | 10:15 |
| wgrant | Once we have diskless archives, we can publish post-LP-enablement ddebs for very little disk space indeed. | 10:16 |
| wgrant | (we could work out some solution to publish them physically on pepo, but that really doesn't seem worth it) | 10:16 |
| cjwatson | pitti: So, examples: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa has build_debug_symbols=True and publish_debug_symbols=True; https://code.launchpad.net/~unity-team/+archive/ubuntu/phone-right-edge/+packages has build_debug_symbols=True and publish_debug_symbols=False. Either should do for your purpose. | 10:16 |
| wgrant | build_debug_symbols does what it says on the tin. | 10:17 |
| wgrant | publish_debug_symbols is a bit more complicated: they get binary_package_publishing_history records, and they get set to Published as normal, but they never actually hit the archive pool or indices. | 10:17 |
| pitti | mgedmin: it's a really nice way of distributing them, but I guess needs design and thinking around authentication and mirroring | 10:17 |
| pitti | infinity: thanks for the -net tap hint, works great! | 10:18 |
| wgrant | infinity: I was pleasantly surprised this morning to find that we don't have to SRU anything, because I made the relevant changes to pkg-create-dbgsym back in 2009... | 10:18 |
| pitti | didrocks: FYI, http://piware.de/tools/vmbr is similar to vm, just with that -tap thing, so that VMs can talk to each other and with LXC containers | 10:18 |
| infinity | pitti: At the end of the blog post, he suggests just enhancing Packages to list the buildids that each ddeb maps to. | 10:19 |
| infinity | pitti: That wouldn't be an unreasonable approach, and then both "install by package" and "search by buildid" work. | 10:19 |
| pitti | infinity: eww -- that's a *lot* of bloat | 10:19 |
| didrocks | pitti: oh, excellent! | 10:19 |
| pitti | I'd say that can easily double the Packages size | 10:19 |
| cjwatson | It'd be much nicer to have something that serves the individual debug object rather than the whole ddeb, too. | 10:19 |
| mgedmin | it also wouldn't help with getting symbols for ppa packages | 10:19 |
| pitti | right | 10:20 |
| infinity | pitti: It is, yes, and having the index server side instead of client side might be more pleasant, but doesn't really fit in an aptish world. | 10:20 |
| pitti | you want http://debug.ubuntu.com/d/de/deadbeef1337 | 10:20 |
| cjwatson | Putting it in LP would let us security-proxy it so that it works for private archives etc. But it'd be a lot of data and a fairly large new service. | 10:20 |
| didrocks | pitti: hum, the second is saying that the device is busy though | 10:22 |
| pitti | didrocks: hold that, it's broken | 10:22 |
| cjwatson | (And with some kind of diskless view you could still mirror the public parts) | 10:22 |
| infinity | It's certainly worth some thought, but without external contribution, I don't see it happening. | 10:23 |
| infinity | Not in a timely fashion anyway. | 10:23 |
| sil2100 | @pilot in | 10:24 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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: sil2100 | ||
| xnox | there is a fuse filesystem for debug symbols.... when attempted to be accessed they are fetched from http server... | 10:50 |
| pitti | slangasek: I now have working NFS under systemd, under various scenarios; bug 1312976 updated; would you like to review the debdiff and comment, or shoudl I just upload? | 11:26 |
| ubottu | bug 1312976 in nfs-utils (Ubuntu) "Make NFS client/server work under systemd" [High,In progress] https://launchpad.net/bugs/1312976 | 11:26 |
| xnox | pitti: i have another thing to ponder with you. In ubuntu dbus-daemon is shipped in /bin, rather than /usr/bin. | 11:27 |
| xnox | pitti: however i do not believe this to be necessory, if not wrong. | 11:28 |
| pitti | xnox: yeah, ancient modification; probably because upstart needs it early on? | 11:28 |
| pitti | (I never knew/understood why we need it) | 11:28 |
| pitti | it's certainly not wrong, but a moderately annoying delta when merging | 11:28 |
| xnox | pitti: the comment from keybuk was "start it earlier" -> but in practice all dbus daemons are in /usr/ | 11:28 |
| xnox | pitti: upstart doesn't need it, as it opens it's own private bus socket and uses that. And it does operate fully without dbus-daemon ever getting started. | 11:29 |
| xnox | (unlike systemd/logind) | 11:29 |
| pitti | and under sytsemd dbus starts After=basic.target, i. e. after local-fs.target | 11:30 |
| xnox | pitti: upstream we are pondering to move /etc/dbus-1 -> /usr/share/dbus-1, and a question came up whether this will or will not "break ubuntu's /bin" | 11:30 |
| xnox | pitti: yeap. | 11:30 |
| xnox | pitti: i want to move dbus back to /usr, may i test & prepare a patch to do so? | 11:30 |
| pitti | so from my POV I'm happy to drop that delta -- it has caused some pain in various places | 11:30 |
| xnox | pitti: /server work under systemd" [High,In progress] https://launchpad.net/bugs/1312976 | 11:30 |
| xnox | * darkbasic_ (~quassel@niko.linuxsystems.it) has joi | 11:30 |
| ubottu | Launchpad bug 1312976 in nfs-utils (Ubuntu) "Make NFS client/server work under systemd" [High,In progress] | 11:30 |
| xnox | bah, bad url | 11:30 |
| xnox | pitti: https://bugs.freedesktop.org/show_bug.cgi?id=89280 | 11:30 |
| pitti | xnox: go ahead | 11:30 |
| ubottu | Freedesktop bug 89280 in core "support ignore_missing attribute in the includedir element, and use that to support all default configuration in datadir" [Normal,New] | 11:30 |
| pitti | xnox: the previous was a copy&paste error? or does that apply to NFS? | 11:31 |
| xnox | pitti: copy&paste error. | 11:31 |
| pitti | xnox: and yay for throwing out /etc/dbus-1/system.d! | 11:31 |
| pitti | (or all such policies, really) | 11:32 |
| xnox | pitti: =) | 11:32 |
| pitti | a user can put an updated one into /etc, but we shouldn't put the defualt ones there | 11:32 |
| xnox | pitti: that's what my patches there achieve. | 11:32 |
| pitti | \o/ | 11:32 |
| xnox | pitti: ditto patches to systemd -> to make policies generate .want symlinks in /run, rather than /etc. | 11:33 |
| xnox | pitti: and a bunch of similar patches for other projects as well. | 11:33 |
| LocutusOfBorg1 | hi sil2100 did you already upload vbox? | 11:33 |
| xnox | not everything is forwarded to upstreams yet. | 11:33 |
| LocutusOfBorg1 | feel free to rename the patch if you didn't already upload the package | 11:34 |
| LocutusOfBorg1 | yes, a number might be better for future uploads | 11:34 |
| xnox | pitti: i see upstartisms in dbus.postinst =/ | 11:39 |
| xnox | pitti: is there a way to do archive-wide scan for these? | 11:39 |
| * xnox guesses lintian. | 11:39 | |
| pitti | xnox: where? | 11:40 |
| pitti | looks fine to me at first sight | 11:40 |
| xnox | pitti: http://paste.ubuntu.com/10514296/ | 11:40 |
| pitti | xnox: ah, so s/status/service/? | 11:41 |
| xnox | pitti: well, and then check for return code, rather than 'upstart formatting of pid #' and need to check that service status under both upstart & systemd outputs the same exit codes. | 11:42 |
| xnox | pitti: do you have lintian lab or some such way to scan all .deb's maintainer scripts to make sure they don't call initctl / upstart naked commands? | 11:43 |
| xnox | q | 11:43 |
| xnox | ZZ | 11:43 |
| xnox | :wq! | 11:43 |
| pitti | I don't, no; do we still have the codesearch setup for ubuntu? | 11:45 |
| xnox | pitti: well i only provide dns for it http://ubuntu-codesearch.surgut.co.uk/ and it points into 502 inside canonistack. | 11:47 |
| xnox | Laney: are you running codesearch still? | 11:47 |
| === MacSlow is now known as MacSlow|lunch | ||
| Laney | nein | 11:47 |
| xnox | Laney: warum nicht? =) | 11:48 |
| LocutusOfBorg1 | hi all :) | 11:48 |
| Laney | keine zeit | 11:48 |
| Laney | basically it kept breaking | 11:49 |
| Laney | the easiest way I know of atm is to ask j_dstrand to do a grep for you | 11:49 |
| xnox | Laney: well, i want to grep for "upstartisms" in the .deb maintainer scripts. | 11:50 |
| xnox | Laney: e.g. dbus postinst calls "status dbus | ...." for a non-upstart specific code-path. | 11:50 |
| Laney | I believe you have a good usecase | 11:50 |
| Laney | but I'm afraid that codesearch isn't deployed atm :( | 11:50 |
| pitti | flexiondotorg: did you ever happen to run MATE under systemd? any problesm there which would block switching to it by default? | 11:52 |
| Laney | maybe we could at some point look at doing it again | 11:52 |
| xnox | pitti: i still have bits that are not ported on the phone for pid1 systemd. | 11:52 |
| xnox | pitti: so at least touch, should be kept on upstart for the time being. | 11:53 |
| pitti | xnox: yeah, phone won't switch for sure | 11:53 |
| pitti | xnox: just added a work item and discussed with ogra in #u-touch | 11:53 |
| pitti | xnox: most touch devices have too old kernels (3.4), that'll block the switch until touch moves to a newer android | 11:53 |
| xnox | pitti: really? why? what's needed / missing? | 11:54 |
| ogra_ | pitti, i doubt we will ever get a newer android for the released phones | 11:54 |
| ogra_ | and even then it is doubtful that they will have any newer kernels | 11:54 |
| xnox | pitti: can't we just patch xattr support back in? http://cgit.freedesktop.org/systemd/systemd/commit/?id=d2edfae0f9bdbecf6a8518e2a5bcf06f470e0d9e&ss=1 | 11:54 |
| flexiondotorg | pitti, I'm also an Arch TU so I've been running MATE on systemd for a couple of years now 😃 | 11:54 |
| pitti | yeah, I wasn't saying "next week", this will still be a few years in the worst case | 11:55 |
| ogra_ | i think the only way would be to backport missing bits | 11:55 |
| flexiondotorg | pitti, We did the systemd support for MATE a good while back. | 11:55 |
| xnox | pitti: or like backport xattr support for cgroups. | 11:55 |
| pitti | flexiondotorg: right, but I meant on Ubuntu? I don't expect problems, but I'd like to get a confirmation from each flavor that it doesn't break stuff | 11:55 |
| flexiondotorg | pitti, The transition from Ubuntu 14.10 to 15.04 was seamless. No systemd issues that I've encountered. | 11:55 |
| ogra_ | xnox, our prob here is that porters will have to do the same ... we dont want that porting turns into a kernel patching orgy | 11:55 |
| flexiondotorg | *from Ubuntu MATE 14.10 to 15.04 | 11:55 |
| xnox | ogra_: it already is, e.g. we mandate apparmor. | 11:56 |
| pitti | flexiondotorg: the default is still upstart, you need to opt-in (boot systemd in the grub menu or isntall systemd-sysv) | 11:56 |
| xnox | flexiondotorg: 15.01 doesn't use systemd-sysv yet. | 11:56 |
| flexiondotorg | pitti, Confirm systemd looks good on Ubunut MATE 15.04 currently :) | 11:56 |
| pitti | flexiondotorg: ok, thanks! | 11:56 |
| ogra_ | xnox, right, patching our apparmor in means essentially "delete the upstream apparmor folder in your tree and copy ours in place" | 11:56 |
| tjaalton | pitti: I'd say upload nfs-utils now, it doesn't affect current upstart users anyway | 11:56 |
| flexiondotorg | xnox, pitti You say systemd is not default? | 11:56 |
| flexiondotorg | How do I fully opt it exactly? | 11:57 |
| ogra_ | xnox, if we can make the systemd patching as easy, then yes, not an issue ... but i fear it will take a bit more there | 11:57 |
| xnox | flexiondotorg: correct, you need to install systemd-sysv packge to test that ubuntumate works with systeemd as pid 1. | 11:57 |
| pitti | flexiondotorg: https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems | 11:57 |
| cjwatson | well no you don't | 11:57 |
| cjwatson | you can just as well use the grub menu entry | 11:57 |
| flexiondotorg | pitti, So I can modify my seeds and rebuild then? | 11:57 |
| pitti | the wiki page shows both methods | 11:57 |
| flexiondotorg | pitti, Will gladly test that. | 11:57 |
| pitti | flexiondotorg: nah, not necessary | 11:57 |
| pitti | flexiondotorg: also, you can't -- ubuntu-minimal is shared between flavours | 11:58 |
| xnox | cjwatson: true, but that wouldn't catch things that calls "/sbin/init" expecting to start upstart user session and things like that. Although, I believe i fixed all of those by now. | 11:58 |
| flexiondotorg | pitti, OK, understood. | 11:58 |
| xnox | (e.g. lightdm greeters spawning "init --user" to run indicators.....) | 11:58 |
| pitti | also, these ^ shoudln't be desktop specific, but better safe than sorry :) | 11:58 |
| flexiondotorg | pitt, I'll do an inplace test now. | 11:58 |
| flexiondotorg | pitti, xnox Is the switch to systemd planned for 15.04? | 11:59 |
| mardy | pitti: hi! I'm a bit rusty with dbus python: I want to return a DBus error from a mocked method, how do I do that? | 11:59 |
| pitti | flexiondotorg: yes, still; I'm currently writing an FFE | 11:59 |
| sil2100 | LocutusOfBorg1: ouch, already uploaded it as it was... | 12:04 |
| pitti | slangasek: FYI, filed bug 1427654 | 12:05 |
| ubottu | bug 1427654 in ubuntu-meta (Ubuntu Vivid) "FFE: switch system init to systemd [not touch] in 15.04" [Undecided,New] https://launchpad.net/bugs/1427654 | 12:05 |
| sil2100 | LocutusOfBorg1: might consider re-uploading or something, but I suppose it shouldn't be a big problem | 12:05 |
| sil2100 | @pilot out | 12:05 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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: | ||
| xnox | pitti: i'm not sure if $ service dbus status -> is useful under systemd. | 12:05 |
| pitti | xnox: why not? | 12:07 |
| xnox | pitti: well, i guess i will use systemctl -q is-active dbus | 12:08 |
| xnox | pitti: service dbus status -> outputs a bunch of colored output and exits zero. | 12:08 |
| pitti | right, and it exits with 3 for non-running jobs | 12:09 |
| ogra_ | just write an AI that can judge the colors | 12:09 |
| pitti | >/dev/null obviously required :) | 12:09 |
| pitti | tjaalton: yeah, it's tempting, but I guess I'll give slangasek at least a chance to review before I upload | 12:11 |
| xnox | pitti: ok that should work. let me check this under upstart as well and switch to service command then. | 12:11 |
| pitti | mardy: look into e. g. the bluez4.py template: raise dbus.exceptions.DBusException('org.foo.bar', 'not foobarized') | 12:12 |
| pitti | xnox: so what Debian does should actually work fine? | 12:13 |
| === _salem is now known as salem_ | ||
| pitti | xnox: calling /etc/init.d/dbus is not the most efficient as it needs to go through the lsb script, but it should work | 12:13 |
| pitti | but *shrug*, it's not like it matters | 12:14 |
| xnox | pitti: well, "$ service dbus status" under upstart gives: "dbus stop/waining" and exits 0 | 12:15 |
| xnox | =( | 12:15 |
| pitti | bah | 12:15 |
| xnox | (in a single user mode, as otherwise stopping dbus under upstart brings the systemd down) | 12:15 |
| pitti | yeah, try that with anacron or somethign harmless :) | 12:16 |
| xnox | pitti: i'm not proud http://paste.ubuntu.com/10514602/ | 12:20 |
| flexiondotorg | pitti, pitti install systemd testing is going well on Ubuntu MATE. Actually resolves a shutdown issue I've been having :) | 12:21 |
| pitti | xnox: hm, that still doesn't work for Debian under sysvinit? can we do a "if <runnign under upstart> status else /etc/init.d/dbus status"? | 12:22 |
| pitti | xnox: also, why doesn't /etc/init.d/dbus status work? /lib/lsb/init-functions.d/01-upstart-lsb shoudl divert it to status already? | 12:23 |
| xnox | let me check exit codes. | 12:23 |
| pitti | flexiondotorg: nice, thanks! once you are sufficiently convinced that it doesn't break stuff, woudl you mind sending something like "confirming that MATE works with systemd" to bug 1427654? | 12:24 |
| ubottu | bug 1427654 in ubuntu-meta (Ubuntu Vivid) "FFE: switch system init to systemd [not touch] in 15.04" [Undecided,New] https://launchpad.net/bugs/1427654 | 12:24 |
| xnox | pitti: (a) 01-upstart-lsb is in ubuntu only (b) /etc/init.d/dbus status exists zero here under upstart and dbus not running. | 12:24 |
| pitti | ok, so 01-upstart-lsb is broken | 12:24 |
| pitti | xnox: I guess Debian doesn't care much about this, and we can drop that delta next cycle (hopefully), so then just go with your's | 12:25 |
| flexiondotorg | pitti Will do. | 12:25 |
| flexiondotorg | pitti I noticed that plymouth didn't appear. Is this by design? | 12:25 |
| flexiondotorg | pitti, I only ask because I remember the back lash when Arch switched to systemd. | 12:25 |
| xnox | flexiondotorg: depends if plymouth is integrated correctly on mate..... | 12:26 |
| xnox | flexiondotorg: it works under systemd on ubuntu-unity | 12:26 |
| flexiondotorg | pitti, Just need to know if I need to find my flame proof trousers again. | 12:26 |
| flexiondotorg | xnox, Prior the adding systemd I have a slow boot and Plymouth. After adding systemd VM boot waaaaay faster. | 12:27 |
| flexiondotorg | Thinking I might not be seeing plymouth because X was hammered up that much quicker. | 12:27 |
| pitti | flexiondotorg: no, should work | 12:27 |
| xnox | there is plymouth in VMs. | 12:27 |
| flexiondotorg | pitti, Thanks. | 12:27 |
| pitti | plymouth in VM is a bit fiddly, though | 12:27 |
| mardy | pitti: excellent, thanks! | 12:27 |
| flexiondotorg | xnox, VirtualBox VM with Ubuntu MATE in it. | 12:27 |
| pitti | flexiondotorg: often the VM is too fast, and you don't actually see it; or the graphics driver (like qemu's default one) causes some corruption | 12:28 |
| pitti | it usually shows better on real iron, or with e. g. qemu's -vga std | 12:28 |
| flexiondotorg | pitti, xnox - Anyway to test Ubiquity install with systemd installed? | 12:28 |
| pitti | flexiondotorg: yes; append "init=/bin/systemd" to the kernel command line in gfxboot | 12:29 |
| flexiondotorg | Of course. Thanks. | 12:29 |
| pitti | flexiondotorg: i. e. press a key to get the menu, press F6 to get the expert menu, press Esc twice to close it again | 12:29 |
| pitti | flexiondotorg: then you can edit the kernel command line | 12:29 |
| pitti | flexiondotorg: (I tested that on ubuntu a few months ago) | 12:29 |
| flexiondotorg | pitti Yep, done it. | 12:30 |
| mdeslaur | @pilot in | 12:39 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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: mdeslaur | ||
| flexiondotorg | pitti, One issue with systemd enable during install. | 12:42 |
| LocutusOfBorg1 | sil2100, maybe I can rename in the next upload :) | 12:43 |
| flexiondotorg | pitti, When I click restart it does just that. No prompt to remove the media. | 12:43 |
| LocutusOfBorg1 | or I can ask -release to reject but I guess it should be fine | 12:43 |
| LocutusOfBorg1 | I do not really care about them | 12:43 |
| * dholbach hugs mdeslaur | 12:53 | |
| * mdeslaur hugs dholbach back | 12:53 | |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | flexiondotorg: ah, bug report appreciated; thanks for testing! | 13:27 |
| doko | jamespage, which packages build-depend on gccgo-go? just juju-core? | 13:27 |
| doko | https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1427676 | 13:30 |
| ubottu | Launchpad bug 1427676 in juju-core (Ubuntu) "juju-core should drop the b-d on gccgo-go and libgo5, using gccgo instead" [Undecided,New] | 13:30 |
| flexiondotorg | pitti, Will test some more befre I raise bugs. | 13:30 |
| doko | pitti, jibel: looks like a lot of the i386 perl related autopkg tests need a give back | 13:39 |
| cjwatson | This is why I always sync perl by copying it into a devirt archive and then copying with binaries to the main archive ... | 13:40 |
| doko | noticed for the future ... | 13:41 |
| cjwatson | After one too many situations where I wound up with perl being uninstallable and unbuildable in -proposed | 13:41 |
| pitti | doko: yep, I got the bunch of errors, I'll lean on the retry button | 13:41 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| === Guest41677 is now known as rcj | ||
| === rcj is now known as Guest72440 | ||
| jdstrand | pitti: hey, fyi re bug #1312976, apparmor may load files from /var | 14:17 |
| ubottu | bug 1312976 in console-setup (Ubuntu) "Make NFS client/server work under systemd" [Undecided,In progress] https://launchpad.net/bugs/1312976 | 14:17 |
| pitti | jdstrand: hey | 14:18 |
| jdstrand | pitti: is /var expected to be nfs-mountable? | 14:18 |
| pitti | jdstrand: ah, and we want to support NFS on /var? | 14:18 |
| jdstrand | that's the question | 14:18 |
| pitti | jdstrand: ok, we could flip that around, if we don't care about protecting all the NFS stuff by apparmor? | 14:18 |
| jdstrand | I don't think I can answer that-- I'm not up on the issue | 14:18 |
| jdstrand | pitti: so, when cache loading hits and we have proper systemd support for apparmor, the initscript would become a second stage loader to update the cache. I thihnk it could have remote_fs then | 14:19 |
| jdstrand | but we don't have that right now, so not sure what the best course of action is in this transition period | 14:20 |
| jdstrand | sbeattie: fyi (systemd/apparmor backscroll) ^ | 14:21 |
| pitti | jdstrand: ah, ok; so I'll see to breaking the dep cycle in some other way | 14:21 |
| jdstrand | ok, it seems like it might be easier for now | 14:22 |
| === kickinz1 is now known as kickinz1|afk | ||
| jdstrand | well and in the future :) | 14:22 |
| pitti | jdstrand: ok; I was a bit concerned about your "start apparmor as early as possible" request, but if you are happy with starting NFS before, I'm ok with that | 14:23 |
| pitti | fun, that's the third time when the need for a /cache/ pops up | 14:24 |
| pitti | i. e. early-boot cache which is guaranted to be available without NFS, separate partitions, and stuff | 14:24 |
| jdstrand | pitti: happy is strong. we will have apparmor start as early as possible with the cache loading work | 14:24 |
| pitti | jdstrand: well, then the cache can't go on /var | 14:25 |
| jdstrand | it is a bit unfortunate for the initscript since there are profiles available for portmap iirc | 14:25 |
| jdstrand | there are two caches> system cache in /etc and snap/click cache in /var | 14:27 |
| pitti | jdstrand: ah, so once we split the startup scripts into system/click that'd work? | 14:27 |
| jdstrand | maybe | 14:27 |
| pitti | jdstrand: cache in /etc/ is really ugly too, though | 14:28 |
| pitti | jdstrand: perhaps /lib/apparmor/ ? | 14:28 |
| pitti | jdstrand: hwdb.bin is a similar case, I ended up putting it into /lib/udev/ | 14:28 |
| jdstrand | /etc is a historical artifact | 14:28 |
| jdstrand | we've discussed moving /etc/apparmor.d/cache in the past. looks like we'll need to discuss it again | 14:29 |
| jdstrand | the thing is-- currently snaps with systemd jobs have their cache in /var/cache/apparmor. I think those units all have Requires=apparmor.service | 14:31 |
| jdstrand | so they should be ok | 14:31 |
| pitti | jdstrand: on snappy and touch that shouldn't matter at all; we ship a single root fs, no /var on NFS | 14:32 |
| jdstrand | but I feel like we need to revisit the cache locations and timing of things for when libapparmor supports cache loading (and therefore systemd can use it) | 14:33 |
| jdstrand | tyhicks: fyi (please see backscroll for last 15 minutes or so) | 14:33 |
| pitti | jdstrand: ok, so for now you want me to revert that, and have NFS start before apparmor? | 14:33 |
| jdstrand | pitti: I think for today, that is the best option | 14:34 |
| pitti | and we revisit after the cache work/job split? | 14:34 |
| pitti | jdstrand: ack; thanks for the heads-up! sorry for the misunderstanding | 14:34 |
| jdstrand | pitti: I noticed on snappy the other day dhclient was running unconfined. if we don't land the cache work, we'll need to deal with that in some way. perhaps some of that thinking might be put towards portmap profile | 14:35 |
| jdstrand | pitti: thanks for the discussion-- now we'll think about it and discuss it as upstream | 14:36 |
| doko | xnox, boost ping | 14:37 |
| xnox | doko: yo, what about it? | 14:37 |
| * xnox doesn't recall a boost ping - you mean gcc5 fixing? | 14:38 | |
| doko | =) | 14:38 |
| doko | xnox, afaiu 1.57 is ready for GCC 5 | 14:38 |
| xnox | doko: *sigh* | 14:39 |
| xnox | doko: i could transition, but in W not in V | 14:39 |
| doko | yeah, v is a bit late ... | 14:40 |
| xnox | doko: well, and debian experimental i guess | 14:40 |
| pitti | jdstrand: hm, that's tricky; this means that network.target, pollinate, and more all need to sort themselves before apparmor, on really early boot | 14:52 |
| doko | tjaalton, you're the X guy, aren't you? xauth gained new b-d's. could you file MIR's? | 14:58 |
| doko | didrocks, https://bugs.launchpad.net/ubuntu/+source/grilo-plugins/+bug/1394731 this still has the recommends. is this intended? | 15:00 |
| ubottu | Launchpad bug 1394731 in grilo-plugins (Ubuntu) "[MIR] grilo-plugins" [Undecided,Fix committed] | 15:00 |
| didrocks | doko: I guess the deal was to not promote that binary | 15:02 |
| didrocks | darkxst: that's right, isn't it? ^ | 15:02 |
| smoser | hey.. | 15:03 |
| smoser | i have a problem seems like might ave been solved before. | 15:04 |
| smoser | curtin runs in python2[.7] or python3. | 15:04 |
| smoser | cloud-images in vivid no longer have python-yaml (python2) | 15:04 |
| smoser | cloud-images in precise do not have python3-yaml (or python3 at all). | 15:05 |
| tjaalton | doko: ok | 15:05 |
| smoser | what i'd like is a /usr/bin/python3or2 that ran 3 if possible, otherwise ran 2 | 15:05 |
| smoser | i'm guessing that is a problem that someone else has seen and solved. | 15:06 |
| smoser | barry, ^ maybe ? | 15:06 |
| pitti | jdstrand: just for the rationale: currently /var/cache/apparmor/ is empty for me -- why is it needed to have /var for apparmor? | 15:07 |
| pitti | jdstrand: (other than on touch/snappy where /var on NFS isn't an option) | 15:07 |
| doko | smoser, I don't think this can work, because you can't ensure that every module is provided for one interpreter | 15:08 |
| barry | smoser: the windows launcher has that iirc. it's been discussed several times in various python forums, but so far nothing exists for *nix afaik | 15:08 |
| pitti | jdstrand: i. e. right now the cache actually is in /etc/? or am I missing anything? | 15:09 |
| smoser | doko, well, with the help of a 'python -m some_checker_module' you could. | 15:09 |
| slangasek | pitti, cyphermox: ok, looks like we should just drop the console-setup-freebsd binary package, thanks for the pointer | 15:09 |
| tjaalton | cjwatson: do you remember why our xauth is marked M-A: foreign? to fulfil some cross-arch dependency? | 15:09 |
| smoser | and in this simplistic case , it'd be good enough to 'python3 -c "sys.exit(0)"' as a test. | 15:10 |
| barry | make be should call it /usr/bin/python2.8 :) | 15:10 |
| barry | *maybe we* -- jeebus | 15:10 |
| cyphermox | slangasek: agreed, I was working on that just now | 15:12 |
| slangasek | cyphermox: great, I'll leave you to it | 15:13 |
| pitti | jdstrand: also, /etc/init/apparmor.conf runs before NFS and mounting /var too? | 15:13 |
| jdstrand | pitti: /etc/apparmor.d/cache is for any profiles in /etc/apparmor.d. profiles shipped in debs are put in /etc/apparmor.d/ | 15:15 |
| doko | smoser, but how do you express this using package dependencies? | 15:16 |
| jdstrand | pitti: /var/cache/apparmor is for any profiles in /var/lib/apparmor/profiles. profiles for clicks and snaps are generated and put in /var/lib/apparmor/profiles | 15:16 |
| pitti | jdstrand: right; my question was (1) what is in /var/cache/apparmor (I don't have that here), and (2) if that's important, how does /var on NFS work under upstart? | 15:16 |
| ogra_ | pitti, click app profiles | 15:16 |
| ogra_ | (which we plan to support on desktop iirc) | 15:17 |
| pitti | ogra_: right; but I still fail to see how you can have /var/lib/apparmor on NFS under upstart | 15:17 |
| pitti | it's a pretty drastic cyclic dependency | 15:17 |
| pitti | (and we don't currently have it) | 15:17 |
| ogra_ | no idea, i havent use NFS in 8 years or so :) | 15:18 |
| pitti | /etc/init/apparmor.conf is "start on starting rc-sysinit", it makes no effort to wait for NFS or /var etc. | 15:18 |
| ogra_ | (on the phone it has ano override ... that set "start on lightdm") | 15:19 |
| ogra_ | err | 15:19 |
| ogra_ | start on startin | 15:19 |
| ogra_ | g | 15:19 |
| jdstrand | pitti: I don't recall if NFS /var and apparmor worked with apparmor. perhaps mdeslaur recalls? istr we may have discussed it | 15:19 |
| cjwatson | tjaalton: It can be depended on to provide an interface (i.e. /usr/bin/xauth), isn't coinstallable with other versions of itself, and that interface isn't architecture-dependent; that's reason enough | 15:20 |
| cjwatson | tjaalton: I expect there was probably a dependency or build-dependency somewhere that made this useful, yes, though I don't remember what | 15:20 |
| cjwatson | tjaalton: Oh, I filed a Debian bug and gave some reasoning. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695087 | 15:21 |
| ubottu | Debian bug 695087 in xauth "xauth: Please mark Multi-Arch: foreign" [Wishlist,Open] | 15:21 |
| jdstrand | pitti: apparmor aside, I think we are getting back to the previous question-- is NFS mounted /var even expected to work on Ubuntu at all? | 15:22 |
| jdstrand | and I don't have an answer to that | 15:22 |
| pitti | jdstrand: I don't know :/ | 15:22 |
| jdstrand | seems logging would break pretty hard | 15:22 |
| mdeslaur | pitti: yes, but rc.sysinit is start on filesystem | 15:22 |
| pitti | well, people might expect it :) but I have no idea whether it actually works | 15:22 |
| jdstrand | slangasek: hey-- is /var mounted on NFS supposed to work? | 15:22 |
| mdeslaur | pitti: filesystem includes local-filesystems and remote | 15:23 |
| smoser | doko, yeah, from a package perspective not easily solved. | 15:23 |
| pitti | mdeslaur: ah, ok; so under upstart we also let rpcbind, the nfs daemons, pollinate, and whatnot run before, so that we can't apparmor-protect them? | 15:23 |
| pitti | we can do that, it just seems the wrong way around to me | 15:24 |
| mdeslaur | pitti: right, but we do need to protect the dhclient that gets run as part of the network interface coming up | 15:24 |
| jdstrand | with upstart we had a bunch of patches for updating upstart jobs | 15:24 |
| slangasek | jdstrand: I'd say it's known to not work, because of /var/lib/nfs | 15:24 |
| jdstrand | slangasek: oh, heh | 15:24 |
| mdeslaur | pitti: which is why apparmor cache is in /etc, and not in /var | 15:24 |
| pitti | mdeslaur: but then /etc/init/apparmor.conf would run too late? | 15:25 |
| jdstrand | mdeslaur: so, there is /var/cache/apparmor for clicks/snaps. we may need to rethink that | 15:25 |
| ogra_ | pitti, bug 525154 claims it worked once (after this was fixed) | 15:25 |
| ubottu | bug 525154 in nfs-utils (Ubuntu Natty) "mountall for /var or other nfs mount races with rpc.statd" [High,Fix released] https://launchpad.net/bugs/525154 | 15:25 |
| pitti | mdeslaur: right; I think it's correct to have apparmor caches on the root fs (just perhaps not in /etc/, but that's a different question) | 15:25 |
| slangasek | jdstrand: there are some things that can be moved to /run (and have been), but /var/lib/nfs is used for the lock state across reboots... not sure what we do with that, except for perhaps breaking lockd | 15:25 |
| mdeslaur | pitti: yes, which is why we have apparmor hooks in a whole slew of other upstart jobs and the ifup scripts | 15:25 |
| tjaalton | cjwatson: oh good, I'll check that and commit it there if pkg-xorg doesn't oppose | 15:26 |
| jdstrand | our goal with proper apparmor cache loading and systemd is to clean all this up | 15:26 |
| mdeslaur | jdstrand: yes, but at that point, /var is guaranteed to be mounted | 15:27 |
| jdstrand | mdeslaur: yes, but when we have the libapparmor patches, it may not be | 15:27 |
| mdeslaur | jdstrand: oh, wait, you're using that for snaps now, yeah, that's no good | 15:27 |
| mdeslaur | jdstrand: it was ok with click packages, but not for snaps | 15:28 |
| jdstrand | mdeslaur: snaps are actually covered cause they depend on apparmor | 15:28 |
| jdstrand | in their job file | 15:28 |
| jdstrand | Requires=apparmor.service | 15:28 |
| pitti | (After=, I hope) | 15:28 |
| jdstrand | After=apparmor.service | 15:28 |
| jdstrand | yes, both | 15:28 |
| mdeslaur | jdstrand: and apparmor depends on all the local filesystems? | 15:28 |
| mdeslaur | including /var? | 15:28 |
| jdstrand | mdeslaur: well, that is what pitti is looking at | 15:29 |
| pitti | mdeslaur: local-fs, yes | 15:29 |
| mdeslaur | right | 15:29 |
| pitti | mdeslaur: the question was about $remote_fs -- i. e. if /var is on NFS | 15:29 |
| pitti | IMO we should not have caches which we require on early boot on a potential NFS dir, it's just crying for trouble | 15:29 |
| pitti | (and as you said yourself, it's a pain to get to work) | 15:30 |
| mdeslaur | right | 15:30 |
| jdstrand | mdeslaur: I think we need to discuss this with tyhicks and sbeattie. we should be collecting the requirements here and add them to what we know, then come up with a plan | 15:30 |
| * jdstrand has to go to a meeing | 15:31 | |
| mdeslaur | jdstrand: the plan is to move apparmor to the right place in systemd | 15:31 |
| pitti | well, we could split it | 15:31 |
| jdstrand | mdeslaur: yes. and that may mean we move dirs around | 15:31 |
| pitti | /etc/init.d/appamor for loading /etc/apparmor for early boot, and another one for /var for clicks etc. | 15:31 |
| pitti | (or keeping /etc/init.d/apparmor for the late one, and an apparmor-early for the early boot) | 15:31 |
| jdstrand | we already know we need 2 stages: first to load caches, and the next to regenerate the caches in case they are out of date | 15:31 |
| pitti | or declare that you can't have click/snap packages with /var on NFS | 15:32 |
| jdstrand | (since libapparmor will only load caches, not compile them) | 15:32 |
| mdeslaur | yeah, we could split it out | 15:32 |
| mdeslaur | but if /var on nfs is known not to work at the moment, perhaps we don't care | 15:32 |
| pitti | it's not known to work; it hasn't been shown to not work | 15:33 |
| pitti | mdeslaur: the trouble would only be with /var on NFS on a system which uses click, right? | 15:33 |
| cjwatson | tjaalton: Probably shouldn't, I expect it's just an oversight - I think pkg-xorg has accepted other similar stuff from me | 15:33 |
| pitti | but on the pro side we'd have all the networking/NFS/portmap/DHCP parts covered | 15:33 |
| jdstrand | we really want all those parts covered | 15:34 |
| flexiondotorg | I've just fixed the following bug - https://bugs.launchpad.net/ubuntu-mate/+bug/1422402 | 15:34 |
| ubottu | Launchpad bug 1422402 in ubuntu-mate "Shell Command Injection in places.py plugin of mate-menu package" [High,Fix committed] | 15:34 |
| tjaalton | cjwatson: indeed | 15:34 |
| mdeslaur | pitti: what about /usr on nfs? | 15:34 |
| flexiondotorg | I would like to raise a bug to package a new version of mate-menu. | 15:34 |
| pitti | mdeslaur: that's just sheer madness :) | 15:34 |
| mdeslaur | does that work and so people do that? | 15:34 |
| jdstrand | what we have with upstart now is a confusing mess. I mean it works, but it is hard to keep straight. not something you really want when dealing with loading security policy | 15:35 |
| flexiondotorg | Should it be flagged as security related given the bug it addresses? | 15:35 |
| mdeslaur | ok, good, didn't know what is typically done | 15:35 |
| pitti | mdeslaur: more seriously, I haven't seen it, and I don't believe that it works until I see it | 15:35 |
| pitti | mdeslaur: AFAIR in the last meeting we said that /usr/ on a separate partition must work, but /usr on NFS can't | 15:35 |
| mdeslaur | pitti: ok, cool | 15:35 |
| pitti | mdeslaur: for once all the nfs/rpc daemons are in /usr/sbin :) | 15:36 |
| mdeslaur | do we know what is causing the dhclient race? | 15:36 |
| pitti | ah no, not all of them | 15:36 |
| pitti | some are in /sbin/ | 15:36 |
| === kickinz1|afk is now known as kickinz1 | ||
| doko | neutron-lbaas: python-neutron-lbaas | 15:44 |
| doko | [Reverse-Depends: neutron-lbaas-agent (MAIN)] | 15:44 |
| doko | zul, jamespage: ^^^ did the source change? | 15:44 |
| zul | doko: yeah it got split out into its own tree upstream | 15:45 |
| doko | ok, thanks | 15:45 |
| doko | Mirv, qtbase-opensource-src recommends qttranslations-opensource-src (universe). MIR or suggests? | 15:48 |
| tyhicks | mdeslaur: no - we don't know what is causing the race yet | 15:48 |
| doko | barry, there's a lot of python* component mismatches. could you have a look? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 15:49 |
| tyhicks | mdeslaur: steve is supposed to be looking at it more this week | 15:49 |
| barry | doko: i'll look. i don't know when i'll have time to do anything about it :( | 15:51 |
| doko | Laney, you uploaded remmina, needing two MIR's | 15:54 |
| Laney | I think not | 15:54 |
| Laney | that nx thing shouldn't be in main | 15:55 |
| doko | Laney, at least your name is on the changelog ;-P | 15:55 |
| Laney | demote it (with remmina-dbg)? | 15:55 |
| doko | Laney, so demote the binary? | 15:56 |
| Laney | go for it | 15:56 |
| Laney | thanks | 15:56 |
| pitti | kees, slangasek, stgraber, infinity: TB meeting in 2 mins (reminder) | 15:58 |
| pitti | mdeslaur: ^ | 16:00 |
| === kickinz1 is now known as kickinz1|afk | ||
| === kickinz1|afk is now known as kickinz1 | ||
| === beisner- is now known as beisner | ||
| === anthonyf is now known as Guest62520 | ||
| mdeslaur | @pilot out | 16:47 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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: | ||
| pitti | kees, slangasek, stgraber, infinity, mdeslaur: TB meeting in 3 mins, this time for real :) (sorry for confusion) | 16:58 |
| slangasek | :) | 16:58 |
| mdeslaur | hehe | 16:58 |
| slangasek | stgraber: I think you're on for chairing today? | 17:00 |
| pitti | slangasek: would you like to review the nfs patches, BTW? | 17:01 |
| pitti | or should I just upload them? | 17:01 |
| slangasek | pitti: in principle yes, but I don't think I'd be able to get to it today | 17:02 |
| pitti | slangasek: in the next days would be enough; I started the FFE, and we have some other thigns to be done for that | 17:02 |
| === Guest72440 is now known as rcj | ||
| pitti | Unit193: did you test current xubuntu under systemd? (Given how much we talked about it, I suppose yes, but just to avoid doubts..) | 17:04 |
| === kickinz1 is now known as kickinz1|afk | ||
| ericsnow | quick question: is vivid going to switch to using systemd for PID 1 at some point? | 17:35 |
| Odd_Bloke | ericsnow: I've heard that it's expected to happen some time in the next week. | 17:41 |
| ericsnow | Odd_Bloke: ah, thanks | 17:41 |
| Odd_Bloke | ericsnow: *waves hands* | 17:41 |
| ericsnow | :) | 17:42 |
| doko | Logan, infinity: the librdkafka sync broke powerpc. this probably needs to be restored | 17:48 |
| Logan | I'll take a look | 17:48 |
| Logan | doko: yeah, looks like Adam's patch needs to be restored | 17:51 |
| Logan | doko: shall I do an MP? I don't have upload access to main | 17:52 |
| doko | Logan, please check with infinity, eod for me | 17:57 |
| Logan | sure :) | 17:57 |
| Unit193 | pitti: And still running under it, yep. There seems to have been a couple glitches, but nothing consistent. | 18:49 |
| Noskcaj | Is anyone planning to merge meta-gnome3? It would be nice to have it updated for our current gnome packages | 19:55 |
| jtaylor | mh someone know how one subscribes to the glibc list? | 20:01 |
| jtaylor | ah found it, hidden away on the website not the list archive .. | 20:02 |
| smoser | is this bug known? https://bugs.launchpad.net/ubuntu/+bug/1427821 | 20:02 |
| ubottu | Launchpad bug 1427821 in Ubuntu "server iso install fails during grub install" [Critical,Confirmed] | 20:02 |
| smoser | i dont know if it applies to server iso or not. | 20:03 |
| smoser | er... if it applies to desktop or not. | 20:03 |
| smoser | i kind of suspect not. | 20:03 |
| infinity | smoser: Not a bug I'm aware of, will have to give it a try later. | 20:16 |
| cyphermox | smoser: that looks like a fun bug | 20:19 |
| doko | tumbleweed, online? | 20:26 |
| doko | tumbleweed, what is the rationale for a separate /usr/lib/pypy hierarchy? | 20:30 |
| tumbleweed | doko: hi | 20:46 |
| tumbleweed | you mean dist-packages-wise? | 20:46 |
| doko | tumbleweed, yes | 20:48 |
| tumbleweed | incompatible .pyc files. One would be using __pyshared__ and the other wouldn't | 20:48 |
| tumbleweed | unless we'd symlink-farmed | 20:49 |
| tumbleweed | and there's no reasonable way to do transitive dependencies | 20:49 |
| doko | well, cpython looks up __pycache__, why not pypy? | 20:49 |
| tumbleweed | in 3.x, yes | 20:49 |
| tumbleweed | I plan to share dist-packages for 3.x | 20:49 |
| doko | yeah, that would be really useful | 20:50 |
| doko | are you at PyCon? | 20:50 |
| tumbleweed | been meaning to talk to you about that | 20:50 |
| tumbleweed | yes, I will be | 20:50 |
| doko | let's meet before PyCon, or at the sprints | 20:50 |
| tumbleweed | only arriving on the thursday, but I'll be at the sprints | 20:51 |
| === salem_ is now known as _salem | ||
| staylor | I'm curious about a good way to handle an issue I'm having, I have an amd64 host and have used multilib to install arm cross compilers and libraries but since -dev libraries install the .so library links yet can only be installed for a single arch I'm wondering how to handle this (short of manually creating the symlinks). | 21:09 |
| dobey | multi-arch packages are installed in the proper places | 21:19 |
| dobey | but if you want to cross-compile .deb packages, you should probably look at just using sbuild to do it | 21:19 |
| infinity | staylor: Chroots are the way to go, one for native, one for each cross arch. | 21:23 |
| infinity | staylor: Having one messy base system that attempts to build for everything will end in misery. | 21:23 |
| staylor | I don't see what's messy about software installing itself logically but I guess chroot is the only way right now. | 21:23 |
| dobey | everything in the archive doesn't support multi-arch yet | 21:26 |
| dobey | so it gets messy quickly | 21:26 |
| staylor | is moving .so from -dev to the base lib package something that's on the roadmap though? | 21:26 |
| dobey | why would one move .so from -dev to the base lib package? | 21:27 |
| dobey | it's possible to install -dev and -dev:armhf for packages that support multi-arch | 21:28 |
| staylor | I see okay I didn't realize nothing supports multiarch yet | 21:29 |
| dobey | lots of things do | 21:29 |
| dobey | i don't know what you're specifically dealing with though. and building packages in clean chroots is always best anyway | 21:29 |
| staylor | well glib for one, but I concede chroot seems the way to go | 21:30 |
| dobey | the number of times people have built debs locally "just fine" and then had the builds fail in a PPA because they forgot to add things to build-depends, is innumerable | 21:32 |
| dobey | ah, the problem with libglib2.0-dev is that it has some things in /usr/bin | 21:33 |
| dobey | so that creates conflicts when you try to install the dev package for another arch | 21:33 |
| staylor | yeah for packaging I see what you mean and that makes perfect sense, here I am setting up a cross compile environment for developers needing to target arm boards from their workstations so different needs and expecations. | 21:34 |
| dobey | still, chroots are better and make management easier | 21:35 |
| Bluefoxicy | infinity: if I gave you a reliable way to install multiple conflicting versions of a .so on a system so you could have different applications use different versions, how useful would that be? | 23:21 |
| tmpRAOF | Bluefoxicy: Are you describing SOVER? | 23:30 |
| * tmpRAOF is not sure if serious. | 23:30 | |
| Bluefoxicy | tmpRAOF: https://github.com/bluefoxicy/dpkg-ng/blob/master/README.md | 23:31 |
| Bluefoxicy | tmpRAOF: I never got anywhere because I have nfc what i'm doing :3 | 23:31 |
| Bluefoxicy | I mean, rewriting dpkg is kind of a big task | 23:32 |
| Bluefoxicy | tmpRAOF: the way Nix does it is silly. If your binary uses 40 libraries, it puts in 40 runpaths pointing to very specific versions of the packages. | 23:33 |
| tmpRAOF | So, the Debian library packaging policy makes ‘installing different versions of the library and link different applications against them’ work. | 23:34 |
| Bluefoxicy | I figured you would just make the runpath point at /usr/package/$PACKAGE/$VERSION/lib/ first | 23:34 |
| Bluefoxicy | tmpRAOF: you can install conflicting libs? | 23:34 |
| tmpRAOF | Absolutely. | 23:34 |
| tmpRAOF | Or, rather, you can install libfoo3 and libfoo2 at the same time, and dependencies will be resolved appropriately. | 23:34 |
| Bluefoxicy | no | 23:35 |
| Bluefoxicy | libfoo3 installs /usr/lib/libfoo.so.3 | 23:35 |
| Bluefoxicy | libfoo2 installs /usr/lib/libfoo.so.2 | 23:35 |
| sarnold | see e.g. libssl0.9.8 and libssl1.0.0 .. | 23:35 |
| Bluefoxicy | but how do you install libfoo3.1 and libfoo3.1.1? | 23:35 |
| tmpRAOF | Bluefoxicy: The immediate question is ‘why do you want to?’ :) | 23:35 |
| Bluefoxicy | how do you install libmysql.so.5 from Percona and libmysql.so.5 from Mariadb? | 23:35 |
| tmpRAOF | Ah. | 23:36 |
| Bluefoxicy | tmpRAOF: sometimes you have non-backwards-compat libraries | 23:36 |
| tmpRAOF | Bluefoxicy: Right, and in that case it's up to the *library* package to change from libfoo2 to libfoo3. | 23:36 |
| Bluefoxicy | tmpRAOF: This would happen basically constantly if you had a rolling release, too | 23:36 |
| tmpRAOF | It absolutely doesn't; Debian Sid manages just fine. | 23:37 |
| tmpRAOF | So, as I see it, Nix satisfies the “I want my program to link against _exactly_ the code that I've tested it against” desire. | 23:37 |
| tmpRAOF | Which is a perfectly reasonable one. | 23:37 |
| Bluefoxicy | yeah, though I think the NixOS guys are insane | 23:38 |
| tmpRAOF | Regular distros satisfy the “I want my program to work, and benefit from bug fixes in my dependencies without me rebuilding every time one of my dependencies change” desire, which is also perfectly reasonable. | 23:38 |
| Bluefoxicy | it'd make more sense to have e.g. percona-5.2 look in /usr/packages/percona-5.2/lib for libraries first, and put anything specifically selected for percona as a symlink there | 23:38 |
| Bluefoxicy | i.e. normally, that directory would be empty or non-existent | 23:39 |
| jtaylor | kind of like limba? | 23:39 |
| jtaylor | install everything at once but each app only sees the set it wants | 23:39 |
| jtaylor | http://people.freedesktop.org/~mak/limba/ | 23:39 |
| Bluefoxicy | if your package manager goes, "You can't upgrade $LIBX because Percona will break, and you can't install $FOO because it requires a newer $LIBX", it shuffles current $LIBX into /usr/packages/libx-1.0.0/lib/libx.so.1 and symlinks to it from percona's lib; upgrades libx; and installs foo | 23:40 |
| Bluefoxicy | because screw that; conflicts shouldn't prevent me from having two pieces of software installed at the same time | 23:40 |
| Bluefoxicy | jtaylor: interesting. | 23:41 |
| jtaylor | conda also has a similar approach | 23:41 |
| tmpRAOF | Bluefoxicy: How does the package manager know that you can't upgrade libX? | 23:41 |
| Bluefoxicy | tmpRAOF: Conflict: | 23:42 |
| tmpRAOF | Bluefoxicy: So libx version 1.1 needs to Conflict with all the packages it might potentially break? | 23:43 |
| tmpRAOF | Why isn't it bumping SONAME? | 23:43 |
| Bluefoxicy | tmpRAOF: dpkg notes that you need some lib = some version, > some version, < some version, etc; and that some libs can't be installed at the same time; etc. It has a pretty complex dependency resolution system that sometimes tells you you need to remove some packages to install others, or that you can't install two things at the same time because they depend on things that can't be installed at the same time. | 23:44 |
| tmpRAOF | Ah, so *percona* has a Depends: libx = 1.0? | 23:45 |
| Bluefoxicy | eh, percona, maria, and mysql are special cases | 23:45 |
| Bluefoxicy | tehy all install libmysql | 23:45 |
| Bluefoxicy | they all REPLACE each other | 23:45 |
| Bluefoxicy | of course, you get the oddness where libx from some package replaces libx from another, and adds extensions. Different extensions from another replacement. Then you get dependencies on one or the other by specific applications, which can't be simultaneously installed. | 23:46 |
| Bluefoxicy | it's been a while since I've actually cared | 23:46 |
| Bluefoxicy | I was more trying to gauge if it seemed relevant to anyone at this point. | 23:47 |
| Bluefoxicy | The last time I remember it being relevant to everyone in the world, all at once, was when gtk+ was dealing with 1.2 vs 2.0, because gtk+ breaks backwards binary compatibility a lot. | 23:47 |
| infinity | Bluefoxicy: The solution to people not bumping their SOVER is to bump their SOVER, not reinvent the wheel. | 23:47 |
| infinity | Bluefoxicy: And the github-style "use this exact version, or else" mentality is a security vulnerability nightmare. No sane person should try to replicate it, but instead educate them. | 23:48 |
| Bluefoxicy | infinity: thats' why I think the nix approach is insane, versus a "this specifically doesn't work unless you use this version" approach | 23:49 |
| infinity | Bluefoxicy: percona/maria/mysql is a non-problem, FWIW, the servers don't need libmysqlclient, and the clients can all use the one from mysql. | 23:49 |
| infinity | Bluefoxicy: And, again, if that changes, the SONAME should too. | 23:49 |
| Bluefoxicy | rtue | 23:49 |
| Bluefoxicy | true | 23:49 |
| Bluefoxicy | so the current solution is to eliminate all situations where packages have any conflicts, so that all packages in the repository can be installed simultaneously on one system | 23:50 |
| infinity | We define stable ABIs for a reason, if upstreams break that, we educate them. | 23:50 |
| infinity | Eliminating all conflicts is a bit harder, and pretty pointless. | 23:50 |
| infinity | Why do you need 7 things that all provide /usr/sbin/sendmail? | 23:50 |
| Bluefoxicy | heh | 23:51 |
| Bluefoxicy | good point | 23:51 |
| infinity | Anyhow, the forking library case (like percona/maria) is a pretty uncommon one, and the answer is for them to change the SONAME if they stop being compatible with libmysqlclient. | 23:53 |
| infinity | But the GTK example you pointed out is a non-issue, 1.2 and 2.0 could always be installed together. | 23:53 |
| infinity | They couldn't be linked together in the same memory space, but that's a problem no matter how clever you make your filesystem layout, you just need to make sure you don't accidentally do that. :P | 23:53 |
| Bluefoxicy | pizza delivery special instructions | 23:54 |
| Bluefoxicy | "Leave the pizza in front of the door; then turn around and walk away slowly. Don't look back." | 23:54 |
| Bluefoxicy | infinity: there was an issue for a while where you had to recompile for gtk+ in the 1.2 days. Some commercial applications (AIM, Yahoo Messenger) broke because they were compiled against a prior minor point release. | 23:55 |
| Bluefoxicy | they enjoyed keeping the same function calls and such so your code would work, but changing structures used internally. | 23:56 |
| Bluefoxicy | as a result, malloc(sizeof(opaque_struct)) would allocate the wrong size | 23:56 |
| Bluefoxicy | or whatever else | 23:56 |
| Bluefoxicy | it was incredibly bad programming practice | 23:57 |
| Bluefoxicy | maybe people have been beaten enough to learn not to do that in the past 10 years | 23:57 |
| jtaylor | no, even glibc devs still do that ;) | 23:57 |
| jtaylor | (see s390x abi break in 2.18 or 19) | 23:57 |
| Bluefoxicy | yes but that's drepper | 23:57 |
| sarnold | jtaylor: surely they called all six users to give them a heads up? :) | 23:58 |
| Bluefoxicy | jtaylor: tell Drepper next time he breaks s390x, he has to publish a Youtube documentary of his p90x | 23:59 |
| infinity | It hasn't been drepper for a long time. | 23:59 |
| jtaylor | drepper is not involved since a while | 23:59 |
| Bluefoxicy | looks like I'm very out of date | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
