[00:03] <RAOF> ion: In an ideal world, yes. In the real world different renderers support different GL extensions (or GL versions), and exporting all GL extensions that can be implemented in software is user-hostile.
[00:04] <slangasek> RAOF: ah, heh.  Thanks for the explanation, I'd completely forgotten the name AIGLX :)
[00:04] <ion> How about exporting all GL extensions but telling the user which ones are hardware-accelerated?
[00:05] <RAOF> GL doesn't support that :)
[00:05] <ion> A Mesa extension? :-P
[00:06] <slangasek> ion: to what end?  when would you have more than two drivers in practice - one accelerated, one sw?
[00:07] <slangasek> I think the problem here is some oddball driver loaded that doesn't implement the bits that mesa's in-tree drivers do, no?
[00:08] <RAOF> That's one possible problem, yes
[00:08] <slangasek> so even if mesa had awesome support for proxying unsupported extensions over to the llvmpipe swrast driver, that doesn't help if you're not using a mesa driver to begin with, I think
[00:09] <slangasek> btw, did linaro's gles proxy lib ever manifest?
[00:10] <slangasek> (which, er, was supposed to handle exactly this sort of thing)
[02:40] <jdstrand> barry: re ufw> yep, as of 0.32
[03:32] <pitti> Good morning
[03:33] <ajmitch> hi pitti
[04:28] <SpamapS> any reason not to upgrade a precise box to quantal right now?
[04:29] <micahg> SpamapS: qemu-kvm has some issues
[04:29] <micahg> libreoffice has no menus in non-unity envs
[04:39] <SpamapS> yeah I briefly looked at the critical bugs
[04:39] <SpamapS> just sometimes people say NO WAYT THEARCHIVE IS BZORKEN when I do that ;)
[04:40] <micahg> SpamapS: the archive is frozen ATM :)
[05:04] <ahsan> hi all
[05:05] <ahsan> i wanted to write an upstart job which kicks in just before halt/reboot.
[05:05] <ahsan> any pointers on how to do that
[05:06] <ahsan> I tried with "start on runlevel [06]". But, I guess that starts as soon as runlevel 0 or 6 is reached
[05:06] <RAOF> Right.
[05:07] <RAOF> At what point in the shutdown process does it need to run? If it's ‘just as FOO is shutting down’, then ‘start on stopping $FOO’ would get you something like that.
[05:07] <ahsan> yeah, i was looking for something like that..
[05:08] <ahsan> like a S89mytask in rc6.d for sysV
[05:10] <RAOF> You can of course just have a sysv task if you want; upstart supports it.
[05:11] <ahsan> RAOF: ok, just wanted to do it the upstart way.
[05:11] <RAOF> There probably is an event you can start on.
[05:11] <ahsan> yes, I was looking for that event. like you said "start on stopping foo"
[05:12] <ahsan> I am looking for that foo
[05:15] <RAOF> So when does it need to run?
[05:15] <ahsan> just before the halt/reboot is issued
[05:37] <SpamapS> ahsan: what exactly do you want it to stop after?
[05:38] <SpamapS> ahsan: shutdown has a very specific order.. stop services, kill processes, unmount network filesystems, stop networking, kill off straggler processes, unmount filesystems, halt/reboot
[05:44] <SpamapS> ahsan: for instance, a few things do need to be stopped between unmounting network filesystems, and stopping networking. For those, 'stop on deconfiguring-networking' is a good choice, as it will block the shutdown until those things are stopped.
[05:53] <SpamapS> ugh, touchpad on MBA 4,1 is not working now
[05:59] <ahsan> SpamapS: thanks, will give it a try
[05:59] <ahsan> SpamapS: I wanted to just delete a marker, as late as possible
[06:00] <cc11rocks> Can I delete a patch sent to Debian?
[06:00] <SpamapS> ahsan: so you have to do it before filesystems are unmounted
[06:00] <cc11rocks> I accidentally submitted a duplicate to someone else's fix...
[06:02] <ahsan> SpamapS: ok, can you please tell the syntax
[06:07] <ahsan> SpamapS: "start on starting mountall" will be a race condition?
[06:08] <SpamapS> ahsan: mountall is started during the system boot. I thought you wanted on shutdown
[06:09] <ahsan> SpamapS: oh, you're right. sorry
[06:10] <ahsan> SpamapS: btw, when does mountall stops? .. also, which task handles unmounting filesystems?
[06:10] <SpamapS> ahsan: there's no event, currently, attached to unmounting filesystems, but you could either a) push it back to just before networking is deconfigured, or b) add the event to /etc/init.d/umountfs
[06:11] <SpamapS> ahsan: mountall never stops IIRC
[06:11] <SpamapS> ahsan: unmounting is done by /etc/init.d/umountfs
[06:12] <ahsan> SpamapS: thanks
[06:17] <ahsan> SpamapS: which event is emitted when networking is disconfigured
[06:18] <ahsan> ie "start on stopping foo" .. whats foo here? or disconfiguring-network itself is an event which is emitted?
[06:18] <ahsan> /s/disconfigured/deconfigured
[07:00] <dholbach> good morning
[07:07] <dholbach> bdrung, AFAICS ubuntu-packaging-guide is ready for upload :)
[07:16] <MCR1> didrocks: I noticed some important python applications do not work on Quantal (they all fail with the same error: Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)' failed) - who can/should I nerve with this ?
[07:16] <MCR1> didrocks: examples are qbzr or trimage packages...
[07:17] <tsdgeos> it happened again, a bug i just reported got duplicated of a private one https://bugs.launchpad.net/ubuntu/+source/colord/+bug/1046690 and https://bugs.launchpad.net/bugs/1038768
[07:17] <didrocks> MCR1: those are using pygtk or pygi?
[07:17] <tsdgeos> can someone mark the second public and tell me where i open a bug so that this doesn't happen again?
[07:18] <MCR1> didrocks: qbzr says it depends on python-qt4, python2.7
[07:19] <tsdgeos> MCR1: yeah having the same problem :-/
[07:19] <didrocks> MCR1: ok, are all python applications having this kind of gtk warning qt apps?
[07:19] <didrocks> I wonder if it's not just the qt -> gtkstyle binding which is broken
[07:21] <MCR1> didrocks: trimage is also depending on python-qt4 and python >= 2.6
[07:21] <MCR1> didrocks: I am not sure if all have this kind of warning, but many python applications work, while those 2 don't anymore, while at least trimage was working on Precise
[07:22] <MCR1> but I guess qbzr also works there...
[07:23] <MCR1> tsdgeos: Which python applications are creating this problem for you ?
[07:31] <tsdgeos> MCR1: to be honest i'm only using qbzr
[07:31] <didrocks> MCR1: so, I would say it's a Qt issue to not work with latest GtkStyle, maybe some people are knowledgeable on #kubuntu-devel
[07:33] <MCR1> didrocks: ok, I'll ask there. Thx. After all qbzr is a quite important tool for Ubuntu development as there is no real replacement I know of (bzr explorer is slow and buggy)
[07:34] <tsdgeos> it seems someone decided to break qt on quantal, assistant is also crashing on startup :D
[09:15] <brendand> does anyone know why i might be seeing:
[09:15] <brendand> Qt: Session management error: None of the authentication protocols specified are supported
[09:15] <brendand> in Precise (12.04.1)?
[09:16] <brendand> i read something about no X server - which couldn't be possible
[09:16] <cjwatson> barry: http://en.chys.info/2011/11/a-problem-with-pipes-in-python-3/ - gotcha, possibly worth mentioning somewhere.  Note my comment
[09:17] <cjwatson> Relevant if you do things like  subp = subprocess.Popen(blah, stdout=subprocess.PIPE); for line in subp.stdout:  without universal_newlines=True
[09:18] <cjwatson> Because now it defaults to unbuffered for byte streams
[09:25] <zyga> pitti, https://plus.google.com/116315264177593873442/posts/aQq8vV7gUnE :-)
[09:32] <pitti> hey zyga
[09:33] <pitti> zyga: ah, nice! this looks similar to what "apport-bug storage" is doing
[09:33] <zyga> pitti, cool, I didn't know that
[09:33] <pitti> zyga: hm, wouldn't it be easier to run udisksctl monitor? or is that missing some signals?
[09:33] <zyga> pitti, I'll be using that to port checkbox to udisks2
[09:33] <zyga> pitti, no, it's just something I wrote for this task, the code is shared with checkbox actually
[09:33] <pitti> zyga: anyway, if it helps, it should build just fine on precise, so we can put it into a PPA or so
[09:34] <zyga> pitti, hmm, udisks2 in precise ... it might be cool but then again some things (mounting) will still happen via udisks1
[09:34] <zyga> pitti, I'll think about it but the focus right now is to get results from standard installs
[09:35] <pitti> makes sense
[09:35] <zyga> pitti, so that we have predictable behavior in practice
[10:43] <xnox> mpt: what is your opinion on tooltips? bug 1045799
[10:43] <mpt> KILL THEM ALL
[10:43] <mpt> KILL THEM WITH FIRE
[10:43]  * mpt reads the bug report
[10:46] <nigelb> lol
[10:49] <mpt> xnox, is <https://launchpadlibrarian.net/114858452/result.png> how it looks with the default theme?
[10:49] <mpt> Those are some weird icons.
[10:49] <mpt> Wait, that isn't even the installer, that's GParted!
[10:54] <xnox> mpt: so I did change "Add partition","Remove partition", "Edit partition" to symbolic icons "+","-","cog"
[10:54] <mpt> xnox, may I see a screenshot?
[10:54] <xnox> mpt: now I am confused if people are confused about Gparted or Ubiquity.
[10:54] <xnox> mpt: one moment.
[10:56] <cjwatson> I suspect Erick is confused in ways that jibel is not.
[10:56] <xnox> mpt: i really want the "Pencil" icon, instead of/in addition to a "cog"
[10:59] <mpt> xnox, I specced "Change..." as text: https://docs.google.com/a/canonical.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/edit#heading=h.6zratkhfgk60
[10:59] <xnox> mpt: I was naughty =)
[11:38] <bdrung> dholbach: done.
[11:38] <dholbach> thanks bdrung! :)
[11:46] <mpt> xnox, I don't know why you'd add tooltips post-UIF but not just switch to the specced label post-UIF
[11:48] <xnox> mpt: here is link how it currently looks like https://picasaweb.google.com/lh/photo/jsf4RKjSfg6IKFMoShVwtlh0btKKriD5FR8jiayHfxc?feat=directlink
[11:48] <xnox> mpt: I personally hate tooltips and status bars with passion
[11:49] <mpt> xnox, why don't the buttons have borders?
[11:49] <xnox> mpt: also the right click menus
[11:49] <xnox> mpt: ask the theme designers =/
[11:49] <xnox> mpt: the border appears on mouse-over
[11:49] <mpt> Are you sure this is a theme issue?
[11:49] <xnox> mpt: the onces on the right are "button box" the onces on the left is "toolbar"
[11:49] <mpt> Does the theme say "whoa, this button has only an icon in it, I'm dropping the border"?
[11:50] <mpt> xnox, ok, well don't do that then, use a normal button :-)
[11:50] <xnox> mpt: I was naughty =) menubar is the easiest / quickest way to get symbolic icons, but I couldn't get mixed labels/icons in the same toolbar.
[11:51] <xnox> mpt: =)))))
[11:51] <mpt> My designs can take only so much abuse before they break, you know.
[11:51]  * xnox LOL
[11:52] <xnox> mpt: ok. What about the size of the + and - ? big enough? just right? too small?
[11:54] <mpt> xnox, looks right to me.
[11:54] <xnox> mpt: let me change it to what it was suppose to be and then I'll give you another screenshot.
[11:54] <mpt> ok
[13:25] <tjaalton> ppa queue ~7h..
[13:44] <SpamapS> hm, seems xserver-xorg-input-mtrack has restored my trackpad
[13:44] <SpamapS> tho I seem to recall having lots of other problems with this driver
[13:45] <tjaalton> restored how?
[13:48] <SpamapS> tjaalton: with evdev, I get no working trackpad
[13:51] <tjaalton> SpamapS: ok
[13:52] <SpamapS> bug 1046675 btw :)
[13:53] <tjaalton> well I've got xserver 1.13 ready, but nowhere to build it
[13:53] <tjaalton> since half the builders are idle or offline, queue ~7h
[13:58] <barry> cjwatson: yes, that does seem unfortunate.  at least it's documented though ;)  http://docs.python.org/py3k/library/subprocess.html and search for 'bufsize'
[14:13] <mpt> ev, should configuration file prompts in upgrades (bug 86028) be considered errors like debconf prompts? What do you think?
[14:14] <ev> mpt: I'm inclined to say yes, but we should chat with someone who knows conffiles better than I do.
[14:26] <stgraber> pitti: I'm not an archive admin, so can't commit to ubuntu-archive-tools
[14:26] <slangasek> mpt: a conffile prompt for a conffile that the user didn't edit is an error; a conffile prompt for a conffile that they did is the standard conflict resolution method; there's no way for us to tell the difference from an automated report
[14:26] <pitti> stgraber: ah, I thought as ~ubuntu-release you were
[14:28] <stgraber> pitti: ~ubuntu-release now has direct queue admin rights on <dev> and <dev>-proposed, so I can accept packages but I'm not in ~ubuntu-archive
[14:29] <mpt> slangasek, what would we need to change to make them distinguishable? (store the modification date somewhere? or a hash value?)
[14:29] <slangasek> mpt: there's nothing you can do
[14:29] <slangasek> it's *either* a user modifying it, *or* it's software going rogue and modifying it
[14:30] <slangasek> you can't distinguish these unless you know what software is going rogue, e.g. by reproducing it in an autotest
[14:32] <bdmurray> barry, pitti: could one of you review an aptdaemon merge proposal? https://code.launchpad.net/~brian-murray/aptdaemon/bug-875879/+merge/122979
[14:53] <pitti> url 1
[14:53] <pitti> oops
[14:55] <pitti> bdmurray: seems fine to me, thanks
[15:11] <bdmurray> pitti: are you going to upload aptdaemon then? also do you have any ideas for an SRU test case for this?
[15:11] <pitti> we are still frozen anyway, and mvo is working on a few branches which I guess he'd want in soon as well, so I guess he'll do an upload soon
[15:15] <mvo> yeah, I would love to get a new version in on friday
[15:16] <bdmurray> mvo: do you have an idea of an sru test case for bug 875879?
[15:20] <shadeslayer> cjwatson: you mentioned a couple of days ago that something was misbuilt
[15:21] <cjwatson> I fixed it
[15:21] <cjwatson> https://launchpad.net/ubuntu/+source/syslinux-themes-ubuntu/5
[15:21] <cjwatson> That was the cause of the iso-hybrid failures in live-build
[15:27] <mvo> bdmurray: hm, we could have to find a package that changes the conffile during a upgrade, I could try to fabricate something
[15:29] <BenC> Laney: haskell-hint builds on ppc, and it looks like it's restrictions on architecture are based solely on needing ghci. Should I set it to Arch: any and update the build-deps to use ghc-ghci?
[15:35] <mvo> bdmurray: hrm, hrm, so I created a artifical conffile prompt, but couldn't trigger the bug with it
[15:36] <bdmurray> mvo: with quantal or precise? errors.ubuntu.com doesn't show any quantal versions of the error for some reason
[15:37] <mvo> bdmurray: tested on my precise box
[15:39] <dholbach> can somebody please reject https://code.launchpad.net/~ianrob1201/ubuntu/quantal/libmoosex-semiaffordanceaccessor-perl/typo-fix/+merge/122370?
[15:40] <BenC> Laney: …so that seemed to the the correct way to handle it based on other packages, I've uploaded that change
[15:40] <bdmurray> mvo: that seems strange
[15:40] <dholbach> https://code.launchpad.net/~radumstoica/ubuntu/quantal/libnss-pgsql/typo-fix/+merge/122383 too please
[15:41] <BenC> Laney: And after that, it seems the transition is basically done for powerpc (two dep-waits that will eventually trigger today sometime)
[15:41] <mvo> bdmurray: I put info how to reproduce into the bugreport now, its a artificial thing that should only be done in a VM
[15:42] <bdmurray> mvo: okay, thanks I'll have a look in a bit
[15:42] <mvo> bdmurray: its really odd, the conffile is there and all but the diff looks valid instead of crashing
[15:42] <xnox> does update-manager -d work against a local mirror?
[15:43] <xnox> as in, when there is no network to archive.ubuntu.com
[15:43] <xnox> but there is to some other official mirror
[15:43] <mvo> xnox: if the mirror is the only server then yes, if you mix it with a official mirorr it will ocmment the local one out
[15:43] <BenC> infinity: Is ghci segfaulting on arm?
[15:43] <xnox> mvo: what if the official one times-out?
[15:44] <xnox> mvo: or otherwise inaccessible? e.g. blocked by firewall?
[15:44] <mvo> xnox: I'm not sure, but I don't think its very clever in this case and will just fail
[15:44] <xnox> mvo: ok.
[15:48] <BenC> Is anyone able to give me shell access to an arm box so I can try to fix ghc?
[15:50] <tumbleweed> BenC: http://arm.trystack.org/ <- public access to the calxeda machines
[15:50] <tumbleweed> (takes a while to get an account, but I can spin one up and give you acesss to it, if you want)
[15:50] <BenC> Thanks, I think I'll actually just fire up a qemu
[15:51] <tumbleweed> yaeh, that works well enough for ARM
[15:52] <mpt> ev, interesting how errors.ubuntu.com has a spike in errors/day during the weekends, but trunk has a dip in the weekends.
[15:52] <ev> hmm, nice spot
[15:53] <mpt> (In both cases the pattern might be clearer if they were PDT or CT days rather than UTC -- not that that means you should switch.)
[15:53] <ev> some day we'll calculate it by hour
[15:53] <ev> and let you zoom in
[15:53] <ev> ah
[15:53] <ev> I guess that doesn't help here
[15:55] <xnox> mpt: buttons as per spec: https://picasaweb.google.com/lh/photo/IX7RCztyVR5RU0OPsX2CXVh0btKKriD5FR8jiayHfxc?feat=directlink
[15:56]  * xnox is dissappointed that (a) gtk does not have symbolic stock buttons (b) that I couldn't simply use + and - ascii characters for those "labels" and had to hack together symbolic image with empty text label next to it
[15:57] <mpt> xnox, better, thanks. Someday we'll have buttons smart enough to glob together (like USC's Back and Forward buttons) if you put them right next to each other.
[15:57] <mpt> A really smart theme could do that.
[15:58] <xnox> mpt: well that was one reason I used toolbar buttons originally, naïvely thinking they'd do the globbing
[15:58] <zyga-w510> cr3, http://pastebin.ubuntu.com/1189171/
[15:58] <cr3> zyga-w510: sweet, thanks man!
[15:59] <xnox> mpt: although in System Settings we have globbing! Open System Settings -> Appearance and notice that (all settings|appearance)
[16:00] <shadeslayer> cjwatson: awesome, thanks :)
[16:00] <xnox> mpt: I am committing this for now, can do globbing later.
[16:00] <cr3> zyga-w510: so, your Wacom ISDv4 E2 Finger touch doesn't seem to be detected as a multitouch device. is it appearing in the System Settings -> Wacom Graphics Tablet?
[16:00] <shadeslayer> let's see if it works
[16:00] <zyga-w510> cr3, yes
[16:00] <zyga-w510> cr3, it's dual touch technically
[16:01] <cr3> zyga-w510: technically, but it's not currently working as mutitouch, right?
[16:01] <zyga-w510> cr3, it does't work at all now
[16:01] <zyga-w510> cr3, touching the screen randomly moves the pointer around
[16:01] <mpt> thanks xnox
[16:01] <zyga-w510> cr3, actually
[16:01] <cr3> zyga-w510: good for me, bad for me :) this is valuable information
[16:01] <zyga-w510> cr3, when I tried that just now it _did_ work
[16:01] <cr3> err, s/bad for me/bad for you/
[16:02] <cr3> zyga-w510: it's working as a touch device but not a multitouch device though, right?
[16:02] <zyga-w510> yes
[16:02] <zyga-w510> cr3, although a moment ago I'm pretty sure that id did something rather stupid and made the pointer dance around the screen
[16:02] <zyga-w510> cr3, in precise I did apply a few udev tweaks that I forgot about and got lost later when I wiped this machine
[16:02] <cr3> zyga-w510: ok, so we need to determine whether we want to test whether touchscreens work as touch devices separately from whether they work as multitouch devices
[16:03] <zyga-w510> cr3, definitely
[16:04] <zyga-w510> cr3, testing this now I realize one more thing is important and relevant for udisks2 and other tests
[16:04] <zyga-w510> cr3, the speed of discovery -- it's not instant
[16:04] <zyga-w510> cr3, I suspect there's some polling behind the scenes
[16:04] <zyga-w510> cr3, I'll add timestamps to my output so that we know better what to do, maybe the 20 second timeout should be changed
[16:05] <cr3> zyga-w510: while you're on that machine, could you also pastebin the output of /usr/share/checkbox/scripts/udev_resource? it's so great having all the scripts in checkbox readily available onthe live image to test hardware!
[16:06] <zyga-w510> sure
[16:10] <zyga-w510> cr3, http://paste.ubuntu.com/1189198/
[16:12] <cr3> zyga-w510: hehe, I meant the output of running that script :)
[16:12] <zyga-w510> oh
[16:12] <zyga-w510> I was curious after doing that
[16:12] <zyga-w510> why would you need it ;)
[16:13] <cr3> zyga-w510: I love the python3 part, barry will be proud :)
[16:13] <zyga-w510> http://paste.ubuntu.com/1189202/
[16:13] <zyga-w510> cr3, that the script is written in python3?
[16:14] <barry> cr3: rock!
[16:14] <cr3> zyga-w510: lines 480 to 492 look pretty darn good!
[16:14] <ogra_> so drop the rest !
[16:14] <cr3> ogra_: we're still talking about lines, right? :)
[16:15] <ogra_> yeah, but then your code becomes *perfect*
[16:15] <ogra_> like a haiku :)
[16:15] <zyga-w510> cr3, in the pastebin?
[16:15] <cr3> ogra_: 0 lines == 0 bugs
[16:15] <ogra_> ++
[16:15] <zyga-w510> category touch?
[16:16] <cr3> zyga-w510: yeah, your wacom device seems to be properly detected by the udevadm parser. so at least we're reporting complete information and accurate too, as it's being properly recognized as a TOUCH device
[16:16] <zyga-w510> cr3, right, I understand that now, cool, that's very good
[16:16] <cr3> zyga-w510: we might need to refine that category for touch vs multitouch
[16:17] <zyga-w510> cr3, do you think you'd like a separate multi-touch category (or extra property somewhere)
[16:18] <cr3> zyga-w510: I'm very careful before adding categories, so we'll evaluate the need for it as we write tests
[16:18] <zyga-w510> barry, why oh why py3k/py2k bytes type is such a mess :-)
[16:19] <zyga-w510> barry, couldn't py3k use raw_bytes or something
[16:19] <barry> zyga-w510: i'm not sure what you mean ;)  okay, yeah it's a mess in py2
[16:21] <zyga-w510> barry, I mean that since it means something totally different then for the sake of easier compatibility the true bytes type in py3k could have been called raw_bytes, leaving bytes as an alias of str to keep the old crappy behavior
[16:21] <zyga-w510> barry, I probably want the impossible
[16:21] <zyga-w510> (I now have to do the ord/chr dance)
[16:22] <cr3> ogra_: I find it unfortunate that the industry still rewards people adding code more than those removing it
[16:22] <zyga-w510> cr3, evolution did the same, mind you
[16:22] <cr3> zyga-w510: never settle for anything less than the impossible :)
[16:22] <ogra_> heh
[16:22] <barry> yeah, given that python 2 is a dead end, it's impossible :)
[16:23]  * zyga-w510 wishes for py2.7.9(9) release with from __future__ import bytes3k
[16:23] <zyga-w510> to suck less
[16:23] <cr3> zyga-w510: evolution is slowly getting rid of the appendice routine
[16:24] <cr3> appendix in english, I mean
[16:25] <zyga-w510> barry, was there a 3to2 program or is there only 2to3?
[16:26] <barry> zyga-w510: pep 404 :)
[16:26] <zyga-w510> heh
[16:26] <zyga-w510> yeah
[16:26] <zyga-w510> barry, but in all fairness that policy huts the transition -- I'm not asking for a real 2.8
[16:26] <barry> zyga-w510: there's a rumored 3to2 program, but i've never tried it.  frankly i'm not a fan of 2to3 for production or development either (although a cool framework, it's just too slow)
[16:27] <zyga-w510> barry, it's like u getting back to 3k
[16:27] <zyga-w510> s/huts/hurts/
[16:28] <barry> zyga-w510: yeah.  it's just that i think that if your py2 code is unicode clean, you will have a much easier time with the transition.  caveat that with the tricks we've learned, tools like the six module, and maybe even the re-introduction of u'' in py3.3 for the web framework guys
[16:29] <cr3> barry: wait, why reintroduce u'' for web framework guys?
[16:29] <zyga-w510> barry, what would you do when you had to ship 2/3 programs for the next few years?
[16:29] <zyga-w510> cr3, for 2to3 to indicate where it is safe, web is not unicode
[16:29] <zyga-w510> web is _B_Y_T_E_S_ man
[16:30] <barry> cr3: http://www.python.org/dev/peps/pep-0414/
[16:30] <ScottK> I have packages that run 2to3 at build time and ship both python and python3 binaries, it's not that hard.
[16:30] <zyga-w510> Scott, I wrote mine in py3 so I'm hosed
[16:31] <didrocks> ScottK: waow, and you didn't have to adjust anything else?
[16:31]  * didrocks always has some adjustement to do after running 2to3
[16:31] <barry> zyga-w510: i agree, but i'm not the project leader of django/zope/cherrypy/wtfwebetckthxbye
[16:31] <ScottK> Upstream coded for it to be done that way.
[16:31] <barry> zyga-w510: i've written lots of single-code base py2/py3 compatible code.  it's not that hard
[16:32] <didrocks> ah ok, it's not the pure python2 first draft, it had been adapated :)
[16:32] <barry> zyga-w510: w/o 2to3
[16:32] <infinity> BenC: I haven't been paying attention to GHC (or much of anything) lately. :/
[16:32] <zyga-w510> barry, so did I today
[16:32] <didrocks> adapted*
[16:32] <ScottK> Personally, I find it easier for stuff I'm writing to target 2.6+ and make the code work with python and python3.
[16:32] <zyga-w510> barry, except for bytes that I'm actually fixing now
[16:32] <ScottK> didrocks: Yes.  It's upstream's method for supporting older than python2.6 and python3.
[16:32] <cr3> barry: thanks, I can appreciate this harsh reality: Most of those users couldn't care less about the "purity" of the Python language specification, they just want their websites and applications to work as well as possible.
[16:33] <barry> ScottK: >= 2.6 is a requirement imho, but some folks have been able to go all the way back to 2.4 with single code base.
[16:33] <didrocks> ScottK: that's nice :)
[16:33] <zyga-w510> cr3, end of quote ;)
[16:33] <barry> zyga-w510: yeah, that's what i mean.  the bytes v. strings model must be solid, which is not always easy. (e.g. email is both)
[16:34] <ScottK> So is DNS.
[16:34] <zyga-w510> yeah, I fully agree
[16:34] <barry> ScottK: yeah
[16:35] <barry> zyga-w510, cr3, ScottK: many people have found this compatibility library to be very helpful: http://packages.python.org/six/
[16:35] <ScottK> I've heard about it, but haven't used it.
[16:35] <barry> and of course it's available as python-six and python3-six
[16:35] <zyga-w510> wow
[16:35] <zyga-w510> six.binary_type
[16:35] <zyga-w510> ++
[16:35] <zyga-w510> cool, thanks
[16:35] <barry> i haven't needed to use it myself, but i've occasionally lifted tricks from it :)
[16:37] <cr3> barry: exponent is even more powerful than multiplication, so eight will certainly be even better than six!
[16:37] <mpt> ev, speak of the devil: https://launchpadlibrarian.net/114961700/libreoffice-upgrade.png
[16:38] <ev> mpt: ICK
[16:38] <cjwatson> barry: Oh, which reminds me: am I safe to assume at this point that we really aren't going to revert to py2, and start ripping out compatibility code from ubiquity?
[16:38] <zyga-w510> heh
[16:39] <cjwatson> It's not a desperate hardship to keep it, but I kind of figure I'd have heard by now if we were going back
[16:40] <zyga-w510> barry, I wonder if angry mint-switching users will fork python2.7 and release minthoon-2.8 ;)
[16:43] <xnox> zyga-w510: mint users are ok, until they take my packages from ubuntu (!) and report bugs against debian (!!) that it doesn't work with mint-foo (!!!)
[16:43] <zyga-w510> ^_^
[16:44] <zyga-w510> well
[16:44] <zyga-w510> you can't blame them
[16:44] <zyga-w510> they go upstream, right
[16:44] <silverarrow> what`s wrong with mint then?
[16:45] <xnox> silverarrow: forking core libs & changing API&ABI without rebuilding r-deps in the whole archive.... shall I continue?
[16:46] <barry> cjwatson: no going backward only forward :)  it does mean will have to ship py2.7 and 3.3 for 12.10 and try again to remove 2.7 from the 13.04 isos, but i have no problem with you ripping out the compatibility code and making it a clean py3 app.  that's what we're doing with gwibber (though it won't make it for 12.10 obviously)
[16:46] <ogra_> silverarrow, supressing security updates
[16:46] <silverarrow> might get messy
[16:46] <barry> zyga-w510: :)
[16:47] <silverarrow> ubuntu have at least been very good with security updates
[16:48] <xnox> barry: should the rest of the task still be completed on the best effort bases from the python-versions spec?
[16:49] <xnox> s/task/tasks/
[16:49] <xnox> barry: and is xapian the road-block blocking everything else?
[16:50] <barry> xnox: yes, if possible.  i've copied the spreadsheet to a new one for 13.04 and removed all the green.  i'll publish that soon, but i definitely want to get a jump on the ports for 13.04.
[16:50] <barry> xnox: xapian, twisted, and the launchpadlib stack are big blockers
[16:51] <barry> xnox: twisted is probably in the best shape (people are actively working on it).  the lplib stack and xapian are still the most problematic
[16:52] <xnox> barry: ok.
[16:52] <xnox> barry: by launchpadlib you mean the bug reporting integration for apps or just the pythonic api to talk to launchpad (e.g. stuff like lp-shell and etc)?
[16:57] <barry> xnox: well, actually, i will have to re-evaluate it for 13.04.  launchpad-integration was the package that needed porting but it no longer has an ubuntu-desktop task afaict
[16:57] <barry> xnox: if we can ignore that stack, i would be ecstatic
[16:57] <xnox> barry: yes, because it's dropped. We have whoopsie & apport instead.
[16:58] <xnox> barry: it's dead =) & on the way out.
[16:58] <ev> whoop
[16:58] <didrocks> sie? :)
[16:58] <barry> ev you are my bff :)
[16:59] <ev> barry: well lets get bracelets made then
[16:59] <[snake]> can I compile something into a directory that I specify?
[16:59] <[snake]> with make
[17:00] <barry> xnox, ev: which cuts out wadllib, and a host of other really nasty and difficult to port stuff.  win!
[17:00] <[snake]> I've written a patch for xchat and I want to compile it somewhere where it doesn't overwrite my normal xchat
[17:00]  * xnox is googling for custom made bracelets "whoop" for ev and "sie" for barry
[17:00] <ev> haha
[17:01] <barry> :)
[17:01]  * xnox they will have "signed by didrocks" signature trademark. And inside will have a writting like in Lord of the Rings "To collect all bugs and unite all crashes..."
[17:01] <didrocks> heh :)
[17:02] <[snake]> target in the man page for make is where it compiles correct?
[17:03] <xnox> [snake]: #ubuntu-app-devel for app development on ubuntu. This a channel for developing ubuntu itself.
[17:03] <[snake]> xnox, what if I am make-ing ubuntu?
[17:04] <mpt> "Replace the customized configuration file '/etc/update-manager/release-upgrades'?" </irony>
[17:04] <[snake]> xnox, I mean, I'm not, but the question is just about make
[17:04] <[snake]> :(
[17:04] <xnox> mpt: I call BS =)
[17:04] <bismay> Hii I want to be an ubuntu app developer any suggestions from where I should start?? Currently i have knowledge of c and c++
[17:04] <xnox> [snake]: google for out of the tree builds, or VPATH builds then
[17:04] <mpt> xnox, https://launchpadlibrarian.net/114963812/update-manager-conf-file.png
[17:05] <tsimpson> [snake]: set a different --prefix with configure
[17:06] <mpt> bismay, questions like that are better in #ubuntu-app-devel, but the short answer is <http://developer.ubuntu.com/get-started/>
[17:06] <[snake]> tsimpson, oh, thanks :) I checked and target was just what you're compiling. so thanks for telling me that
[17:06] <bismay> mpt, thanks..:)
[17:06] <xnox> mpt: that bug was already reported =)
[17:07] <mpt> xnox, I didn't see it when I searched.
[17:07] <mpt> xnox, it's bug 1046942 if you want to mark it as a duplicate.
[17:08] <xnox> bdmurray: what was the bug for Libreoffice prompt vs Prompt? Or is mpt the first reporter?
[17:08] <mpt> I was not
[17:08] <xnox> mpt: wait.... why update manager. Me is confused.
[17:09] <xnox> maybe it's a different one
[17:09] <mpt> xnox, the libreoffice one is bug 918352
[17:09] <nuclearbob> can anybody field a casper question for me?
[17:09] <mpt> Now I'm about to report a gdm one
[17:10] <bdmurray> xnox: bug 1045579
[17:10] <xnox> bdmurray: thanks. mpt ^^^^
[17:10] <mpt> ohhhh
[17:11] <xnox> mpt: I can totally understand how easy it is to relate your & that bug titles
[17:11] <xnox> =))))))))))))
[17:25] <mpt> xnox, also, it was filed against a different package, so I wouldn't have seen it anyway.
[17:25] <xnox> mpt: haha. True. It has now been marked against the package that is causing the error, not the package where the file belongs nor the window that shows it.
[17:26] <xnox> mpt: it's same way that adobe acrobat reader, is causing similar errors on gnome-mimetypes package upgrade. Or something like that =)
[17:34]  * mpt arrives at the "Remove obsolete packages" stage (bug 940789)
[17:50] <xnox> mpt: you are using KDE?!
[17:51]  * xnox is a bit sad =(
[17:51] <xnox> mpt: or does it affect gtk front-end as well?
[17:55] <mpt> xnox, I think it affects GTK coincidentally
[17:55] <mpt> It's a typical GTK2 dialog that hasn't been ported to GTK3 and ballooned in height
[17:56] <mpt> reported as bug 1046955
[17:59] <xnox> mpt i will take it for the jam then.
[18:18] <stokachu> hi has anyone seen an error like this before > http://paste.ubuntu.com/1189405/
[18:18] <stokachu> attempting to checkout a branch on precise
[18:20] <stokachu> not sure if this is a launchpad issue or not
[18:22] <mpt> stokachu, I get the same error, so I think it is a Launchpad problem. Try asking in #launchpad.
[18:22] <mpt> stokachu, I get the same error, so I think it is a Launchpad problem. Try asking in #launchpad.
[18:23] <stokachu> mpt: thanks will do
[18:33] <scott-work> skaet: i have done what i can at this time
[18:33] <skaet> thanks scott-work
[18:36] <stokachu> cyphermox: is http://pad.lv/872824 something you would approve a full a quantal patch for precise even though strongswan has seen at least 2 release bumps
[18:38] <stokachu> there seems to be several code changes from precise to quantal and i dont think cherry-picking will be trivial
[18:41] <cyphermox> stokachu: what about backporting strongswan? I think it should be doable, it's in universe and IIRC has no reverse-depends except itself
[18:44] <cyphermox> stokachu: the bzr error, I got the same earlier this morning; but I don't know what causes it, let me know if you find out
[18:44] <stokachu> cyphermox: ah, yea its a bug i had to add launchpad.packaging_verbosity = off to my ~/.bazaar/bazaar.conf
[18:45] <cyphermox> blarg
[18:45] <stokachu> cyphermox: https://bugs.launchpad.net/bzr/+bug/888615
[18:45] <stokachu> the history is incomplete on that branch as well
[18:46] <stokachu> it isn't showing the latest changelog for the released version of network-manager
[18:46] <cyphermox> it isn't?
[18:46] <cyphermox> stokachu: anyway, there is the right stuff in lp:~network-manager/network-manager/ubuntu.precise
[18:46] <stokachu> network-manager (0.9.3.995+git201203152001.04b2a74-0ubuntu1) precise; urgency=low is the latest one in changelog
[18:46] <cyphermox> let me know if you
[18:47] <cyphermox> need to make changes, I'm preparing a SRU locally
[18:47] <stokachu> ok will do
[18:49] <stokachu> cyphermox: yea i think it would be best to backport strongswan and network-manager-strongswan to precise
[18:50] <cyphermox> stokachu: can you file the appropriate bugs?
[18:50] <stokachu> cyphermox: sure thing, thanks :)
[18:51]  * micahg points stokachu at requestbackport
[18:51] <stokachu> micahg: ah nice
[19:08] <ev> pitti: if you're still around. Why does apport-retrace now need a terminal emulator?
[19:08] <ev> r2009
[19:08] <ev> I can't find any other reference in the log
[19:12] <trism> ev: it pops up a terminal to show progress when downloading packages if you use "Examine Locally" from the apport dialog (though depend might be a bit strong)
[19:12] <ev> trism: but that's in apport-gtk, not apport-retrace
[19:14] <trism> ev: yes but apport-retrace enables the functionality
[19:15] <ev> trism: sure, but that seems the wrong way around to me. apport-retrace is a headless application, it doesn't need to pull in the universe.
[19:39] <trism> ev: good point, the changelog hints it was added a couple months ago in 2.2.3-0ubuntu1, not sure
[19:59] <mterry> ev, heyo!  Do you know how to extract a trace-with-symbols from errors.ubuntu.com?
[20:01] <dobey> mterry: hrmm; actually, looking at the "Problem failed:/blah/blah" strings, I wonder if it is due to some obscurbe multiarch issue on the error reporting box that breaks the retracing
[20:07] <ev> mterry: can you point me at the problem you're looking at?
[20:11] <mterry> ev, like https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Findicator-weather%3A11%3Ax86_64%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B1cf08%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Baca2%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Bcafa%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B47d53%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B480a0%3A%2Flib%2Fx86_64-linu
[20:11] <mterry> x-gnu%2Flibglib-2.0.so.0.3200.3%2B4849a%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgtk-x11-2.0.so.0.2400.10%2B1342f7%3A%2Fusr%2Flib%2Fpython2.7%2Fdist-packages%2Fgtk-2.0%2Fgtk%2F_gtk.so%2B1ac046%3A%2Fusr%2Fbin%2Fpython2.7%2B9890a%3A%2Fusr%2Fbin%2Fpython2.7%2B98602%3A%2Fusr%2Fbin%2Fpython2.7%2B9f1c0%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9081%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9311%3A%2Fusr%2Fbin%2Fpython2.7%2Baa8bd%3A%2Flib%2Fx86_64-linux-gnu%2Flibc-2.15.so%2B2176d
[20:12] <ev> mterry: that's one that failed to retrace
[20:12] <ev> mterry: https://bugs.launchpad.net/daisy/+bug/1044418
[20:12] <mterry> ev, OK...  is that what the "failed:" prefix means?
[20:12] <ev> yes
[20:12] <ev> I'm making a note to make that more obvious
[20:12] <ev> as this is not the first time it's come up
[20:13] <mterry> ev, OK makes sense.  Thanks!
[20:27] <jdstrand> barry: hi! are we expecting only one python3 in main? I see python3.3 in the archive is wanting to come in (I'd really prefer to support only one py2 and one py3)
[20:29] <xnox> jdstrand: due to a bug in python3-defaults 3.3 will not become default, which blocks switching to it.
[20:29] <xnox> jdstrand: so while it might be in the archive both 3.2 & 3.3 will not be supported (e.g. modules will not be compiled against both)
[20:29] <xnox> jdstrand: my guess is that it will mean that python3.3 will be in universe this cycle.
[20:30] <jdstrand> xnox: thanks, that works fine for me
[20:30]  * jdstrand points to http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[20:31] <jdstrand> 'distribute' wants it in main
[20:33] <barry> jdstrand, xnox plus 3.3 final is not out yet, so yeah, we're carrying 3.2 and 3.3 for 12.10
[20:34] <barry> and we know that there are a few bugs in 3.3 that will bite people.  e.g. the ancient version of zope.interfaces is not compatible w/3.3 so we (and debian too) need to upgrade that to z.i 4.0.1
[20:34] <xnox> barry: jdstrand cares about 3.3 in the main or in the universe ?
[20:35] <xnox> barry: will 3.3 be supported in any way (e.g. modules compiled for it)
[20:35] <infinity> Methinks this means 3.3 should stay in universe, and distribute should be made to love 3.2.
[20:35] <barry> yeah 3.3 in uni
[20:35] <xnox> oh... yes, I agree with infinity.
[20:35] <ScottK> Distribute does love 3.2, it's just not monogamous
[20:35] <barry> % apt-cache showsrc python3.3 | grep -i section
[20:35] <barry> Section: universe/python
[20:35] <barry>  
[20:36] <infinity> barry: Yeah, we know it's in universe, that's what started this whole conversation. :P
[20:36] <barry> oh :)
[20:36] <infinity> barry: doko uploaded a version of distribute that build-deps on 3.3
[20:36] <jdstrand> one of them in universe is all I care about :)
[20:36] <infinity> doko: Plz fix.
[20:37] <infinity> doko: Or I will.
[20:37] <jdstrand> thanks! :)
[20:37] <barry> infinity lays the smackdown
[20:37] <xnox> infinity: I was about to ask how did a package manage to build-dep on 3.3 if only doko uploaded 3.3 & didn't add it as supported....
[20:37] <ScottK> infinity: I'm sure he got an FFe before uploading that.
[20:38] <infinity> ScottK: Sarcasm is unbecoming.
[20:38]  * barry runs away back to #gwibber
[20:43] <xnox> slangasek: was that I hint, I should write release notes ? =)
[20:44] <xnox> slangasek: was that a hint, I should write release notes ? =)
[20:44] <slangasek> xnox: yes :)
[20:44]  * infinity waits for the second "xnox: yes :)"
[20:44] <xnox> slangasek: also the whiteboard needs clean up
[20:45] <slangasek> probably
[20:45] <slangasek> xnox: release note is a higher priority though, as this is currently a gap in the tech overview for beta1
[20:45] <doko> infinity, xnox: distribute should support 3.3 as well
[20:45] <doko> but maybe I'll just b-d on 3.2
[20:46] <xnox> doko: danke.
[20:46] <haakonn> Why is not ubuntu updating packages from debian sid? or at least my package
[20:46] <infinity> doko: I was just fixing it to not b-d on 3.3
[20:46] <xnox> haakonn: because ubuntu is currently frozen.
[20:46] <doko> ahh, thanks
[20:46] <xnox> haakonn: and so is debian.
[20:46] <haakonn> already? ok
[20:47] <xnox> haakonn: check quantal release schedule, debian import freeze is quite early. This is when we stop auto syncing. You can request a sync with requestsync if it is suitable per ubuntu policy, you might also need FFe
[20:49] <haakonn> FFe?
[20:52] <jbicha> haakonn: it's short for Feature Freeze Exception, bug fixes are fine but new features need approval
[20:52] <jbicha> https://wiki.ubuntu.com/FreezeExceptionProcess
[21:00] <haakonn> jbicha: Hm. it has both bugfixes and new features. Is it hard to get approval?
[21:07] <jbicha> haakonn: it depends; is it in universe? does it affect many other packages? how well tested is it?
[21:08] <slangasek> xnox: prelim release notes added to https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta1
[21:21] <haakonn> jbernard: it is in universe yes, and it does not affect any other packages. It has been tested for a month by me and a few other poeple.
[21:22] <haakonn> https://launchpad.net/ubuntu/+source/mactelnet
[21:22] <jbernard> jbicha: ^
[21:22] <haakonn> yes, sorry
[21:22] <jbernard> haakonn: no worries