[00:03] Is there a (dpkg/dh_*) tool for listing a debian/control file's dependencies for a specific architecture? (The control file at hand contains [arch] and '|' conditions, and I'd rather avoid having to make my own parser if I can) [00:05] sveinse: Deps, or build-deps? (Deps generally also involve ${misc:Depends} etc. which isn't really knowable without doing the build) [00:06] For build-deps, /usr/lib/pbuilder/pbuilder-satisfydepends in some form might be useful [00:09] geofft: Deps. If I can get a list where ${misc:Depends} is one of them, I would be happy. It's the arch specific constraints I need to filter out [00:10] geofft: OOI and slightly OT, what is ${misc:Depends} replaced by normally? I always use it, but I've never asked why [00:12] well, for the latter, Google is a friend, so forget it [00:12] also grep misc:Depends /usr/bin/dh_* :) [00:13] hm, looks like last time I wanted this, I used the Dpkg::Deps perl module, which gives me a deps_parse function [00:14] http://web.mit.edu/geofft/debathena/dh-ifexists/dh_ifexists [00:14] (note that that command is a slightly terrible idea, I'm only posting it as sample code) [00:15] Do I understand things correctly that dh_* never actually parses Deps, only put it into the pkg's control file? So a dep of "pkg1[armel] | pkg2[armhf] | pkg3" is never actually parsed by dh_* [00:18] hmm. Seems like a custom parser is unavoidable :( [00:19] sveinse: That has nothing to do with debhelper at all, it's dpkg-gencontrol. But if what you want to say is "if I'm on armel, I want pkg1, if I'm on armhf, I want pkg2, else I want pkg3", you want "pkg1 [armel], pkg2 [armhf], pkg3 [!armel !armhf]" and dpkg-gencontrol filters the right ones for the right arch builds. [00:20] infinity: Ah, so you can put more than one constraint (e.g. [!armel !armhf]). I was looking for that in the policy manual, but could not find any about that === freeflying_away is now known as freeflying === _salem is now known as salem_ === salem_ is now known as _salem === GridCube_ is now known as GridCube [02:13] xnox, just saw your comment about installing grub on fakeraid arrays.. it will need some work to keep that going with the mdadm transition... looking for that thread I started on it a while back now === saurik_ is now known as saurik === shuduo_afk is now known as shuduo [05:35] Good morning [05:36] infinity: can I talk you into accepting the SRUs for bug 1257211? (fairly mechanical; all upstream/distro tested, no packaging changes, has MRE); it's a relatively important data loss fix this time [05:36] bug 1257211 in postgresql-9.1 (Ubuntu Saucy) "New upstream microreleases 9.1.11, 8.4.19" [High,In progress] https://launchpad.net/bugs/1257211 [05:42] pitti: Let me have a quick look. [05:43] pitti: 6 of them? Okay, a slightly less quick look. [05:43] infinity: yeah, I'm afraid so :/ they all look the same though [05:46] pitti: The 0 changes to debian/* is comforting. Do the orig tarballs come directly from upstream, or get repacked in annoying ways? [05:47] infinity: nope, straight from upstream [05:47] shared between upstream, debian, ubuntu, and apt.postgresql.org [05:47] Oh, heh, found one with a change to debian. :) [05:48] (Just the update-maintainer flip) [05:48] ah yes, first SRU to saucy [05:48] Indeed. [05:48] So, I think I'll just verify hashes on the upstream tarballs and call it good enough, due to the MRE. [05:48] dpkg-buildpackage would otherwise barf at me, so update-maintainer is less annoying than always rebuilding with DEBEMAIL= [05:48] pitti: Yeah, I always listen to dpkg-buildpackage about that too. [05:49] pitti: Which is good, since that was the point of the policy. :P [05:52] pitti: Right, those all match, thanks for making my life easy. [05:53] infinity: fortunately the days when we had an upstream tar.bz wrapped in a custom debian orig.tar.gz are over with hardy being EOL [05:54] pitti: Yeah. I maintain packages that need to dfsg cleansing business, so it's nice to run into ones that don't. :P [05:54] s/to/the/ [05:54] infinity: yeah, it's really quite mechanical, but always better to have four eyes on it (and cross-check that I put in the right bug number, etc.) [05:54] of course I did *not* (no, no!) rebuild the sources ever because I accidentally put in the one for the previous SRU *cough* [05:55] ;) [05:56] pitti: I assume we're moving to 9.2 for trusty? [05:56] infinity: 9.3 [05:56] Ooo, or that. Shiny. [05:56] infinity: I have it on my list to weed out the remaining 9.1 rdeps, and reduce p-9.1 to -plperl [05:56] we need that for upgrades due to libperl non-coinstallability [05:56] (similar to what I do in unstable for wheezy) [05:56] It never ceases to amaze me that people implementing a decades-old spec keep finding new ways to add features and pump out new versions. [05:57] infinity: postgresql? [05:57] infinity: or perl? [05:57] lifeless: psql. [05:58] infinity: I think they could be there another few decades; sql was a very theoretical spec, so there's huge sets of optimisations folk are only just touching on [05:58] (That wonderment is a bit ironic, given that my largest upstream involvement is in a project implementing POSIX/SUS C) [06:00] pitti: Alright, I think that's all of 'em. [06:00] infinity: cheers [06:01] I'll treat them with my p-common test torture for verification once they are built/published === jono is now known as Guest52213 [06:29] is there a way to add an apport hook for a project? [06:29] aiui it's possible to file bugs against source/binary packages [06:29] but dunno if the same is true for projects [06:29] pretty sure you can [06:29] mainly for attaching bug logs [06:30] tjaalton: you can add an apport hook to a package which makes bugs go to the project [06:30] (common for e. g. PPA packages) [06:30] pitti: how about private projects then? [06:30] tjaalton: the hook can also check easily if the package is from ubuntu or not [06:31] tjaalton: if you put it into a PPA which only people can access that can also file bugs to that private project, sure [06:31] ahh, yeah that works then [06:31] tammy: ^ :) [06:31] pitti: thanks [07:33] good morning [08:23] barry, pitti I fixed adt notifications. LP credentials had not been migrated from previous server. It is now saved in a non-default launchpadlib_dir that will make migration easier just in case this service had to move again. === funkyHat_ is now known as funkyHat === EntropyWorks_ is now known as EntropyWorks === czchen_ is now known as czchen === warp10_ is now known as warp10 === mvo_ is now known as mvo === pitti_ is now known as pitti [08:49] sarnold, roaksoax: is maas heavily dependent on the psql version 9.1? (I just filed bug 1258442) [08:49] bug 1258442 in maas (Ubuntu) "Move to postgresql-9.3" [Undecided,New] https://launchpad.net/bugs/1258442 [08:50] if it isn't very version sensitive, then I'd recommend the versionless metapackage as an alternative; if you'd rather only allow explicitly tested psql versions, then just "-9.3" will do for now (but prevent usage with newer psqls) === mthaddon` is now known as mthaddon === ochosi_ is now known as ochsoi === ochsoi is now known as ochosi === cjwatson_ is now known as cjwatson === yofel_ is now known as yofel === wedgwood is now known as Guest45906 [10:40] pitti: is even suggesting a package from universe prohibited for packages in main? [10:40] tseliot: no, that's fine; suggests aren't installed by default [10:41] pitti: so that could work for bug #1255583, couldn't it? [10:41] bug 1255583 in bbswitch (Ubuntu) " [MIR] Main inclusion request for bbswitch" [Medium,Incomplete] https://launchpad.net/bugs/1255583 [10:42] tseliot: well, not really; we really want such stuff to use dkms, not m-a [10:42] ok, I'll tell the maintainer === DzAirmaX_ is now known as DzAirmaX === shuduo is now known as shuduo_afk [11:33] pitti, ev: apport is off for releases right? which makes whoopsie off too? [11:33] Riddell: no [11:33] ev: no to which? [11:33] apport doesn't report to Launchpad post-release [11:33] but it still reports to daisy.ubuntu.com (via whoopsie) [11:33] ev: ah hah [11:33] sorry for the terseness there [11:34] Riddell: more precisely, we stop sending crash reports to LP post-release; "ubuntu-bug" (i. e. no-crash manual bug reports) still works [11:35] Riddell: I was talking to apachelogger about apport/KDE yesterday, did you see this in scrollback? (to avoid duplicate work/discussions) [11:35] pitti: I'm working with him now, seems apport has been broken in kubuntu for the last couple of releases and we didn't notice (because it's not used for kde apps) === _salem is now known as salem_ [11:47] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: rbasak [11:51] * dholbach hugs rbasak [11:51] o/ === ivoks_ is now known as ivoks [12:00] mvo, hi, what’s the simplest way you can think of to produce a package that Synaptic will label as “Broken”? :-) [12:03] (e.g. by messing with an existing package) [12:06] mpt, you can probably dpkg -r a depends of an installed package [12:07] mpt, e.g sudo dpkg -r --force-depends evince-common [12:07] mpt: indeed, what seb128 said - sudo apt-get install 4g8; sudo dpkg -r --force-depends libnet1 [12:07] that should make evince unhappy [12:08] * mvo hugs seb128 [12:08] I think I’ll try with 4g8 rather than my favorite PDF viewer 3-) [12:08] mpt: why do you care about synaptic? [12:08] thanks [12:08] * seb128 hugs mvo back ;-) [12:10] mvo, just folloing up on an old bug report [12:43] Will arm64 build failures block proposed migration for unseeded packages? I'm wondering if I can upload a merge that has never worked on arm64 without fixing it. [12:46] rbasak: They will, but only if it has built there before (same as for all architectures: https://wiki.ubuntu.com/ProposedMigration point 1.) [12:53] rbasak: "it must not regress" in architecture list where it does succeed to be built/installable. [12:54] Laney, xnox: aha. Thank you! [14:02] jibel: cool, thanks [14:07] is there any options to apt to get it to log timestamps during apt-get dist-upgrade ? [14:08] i'd like to time an apt-get dist-upgrade and have some info on where the time goes [14:09] smoser: does running it using annotate-output help? [14:10] hloeung, i was unaware of that program. i hacked something similar just now. [14:10] thanks. [14:11] i think log data from apt would probably be more correct. but this might suffice. [14:30] xnox: ddf and imsm aren't quite the same... iirc, there was a check in the grub-install script to see if you were trying to install to a /dev/mapper device that was managed by dmraid, aand allow it to procee, and the grub device iterator code assigned a grub device to the array assuming it was bios accessible [14:33] psusi: can you give me pointers in grub code? [14:45] xnox: iirc, it was in a file named deviter.c [14:45] xnox: and of course, the grub-install script [14:47] xnox: I had a discussion on the mailing lists back in 2010 and I wanted a way to ask mdadm what kind of raid it is and if it is recognizable to the bios... not sure if it was ever added to mdadm [14:48] psusi: there is now, --detail-platform or somesuch, which will print / notify if there are bios recognisable raid devices (that is ddf/ISW controllers that are recognised on boot) [14:49] psusi: subsequently one can start that controller as "container" and see which raid arrays are defined within it, and thus confirm that those raid arrays will be available on boot. [14:53] xnox: the idea is that if you run grub-install /dev/md0 and mdadm says it's a bios recognizable array, then go ahead with installing, and assume it's (hd0) or some other number [14:54] ohh, and there was some logic somewhere to figure out whether grub needs the raid module.. it doesn't if it's a fakeraid [14:55] that was based on where /boot is.. if /boot is on a software raid, it needs the raid module, fakeraid, it doesn't... [14:55] psusi: i've tried grubinstall patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699434 but it didn't work for me on an ISW/RAID0 [14:55] Debian bug 699434 in grub-installer "grub-installer: support for Intel Matrix Raid" [Normal,Open] [14:56] psusi: i see. that patch added a dummy echo "(md/0) $md_bootdev" >> $ROOT/boot/grub/device.map [14:56] which imho is fragile, given that i can have multiple raid devices regornised on boot. [14:57] things are a bit muddied by the fact that Ubuntu is still carrying patches to auto assign grub devices and not use device.map [14:57] (e.g. one for windows and one for debian/ubuntu) [14:57] device.map is deprecated, please don't add new stuff relying on it [14:57] psusi: that statement is exactly the opposite of reality ... [14:57] it is? [14:57] cjwatson: right. what should be used instead of device.map? and how can i make it recognise "fakeraid ISW and DDF" properly? [14:57] psusi: upstream removed grub-mkdevicemap altogether; Ubuntu is carrying patches to put it back because we needed it for some packaging-level code [14:58] (or verify that it does / doesn't) [14:58] Hey. Ubuntu Trusty uses :powerpc specifiers in dependency fields. Is there a spec for that? (Allowing cross-arch deps.) [14:58] I thuoght last time I asked about why I couldn't find deviter.c upstream you said it was ubuntu specific? [14:58] psusi: the use of device.map is deprecated [14:58] pkern: :arch are not allowed, where is that? one is allowed to use :any in the Depends: [14:58] psusi: indeed, but its purpose is not as you describe. the purpose of deviceiter.c is to help generate device.map - i.e. it's part of grub-mkdevicemap [14:58] pkern: and :any is allowed in Debian as well. [14:58] That's not my question. [14:59] cjwatson: I thought it was also used to generate the temporary in memory map so that grub-install could figure out what device is what [14:59] psusi: no [14:59] xnox: crossbuild-essential-powerpc [14:59] Depends: libc6-dev:powerpc [14:59] then how does grub-install decide what grub device to reference? [15:00] I could have sworn that was from deviceiter.c assigning an (hdX) to each disk and an (mdX) to each raid array, etc... [15:00] xnox,psusi: ok, so. there are two cases. for the userspace tools, mostly all we need to be able to do is check whether two devices are the same. for that, it's sufficient to just have an arbitrary sequence that's stable within the run of a given tool. [15:00] pkern: right, that package is a bit special (no wonder it gets stuck in britney proposed migration). The spec is https://wiki.ubuntu.com/MultiarchSpec but at the moment officially supported/endorsed suffixes are ":any" in Depends: in both ubuntu & debian. [15:01] xnox: We're parsing dependencies and our mirroring of trusty is stuck, too. [15:01] It makes sense to me but if you didn't intend to allow it... [15:01] pkern: the fact that :$arch works is nice, but it relies on one adding foreign-arch and have archives available for it. [15:01] Doesn't it "just work" if you have ppc in your cache? [15:01] Yeah, I know that. [15:01] xnox,psusi: the other case is for generating config files (i.e. things that will be used at boot time). for that, we actually don't care whether we know what the GRUB device names are; we generate some in a best effort kind of way, but what we actually depend on in reality is "search --fs-uuid". [15:02] cjwatson: right... and deviceiter.c generates that arbitrary sequence... but without that, then there would be no (hd0) unless you have a device.map wouldn't there? [15:02] People didn't like that for the qemu case. [15:02] pkern: well, we rely on it to enable cross-compilation with multiarch enabled. [15:02] psusi: that's not true, the grub userspace tools will synthesise an arbitrary sequence if you don't have a device.map [15:02] psusi: and in practice this will all be fine [15:02] pkern: in the cross-build-depends package only as it seems at the moment. no other packages should be doing it... [15:02] cjwatson: I thoguht they did that using the code in deviceiter.c [15:02] pkern: i wonder if wine started doing it as well or not. [15:03] psusi: nope [15:03] xnox: I don't have a problem with cross-amd64-i386 stuff, because we enable both. :P [15:03] psusi: deviceiter.c is essentially a doomed effort to guess what order devices will be iterated in at boot time; we try rather hard to avoid actually relying on it for anything important. it's basically stub code [15:03] I'm confused.... "synesis an arbitrary sequence if you don't have a device.map" is what deviceiter.c does, isn't it? [15:03] pkern: for parsing, it is save to strip ":*" from the package name, to get the package name only. [15:03] pkern: the ":*" is arch qualifier in dpkg. [15:04] I know. This is about validation. [15:04] psusi: no, deviceiter.c walks through all the devices it can think of on your system and assigns a sequence that way. what I'm talking about is basically just a simple counter incremented each time a tool notices a device it hasn't seen yet. [15:04] We don't want to accept stuff which might break later. And the dev argues with me that I should find out if that presence is not a bug. [15:04] psusi: except in grub-mkdevicemap, we no longer try to go and aggressively discover all block devices on your system, which is what deviceiter.c was trying to do. [15:05] (in userspace, that is) [15:05] xnox: So if it's going to stay and not a mistake and cjwatson fixes up britney, I shall communicate that. :P [15:05] (This is not a question with Debian background, fwiw.) [15:05] pkern: I gave up on fixing it properly in britney, I just fauxpkged it [15:06] or something similar [15:06] cjwatson: so for fakeraid, somewhere it needs to decide whether the device /boot is on should be designated (mdX) or (hdX)... where is that? [15:06] psusi: grub_util_get_grub_dev I believe [15:06] pkern: it is here to stay. in fact all packages can be refered to with :$arch suffix, dpkg inplicitely uses native-arch or any it can find when not specified. [15:07] xnox: there you go [15:07] psusi: let me catch up on the grub conversation. [15:07] xnox: just the last bit that was important... sounds like it's grub_util_get_grub_dev you'll need to modify [15:07] there's already an IMSM test nearby [15:08] to avoids tagging it as the RAID abstraction if it finds IMSM [15:08] cjwatson: ahh, I thought the existing code looked for dmraid ( /dev/mapper ) and would need modified for the mdadm switch [15:08] which would have the effect of making it be (hdX) [15:09] cjwatson, xnox: Thanks. [15:09] psusi: you're in part describing old code, I think [15:09] figures ;) [15:09] psusi: there's certainly some mdadm code in here already [15:09] last time I was looking at this was apparently 2010 [15:09] xnox: if you're looking at this, please look at git master, not our current packaging; I'll be switching to a snapshot soon [15:10] and there's better support for grabbing stuff from subprocesses in master anyway [15:10] http://git.savannah.gnu.org/gitweb/?p=grub.git [15:11] cjwatson: right, and grub-installer patches are against wheezy. I'll just shelf installing onto IMSM patches for now, until snapshot arrives. [15:11] cjwatson: grub are rebels =) not using the GNU DVCS ? =) [15:11] switched away recently [15:11] very few gnu projects use it ;) [15:11] I think emacs is the main big one left [15:12] psusi: the only important one does.... yeap emacs. [15:12] Just use vi. [15:12] pkern: M-x viper-mode [15:13] latest Microsoft ergonomic keyboard is sooo emacs friendly =) [15:13] I tried that. I was not convinced. And apparently it's despised by many. [15:13] I couldn't be chatting with you on irc while running two shells, editing code, and have my git commit log entries pop up in a window with vi ;) [15:13] pkern, huh ? shouldnt you promote gobby ? [15:13] pkern: the new one? sculpt? [15:13] vi with youcompleteme \o/ [15:13] ogra_: If gtksourceview had vi keybindings. [15:13] :) [15:13] Also apparently the market decided that web apps are better than desktop apps. [15:14] * psusi goes back to reading IEEE 802.3 [15:14] youcompleteme> interesting === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [15:20] cjwatson: grub.git looks very sane will try it out. thanks a lot. === freeflying is now known as freeflying_away [16:20] jcastro: can you please reopen http://askubuntu.com/questions/59475/how-to-correctly-add-a-fake-raid-entry-to-fstab for me? [16:20] jcastro: i'll provide a proper answer in a second. [16:22] on it [16:26] xnox, done [16:53] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === wedgwood is now known as Guest77125 === Guest77125 is now known as wedgwood [17:18] slangasek: I've tested a change to update-manager to support an upgrade from Q to T per some discussion at vUDS. Basically, upgrader only wants to upgrade from Q to R so I could hard code something to have it allow upgrades from Q to T and only put that in update-manager in raring-proposed. Or maybe do something smart with a switch for update-manager. [17:19] could somebody review aptdaemon in the trusty SRU queue? it should fix the most report e.u.c error on the daily view [17:20] seb128: saucy? [17:20] ups, yes, sorry [17:20] bdmurray, you uploaded so I guess you can't review [17:20] seb128: yeah, I'd prefer not to review it [17:21] slangasek, isn't friday your SRU day? ;-) that's an easy few liner of python changes [17:21] bdmurray, slangasek: btw not sure if you saw, but I would appreciate a review from you on https://code.launchpad.net/~seb128/apturl/dont-decode-str/+merge/197804 (you wrote that code/changed it) [17:24] seb128: I'll have a look at it today [17:25] bdmurray, thanks [17:36] no godoc in the new golang packages :( [17:37] cjwatson, slangasek, mdeslaur, hallyn_: hey, so I'm playing with unprivileged containers and I currently can't ssh in because pam_loginuid is failing (/proc/self/loginuid isn't writable in a userns). How bad would it be to change that specific plugin from required to optional? [17:40] Apart from things just not generally working as well, the main effect I can think of which could cause problems would be that getlogin() would return "root" [17:41] Of course if /proc/self/loginuid isn't writable it's not clear what we could do about that [17:41] Kind announcement: Today is the last day to do the FLOSS survey 2013: http://floss2013.libresoft.es/ [17:41] (In particulary aimed at FLOSS contributors) [17:41] getlogin uses loginuid? what did it do before loginuid existed? [17:42] dunno, I'm just going by bug 1067779 [17:42] bug 1067779 in shadow (Ubuntu) "missing pam_loginuid.so breaks getlogin()" [High,Confirmed] https://launchpad.net/bugs/1067779 [17:44] http://paste.ubuntu.com/6530814/ [17:44] * stgraber goes to look at that bug report [17:48] hmm, I can't seem to reproduce what the reporter describes with my test... [17:48] stgraber: cjwatson: well I guess say the word if http://lkml.org/lkml/2013/12/4/156 becomes more important [17:49] but loginuid had a purpose, and letting a contaienr set it seems wrong [17:49] i've not looked closely at the patchset though [17:49] yet :) [17:51] hallyn_: so I'd definitely prefer it if we could get a kernel fix instead of having to patch userspace (I'd love to save myself all the backports ;)). It doesn't seem entirely unreasonable to let uid 0 in a userns set loginuid as confusing as that may be when looked at from the outside. [17:51] stgraber: slangasek: so, sorry, i finally realized that dbus from a userns is getting a REJECTED EXTERNAL DBUS_COOKIE_SH<...> where in same userns it gets OK there [17:52] stgraber: it's nto about being confusing, [17:52] it's about knowing the uid which "owns" the tasks [17:52] but ok, i'll aim to take a look in a bit. though i really have to spend some time on qemu soon [17:53] hallyn_: the whole concept of owernship becomes blurry once your user owns a few thousands uids ;) [17:53] ownership too [17:54] not my pirate ship though [17:54] stgraber: would this help any? https://git.fedorahosted.org/cgit/linux-pam.git/commit/?id=45cdd2489e68465c2d2202370c350069d2a391b8 [17:55] stgraber: so my uneducated guess is that the sha1 cookie which the dbus client sends hashes up its uid! [17:55] stgraber: rsince client's uid is not the uid that the server end sees, that fails [17:55] mdeslaur: you an expert on dbus auth? [17:55] hallyn_: nope, sorry [17:56] mdeslaur: know anyone who is? [17:56] tyhicks: do you know how that works? ^ [17:58] mdeslaur: I doubt it... in our case, loginuid is already set to -1 (well, 4294967295) as the actual uid can't be mapped to the userns. So even with that change, pam_loginuid will still attempt to set it to the right value (1000 in my case) and fail with permision denied [17:58] mdeslaur: nope, I haven't looked at that before [17:58] ok thanks - i'll read over http://dbus.freedesktop.org/doc/dbus-specification.html again [17:59] stgraber: ah, ok [17:59] "Thus the security of DBUS_COOKIE_SHA1 depends on a secure home directory" <-- not good [18:00] mdeslaur: if it's too hard to fix in the kernel and can't be done for 14.04, then I think the fallback will be to patch pam_loginuid to ignore (just log) failures to write to loginuid, then SRU that change to all releases. [18:00] that'll still prevent anyone from running non-Ubuntu containers in a userns though, so I'd love to avoid that... [18:01] slangasek: ^ unless there's another auth mech i can use, this may mean that dbus can't be used for the cgmanager (^) [18:02] stgraber: i'll look at the patchset this afternoon. [18:02] hallyn_: I guess you'll need to talk to the kernel team too because with the 3.13 merge window closed, it's doubtful we'll get that change in our kernel from upstream, so we'll need to apply that set ourselves and/or cherry-pick once that's upstream [18:02] stgraber: would that be pretty much the equivalent of setting it as optional? or is there a way for you to only the failure only in an unprivileged container? [18:02] bdmurray: wouldn't you want the behavior change SRUed into Q rather than into R? [18:02] or maybe i can disable auth? [18:03] mdeslaur: it'd be similar to setting it as optional but with the benefit of not having to patch all packages that ship their own pam profile [18:03] seb128: yep, SRU day for me today [18:03] slangasek: right, my mistype [18:03] stgraber: I suppose ignoring the error only if it's not writable is better than setting it as optional, now that I think about it [18:04] mdeslaur: yeah, that was my thought too. The only case you'd get a permission denied in is userns or if another MAC is preventing writes to the path, in all those cases, it's fine to ignore I think. [18:05] stgraber: I don't think changing loginuid to optional is reasonable; anyone who wants loginuid expects it to work reliably, and you don't want all errors to be silently ignored [18:05] slangasek, hey, great ;-) [18:06] +1 [18:06] hallyn_: auth mech> hum, ok then. :/ [18:06] bdmurray: right - so I think that's a reasonable strategy [18:06] slangasek: how about only ignoring permission denied (with a suitable log message)? (only discussing this as a fallback if hallyn_ can't get us to ship the audit userns kernel patch) [18:06] stgraber: if loginuid is failing with a permissions error, and it's wrong to change the kernel to allow the operation, then I think pam_loginuid needs to be changed to not fail under those circumstances [18:07] Yeah, I think it would be a design error to do that in all the services === pmahent is now known as ptmahent [18:09] slangasek: Just having a version of update-manager that supports Q to T upgrades hanging out in -proposed? or also requiring a command-line option for that to work? [18:09] slangasek: ok. I think the implementation would be something like "ignore permission denied when writing loginuid if loginuid doesn't belong to the owner of the process" which should be specific enough to only match the userns case in reality. [18:11] gah no, won't work... I was vaguely hoping uid -1 would own loginuid but that's not the case... it appears as owned by the process owner but just isn't writable... [18:12] bdmurray: hmm, do we want it to go straight from Q->T, or should it be Q->S? [18:12] anyway, will only spend more time thinking about the workaround if hallyn_ doesn't manage to get us the kernel fix [18:12] bdmurray: since R goes EOL before Q, but S does not [18:12] (I'm asking because I don't remember what we discussed) [18:12] stgraber: ok, sounds good [18:12] I believe we discussed to T because Q was closer to P the last lts [18:13] slangasek: from what i remember of the upgrade testing vUDS session, we said P -> T and Q -> T [18:13] ok. I thought maybe we did it because Q->S only buys you 3 more months of support before you have to upgrade again [18:14] 12.10 (Q) EOLs in 14.04, 13.04 (R) EOLs in 14.01, 13.10 (S) EOLs in 14.07 [18:15] so we can't offer Q users to upgrade to T until T releases [18:15] right? [18:15] which means it's already EOL at that point [18:15] so I think we actually need to do Q->S instead [18:17] don't we control the day 12.10 goes EOL? [18:18] if it's just a matter of days, it'd be better to postpone the 12.10 EOL a bit than have to SRU every single LTS to LTS fixes to S... [18:21] bdmurray: yes, but we don't want users of 12.10 to be /stuck/ on 12.10 from January to April [18:21] which is what they'll be after 13.04 goes EOL [18:22] ah, got it. okay from Q to S then, but the requiring a command line option still remains. [18:22] yeah, I think we shouldn't require a commandline option [18:22] we should just flip the switch when R goes EOL [18:25] slangasek: and does move the package from -proposed to -updates count as "flipping the switch"? The potential issue is people unexpectedly upgrading from Q to S instead of R if they use the version of update-manager from -proposed. I guess it is rather close to R's EOL though. [18:26] bdmurray: yeah, I would count -proposed->-updates as flipping the switch, and think it's ok to have users who have -proposed enabled and who upgrade wind up skipping R === bfiller is now known as bfiller_afk [18:37] slangasek: so in a userns the client gets http://paste.ubuntu.com/6531031/ - whereas not in a userns, in place of the first REJECTED msg it gets an OK. I note the client DOES seem to get past auth, as it gets AGREE_UNIX_FD. [18:45] slangasek: oh, that'll mean an SRU for the saucy release upgrader too [18:52] hallyn_: so... the cookie is rejected, but the auth succeeds? hmm. [18:52] hallyn_: at this point I'd say we need the dbus upstream mailing list [18:55] bdmurray: right, I figured that would be the case [18:56] grrr [19:06] hm, and now i get Failed to open connection to "session" message bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 [19:10] oh, nm, user error [19:21] slangasek: ah, going by http://lists.freedesktop.org/archives/dbus/2008-May/009761.html and http://lists.freedesktop.org/archives/dbus/2008-May/009831.html it seems I'm "walking on experimental ground" [19:22] but yeah i guess i may have to mail upstream to get their "Why tf would you want to do that" [19:27] hallyn_: long-running experiment, what is this, CERN? :) [19:27] or the dbus pitch drop [19:29] hahaha [19:30] new insight - the first step done by both is to attempt AUTH EXTERNAL. But the working one sends AUTH EXTERNAL 31303030, while the broken one sends AUTH EXTERNAL 30 [19:30] * sarnold idly wonders how many free software projects have been started _and_ stopped in the time between two pitch drop events... [19:30] sarnold: all of them! [19:31] (well, all the defunct ones anyway :) [19:31] slangasek: that's gotta say something about our attention span! [19:31] poor poor multics. [19:31] at least fortran and cobol are going strong :) [19:38] and now my laptop shut itself down (thermal) during release-upgrade to trusty. nwo drops me at grub-rescue [19:39] maybe it's time to get a chromebook === doko_ is now known as doko [20:21] why hello there! any fglrx package maintainers here by any chance? ;) [20:25] eh, i'll just mail the proper person - at least then i can count for getting sh...tuff done [20:29] ok, so apparently i should mail the core dev list, which i'm not going to do, so i'll just leave it here: any fglrx packages providing drivers (be it fglrx or fglrx-updates) provides virtual packages opencl-icd and libopencl1 - would be kind if someone handled this in a timely manner; would definitely save future users some torn hair, despite this issue sitting in limbo for 2+ years [20:30] zer0def: I think you might be looking for tseliot, but he seems afk [20:30] eh, i don't care, i've already moved on from ubuntu a long time ago [20:31] just trying to prevent others from violating their heads too much [20:32] especially since there's no good reason for denying people the ability to dev opencl using amd cards on ubuntu [20:33] well, at least those who rather stick to repository packages rather than do their thing. [20:33] anyway, message delivered; cheers === retoaded is now known as retoaded_biab [20:54] stgraber: slangasek: http://lists.freedesktop.org/archives/dbus/2013-December/015867.html [20:58] Is a faster build really enough to not sync sdcc from debian? This issue is now partially fixed anyway [21:05] BenC, Can you check if sra-sdk is syncable? I didn't really understand why you made it x86 only [21:14] Noskcaj: https://buildd.debian.org/status/package.php?p=sra-sdk <-- Should make it obvious why it's x86-only. [21:15] thanks [21:15] Noskcaj: Also, no point in syncing it when it's FTBFS even on i386. :P [21:15] stgraber: regarding loginuid in userns, [21:15] hm, hold on [21:16] well, yeah. so (1) everywhere I am, it seems to be unset, and (2) once it is set it should not be re-setable; so [21:17] if it's so crucial thaqt it be set, then it should be set on all my logins; and in that case, starting a container would m ean all those tasks would have my loginuid, [21:17] so the conatiner wouldn't be able to set it anyway [21:17] so i'm confused [21:17] Noskcaj: That said, once the i386 FTBFS is fixed, it could be synced and just fail on !x86, I'm fine with that. I think Ben was probably just on a crusade to remove the red from the FTBFS list. :P === retoaded_biab is now known as retoaded [21:18] ok [21:19] Is anyone around willing to give me a testimonial for MOTU? https://wiki.ubuntu.com/Noskcaj#MOTU [21:21] hm, how does this 'loginuid_immutable' kernel 'feature' work? boot cmdline? [21:21] hallyn_: yeah, it seems like it's only getting set for ssh sessions at the moment and soon for jobs started by at [21:22] hallyn_: /proc/self/loginuid sure seems to be writable here... [21:22] hallyn_: oh but indeed write once [21:22] hallyn_: I'm just surprised that as a regular user I can echo any value in there though ;) [21:23] even ssh isn't doing it for me [21:24] (that's precise though) [21:24] it sure does here (on precise) [21:24] stgraber@shell01:~$ cat /proc/self/loginuid [21:24] wonder what the difference is [21:24] 201105 [21:24] serge@ac100:~$ ssh hetzner.hallyn.com cat /proc/self/loginuid [21:24] 4294967295serge@ac100:~$ [21:24] now, [21:25] ok yeah in ubuntu we don't set the immutable flag - so root can clear out your loginuid. [21:25] if that were set, then even root could not [21:25] all in all, this has a use case - but to us, the way things are set up, it's useless [21:26] so i think we should simply go with the workaround you and mdeslaur were talking about [21:26] the 20 patch audit patchset doesn't even include a fix for loginuid! [21:26] just prep work :) [21:26] hmm, ok [21:26] the main issue with the workaround is the need to apply it to all Ubuntu releases and to any other distro we wish to run in a userns [21:28] hallyn_: is there an easy check I can do to detect whether we are in a userns or not? ideally I'd like to avoid ignoring all EPERM and only ignore them when in a userns [21:30] well you can compare /proc/$$/ns/user stat.st_ino, or just check for '0 0' in uid_map [21:30] (0 0 4294967295) [21:34] hallyn_: I guess I'll have to parse uid_map, I can't find a good way to determine whether I'm in the host namespace or not based on stat.st_ino of ns/user [21:37] hm, yeah, i was thinking of a server in init_user_ns (bc that's my mindset this week :) [21:38] anyway, it's not too difficult, check if the file exists, if it does, open it and read the first 3 char, if that's '0 0', we're in the host namespace [21:40] well i think someone *could* mess with you and create an ns with 0 mapped to 0, but only 1 uid :) [21:40] but i don't think you care about them. [21:41] well, if 0 is mapped to 0, then we're still actual root so should try to write loginuid [21:41] they'll fail [21:42] !init_user_ns so no capable(CAP_SYS_AUDIT). (it's not ns_capable(ns, CAP_SYS_AUDIT)) [21:42] hallyn_: I am only a bot, please don't think I'm intelligent :) [21:42] \sorry ubottu [21:44] hallyn_: fine, I'll specifically look for ' 0 0 4294967295' then, that should do it :) [21:45] hallyn_: uid_t is guranteed to always be uint32 right? [21:46] stgraber: well there is uid16 support somewhere... [21:48] no that's just legacy syscalls [21:48] shouldn't affect /proc [21:49] hallyn_: good, so I don't need to care about it and can hardcode 4294967295 :) === salem_ is now known as _salem [21:58] first timer.. cannot bzr init-repo.... getting Permission Denied (Public Key) error..help [22:01] charlie: usually when i get that it means i've not added my launchpad ssh key ito my ssh-agent keychain [22:06] how i do that? [22:11]