[00:24] 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] cjwatson: oh, and libreoffice. ;) [00:32] * micahg thought we wanted a libreoffice rebuild for alpha1 [00:48] 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? === Ursinha_ is now known as Ursinha [00:59] SpamapS: excellent [00:59] micahg: so did I, but I think it's too late now :-/ [01:00] cjwatson: do you sleep? It seems that you're online every time I hop on IRC... :P [01:00] SpamapS: well done on sorting through the bulk of the build failure swamp [01:00] awsoonn: heh, a few people say that ... I'm just about to [01:00] good! :) [01:01] 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] 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] give it an install target, have the target honour DESTDIR [01:04] cjwatson: the swamp definitely had more ROUS's than I expected.. but the quicksand and fire traps weren't even a problem. ;) [01:04] so e.g. 'install -m0755 mygame $(DESTDIR)/usr/bin' [01:05] (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] i dont mind effort if there is some glimmer of learning something usefull [01:05] (sorry, that wants 'install -d $(DESTDIR)/usr/bin' first) [01:06] in automake you'd just have 'bin_PROGRAMS = mygame' and then 'mygame_SOURCES = mygame.c' (say) [01:07] but for something simple it's not unreasonable to do it by hand, particularly as you'll get more reward more quickly :) [01:07] and if you already have a Makefile that does the building part, it's not much more [01:07] anyway, bed [01:07] ok, thx for the heads up, g'night! [01:09] win 76 === dendro-afk is now known as dendrobates [03:55] SpamapS: great work on the libmysqlclient transition [03:57] micahg: thanks.. I think there are still a few tiny dangling bits but they're all too big to be patching around. === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk [06:38] Good morning === TimStarling is now known as Tim-away [07:26] * SpamapS realizes a few universe packages were missed in the libmysqlclient sweep [07:30] SpamapS: No time like the present to fix 'em. ;) [07:39] yeah, thank god for submittodebian [08:08] good morning [08:50] morning, for the kernel team: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc3-oneiric/ <--- there are missing packages inside this directory === smb` is now known as smb [09:05] 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] oh, ok [09:06] bambee, the fix for that is in linus' tree and so we expect the later dailies and releases to build again [09:06] infinity, did those bootstrap builds work ok? [09:07] 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] apw: the DEB_STAGE trick worked fine to squeeze out a linux-libc-dev, a full build failed with kernel-wedge puking. [09:08] infinity, got a log for that, is that kernel-wedge broken or our tree ? [09:08] apw: I have my hands full with other stuff right now, so failed to care deeply. [09:08] fair enough [09:08] as long as you have your bootstrap life is good [09:09] apw: Pretty much, yeah. I don't really care about having an omap3 kernel right now. ;) [09:09] infinity, i'll add it to my todo list for when we have a chroot [09:09] apw: We have chroots. [09:09] apw: It's building. :P [09:09] apw: Unless you mean on a porter box. [09:09] apw: I can probably convince lamont to set one up tomorrow. [09:10] infinity, yeah somewhere i can play yes then i can debug it without interfering [09:10] * apw ^5s DEB_STAGE [09:10] Yeah, much love for the DEB_STAGE hack. [09:10] Whoever did that. [09:10] it was done by linaro for the very same use [09:11] in their case they are bootstrapping new vendor boards [09:13] 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:13] Launchpad bug 857956 in glance (Ubuntu Precise) "[SRU] Control file needs python-httplib2 dependency" [High,Fix committed] https://launchpad.net/bugs/857956 [09:20] pitti: gah, yes - will be uploaded today. [09:20] Thanks. [09:21] Daviey: thanks [09:40] ooh armhf builds [09:43] am I correct in assuming that armhf and armel can chroot each-other without emulation? [09:53] pitti: it is Fix Released in precise. [09:53] Daviey: yay you, moving to -updates [09:54] there it goes [09:54] rocking :), thanks [10:22] 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] apw: it's ubiquity [10:23] apw: incidentally, I'm just working on finding a simpler reproducer for it [10:23] 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] apw: yep, will do [10:24] apw: NB that it only seems to happen for i386 images on amd64 [10:24] ... hosts [10:24] yeah i see there is some correlation there [10:25] apw: logging the file name is easy, you just need to edit /usr/lib/ubiquity/ubiquity/install_misc.py [10:25] and at the top of def copy_file(), add something like [10:25] pitti, yeah i guess it is easy, just mad that when the think throws up it doesn't report the failing filename [10:25] syslog.syslog('copying %s -> %s' % (sourcepath, targetpath)) [10:25] if it did we would already know if its random or the same file [10:26] so for the next time, i want it to report the failing file [10:26] right, we could intercept IOError, log the file, and raise it again, that's better [10:26] 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] apw: sounds good, we don't overlap then [10:27] it's currently expected that running precise ISO with the oneiric kernel will work, but that's to be proven [10:28] pitti, yeah given we have new libc and new python (i believe) it really could be any of them [10:28] EINVAL is common in libc too at least [10:28] 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] gema, you aware of the EINVAL issue in QA ? [10:29] jibel might remember [10:30] i believe they do daily testing, so we should know which day it started [10:35] apw: https://launchpadlibrarian.net/86175847/buildlog_ubuntu-precise-armhf.iptables_1.4.12-1ubuntu2_FAILEDTOBUILD.txt.gz [10:35] 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] infinity, looking [10:37] apw: (Completely reproducible on x86, not an ARM thing) [10:37] apw: klibc is in the same boat right now (which is when I first noticed it) [10:39] infinity, it looks new, so could be, is there a bug yet ? [10:40] apw: Nope. It's 3:40am, I don't file bugs at this time of day. [10:40] apw: I just whine on IRC instead. [10:41] infinity, reasonable indeed [10:42] 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] pitti, joy [10:42] apw, it started on Nov. 16th with Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20111116) [10:43] 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] apw: that pretty much rules out eglibc then [10:46] apw: python as well, unchanged since oneiric [10:47] but 3.1.0 -> 3.2.0 happened on Nov 18 [10:47] so that doesn't fit either [10:50] 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] right [10:51] 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] jibel, do you keep the host static or does that upgrade too throughout the cycle [10:56] 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] although I guess we need to look at uploads from Nov 15 [10:57] we uploaded awfully lot on all days [10:57] pitti, i'd like to have a proper bound on when it was last definatly successful, but yes 15th [10:58] 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] 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] jibel, by compatible do you mean there was an upgrade host side in the right time span ? [11:00] apw, I confirm the failures started after the upgrade of the host to Oneiric [11:00] jibel, thanks [11:01] jibel, what was the host running before? [11:01] natty [11:01] pitti, ^^ [11:01] ah [11:02] yesterday I tried runnign with lucid kernel on precise guest, which also succeeded [11:02] Ok, so just a minor change... ;-P [11:02] jibel, so, can we get one of the test platforms zapped to natty easily to confirm thats the cause ? [11:02] I'm currently running an i386 guest install on amd64 host, but so far still not reproduced [11:02] pitti, yeah its probabally something new in the new kernel which uses something new in the oneiric kernel which is broken [11:03] so downgrading either should sort us out [11:03] jibel, actually it may be only necessary to install a natty kernel on the oneiric host and test with that combination [11:03] right [11:03] and that's much easier to do, too [11:04] so, my test install finished the copying [11:04] i could test that here if i could repro the problem at all [11:04] I will now install/boot the oneiric kernel on my precise system and try again [11:04] apw, the previous kernel is still installed and we could reboot to this kernel. [11:05] * apw realises [11:05] well, I'll run the same precise kernel host test again, as it doesn't happen every time [11:05] jibel, that sounds good [11:06] pitti, just realised i am running O with [11:06] with the P kernel, so that may not repro [11:10] 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] jibel, ok thanks [11:14] jibel, will let you know if we find anything else [11:15] apw: EINVAL - FWIW jibel found a similar-looking case in dpkg, which IMO rules out everything except kernel+libc [11:16] (this may be overtaken by events; I was flicking through scrollback) [11:16] cjwatson, was that also testing in a VM, and if so do you know the host release [11:16] I don't know, hopefully jibel will remember what I'm talking about [11:17] oh, here [11:17] 16:31 bug 896546, same crash than bug 894768 but with virtualbox [11:17] Launchpad bug 894768 in linux (Ubuntu Precise) "duplicate for #896546 Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,Triaged] https://launchpad.net/bugs/894768 [11:17] Launchpad bug 894768 in linux (Ubuntu Precise) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,Triaged] https://launchpad.net/bugs/894768 [11:17] hopefully that's enough references to help [11:17] ok, my second i386 precise VM install on amd64 precise succeeded [11:17] I'll try with the oneiric kernel on host now [11:17] cjwatson, yes thanks [11:17] pitti, starting my second O+Pkernel one now (first successful) [11:18] apw: ok, that'll give us four runs with the P kernel on host [11:18] reboot, ,brg [11:18] oh, or not, where was it [11:18] OMG typing [11:19] apw: http://irclogs.ubuntu.com/2011/11/25/%23ubuntu-devel.html#t17:17 [11:19] I guess that was in a VM too === _salem is now known as salem_ [11:26] 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] pitti, that is peculiar indeed [11:28] apw: so, now running a test install under oneiric amd64 kernel [11:37] pitti, second install finished, just rebooting it to confirm [11:38] 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] I don't think it's the python part [11:38] the write() syscall failed with EINVAL [11:38] its feeling like a kvm host bug from all the evidence we have [11:39] apw: except that someone got it under a Mac and with virtualbox, too [11:40] apw: and oneiric guest installs all succeed [11:40] which makes it sound like a guest side problem [11:41] ooooh! "The installer crashed" [11:41] well likely precise is using the latest abi features of kvm, so it could easily be triggering a bug in the hostside [11:41] this is my first-ever reproducer [11:41] after some 10 installs [11:41] pitti, and thats changing only the host kernel right? [11:41] right, same guest: [11:41] 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] I used -net none just to speed it up [11:42] as all the net stuff happens after copying [11:43] * pitti updates the bug [11:45] I'll now test a simpler reproducer [11:46] interesting graphics corruption bug in the VM, too === doko_ is now known as doko [11:47] apw: sorry, I was afk for a while [11:47] apw: reading now [11:48] gema, i think jibel answered all our queries to now [11:48] 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] jibel: coudl we run the natty or precise kernel on those test machines for the time being, to unblock the daily tests? [11:56] 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] can someone review quantum for me...its sitting in the new queue for a while now [12:14] 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] apw: same EINVAL? [12:19] * apw wonders how he finds that out [12:20] pitti, yes, Errno 22 === MacSlow is now known as MacSlow|lunch [12:22] 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] doko: I'm fine with it if and only if that's the case [12:24] 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] pitti, i also hit it in the close on this failure here [12:26] apw: running again now; I want to find out which file it stumbles over [12:26] yeah be very interested if its consistant [12:27] cjwatson, the solution is different, but you don't need a transition. libjpeg-turbo8 is diverting the shared library [12:27] can anybody help me on https://bugs.launchpad.net/ubuntu/+source/tclcl/+bug/897158 [12:27] Launchpad bug 897158 in tclcl (Ubuntu) "Please sync tclcl (1.20-4) from Debian Sid (main) to Ubuntu (universe)" [Wishlist,New] [12:28] geser, pinagling, could you add armhf to the ftbfs list on ubuntuwire ? [12:28] doko: diverting?! [12:29] doko: why oh whwy [12:29] *why [12:29] (looking at the code that looks like a one line change) [12:29] ogra_: no, see the page header [12:29] "Note: armhf is tracked on its own page until it settles down" [12:29] OH ! [12:29] thanks [12:30] one would think setting "Note" in bold should be enough for people noticing it :P [12:32] cjwatson, I assume it was easier in the past to switch between the two implementations [12:35] ogra_: I will prepare the FTBFS page to add armhf once it settles down [12:35] yeah, understood, i simply missed the note [12:36] cjwatson: how long do you expect armhf to settle down? days? weeks? next release cycle? [12:36] 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] geser, weeks [12:36] for main it should take 4-6 weeks over the thumb, probably less [12:37] ok, so I'm not in a hurry [12:37] geser: doesn't the FTBFS page auto-detect archs? [12:37] it has an arch list [12:37] in the code [12:37] tumbleweed: not yet, but that would be a good opportunity to finally add it [12:37] 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] geser: Not autodetecting seems sane for now, having it on its own page (as wgrant set it up) keep the clutter down. [12:39] infinity, did you miss the ldd change in eglibc? [12:39] doko: No. [12:39] geser, ogra_: um, my checkout of it does [12:39] doko: What makes you ask? [12:40] tumbleweed: then I haven't looked into the code for some time, might got included in one of wgrant's merge proposals [12:40] infinity, didn't see it mentioned in your changelog entry [12:41] doko: * Add dynamic linker name for the non-default multilib in ARM ldd. [12:41] doko: Or did you mean another change? [12:41] doko: (I fixed that in 2.15 bzr as well, it was slightly wrong) [12:42] doko: I have a few other things to commit to 2.15 too, but I'll do that after I've napped. [12:42] ok, thanks [12:45] pitti, we also have to remember there is a userspace component on the host for the disks [13:08] pitti, have you managed to get any filenames out ? [13:08] apw: still not; restarting the umpteenth time now [13:10] apw: did you? [13:11] it behaves strangely now, it doesn't seem to start copying files at all [13:11] pitti, i've had exactly one reproduce on my O/P host (U/K) and P image testing [13:11] apw: I never reproduced it with the P host kernel, only with O host kernel [13:12] pitti, that and it changing when you try and get the filename out implies its a very narrow race somewhere i suspect [13:12] hm, adding the IOErro logging to ubiquity somehow seems to completely break it; it just doesn't start copying at all [13:12] apw: no, no [13:12] I mean ubiquity doesn't _succeed_ copying files [13:12] it doesn't _start_ [13:12] it just sits around showing the slideshow [13:13] 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] it doesn't show me the partitioner either [13:14] ok, back again [13:14] aah, apparently I had two other KVMs running somewhere [13:15] jibel: really, you could have invented a bug which wouldn't need three hours to reproduce [13:15] * pitti hugs jibel, J/K === MacSlow|lunch is now known as MacSlow [13:32] stgraber: hm, is the "Precise Daily" milestone gone from teh new tracker now? [13:35] 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] herton: fixed that and lbm [13:37] ok thanks [13:37] pitti: thanks [13:40] 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] apw: finally, another crash [13:47] apw: noted the file name in bug, doing another run now [13:49] pitti, was that on read or write? [13:49] smb: it never happened on read yet; we had it on write() or close() [13:50] that was on close() [13:50] pitti, ok, which could be both write access [13:50] yeah, I guess close() just flushes the remaining buffers [13:51] Right, I would expect it to do that [13:52] Hm, interestingly at least on close -EINVAL seems not defined (or the man page is outdated) [13:53] apw, any estimate when bug 861296 will be addressed for precise? [13:53] Launchpad bug 861296 in linux (Ubuntu) "mmap fails to allocate 2030Mb heap on ARM" [High,Confirmed] https://launchpad.net/bugs/861296 [13:54] pitti: could be that jibel did it [13:56] pitti, stgraber I disabled it to avoid confusion and having to consolidate results afterwards. Do you need it ? [13:56] jibel: no, I was just wondering === bladernr_afk is now known as bladernr_ [14:01] lucas, is rubygems / dh_ruby considered part of the ruby packaging infrastructure? [14:03] doko: gem2deb, you mean? yes [14:03] pitti, One other thing that may be interesting, is ubiquity using O_DIRECT for the target file(s)? [14:03] lucas, ok, thanks [14:04] smb: no, we already checked that [14:04] ah ok, missed that in the scrollback [14:04] smb: so all the "bad alignment" error cases shouldn't apply [14:04] thanks [14:04] smb: nah, we did that yesterday, not in the discussion with apw [14:04] ah :) [14:24] 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] roadmr: you might perhaps want to ask in #ubuntu-kernel [14:27] geser: thanks! heading over there === hyperair is now known as Guest43903 [14:42] 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] apw: four installs later, still no second reproducer; this sucks [14:46] and yay for linux being so exceptionally crappy with high IO, during that time my workstation is utterly slow [14:46] , sorry [14:47] 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] roadmr: i'll look for that, thx. [14:48] hallyn: on account settings go to server settings, advanced, untick "use idle command if server supports it" [14:48] found it, thanks :) [14:48] It's a neat feature, agreed, but definately something i don't want :) [14:51] hallyn, what reasons are there to promote the spice dependencies now, after splitting the package in oneiric? [14:52] 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] 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] mterry, ^^^ [14:54] doko, I'm forgetting the backstory here? [14:55] mterry, trying to understand why we did split it in the first place === Amaranth__ is now known as Amaranth [14:57] mterry, hallyn: I think I remember, these were the excessive devil build dependencies (which are missing in this MIR anyway) [14:58] 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. === Amaranth__ is now known as Amaranth [14:58] hallyn, including allegro common lisp? [14:58] 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] doko: allegro4.2, yes [14:59] hallyn, sorry, but I don't want to have another lisp in main just for spice [14:59] apw: bug updated, finally got a second failure now [15:00] apw: so it's random files [15:00] doko: well, that sucks, but i understand. [15:00] Then I'll have to beg lool to let us enable spice in a package built from qemu-user :) [15:01] Hey, how may I help? [15:01] i forget who originally suggested that at UDS. was it slangasek? [15:01] hallyn, for the future, it would be good to open bug tasks for the other packages, not separate reports [15:01] doko: i don't understand (sorry i did it wrong) you mean one bug for all MIRs? [15:02] hallyn, for devil and it's b-d's and d's [15:02] doko: i'll mark them all invalid if you like. the libs were: devil, svgalib, freeimage, and allegro4.2 [15:02] doko: devil itself was just a dep by cegui-mk2 (which also scares me). should those have all been one? [15:03] hallyn, let's slangasek comment on this [15:03] 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] doko: ok [15:03] maybe. I think ti makes it easier to see why packages are promoted [15:05] so mark the bug as affecting multiple pkgs i assume. makes sense. [15:06] I'm afraid I know nothing of SPLICE; indeed slangasek revamped the qemu-kvm/qemu-linaro source packages last cycle [15:06] err SPICE [15:06] ah, ok [15:07] You seem to be doing the right thing in filing MIRs though, not exactly sure where I could be helpful [15:12] lool: well apparently the MIRs will be rejected :) === JackyAlcine is now known as Guest31399 === EvilJackyAlcine is now known as JackyAlcine [15:23] hallyn: Oh ok; what's the issue with having the two source packages like right now? [15:24] pitti, do you have a feel for how reproducible it is on your setup ? [15:24] apw: something like 1 out of 4 [15:25] apw: I tried writing a python script which copies stuff, need to run this again [15:25] to have a smaller reproducer [15:26] pitti, its 1/7 so far on my combo, will reboot into an older kernel now to see if that differes [15:28] 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] apw, is iw supposed to promote? crda recommends it [15:39] 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] 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] lool: no, b-d's would be required in main too [15:45] doko: Yes, but could we flag them as unsupported? [15:45] no, we don't know about something like this [15:47] hallyn: You mean qemu-linaro? [15:47] lol: right [15:48] hallyn: I don't have a strong opinion, but we definitely want slangasek's comments here [15:48] uh, lool :) [15:48] lool: ok, let's wait for him. thanks. === JackyAlcine is now known as Guest19827 === EvilJackyAlcine is now known as JackyAlcine [15:55] cnd: ping [15:57] dantti, pong [15:58] 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] the upower patch is commited [15:58] cool! [15:58] but I have no idea how to do it on the kernel since I never did anything there.. [15:59] are you asking how to submit your magicmouse patches? [15:59] 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] cnd: yes, and I'm concerned how to merge my patch to the one a guy sent recently.. [16:01] dantti, do you have your patches as separate commits in a git tree? [16:02] 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] cnd: http://paste.opensuse.org/50066334 [16:02] ahh [16:03] dantti, so you'll want to clone the upstream hid repository [16:03] git clone git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git [16:04] this will download a bunch of data and take probably 10 minutes on a fast connection [16:04] cnd: thanks, I was wondering if the kernel was in a huge git repo... [16:05] dantti, have you used git before? [16:06] cnd: sure, I code kde stuff, and packagekit too (which is why the upower commit was fast :P ) [16:06] ok, good [16:07] cnd: this screenshot is nice too http://susepaste.org/49311448 [16:07] dantti, once you get Jiri's tree cloned (note that I pasted the link to Jiri's HID tree, not Linus' tree) [16:07] checkout the upstream branch [16:07] the hid power patch is on the top of that branch [16:08] cnd: hmm is it another repo or just another branch on jiri's repo? [16:08] just another branch [16:08] k [16:09] when you have commits working, use git format-patch to generate patches (I'm guessing you know this already) [16:09] then read http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=blob;f=Documentation/SubmittingPatches;h=4468ce24427cb011e7991d8f1ae2560764b170b8;hb=HEAD [16:09] (that's a link to Documentation/SubmittingPatches in the kernel tree) [16:09] 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] sorry hit the wrong shortcut.. [16:10] heh [16:11] dantti, I'm not sure how to handle the keyboard [16:11] asking Jiri directly on the mailing list may help [16:11] cnd: so the patch would be the same to I guess hid-apple, but the duplication would suck... [16:12] K, I'll generate the patch and ask that too.. [16:13] the patch is quite simple at the end, but the path to get there was not ... [16:14] heh [16:14] good luck! === shadeslayer_ is now known as shadeslayer [16:16] hi [16:17] 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] but this fails if mirrors (such as http://ubuntu.washdc-linux.com/ubuntu/ ) are borked [16:18] washdc-linux.com is squatted by some domainname hoarder [16:18] what would be the fastest way to have somebody pull faulty mirrors from http://mirrors.ubuntu.com/US.txt [16:22] job, try asking in #ubuntu-mirrors [16:23] yes i just read that, sorry :) [16:23] cnd: thanks === beuno is now known as beuno-lunch === chrisccoulson_ is now known as chrisccoulson [16:47] 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) [16:47] Launchpad bug 607039 in nfs-utils (Ubuntu) "NFS4 automount using replicated servers doesn't work" [Medium,New] https://launchpad.net/bugs/607039 [16:47] Launchpad bug 117957 in nfs-utils (Ubuntu) "Need to modprobe nfs module before mounting nfs4 export" [Medium,Triaged] https://launchpad.net/bugs/117957 === Ursinha is now known as Ursinha-lunch [17:07] 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] so I am guessing it is due to proxy issues [17:15]