=== LaserJock is now known as LaserJock_ === LaserJock_ is now known as LaserRock === LaserRock is now known as LaserJock [01:28] ok, what the hell? I added my key to ubuntu-keyring as the wiki said to do for customizing the install cd, yet it isn't there in the installed target... if I chroot into /target and manually install ubuntu-keyring, it's there.. it's like it's got a secret copy of the original package stashed somewhere that it's installing instead of mine [01:29] but of course, mine is the only one in pool/main/u/ubuntu-keyring === v is now known as DoorDonkey === DoorDonkey is now known as DirtyLegs === DirtyLegs is now known as BiscuitNeck === Ursinha-afk is now known as Ursinha [02:40] oh weird... it seems that d-i does *not* use debootstrap, but has switched to live-install, which copies a pre debootstrapped squashfs image. hrm... [02:40] had to slip the updated ubuntu-keyring into the squashfs [02:42] can probably get back some space on the install cd by eliminating the packages from the pool that are already included in the squashfs... or maybe drop the squashfs if eatmydata can reduce the extra time deboostrap takes over the squashfs method to a minimum [02:47] wow... 4.5 minutes for an update-initramfs, then it turns around and does it again 10 seconds later.. that's going to have to go... [02:49] psusi: It also requires initramfs size*2.5 or so in /boot [02:50] Otherwise it gets very cranky [02:54] it looks like there is a *log* of low hanging fruit for speeding up d-i these days [02:54] *lot* even === robert_ancell is now known as robert_ancell|di [04:52] Good morning [04:52] dupondje: did you upgrade initramfs-tools along? [04:53] dupondje: thanks for the bug, will investigate there [04:54] infinity: versions> because ubuntuN+1 steals actually used version numbers, and I'd have to commit all these no-change rebuilds to VCSes (some of which I can't even access) [04:55] infinity: for the unmodified Debian ones I went with the normal -buildN [05:21] dupondje, slangasek, ScottK: FYI, I followed up to bug 1154813 [05:21] bug 1154813 in systemd (Ubuntu) "Boot broken with initramfs-tools 0.103ubuntu0.5b1" [Critical,In progress] https://launchpad.net/bugs/1154813 [05:22] will upload the workaround again (argh for papering over unreproducible bugs) [05:28] pitti: hmmmm, interestingly when I was looking at logind originally, I also ran into problems with SOCK_NONBLOCK there which I was subsequently unable to reproduce in raring [05:28] slangasek: I'll look at sbin/wait-for-root in the initramfs, I guess that somehow doesn't get along with a nonblocking socket [05:28] (so I never applied that patch to the package) [05:29] * slangasek nods [05:29] that's the only plausible thing in the initramfs which could cause this [05:29] wait-for-root isn't Ubuntu-specific though, is it? [05:29] I think lool hit this in udev 171 [05:29] so I guess I can poke both dupondje and him to test a possible fix [05:29] ah no, it *is* UBuntu-specific [05:31] ah, that sounds very likely then [05:38] slangasek: WDYT if I change wait-for-root to set the socket to blocking instead? [05:38] slangasek: that at least reduces the workaround to the one place which we know is broken, without affecting all the rest of the system [05:39] pitti: well, what's the downside of making the sockets blocking everywhere? [05:39] if nonblocking is the "right" answer, then we can make wait-for-root set the blocking flag for its own use; but I'm concerned about the same bug recurring in other users of libudev [05:39] I don't quite like this kind of diversion from upstream ABIs; [05:40] if we were actually auditing the revdeps to make sure they all cope with a nonblocking socket, that would be fine with me [05:40] we can add it back and cement the diversion, but it doesn't happen in any other distro [05:41] but having found one user that doesn't cope with nonblocking, I think there are likely to be others [05:41] well, adding blockign is certainly not a fix, just a reduction of the workaround [05:41] "any other distro" - Debian also doesn't have libudev1 [05:41] I'm currently staring at the code to see what it could do wrong there [05:42] slangasek: SOCK_NONBLOCK was introduced in udev 171, that was years ago [05:42] it has libudev0 that's at the same upstream version as ours [05:42] oh, you said this was an Ubuntu-specific patch to udev previously, right [05:43] and enen the documentation says "The monitor socket is by default set to NONBLOCK" [05:43] ooh, I see [05:44] main() just does [05:44] while ((udev_device = udev_monitor_receive_device (udev_monitor)) != NULL) { [05:44] but the documentation says " variant of poll() on the file descriptor returned by udev_monitor_get_fd() should to be used to wake up when new devices arrive, or alternatively the file descriptor switched into blocking mode." [05:44] sorry, missing an "A" at the beginning [05:44] so switchign to blocking there is actually the right answer, as this program doesn't have to do anything else than waiting for udev events [05:45] * slangasek nods [05:46] slangasek: I'll walk through http://codesearch.debian.net/search?q=udev_monitor_receive_device [05:47] just two pages, that's not too hard to audit [05:47] fwiw I've just checked that upstart and mountall are ok [05:47] lvm seems not to use it [05:48] (despite using libudev) [05:48] usually one would call this function from an event callback, where the blocking doesn't matter, indeed [05:48] so, that probably covers us as far as breaks-your-system, unbootable regressions are concerned [05:48] oh, should probably check libdevmapper too [05:48] ah no, that's from lvm2 source after all [05:49] xorg also looks good [05:50] pretty much everything calls that from callback handlers [05:52] upstart looks good [05:52] (ah, you already checked it) [05:54] dupondje: so, sorry for the trouble! [05:54] we should have debugged this properly back then, such things are lingering disasters [05:56] pitti: debian/patches/avoid-exit-deadlock-for-dm_cookie.patch also touches libudev; have you forward-ported this one to the systemd package? [05:57] no, I didn't [05:57] *nnng* people, please forward such patches upstream [05:58] I thought I remember this one being forwarded upstream at the time, despite not having the info in the patch header [05:59] or, it's possible that this wasn't upstreamed because it's only used in conjunction with some difficult-to-unwind lvm2 patches which are also not upstream [06:01] * pitti googles "google site:spinics.net hotplug DM_COOKIE", but cannot find anything [06:01] ah; we have a much newer lvm2 now, are we still having these patches? [06:01] yes [06:06] pitti: so, the patch is still needed but despite being exported as part of libudev0, it seems that udev itself is the only consumer [06:06] so we can omit that for now [06:06] ah, good [06:06] (lvm2 relies on that functionality, but only in udevd) [06:06] we still need to port it once we move to current udev then [06:06] yep [06:07] thanks for checking [06:10] slangasek: http://paste.ubuntu.com/5612832/ , rebooting now for smoketesting [06:12] still boots fine [06:20] so, feel entitled to yell "Lennart broke my boot!" :-) [06:22] "Lennart broke my boot!" === robert_ancell|di is now known as robert_ancell === slacker_1l is now known as slacker_nl === tkamppeter__ is now known as tkamppeter [07:22] dupondje: \o/ [07:28] infinity: so, who else is in ubuntu-sru that I could ping for reviewing samba for precise-updates? [07:43] good morning [07:49] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mlankhorst [08:08] lool: will do [08:21] thx pitti :) [08:39] bkerensa: is xfce4-session also already ported to logind? === jibel_ is now known as jibel [09:00] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [09:00] bbiab [09:31] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mlankhorst === yofel_ is now known as yofel [10:32] ev, hey, https://errors.ubuntu.com/?package=nautilus triggers an error ... known issue? [10:33] pitti: is it any problem if i upload new versions of packages that use libudev? xorg-server and mesa 9.0.3 [10:33] mlankhorst: no, that's fine; please feel free to stomp over my "no-change rebuild" changelog with -b1 suffixes [10:33] mlankhorst: I deliberately chose those suffices to not steal the next version numbers and get out of sync with VCSes [10:35] * ev digs [10:36] I hope mesa 9.0.3 won't bump wayland again [10:37] mlankhorst: *shrug* the more you upload the fewer TIL remain for me :-P [10:43] seb128: just waiting for webops to roll out the fix [10:43] ev, thanks [10:44] seb128: mthaddon is on it. RT 60095. [10:44] excellent [10:44] now to find out why this is happening :) [10:47] seb128: it's working now [10:48] * ev adds a todo item to build out https://errors.ubuntu.com/status to cover some common API calls [10:48] ev, indeed, works now, thanks a lot! [10:48] seb128: sure thing. Sorry it happened in the first place :) [11:13] Let's say I have Ubuntu installed on my hdd. If I shrink the size of my hdd, create a new partition and install, for example windows 7. Will it mess up grub on that hdd? === amitk is now known as amitk-afk [11:46] well if we need to rebuild libdrm anyway, might as well do a new upload === MacSlow is now known as MacSlow|lunch [12:22] Hi, my ubuntu keeps on crashing and this is the relevant part of the syslog http://pastebin.com/CYFp5DKH When reporting this bug, what kind of information should I also include? [12:23] specifically what crashes.. [12:23] leex_: https://wiki.ubuntu.com/DebuggingSoundProblems I suspect [12:24] cjwatson: you don't know what crashes, could be that nouveau line :P [12:24] hi [12:25] mlankhorst: True [12:25] mlankhorst: mplayer crashes, system freezes, can't access tty [12:26] that's the short story [12:26] I will paste the whole syslog if you want [12:28] I am coming with a question related to lxpanel, in a Precise install, if anybody has an idea about this (I wonder if I should post a bug report). while trying to start htop from the lxpanel menus, in an install with mainly Openbox, and Sakura as terminal, I was suprised it would not start. It works fine when started in console. then looking in the ~/.xession-errors file I saw it was searching each time for lxterminal. I just looked at the pac [12:28] kage page, and nowhere lxterminal is mentioned as a dependency. and I thought lxde components could be used alone and not depend on other main components... http://packages.ubuntu.com/precise/lxpanel [12:28] here is the whole syslog http://paste.ubuntu.com/5613463/ [12:31] so shall I just run ubuntu-bug -s audio? [12:31] well, htop is a terminal-based program; it doesn't specifically depend on lxterminal, but it needs to be run in *a* terminal. it's probably just missing some bit of metadata in its menu file to tell the menu system to run it in a terminal [12:31] (I don't know exactly what but maybe this gives you a place to start) [12:32] ah, you say "it" was searching for lxterminal. You might like to find out what "it" is; I bet it's not htop [12:32] the .desktop file defines Terminal+yes [12:32] err [12:32] Terminal=yes [12:32] perhaps the panel needs a terminal installed in order to be able to start launch-in-terminal applications [12:32] which would seem likely :) [12:33] though i would expect it to use the default one from the alternative [12:33] does Sakura perhaps not use that ? [12:34] or set it ... === _salem is now known as salem_ [12:48] does anyone know why the celt codec isn't avaiable in raring? [12:49] xnox: what is dh_links? or is that a typo? https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/python-pip/raring/revision/14/debian/rules [12:50] mitya57: probably a typo.. [12:50] cjwatson I have done several tests with the htop.desktop file, and I can assure you I don't see the problem elsewhere than in lxpanel : when I start htop from the menus in the openbox applications menu, it starts in the console which is installed. [12:51] mitya57: s/links/link/ [12:51] *sigh* [12:51] xnox: will you fix that yourself or should I file a MP? [12:51] and the pipe menu which provides the applications right-click menu uses libmenu-cache as lxpanel does [12:51] so ? [12:51] mitya57: if you have time, please file a MP, i'll bzr bd & upload it. [12:52] xnox: ok, will do now. I also think that /usr/bin/pip3 is a nice thing to have in Debian too. [12:52] cjwatson i tried to replace "Exec=htop" in the desktop file with : [12:52] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [12:52] x-terminal-emulator htop [12:52] x-terminal-emulator -e htop [12:52] x-terminal-emulator -x htop [12:52] -ENOTTY [12:52] and each time in the .xession-errors file I could see: [12:53] "lxterminal "x-terminal-emulator htop" : lxterminal is not installed [12:53] and same for the other commands [12:53] this is how I saw lxterminal was sought for [12:53] cjwatson does that seem a fair test to you ? [12:54] I don't know, sorry [12:54] I even tried "Exec=sakura -e 'htop'" and the .xession-errors file returned "lxterminal sakura 'htop'" : lxterminal not installed; :) [12:54] cjwatson thank you. [12:54] I was just making a passing comment in the hope that it might help; I can't help further [12:55] I'll ask the person who uploaded the package [12:55] cjwatson you have helped me : you suggested what I did, and I was hoping to see more but there isn't. :) [12:55] thank you very much. [12:56] I will have other questions next, but not all at one time... :) === MacSlow|lunch is now known as MacSlow === wedgwood_away is now known as wedgwood === amitk-afk is now known as amitk [13:57] seb128: hi! Raring will not get GNOME 3.8, will it? [13:58] mardy: https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-gnome-plans-review [13:58] mardy: no, we are sticking with 3.6 and pulling patches and or individual apps as we see fit. === jono is now known as Guest54570 [14:00] xnox: I'd like to see if we can make an exception for some other components; should I start by proposing the change in the blueprint's whiteboard? [14:00] xnox: FYI, EDS/Evolution (the developer claims he has been developing them on top of GNOME 3.6 [14:03] mardy: we are past feature freeze. [14:03] mardy: you'd want FFe now. [14:03] mardy: Thunderbird is our default mail app, why would we want new Evolution? [14:03] xnox: Online Accounts integration [14:04] mardy: don't edit whiteboard (that was relevant during raring development up to feature freeze), open FFe bug instead. [14:04] mardy: well, _which_ online accounts? ubuntu or gnome? [14:04] xnox: Ubuntu :-) [14:07] xnox: thanks. Well, first I'll try and see if it's really true that I can build it on raring :-) === schmidtm_ is now known as schmidtm [14:21] mardy, hey, yeah we stay on GNOME 3.8 [14:21] mardy, is there some abi changes in e-d-s/soname updates? [14:21] mardy, does the new evo require gtk 3.8 (we didn't go for it) [14:22] mardy, in any case it seems like that can wait a month and land after raring... [14:22] seb128: I'm trying right now to build it on raring, I'll let you know [14:22] mardy, ok, thanks [14:22] mardy, did they include uoa support in 3.8? or do they just have work in progress on top of that version? [14:23] seb128: yes, that's why I'm interested in it [14:23] seb128: it's in master :-) [14:23] ok, cool [14:56] ScottK, hello! I don't quite understand your question in bug 1155157, could you explain? [14:56] bug 1155157 in unity-greeter (Ubuntu Raring) "[FFe] Allow custom indicators" [Undecided,New] https://launchpad.net/bugs/1155157 [14:59] mterry: I recall some discussion the other day on IRC about session buses needing to be manually enabled. It may have been irrelevant, but my question was are we already using a greeter session bus by default or does the greeter normally use the system bus? [15:01] ScottK, the greeter has a session bus already. I know because it spawns some things that have used it. But it's never exposed an interface on the bus before. That's new [15:01] (things like indicators use it) [15:01] smb: hi - kvm module autoloading is causing me a new problem. [15:02] what exactly causes it to get loaded? [15:02] hallyn, there is now cpu aliases for the modules [15:02] alias: x86cpu:vendor:*:family:*:model:*:feature:*0085* [15:02] for example [15:03] smb: the problem is that is getting done before qemu-kvm.conf runs. qemu-kvm.conf optionally loads kvm_intel with thenested=1 parameter [15:03] so that isn't getting done [15:04] now it's rnning on 'runlevel [2345]', i guess i can move it much earlier than that, but when are the modules being autoloaded? presumably very very early? [15:04] i suppose i can just 'rmmod kvm_intel' always before modprobing it [15:06] smb: can i ask what the advantage is of always loading that? [15:06] hallyn, I would suspect that happens with some udev rule. (maybe on --trigger). That could work... I guess creating its own /etc/modprobe.d/ rule was bad for some reason [15:08] hallyn, Suspect its a simplification so you cannot forget... But I would not know the real reason [15:08] h, but always rmmod'ing kvm is bad as libvirt may be racing with us, vms already running [15:10] hallyn, yeah probably not the best variant... need to look, is the upstart file doing much more than loading? [15:11] hallyn, Hm, other option, not sure, but maybe it can be changed in /sys/modules...? [15:11] smb: bug 1155177 [15:12] bug 1155177 in qemu (Ubuntu) "nested=1 not taking effect" [High,Confirmed] https://launchpad.net/bugs/1155177 [15:12] oh, you think it can be done at runtime? [15:12] smb: at this point i'm not sure anyone would wnat/need to run without nesting support [15:12] so perhaps it's ok to just always turn it on [15:13] (with the qemu package, per the bug) [15:13] but yes, lemme try andn set it through sysfs [15:13] hallyn, I thought nested=1 also is the modules default... [15:13] if it is then it's not working [15:14] oh, no, not the kernel module's default [15:15] smb: nope, can't change it through sysfs [15:16] so what is the dh_* way to install a modprobe.d file? [15:17] hallyn, dh_installmodules (package.modprobe)? [15:17] oh, this is a regression. [15:17] quantal had that file [15:17] smb: but just having package.modprobe is sufficient right? [15:17] i don't even need that line then? [15:18] hallyn, you are asking the blind (or the deaf) :) [15:18] smb: will test - thanks :) [15:18] Just looked it up but maybe the file only is sufficient [15:20] hallyn, And yeah, seems all the options of the module are unchangable without rmmod/modprobe... [15:20] smb: so... should i assume that thos modules are always loaded, [15:20] and remove the modprobe from qemu-kvm upstart altogether? [15:20] hallyn, Right and also now the right ones [15:20] are there any cases where that won't happen? [15:20] based on SVN or VMX [15:20] ev/cjwatson: can you offer any advice on how a python script can dynamically determine the full path to its installed icon file? [15:20] smb: cool so only ksm setting will be left. that and vhost_net [15:21] hallyn, Yes, if a cpu does not support the feature or like in the case of dom0 if someone hides it [15:21] how do you mean, icon file? === lfaraone_ is now known as lfaraone [15:21] cjwatson: well, and svg or png file that will be displayed in help->about actually. [15:21] any reason that needs to be dynamic? [15:22] I'd probably just hardcode a path, maybe substitute it in at build time if I were feeling keen [15:22] at least if it was just a script rather than a module [15:22] cjwatson: I'm using gtk set_icon_from_file(), but the .py isn't going to know where the image file is once it's installed. [15:23] cjwatson: yeah, this is just a single script - it's currently looking in cwd but that won't work when I install it [15:23] so you're trying to make it depend on autoconf --prefix or similar/ [15:23] ? [15:24] cjwatson: something like that. I wondered about creating file.py.in or similar (not: there is no setup.py atm). [15:24] cjwatson: s/not:/note:/ [15:25] smb: testing http://paste.ubuntu.com/5613875/ fwiw [15:25] jodh: that's what I'd do [15:25] and have it test each of installed-path and cwd in some order to see if they exist [15:25] or give it a path override option [15:26] (probably overkill for an icon) [15:28] hallyn, minus the debian packaging magic I am never sure of, that would look good to me [15:30] cjwatson: ok thanks. I'd wondered if it was possible to query a desktop file and it is using python-xdg. Only problem is finding the path to your .desktop file .... :) [15:30] well exactly, same problem [15:30] cjwatson: right :) [15:30] I suppose you could try to divine your prefix from __file__ or whatever it is [15:31] Not convinced that would be more robust === norbi is now known as Guest50187 [15:51] jodh: if you drop icon into correct location for desktop icons, the gtk_icon thing has a function to give you theme icon for "upstart" [15:51] jodh: thus you don't need full path in the first place. [15:52] jodh: see xdg icon spec for reference [15:52] https://developer.gnome.org/gtk3/3.4/GtkImage.html#gtk-image-get-icon-name [15:53] jodh: then drop the svg into /usr/share/icons/hicolor/scalable/apps/upstart.svg [15:53] ah, yeah, that might be better if you can manage it [15:53] run magic stuff to update icon caches. [15:54] (i usually reinstall one of the packages which already has icons there) [15:54] how do i add ttyS0 to the list of things triggering ckit? [15:54] and use it =) [15:54] stgraber: ^ ? [15:54] xnox: thanks! [15:54] np [15:55] I use glade, so i just set icon name there. [15:55] hallyn: I don't remember ckit needing any kind of device whitelist. It's typically hooked into pam. [15:56] xnox: dh_icons, but you shouldn't need to do that if installing under /usr/share/icons/hicolor/ since hicolor-icon-theme has a trigger [15:56] Though it wouldn't hurt [15:56] dh should do it for you though [15:57] cjwatson: i mean when i'm locally just dropping/updating icons there for testing & artistic impression =) [15:57] * xnox notes down to see what hicolor-icon-theme trigger executes. [15:57] right. update-icon-caches isn't much typing :) [15:58] (hicolor-icon-theme.postinst does it an older but basically equivalent way) [15:58] well, update-icon-caches only handles gtk3 [16:08] pitti, the tests in systemd are disabled because "some tests fail under fakeroot". Do you happen to know how many we're talking about? (like, are we skipping 200 tests because 2 fail or because 198 fail?) [16:09] Not that systemd has 200 tests, that was just an example number [16:09] mterry: it's got quite a number of tests, but very few of them (only the unit tests) are actually shipped in the package [16:10] mterry: the integration tests (which build and run VMs) are only in git; I want to talk to upstream to ship them as well, so that we can run them in autopkgtest, etc. [16:10] pitti, yeah, you mentioned that in the MIR [16:10] mterry: building, I'll tell you in a bit [16:10] But it would be neat to run the unit tests too [16:10] yes, absolutely [16:14] xnox: Hm, do you also have multiarching in progress for tk8.5? [16:16] mterry: from upstream git I get 6/26 failures, apparently it's making some assumptions about the environment which aren't true on Ubuntu [16:16] cjwatson: needs to take the patch from 8.4 and apply on top of 8.5, do you need it urgently? [16:16] xnox: Because I'm having trouble getting ruby1.8 to build again when tclConfig.sh and tkConfig.sh are in different directories [16:16] xnox: And the relevant bit of its build system is, well, in ruby, and it's hurting my brain to unpack [16:16] pitti, hrm. Is it easy to selectively disable them? [16:17] cjwatson: hmm... well the _default_ tclConfig.h has not moved, but the 8.4 & 8.5 did move. [16:17] mterry: yes, it's individual programs [16:17] xnox: err, I beg to differ [16:17] mterry: but probably it's better to fix them [16:17] $ dpkg -L tcl-dev | grep tclConfig [16:17] /usr/lib/i386-linux-gnu/tclConfig.sh [16:17] mterry: but I had so much stuff at my hands with that tradition that I didn't get to that yet [16:18] pitti, yeah [16:18] xnox: And that's necessary AFAICS so that tcl-dev can be M-A: same [16:18] cjwatson: true, cuase it had too, otherwise tcl-dev would not be m-a:same. *sigh* [16:18] =) [16:19] cjwatson: i totally miss-read your question. [16:19] cjwatson: No, i do not have any progress on tk multiarchification. [16:19] Ah [16:19] OK, maybe I need to do that then [16:19] +1 maintenance -> yak shaving [16:20] I was two levels down from the original problem already :) [16:20] cjwatson: but if you use tcl8.6 and tk8.6 neither are multi-archified and ruby will build =) i guess you want to continue building ruby against the default tcltk stack.... [16:21] That doesn't seem like an unalloyed step forward, really [16:21] And indeed I don't want to get into serious ruby maintenance, I just want to get it building again [16:21] I suspect it's not the only build system that assumes that tclConfig.sh and tkConfig.sh are in the same directory, so I think it'd be best to fix this regardless [16:22] cjwatson: we can ship "/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh" which will call dpkg-architecture & exec the real Config script from /lib/$(DEB_MULTIARCH/ [16:22] cjwatson: we can ship "/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh" which will call dpkg-architecture & exec the real Config script from /usr/lib/$(DEB_MULTIARCH/ [16:22] mterry: so the tests seem to run fine on Debian (says mbiebl) without fakeroot, so I'll investigate this [16:22] pitti, thanks! it makes me nervous to have 0% coverage :) [16:22] mterry: heh, same here :) [16:22] as long as it has same contents on all arches =) [16:23] xnox: Which is going to involve multiarching tk anyway, and I already have the ruby fix to honour DEB_HOST_MULTIARCH ... I'm not sure it makes sense to try to avoid this work [16:23] Tk should be multiarched for basically the same reasons Tcl was [16:23] So I'll start in on that now, I think [16:23] cjwatson: well, tkConfig.sh can stay as it is for now. Just ship the "compat" /usr/lib/tclConfig.sh. [16:24] cjwatson: or that =) [16:24] * xnox did not have fun with getting tcltk-defaults to do the right thing though. [16:24] mterry: ah, could actually be that it assumes that it's running under systemd [16:25] Anyway I don't really like such compat hacks when not absolutely necessary - they have a habit of complicating an area of packaging that not enough people understand as it is [16:26] unbroke python =) [16:29] mterry: ok, got it (assumes having /etc/machine-id) [16:34] mterry: https://bugs.freedesktop.org/show_bug.cgi?id=62344 [16:35] Freedesktop bug 62344 in general "tests depend on /etc/machine-id" [Minor,New] [16:36] pitti, awesome. if it's not easy to retro-fit machine-id-agnosticism, would you mind enabling the other tests at least until upstream fixes that? [16:40] mterry: I rather do the former, investigating (but won't finish today, need to leave in 10 mins) [16:49] All 26 tests passed [16:49] now, here we go [16:50] pitti, leave :) [16:50] (but awesome!) [16:58] will eglibc commit cbc105f8b590f (aarch64: use lib64 as default lib and slib directory) be a problem for use at some point? [17:16] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity [17:16] jtaylor: Ugh. As long as no one also moved the linker. Let me look. [17:19] jtaylor: Nope, that *should* be fine. So far, no one's relocated the linker. Default libdir and slibdir can be overridden anyway, and we will. [17:19] jtaylor: doko was involved in a long thread with gcc upstream about all of this, here's hoping no one does anything stupid. [17:20] * infinity goes to future-proof the packaging by preseeding libdir and slibdir so he doesn't get a nasty surprise when he rolls 2.18 [17:20] ? [17:21] doko: Andreas Schwab committed a libdir/slibdir change from lib to lib64 to glibc upstream. Relates that thread you were involved in last week. [17:21] doko: (For AArch64) [17:22] doko: Anyhow, doesn't look like he moved the linker, just the libdirs, so doesn't really affect us. I just need to change it back to lib for us. [17:22] doesn't affect multiarch [17:22] Right. [17:24] Oh, indeed, might not affect as at all, as we install everything (except linkers) to multiarch paths anyway and completely ignore libdir and slibdir. [17:24] Except for biarch packages. [17:24] s/affect as/affect us/ [17:26] so, up through quantal we had /etc/default/qemu-kvm to store some settings, and /etc/init/qemu-kvm.conf to do stuff with them. it had been claimed the default file should be dropped bc it slows things down. but that causes trouble when ppl make changes and the iniwupstart script changes. [17:26] woudl anyone object if i switch back to /etc/default/qemu-kvm? [17:31] all right i'll put that off fornow [17:32] infinity: hey, do you know who (or you?) should I ask for some regular ppa scoring (we have a feature ppa when we need a higher score for daily build to have amd64 packages built timely)? [17:33] didrocks: webops [17:33] didrocks: A one-time scoring of some time-sensitive builds, or a rescoring of the PPA itself? [17:33] thanks cjwatson [17:33] https://wiki.canonical.com/Launchpad/PolicyandProcess/PPAPriorityPolicy [17:33] infinity: rescoring of the ppa [17:33] didrocks: As Colin says, webops if it's the latter. [17:33] * didrocks reads [17:33] thanks infinity, cjwatson [17:35] infinity: we can actually rescore a whole PPA ourselves [17:35] infinity: (through API) [17:36] stgraber: we can, but the policy is there to protect us from world+dog asking us to [17:36] stgraber: after a problem of that kind [17:36] (well, in part; it's also useful justification and makes sure that there's a central group tracking what's been scored up, at least in theory) [17:36] cjwatson: hmm, yeah, I guess it makes sense for webops to handle all PPA tweaking so they can keep a log of what's going on [17:37] especially if it all goes through RT tickets as requested in that doc [17:45] bryce, I have an Xorg apport crash file from a jenkins autopilot run that seems to be inspectable. Do you mind giving it a look see? http://mterry.name/_usr_bin_Xorg.0.crash [17:53] kirkland: Can't. Stop. Laughing. [18:49] infinity: it's good stuff :-) [18:49] =o === dpm is now known as dpm-afk === rickspencer3_ is now known as rickspencer3 [19:16] jamespage: think i figured out the kvm problem you're having. it's hillarious really. i need to create group kvm in preinst not postinst. [19:17] mterry: did you see my ping about bug 1056545? [19:17] bug 1056545 in sessioninstaller (Ubuntu Quantal) "session-installer crashed with AlreadyCalledDeferred in callback()" [High,Triaged] https://launchpad.net/bugs/1056545 [19:17] bdmurray, yes, commented in bug, have filed a merge upstream [19:18] mterry: oh, maybe I should have refreshed or subscribed ;-) [19:18] :) [19:19] xnox: hi, perhaps it would be more useful to talk through the file bridge stuff here rather than having our mails cross in the mp :) [19:20] slangasek: maybe =) [19:21] slangasek: what were your thoughts? [19:21] * xnox thinks jodh might be end of day by now. [19:21] slangasek: how come inotifywait -r -m /foo/ handles it fine then? [19:21] xnox: well, per my last mail, the stuff you're doing is out of scope for what I believe the desktop team needs [19:22] xnox: I don't know anything about inotifywait, but I talked about this with jodh and he made it clear that the corner cases are a giant rathole [19:23] one which we don't need to stick our heads into [19:23] slangasek: well, let me re-read the code, as it looks like if the directory does not exist a watch on one above is established and later moved further down, such that this should be supported. [19:24] slangasek: I'm just thinking about for example a first login of a brand new account will recursively create many directories. Maybe some of the common onces should be moved into skeleton? Like ~/.cache ~/.config ~/.local at least. [19:26] xnox: well, I know that jodh was trying to tackle the "watch parent dir, then move the watch when the next level is created" problem, but I believe the work was incomplete and I explicitly asked him not to block on completing it because I didn't believe it's needed [19:26] ok. [19:26] xnox: the first-login case is an interesting point; I was actually just wondering to myself if we have the same problem on package install [19:26] i.e., if dpkg unpacks /var/lib/service/foo and /etc/init/foo-monitor.conf out of order, does the file bridge get wedged? [19:28] and watching for /var/lib/service/foo/* or foo itself? =) [19:28] xnox: sorry, I haven't actually looked at the branch yet so am not sure what the semantic difference between those two is :) Would watching for "foo" mean watching for its creation? [19:29] /var/lib/service/foo/* seems to be what we want [19:29] but I'm not sure what watching '/var/lib/service/foo' would mean, if it already exists and is a directory [19:30] it seems like one can either for for files or directories. I didn't actually check how the distinction is made though. [19:30] slangasek: when is runlevel 2 emitted? before or after certain mountall events? [19:31] xnox: runlevel 2 is emitted only after the 'filesystem' event [19:31] which doesn't actually mean all filesystems are mounted [19:31] ;) [19:31] however, /var, /usr should be fully mounted [19:31]