[00:24] <SpamapS> cjwatson: I believe at this point the libmysqlclient transition is "complete" .. the only things left on the transition page are things that FTBFS for some other reason.
[00:24] <SpamapS> cjwatson: oh, and libreoffice. ;)
[00:32]  * micahg thought we wanted a libreoffice rebuild for alpha1
[00:48] <awsoonn> I'm writing a small game and wanted to make a proper makefile and .deb for it. I've already made a makefile and the debian directory, but how do I tell it where to install the binary files?
[00:59] <cjwatson> SpamapS: excellent
[00:59] <cjwatson> micahg: so did I, but I think it's too late now :-/
[01:00] <awsoonn> cjwatson: do you sleep? It seems that you're online every time I hop on IRC... :P
[01:00] <cjwatson> SpamapS: well done on sorting through the bulk of the build failure swamp
[01:00] <cjwatson> awsoonn: heh, a few people say that ... I'm just about to
[01:00] <awsoonn> good! :)
[01:01] <awsoonn> could you think of a good example package for me to look at to figure out how to build a .deb for homebrew game?
[01:02] <awsoonn> specificly I want to figure out how to make my makefile put the binaries in teh right spot to be included in the .deb
[01:03] <cjwatson> give it an install target, have the target honour DESTDIR
[01:04] <SpamapS> cjwatson: the swamp definitely had more ROUS's than I expected.. but the quicksand and fire traps weren't even a problem. ;)
[01:04] <cjwatson> so e.g. 'install -m0755 mygame $(DESTDIR)/usr/bin'
[01:05] <cjwatson> (using the autotools is better because it makes it easier for the packaging to override choices of directories etc., but that's more effort)
[01:05] <awsoonn> i dont mind effort if there is some glimmer of learning something usefull
[01:05] <cjwatson> (sorry, that wants 'install -d $(DESTDIR)/usr/bin' first)
[01:06] <cjwatson> in automake you'd just have 'bin_PROGRAMS = mygame' and then 'mygame_SOURCES = mygame.c' (say)
[01:07] <cjwatson> but for something simple it's not unreasonable to do it by hand, particularly as you'll get more reward more quickly :)
[01:07] <cjwatson> and if you already have a Makefile that does the building part, it's not much more
[01:07] <cjwatson> anyway, bed
[01:07] <awsoonn> ok, thx for the heads up, g'night!
[01:09] <Daviey> win 76
[03:55] <micahg> SpamapS: great work on the libmysqlclient transition
[03:57] <SpamapS> micahg: thanks.. I think there are still a few tiny dangling bits but they're all too big to be patching around.
[06:38] <pitti> Good morning
[07:26]  * SpamapS realizes a few universe packages were missed in the libmysqlclient sweep
[07:30] <infinity> SpamapS: No time like the present to fix 'em. ;)
[07:39] <SpamapS> yeah, thank god for submittodebian
[08:08] <dholbach> good morning
[08:50] <bambee> morning, for the kernel team:  http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc3-oneiric/  <--- there are missing packages inside this directory
[09:05] <apw> bambee, they arn't missing so much as unbuildable.  that release has compile issues on all architectures/flavours we build in mainline builds
[09:06] <bambee> oh, ok
[09:06] <apw> bambee, the fix for that is in linus' tree and so we expect the later dailies and releases to build again
[09:06] <apw> infinity, did those bootstrap builds work ok?
[09:07] <bambee> I just need a recent kernel for my sandy bridge (performance+stability), however I can wait, there's no hurry :) (the 3.2-rc2 works just fine)
[09:07] <infinity> apw: the DEB_STAGE trick worked fine to squeeze out a linux-libc-dev, a full build failed with kernel-wedge puking.
[09:08] <apw> infinity, got a log for that, is that kernel-wedge broken or our tree ?
[09:08] <infinity> apw: I have my hands full with other stuff right now, so failed to care deeply.
[09:08] <apw> fair enough
[09:08] <apw> as long as you have your bootstrap life is good
[09:09] <infinity> apw: Pretty much, yeah.  I don't really care about having an omap3 kernel right now. ;)
[09:09] <apw> infinity, i'll add it to my todo list for when we have a chroot
[09:09] <infinity> apw: We have chroots.
[09:09] <infinity> apw: It's building. :P
[09:09] <infinity> apw: Unless you mean on a porter box.
[09:09] <infinity> apw: I can probably convince lamont to set one up tomorrow.
[09:10] <apw> infinity, yeah somewhere i can play yes then i can debug it without interfering
[09:10]  * apw ^5s DEB_STAGE
[09:10] <infinity> Yeah, much love for the DEB_STAGE hack.
[09:10] <infinity> Whoever did that.
[09:10] <apw> it was done by linaro for the very same use
[09:11] <apw> in their case they are bootstrapping new vendor boards
[09:13] <pitti> Daviey: any chance we can get bug 857956 fixed in precise today? it got SRUed without uploading to precise, which is now both blocking promotion to -updates and also an alpha-1 targetted bug
[09:20] <Daviey> pitti: gah, yes - will be uploaded today.
[09:20] <Daviey> Thanks.
[09:21] <pitti> Daviey: thanks
[09:40] <Laney> ooh armhf builds
[09:43] <tumbleweed> am I correct in assuming that armhf and armel can chroot each-other without emulation?
[09:53] <Daviey> pitti: it is Fix Released in precise.
[09:53] <pitti> Daviey: yay you, moving to -updates
[09:54] <pitti> there it goes
[09:54] <Daviey> rocking :), thanks
[10:22] <apw> pitti, i see you looked at this installer EINVAL error thing.  the library that is reporting the EIO, what is that part of, i want to file a bug against it to get the damn filename out
[10:23] <pitti> apw: it's ubiquity
[10:23] <pitti> apw: incidentally, I'm just working on finding a simpler reproducer for it
[10:23] <apw> pitti, that is excellent yell if you do find one, /me is downloading an up to date iso to try and repro. it too
[10:24] <pitti> apw: yep, will do
[10:24] <pitti> apw: NB that it only seems to happen for i386 images on amd64
[10:24] <pitti> ... hosts
[10:24] <apw> yeah i see there is some correlation there
[10:25] <pitti> apw: logging the file name is easy, you just need to edit /usr/lib/ubiquity/ubiquity/install_misc.py
[10:25] <pitti> and at the top of def copy_file(), add something like
[10:25] <apw> pitti, yeah i guess it is easy, just mad that when the think throws up it doesn't report the failing filename
[10:25] <pitti> syslog.syslog('copying %s -> %s' % (sourcepath, targetpath))
[10:25] <apw> if it did we would already know if its random or the same file
[10:26] <apw> so for the next time, i want it to report the failing file
[10:26] <pitti> right, we could intercept IOError, log the file, and raise it again, that's better
[10:26] <apw> pitti, anyhow my plan without a simple reproducer is to confirm it, then try and downgrade the kernel in the ISO, confirm if its even kernel
[10:27] <pitti> apw: sounds good, we don't overlap then
[10:27] <pitti> it's currently expected that running precise ISO with the oneiric kernel will work, but that's to be proven
[10:28] <apw> pitti, yeah given we have new libc and new python (i believe) it really could be any of them
[10:28] <apw> EINVAL is common in libc too at least
[10:28] <pitti> apw: we already checked what man write(2) had to say about EINVAL, but it didn't ring a bell
[10:28]  * apw wonders if QA might still have the older isos.  when did this start occuring
[10:29] <apw> gema, you aware of the EINVAL issue in QA ?
[10:29] <pitti> jibel might remember
[10:30] <apw> i believe they do daily testing, so we should know which day it started
[10:35] <infinity> apw: https://launchpadlibrarian.net/86175847/buildlog_ubuntu-precise-armhf.iptables_1.4.12-1ubuntu2_FAILEDTOBUILD.txt.gz
[10:35] <infinity> apw: ^-- Is that an upstream kernel header oops?  I've seen it a couple of times now (and only with 3.2 headers).
[10:37] <apw> infinity, looking
[10:37] <infinity> apw: (Completely reproducible on x86, not an ARM thing)
[10:37] <infinity> apw: klibc is in the same boat right now (which is when I first noticed it)
[10:39] <apw> infinity, it looks new, so could be, is there a bug yet ?
[10:40] <infinity> apw: Nope.  It's 3:40am, I don't file bugs at this time of day.
[10:40] <infinity> apw: I just whine on IRC instead.
[10:41] <apw> infinity, reasonable indeed
[10:42] <pitti> apw: interesting: when I run my smaller reproducer, the VM gets messed up in all kinds of interesting ways: ssh suddenly stops working, now compiz is crashing, etc.
[10:42] <apw> pitti, joy
[10:42] <jibel> apw, it started on Nov. 16th with Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20111116)
[10:43] <jibel> apw, but we don't have the iso.
[10:43]  * apw wonders why it took till the 25th to file a bug about it
[10:45] <pitti> apw: that pretty much rules out eglibc then
[10:46] <pitti> apw: python as well, unchanged since oneiric
[10:47] <pitti> but 3.1.0 -> 3.2.0 happened on Nov 18
[10:47] <pitti> so that doesn't fit either
[10:50] <apw> pitti, to confirm i am reading the publishing history right, we uploaded 3.1.0-2.2 on the 2011-10-28 and 2.3 on the 2011-11-18
[10:50] <pitti> right
[10:51] <apw> jibel, so can i confirm everything worked on the 15th and not on the 16th ?
[10:51]  * apw wonders if this could be a host upgrade interacting with the guest
[10:52] <apw> jibel, do you keep the host static or does that upgrade too throughout the cycle
[10:56] <pitti> apw: do we turn any knobs in procps which might cause https://lists.ubuntu.com/archives/precise-changes/2011-November/002607.html to have a different effect now?
[10:57] <pitti> although I guess we need to look at uploads from Nov 15
[10:57] <pitti> we uploaded awfully lot on all days
[10:57] <apw> pitti, i'd like to have a proper bound on when it was last definatly successful, but yes 15th
[10:58] <jibel> apw, it started the week of the qa sprint and is compatible with an host upgrade. Let me check the date of the upgrade to Oneiric
[10:58] <apw> pitti, so the upload on the 18th only added postrm etc files to linux-virtual-extra which would not be involved here anyhow
[11:00] <apw> jibel, by compatible do you mean there was an upgrade host side in the right time span ?
[11:00] <jibel> apw, I confirm the failures started after the upgrade of the host to Oneiric
[11:00] <apw> jibel, thanks
[11:01] <smb> jibel, what was the host running before?
[11:01] <jibel> natty
[11:01] <apw> pitti, ^^
[11:01] <pitti> ah
[11:02] <pitti> yesterday I tried runnign with lucid kernel on precise guest, which also succeeded
[11:02] <smb> Ok, so just a minor change... ;-P
[11:02] <apw> jibel, so, can we get one of the test platforms zapped to natty easily to confirm thats the cause ?
[11:02] <pitti> I'm currently running an i386 guest install on amd64 host, but so far still not reproduced
[11:02] <apw> pitti, yeah its probabally something new in the new kernel which uses something new in the oneiric kernel which is broken
[11:03] <apw> so downgrading either should sort us out
[11:03] <apw> jibel, actually it may be only necessary to install a natty kernel on the oneiric host and test with that combination
[11:03] <pitti> right
[11:03] <pitti> and that's much easier to do, too
[11:04] <pitti> so, my test install finished the copying
[11:04] <apw> i could test that here if i could repro the problem at all
[11:04] <pitti> I will now install/boot the oneiric kernel on my precise system and try again
[11:04] <jibel> apw, the previous kernel is still installed and we could reboot to this kernel.
[11:05]  * apw realises
[11:05] <pitti> well, I'll run the same precise kernel host test again, as it doesn't happen every time
[11:05] <apw> jibel, that sounds good
[11:06] <apw> pitti, just realised i am running O with
[11:06] <apw> with the P kernel, so that may not repro
[11:10] <jibel> apw, ok, I need to schedule some downtime, it's our main host for iso testing. I think we can do that later today in the evening.
[11:14] <apw> jibel, ok thanks
[11:14] <apw> jibel, will let you know if we find anything else
[11:15] <cjwatson> apw: EINVAL - FWIW jibel found a similar-looking case in dpkg, which IMO rules out everything except kernel+libc
[11:16] <cjwatson> (this may be overtaken by events; I was flicking through scrollback)
[11:16] <apw> cjwatson, was that also testing in a VM, and if so do you know the host release
[11:16] <cjwatson> I don't know, hopefully jibel will remember what I'm talking about
[11:17] <cjwatson> oh, here
[11:17] <cjwatson> 16:31 <jibel> bug 896546, same crash than bug 894768 but with virtualbox
[11:17] <cjwatson> hopefully that's enough references to help
[11:17] <pitti> ok, my second i386 precise VM install on amd64 precise succeeded
[11:17] <pitti> I'll try with the oneiric kernel on host now
[11:17] <apw> cjwatson, yes thanks
[11:17] <apw> pitti, starting my second O+Pkernel one now (first successful)
[11:18] <pitti> apw: ok, that'll give us four runs with the P kernel on host
[11:18] <pitti> reboot, ,brg
[11:18] <cjwatson> oh, or not, where was it
[11:18] <pitti> OMG typing
[11:19] <cjwatson> apw: http://irclogs.ubuntu.com/2011/11/25/%23ubuntu-devel.html#t17:17
[11:19] <cjwatson> I guess that was in a VM too
[11:26] <pitti> ah, that took a while, oneiric's kernel plus .config/monitor.xml is broken with my external monitor (curiously it works fine with both lucid and precise kernels)
[11:28] <apw> pitti, that is peculiar indeed
[11:28] <pitti> apw: so, now running a test install under oneiric amd64 kernel
[11:37] <apw> pitti, second install finished, just rebooting it to confirm
[11:38] <jibel> apw, I found it only once with dpkg, and running the test again passed so I blamed the environment. it was the same testing environment but the test was running d-i instead of ubiquity.
[11:38] <pitti> I don't think it's the python part
[11:38] <pitti> the write() syscall failed with EINVAL
[11:38] <apw> its feeling like a kvm host bug from all the evidence we have
[11:39] <pitti> apw: except that someone got it under a Mac and with virtualbox, too
[11:40] <pitti> apw: and oneiric guest installs all succeed
[11:40] <pitti> which makes it sound like a guest side problem
[11:41] <pitti> ooooh! "The installer crashed"
[11:41] <apw> well likely precise is using the latest abi features of kvm, so it could easily be triggering a bug in the hostside
[11:41] <pitti> this is my first-ever reproducer
[11:41] <pitti> after some 10 installs
[11:41] <apw> pitti, and thats changing only the host kernel right?
[11:41] <pitti> right, same guest:
[11:41] <pitti> kvm -m 2048 -vga std -net none -drive if=virtio,index=0,file=/home/martin-scratch/images/test.img -cdrom ~/download/ubuntu/precise-desktop-i386.iso -boot d
[11:42] <pitti> I used -net none just to speed it up
[11:42] <pitti> as all the net stuff happens after copying
[11:43]  * pitti updates the bug
[11:45] <pitti> I'll now test a simpler reproducer
[11:46] <pitti> interesting graphics corruption bug in the VM, too
[11:47] <gema> apw: sorry, I was afk for a while
[11:47] <gema> apw: reading now
[11:48] <apw> gema, i think jibel answered all our queries to now
[11:48] <doko> cjwatson: tgall_foo completed the libjpeg-turbo rebuild tests (mail on linaro-dev), do you have concerns uploading the libjpeg packages after the alpha?
[11:50] <pitti> jibel: coudl we run the natty or precise kernel on those test machines for the time being, to unblock the daily tests?
[11:56] <gema> apw: ack. We have started last week our history of builds, so this time we don't have builds that go that far, but we will from now on. We are caching 2 weeks worth of builds now and plan to extend it to a month
[12:09] <zul> can someone review quantum for me...its sitting in the new queue for a while now
[12:14] <apw> pitti, i just ran a third install using your command line, and appear to have an installer crash (O userspace but with a P kernel)
[12:15] <pitti> apw: same EINVAL?
[12:19]  * apw wonders how he finds that out
[12:20] <apw> pitti, yes, Errno 22
[12:22] <cjwatson> doko: does the libjpeg-turbo source package build a libjpeg8 binary package so that we don't need a transition, as I requested (if they're still ABI-compatible)?
[12:22] <cjwatson> doko: I'm fine with it if and only if that's the case
[12:24] <pitti> apw: meh, now that I instrumented the write() call, it *of course* has to crash not there, but in the following .close()
[12:25]  * pitti updates the code and runs another two installs
[12:25] <apw> pitti, i also hit it in the close on this failure here
[12:26] <pitti> apw: running again now; I want to find out which file it stumbles over
[12:26] <apw> yeah be very interested if its consistant
[12:27] <doko> cjwatson, the solution is different, but you don't need a transition. libjpeg-turbo8 is diverting the shared library
[12:27] <wzssyqa> can anybody help me on https://bugs.launchpad.net/ubuntu/+source/tclcl/+bug/897158
[12:28] <ogra_> geser, pinagling, could you add armhf to the ftbfs list on ubuntuwire ?
[12:28] <cjwatson> doko: diverting?!
[12:29] <cjwatson> doko: why oh whwy
[12:29] <cjwatson> *why
[12:29] <ogra_> (looking at the code that looks like a one line change)
[12:29] <cjwatson> ogra_: no, see the page header
[12:29] <cjwatson> "Note: armhf is tracked on its own page until it settles down"
[12:29] <ogra_> OH !
[12:29] <ogra_> thanks
[12:30] <ogra_> one would think setting "Note" in bold should be enough for people noticing it :P
[12:32] <doko> cjwatson, I assume it was easier in the past to switch between the two implementations
[12:35] <geser> ogra_: I will prepare the FTBFS page to add armhf once it settles down
[12:35] <ogra_> yeah, understood, i simply missed the note
[12:36] <geser> cjwatson: how long do you expect armhf to settle down? days? weeks? next release cycle?
[12:36] <tgall_foo> cjwatson, yes that is the case?..   and the diverts can go,   that was there since when the libjpeg-turbo was originally put together we knew libjpeg was going to be installed
[12:36] <ogra_> geser, weeks
[12:36] <ogra_> for main it should take 4-6 weeks over the thumb, probably less
[12:37] <geser> ok, so I'm not in a hurry
[12:37] <tumbleweed> geser: doesn't the FTBFS page auto-detect archs?
[12:37] <ogra_> it has an arch list
[12:37] <ogra_> in the code
[12:37] <geser> tumbleweed: not yet, but that would be a good opportunity to finally add it
[12:37] <jibel> pitti, I'll reboot the machine with a natty kernel this evening. I can't do that now because it is a production server.
[12:38] <infinity> geser: Not autodetecting seems sane for now, having it on its own page (as wgrant set it up) keep the clutter down.
[12:39] <doko> infinity, did you miss the ldd change in eglibc?
[12:39] <infinity> doko: No.
[12:39] <tumbleweed> geser, ogra_: um, my checkout of it does
[12:39] <infinity> doko: What makes you ask?
[12:40] <geser> tumbleweed: then I haven't looked into the code for some time, might got included in one of wgrant's merge proposals
[12:40] <doko> infinity, didn't see it mentioned in your changelog entry
[12:41] <infinity> doko: * Add dynamic linker name for the non-default multilib in ARM ldd.
[12:41] <infinity> doko: Or did you mean another change?
[12:41] <infinity> doko: (I fixed that in 2.15 bzr as well, it was slightly wrong)
[12:42] <infinity> doko: I have a few other things to commit to 2.15 too, but I'll do that after I've napped.
[12:42] <doko> ok, thanks
[12:45] <apw> pitti, we also have to remember there is a userspace component on the host for the disks
[13:08] <apw> pitti, have you managed to get any filenames out ?
[13:08] <pitti> apw: still not; restarting the umpteenth time now
[13:10] <pitti> apw: did you?
[13:11] <pitti> it behaves strangely now, it doesn't seem to start copying files at all
[13:11] <apw> pitti, i've had exactly one reproduce on my O/P host (U/K) and P image testing
[13:11] <pitti> apw: I never reproduced it with the P host kernel, only with O host kernel
[13:12] <apw> pitti, that and it changing when you try and get the filename out implies its a very narrow race somewhere i suspect
[13:12] <pitti> hm, adding the IOErro logging to ubiquity somehow seems to completely break it; it just doesn't start copying at all
[13:12] <pitti> apw: no, no
[13:12] <pitti> I mean ubiquity doesn't _succeed_ copying files
[13:12] <pitti> it doesn't _start_
[13:12] <pitti> it just sits around showing the slideshow
[13:13] <apw> hrm
[13:13]  * apw will continue to try and get an idea of how reproducible it is here as well, and investigate what we can capture in qemu
[13:14] <pitti> it doesn't show me the partitioner either
[13:14] <pitti> ok, back again
[13:14] <pitti> aah, apparently I had two other KVMs running somewhere
[13:15] <pitti> jibel: really, you could have invented a bug which wouldn't need three hours to reproduce
[13:15]  * pitti hugs jibel, J/K
[13:32] <pitti> stgraber: hm, is the "Precise Daily" milestone gone from teh new tracker now?
[13:35] <herton> pitti, tjaalton reported that he can't install last oneiric kernel from proposed, some of the 3.0.0-14.23 packages ended up in universe, and aren't installable (linux-image* ones)
[13:37] <pitti> herton: fixed that and lbm
[13:37] <herton> ok thanks
[13:37] <tjaalton> pitti: thanks
[13:40] <NCommander> cjwatson: so as a followup to the UDS discussion, what do we need specifically to get partman to be able to handle partitioningon multiple devices (i.e., creating the /dev/mmcblk0p1 partition)
[13:43] <pitti> apw: finally, another crash
[13:47] <pitti> apw: noted the file name in bug, doing another run now
[13:49] <smb> pitti, was that on read or write?
[13:49] <pitti> smb: it never happened on read yet; we had it on write() or close()
[13:50] <pitti> that was on close()
[13:50] <smb> pitti, ok, which could be both write access
[13:50] <pitti> yeah, I guess close() just flushes the remaining buffers
[13:51] <smb> Right, I would expect it to do that
[13:52] <smb> Hm, interestingly at least on close -EINVAL seems not defined (or the man page is outdated)
[13:53] <doko> apw, any estimate when bug 861296 will be addressed for precise?
[13:54] <stgraber> pitti: could be that jibel did it
[13:56] <jibel> pitti, stgraber I disabled it to avoid confusion and having to consolidate results afterwards. Do you need it ?
[13:56] <pitti> jibel: no, I was just wondering
[14:01] <doko> lucas, is rubygems / dh_ruby considered part of the ruby packaging infrastructure?
[14:03] <lucas> doko: gem2deb, you mean? yes
[14:03] <smb> pitti, One other thing that may be interesting, is ubiquity using O_DIRECT for the target file(s)?
[14:03] <doko> lucas, ok, thanks
[14:04] <pitti> smb: no, we already checked that
[14:04] <smb> ah ok, missed that in the scrollback
[14:04] <pitti> smb: so all the "bad alignment" error cases shouldn't apply
[14:04] <smb> thanks
[14:04] <pitti> smb: nah, we did that yesterday, not in the discussion with apw
[14:04] <smb> ah :)
[14:24] <roadmr> Hey everyone! I need to report a couple upstream bugs on the kernel, but bugzilla.kernel.org is still down :-/ what's a good place to file bugs in the meanwhile? LKML? or the per-subsystem mailing lists? what are other people doing about this?
[14:25] <geser> roadmr: you might perhaps want to ask in #ubuntu-kernel
[14:27] <roadmr> geser: thanks! heading over there
[14:42] <hallyn> qualifies as first world problem, but, i'm trying out thunderbird, but though i set it to not check for mail every X minutes, it still checks every minute!
[14:45] <pitti> apw: four installs later, still no second reproducer; this sucks
[14:46] <pitti> and yay for linux being so exceptionally crappy with high IO, during that time my workstation is utterly slow
, sorry
[14:47] <roadmr> hallyn: do you actually see it polling every minute, or does email just arrive "as it hits the server"? you may try disabling IMAP IDLE so it only polls at your configured interval
[14:47] <hallyn> roadmr: i'll look for that, thx.
[14:48] <roadmr> hallyn: on account settings go to server settings, advanced, untick "use idle command if server supports it"
[14:48] <hallyn> found it, thanks :)
[14:48] <hallyn> It's a neat feature, agreed, but definately something i don't want :)
[14:51] <doko> hallyn, what reasons are there to promote the spice dependencies now, after splitting the package in oneiric?
[14:52] <hallyn> doko: spice in universe was only meant to be temporary.  we do not want to keep it split.  we just wanted ppl to be able to start testing, as there are lots of things (like libvirt support) to be worked out while we wait for main deps.
[14:53] <hallyn> doko: the current kvm-spice package is not maintainable imo, if we can't get deps into spice we'll need to switch to qemu-user (which is a different tree) providing it.
[14:53] <doko> mterry, ^^^
[14:54] <mterry> doko, I'm forgetting the backstory here?
[14:55] <doko> mterry, trying to understand why we did split it in the first place
[14:57] <doko> mterry, hallyn: I think I remember, these were the excessive devil build dependencies (which are missing in this MIR anyway)
[14:58] <hallyn> doko: I've opened MIRs for all the devil builds.  there are 3 or 4 more spice deps i need to file for, but the devil ones are all opened.
[14:58] <doko> hallyn, including allegro common lisp?
[14:58] <hallyn> doko: don't get me wrong.  i fjeer image libraries.  i want spice in main, but i'll understand if these are deemed unsafe.
[14:59] <hallyn> doko: allegro4.2, yes
[14:59] <doko> hallyn, sorry, but I don't want to have another lisp in main just for spice
[14:59] <pitti> apw: bug updated, finally got a second failure now
[15:00] <pitti> apw: so it's random files
[15:00] <hallyn> doko: well, that sucks, but i understand.
[15:00] <hallyn> Then I'll have to beg lool to let us enable spice in a package built from qemu-user  :)
[15:01] <lool> Hey, how may I help?
[15:01] <hallyn> i forget who originally suggested that at UDS.  was it slangasek?
[15:01] <doko> hallyn, for the future, it would be good to open bug tasks for the other packages, not separate reports
[15:01] <hallyn> doko: i don't understand (sorry i did it wrong)  you mean one bug for all MIRs?
[15:02] <doko> hallyn, for devil and it's b-d's and d's
[15:02] <hallyn> doko: i'll mark them all invalid if you like.  the libs were:  devil, svgalib, freeimage, and allegro4.2
[15:02] <hallyn> doko: devil itself was just a dep by cegui-mk2 (which also scares me).  should those have all been one?
[15:03] <doko> hallyn, let's slangasek comment on this
[15:03] <hallyn> lool: right now we have qemu-kvm-spice in main, built from a separate source package.  bc spice is in universe.  ppl want spice.  can we move the qemu-kvm-spice package into qemu-user source pkg?
[15:03] <hallyn> doko: ok
[15:03] <doko> maybe. I think ti makes it easier to see why packages are promoted
[15:05] <hallyn> so mark the bug as affecting multiple pkgs i assume.  makes sense.
[15:06] <lool> I'm afraid I know nothing of SPLICE; indeed slangasek revamped the qemu-kvm/qemu-linaro source packages last cycle
[15:06] <lool> err SPICE
[15:06] <hallyn> ah, ok
[15:07] <lool> You seem to be doing the right thing in filing MIRs though, not exactly sure where I could be helpful
[15:12] <hallyn> lool: well apparently the MIRs will be rejected :)
[15:23] <lool> hallyn: Oh ok; what's the issue with having the two source packages like right now?
[15:24] <apw> pitti, do you have a feel for how reproducible it is on your setup ?
[15:24] <pitti> apw: something like 1 out of 4
[15:25] <pitti> apw: I tried writing a python script which copies stuff, need to run this again
[15:25] <pitti> to have a smaller reproducer
[15:26] <apw> pitti, its 1/7 so far on my combo, will reboot into an older kernel now to see if that differes
[15:28] <hallyn> lool: well there has already been an update to the -spice package bringing it out of sync (in terms of version #) with qemu-kvm.  and there was a security update to qemu-kvm yesterday which will have to be duplicated manually in qemu-kvm-spice.  It just seems like begging for mistakes.
[15:30] <doko> apw, is iw supposed to promote? crda recommends it
[15:39] <lool> hallyn, doko: Would it make sense to build two flavors of qemu-kvm out of a single source package, promote just libspice to main but publish qemu-kvm-spice in universe as not to have any supported spice packages in main?  (don't know whether we can mark libspice as unsupported)
[15:41] <hallyn> lool: maybe, but that's a bit beyond me.  Using qemu-user as the source pkg seemed nice and simple.  Are there downsides?
[15:45] <doko> lool: no, b-d's would be required in main too
[15:45] <lool> doko: Yes, but could we flag them as unsupported?
[15:45] <doko> no, we don't know about something like this
[15:47] <lool> hallyn: You mean qemu-linaro?
[15:47] <hallyn> lol: right
[15:48] <lool> hallyn: I don't have a strong opinion, but we definitely want slangasek's comments here
[15:48] <hallyn> uh, lool  :)
[15:48] <hallyn> lool: ok, let's wait for him.  thanks.
[15:55] <dantti> cnd: ping
[15:57] <cnd> dantti, pong
[15:58] <dantti> cnd: so I have it working on upower now, needed a few patches on upower and a few others on the hid-magic mouse
[15:58] <dantti> the upower patch is commited
[15:58] <cnd> cool!
[15:58] <dantti> but I have no idea how to do it on the kernel since I never did anything there..
[15:59] <cnd> are you asking how to submit your magicmouse patches?
[15:59] <dantti> also there is a patch on the linux-input ml tthat changes hid-core to have some sort of generic way of working with batteries but that does not work for apple devices (and I'm pretty sure to no other)
[16:00] <dantti> cnd: yes, and I'm concerned how to merge my patch to the one a guy sent recently..
[16:01] <cnd> dantti, do you have your patches as separate commits in a git tree?
[16:02] <dantti> cnd: no, I think I should clone it, I actually apt-get source.. and made the changes there, but is a mess right now.. :P
[16:02] <dantti> cnd: http://paste.opensuse.org/50066334
[16:02] <cnd> ahh
[16:03] <cnd> dantti, so you'll want to clone the upstream hid repository
[16:03] <cnd> git clone git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
[16:04] <cnd> this will download a bunch of data and take probably 10 minutes on a fast connection
[16:04] <dantti> cnd: thanks, I was wondering if the kernel was in a huge git repo...
[16:05] <cnd> dantti, have you used git before?
[16:06] <dantti> cnd: sure, I code kde stuff, and packagekit too (which is why the upower commit was fast :P )
[16:06] <cnd> ok, good
[16:07] <dantti> cnd: this screenshot is nice too http://susepaste.org/49311448
[16:07] <cnd> dantti, once you get Jiri's tree cloned (note that I pasted the link to Jiri's HID tree, not Linus' tree)
[16:07] <cnd> checkout the upstream branch
[16:07] <cnd> the hid power patch is on the top of that branch
[16:08] <dantti> cnd: hmm is it another repo or just another branch on jiri's repo?
[16:08] <cnd> just another branch
[16:08] <dantti> k
[16:09] <cnd> when you have commits working, use git format-patch to generate patches (I'm guessing you know this already)
[16:09] <cnd> then read http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=blob;f=Documentation/SubmittingPatches;h=4468ce24427cb011e7991d8f1ae2560764b170b8;hb=HEAD
[16:09] <cnd> (that's a link to Documentation/SubmittingPatches in the kernel tree)
[16:09] <dantti> cnd: btw I have a concern about the keyboard wich works the same way but hid-magicmouse does not take care of it..
[16:10] <dantti> sorry hit the wrong shortcut..
[16:10] <cnd> heh
[16:11] <cnd> dantti, I'm not sure how to handle the keyboard
[16:11] <cnd> asking Jiri directly on the mailing list may help
[16:11] <dantti> cnd: so the patch would be the same to I guess hid-apple, but the duplication would suck...
[16:12] <dantti> K, I'll generate the patch and ask that too..
[16:13] <dantti> the patch is quite simple at the end, but the path to get there was not ...
[16:14] <cnd> heh
[16:14] <cnd> good luck!
[16:16] <job> hi
[16:17] <job> i have ton of machines spread around the globe, i use the ' mirror://mirrors.ubuntu.com/mirrors.txt/dists/maverick/Release.gpg' trick in /etc/apt/sources.list to have them use mirrors close by
[16:17] <job> but this fails if mirrors (such as http://ubuntu.washdc-linux.com/ubuntu/ ) are borked
[16:18] <job> washdc-linux.com is squatted by some domainname hoarder
[16:18] <job> what would be the fastest way to have somebody pull faulty mirrors from http://mirrors.ubuntu.com/US.txt
[16:22] <johanbr> job, try asking in #ubuntu-mirrors
[16:23] <job> yes i just read that, sorry :)
[16:23] <dantti> cnd: thanks
[16:47] <smb> slangasek, Hi Steve, just for a more direct info: I had been trying an attempt to get a nfs4 alias into the nfs module upstream. But the answer was rather mount.nfs4 should not be used. My impression is that nfs4 as an explicit fstype is deprecated. But nobody else got told (re bug 607039/bug 117957)
[17:07] <m4n1sh> is it true that update-manager does not have gnome-proxy support? Sorry, i am not on proxy, but tried it on workplace where it didnt work
[17:07] <m4n1sh> so I am guessing it is due to proxy issues
[17:15] <mvo> m4n1sh: hm, it will use the systemwide settings
[17:15] <m4n1sh> mvo: I was just troubleshooting a collegue's issue
[17:15] <m4n1sh> he had to get it done
[17:16] <m4n1sh> by config file
[17:16] <m4n1sh> it looks like it doesn't take the settings from gnome proxy settings
[17:16] <mvo> m4n1sh: there is a setting in the gnome-proxy-setup that says "apply systemwide" if that is set it should work - if not I would love ot hear more, but I need to get some dinner now
[17:17] <m4n1sh> mvo: sure. even I am waiting for the dinner. :)
[17:17] <doko> Daviey, zul, well the keystone MIR is assinged to jdstrand for a security audit, not to add the missing MIR's for depending packages ;)
[17:18] <Daviey> doko: right, didn't claim otherwise. :)
[17:24] <doko> Riddell, ScottK: does k3b need to recommend vcdimager, or is a Suggests enough?
[17:29] <apw> pitti, i managed to get this to reproduce stracing the qemu, and cannot see any EINVALs in the host at the time
[17:32] <apw> pitti, though i am yet to convince myself this contains all of the IO
[17:32] <pitti> apw: yeah, and the guest also doesn't have anything in dmesg
[17:32] <apw> this is going to be a beast
[17:32] <pitti> so by the time the bits get to the outside (host), the error has been lost in all the file system / guest block device etc. layers
[17:33] <pitti> apw: so you still get this with the precise kernel on the host?
[17:33] <apw> i got it one in 7 not the 1/2 i get with an oneiric host
[17:42] <slangasek> smb: nfs4> heh, cute.  What action is needed here then?  Updates to the mount manpage in util-linux, what else?
[17:42] <slangasek> hallyn, doko, lool: I don't know anything of splice either, what comments are you looking for?
[17:43] <slangasek> hallyn: is this "can we enable it in qemu-linaro so we don't have to in qemu-kvm"? :)
[17:43] <hallyn> slangasek: right now we have qemu-kvm in main, and a copy of its source tree in universe to build qemu-kvm-spice
[17:43] <hallyn> slangasek: yeah
[17:43] <slangasek> right
[17:43] <slangasek> I think I suggested this already when doing the NEW processing of it :)
[17:43] <hallyn> MIRs apparantly are a no-go
[17:43] <doko> because spice as a lot of b-d's which we didn't want to have in main
[17:44] <doko> for oneiric
[17:44] <hallyn> slangasek: yeah, i couldn't remember when you did
[17:44] <doko> so what did change that we want to merge it again?
[17:44] <slangasek> well, I'm not happy about having duplicated source packages
[17:44] <slangasek> hallyn's probably not happy maintaining them ;)
[17:45] <hallyn> doko: for o there was just no time.  for p there was time to at least try
[17:45] <hallyn> slangasek: yes, we're already one security fix behind in qemu-kvm-spice
[17:45] <doko> but her would be happy to maintain the 3rd lisp impl in main?
[17:45] <doko> he even
[17:45] <hallyn> doko: not particularly
[17:45] <hallyn> doko: that's why i'm asking about moving the pkg to qemu-linaro source
[17:45] <hallyn> so spice can stay in universe
[17:45] <doko> that would be an idea.
[17:46] <doko> anyway, afk for the next hours
[17:46] <hallyn> doko: thx
[17:46] <hallyn> slangasek: so no objectino from you in principle?  i should come up with a debdiff to propose?
[17:46] <slangasek> hallyn: I'm happy to have it merged with qemu-linaro in universe provided that building it from the linaro branch meets your needs
[17:47] <hallyn> slangasek: difference in the trees are supposed to be becomign minimal, and in fact the spice patches may be more uptodate in qemu than qemu-kvm, so i think it meets the needs,yeah
[17:48] <hallyn> thanks, i'll go try
[17:49] <slangasek> hallyn: ta :)
[17:50] <slangasek> hallyn: so I'm about to run out the door, but if you have some time a bit later today I'd like to sit down with you in realtime regarding the lvm/udev patches you tagged me for reviewing... I think I'm going to need some help understanding how we now think this is supposed to work
[17:51] <hallyn> slangasek: ok
[17:52] <Riddell> doko: I think it can downgraded to suggests
[18:09] <Daviey> SpamapS: did you see bug 887410 had a response?
[18:10] <Daviey> doko: I am getting concerned with the volume of comments regarding lack of sqlite2 support.  Is it viable to re-introduce it in universe?
[18:10] <Daviey> (bug 852349)
[18:13] <micahg> Daviey: I was going to try to get it dropped from Debian and Ubuntu this cycle since it's been dead upstream for a while and it's probably not supportable by anyone for 5 years
[18:14]  * micahg tried to get it dropped from Debian last cycle, but it fell through the cracks
[18:15] <Daviey> micahg: right, but users still want it - and are using straight binaries from forum attachments.
[18:15] <Daviey> I'd rather there was universe support, than people doing that
[18:16] <micahg> Daviey: users do lots of crazy things, that doesn't mean that we should condone them, lucid would be the best option for these people since it's supported on the server until 2015
[18:17] <micahg> IMHO, by 2015 sqlite2 will have been deprecated for almost 10 years and we shouldn't be encouraging support past that
[18:49] <broder> could i get pycryptopp in the maverick unapproved queue rejected please?
[18:49] <broder> i forgot to update-maintainer
[18:52] <matti> Bank details for new employer
[18:53] <matti> LOL
[18:53] <matti> Sorry, pasted website by accident.
[18:53] <matti> :)
[19:53] <hallyn> kees: do you have any security concerns for any of the info exposes with: http://lkml.org/lkml/2011/11/29/349
[19:55]  * kees reads
[19:57] <kees> hallyn: PR_SET_MM should absolutely be privileged, but I'm not sure which cap it should be under.
[19:58] <hallyn> kees: are you concerned about just printing out the start_data etc (in patch 1)?
[19:58] <hallyn> i guess it's still under 'permitted', so...
[19:59] <hallyn> yeah as for the priv either sys_admin or ptrace is fine with me.
[20:00] <hallyn> no, ptrace wouldn't do.
[20:00] <kees> 1/3 looks fine, it's using "permitted", so I'm happy.
[20:01] <kees> the cap needs to be stronger than ptrace, IMO. sysadmin is probably right, but it's just such a dumping ground.
[20:02] <kees> I don't think I'm happy with 3/3, though.
[20:02] <kees> nothing in that prctl is verified against mmap_min_addr
[20:07] <hallyn> kees: thanks for looking.
[20:08] <kees> hallyn: np, thanks for bringing it to my attention.
[20:25] <wgrant> geser, tumbleweed: I changed it recently to take an explicit arch list, because of stuff like armhf and rebuild archives.
[20:25] <wgrant> geser, tumbleweed: I also yesterday added a couple of quick changes to make armhf easier, which I haven't proposed yet.
[20:25] <wgrant> (allowing a custom note at the top, and customising the name of the output file)
[20:37] <tumbleweed> wgrant: are you ever going to start using my graphs? :)
[20:41] <awsoonn> I've been having trouble with my bluetooth devices ever since upgrading to 11.10, are there any known issues? What's really got me puzzled is that ever since trying to pair with my mom's cellphone I've been getting random kernel panics...
[20:41] <wgrant> tumbleweed: Graphs?
[20:43] <tumbleweed> wgrant: in lp-ftbfs-report trunk
[20:43] <tumbleweed> e.g. http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/primary-precise.html
[20:44] <wgrant> Ah, I don't think anyone told me about that :)
[20:46] <tumbleweed> wgrant: feel free to grab the sqlite DBs I have with precise history (that's why I've been running it)
[21:00] <awsoonn> how can I find what package provided a specific file?
[21:01] <Pici> awsoonn: 1) this isn't a support channel, use #ubuntu, 2) dpkg -S /path/to/file
[21:03] <awsoonn> Pici: I'm sorry I thought I was in the right place... I am trying to learn how to track down and fix a seg fault in bluetoothd. Should I still poke #ubuntu or is there a better place?
[21:04] <Pici> awsoonn: #ubuntu really would be the right place to ask, but I'm not sure you're going to find much help for a random kernel panic issue in either channel.
[21:06] <stgraber> slangasek: btw, while working on making ifenslave work with event based boot, I noticed that bridging is even more broken, so my home setup of eth0 + eth1 => bond0 => bond0.1000 + bond0.1020 with each of the bond0.XXXX being in a separate bridge explodes completely :)
[21:06] <awsoonn> Pici, have a better idea where to go for help?
[21:07] <stgraber> slangasek: only workaround for now is a nice sleep 5 in the boot sequence... guess I'll fix these once I'm done with ifenslave
[21:07] <maco> for a kernel panic, you'd probably want to file a bug
[21:07] <maco> as that's pretty clearly a bug
[21:07] <Pici> maco: thanks.
[21:07] <Pici> maco: but a segfault?
[21:07] <maco> not just user error, which is what tech support normally fixes :P
[21:07] <maco> segfaults are also bugs
[21:08] <maco> a command was used wrong in the code, or free() was called on the same variable twice, or a variable was read from without being initialized first...
[21:08] <awsoonn> I've done so already, but I'm diving into fixing it myself and providing a patch. I'm wondering now what is the proper channel to ask for help when needed
[21:08] <maco> if you're making a patch, here is fine
[21:09] <maco> i dont know how many are around right now that could help you if you're having trouble with C or whatever though
[21:09] <maco> ##c may be useful
[21:10] <awsoonn> thanks maco, I've got a decent grasp on C, but the system archetecture is best learned by diving in no doubt. That's where I need  the most help. :P
[21:11] <awsoonn> I do get confused as to which IRC channels i should poke though, what's the differnce between -devel and -motu?
[21:12] <maco> motu is a bit more mentor-y and devel is a bit more "lets discuss decisions about direction blah blah"
[21:12] <maco> people in both *should* be able to help though
[21:12] <maco> there's also -packaging ;)
[21:13] <stgraber> slangasek: ah, and one other thing I've noticed that's going to be a lot of fun to deal with, you can't create vlans or bridge a bond that doesn't have any slave (as it doesn't have a mac address) :)
[21:13] <awsoonn> right-o, I think I'll start off in -motu from now on. yea? I wish I had known about -packaging.... I just spent two days figuring out the launchpad bzr and ppa systems and how to build my own pkg from scratch...
[21:14] <maco> yeah motu's a good place for "halp! i'm trying to contribute, but...."
[21:15] <awsoonn> well, thanks maco I'll make the jump now. :D
[22:42] <stgraber> slangasek, SpamapS, Daviey: So that's my new problem when dealing with event based boot and complex network configuration... http://paste.ubuntu.com/754234/ (currently only bit that doesn't seem racy is my new ifenslave, sadly it only showed that the rest is broken too)
[23:02] <broder> is anybody looking into/planning to multiarch-ify the gtkmm stack?
[23:03] <TheMuso> broder: Has Debisn started to do it?
[23:04] <broder> TheMuso: doesn't look like it
[23:04] <TheMuso> broder: ah ok
[23:05] <broder> i'd kind of like to see it done for precise, and could probably drive it, but don't want to step on anybody's toes
[23:06] <broder> ...although now that i think about it, my use case may not require the libraries being co-installable, so i could probably just remove the local arch gtkmm packages and install the foreign arch ones
[23:06] <broder> but i can try to do it anyway