[02:02] bug #1198846 complains that if you have both the dvd and usb installation media present, the system mounts the usb instead of the dvd when you ask the bios to boot the dvd. my first instinct was to close this as not a bug but it has "OEM Priority Project" tasks. what exactly does that mean? someone is paying Canonical to do something about this? so should I leave it alone then? [02:02] bug 1198846 in grub2 (Ubuntu) "[efi boot to unexpected media] plug in live usb and DVD at the same time, try to boot from DVD but it comes to usb" [Undecided,New] https://launchpad.net/bugs/1198846 [02:05] psusi: All it means, AIUI, is that it affects something Canonical OEM services is doing. Hard to say exactly what. [02:06] I don't think you should triage the Ubuntu bug task any differently than you normally would. [02:07] agreed; if it needs to get escalated within Canonical to fix it, that's not something you should need to worry about [02:07] and in the first instance, if the community devs think it's a wontfix issue, you shouldn't hesitate to mark it as such [02:13] cool [02:47] roaksoax, kirkland: ping ( === henrix_ is now known as henrix [03:34] Logan_, about bug 1185765 ... [03:34] bug 1185765 in Ubuntu "[needs-packaging] multibootusb" [Wishlist,Fix released] https://launchpad.net/bugs/1185765 [03:36] Noskcaj: pong [03:37] roaksoax, a few thing: 1. the description of testdrive is very outdated on the lp page. 2. It seems installing testdrive from source doesn't work. 3. Find some time for a testdrive hackfest, please. [03:37] mostly number 1 [03:39] roaksoax, and plz, do give us a wiki page or something to teach people how to hack on Testdrive. [03:39] +1 to that. [03:39] that's pretty much my goal for a hackfest day [03:47] he ran away again, didn't he. [03:47] Noskcaj, where the hell is multibootusb in Ubuntu/ [03:47] ? [03:48] "apt-cache search multibootusb" gives the result: multibootusb - Multiple live linux on USB. [03:49] Noskcaj, hah? [03:49] I don't get it here [03:49] * can't [03:50] dam, it's just a broken repo on my PC [03:50] Noskcaj, can you please confirm if you enabled https://launchpad.net/~upubuntu-com/+archive/ppa ? [03:50] Noskcaj, so, it doesn't exist, please package it [03:50] :P [03:51] yeah, that's what it was. i'm working on it now [03:52] Noskcaj, great:) [03:52] Shouldn't be very difficult I hope:) [03:58] what do i do is a program i'm trying to package already has a .deb? [04:14] roaksoax, one other thing. the testdrive .dsc file isn [04:14] Noskcaj, well, you still have to package it even if it has a deb [04:14] 't lintian clean [04:14] Noskcaj, lintian clean is rather difficult you know:P [04:15] We try to make it lintian clean [04:15] all i know is an error appeared [04:15] Noskcaj, what's the lintian message? [04:15] W: testdrive source: out-of-date-standards-version 3.9.3 (current is 3.9.4) [04:15] looking at the lintian website, it looks like a fairly easy fix [04:15] Noskcaj, ah, simple [04:16] Noskcaj, wait till the next feature upload will be better [04:16] ok [04:26] Noskcaj: lintian clean doesnt mean theres no lintisn warnings or stuff [04:27] ok, i'm new to this [04:27] Noskcaj: no worries. you will gain more experience with prsctice. [04:27] yhe error of testdrive 3.20 is because of pygobject [04:28] idk whether its upstream or testdrive issue [04:28] but it hsppenend sfter tje upgrade of libraries [04:30] Noskcaj: could you please file bugs thatd easier for me to track [04:30] roaksoax, ok. [04:33] Noskcaj, I'm thinking of the multibootusb package, how will you filll in the copyright file? [04:33] Looks like it's very difficult:P [04:33] smartboyhw, i've pretty much given up on that one, since it's my first package [04:34] i've contacted the guy who makes it and am awaiting reply [04:34] Noskcaj, copyrights are VERY important (as I learnt in Kubuntu packaging) [04:34] I got rejects solely because of that file [06:17] roaksoax, bug 1199235 [06:17] bug 1199235 in TestDrive "Testdrive-gtk crashes when installed from 3.20" [Undecided,New] https://launchpad.net/bugs/1199235 [07:26] good morning === tkamppeter_ is now known as tkamppeter === mwhudson_ is now known as mwhudson [08:19] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox [08:24] ev: ping. can you have a look at the mail I sent you a few days back related to LP 1197974 [08:24] Launchpad bug 1197974 in Activity Log Manager "Error setting crash reporting: GDBus.Error:org.freedesktop.DBus.Error.AuthFailed: Not authorized." [Medium,Confirmed] https://launchpad.net/bugs/1197974 [08:25] whenever you are free === 36DAAZP3C is now known as tvoss [08:29] m4n1sh: yup, will do. For what it's worth, it's a harmless error [08:29] it just means that the code tried to reflect the UI state in the configuration file, but the user hadn't pressed the "unlock" button yet [08:29] ev: well, i don't know much about that component, so referred it to you. reported by jbicha [08:30] sure thing === Jack is now known as Guest68663 === evilissimo is now known as Guest58872 === yofel_ is now known as yofel === dholbach_ is now known as dholbach [10:46] is there a trick to getting qtcreator to set LD_* correctly? I'm trying to build and run ubuntu-system-settings locally, but it fails with 'libSystemSettings.so.1: cannot open shared object file: No such file or directory' [10:47] I've just been building the package :( [10:58] seb128: ^ any idea? [11:03] ev, Laney: no idea, I don't run it from qtcreator either [11:03] seb128: thanks all the same [11:03] but mardy_ can maybe help there... [11:04] ev: I don't use qtcreator either, but I know you can change the environment variables used when running your app === mardy_ is now known as mardy [11:05] mardy, hey, welcome back ;-) [11:05] seb128: thanks :-) [11:05] mardy, I'm looking at a system setting translation issue ... do you have a preference on translating displayName in the backend or in the UI? [11:05] thanks [11:06] mardy, I'm not sure if I should add the tr() call to the item-model.cpp code or in the UI [11:09] seb128: I'd probably do that in the UI, but IMHO both are fine === MacSlow is now known as MacSlow|lunch [11:20] mardy, ok, I found how to do it in the UI (I was just missing the gettext domain), merge request coming in a bit [11:20] mardy, https://code.launchpad.net/~seb128/ubuntu-system-settings/storage-bar-border/+merge/173672 ... did you mean to change the mr status as well? [11:21] mardy, I've no strong opinion on the anchors, I just tend to try to go for "less lines of code" [11:21] ;-) [11:21] seb128: no, it's fine, I just wanted to wait for your reply. I've approved it now :-) [11:22] mardy, ok ;-) [11:22] mardy, is there any difference in behaviour/performance between both ways? [11:22] mardy, or is it just that you find it easier to read when declared with left/right/... [11:22] mardy, oh, and thanks for the review ;-) === Guest58872 is now known as evilissimo === ikonia_ is now known as ikonia [11:47] tjaalton: Could you please look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707064 ? If you need help I can try to come up with something [11:47] Debian bug 707064 in libapache2-mod-nss "libapache2-mod-nss: sourceful transition towards Apache 2.4" [Serious,Open] [11:54] cjwatson: yeah I should sync with upstream first, fedora has done the transition earlier this year iirc === greyback is now known as greyback|food [11:58] well, they just patched upstream [12:00] sforshee: did you try the macbook yet on 3.11 pre rc? [12:03] Hi All, can anyone point me to example source packages that use the new elegant "dh" debhelper syntax to build multiple binaries using different configuration options. I looked at the vim and mpb packages but both of these use the old semi-manual dh_* syntax in the rules file. In fact, is this even possible using dh? [12:11] cjwatson: ping [12:11] cjwatson: ok I have the source sorted out, now need to migrate the packaging [12:11] cjwatson: I'm looking for some advice, what it the current best way to test dbus services? spawn a separate bus and test on that? [12:12] cjwatson: mock the hell out of dbus? (feels wrong though) [12:12] cjwatson: or something else? [12:12] cjwatson: the service is written in python3 [12:12] zyga: pitti has a dbusmock library or something along those lines [12:12] tjaalton: cool, thanks [12:12] cjwatson: oh, I'll have a look [12:12] cjwatson: thanks! [12:13] tjaalton: http://wiki.debian.org/Apache/PackagingFor24 is fairly easy to follow [12:13] k thanks [12:14] valavanisalex: you can do anything with dh; it may just require lots of overrides. openssh builds two variants of itself for instance [12:14] cjwatson: that looks awesome, thanks! [12:14] valavanisalex: or grub2 but that is Complex [12:15] (and actually grub2 is a slightly strange mix of styles so perhaps not the best example) [12:16] valavanisalex: the main important thing to realise is that you can override dh_auto_* to run each of your relevant build passes [12:16] valavanisalex: for instance Python packages (*searches for random example* e.g. germinate) tend to run a build pass for each version of Python they're building for [12:17] zyga: thank pitti, but yes :) [12:17] one of these days maybe I should convert ubiquity to use that [12:20] valavanisalex: cjwatson: with debhelper 9, one can define "build:" target and just do all the building there as compex, as needed. dh, will notice and run those commands instead of dh_auto_* stuff. [12:20] cjwatson: for ubiquity build, i'd love to somehow multiplex and build included packages in-parallel, but with sane/sorted build-log. === zyga_ is now known as zyga [12:29] xnox,valavanisalex: You can do that. It can have some surprising effects, and I've generally found it better to use overrides. [12:29] xnox: Yes === MacSlow|lunch is now known as MacSlow [12:35] cjwatson: is apache 2.4 in saucy-proposed yet? [12:36] tjaalton: Yes [12:36] tjaalton: But better to do the transition in unstable and let it autosync, where possible [12:36] sure [12:36] tjaalton: (I guess you'll need a manual sync in this case) [12:36] I'll test the builds against sid anyway [12:37] but need someone to sponsor it [12:37] I can do that [12:37] mlankhorst: I haven't tried 3.11 yet on any macbooks [12:38] gema_: hi! should I use the qa-daily-testing tag on a bug for smoke testing failures? ie, I want bug #1199351 to show up for the failures for http://reports.qa.ubuntu.com/smokeng/saucy/image/2900/ and http://reports.qa.ubuntu.com/smokeng/saucy/image/2899/ [12:38] bug 1199351 in linux-manta (Ubuntu) "/usr/share/ufw/check-requirements -f fails on Nexus 4 and Nexus 10" [Undecided,New] https://launchpad.net/bugs/1199351 [12:39] jdstrand: it's not a tag in the lp sense, if you want them to show in the dashboard, the bug number needs to be added to jenkins [12:39] jdstrand: we can do that, or you can do it if you have access to the lab [12:39] gema_: how do I do that? [12:39] I think I do. I'd like to try, so I can do it in the future [12:40] ack [12:40] so connect to the vpn [12:40] I will tell you how to find the right job [12:40] * jdstrand is connected [12:40] ok [12:40] so this is the job that you want tagged: https://jenkins.qa.ubuntu.com/job/saucy-touch-mako-smoke-security/15/? [12:41] all we need to find it's equivalent in the internal jenkins [12:41] yes === _salem is now known as salem_ [12:46] sforshee: did anything land in 3.11 related to macbook though? like the pci crap perhaps [12:48] mlankhorst: not that I'm aware of, but I haven't been monitoring it closely [12:48] hm then again nfs seems to be dying again now too, maybe it is related to that.. [13:00] cjwatson: hm, seems to otherwise work, but somehow dh_strip doesn't strip the module as it used to [13:01] barry: system-image meeting in #ubuntu-meeting [13:03] cjwatson: oh I know, guess dh_apache2 copies an unstripped version there, this doesn't use dh yet [13:04] so I just added dh_apache2 after dh_install [13:06] mpt: any idea who I need to talk to about getting an icon made up for "diagnostics" in ubuntu-system-settings, or are you already on it? [13:13] ev: talk to tiheum from design about icons [13:14] seb128: what good fortune. I'm facing him. [13:14] will do, thanks [13:14] ev: yw ;-) [13:15] you mean [13:15] ev: let me forward you an email with the icons he sent us [13:15] thank you [13:15] ev: there is the one you want in there [13:19] ev: email sent [13:21] perfect! thanks seb128! [13:22] ev: yw! [13:24] seb128: what about the colour editing thingy you told me to do? [13:24] or did that get fixed? [13:25] colour editing... me tries to remember [13:25] Laney, oh, I included that in the email [13:25] aha [13:25] it's cccccc -> 808080 in the svg [13:25] thought that extra detail might have been left out [13:25] nm [13:26] cjwatson: ok it's fixed [13:27] Laney, thanks for checking ;-) [13:28] tjaalton: Lovely, thanks [13:30] cjwatson: pushed the source to http://kernel.ubuntu.com/~tjaalton/tmp/ [13:36] ev, wait, you have the stethoscope icon? [13:36] I have a heartbeat monitor icon [13:37] you can see it if you come over here :) [13:37] oh cool [13:37] But that involves walking, like, six steps [13:37] use a hangout ! [13:37] hahaha [13:38] Five minutes to set up the hangout, five more minutes to figure out the screen sharing feature [13:38] but you dont have to walk [13:38] tjaalton: your .dsc has a different .orig.tar.gz size from the one in Debian unstable - I guess I'm safe to ignore that? [13:38] cjwatson: oh.. yes please do. I'll fix mine [13:38] tjaalton: Oh, it's different in unstable vs. saucy [13:39] duh [13:39] tjaalton: That sucks, it'll have to be a fakesync [13:39] can't remember why it was originally [13:39] tjaalton: They're identical file contents, but packed independently from different top-level directory names [13:40] Ah well [13:40] Get it right next upstream release ;-) [13:40] yeah, I'll poke upstream (@redhat) to actually release a new version and not just patch the package all the time [13:49] SRU team members: Can you try to review Bug 1189083 and Bug 1189085's SRU patch into Raring, I want to test it today or tomorrow as I'm leaving tomorrow afternoon (UTC time). [13:49] bug 1189083 in ibus-cangjie (Ubuntu Raring) "Make "Preferences" button work in "IBus Preferences"" [Undecided,Confirmed] https://launchpad.net/bugs/1189083 [13:49] bug 1189085 in ibus-cangjie (Ubuntu Raring) "ibus-cangjie missing dependency gir1.2-ibus-1.0" [Undecided,Confirmed] https://launchpad.net/bugs/1189085 [13:49] And upload, ofc:P === Guest86601 is now known as mfisch === mfisch is now known as Guest37969 === achiang` is now known as achiang === wendar_ is now known as wendar [14:09] Nobody help? ^ [14:39] barry, hey [14:39] seb128: hi [14:39] barry, is that known that your python-configglue updates broke ubuntuone-syncdaemon on saucy? [14:40] seb128: no, but add it to the list :( [14:40] it also broke software-center and virtualenv [14:40] barry, can you try running /usr/lib/ubuntuone-client/ubuntuone-syncdaemon [14:40] ? [14:40] not python-configglue directly, but its new dependence on python-configparser [14:40] barry, seems like we need autopkgtests in python-configglue to make sure it doesn't break all our softwares when updated ;-) [14:40] the latter which seems to break a lot of stuff [14:42] seb128: yeah, i need to untangle all of that. i may have to talk to pindonga about dropping that dep so we can kill -configparser out of the archive [14:42] seb128: you need tests in the packages that depend on python-configglue, you mean :) [14:42] cjwatson, right ;-) [14:42] configglue is fine, configparser is killing us [14:43] dobey, ^ would be nice to have in s-c and u1-syncdaemon [14:43] (well, fine module its dependence on the latter ;) [14:43] seb128: software-center is fixed already [14:43] *modulo [14:43] barry, well, downgrading configglue makes u1 work again [14:43] but yeah [14:43] yeah [14:43] well, i fixed the crash that was caused by configparser [14:44] i don't have time to look right now, but i suspect configglue doesn't *really* need configparser (iow, it can be written against ConfigParser for py2) [14:44] almost certainly [14:44] i'm trying to decide whether it's better/possible to fix configparser or kill it off [14:45] (or at least relegate it to universe) [14:45] kill kill kill [14:45] anyway, it's third on my todo list for today :) [14:46] "backports" of python3 modules onto python2 are evil, and tend to break things in weird ways [14:46] particularly things that have to work on both versions and do things like try: import configparser except ImportError: import ConfigParser [14:46] seb128: is there a bug for the syncdaemon breakage? if not, please file one, i need ammo :) [14:47] dobey: right. it would be much better to be named something that doesn't overlap with a py3 stdlib package name [14:48] barry, dobey: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/1198480 [14:48] Launchpad bug 1198480 in ubuntuone-client (Ubuntu) "ubuntuone-syncdaemon crashed with AssertionError in expand_user()" [Undecided,Confirmed] [14:48] barry: the problem is people write code for py3, and then someone says "i must run this on py2" and so they just take the py3 core module and make it "work" on py2, and ship it as is [14:49] dobey: that is a problem [14:50] it wouldn't be so bad if they were all namespaced into a "py3backports" package or something [14:50] at least then they wouldn't break things that aren't intentionally using them [14:52] cjwatson: btw, today's updates broke x.org for me too :/ [14:53] well, at least the greeter doesn't start [14:53] Hmm, sounds like nobody noticed my request or something:( [14:54] libjpeg-dev in raring is not MA:same (and is arch:all so things which build-dep on it end up getting the wrong-arch version of libjpeg-turbo-dev installed [14:55] * barry thanks his disk snapshots [14:56] barry: all I know about it is what I saw in proposed-migration, which isn't very relevant for this :) [14:56] cjwatson: yeah [14:56] wookey: raring is what it is with regard to multiarch - I suggest getting it fixed in saucy :) [14:57] cjwatson: yeah. I know - I just discoered it there helping someone build his stuff [14:57] and was checking that we agree this is wrong - I know there is a load of complexity around the 'two different libjpegs' fight [14:58] Wellark: hi! [14:58] I don't agree it's "wrong" in that we haven't yet said it's a bug for -dev packages not to be multiarch, but it sounds as though it could be improved [14:59] I'm not totally sure of the intended semantics of Depends: [14:59] Wellark: I saw you are working on unity-action-api - how does the status look like currently? [14:59] cjwatson: it's always wrong SFAIK [14:59] slangasek probably knows [15:00] which is why we fixed it in libdb-dev [15:00] wookey: arguably; but in this case it seems kind of reasonable [15:00] I mean, it's wrong by assertion rather than by obviousness, I feel :) [15:00] although we have a much bigger problem with that sort of things outside C-library world [15:00] (e.g perl modules) [15:00] that said, the current setup means that you can't do B-D: libjpeg-dev, libjpeg-dev:native and have it work [15:00] so that rather suggests that libjpeg-dev Arch: any M-A: same would be more correct [15:01] sil2100: timp is working on integrating it directly to the UITK [15:01] the defined semantics are that the dep of an Arch: all package on an M-A: same package can only be satisfied by the package of the primary arch; if you need something more complex the package needs to be changed to no longer be Arch: all [15:01] sil2100: it should be ready to be used next week [15:01] Wellark: ok, so no daily-releasing for now until that's done? [15:03] Wellark: or will the package be removed completely and integrated into UITK somehow? [15:04] sil2100: the package will be in main. If you are using UITK then you will have it already set up if you use MainView and Page [15:04] sil2100: but if you develop an application that does not use UITK then you can use the direct QML API [15:05] Wellark: ok, all clear - then I'll ping you back again next week, thanks! [15:09] sil2100: np :) [15:09] wookey: uploaded libjpeg8-empty to fix that. [15:10] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:10] * xnox => lunch [15:18] xnox: chers very much![D[D[D[D[D[D[D[D[D[D[D[D[De [15:18] why would libtwin be in raring and previous 4 releases, but not saucy? [15:19] its in saucy..? [15:20] https://launchpad.net/ubuntu/+source/libtwin [15:22] hmm. but it doesn;t appear in http://packages.ubuntu.com/search?suite=saucy§ion=all&arch=any&keywords=libtwin-dev&searchon=names [15:22] that's what confused me [15:22] doesnt look like anything on saucy is on there [15:29] wookey: packages.u.c is out of date I think; don't trust it [15:34] tjaalton: uploaded, sorry for the delay [15:35] tjaalton: can you deal with the fakesync into Ubuntu or want me to? (syncpackage -F deals with that easily these days) [15:40] cjwatson: woot, thanks.. i can handle that part [15:48] Should I normally have to explicitly specify -sa to debuild when preparing a merge? I just got a rejection because I didn't upload the orig tarball. I can do it again with -sa, but just want to make sure that it's expected and I haven't done something else wrong. [15:48] rbasak: Yes [15:49] OK, thanks! [15:58] err, if you use -v, doesn't wit work out if it needs -sa or not? [15:58] rbasak: also correct -v is nice as well. [15:58] tumbleweed: not really, it only incudes tarball for -1 -0ubuntu1, but not like for -3ubuntu1 === Sweetsha1k is now known as Sweetshark [16:16] cjwatson: Sorry for the slow reply; thanks very much for the help. I'll take a look at those packages for inspiration. [16:29] jibel, hey, I just got an email about "Jenkins Failure - saucy-adt-libproxy 42" pointing to https://jenkins.qa.ubuntu.com/job/saucy-adt-libproxy/42/? [16:29] jibel, which has "no test" [16:29] jibel, do you know what's going on there? [16:30] seb128, mkdir: cannot create directory `/dev/shm/adt': Permission denied, it is a problem on the testing node [16:30] seb128, I'll look into this [16:30] jibel, where do you see that? [16:30] jibel, thanks [16:30] jibel, just got a similar one for poppler [16:30] seb128, https://jenkins.qa.ubuntu.com/job/saucy-adt-libproxy/42/ARCH=amd64,label=adt/console [16:30] amd64 -> console output [16:31] thanks [16:31] I was just looking at the "no test" empty page :p [16:31] I didn't think about clicking on the side [16:31] the jenkins UI is not the most obvious thing [16:32] there is no better UI than jenkins ;) [16:33] It's like mpt himself designed it === Guest37969 is now known as mfisch === mfisch is now known as Guest41197 [16:35] seb128, fixed, now I'm wondering how it could lose this mount point [16:35] seb128, I'll re-run poppler and libproxy [16:35] jibel, 'ci [16:38] jibel: glib2.0 too please [16:39] Laney, done too, I re-triggered all the tests that failed [16:39] ah OK, it didn't sound like you had a complete list [16:39] thanks [16:42] seb128, jibel: You may have realized this, but it's easy for "the jenkins UI is not the most obvious thing" and "there is no better UI than jenkins" to be true at the same time. :-) [16:44] mpt, is it? [16:45] If you qualify the second statement with "for the task at hand", perhaps. [16:45] Sure, if the state of the art is terrible [16:45] I could probably vomit a better UI than Jenkins. [16:56] infinity: but if you do, you should seek medical attention === olli_ is now known as olli === psivaa is now known as psivaa-afk === dholbach_ is now known as dholbach [17:44] mdeslaur: Could you please either merge php5 or tell me I can? It's important for the Apache 2.4 transition in progress. [17:45] cjwatson: Robie was going to look at php5. [17:45] rbasak: ^ === directhe` is now known as directhex [18:33] Greetings, is there a way to stack on a read only persistent layer when booting live cd? Say like casper-ro? [18:33] I ask since I would like to deploy live image with some additions and make them act more like a firmware install. [18:34] unixabg: perhaps overlayfs can get you there [18:36] sarnold: First thank you for the response, can I do this with a defalut official ubuntu live iso? [18:37] I am trying to avoid remastering so I can stay with current releases. [18:37] unixabg: if you have a live image booted, check /proc/filesystems for overlayfs [18:39] sarnold: booting one now, one moment.. [18:43] sarnold: ok booted, and cat /proc/filesystems lists : nodev overlayfs [18:46] barry: the big problem seems to just be that configglue now returns unicode() for lots of things on py2 where it used to return byte strings as str() [18:46] barry: at least, as far as configglue/configparser relates to breaking ubuntuone-syncdaemon [18:47] sarnold: I am not sure how to utilize to achieve ro persistence with default iso. I can configure entries in grub if this helps. === Guest41197 is now known as mfisch [18:48] dobey: let me see if i can get pindonga in on the conversation === mfisch is now known as Guest1021 [18:50] pindonga: hi [18:50] hi [18:50] barry: the big problem seems to just be that configglue now returns [18:50] unicode() for lots of things on py2 where it used to return byte [18:50] strings as str() [18:50] barry: at least, as far as configglue/configparser relates to breaking [18:50] ubuntuone-syncdaemon [18:50] blah, ugly paste [18:50] right. it's probably the result of configglue returning unicode() instead of bytes [18:51] err [18:51] pindonga: so, python-configparser broke software center, is breaking syncdaemon and virtualenv too [18:51] configparser returning them, that is [18:51] barry, well, python-configparser is a backport of the py3 configparser, yes? [18:51] which is backwards incompatible with py2's ConfigParser [18:51] which of course breaks everything [18:52] pindonga: it's backwards-incompatibile with the fact that python2 doesn't use unicode by default [18:52] at least, that's why it is breaking ubuntuione-syncdaemon [18:52] so, what's the issue here? why is python-configparser needed? [18:52] pindonga: configglue is depending on it, and thus pulling it in [18:52] pindonga: it's a dependency on -configglue now afaict [18:52] ie, if we're not packaging the latest configglue it should be no problem yes? [18:53] right, why do we need the latest configglue then? [18:53] pindonga: we're packaging it now :) [18:53] 1.1.0 is in sauncy [18:53] 1.0.3 should work fine with py2 [18:53] err saucy [18:53] 1.1.0 and 1.1.1 are py3 compat [18:53] pindonga: for py3 in saucy [18:53] yes, but it breaks compat with py2 [18:54] because things that were str() in python2 are now unicode() [18:54] ok, what do you suggest? [18:54] pindonga: how difficult would it be for py2 configglue to just use stdlib ConfigParser instead of python-configparser? [18:54] why don't we ship 1.0.3 ? [18:54] barry, the main problem is that it won't work with py3 [18:54] pindonga: try: except: like everyone else that supports both versions? [18:55] well, if we want to support both versions, maybe ;-) [18:55] pindonga: sure, but configglue is now py2 and py3. so you could use `from ConfigParser import ConfigParser` for py2 and wrap that in a try/except [18:55] I can give it a try [18:55] with the except being `from configparser import ConfigParser` [18:55] pindonga: well, "want" is a strong word. we have to support both versions :) [18:55] I can't guarantee it'll work, but I'll let you know if I manage to [18:56] or we have to ship two different versions of configglue [18:56] there are many changes between py2 and py3 in ConfigParser [18:56] too many [18:56] pindonga: do the py2 import in the try [18:56] barry, the main problem is the api changed [18:56] so it's not just like changing the import [18:56] pindonga: do you use the new api? [18:56] pindonga: are you actually using the new API? [18:56] afaik there is only one api [18:57] as said... will give it a go and see what happens [18:57] my initial attempts were'nt successfull [18:57] hence I opted for the backported configparser [18:57] barry: do we even ship any applications that use configglue on python3? [18:58] pindonga: thanks for giving it a shot. i can help out more later today [18:58] i don't think we do [18:58] dobey: not yet, but it's a dep for porting other things we need to get off of py2 [18:58] dobey: e.g., yeah you guessed it: ubuntuone-client [18:59] ubuntuone-client is the only thing that uses configglue at all, really [18:59] unless you plan to port django as well :) [18:59] really, i think python-configparser is quite ill-advised and i am going to contact upstream about "the problem" [19:00] doesn't django already support py3? maybe not packaged yet, but that's a SMoE [19:00] :) [19:01] i'm just saying, it's ubuntuone and a module for django to use configglue in a django app. those are the only things in ubuntu that use configglue; and now they're both broken :) [19:01] dobey: yeah :( [19:02] unixabg: I'm not entirely sure how you'd use it either, but it -is- a mechanism to overlay one FS on top of another [19:36]