[02:22] <alazare619> anyone in here an actual ubuntu builder im using the ubuntu livecd-rootfs/live-build scripts could use a little assitance
[05:24] <pitti> Good morning
[06:02] <Roj> hi how i can use Gwibber in my apps?i need resource :(
[06:04] <RAOF> Roj: What do you want to do?
[06:06] <Roj> i went to create unity lens for it :)
[06:06] <RAOF> How will this be different from the existing unity lens for it?
[06:08] <Roj> like pading lens
[06:08] <Roj> to seatch user in facebook or etc
[06:08] <RAOF> I'd start with unity-lens-gwibber
[06:09] <Roj> :( have lens for it?
[06:10] <RAOF> Yes.
[06:19] <Roj> you think i can use it in my app for submit in The Ubuntu App Showdown?
[06:56] <dholbach> good morning
[09:22] <dholbach> didrocks, care to join us again? :)
[09:22] <didrocks> dholbach: oh sure :)
[09:24] <iulian> Uh-oh! Sounds like a fancy party. Can I join you guys? :-)
[09:40] <ev> mpt: do you think we should try to fold the Help buttons into the main interface? http://people.canonical.com/~evand/tmp/Screen%20shot%202012-07-05%20at%2010.20.15.png They can get quite long though (see the Extended_description entries in /var/cache/debconf/templates.dat).
[09:45] <sladen> ev: 'needs your help' and '[help]' terminology confusion too
[09:45] <ev> sladen: yeah, the text is very much a work in progress
[09:45] <ev> https://wiki.ubuntu.com/ErrorTracker#debconf
[09:46] <ev> ^ is the design I'm slowly moving towards
[09:46] <ev> ah and indeed he's already covered this
[09:47] <sladen> ev: *nod* sounds like it's already designed; the text from the second-level dialogue would simply be placed in the main area as 'Long description in smaller print'
[09:47] <sladen> (if I understood correctly)
[09:48] <sladen> and 'Mailname of your system:' would be the 'Short description above'
[09:52] <bob235> hi, is this the right channel to ask about the qualtal debian import freeze?
[09:53] <bob235> i see from the qualtal release plan that 5 july is the debian import freeze
[09:53] <cjwatson> yes
[09:54] <bob235> i'm hoping to get the latest version of rabbitmq-server into qualtal
[09:54] <bob235> if i miss the deadline today have i missed the boat?
[09:54] <cjwatson> are you the Debian maintainer?
[09:54] <bob235> there is a sync request bug https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1018001
[09:55] <cjwatson> manual sync requests can be processed after Debian import freeze
[09:55] <bob235> yes i'm the debian maintainer
[09:55] <cjwatson> the only thing this freeze affects is that we won't run auto-syncs after today
[09:55] <sladen> bob235: you can do it manually later.  Tomorrow is the end of automatic syncs
[09:55] <cjwatson> so no, you have not missed the boat
[09:56] <bob235> phew, that's good news!
[09:56] <bob235> so what do i need to do manually later?
[09:56] <cjwatson> I'd rather leave it up to somebody like roaksoax or Daviey to check the manual sync request
[09:57] <bob235> ok, so i don't need to panic, and wait for Daviey to pick it up?
[09:57] <cjwatson> inded
[09:57] <cjwatson> *indeed
[09:58] <bob235> thanks for your help. i'll sit tight until that happens then
[09:58] <ev> sladen: exactly
[09:59] <ev> I was just spending too much time staring at the first mockup
[10:12] <cjwatson> stgraber: can the lttng-ust source package be replaced by ust 2.0.4-1 from Debian?  Noticed this while running auto-sync.
[10:16] <Fudge> hi can i report broken links on developer.ubuntu.com/packaging/
[10:17] <mpt> ev, are the Help buttons showing the "long description" part of the Description field?
[10:17] <mpt> If not, where are they getting their text?
[10:17] <mpt> And if so, I showed where the long description goes in the wireframes.
[10:17] <ev> mpt: yes - sladen and I were discussing that around 10:45
[10:17] <ev> indeed
[10:18] <ev> mpt: back and continue for the buttons?
[10:18] <mpt> ev, just Continue unless you want to implement back/forward navigation
[10:18] <ev> or was your intent to not treat it like an assistant at all?
[10:18] <seb128> @pilot in
[10:19] <ev> mpt: I'm asking because there's already back/forward navigation there
[10:19] <ev> as debconf does let you back up through questions
[10:20] <mpt> ev, I know, I'm asking you if you want to implement that in this cycle. If so, I'll add it to the design
[10:20] <ev> mpt: ah, apologies
[10:20] <ev> this would probably be so much easier if I just walked the 10 feet to you
[10:21] <ev> yay, sorted
[10:22]  * mpt giggles at the maximizable Help alert
[10:22] <ev> :)
[10:22] <mpt> I bet that looks just stunningly beautiful when maximized
[10:27] <sladen> empty space is beautiful
[10:32] <ev> mpt: for what it's worth, we're blocked on the compiz merge until we have that plan for dealing with applications hanging and coming back: https://code.launchpad.net/~ev/compiz/call-apport-on-hangs/+merge/113436/comments/243748
[10:33] <ev> if we can recreate the wonderful Firefox experience of ZOMG XUL IS HANGING! that would be ace :)
[10:35] <ev> mpt: ps. since you were curious: http://people.canonical.com/~evand/tmp/Screen%20shot%202012-07-05%20at%2011.34.14.png
[11:27] <dupondje> cyphermox: cjwatson: noted https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1021122 ?
[11:29] <cjwatson> dupondje: that's an entertaining arrangement of links
[11:29] <cjwatson> lrwxrwxrwx root/root         0 2012-07-04 14:56 ./usr/bin/apt-add-repository -> add-apt-repository
[11:29]  * cjwatson digs
[11:49] <cjwatson> dupondje: fix uploading now
[12:01] <dupondje> cjwatson: great :)
[13:11] <seb128> cjwatson, hey, do you know what's the status on https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/926340? it's assigned to you and on the LTS .1 list?
[13:11] <cjwatson> not got anywhere as yet, sorry, but I thought glatzor had indicated some kind of progress there
[13:12] <seb128> cjwatson, he asked you for a patch review mid june so I wondered if you had looked at the patch yet
[13:13] <cjwatson> he did?  argh
[13:14] <stgraber> cjwatson: hmm, I'm a bit surprised the Debian maintainer didn't also change the source name in the process, but yeah, the binary packages are the same so lttng-ust should be replaced by ust
[13:14]  * cjwatson looks
[13:14] <seb128> cjwatson, thanks
[13:25] <ScottK> stgraber: I didn't check if you dealt with avogadro or not, but we decided I'll fix it in python-qt4 in Debian.  If you fixed avogadro, no need to revert.  It'll be happy either way.
[13:28] <stgraber> ScottK: I uploaded avogadro yesterday afternoon
[13:28] <ScottK> OK.
[13:29] <ScottK> So for your purposes it's solved no matter what I do.
[13:32] <stgraber> right
[13:38] <cjwatson> seb128: replied now
[13:38] <seb128> cjwatson, thanks ;-)
[13:47] <apw> mvo, yo ... been playing with squid-deb-proxy and IPv6, finally figured out that the IPv4 records with IPv6 addresses make sense as that field refers to the broadcast channel we used to obtain the address and says nothing about the address itself
[13:47] <hallyn> cyphermox: libnl3 FTBFS waiting on source-highlight, which looks like it is published since apr 30.  any idea?
[13:48] <apw> mvo, anyhow, have put some patches together to advertise, prefer, a
[13:48] <cjwatson>     libnl3 |    3.2.7-4 |       quantal | source
[13:48] <cjwatson> source-highlight |    3.1.6-1 | quantal/universe | source, amd64, armel, armhf, i386, powerpc
[13:48] <cyphermox> is source-highlight in universe?
[13:48] <cyphermox> ah
[13:48] <cyphermox> so we'll have to file a MIR
[13:48] <apw> mvo, anyhow, have put some patches together to advertise, prefer, and use IPv6, under bug #1021298; branch attached
[13:48] <cjwatson> listed on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[13:49] <hallyn> cyphermox: d'oh, shoulda checked that
[13:49] <cyphermox> np
[13:49] <hallyn> cyphermox: i do have a hard time believeing that 'source-highlight' could be crucial to building libnl3...
[13:50] <cyphermox> hallyn: it's likely for the docs; if you want you can try to disable it ;)
[13:50] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657254
[13:51] <hallyn> cyphermox: i'll give it a shot.
[13:52] <mvo> apw: \o/
[13:52] <mvo> apw: I have a look  now
[13:53] <apw> mvo, i have tested it here, but only on an ipv6 enabled network, in theory it should work using link locals anyhow if you have them or fall back to ipv4
[13:53] <apw> mvo, so some testing on a normal network is in order before upload
[13:54] <ScottK> apw: It's not going to slow things down if there's no IPv6 is there (RFC 6555, Section 3.2 warns about this).
[13:55] <apw> ScottK, no the new code does fewer lookups so it should be quicker overall, it scans the same list twice picking any advertised v6 addys first, then falling back to ipv4
[13:55] <apw> ScottK, and as avahi is link local anyhow, in theory you should be always able to use the link-locals if they exist
[13:56] <apw> ScottK, but ... it does need some combintation testing before its released
[13:56] <ScottK> OK.  I get nervous about people 'fixing' stuff to look at IPv6 first as it's often gone astray in the past.  I'm glad you've thought it through.
[13:57] <ScottK> Besides, how often to I get to refer to an RFC titled "Happy Eyeballs"?
[13:57] <apw> ScottK, i am worried enough still :)  but also unless we try things we'll not get things fixed at all, and thats a worry with ipv4 creaking so
[13:57] <apw> ScottK, heh there is that indeed.
[13:57] <ScottK> Agreed.
[13:58]  * apw sees .eu has 3 weeks till it joins .ap
[13:58] <didrocks> ev: hey, did you get any more info on why I got all those errors on errors.ubuntu.com with my credentials?
[13:58] <didrocks> ev: it's really making hard using it :/
[13:59] <ScottK> Recently I got an RC bug in Debian on opendkim due to IPv6 problems.  It turns out it works ~fine, but the documentation for use with IPv6 was sorely lacking.  I get the impression real people are starting to use it.
[13:59] <ScottK> (it being IPv6)
[14:00] <apw> mvo, i wonder if i should be using the IPv6/IPv4 fields to 'enable' use of addresses in that realm ... as a hint we as a consumer have ipv6 for instance
[14:00] <ev> didrocks: I sadly haven't gotten to it yet. I don't suppose you could grab someone in #webops and see if you can pair through the issue? I imagine you'll have much more success than me trying to vaguely convey what's happening on your connection to them.
[14:00] <ev> didrocks: as the openid stuff is not something I build yet
[14:01] <ev> (it's currently an apache module, whereas in the future I hope to move to something like django-openid-auth, if I can rip the notion of writing to tables from its brain)
[14:02] <didrocks> ev: I'll try a losa ping
[14:02] <apw> mvo, ScottK, if you use squid-deb-proxy could you paste me the output of: avahi-browse -kprt _apt_proxy._tcp
[14:02] <ScottK> I don't.  Sorry.
[14:02] <apw> i can use those to test the algorithm
[14:02] <apw> np
[14:32] <xnox> dholbach: $ reverse-depends adept \n No reverse dependencies found
[14:32] <xnox> is there a removal bug?
[14:33] <dholbach> at least none https://bugs.launchpad.net/~ubuntu-archive is subscribed too
[14:33] <dholbach> to
[14:34] <dholbach> https://code.launchpad.net/~scarneiro/ubuntu/quantal/adept/fix-invalid-brace.expansions/+merge/111331 is how I found out about it (which can be rejected then)
[14:34] <dholbach> and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673085 in Debian, maybe for reference
[14:34] <ScottK> If the rdepends are gone, I'll remove it.
[14:35] <xnox> ScottK: do it ;-)
[14:35] <xnox> dholbach: ScottK: i was about to $ import-bug-from debian 673085 + subscribe ubuntu-archive ;-)
[14:35] <melodie_> Hi
[14:35] <ScottK> Save yourself the trouble.
[14:35] <xnox> thanks =)
[14:36] <melodie_> I have a few questions related to services in relation with bum package and chkconfig package. I wonder where would the right chan be ? the #ubuntu : no way, full with users now and impossible to get a hint
[14:37] <ScottK> xnox: Gone.
[14:37] <xnox> =)
[14:37] <ScottK> dholbach: ^^^
[14:37] <dholbach> fantastic - thanks
[14:37] <dholbach> can anyone reject https://code.launchpad.net/~scarneiro/ubuntu/quantal/adept/fix-invalid-brace.expansions/+merge/111331 because adept was removed from the archive?
[14:38] <xnox> dholbach: I will with a comment
[14:38] <ev> mpt, seb128: https://bugs.launchpad.net/errors/+bug/1021326
[14:38] <seb128> ev, thanks
[14:39] <ev> sure thing
[14:39] <stgraber> dholbach: rejected
[14:39] <dholbach> thanks
[14:39] <stgraber> xnox: I don't think you can actually reject a branch, all you can do on a UDD branch is post a review. You need to be part of ~ubuntu-branches to actually reject a MP
[14:40] <xnox> stgraber: it does offer me the reject option.... let me try
[14:40] <xnox> stgraber: nah, can't be asked, will try some other time.
[14:40] <melodie_> I'll rephrase : I tried to configure ssh for it to be started at boot in a Lubuntu precise but I could not find a tool for that in the distro and didn't know what file to look at. So I tried this package : http://packages.ubuntu.com/precise/chkconfig
[14:41] <xnox> melodie_: surely you want to install openssh-server..... or use @reboot cron job.... or write your own upstart job to do this
[14:42] <ScottK> Installing the server is both necessary and sufficient.
[14:42] <melodie_> it appears after trying that it is not only buggy for the path : it looks for /sbin/insserv whereas this file is in the /lib tree directory, but when for a test I create a symlink to please him, the command I launch then complains that it is not an Upstart Job
[14:42] <xnox> melodie_: try !askubuntu website in the future
[14:42] <melodie_> so I thought there are at least 2 bugs :
[14:42] <melodie_> one related to the program, one is that this program might be removed from the repos as becoming irrelevant : what do you think ?
[14:43] <melodie_> I am not trying to solve just one issue, but to see what I could do to help improve Ubuntu
[14:44] <ScottK> Since chkconfig doesn't know about upstart, I think it's unlikely to work on Ubuntu.
[14:44] <melodie_> askubunty might help me find a solution as ubuntu-fr.org can : I read French more comfortably, but there I found bum which does not solve because I can't find the ssh service in it. (and I don't know if this is a bug yet)
[14:45] <melodie_> xnox, and I have installed openssh-server, thanks. :)
[14:46] <melodie_> xnox, I don't want to write jobs or scripts, I don't code, I don't know how to do that, I can edit files, and click on buttons sometimes too. ;)
[14:46] <xnox> melodie_: i didn't ask you to code, but add configuration.
[14:46] <melodie_> and if there is a more relevant chan to discuss about the packages meant to ease the management of the services
[14:47] <melodie_> xnox, this is it : I am currently seeking for a tool or the info on which file to edit ?
[14:47] <xnox> melodie_: $ sudo apt-get install openssh-server
[14:47] <xnox> reboot
[14:48] <xnox> ssh-server is started on boot
[14:48] <xnox> what is your question?
[14:48] <melodie_> what is the file where it is written ?
[14:48] <xnox> melodie_: no need to write a file.
[14:48] <xnox> but if you want details
[14:48] <melodie_> yes, I would like to have details
[14:49] <melodie_> I can start ssh with console, but knowing better the new programs managing the services would be nice too
[14:49] <xnox> melodie_: $ ssh host; doesn't start ssh.... it creates a client session
[14:49] <xnox> melodie_: /etc/ssh/sshd_config is the sshd (server) settings
[14:50] <xnox> started by upstart using $ /etc/init/ssh.conf
[14:50] <xnox> melodie_: do you want server or client to be started on boot?
[14:50] <melodie_> I am thinking...
[14:52] <melodie_> I use both and confuse both too. I have a remove machine : squirrel, which I wanted to connect to the local machine "copernic" to send a file to it. I couldn't. I randomly installed the ssh-server and didn't retry since I was trying to find a tool where to configure the jobs at start, and was wondering why I can't set it up the way I want with gui tools
[14:53] <melodie_> suppose the server on "copernic" will allow connecting the remote "squirrel" to it ? (when I say remote it is still on a lan anyhow)
[14:54] <xnox> melodie_: on squirrel do $ apt-get install openssh-server
[14:54] <xnox> melodie_: on local machine open a folder -> file Connect to server -> select SFTP -> type squirrel your username and password
[14:55] <xnox> done
[14:55] <melodie_> xnox, squirrel already has it (a very old Archlinux install which is full with all what's needed)
[14:55] <xnox> melodie_: please go to #ubuntu this is nothing to do with development
[14:55] <xnox> melodie_: ask "how to connect to remote ssh server"
[14:55] <melodie_> xnox, sure. (all works now)
[14:56] <melodie_> xnox, what about the chkconfig package ? Should not I go somewhere (launchpad ? bug section ?) to say that it is not needed in the repos anymore ?
[14:56] <seb128> xnox, hey
[14:57] <melodie_> xnox, thanks, anyhow I know how to connect with ssh, sshfs and so on. I just wonder why it is so hard to find a gui to configure the services.
[14:57] <melodie_> I mean, one which offers the choices for all services installed.
[14:57] <xnox> melodie_: dunno. ask on #ubuntu-server. I am fine with editing files.
[14:57] <seb128> xnox, I'm doing some sponsoring ... you maintain mdadm right? do you plan to do a SRU update soon? I'm wondering if I should sponsor the fix from bug #946758 to precise or let that to you for a SRU (since I saw other issues are milestoned for 12.04.1)
[14:57] <xnox> seb128: yes?!
[14:58] <melodie_> xnox, ok I try, thanks
[14:59] <seb128> xnox, tldr ; should I upload https://launchpadlibrarian.net/109290854/mdadm.debdiff
[14:59] <xnox> seb128: no.
[14:59] <xnox> seb128: let me read now =)
[15:00] <seb128> xnox, yes, no ... you are a binary man :p
[15:00] <xnox> seb128: is there a bug or anything? this is just a launchpadlibrarian
[15:00] <seb128> xnox, the bug was in the first sentence I wrote
[15:00] <seb128> xnox, after the "hey"
[15:00] <xnox> ah
[15:00] <xnox> sorry to much highlight on the screen
[15:00] <xnox> =)
[15:00] <seb128> xnox, no worry ;-)
[15:01] <xnox> seb128: i believe that bug fix is already part of my sru, but it got rejected. So i only need to add a changelog entry and fix up the sru and re-upload.
[15:01] <xnox> seb128: i was planning to do it today or tomorrow.
[15:02] <seb128> xnox, ok, good, I will unassign sponsors and assign the bug to you
[15:02] <seb128> xnox, works?
[15:02] <xnox> seb128: so please don't upload... unless you claim to reproduce it and test it.
[15:02] <xnox> seb128: sure =)
[15:02] <seb128> xnox, it's all yours then, thanks ;-)
[15:03] <hallyn> cyphermox: libnl-3 seems to build find without source-highlight
[15:12] <cyphermox> hallyn: cool
[15:12] <hallyn> cyphermox: i don't have upload rights, do you mind making that change?
[15:12] <Laney> wait
[15:12] <Laney> the Debian bug said that it tried to download from the internet without that BD
[15:12] <Laney> hallyn: did you build in such an environment?
[15:13] <hyperair> it looks like bug #785822 which is the last remaining bug requiring verification-done for banshee can't be verified because nobody who experienced the bug in the first place is present to verify that it's fixed.
[15:13] <cyphermox> hallyn: that changes things a whole lot, should try building it in a PPA
[15:13] <Laney> wait, maybe I'm misremembering
[15:13] <seb128> hyperair, you can testify that there is no regression
[15:13] <seb128> which is good enough to verification-done it
[15:14] <hyperair> okay.
[15:14] <cyphermox> (and anyway, it would be a good idea to try to build some of the reverse-depends in case something changes that breaks them)
[15:14] <hallyn> sure, will try in ppa.  or i could just try in a container sans networking, iiuc
[15:14] <Laney> yeah
[15:14] <Laney> I think it might not be this bug I'm thinking of, though.
[15:15] <hallyn> pushed, will ping when done :)
[15:15] <Laney> also it might be easier in the long run to MIR source-highlighting, should be relatively innocuous
[15:18]  * hallyn goes to look at the code
[15:27] <Roj> hi have any why to run python code from glade web browser?
[15:28] <Roj> write code in html tag and can run with glade web browser
[15:34] <melodie_> bye, and thanks
[15:42] <Roj> hi have any why to run python code from glade web browser?
[15:47] <hallyn> cyphermox: Laney: fwiw libnl-3 built fine in ppa (https://launchpad.net/~serge-hallyn/+archive/virt)
[15:48] <hallyn> still going to look at the source-highlight source code (looked over its new bugs for starters)
[15:48] <Laney> cool
[15:48] <hallyn> but it seems i messed up cgroup-lite, so fixing that first :)
[15:49] <hallyn> general q - awk being in /usr/bin not /bin, i would assume that has come up before?  (for bootup for systems with separate /usr)
[15:50] <hallyn> i assume i should work around that, moving awk to /bin is not doable?
[15:50] <cjwatson> work around it - there should be enough other tools in /bin to make it workaebl
[15:50] <cjwatson> *wowrkable
[15:50] <cjwatson> oh bah, I give up
[15:50] <hallyn> :)
[15:50] <cjwatson> hate typing on systems under load
[15:51] <hallyn> yeah i don't mind working around it, just seems like there would be lots of boot scripts using awk...
[15:51] <hallyn> thanks
[15:51] <cjwatson> shouldn't be, they should all already have run into the same problem :)
[15:51] <cjwatson> not many things have to worry about being run before /usr is mounted
[15:52] <slangasek> also, becomes a non-issue once we implement foundations-q-usr-merge
[15:52] <cjwatson> exactly
[15:54] <hallyn> oh no, no 'logger' command either
[15:55] <slangasek> fwiw, moving awk to /bin is particularly knotty because it's an alternative provided by two separate packages
[15:55] <hallyn> and no tail
[15:55] <slangasek> so we shouldn't really do that
[15:55] <hallyn> slangasek: right, it didn't look pretty
[15:55] <hallyn> but, no tail?
[15:57] <slangasek> tail is not in the category of "things required in order to mount filesystems" :)
[15:57] <ogra_> for reading the end of the log after the mount failed !
[15:58] <hallyn> 'required', guess not.  i was just using it to skip the first line of /proc/cgroups
[15:58] <slangasek> where are you getting a log?  rsyslogd is on /usr :P
[15:58] <hallyn> i'll use the '#'
[15:58] <ogra_> heh
[15:58] <cjwatson> sed -n '2,$p'
[15:58] <cjwatson> hallyn: ^-
[15:59] <hallyn> leading '#' might actually be more reliable.  will think on it
[16:00] <dobey> how does one run "make check" in override_dh_auto_test when using cmake?
[16:01] <dobey> it seems to do the cmake in a subdir, and none of the env vars have that path in them :-/
[16:09] <debfx> dobey: doesn't dh_auto_test do that already?
[16:11] <dobey> debfx: well i would like to use a different make target than check
[16:12] <debfx> dobey: you could call dh_auto_build -- <TARGET>
[16:16] <dobey> debfx: thanks
[16:40] <hallyn> gah.  i left logger still.  though only in failure paths.  is there a good replacement for 'logger' for during early boot (pre-/sys) ?
[16:40] <seb128> @pilot out
[16:47] <SpamapS> hallyn: upstart?
[16:50] <stgraber> hallyn: just going with echo should be good enough, the output will go to /var/log/upstart/cgroup-lite.log
[16:50] <hallyn> SpamapS: going by the cookbook, it seems i'd jsut be writing to /dev/kmsg
[16:50] <hallyn> stgraber: oh, so maybe is hould do that in all cases even if logger is available?
[16:50] <hallyn> is that pretty new?
[16:51] <stgraber> yeah, I don't see any specific reason to write to syslog when we have per-job logs now
[16:51] <stgraber> was introduced in 12.04
[16:51] <stgraber> before that job output would just be lost
[16:51] <hallyn> stgraber: no wait.  is that only in the upstart job itself, or also for scripts called by the upstart job?
[16:51]  * hallyn tests
[16:52] <stgraber> any output to stdout/stderr cause by the job should end up there (including anything that it spawns)
[16:52] <stgraber> *caused
[16:53] <hallyn> not seeing a /var/log/upstart
[16:53] <vibhav> I was having a look at http://packages.debian.org/changelogs/pool/main/g/gksu-polkit/gksu-polkit_0.0.3-1/changelog#version0.0.2-2
[16:54] <hallyn> oh i still need console output then
[16:54] <vibhav> and noticed https://merges.ubuntu.com/g/gksu-polkit/gksu-polkit_0.0.2-2.1ubuntu1.patch doesnt have gksu-polkit (0.0.2-2.1) unstable; urgency=low , Am I missing something?
[16:54] <hallyn> no, no help
[16:54] <vibhav> Actually, the debian/changelog doesnt have gksu-polkit (0.0.2-2.1) unstable; urgency=low
[16:54] <stgraber> hallyn: that's weird... you should definitely have /var/log/upstart (a directory) on your system and /var/log/upstart/<job>.log for any job that outputs something
[16:54] <stgraber> hallyn: unless for some reason your system booted with --no-log
[16:55] <hallyn> proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-3.5.0-2-generic root=LABEL=cloudimg-rootfs ro console=ttyS0
[16:55] <stgraber> hmm, you really should have /var/log/upstart/ then :)
[16:56] <hallyn> lemme mkdir it
[16:56] <hallyn> still no file in there
[16:56] <stgraber> try "sudo initctl notify-disk-writeable"
[16:56] <hallyn> i do see my precise host has it
[16:56] <ogra_> infinity, any idea what we can do about the flash-kernel unmount thing ? thats a longstanding bug we had in the old version and something i even ran into with rootstock at times
[16:57] <hallyn> stgraber: still no /var/log/upstart/*
[16:57] <hallyn> stgraber: but, i guess i'll assume that is a configuration bug, or an upstart bug in quantal - the point remains i should have 'console output' in the cgroup-lite.conf, and use 'echo' ?
[16:57] <stgraber> jodh: ^ (hallyn doesn't have /var/log/upstart on his system even though he didn't boot with --no-log)
[16:58] <ahasenack> smoser: hi, just so you know, https://bugs.launchpad.net/cloud-init/+bug/897688 backfired
[16:58] <vibhav> Also, what is the dh_python2 equivalent of XS-Python-Version = all?
[16:58] <ahasenack> smoser: dpb has one of those stupid ISPs with wildcard domains
[16:58] <stgraber> hallyn: you shouldn't need "console output" as logging is the default for any version of upstart that supports it
[16:58] <ahasenack> smoser: that respond to foo.bar.stupid.domain.my.isp with a valid ip showing some standard "domain not found" html page
[16:58] <hallyn> stgraber: excellent
[16:58] <stgraber> hallyn: so just moving from these logger calls to echo should do the trick
[16:58] <ahasenack> smoser: and the machines he fired up with cloud-init ended up pointing at ubuntu-mirror.localdomain, which didn't work, of course
[16:58] <hallyn> so i'll just switch to echo and call it good.  thanks
[16:59] <infinity> ogra_: It's recurred in 3.0?  Cause I thought we had is nailed in precise.
[16:59] <infinity> ogra_: /is/it/
[17:00] <ogra_> infinity, well, you were the last person editing bug 1014139
[17:00] <ogra_> :)
[17:01] <infinity> ogra_: Oh, I was just reassigning some initramfs-tools bugs, but yeah, that's clearly with 3.0
[17:02] <infinity> ogra_: I guess we need to look at what we mangled in 2.x and forward-port the violence.
[17:02] <ogra_> i also saw the issue here personally when upgrading my ac100
[17:03] <infinity> xnox: Hey!
[17:03] <ogra_> haha
[17:04] <ogra_> we have a filesystem specialist now, i always forget :)
[17:04] <xnox> infinity: hello!
[17:04]  * xnox was offline for an hour due to xchat crash
[17:04] <infinity> xnox: Has anybody yelled at you about your mongodb and qpid-cpp uploads yet?
[17:04] <xnox> infinity: ogra_: what did I miss? =)
[17:04] <xnox> infinity: micahg did =)
[17:04] <ogra_> infinity, i think we used a sledgehammer like umount -l back in 2.0
[17:04] <ogra_> or something similarily bad
[17:05] <infinity> xnox: Can you revert the disabling of armhf on the former?
[17:05] <infinity> xnox: As for the qpid-cpp one, did you disable the entire testsuite (as the changelog suggests), or just some network tests?
[17:05] <xnox> infinity: yes, that's what micahg told me to do. And you mean reverting disable of *armel* right?
[17:05] <infinity> xnox: Err, armel, not armhf.  Whatever.
[17:06] <infinity> xnox: I removed the problematic binaries for you for now.  Keep in mind that disabling building on an arch doesn't actually remove binaries anyway, so wouldn't have done what you wanted regardless.
[17:06] <xnox> infinity: qpid-cpp I think i disabled it out-right =) but now that we have a boost1.49 binary, i can re-enable all of it back :P
[17:06] <ogra_> xnox, heh, sorry, i thought infinity's ping was related to the mount issue we have in flash-kernel :)
[17:06] <infinity> ogra_: Nothing all that bad about lazy umounts.
[17:07] <ogra_> apart from the fact that the "physical" mount might still be there ?
[17:07] <xnox> ogra_: well I have a panda in a box, but haven't booted it yet.
[17:07] <ogra_> -l only updates mtab, no ?
[17:07]  * xnox has nothing against pandas or animals in general BTW
[17:07] <ogra_> just make sure you have enough bamboo in your storage :)
[17:07] <infinity> flash-kernel (2.28ubuntu34) oneiric; urgency=low
[17:07] <infinity>   * Avoid races between umount and rm of the mountpoint with umount -l
[17:08] <infinity> That seems to be the last thing the changelog has to say about it.
[17:08] <ogra_> yeah, that sounds like the "fix"
[17:08] <infinity> ogra_: No, it does more than update mtab.  It detaches the filesystem, and cleans up once it's no longer busy.
[17:08] <ogra_> i still dont like to hide a race behind a lazy unmount
[17:09] <ogra_> but i invested plenty of time to track down the race in the past and failed
[17:09] <ogra_> evcen if you run lsof in the script, the open files are gone already
[17:11] <gema> ogra_: http://www.weather.com/weather/videos/news-41/top-stories-169/108-tai-chi-pandas-in-the-rain-29461
[17:11] <infinity> ogra_: Yeah, looks like exactly the same race, just relocated to a different spot in the code.
[17:11] <ogra_> right
[17:12] <infinity> ogra_: -l should fix it.  You could also try to forceful syncs, but I don't see the point.  This is exactly what -l is for.
[17:12] <ogra_> ok
[17:12] <ogra_> well, i would like to know whats going on, this bothers me
[17:12] <ogra_> gema, LOL
[17:13] <vibhav> if XS-Python-Version=all , Then can I set X-Python-Version=$smallest_python_version_number ?
[17:13] <infinity> ogra_: It'll bother you less if -l fixes it and you never see another bug report. ;)
[17:14] <ogra_> heh, i still *know* its there
[17:14] <infinity> (It certainly stopped bugging me after we fixed it in oneiric)
[17:14] <ogra_> its like that stripe of duct tape holding your engine in place in the car ...
[17:14] <jtaylor> vibhav: just drop it in that case
[17:14] <ogra_> it might still work but its an ugly solution
[17:14] <ogra_> and you know its there under the hood
[17:15] <infinity> ogra_: Meh.  It worked in oneiric/precise, and no one complained, so I declare that it *is* the right solution. :)
[17:15] <vibhav> jtaylor: Remove XS-Python-Version ?
[17:15] <ogra_> heh, ok
[17:15] <vibhav> Without using x-p-v?
[17:15] <infinity> ogra_: Mostly because I don't want to try to hunt down all the things that might, potentially, be keeping that mountpoint open for a brief period.
[17:15] <jtaylor> vibhav: yes, assuming your converting something to dh_py2
[17:15] <vibhav> jtaylor: yeah, thanks
[17:16] <ogra_> infinity, yes, and several people tried that in the past
[17:16] <infinity> ogra_: In all seriousness, anything that might be keeping a file open there will be a child of flash-kernel, so the lazy umount will complete and clean up as soon as f-k is done, which is close enough to what we want anyway.
[17:37] <nemo> Hm... Is this just my system, or is 12.04 a bit broken in package deps?
[17:37] <nemo>  trac-wikiprint : Depends: python-pil but it is not installable
[17:37] <nemo> E: Package 'python-pil' has no installation candidate
[17:41] <jtaylor> nemo: bug 982669
[17:42] <jtaylor> looks like a simple fix
[17:46] <nemo> jtaylor: maybe, but sure doesn't seem like it was made :-p
[17:47] <nemo> oh well. looks like I need to do my own source build it seems
[17:48] <jtaylor> I'll fix it
[17:59] <jtaylor> hm looks like a bug in dh_python2, nice ...
[18:00] <ScottK> How so?
[18:00] <jtaylor> it considers python-pil a valid dependency even though it has no installation candidate
[18:00] <jtaylor> in debian the package does not exist anymore so it is not affected
[18:00] <jtaylor> in ubuntu it only "exists" due to those two depending on it
[18:01] <ScottK> Does it think that because it's in requires.txt?
[18:01] <jtaylor> yes, it guesses it to python-pil
[18:01] <jtaylor> which it only does if python-pil exists
[18:01] <jtaylor> actually its a but more strange it should only accept the guess if its installed
[18:02] <jtaylor> how does it consider it a valid guess
[18:02] <ScottK> IDK and POX is mostly offline at Debconf.
[18:06] <jtaylor> :( dig through the source then
[18:07] <hallyn> Laney: cyphermox: i just dunno.  debian bug 657254 does say that libnl3 was FTBFS with asciidoc and without syntax-highlight.  it builds fine in ppa without.  But MIRing syntax-highlight is a bit daunting bc it depends on boost-defaults
[18:08] <Laney> is that bad?
[18:08] <Laney> and I was thinking of another bug I had yesterday with the internets thing
[18:09] <jtaylor> hm dh_python2 does not validate its guesses at all
[18:09] <hallyn> is which bad?  needing to MIR boost?  it's a huge chunk of c++ templates near as i can tell...
[18:09] <jtaylor> how can that be
[18:09] <Laney> boost-defaults. it's already in main
[18:12] <hallyn> Laney: yeah, i'm mixing up my packages - meant libboost-regex-dev
[18:12] <hallyn> hm
[18:12] <hallyn> so it'll be promoted as soon as something in main uses it, bc its source pkg is in main?
[18:13] <cjwatson> yeah, moving binaries to main doesn't need paperwork
[18:13] <Laney> not sure what the main situation is with boost-defaults
[18:13] <cjwatson> boost-defaults source is in main
[18:13] <Laney> I see that package has never been in main
[18:13] <cjwatson> uh
[18:13] <cjwatson> boost-defaults |   1.49.0.1 |       quantal | source
[18:13] <Laney> the binary
[18:13] <cjwatson> oh, right.  but in any case MIRs are per source package ...
[18:13] <hallyn> right
[18:13] <Laney> so nothing in main has ever BDed on that. mildly curious, but doesn't matter
[18:13] <hallyn> point being, i was worryin gover nothing - thanks :)
[18:13] <ScottK> And boost-defaults isn't the right source.
[18:14] <ScottK> Or it's not the only one.
[18:14] <hallyn> eh?
[18:14] <Laney> for libboost-regex-dev?
[18:14] <jtaylor> ok, debian is affected it just got build with a dh_python2 version that does not have this "feature"
[18:14] <jtaylor> time to file 2 rc bugs
[18:14] <jtaylor> maybe 3, this behavior is very weird
[18:15] <ScottK> hallyn: nevermind.  libboost-regex1.49-dev is already in Main.
[18:15] <Laney> haha
[18:15] <Laney> good old boost.
[18:16] <ScottK> It's OK.  xnox is in charge of boost now.
[18:16] <hallyn> ok - i think i'll file MIR for syntax-highlighting then
[18:16] <hallyn> (just looking through some of the .c files first for sanity)
[18:17] <Laney> it should be easier as it's only a BD, not something users will get installed for them
[18:17] <ScottK> jtaylor: Which package are we on?
[18:17] <jtaylor> ScottK: trac-wikiprint, trac-odtexport
[18:18] <hallyn> Laney: and especially as there should be no setuid-root programs or daemons :)
[18:18] <hallyn> of course there are comments like "Currently this looks like a security hole"
[18:19] <Laney> heh.
[18:28] <cjwatson> stgraber: ust> thanks - maybe you could syncpackage it if you've checked Ubuntu diffs?  I feel less comfortable auto-syncing things when they're at all complex
[18:31] <stgraber> cjwatson: I'll have a quick look, and run syncpackage. I believe jbernard used the upstream lttng packaging so it should be identical to what we have currently (except for the source name)
[18:34] <stgraber> cjwatson: diff looks good. Only problem I see is that we won't have armel and armhf binaries but I'll change that after the sync
[18:35] <stgraber> jbernard: what's the reason for not going with arch any for these? IIRC lttng-ust builds just fine on armel and armhf and I didn't see any problem with it when I smoke tested on my pandaboard
[18:37] <barry> jdstrand: apparmor py3 uploaded?
[18:40] <jdstrand> barry: you bet. I was going to ask infinity to bin deNEW it since we added python3-libapparmor
[18:40] <barry> jdstrand: awesome
[18:40] <barry> thanks!
[18:40] <jdstrand> (I'd do it, but I uploaded it, so I can't)
[18:42] <jdstrand> infinity: hey, when you get a chance, can you deNEW apparmor? python3-libapparmor was added (and it should go to main)
[18:42] <jdstrand> looks like they all build
[18:42] <jdstrand> built
[18:47] <infinity> jdstrand: Done.
[18:47] <jdstrand> infinity: thanks! :)
[19:08] <cnd> infinity: I have a package rename, and I need to transition rdepends on to the new package as soon as possible
[19:09] <cnd> I've uploaded the new package "evemu", would you be able to review and approve it for me?
[19:10] <ScottK> cnd: Does it have a transitional package with the old name that depends on the new one?
[19:11] <infinity> cnd: ^
[19:11] <infinity> cnd: That may matter for LTS->LTS upgrades... Unless it's just a library.
[19:12] <infinity> Oh, and it kinda is.
[19:12] <infinity> Except for the python bindings.
[19:12] <highvoltage> xnox: btw, we're traveling from miami to managua at the same time. so this is just to let you know that I've marked you as my designated travel buddy.
[19:12] <xnox> highvoltage: ok. Who are you? =))))
[19:13] <Laney> The One and Only High Voltage
[19:13] <xnox> xnox: found you on pad.lv
[19:14] <highvoltage> Laney said it. well we met at UDS but at least I remember you and should be able to identify you in a crowd :)
[19:15] <xnox> highvoltage: Hmmm. Now I remember you! =)
[19:15] <xnox> get excited and make things =)
[19:15] <highvoltage> :D
[19:15] <xnox> highvoltage: ok, I have now mapped you in person from UDS to the irc nickname =)
[19:16] <xnox> canada, eh?! =)
[19:16] <highvoltage> xnox: oui
[20:15]  * Laney paws at stgraber 
[20:15] <Laney> have you seen stuff like http://paste.debian.net/177883/ before?
[20:15] <Laney> lxc got itself into a bad way somehow
[20:16] <stgraber> Laney: haven't seen that one yet, no. What kernel are you using?
[20:17] <Laney> Linux iota 3.5.0-2-generic #2-Ubuntu SMP Tue Jun 26 14:11:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[20:20] <stgraber> Laney: anything special you had to do to trigger that?
[20:21] <Laney> I'm not sure how I triggered it
[20:21] <Laney> I had a container up today, stopped it, suspended & unsuspended a few times, tried to start it again now and it didn't come up, and then saw this in dmesg
[20:22] <stgraber> it's definitely a kernel bug and looks like a bug somewhere in the network namespace code (based on that refcount entry for the loopback device)
[20:22] <stgraber> hallyn: ^
[20:23] <Laney> i'm being spammed by that message now :)
[20:23] <stgraber> Laney: ubuntu-bug linux
[20:23] <Laney> aye aye
[20:23]  * hallyn reads up
[20:24] <hallyn> oh sigh
[20:24] <Laney> "This is not an official Ubuntu package."
[20:24] <Laney> erm.
[20:25] <hallyn> cyphermox: filed the MIR for source-highlight, fwiw
[20:25] <cyphermox> cool, thanks!
[20:25] <hallyn> Laney: hm, try linux-image-generic?  else ask on #ubuntu-kernel
[20:26] <hallyn> i'm checking the git tree to see what has changed recently
[20:26] <Laney> yeah that worked, thanks
[20:28] <hallyn> Laney: wait, do you have cgroup-bin installed?
[20:29] <Laney> nope
[20:29] <hallyn> ok :)
[20:29] <Laney> I do have cgroup-lite, if that means anything
[20:29] <hallyn> you seem to actually be hung on a mutex, so i was wondering if a task might have been kept frozen after suspend
[20:29] <hallyn> yeah, it measn your good wrt that
[20:33] <Laney> bug #1021471
[20:33] <Laney> help me think of a better title :P
[20:33] <hallyn> 'stuck on mutex_lock creating a new network namespace when starting a container'
[20:34] <hallyn> Laney: thanks i was just going to ask you the # :)
[20:34] <hallyn> odd i don't see any changes in net/core/net_namespace.c that woudl cause this
[20:35] <hallyn> [26205.684141] unregister_netdevice: waiting for lo to become free. Usage count = 1   doh
[20:36] <hallyn> that rings an atonal bell
[20:38] <hallyn> feh, gotta be a buggy net driver
[20:38] <Laney> :)
[20:39] <hallyn> i'll wait and see if kernel team has an obvious idea, and if not by tomorrow take a closer look
[20:39] <Laney> i'm going to have to reboot, so i'll lose the broken state until and if it recurs
[20:40] <hallyn> Laney: if it's not too late, can you first do an lsmod?
[20:40] <hallyn> just wondering if you have any "special" network drivers
[20:40] <Laney> yep
[20:40] <Laney> apport didn't do that?
[20:40] <hallyn> actually that should be in your log info alraeady
[20:40] <hallyn> yeah should have, nm, boot away :)
[20:40] <hallyn> thanks
[20:41] <Laney> did it anyway just in case: http://paste.debian.net/177888/
[20:41] <Laney> brb
[20:48] <BenC> When will things in quantal-proposed be moved to main (IOW, when will the buildd's pick up on it)?
[20:48] <BenC> Mainly, there are two build failures in quantal universe that will be fixed with the latest build of thunderbird that is in proposed
[20:49] <BenC> …on powerpc
[20:49] <infinity> BenC: How do the buildds relate?
[20:50] <BenC> infinity: the rebuild I asked for on enigmail didn't make use of thunderbird 14, it still pulled in 11.0
[20:50] <infinity> BenC: If you just mean "when will stuff get copied to the release pocket?", it's waiting on the e-d-s transition in -proposed to be complete.
[20:50] <infinity> BenC: You should have uploaded that to proposed, if you wanted it to build against proposed. :P
[20:50] <infinity> BenC: Oh, it's just a retry.
[20:50] <infinity> In that case, yeah, just wait.
[20:50] <BenC> right
[20:51] <infinity> Tbird is caught in a transition, it'll be out soonish.
[20:51] <BenC> Ok, thanks
[20:51] <infinity> But thanks for the subtle reminder that I should fix armel at some point, now that you fixed PPC to make me look bad.
[20:55] <BenC> My job is done then
[20:56] <infinity> BenC: :P
[20:56] <infinity> BenC: When the ARM hardware in my house gets faster than my PPC hardware, watch out.
[20:56] <BenC> My actual objective is to indirectly fix arm by making it inferior to an all but forgotten architecture :)
[20:57] <tedg> slangasek, So I'm a bit confused about bootloaders :-)  For x86 on non-Secure Boot systems are we using GRUB2 ?
[20:57] <slangasek> tedg: yes
[20:57] <infinity> BenC: Heh.  Well, I'm sure you're indirectly fixing ARM here and there by fixing generic build failures, and the odd char-signedness issue.
[20:57] <tedg> slangasek, And then for x86 secure boot systems it's efiboot
[20:57] <slangasek> tedg: efilinux
[20:58] <tedg> Ah, yes.  Sorry.
[20:58] <BenC> infinity: I actually thought that the two fixes I dropped for tbird would fix armel, but I never looked at the problem in the log
[20:58] <tedg> slangasek, And then ARM is uboot no matter if it's crazy MS thing or not?
[20:58] <slangasek> tedg: if it's crazy MS thing, we don't get to boot on it anyway on ARM ;)
[20:59] <BenC> Unpacking libschroedinger-1.0-0:powerpc (from .../libschroedinger-1.0-0_1.0.11-2_powerpc.deb) ...
[20:59] <tedg> Heh, great.  Reduces the amount of work for me!  ;-)
[20:59] <BenC> I'm certain I'm in unfamiliar territory now...
[20:59] <infinity> BenC: No, the armel build is very ARM specific, it's that it's building some bits for v7 when it shouldn't.
[20:59] <infinity> BenC: I just need to find some "free time" to hunt those down and purge them with fire.
[21:00] <BenC> infinity: Ah, free time…the days of my youth
[21:00] <tedg> slangasek, So is it possible that a system would have both efilinux and grub installed but only be using one of them, or would they conflict?
[21:00] <tedg> slangasek, Like at the packaging level.
[21:00] <infinity> BenC: Oh, speaking of porting issues and targetting the wrong CPUs...
[21:01] <infinity> BenC: I know you don't directly care, since your product is based on a Freescale CPU that, I assume, has Altivec, but when you're doing PPC fixes here and there, can you look out for things enabling Altivec by default and disable that? :P
[21:01] <infinity> BenC: (Of course, if it's runtime selection, that's perfectly cool, just not build-time)
[21:01] <BenC> Actually, I've run into that already, and this particular CPU doesn't have altivec
[21:01] <infinity> BenC: Oh, snazzy.  Then you're on my side.  Good.
[21:01] <hallyn> infinity: does that mean you know where to look for the tbird and ffox armel FTBFS?
[21:01] <slangasek> tedg: they would not conflict at the packaging level...the actual in-use bootloader gets written to a special EFI boot partition
[21:02] <infinity> hallyn: Yeah, I know vaguely what's wrong, I just haven't had the time to fix it.
[21:02] <BenC> So I'm killing them softly, as if they were -msse or similarly stupid things to have on ppc
[21:02] <infinity> BenC: Excellent.  If things can do runtime selection, obviously, that's awesome, but yes, thanks for killing the compile-time stupidity as you spot it.
[21:02] <hallyn> infinity: rockin', cause i didn't know how to tell if the code was wrong, or the toolchain flags (specified processor)
[21:02] <tedg> slangasek, So, how do I know which bootloader was used to boot the system?
[21:03] <infinity> hallyn: It's a twisty maze of configure breakage, nothing specifically wrong with the code.
[21:04] <slangasek> tedg: that's a good question
[21:04] <slangasek> tedg: but I'm not sure it's actually the right question :-)
[21:04] <slangasek> tedg: what is it you really want to know?
[21:05] <tedg> slangasek, Well, two things.  How do I determine if I want to change the boot parameters which one I should change?
[21:05] <slangasek> tedg: right - so I would say they *both* need to be changed
[21:05] <hallyn> jinkeys, libcommons-compress-java wants a non-existing package ( libxz-java )
[21:05] <tedg> slangasek, Then the other would be, how do I check to see if the last boot was successful.
[21:05] <tedg> slangasek, i.e. fail, then fallback, I want to report the fail.
[21:06] <tedg> slangasek, But, if I change both and call the "install" routine for both wouldn't that install each of them in order into the magic EFI partition?
[21:06] <slangasek> tedg: ah - so actually, we're going to have a shim bootloader in front of all of this
[21:07] <slangasek> tedg: and *that* is the one installed to the magic EFI boot path
[21:07] <slangasek> tedg: and it will be <handwavy> able to detect whether SB is enabled, and select the correct bootloader based on this
[21:07] <tedg> slangasek, That's only in the Secure Boot situation, right?
[21:07] <slangasek> well
[21:07] <slangasek> how do you know a machine is in the Secure Boot situation or not?
[21:07] <tedg> Could efilinux and grub be installed in the non-SB situation?
[21:08] <tedg> I don't, I'm hoping you'll tell me ;-)
[21:08] <slangasek> you only know two things: 1) the machine we're installing on does or does not claim to implement Secure Boot in firmware, 2) Secure Boot is currently enabled
[21:08] <slangasek> do you want the machine to stop booting on a firmware upgrade?
[21:08] <slangasek> or when the user toggles the setting?
[21:08] <slangasek> if not, we need to start installing the whole kit'n'kaboodle whenever we're doing EFI
[21:09] <tedg> So I guess I need to know whether we're BIOS or EFI then?
[21:10] <tedg> Could a non-EFI system have efilinux installed?
[21:10] <tedg> Seems like they could...
[21:10]  * tedg is thinking bad things would happen...
[21:11] <hallyn> is there a way to tell who sync'd a particular package?
[21:11] <hallyn> don't see that info in the publish history
[21:12] <Laney> quantal-changes / api
[21:13] <Daviey> hallyn: Wanna write,  lp-sync-blame-and-finger-point-perhaps-berate ?
[21:13] <hallyn> trying to tell whether whoever syncd libcommons-compress-java was planning to sync and MIR libxz-java (which it now depends on)
[21:14] <Daviey> hallyn: Mr Page.
[21:19] <hallyn> ah thanks
[21:19] <hallyn> jamespage: are you working on sync request for libxz-java ?
[21:19] <jamespage> hallyn, nope - want me to?
[21:20] <hallyn> jamespage: libcommons-compress-java is currently waiting for it.  but that measn it'l lbe waiting until it's both sync'd and MIRd.
[21:20] <jamespage> hallyn, marvellous
[21:21] <hallyn> jamespage: so i dont know if libcommons-compress-java should be / can be built without it
[21:21] <hallyn> jamespage: but if possible, yes please :)
[21:21] <hallyn> eh, i personally prefer to try and build without it, but that sounds anti-java and probably impossible
[21:23]  * ScottK finds nothing against being anti-Java in the CoC.
[21:23] <hallyn> oh hey, look at that.  libgweather-3-dev is sitting in quantal-proposed
[21:23] <hallyn> i apparently need to read up, i thought q-proposed would mainly be used during freezes?
[21:24] <hallyn> ScottK: i just meant that i wasn't sure you could disable parts of a java package like that (as with configure flags during a regular build)
[21:25] <ScottK> Well, being anti-Java myself, I was just being careful to make sure we weren't starting to establish a precedent that being anti-java was somehow 'bad'.
[21:26] <hallyn> heh
[21:27] <hallyn> i don't admit to being anti-java, but am eccstatic jamespage is willing to look at it :)
[21:27] <stgraber> hallyn: -proposed is also used for transitions to prevent skew (currently the case for the eds transition)
[21:28] <hallyn> stgraber: in the case of libgweather vs evolution that sems to have failed :)
[21:28] <infinity> hallyn: sync request for libxz-java?
[21:28] <infinity> hallyn: Wouldn't it need to exist somewhere to sync it?
[21:28] <hallyn> infinity: it's in sid
[21:28] <infinity> Not by that name...
[21:28] <hallyn>  libxz-java | 1.0-1 | sid | all
[21:28] <infinity> Oh, that's built from xz-java.
[21:28] <infinity> Which is in Ubuntu.
[21:29] <hallyn> d'oh
[21:29] <infinity> (base)adconrad@cthulhu:~$ rmadison -S xz-java
[21:29] <infinity> libxz-java |      1.0-1 | quantal/universe | all
[21:29] <infinity> libxz-java-doc |      1.0-1 | quantal/universe | all
[21:29] <infinity>    xz-java |      1.0-1 | quantal/universe | source
[21:29] <jamespage> hallyn, so its just that it eithe needs an MIR or we need to disable it
[21:31] <hallyn> jamespage: yup
[21:33] <hallyn> robert_ancell: hi - i notice libgweather is in quantal-proposed.  is that just while awaiting some testing?
[21:33] <hallyn> (evolution's build is hung waiting for that version)
[21:33] <robert_ancell> hallyn, no, it just needs the archive admins to release it to quantal
[21:34] <hallyn> robert_ancell: cool, thanks
[21:34] <robert_ancell> infinity, who clears out quantal-proposed?
[21:36] <infinity> robert_ancell: Me, if your transition is done.
[21:36] <Laney> hm
[21:36] <Laney> why didn't the depwait get cleared by the quantal libgweather3-dev?
[21:36] <Laney> quantal-proposed*
[21:37] <infinity> It only got published recently, people might be impatient.
[21:37] <Laney> I guess I don't know how long whatever spells makes that happen are cast
[21:38] <infinity> Laney: They happen post-publishing, so there's a bit of an irritating delay.
[21:38] <hallyn> infinity: i'm pretty sure the FTBFS list i'm looking at is from this morning...  i'm afraide i have no concept how long one should normally wait
[21:38] <hallyn> don't mean to be a pest
[21:38] <infinity> Laney: dep-wait mangling is another thing on the long list of "could be done a lot better".
[21:38] <infinity> hallyn: I only let gweather through NEW a little while ago.
[21:38] <Laney> As long as it's not a bug with using proposed, I'm willing to not care
[21:39] <infinity> It *shoudln't* be a problem with pockets, since I'm pretty sure we've hit dep-waits that DTRT in security before.
[21:39] <infinity> But I kinda want to wait a bit and make sure now. :P
[21:39] <infinity> Oh, yeah, it's working.
[21:39] <infinity> You can tell from the other awesome LP bug.
[21:40] <infinity> (Trying to give-back a package that's dep-wait on something currently in the locked/being-cleared set causes a UI timeout instead of an error)
[21:40] <hallyn> yay, cjwatson has requested jbigkit MIR so i don't haveta
[22:35] <infinity> robert_ancell: So, to confirm, e-d-s-in-proposed is all done?
[22:39] <infinity> robert_ancell: gnome-panel being universally FTBFS could be an issue.
[22:39] <robert_ancell> infinity, I uploaded an e-d-s with a fix
[22:40] <robert_ancell> (it was a dependency missing on a -dev file)
[22:40] <robert_ancell> just waiting for publishing before rebuilding gnome-panel
[22:40] <infinity> robert_ancell: Check, I see that.
[22:40] <infinity> robert_ancell: So, it's safe to say that when gnome-panel's done, you're good to go?
[22:40] <infinity> (Well, gnome-panel, and evo...
[22:40] <infinity> )
[22:40] <robert_ancell> yup
[22:40] <robert_ancell> yeah, once all the gears have cranked
[22:42] <infinity> Alright.  When it's all built and published, I won't ask again, then, I'll just do.
[22:43] <robert_ancell> infinity, what is the criteria for moving from -proposed?  Just all the dependencies have built successfully?
[22:45] <infinity> robert_ancell: Normally, the criteria would be "it won't make anything in the release pocket break".
[22:45] <infinity> robert_ancell: Well, and "all arches have built".
[22:45] <infinity> robert_ancell: Thunderbird/armel gets a pass on that, since it's also not built in release.
[22:59] <cyphermox> infinity: I rather perhaps waiting a bit more
[22:59] <infinity> cyphermox: ?
[22:59] <cyphermox> libreoffice should theoretically also be rebuilt; I want to check on it
[23:00] <cyphermox> there's still going to be a few more packages that will need fixing after too
[23:00] <infinity> libreoffice is already 17 transitions behind, I'm not sure it matters here.
[23:00] <cyphermox> fair enough
[23:00] <infinity> Well, unless moving these packages makes libreoffice uninstallable.
[23:00] <infinity> If it does, then we have to wait.
[23:01] <ceti331> hi
[23:01] <cyphermox> let me finish up nautilus-sendto then
[23:02] <ceti331> Greetings, i'm trying to compile compiz\plugins\expo ; link error "cannot find -lcomposite" "cannot find -lopengl".
[23:02] <ceti331> any idea what i've missed ?
[23:02] <infinity> ceti331: apt-get build-dep compiz
[23:02] <ceti331> ok
[23:02] <ceti331> sudo apt-get build-dep compiz
[23:02] <ceti331> oops
[23:03] <ceti331> ok thats installing tonnes
[23:03] <cyphermox> infinity: libreoffice-evolution has no reverse-depends, it's probably fine
[23:04] <infinity> cyphermox: rdeps aren't the issue, it's if it becomes uninstallable itself.
[23:04] <infinity> Which it currently isn't, despite depending on NBS stuff.
[23:04] <cyphermox> well, libreoffice-evolution does have a versioned depends on libreoffice-core, so it would
[23:04]  * xnox did libreoofice-evolution ever worked?!
[23:04] <infinity> So, I don't see that changing.
[23:05] <infinity> cyphermox: Erm, I'm not sure I see how that would matter.
[23:05] <cyphermox> but I suspect very few people have libreoffice-evolution installed, since it isn't depended on by anything
[23:05] <infinity> cyphermox: I don't follow your logic.  Yes, all of libreoffice has versioned deps to the rest, so...?
[23:06] <cyphermox> so I'm getting mixed up in logic
[23:06] <cyphermox> l-evolution depends on libebook-1.2-12; that's what is going to be a problem
[23:06] <infinity> Sure, but libebook-1.2-12 is already NBS, isn't it?
[23:06] <cyphermox> I see that now
[23:07] <infinity> Yeah, it is.
[23:07] <infinity> So, as long as the new e-d-s libs don't conflict with the old ones, we're fine.
[23:07] <ceti331> Ok. still same problem. it installed a lot of new stuff; i did cmake in a new plugin build directory
[23:07] <cyphermox> infinity: libreoffice-evolution is already not installable.
[23:07] <infinity> ceti331: You might want to check the topic.  This isn't really the right channel for this.
[23:08] <infinity> cyphermox: That's patently untrue.
[23:08] <cyphermox> infinity: I certainly can't install it now
[23:09] <ceti331> whats the best channel
[23:09] <cyphermox> well, not without breaking a lot of things
[23:09] <infinity> apt-get install libebook-1.2-12 libreoffice-evolution <-- Works here.
[23:10] <cyphermox> infinity: it wants to remove evolution-data-server libfolks-eds25 here
[23:11] <infinity> Oh, because e-d-s breaks libebook-1.2-12.  Argh.
[23:11] <infinity> A) Britney appears not to check for that.
[23:11] <infinity> B) WHY DOES IT DO THAT?!
[23:11] <infinity> (The breaks, I mean)
[23:11] <cyphermox> yeah
[23:11] <infinity> I guess because the library depends on the server version.
[23:12] <infinity> Silly design.
[23:12] <infinity> So, yeah.  You're right.  libreoffice-evo is just busted anyway.
[23:12] <cyphermox> that particular thing didn't change in this transition though
[23:12] <infinity> So, we won't make it worse.
[23:12] <infinity> Sweetshark: Seriously, are we going to see a new LibreOffice soon?  It's falling woefully behind in several library transitions.
[23:15] <cyphermox> infinity: my guess is at least for libreoffice-evolution, if upstream hasn't done the porting yet (and I suspect they didn't), it's going to need a substancial amount of work
[23:15] <infinity> cyphermox: Has the API for libe* changed that drastically?
[23:15] <cyphermox> enough to be painful
[23:16] <cyphermox> enough that I spent four hours porting indicator-datetime with varying amounts of success, and gave up on evolution-exchange
[23:16] <infinity> Fun.
[23:17] <infinity> Stick apw on it.  He was a wizard with the libpoppler porting effort. ;)
[23:18] <cyphermox> evolution-exchange will get fixed by upstream, if it hasn't been already since yesterday
[23:43] <ceti331> whats the right channel for asking about a compile problem
[23:48] <jbernard> stgraber: I had restricted urcu's arch to only those supported at the time, so I matched ust and ctl to match.
[23:48] <jbernard> stgraber: bug now that I look again, there's no reason to set to all
[23:48] <jbernard> stgraber: ill make that change change will my next upload
[23:48] <jbernard> stgraber: which should be within the next day or so
[23:49] <jbernard> stgraber: er, there's no reason to not set to all. sorry