[00:01] <TheMuso> /c/c
=== slank is now known as slank_away
=== Amaranthus is now known as Amaranth
=== doko__ is now known as doko
[03:02] <TheMuso> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== jackyalcine_ is now known as jalcine
[04:53] <pitti> Good morning
[04:54] <stokachu> ugh its midnight here :)
[04:54] <chiluk> yes it is...
[04:54] <stokachu> chiluk: o/
[04:54] <chiluk> and yes stokachu I am stalking you!
[04:54] <stokachu> hah, thats ok i welcome the love
[04:54] <pitti> cjwatson: ah, the upstream one does have = NULL, good
[04:55] <chiluk> upstream++
[07:42] <dholbach> good morning
=== smb` is now known as smb
[08:59] <seb128> janimo, hey, thanks for the g-s-d patch, there is no upstream or downstream bug reference in there though, do you have one, can you share it?
[09:04] <hrw> can someone suggest me good example of package with 'read and accept' license?
[09:07] <janimo> seb128, https://bugzilla.gnome.org/show_bug.cgi?id=691691
[09:07] <ubottu> Gnome bug 691691 in xrandr "Use transformation matrix to rotate touchscreens" [Normal,New]
[09:09] <seb128> janimo, thanks, would be nice to put that info in the patch "Bug: bug URL" next time ;-)
[09:09] <janimo> seb128, right, will next time :)
[09:10] <seb128> janimo, thanks ;-)
[09:10] <pitti> yay for Bastien reviewing patches fast
[09:10] <janimo> I wonder why I did not get a mail notification though, it's only now that I checked the URL did I see the review
[09:11] <janimo> seb128, btw I have a new patch for g-s-d but likely not upstreamable. It solved the nexus autorotation issue without relying on kernel changes. I'll write to the ml
[09:11] <geser> hrw: I know only of the non-free jre/jdk packages doing it (in the past)
[09:11] <janimo> s/solved/solves/
[09:12] <hrw> geser: I need it for nonfree package
[09:12] <seb128> janimo, thanks, if that's not upstreamable please open at least a launchpad bug with the rational so we know why it's there next time we look at merging with Debian or review our patches
[09:12] <hrw> geser: Mali T604 drivers for arm chromebook
[09:12] <janimo> hrw, you may want to look at the linux-firmware-nexus package too
[09:12] <hrw> thanks
=== henrix_ is now known as henrix
=== zequence_ is now known as zequence
=== yofel_ is now known as yofel
[09:44] <pitti> dholbach: we'll have some autopkgtest hacking on Friday? Is that announced anywhere already? (for pointing to in my talk)
[09:45] <hrw> bug 1000453
[09:45] <ubottu> bug 1000453 in strace (Ubuntu) "strace 4.7 is available" [Medium,Triaged] https://launchpad.net/bugs/1000453
[09:45] <pitti> dholbach: I'd just ask folks to show up in #ubuntu-quality, that should do?
[09:46] <dholbach> pitti, I'll prepare some things in a bit - yes #ubuntu-quality - not announced yet, but soon
[10:05] <ev> would someone kindly reject whoopsie 0.2.10 and 0.2.11 from Quantal? I was tired when I uploaded those :). They're meant for Raring.
[10:10] <seb128> ev, done
[10:21] <hrw> janimo: thanks, linux-firmware-nexus7 looks like something I need
[10:34] <ev> seb128: thanks!
[10:41] <xnox> hrw: the classic example is ttf-mscorefonts-installer as that one gets it completely right.
[10:41] <hrw> xnox: thanks, will look at this one as well
[10:42] <infinity> doko: Is cloog-parma obsolete now?
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[13:47] <doko>   infinity yes
[13:50] <ogra_> stgraber, yo ... i'm planning on switching the nexus7 to use the g_composite USB gadget driver, that way we can have serial and usbnet support at the same time on the USB port ... to make NM not freak out on your PC i would like to boot with usb0 disabled on the nexus, while a upstart job with "ifconfig usb0 down" will work, i was wondering if you have some more elegant idea
[14:01] <ogra_> bah, crap ... i missed the nomination period for DMB ... i was actually planning to apply
[14:03] <seb128> did anyone apply?
[14:04] <Laney> lots of people
[14:04] <Laney> ogra_: go for the TB instead ;-)
[14:05] <pitti> ogra_: I'm fairly sure they wouldn't slam the door and say "too late" :)
[14:05] <Laney> The poll was just sent out, which I guess is what reminded him
[14:11] <dholbach> dpm, coolbhavi, achiang, mhall119: ready for your sessions later on?
[14:12] <coolbhavi> dholbach, pretty much :-)
[14:12] <dpm> dholbach, indeed, having gotten confused by the dates, I've been ready for about a week ;)
[14:14] <janimo> seb128, is there a way of getting g-s-d run while at the lightdm login? I wonder how to get that screen to react to tablet orientation
=== dpm_ is now known as dpm__
=== dpm is now known as dpm-laptop
=== dpm__ is now known as dpm
[14:19] <seb128> janimo, the unity-greeter does run g-s-d
[14:20] <janimo> seb128, thanks, I'll look into debugging it then
[14:20] <seb128> yw
=== slank_away is now known as slank
[14:24] <EagleScreen> I don't want to be boring, but fixing the bug #1063599 would be important, please take it a look
[14:24] <ubottu> Error: Launchpad bug 1063599 could not be found
[14:24] <EagleScreen> (it is a private bug)
=== slank is now known as slank_away
[14:30] <achiang> dholbach: FSOV "ready" :)
[14:31] <dholbach> :)
[14:34] <mhall119> dholbach: no, but I'll do it anyway ;)
[14:35] <dholbach> haha
[14:35] <dholbach> great
[14:35] <dholbach> sounds like we're all set :)
[14:40] <rperier> hi, this patch has been backported into raring ? https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1061063  , when I activate "Browsing" to "On" it does not work here, and I am running an up-to-date raring
[14:40] <ubottu> Ubuntu bug 1061063 in cups-filters (Ubuntu Raring) "[FFE] Reimplement automatic appearing of CUPS queues broadcasted by a remote CUPS server" [Critical,Fix released]
[14:41] <stgraber> ogra_: oops, sorry, didn't see the highlight until you mentioned it in #ubuntu-desktop :)
[14:41] <ogra_> heh
[14:41] <seb128> rperier, try asking tkamppeter
[14:41] <rperier> ok thanks
[14:42] <rperier> tkamppeter: ping
[14:42] <stgraber> ogra_: so what's surprising is that something brings it up on the nexus7. By default ifupdown (the network-interface jobs) won't bring up anything that's not defined in /etc/network/interfaces
[14:42] <ogra_> stgraber, *i* bring it up :)
[14:43] <stgraber> ogra_: so I'm vaguely suspecting that NetworkManager is what brings it up on the nexus7 and if so, you can work around it by putting "auto usb0" and "iface usb0 inet manual" in /etc/network/interfaces (so that ifupdown doesn't "up" the device and NM considers it managed)
[14:43] <ogra_> usbnet isnt modular so the kernel definitely creates that device on boot and i guess NM then picks it up but leaves it unconfigured
[14:43] <stgraber> ogra_: well, you create the device, but by default it'd be "down", NM brings it "up" (speaking of link state)
[14:43] <ogra_> stgraber, i wont mangle /e/n/i from a package :)
[14:44] <stgraber> ogra_: not from a package, but you can from the installer
[14:45] <ogra_> that will annoy everyone who gets it through an upgrade
[14:45] <ogra_> NM on the desktop you attach the n7 to really goes wild
[14:46] <ogra_> in a pretty nioisy manner
[14:46] <stgraber> yeah, but it's not limited to the nexus7, NM annoys me just as much with all my phones (nokia phones create a usb0 too) :)
[14:47] <stgraber> I think the right fix for this is to make NM only connect to usbX devices if asked to and not start doing DHCP whenever one shows up
[14:47] <stgraber> that'd fix the nexus7 thing and any other phone that creates a usb network interface
[14:47] <stgraber> (then if you actually want to connect to it, just click on the link in nm-applet)
[14:47] <stgraber> cyphermox: does that make sense to you? ^
[14:48] <cyphermox> it does
[14:48] <cyphermox> it's a request in a bug too
[14:48] <ogra_> awesome, so i dont need to add hacks :)
[14:48] <cyphermox> I guess it makes sense I can cook up a quick patch for this today I think
[14:49] <janimo> seb128, should gnome-settings-daemon be running by default in the unity-greeter? On a fresh boot I am at login but ps shows no g-s-d
[14:49]  * ogra_ knew it would be  good to ask :)
[14:49] <seb128> janimo, yes
[14:49] <cyphermox> ogra_: fwiw I'm all for the g_composite gadget
[14:49] <ogra_> already in :)
[14:49] <cyphermox> is the effective USB ID on PC going to be the same as it is now?
[14:50] <janimo> seb128, ok
[14:50] <ogra_> hmm, no idea
[14:50] <ogra_> might have changed with the driver
[14:50] <ogra_> is that important ?
[14:50] <seb128> janimo, you are sure you use the unity greeter?
[14:50]  * cyphermox looks at the driver
[14:50] <seb128> janimo, e.g not the gtk one?
[14:50] <cyphermox> ogra_: somewhat if you don't want MM to also try to probe it
[14:50] <ogra_> oh, i forgot
[14:50] <ogra_> yeah
[14:50] <stokachu> cjwatson: thanks for the added information on that installer issue
[14:51] <janimo> seb128, yes unity, but I see there was an unrelated error in Xsession startup that may have interfered, I'll restart and check again
[14:51] <ogra_> seb128, i think its quite visible if you use the gtk one and warp visually to 1995 :)
[14:51] <seb128> ;-)
[14:52] <cjwatson> np
[14:52] <seb128> janimo, unity-greeter/src/settings-daemon.vala has the code
[14:52] <seb128> janimo, it also has a
[14:52] <seb128> settings-daemon.vala:            debug ("Could not start gnome-settings-daemon over DBus: %s", e.message);
[14:53] <seb128> if it fails to start it (it tries to dbus active org.gnome.SettingsDaemon)
[14:53] <seb128> janimo, check the /var/log/lightdm/*greeter...log
[14:53] <ogra_> hmm, but shouldnt that be noticeable through the theme etc ?
[14:54] <ogra_> i assume it looks awful without g-s-d running
[14:56] <seb128> it should, be you would probably not notice it much from the greeter without using it
[14:57] <ogra_> cyphermox, oh, i noticed that my BT doesnt survive a suspend/resume cycle (well, BT does, but i cant re-connect devices) i suspect there is still some work left for later
[14:57] <seb128> like the background and the userlist are an image and cairo drawing
[15:00] <cyphermox> ogra_: yeah, I think if the patchram ever stops sendng the messages to make hci work, it can't pick it back up
[15:00] <cyphermox> I'll test this some more, but it's going to be tricky
[15:01] <cyphermox> ogra_: what driver do you use for the net interface with composite?
[15:01] <ogra_> we could make pm-utils unload the whole stack (or the parts of it needing to be newly initalized)
[15:01] <cyphermox> yeah guess so
[15:01] <ogra_> that will indeed slow down suspend :/
[15:01] <cyphermox> or maybe just stopping patchram and starting it again could be enough
[15:01] <ogra_> right
[15:02] <cyphermox> I mean, if it somehow gets to sending crap before the tty is ready to accept data
[15:03] <ogra_> cyphermox, the g_composite driver USB_CDC_COMPOSITE is the kernel option for it
[15:04] <cyphermox> yeah
[15:04] <cyphermox> but I mean, did you configure it already?
[15:04] <cyphermox> you need to somehow specific some magic things
[15:04] <ogra_> not beyond enabling it in the kernel
[15:04] <cyphermox> like, what interfaces you want it to do
[15:04] <janimo> seb128, indeed, such an error is logged in the greeter logs, no such service in any .service file. I may have botched something locally
[15:05] <ogra_> well, it does ttyGS0 and usb0 by default
[15:05] <cyphermox> hmm
[15:05] <janimo> I need to do a fresh install soon anyway
[15:05] <cyphermox> I must have misread then
[15:05] <cyphermox> oh well
[15:05] <ogra_> i tested serial and checked that i see usb0 on my PC when i plug it in
[15:05] <ogra_> i didnt actually set up a TCP connection though
[15:05] <seb128> janimo, do you have /usr/share/dbus-1/system-services/org.gnome.SettingsDaemon.DateTimeMechanism.service ?
[15:05] <cyphermox> what USB id does it have?
[15:06] <cyphermox> still 0525:whatever?
[15:06] <seb128> janimo, sorry, ignore that
[15:06] <janimo> seb128, yes, that file is there but I saw no other with the other service name
[15:06] <ogra_> Bus 002 Device 012: ID 0525:a4aa Netchip Technology, Inc. Linux-USB CDC Composite Gadge (Ethernet and ACM)
[15:06] <ogra_> yep
[15:06] <janimo> while debugging I ran g-s-d from the command line
[15:06] <cyphermox> ok
[15:06] <cyphermox> not quite the same but close enough
[15:07] <seb128> janimo, it's a bug, not a local issue, I will fix it ... g-s-d upstream dropped the dbus activation from g-s-d
[15:08] <seb128> janimo, http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-6&id=b778aad98bf5e1acc9899e757345dcee3a5294fd
[15:08] <seb128> janimo, we need to update unity-greeter to activate g-s-d differently (e.g just g_spawn the command)
[15:09] <janimo> seb128, ah ok
[15:09] <janimo> so when that is done we should probably get autorotation work in lightdm as well
[15:10] <seb128> cool
[15:10] <janimo> seb128, are gnome 3.8 components planned for 13.04?
[15:10] <seb128> no
[15:10] <seb128> well nothing in the stack components
[15:10] <seb128> we might take e.g new gedit eog evince
[15:10] <seb128> it depends if we decide to update gtk or not
[15:10] <seb128> but no news g-s-d or g-c-c
[15:11] <ogra_> nautilus ?
[15:11] <Laney> can someone check u-d-a and see if there's a call for votes from micahg waiting to be moderated please?
[15:12] <micahg> Laney: there's no
[15:12] <micahg> *not
[15:12] <janimo> Laney, I got the mail at least
[15:12] <Laney> you'll have had a ballot, yeah
[15:12] <janimo> but not on the ml
[15:12] <Laney> the call for votes shares the manifesto thingies
[15:13] <cjwatson> nothing in the u-d-a queue aside from a couple of spams
[15:14] <Laney> yeah, he confirmed ^ — expect it in a few minutes
[15:35] <tkamppeter> rperier, hi
[15:36] <micahg> cjwatson: message should be in the queue
[15:37] <rperier> tkamppeter: hi
[15:37] <cjwatson> micahg: accepted
[15:38] <micahg> cjwatson: thanks
[15:38] <rperier> tkamppeter: on raring (updated this morning) cups automatic browsing does not work, cups-filter and cups-browsed are installed
[15:39] <OdyX> tkamppeter: is that the bug that needs most recent cups which I should upload ?
[15:39] <tkamppeter> rperier, in Raring the mechanism has changed. The old CUPS broadcasting is replaced by Bonjour broadcasting. The server must be CUPS 1.6.x or Ubuntu with CUPS 1.5.x or higher. The server must have printer sharing turned on and also the individual printers must be set for being shared. The client is Raring with cups-browsed running.
[15:40] <rperier> the server does not run cups 1.6.x, it runs cups 1.5.x I guess
[15:40] <tkamppeter> OdyX, the most recent CUPS is for another bug, bug 1069671.
[15:40] <ubottu> bug 1069671 in cups (Ubuntu Quantal) "no print queues displayed in pure client mode" [Medium,Triaged] https://launchpad.net/bugs/1069671
[15:41] <tkamppeter> rperier, the server must do Bonjour broadcasting. Run avahi-discover on the client and see whether the server's printers appear there as "Internet Printer".
[15:47] <rperier> tkamppeter: I see "Unix Printer", "PLD Printer" and "Internet Printer"
[15:47] <rperier> PDL *
[15:50] <rperier> tkamppeter: however with evince, the list of printers is still empty
=== jono is now known as Guest7503
[16:03] <tkamppeter> rperier, can you restart cups-browsed on the client and see whether the printers appear in evince (or in the output of "lpstat -v"?
[16:04] <rperier> "lpstat: Transport endpoint is not connected"
[16:04] <rperier> :\
[16:05] <tkamppeter> Can you restart cups on the client?
[16:05] <rperier> already done
[16:05] <tkamppeter> rperier, do you have a file /etc/cups/client.conf?
[16:06] <rperier> no
[16:06] <tkamppeter> rperier, or ~/.cups/client.conf?
[16:07] <rperier> tkamppeter: no
[16:07] <rperier> :(
[16:07] <tkamppeter> rperier, do you have any local CUPS queues on the client?
[16:08] <rperier> no, it's just my personal laptop at work
[16:09] <tkamppeter> rperier, so backup all what is in /etc/cups, for example via "sudo tar -cvzf backup.tar.gz /etc/cups" and then run
[16:10] <tkamppeter> sudo dpkg -P --force-depends cups-daemon cups; sudo apt-get install cups-daemon cups
[16:12] <rperier> done
[16:12] <tkamppeter> rperier, does "lpstat -v" work now?
[16:13] <rperier> lpstat -v  => "lpstat: No destinations added."
[16:13] <rperier> output is different, work in progress :P
[16:17] <tkamppeter> OdyX, I have added another small fix on CUPS to the Debian GIT.
[16:17] <tkamppeter> rperier, now restart cups-browsed on the client.
[16:17] <OdyX> tkamppeter: I hope to have the french translation done by the end of the week.
[16:18] <rperier> tkamppeter: done, and I still get the same output
[16:19] <tkamppeter> rperier, is avahi-daemon running on both the server and the client?
[16:19] <rperier> on the client yes, on the server not sure
[16:20] <tseliot> cyphermox: all of our problems with the linux headers seem to be solved now. I think it's ok to approve my merge request now
=== megha is now known as firewall
[16:27] <cyphermox> tseliot: ack
[16:28] <tseliot> cyphermox: thanks!
[16:36] <rperier> tkamppeter: I will ask my sysadmins about the server, thanks for your help!
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[17:42] <cjwatson> pitti: https://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/revision/628 - do you happen to remember why you removed "g_object_set_data (G_OBJECT(ta->tray_icon), "notification", n);"?
[17:42] <cjwatson> pitti: Is it no longer meaningful to keep a handle for the notification around to close it, or something?
=== dpm-laptop is now known as dpm
[18:00] <rbasak> doko: could you please take a look at bug 1073147? Quite a few people are reporting that it's an error and not just a warning now. Do we need to SRU a no-change rebuild or something?
[18:00] <ubottu> bug 1073147 in libapache2-mod-python (Ubuntu) " Python version mismatch, expected '2.7.2+', found '2.7.3'" [High,Confirmed] https://launchpad.net/bugs/1073147
[18:22] <doko> rbasak, no change rebuild sounds fine
[18:23] <rbasak> OK, thanks
[18:32] <stokachu> bdmurray: ping
[18:32] <bdmurray> stokachu: hi
[18:32] <stokachu> bdmurray: hey man :)
[18:33] <stokachu> bdmurray: i've got a case if you got a chance to look at (SRU)
[18:33] <stokachu> its getting some attention and need to get some traction on it
[18:33] <stokachu> bug 1101371
[18:33] <ubottu> bug 1101371 in walinuxagent (Ubuntu) "[SRU] Integrate v1.3 of Windows Azure Linux Agent" [Medium,Triaged] https://launchpad.net/bugs/1101371
[18:35] <bdmurray> stokachu: does this need sponsoring or approving in the SRU queue?
[18:35] <stokachu> looks like it needs both at this time
[18:35] <stokachu> bdmurray: do you want me to have the owner provide a debdiff for upload?
[18:35] <stokachu> looks like they only linked their branches to the case
[18:36] <doko> infinity, apw: is the removal of 'struct siginfo' in 3.8 intentional?
[18:37] <bdmurray> stokachu: that'd help
[18:38] <stokachu> bdmurray: ok ill get them to do that now
[18:40] <stokachu> bdmurray: bah the owner is off this week, im going to build these diffs, mind if i ping you when im done?
[18:42] <mlankhorst> well I've got proof nobody ran wine64 on valgrind yet
[18:42] <mlankhorst> :D
[18:43] <bdmurray> stokachu: nope
[18:44] <stokachu> cool thanks
[18:56] <smoser> psusi, will / would 'blockdev --rereadpt' on a re-written partition table cause the kernel to update its view?
[18:57] <ogra_> thats its purpose, no ?
[19:00] <smoser> well, i was asking specifically wrt partitions that have been updated like with parx at http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commitdiff;h=3b905b794e93609af7e42459d32b27e7c18ce02e
[19:00] <smoser> oh...
[19:00] <smoser> i know why it might not.
[19:01] <smoser> blockdev int he past would REREAD ioctrl which kernel would deny
[19:01] <smoser> if there were mounted filesystems on that device.
[19:01] <smoser> but psusi tells me now that i can grow a mounted partition and tell the kernel about that.
[19:05] <ogra_> yeah
=== Quintasan_ is now known as Quintasan
[19:14] <Quintasan> Laney: Well, I'll take a look at the packaging later but I don't think I have any changes to add there. As for the Debian mainter I'd like to be the primary maintainer. Gotta start contributing to Debian at some point at this seems like a good ocassion.
[19:19] <Quintasan> Laney: By the way, any huge mistakes there? I'm almost done with plugins packaging so I'd like you to take a look at those later.
[19:27] <xkernel> how to create deb package from scratch for existing project?
=== Amoz_ is now known as Amoz
[20:13] <psusi> smoser, right, hence the kernel and other patches
[20:14] <psusi> smoser, BLKRRPART won't work if any partitions are open
[20:24] <infinity> doko: No idea about the signinfo thing, a kernel git log might help (or Andy).
[20:26] <infinity> doko: But, speaking of backward compatibility things, have you fixed and rebuilt all the compilers that need rebuilding so I can drop local-revert-bz13979.diff from eglibc (the FORTIFY_SOURCE / optimization warning)?
=== henrix is now known as henrix_
[21:12] <Laney> Quintasan: Aye aye. I'll admit that I don't really know what you did with xinput.d ;-)
[21:12] <Laney> I think the biggest issue (if I'm not mistaken on that) was the library package being named wrongly
[21:13] <Laney> and I'm not sure the symbols file is a good idea - it seems pretty brittle
[21:31] <slangasek> Laney: what's this about symbols files being brittle?
[21:31] <Laney> slangasek: C++ ones
[21:31] <slangasek> ah, yeah
[21:31] <slangasek> they certainly can be
[21:31] <slangasek> I think Russ Allbery's analysis is canonical there
[21:31] <Laney> http://www.eyrie.org/~eagle/journal/2012-01/008.html
[21:32] <Laney> ha, yeah, that
=== salem_ is now known as _salem
[21:49] <cody-somerville> ev: Happy Birthday! :)
=== firewall is now known as megha
=== _salem is now known as salem_
[22:13] <bdmurray> slangasek: digging around in update-notifer I've discovered that it wants to call gnome-app-install in some cases (when it finds an "addon" CD)
[22:15] <slangasek> bdmurray: is that a command?  I don't seem to have gnome-app-install here
[22:15] <cjwatson> I think addon CDs are historical; that was Edubuntu at one point
[22:15] <cjwatson> gnome-app-install used to be a package
[22:15] <bdmurray> slangasek: I believe it last appeared in karmic
[22:15] <cjwatson> Removed in lucid
[22:15] <slangasek> ok
[22:15] <cjwatson> https://launchpad.net/ubuntu/+source/gnome-app-install/+publishinghistory
[22:15] <slangasek> bdmurray: so it's dead code and should be pruned, I guess?
[22:16] <cjwatson> I think so.  It has quite a lot of tentacles though so try to get them all :-)
[22:16] <bdmurray> Based off cjwatson saying they are historical I'd say yes
[22:17] <cjwatson> Edubuntu stopped using addon CDs in I think jaunty
[22:17] <cjwatson> no, karmic
[22:19] <bdmurray> And it seems nobody else has complained about support being missing so away it will go.
[22:38] <ritz> hi, looking to push for an sru - https://bugs.launchpad.net/ubuntu/+source/unity/+bug/806248
[22:38] <ubottu> Ubuntu bug 806248 in unity (Ubuntu Precise) "unity::TimeUtil::TimeDelta returns an int value which overflows after 24 days of uptime" [High,In progress]
[22:39] <infinity> That still isn't fixed in precise? :/
[22:40] <arges> infinity: nope. branches are linked and ready
[22:40] <cjwatson> What else is in this SRU?
[22:41] <arges> I think the merge request just needs to reviewed/accepted
[22:41] <infinity> arges: There seems to be a followup about your merge requests.
[22:41] <cjwatson> I agree that bug is serious; if it's just that one change, I'd grant it an exception
[22:42]  * infinity nods.
[22:42] <arges> infinity: it was an answer to a question about the process.
[22:42] <arges> infinity: i did a debdiff, but a bzr merge was requested, and I messed that up  : ) to timo did a proper merge request
[22:43] <infinity> I'm inclined to disgaree that, in general, MPs are preferred over diffs, but I don't want to get into an argument in the bug comments. :P
[22:44] <tjaalton> oh that's the bug I was seeing..
[22:44] <infinity> (I also just get annoyed as a matter of principle when people argue that the format of a patch, rather than the content, is "wrong")
[22:45] <infinity> arges: I assume this is unity-specific, and doesn't affect unity-2d?
[22:46] <arges> infinity: i'm not sure. this is the first unity bug i've looked at
[22:46] <arges> i thought unity-2d was derived from unity?
[22:47] <infinity> Only in name.
[22:47] <cjwatson> And design.
[22:47] <cjwatson> The actual code is (AIUI) largely independent.
[22:47] <infinity> They're completely different codebases, one being a compiz plugin, and the other abusing metacity.
[22:48] <arges> well don't see anything a bug search
[22:49] <arges> looking for similarly named files
[22:49] <bregma> 806248 is unity-specific:  it's scheduled to go in with the regular 12.04 unity/compiz SRU in February
[22:50] <arges> does look like it even uses TimeUtil::TimeDelta so I would guess it isn't affected
[22:50] <infinity> bregma: Do you think it's worth a cherry-pick SRU for 12.04.2?
[22:51] <xxiao> how can I add a new arch to ubuntu?
[22:51] <infinity> bregma: (Colin and I are certainly inclined to accept it)
[22:51] <infinity> xxiao: Which arch would that be?
[22:51] <xxiao> tried bootstrap debian for a new arch in the past, PITA
[22:51] <xxiao> infinity: 64bit freescale powerpc chip
[22:52] <bregma> infinity, that's really up to the distro guys, certainly the patch is already in 12.10 and raring so it's well tested
[22:52] <infinity> xxiao: If you just mean the kernel side, talk to BenC.  He's already on top of things with the 32-bit fsl ppc stuff.
[22:52] <bregma> I have no objection to a cheryy-pick SRU
[22:52] <infinity> xxiao: If you mean a ppc64 userspace, that's probably not going to happen (and largely a pointless endeavour, ppc32 userspace on ppc64 kernels is saner)
[22:54] <xxiao> infinity: actually for kernel it's less urgent, the ubuntu rootfs is more interesting
[22:54] <infinity> xxiao: Except that Ubuntu's userspace already supports your processor, so we're done. ;)
[22:54] <xxiao> we're trying to do some enterprise level data center stuff with the 64bit ppc
[22:54] <xxiao> infinity: are you sure about that on e5500/e6500 ppc?
[22:55] <infinity> xxiao: Quite sure, except for kernels and installers.
[22:55] <cjwatson> Not wanting to be blunt, but a new architecture involves substantial enough outlay of time, effort, and money that it's unlikely to happen without some kind of contractual arrangement with Canonical
[22:55] <infinity> xxiao: It's a common misconception that you need (or even want) a 64-bit userspace on 64-bit CPUs.
[22:55] <xxiao> i used that on e500 machines and got some floating point issues in the past, but e5500/e6500 does have the legacy ppc FPU now
[22:56] <xxiao> i mean i used the default debian rootfs in the past
[22:56] <infinity> xxiao: If you had/have FPU issues on e500, please, file bugs against the affected packages.
[22:56] <cjwatson> (We've looked at ppc64 before, but it needs that kind of support to have it in Ubuntu)
[22:57] <xxiao> without 64bit userspace for data-centric usage 32bit might not be enough
[22:59] <xxiao> cjwatson: what kind of support?
[22:59] <xxiao> debian's ppc64 efforts only work for ppc64 with VMX
[23:00] <infinity> xxiao: 15:55 < cjwatson> Not wanting to be blunt, but a new architecture involves substantial enough outlay of time, effort, and money that it's unlikely to happen without some kind of contractual arrangement with Canonical
[23:00] <infinity> xxiao: That kind of support.
[23:00] <xxiao> infinity: that's very likely, i'm doing some pilot study here first
[23:01] <infinity> xxiao: Still, I'm going to continue arguing that you probably don't actually need a 64-bit userspace (except, possibly, the occasional application built with 64-bit support).
[23:03] <xxiao> infinity: for now i will actually have to use 32bit rootfs
[23:03] <infinity> xxiao: Which should work fine, as I said.  If you bump into bugs, please do file them.
[23:03] <cjwatson> I will say that if there were ever commercial backing for it then some of us do actually enjoy bringing up ports
[23:04] <infinity> Yes, some of us do. :)
[23:04] <infinity> And some of us have a soft spot for PPC too.
[23:04] <xxiao> we never had e500 full support as far as i know due to its "new" fpu, but we return to the non-e500 ppc so the 32bit rootfs should work at least
[23:04] <cjwatson> But with the requirements that Launchpad builders be in the data centre and that the initial tarballs be highly trusted, it isn't really something third parties can do (well, obviously you could in principle run a parallel set of builders if you wanted to, but to have it actually part of Ubuntu ...)
[23:05] <infinity> xxiao: Well, we have e500 kernels and supposedly support it, so it would be nice to know what these issues were that you were seeing.
[23:05] <xxiao> infinity: i thought everyone is leaving ppc for ARM nowadays :)
[23:05] <cjwatson> Some of us *personally* have a soft spot for ppc, which isn't quite the same :)
[23:06] <xxiao> http://pureperl.blogspot.com/2011/10/debian-powerpc-e500v2-port-part-5.html
[23:07] <xxiao> for ppc there are always some little instruction difference
[23:07] <xxiao> for e500 with standard debian we had issues with floating points in the past
[23:07] <cjwatson> Cross-compiling of packages is getting a lot easier thanks to work being done mainly for ARM
[23:07] <infinity> xxiao: That's Debian, not Ubuntu.  Just sayin', Servergy has e500 machines that they run Ubuntu on.
[23:07] <cjwatson> https://wiki.ubuntu.com/CrossBuilding
[23:07] <cjwatson> https://wiki.ubuntu.com/CrossBuilding/BuilddChroot
[23:08] <cjwatson> And similar efforts in Debian
[23:08] <xxiao> infinity: yeah i am now working with servergy guys :)
[23:08] <cjwatson> Most of this stuff is fairly architecture-independent once you have a cross-toolchain - and there's a powerpc cross-toolchain in raring
[23:08] <infinity> xxiao: Then I suggest talking to BenC about the issues you've seen.
[23:09] <cjwatson> (ok, not ppc64)
[23:09] <infinity> cjwatson: We have a ppc64 cross toolchain too.
[23:09] <infinity> cjwatson: (The cross is bi-arch)
[23:09] <xxiao> we have the toolchain built from yocto
[23:09] <xxiao> will find BenC
[23:10] <cjwatson> xxiao: multiarch cross toolchains are slightly different
[23:10] <xxiao> cjwatson: that's still been worked on indeed
[23:10] <cjwatson> you want the multiarch configuration so that cross-building packages stands a chancec
[23:10] <infinity> Our toolchain is slightly different in general.  I don't tend to recommend crossing for Ubuntu with some other random toolchain.
[23:11] <cjwatson> infinity: mm, I expect that if we actually wanted to do cross-building to ppc64 we'd want a gcc that defaulted to it, rather than it merely being an -m64 choice
[23:11] <infinity> cjwatson: Oh, for ppc64 the Debian arch, yes.
[23:11] <cjwatson> the latter's fine for one-offs but not much use for crossing at scale
[23:11] <infinity> cjwatson: But for ppc64, the compilation target, a biarch cross works fine.
[23:11] <cjwatson> yeah
[23:13] <infinity> Dangit.  Missed the post-copy-pre-publish window to promote linux-ppc back to main.
[23:15] <cjwatson> really.  really.  really must fix that bug.
[23:15] <infinity> Yeah.  It's merely annoying busywork most of the time, but it's pretty heinous when it does things like subtly move binaries from multiverse to universe and we don't notice.
[23:19]  * xnox is yet to participate in bringing up a new arch
[23:24] <infinity> xnox: I've only been involved in 5 or 6.
[23:25] <infinity> xnox: You might not be missing out on much.  Some people find it an awful process.  Me, I live for awful, cause I'm a software masochist.
[23:25] <xnox> infinity: hmm... did all of them make it? but i guess that doesn't really matter as rootfs and builders are done at that point.
[23:26] <infinity> xnox: All of the ones I did for Ubuntu made it, to some degree or other, though many are becoming deprecated now.
[23:27] <infinity> No love lost between lpia and I, good riddance to it in April.
[23:30] <xxiao> what about the AARM64 support
[23:32] <xxiao> looks like ARM sponsored linaro who then sponsored cannonical to do that
[23:32] <infinity> xxiao: aarch64 or arm64, not aarm64. :)
[23:32] <sarnold> "International Packaged Ice Association"? "International Pipe Inspectors Association"?
[23:32] <xxiao> aarh...
[23:33] <infinity> xxiao: And the relationships are a bit muddier than that, even, but yes, it's in progress.
[23:33] <infinity> sarnold: That's LPIA, not IPIA.
[23:33] <cjwatson> Don't expect people to spell out exactly who's paying whom how much in public, though.
[23:33] <sarnold> infinity: ah! I missed that pixel. :)
[23:33] <xxiao> wookware.org/talks/arm64linuxconf2012.pdf
[23:34] <cjwatson> Yeah, we know, we work with wookey regularly
[23:34] <xxiao> most ARM can not even handle 1G port...and we're all talking about arm64 server nowadays
[23:34] <infinity> cjwatson: So, I shouldn't tell people that I'm being sponsored by my neighbour to fix bugs in sl?
[23:34] <cjwatson> infinity: If you've signed an NDA with your neighbour, that's your look-out
[23:35]  * xxiao looks the ppc board that has 4x10G ports on the bench
[23:35] <infinity> cjwatson: I did, but then I ate it.  So, it doesn't count, right?
[23:36]  * infinity loves that command-not-found recommends installing sl when you typo ls or have your caps-lock on.
[23:36] <infinity> I wonder how many people do...
[23:37] <xxiao> INFO: rcu_sched_state detected stall on CPU 21 (t=15000 jiffies)  sigh
[23:37] <xxiao> another kernel lockup