=== Logan_ is now known as Guest22407 === Logan__ is now known as Logan_ === salem_ is now known as _salem === Logan__ is now known as Logan_ [03:17] Good morning === lynxman_ is now known as lynxman === mmrazik is now known as mmrazik|afk === gusch_ is now known as gusch === mmrazik|afk is now known as mmrazik [07:22] good morning === smb` is now known as smb === wedgwood_away is now known as wedgwood === doko_ is now known as doko === ckpringle_ is now known as ckpringle === pete-woods1 is now known as pete-woods [09:50] ubuntu-mir: please have a look at bug 1184927 [09:50] bug 1184927 in libnet-smtp-ssl-perl (Ubuntu) "[MIR] libnet-smtp-ssl-perl" [Undecided,New] https://launchpad.net/bugs/1184927 === ckpringle_ is now known as ckpringle [10:12] pitti, tested clamd locally and works, do you know why it can be failing? [10:17] * pitti runs it in a VM [10:26] whoa, this takes a long tie [10:26] time, even [10:28] it looks to me like touchpad's used to have a 'Touch mode' attribute in xinput --list, but now they don't? but touchscreens still do [10:32] didrocks,doko: could either of you have a look at bug 1184927? [10:32] bug 1184927 in libnet-smtp-ssl-perl (Ubuntu) "[MIR] libnet-smtp-ssl-perl" [High,New] https://launchpad.net/bugs/1184927 [10:32] cjwatson: just answered on it, promoting now [10:32] ah, thanks [10:32] yw :) [10:33] * cjwatson gives it a bug sub as well [10:34] yolanda: succeeds here too (I already ran it yesterday); perhaps this needs network access? [10:35] (done) [10:35] yolanda: the DC has restricted network access; there is a proxy [10:35] pitti, this just tests that the daemon starts, but let me try without internet access anyway [10:36] yolanda: the test runs awfully long, perhaps the daemon itself is downloading stuff at first startup? === mmrazik is now known as mmrazik|lunch [10:36] yolanda: in that case, perhaps the test can put in a tiny dummy DB [10:39] pitti oh, yes, the freshclam [10:39] that's the issue, yes [10:39] without that, clamd doesn't start [11:11] doko: when are you planning to have first archive rebuild? after Debian Import Freeze? [11:11] xnox, when binutils is updated to the trunk, hopefully next week [11:12] doko: ok, awesome. [11:13] ogra_, ping [11:13] tvoss, jau [11:15] could anyone sponsor my systemd upload in http://people.canonical.com/~pitti/tmp/ (systemd_202-0ubuntu8_source.changes) [11:15] I lost my GPG key an hour ago, and it's kinda nontrivial to retrieve it :( [11:16] moment [11:16] cjwatson: ^ FYI, this adds the /sbin/udevadm symlink to the initramfs [11:16] ta, was hoping for that :) [11:20] pitti: done === MacSlow is now known as MacSlow|lunch [11:21] so i am not sure whats going on :) [11:21] i am stuck at runlevel N 2 ... with / being ro mounted [11:22] but can't find any error in dmesg etc. [11:22] i can mount / -o remount to get a writeable FS [11:22] and use irrsi now :) === mmrazik|lunch is now known as mmrazik [11:23] any ideas? [11:23] this is raring [11:24] cjwatson: do you mind if I remove ${misc:Depends} from nvidia-persistenced? It's because of this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709482 [11:24] Debian bug 709482 in debhelper "dh_installinit: permit file-rc for upstart jobs" [Serious,Open] [11:25] tseliot: uh, file-rc doesn't exist in Ubuntu, so there's no need to take account of that bug in Ubuntu [11:25] So yes, I mind :) [11:25] cjwatson: oh but we don't have that version of sysv-rc either [11:26] Sure we do [11:26] sysv-rc | 2.88dsf-41ubuntu1 | saucy | all [11:27] cjwatson: what about Precise? I'm supposed to backport this to Precise [11:27] tseliot: precise has a different dh_installinit [11:28] And it doesn't add that dependency - if it did we would be in trouble! [11:29] cjwatson: cheers [11:29] tseliot: You know that pretty much every other package in the distro that ships upstart jobs relies on dh_installinit, right? [11:30] If it works for them, it ought to work for you [11:30] I don't mind if you need some tweaks, but dh_installinit should be the baseline [11:31] cjwatson: ok, it's the first time I use it and I'll keep it in mind for any other packages that install upstrart jobs [11:55] xnox, if you feel like taking a look, i just uploaded android-tools with an adbd patch [11:56] (surely needs more cleanup) [11:56] ogra_: cool. [11:58] ogra_: looks like it is around time for me to take a look at ubuntu changes ;D [11:59] hrw, yeah, we're at ubuntu4 already :) [12:00] ogra_: ;) [12:01] ogra_: and I can do changes only though Debian now ;) [12:01] well, you dont want my latest patch directly in debian i guess [12:01] it largely duplicates core/adb [12:02] xnox: hey ... any idea how i can find out why my system mounts / in ro? [12:02] ogra_: it adds new binary package so I would not be able to upload it anyway [12:02] xnox: i cant find anything interesting in dmesg/syslog [12:02] have run fsck in recovery ... no errors [12:02] i guess you rather want to build twice in core/adb and have it spit out adb annd adbd in succession [12:02] etc. [12:03] hrw, oh, now i get it [12:03] xnox: also nothing about mount in /var/log/upstart ... no clue what is going on :) [12:04] ogra_: to be honest your way is cleaner than doing two vpath builds & dealing with clashing objects. Why did you commit the tree instead of doing "cp adb/ adbd/" in debian rules as first step, and "rm -rf adbd/" in clean? [12:04] (s/commit/add to the patch/) [12:04] +1 to xnox note [12:04] or are the two trees different? [12:04] xnox, because it isnt completely identical [12:05] xnox, doko: hi, what's the status of qt4-x11/gcc fixes? [12:05] do you want a patch from me that disables pch? [12:05] ogra_: i thought it was mostly conditionals + some extra files for the other one. [12:05] well, diff the two dirs :) [12:05] mitya57: yes, that is the way forward at the moment. [12:05] ogra_: ok, I should. [12:05] ;-) [12:05] most can likely be #IFDEFed [12:06] asac: /var/log/boot.log? [12:06] * mitya57 copies some lines from debian [12:12] stgraber, ogra_: I don't suppose either of you know where we stand on the chroot flip on ubuntu mobile, and if there is a bug or ML thread or something that I can use to track progress? [12:13] dunno, ubuntu mobile is dead since a few years :P [12:13] ev, but joking aside, we should have something by end of the week [12:13] hahaha [12:13] cool [12:13] xnox: lp:~mitya57/kubuntu-packaging/qt-no-pch (not tested, obviously) [12:14] ev, https://blueprints.launchpad.net/ubuntu/+spec/client-1303-containers-host-client-ubuntu-android [12:14] * Laney meeps at mitya57 [12:14] I saw you were looking at getting vte.sh sourced somehow - where does that stand? [12:14] mitya57: thanks, will run a test build on arm here. [12:14] ah! That's exactly what I was after. Thanks ogra_ [12:14] ev, i should be done with the initrd stuff today and will start working on the lxc bits [12:15] Laney: after your update in Debian it stopped working for me [12:16] you should just have to source it [12:16] that works for me anyway [12:16] I also asked doko to see if we can create something like /etc/bash.rc.d, but he didn't say anything yet [12:16] xnox: doesnt complain about anythging there [12:16] let me reboot one more time [12:16] ugly [12:17] Laney: but we aren't going to make all users source it from their ~/.bashrc, right? [12:17] no [12:17] but I don't know what a good solution looks like [12:18] doko: maybe we can follow Fedora (i.e. source /etc/profile.d/* in both login and non-login shells)? [12:18] apw, ogasawara : did you have a chance to have a look at the binutils in ubuntu-toolchain-r/test ? [12:20] mitya57: A parallel solution will have to be done for zsh too [12:22] (since vte.sh supports it) [12:28] Laney: yes, and that sounds like the least hacky solution to me (following Fedora) [12:28] I don't know anything about the arguments for/against that, but I bet people have opinions === _salem is now known as salem_ [12:29] Laney: "after your update in Debian it stopped working for me" — please ignore, works fine now [12:33] asac: not sure how to get more logs, as well filesystem is readonly and we need to output logs somewhere.... have you tried booting in to live CD and doing fsck / mounting the filesystem to see if everything is ok with it? === MacSlow|lunch is now known as MacSlow [12:38] doko, now i did start, but i can nolonger remember how far i got [12:43] hi, i'm looking to install clamav-freshclam database files locally, but i'd like to have a set of smaller files to embed them, anyone knows about it? clamav-freshclam files are more than 30mb each === mmrazik is now known as mmrazik|afk [12:59] mmrazik|afk, ping === mmrazik|afk is now known as mmrazik [12:59] tvoss: pong === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik [13:26] cjwatson: if the diff looks good to you I'll reupload nvidia-persistenced [13:26] tseliot: it's fine with the modification I sent by mail [13:32] cjwatson: the bzr branch of grub2 appears to be buggered... trying to build a clean bzr branch of lp:ubuntu/grub2 gets me a bunch of dpkg-source errors about upstream files changed, a number of which it thinks are binary files even though they are not. [13:32] psusi: wrong branch anyway [13:33] apt-cache showsrc grub2 | grep ^Vcs [13:34] cjwatson: I thought that lp:ubuntu/grub2 was an alias to that ( at the appropriate release )? [13:35] It is not [13:36] Sorry [13:36] If I make it an alias then the automatic importer will start mucking around with it and I don't want it to [13:37] mterry: ping [13:38] ugh... sucks having multiple branches especially when the canonical one is bad [13:41] Honestly I'd rather finish getting everything synced up with Debian and then completely ignore any Ubuntu branches [13:43] zul, pong, about the MIRs? I'm going to look at them today [13:43] mterry: cool thanks [13:44] whether they are actively used for development or not, you should still be able to branch from them and get the correct and working sources [13:45] even if it is just an auto import of the source deb [13:46] Sorry, not a problem I'm going to spend any time on [13:46] I'm sure it can be made to work with some fiddling [13:48] But it's not worth any of my time, because any branches people create based on that won't be mergeable into the branches I care about anyway === francisco is now known as Guest51059 [13:59] cjwatson: lp:~ubuntu-core-dev/ubuntu/raring/grub2/raring also fails to build.. quilt patches won't apply because they are already applied... I am guessing you did a merge from the debiaan branch that already had them applied into the ubuntu branch, which keeps them unapplied? [13:59] maybe I'll have better luck with apt-get source... [14:03] Is there any requirement for the language and toolkit chosen for working on new Ubuntu apps? I worked on Contributor Console a while back (https://wiki.ubuntu.com/ContributorConsole) using Gtk and Python, but I would prefer to use Qt and C++ or Python. Would this be okay? [14:03] iBelieve: yes. === dholbach_ is now known as dholbach [14:05] xnox, Yes, meaning yes it is okay? I know Ubuntu apps can be written in any language & toolkit, but I wanted to double check on this since it is an Ubuntu-designed app for inclusion in Ubuntu. [14:08] iBelieve: we often have preferred technologies and toolkits, but it's not very constrained. Something GUI targetting desktop can be written in Gtk/Qt in any of languages those support. For touch friendly UI on Ubuntu Touch platforms QML/Qt is the only one supported at the moment. [14:09] iBelieve: all of above toolkits are in "main" and are good dependencies, that will be provided on Ubuntu for a long time. [14:10] xnox, thanks for the pyqt5 info :) [14:10] xnox, Okay, thanks for clarifying that for me. [14:10] brendand: =)))) hehe. [14:11] xnox, do you know anything about how to add bindings? [14:11] xnox, or someone who does? [14:11] brendand: i have a branch & ppa somewhere with best efforts. Not sure where mitya57 hosts his at the moment. But yeah, there are not enough bits to have Declarative2.0 nor even attempt running Ubuntu Touch components. [14:13] brendand: well riverbank uses "sip" to generate bindings from C++ libraries, so if you look into pyqt source package you will notice all the files that are used to create the bindings from the c++ Qt libraries. But I don't have more info/knoweledge in writing those. [14:14] xnox, having a look at your best efforts might be informative [14:14] xnox, yeah i saw about sip, but no idea how to use it [14:14] brendand: i'm guessing we'll need bindings for QtQuick + any other qtubuntu-* libraries we wrote. [14:15] but I'd rather wait for riverbank to wrap QtQuick, it's getting closer. [14:15] xnox, yeah, but we somewhat don't have the luxury of time [14:15] brendand: what's the story with python? I would rather thought that python uses too much memory and battery to run UI apps. [14:16] brendand: oh. we need python?! I see. when do you want it by? july? october? [14:17] cjwatson: I think I've fixed it for good [14:17] xnox, well this isn't quite what you think it is i guess [14:17] xnox, we have the whole core of our application written in python [14:17] xnox, and we have to implement a ui in the next 3 months === barry` is now known as barry [14:18] xnox, so we need to decide the toolkit to use [14:19] xnox, ubuntu sdk sounds good, but then there's the question of interfacing with the python core [14:19] xnox, we aren't even neccesarily talking about running on the phone [14:19] long trem that will be the same :) === davmor2_ is now known as help [14:20] brendand: i see. [14:20] *term [14:20] theoretically depending on the platform api should get you what you want === help is now known as davmor2 [14:21] brendand: it's a hard choice. And python-qt5 is not here yet. But using pyqt4 (without deprecated / removed in qt5 functionality) should be ok. You will not have QtDeclarative 2 (aka quick) today, but there is declarative 1 packaged with pyqt4. [14:22] brendand: I am expecting that saucy will ship pyqt5 in one way or another. And there is a chance it will have declarative (aka QtQuick) [14:22] xnox, i was of the understanding that the ubuntu sdk will not work with Qt4 [14:23] brendand: it doesn't. ubuntu-sdk = Qt5 + custom touch widgets for mobile/touch platforms + webkit (... and JS frameworks) + other libraries (e.g. android hw sensors) [14:23] it's a meta-package =) [14:24] brendand: at the moment python is not part of it, at all. [14:24] xnox, ok, so if we narrow down to just the widgets - can we use that with Qt4? [14:25] xnox, that's really all we want [14:25] brendand: but if you are after python, using pyqt4 with expectation to migrate to pyqt5 once it's availabe. is the best bet. [14:25] xnox, we mainly want to avoid writing our own widgets [14:25] psusi: I strongly prefer keeping patches applied, yes. Use http://paste.ubuntu.com/5710351/ if it helps [14:26] brendand: well the desktop UI widgets is part of standard Qt and are available in both qt4 & qt5. (the ones to drive with mouse ;-) ) [14:26] brendand: the UbuntuTouch components are for Qt5 with QML and QtQuick only at the moment. [14:26] psusi: You're mistaken that the Ubuntu branch keeps them unapplied - it's just that .pc isn't checked in [14:26] So you can use that dpkg-quilt-setup script to initialise things properly [14:27] brendand: maybe you should talk to ubuntu-sdk team. they might have better answers for you. [14:32] anyone with experience with clamav? [14:32] yolanda: try ScottK [14:33] ScottK , i'm trying to generate a set of small cvd files just for testing, without connecting to net and executing freshclam, but i'm having some issues [14:34] Hi all. I'm talking with an upstream who is introducing a "helpful" step in their build system that bodily copies 'foo-dev' package's files into their source tree, overwriting ones there already, if you indicate that you don't want to use their bundled foo library. There's no obvious "clean" step after this. I think I should argue with them that this is a bad idea, but I don't know all the rationalle in debian-policy for the clean step of rules. [14:34] What problems does it solve? [14:35] We compare the result of clean to the orig tarball, right? Why? [14:36] qengho: whilst it's unhelpful, you just have to make sure you use e.g. a bzr branch for packaging and do $ bzr bd to do out of the tree builds. If you do not intend to patch the libraries, then you can extend ./debian/source/options to ignore diff in the mangled directory. [14:36] see dpkg-source manpage for more info. [14:37] xnox: okay, yes, am using bzr u-d-d and it's 3.0 (quilt) format. [14:38] qengho: the package should build twice in a row, as per debian policy. So clean; binary; clean; binary should work from the same unpacked tree. And there are plently of package that modify their original sources at build time. [14:38] so yeah, just extend ignore diff option, and carry on. [14:38] xnox: yes, I do not intend to patch any of the files that they'd be copying in to their tree from the rest of the distro.. [14:41] pitti, Do "we" know of any udev related issues in current saucy? (maybe related to previous udevadm mentioned) [14:42] smb: until a few hours ago we didn't have the /sbin/udevadm compat symlink in the initramfs [14:42] * smb sees Xen guest failing to mount/find /dev elements and there are missing lvm symlinks [14:42] mmrazik, ping [14:42] aka bug 1184066 [14:42] bug 1184066 in casper (Ubuntu) "Cannot boot usb live media: hardcoded paths to udevadm (2013.05.24 daily live)" [Critical,Fix released] https://launchpad.net/bugs/1184066 [14:43] smb: oh, I don't know about that one [14:43] pitti, Yeah, the guests probably have that issue [14:43] I mean not getting /dev/null and such [14:43] so far I have https://launchpad.net/ubuntu/+source/systemd/+bugs under tight control (and am subscribed) [14:43] 1184066 shouldn't affect xen guests itself, unless they have scripts that call /sbin/udevadm [14:43] tvoss: pong [14:43] even that, in the actual system the symlink has always been there [14:43] ... in the initramfs, yes [14:44] the only ones I found in my initramfs were casper and cryptsetup, and I fixed both [14:44] hardcoded paths are evil even if they're correct :) [14:44] It feels like the mini-isos / pxeboot I use to install miss things in initramfs [14:45] It would help me if you could explain a bit more precisely what you're seeing? [14:45] e.g. which stage of installation / boot are things failing at, with what error messages, etc. [14:46] cjwatson, I try pxeboot installs which get a kernel panic when trying to kill init and the last messages before say /dev/null cannot be found (twice) and mounting /dev/pts fails [14:46] smb: exactly which image? [14:46] (url) [14:47] cjwatson, A second, I have to check what cobbler-ubuntu-import goes for [14:47] pitti: fwiw, udev-udeb is missing the symlink too - that might not hurt [14:47] rather, adding it there too might not hurt [14:48] cjwatson: ack; do you want that uploaded now, or should I just stage it in git? [14:49] wgrant: FYI, I just "fixed" the lxc saucy branch in UDD. The old branch was completely messed up so I moved it to lp:~ubuntu-branches/ubuntu/saucy/lxc/broken-saucy, took the raring branch, re-imported all the .dsc for saucy and pushed to lp:~ubuntu-branches/ubuntu/saucy/lxc/saucy then changed the branch for the saucy-release to point to it [14:49] cjwatson, http://archive.ubuntu.com/dists/$REL/main/installer-$ubuntu_arch/current/images/netboot/mini.iso [14:49] cjwatson, But let me run the update again to make sure it really is current [14:50] should be easy for me to have a look - one sec [14:50] pitti: let me see how pervasive the problems are [14:50] wgrant: I expect the importer to be a bit grumpy about this, however since it hasn't been working for us for over a year anyway, it's not really bothering us that much :) [14:53] cjwatson, Ok not changed but the correct url is http://archive.ubuntu.com/ubuntu/dists/saucy/main/installer-amd64/current/images/netboot/mini.iso [14:54] smb: something is very unhappy here (testing i386), but I'm not sure it's udev's fault [14:57] smb: (bug 1185053, concurrently, from plars) [14:57] cjwatson, It could be something else causing /dev elements to be missing. I was just first-guessing udev because on the already installed host running saucy I got this weird thing of not all symlinks (/dev/mapper and /dev/) showing up [14:57] bug 1185053 in debian-installer (Ubuntu) "Saucy server images do not boot for 20130528" [Undecided,New] https://launchpad.net/bugs/1185053 === gusch_ is now known as gusch_|away [15:04] pitti: this installer failure is udev's fault somehow, and it's something different, so certainly don't upload yet :) === dholbach_ is now known as dholbach === tkamppeter_ is now known as tkamppeter [15:09] pitti: Shouldn't start-udev be mounting devtmpfs, not tmpfs? It used to. [15:10] cjwatson, When looking again on the bare-metal boot (the one with many LVs) I see a segfault of systemd-udevd and several "cannot open /dev/null"s [15:10] pitti: http://paste.ubuntu.com/5710472/ - part of diff between broken/working installer images [15:10] cjwatson: I thought that moved to /lib/init/fstab ages ago [15:10] pitti: not in the udeb [15:10] smb: bare-metal boot of what stage? the installer, or the installed system? [15:10] oh, for udeb [15:11] smb: these are completely different stacks and I really need clarity of which you're talking about [15:11] cjwatson, installed system [15:11] smb: ok, that must be some different bug from the one I'm looking at, although it appears to share similar symptoms [15:11] cjwatson, Yes, sorry for throwing them into the middle [15:12] specifically, "cannot open /dev/null" suggests an empty /dev rather than a devtmpfs [15:12] ah, found the script; I'll update that to the previous version [15:12] now whats possibly wrong with that sentence :) [15:13] well, it doesn't have to be the *entire* previous version, which e.g. assumes udevd on $PATH and has a hardcoded /sbin/udevadm path [15:13] yeah, I mean the /dev and /dev/pts/ mounting [15:14] I wonder how the version in Debian manages to work [15:14] indeed, that seems ancient (make_extra_nodes..) [15:14] well, that's the version you're using here [15:15] but I don't understand how it works anyway, unless udevd is creating /dev/null manually [15:15] the bug here is basically that you seem to have reverted start-udev to the Debian version, so I'm wondering how the Debian version works :_ [15:15] :) [15:16] it might be more sensible to go back to the previous entirely different version we had in Ubuntu, but just update the udevd and udevadm calls [15:16] yes, that's more or less what I'm doing now; I have the old and current script [15:19] so, the script more or less looks like the old one now, except for the added "modprobe -q scsi_wait_scan && modprobe -r scsi_wait_scan || true" bits [15:20] not sure whether d-i has some fake module with that, but it certainly doesn't exist in the running system [15:20] we didn't have it before, so I'll just drop it [15:22] cjwatson: after three cleanup commits, http://paste.ubuntu.com/5710512/ is the diff between the old and my current version of the script [15:22] d-i has no such things as fake modules [15:22] pitti: looks ok if you don't need the /proc/sys/kernel/hotplug bit any more [15:24] cjwatson: it's an alias for /sys/kernel/uevent_helper, and that's a more modern name [15:24] ok [15:24] i. e. if you echo something to /proc/sys/kernel/hotplug, you get the same if you cat /sys/kernel/uevent_helper [15:25] (and vice versa) [15:26] cjwatson: ah, http://lwn.net/Articles/166954/ mentions this as well [15:26] wow, that was 2006 [15:28] mterry: thanks for looking, i replied to your pbr question [15:28] cjwatson, smb: ok, time for another upload then, I guess? [15:28] I should be able to again [15:29] pitti: yes please :) [15:29] At least that sounds like fixing quite some badness. Not sure it also does something with the other oddness but yeah [15:29] zul, out of curiosity, why is it called pbr? [15:30] mterry: python build reasonableness [15:30] zul, :-| [15:31] yeah [15:31] pitti, I don't understand it yet. Somehow starting in xen mode systemd-udevd has some issues with device-mapper/lvm, and when I start in non-xen mode (at least on the amd server) it seems to hang trying to send some xen socket event [15:31] smb: the former certainly sounds related to the missing devtmpfs (you wouldn't have most stuff in /dev/) [15:32] But start-udev isn't called anywhere but the udeb, is it? [15:32] So if it's a similar bug, it seems like it must be in some other place too [15:32] mterry: im pretty sure when it hits debian it will come from us anywyays [15:32] pitti, Though after boot at least /dev is a devtmpfs [15:32] cjwatson: right [15:33] I thought we arrived at start-udev while debugging smb's problem (sorry, no idea how xen works, I assumed it was during installation) [15:33] pitti, Yeah, sorry the confusion is that I talked about two different issues [15:34] didrocks, ping [15:34] pitti, One is with the installation of guests which is what you likely solved [15:35] slangasek, ping [15:35] pitti, The other problem is on the already installed host during boot. There seems to be one fallback in initramfs if devtmpfs fails but I cannot say whether that is hit or not as I am not sure where that message would end up in === cjohnston_ is now known as cjohnston [16:07] tvoss: pong === mmrazik is now known as mmrazik|afk [16:12] cjwatson: as for bug 1185053, did that d-i rebuild include the new udev-udeb? i. e. were we still using the old version before? [16:12] bug 1185053 in systemd (Ubuntu Saucy) "Saucy server images do not boot for 20130528" [Critical,Triaged] https://launchpad.net/bugs/1185053 [16:12] Yes [16:12] ah, that explains it then [16:12] my plymouht change from yesterday really sounds unrelated [16:12] plymouth cannot possibly have anything to do with it; that was misdiagnosis [16:13] plymouth isn't even used at server installer boot time [16:13] I was expecting you to close that bug with your systemd upload, TBH :) [16:14] cjwatson: yeah, I saw it too late [16:14] but we need a d-i rebuild for it to really be fixed then [16:18] pitti: yes, I'm waiting for systemd to build everywhere [16:18] (and publish) === greyback is now known as greyback|food === gusch_|away is now known as gusch === mthaddon` is now known as mthaddon === jono is now known as Guest93857 === greyback|food is now known as greyback === glebihan__ is now known as glebihan [17:33] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry === wedgwood is now known as wedgwood_away [18:03] hmm [18:03] Setting up android-tools-adbd (4.2.2+git20130218-3ubuntu4) ... [18:03] All runlevel operations denied by policy [18:03] invoke-rc.d: unknown initscript, /etc/init.d/android-tools-adbd not found. [18:03] dpkg: error processing android-tools-adbd (--configure): [18:03] does the new world order require that my package ships a sysvinit script ? [18:05] (with the init_is_upstart stuff ... ) [18:05] i was assuming if i only create a .upstart file debhelper takes care of the rest, isnt that the case ? [18:10] hmm [18:10] Setting up libpam-systemd:armhf (202-0ubuntu8) ... [18:10] All runlevel operations denied by policy [18:10] invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. [18:10] seems to have the same issue [18:18] cjwatson: seems we can rebuild d-i now; are you on it, or shall I upload a rebuild? [18:22] ah, libpam-systemd makes all other arches fail too [18:24] slangasek, ^^^ is having an debian/*.init script mandatory with https://wiki.ubuntu.com/UpstartCompatibleInitScripts ? [18:25] ogra_: cjwatson and I discussed this bug already; this is actually an unanticipated bug in invoke-rc.d [18:25] so I'm working on fixing that [18:25] (teh wikipage doesnt really say that) [18:25] ah, k [18:26] Debian policy does say that you shouldn't ship upstart jobs without corresponding init scripts; however, that's Debian, not Ubuntu [18:26] * ogra_ will give up on image builds for today then [18:27] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, jdstrand [18:27] I'll have a fixed sysvinit package uploaded sometime today. Basically, this issue only arises in chroots where initctl can't talk to upstart (so chroots on really old hosts, basically) [18:28] jdstrand: howdy. let me know what you're working on so we don't step on each others toes [18:28] barry: sure, thanks. I'm starting with some security sponsoring bugs [18:28] jdstrand: cool === mmrazik|afk is now known as mmrazik === greyback is now known as greyback|away [18:53] pitti: doing [18:53] (interrupted by dinner) [19:35] ogra_: fixed sysvinit uploading shortly, fwiw [20:05] stgraber: is there a way to overwrite/modify upstart user sessions scripts with an own version? I just found out why my gpg card stopped working for ssh logins (the gpg-agent upstart session script is missing the option for it) [20:06] geser: yep, you can dump your own copy in ~/.init/ or just a .override file if that's simpler [20:18] stgraber: thanks, almost there. Can initctl set-env also set two variables or do I need two calls for this? [20:19] I have a replacement package modules-tools-init-z which Provides: and Conflicts: with modules-tools-init (same package with zlib enabled) in my local repo (together with the rest of Precise). Try as I might I can't get debootstrap to use it. I'm using --include modules-tools-init-z and --exclude modules-tools-init. Any ideas? [20:21] geser: I believe you need two calls for that [20:21] (source at https://github.com/abligh/modules-init-tools-z if anyone is interested) [20:24] bdmurray: should i re-add verification-needed back to bug #1173249 as well? [20:24] bug 1173249 in aptdaemon (Ubuntu Quantal) "update-software-center AttributeError during upgrade from 12.10 to 13.04" [High,Triaged] https://launchpad.net/bugs/1173249 [20:25] alexbligh1: not sure about it but as module-init-tools is priority required it might make you it more difficult to replace it [20:27] stgraber: yeah, using my gpg card for ssh authentication works again. Thanks [20:29] bdmurray: oh, nevermind. i see it hadn't been removed [20:38] geser, hmm, perhaps I should set mine to priorty: required. I can also exclude module-init-tools from my repo I guess. I am really hoping debootstrap looks at Provides: [20:40] hmm, I suppose I could write my own debootstrap script [20:43] alexbligh1: Provides only works if there is no versioned dependency on module-init-tools. Is there a reason why you don't just provide a modified version in your repo and keep the package name? [20:46] Could someone please do a give-back of geoip-database in saucy-proposed. It builds now the the current geoip-bin package in saucy. [20:49] geser, hmmm - I suppose I hadn't thought of the ability to filter module-init-tools on pull from the precise-upstream (I'm trying to make it update automatically) [20:49] but you are probably right, that is the path of least resistance. I thought I was doing it properly :-/ [21:08] alexbligh1: There are tons of versioned deps on module-init-tools, you really should just build your own differently-versioned package, rather than changing the name. [21:10] alexbligh1: More interestingly, is there an argument for why we might want/neet this in precise proper, rather than just your repo? [21:12] infinity, yes, it saves 100MB out of 150MB on initramfs [21:13] infinity, talk tomorrow - have company now! [21:14] barry (or any other familiar with building for Python 2 and 3): if you have some time: could you check if my patch in bug #1185170 looks sane or if there is a better way to solve this? [21:14] bug 1185170 in python-json-patch (Ubuntu) "setup.py stumbles about an umlaut in jsonpointer.py when running under Python 3" [Undecided,New] https://launchpad.net/bugs/1185170 [21:15] geser: possibly, if i can finish this current package in time. [21:15] barry: no hurry [21:36] barry: could you look at syncing cython? as a source generator its good to have it early to avoid surprises in rebuilds later [21:38] or doko you probably know best if the patch is forwarded [21:38] please add dep3 headers ._. === greyback|away is now known as greyback [21:53] bdmurray: I've done some analysis on bug #1069019 and isolated the bug; I don't recall the right way to fix this particular class of python3 unicode problem though [21:53] bug 1069019 in python-apt (Ubuntu Saucy) "[software-properties-gtk] can not delete, enable or modify any software source with non-ASCII characters in the comment" [Medium,Triaged] https://launchpad.net/bugs/1069019 [21:57] barry: ^^ I'm not doing enough bilingual python to remember the recommended approach for making sure the right encoding is used for I/O regardless of locale; can you remind me? [21:58] slangasek: might it be: open(filename, encoding='utf-8') (or whatever encoding you want)? [21:59] geser: that's not bilingual - it fails for the python2 case, which still needs to be supported here [22:00] ah, than that's the same case I tried to fix in a FTBFS (which I asked barry to review) [22:00] possibly io.open() [22:02] stackoverflow suggests also io.open() [22:05] io.open is OK as long as it never gets passed bytes in Python 2 [22:06] slangasek: perhaps the runes in germinate.seeds would be helpful [22:06] (if you need to tolerate being passed bytes) [22:06] oh, that was for writing, not reading [22:07] so, yeah, io.open is probably OK. It was slow in 2.6 but I believe is OK in 2.7 [22:08] cjwatson: right; we should be able to ensure that anything we're writing is unicode, and the code does guard against writing out a file that it's previously failed to read in [22:12] hmmm, though the code doesn't /currently/ ensure it's not doing bytes in python2 [22:16] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand [22:17] geser: okay, i won't get to it today, but i've got the tab open for tomorrow [22:17] jtaylor: can you open a bug and paste me the #? i won't get to it today, but possibly tomorrow [22:18] slangasek: totally different ways to do it if it's python2 or 3 :) [22:18] barry: no problem, I've added a 2nd debdiff which uses io.open() instead of my previous attempt (based on the recent discussion here) [22:19] barry: whimper [22:19] although codecs.open(..., encoding='whatever') is available in both [22:19] barry: so do you advise against using io.open() ? [22:20] barry: well, let me push what I have here for your review [22:20] slangasek: io.open() can work, but it will be slow in py2 and non-existent in py2 < 2.7. codecs.open() is probably better if it has to work in both [22:21] barry: it's python-apt; so it doesn't have to be portable to anything except the current version of python2 [22:21] (I would argue) [22:22] slangasek: i'd probably still use codecs.open(). io is pure python in py2.7 (iirc) so it can be slow. it's nicely rewritten in c for py3 [22:22] :) [22:22] barry: hmm, cjwatson seemed to think io.open() exists in 2.6 but is slow, and is improved in 2.7 [22:23] * barry has to utsl [22:23] its implemented in C in 2.7 vs python in 2.6 I think [22:23] anyway, let me know if you think this is bletcherous (or just wrong): lp:~vorlon/python-apt/lp.1069019 [22:23] jtaylor: yep, you're right [22:23] * barry just wants to put a stake through the heart of py2 already! [22:24] cythongs test suite is to excessive 40 minutes test and counting :( [22:25] anyway, i'm eod for now. ping me tomorrow! [22:26]