[04:44] Good morning [04:45] infinity: I don't think they were [04:45] infinity: I checked the upload log, and there was just one package that it tried to upload to ppa.launchpad.net, failed with "connection refused", and then it stopped [04:46] nothing else [04:46] infinity: the log timestamps coincide with the failed upload log at least [04:46] WTF?? [04:47] * pitti mass-rejects [04:49] infinity: so this remains a complete and utter mystery to me; PPA upload seems broken again (firewall changes?), but then the script should (and according to the log, did) break, not upload to other places [04:56] infinity: oooh *headdeask* I know what happened [04:59] infinity: I guess the next time it auto-uploaded quantal packages, the failed list of precise/lucid packages were still in "updated-packages" (the file with the upload list), and so it uploaded those along [04:59] I'm not sure how that dodged the "if test -s updated-packages; then exit 1" command, though [05:00] test -s updated-packages && exit 1 ? :-) [05:00] well, there's an echo in between as well [05:00] StevenK: but that should essentially be the same? [05:01] * pitti asks IS for fixing firewall rules [05:01] pitti: Yeah, that's why I suggested it, it avoids an if, but since there's an echo there's no point. [05:05] aah, I know [05:05] * pitti fixes [06:57] good morning [07:13] morning all === mcclurmc_away is now known as mcclurmc [07:46] i've forgot again.. how to disable multiarch on quantal? just getting rid of /etc/dpkg/dpkg.cfg.d/multiarch isn't enough [07:46] not that useful on chroots [07:47] at least when not mirroring i386 locally, making sbuild-update fail === smb` is now known as smb === henrix_ is now known as henrix === henrix is now known as henrix_ [08:31] /whois Daviey Daviey [08:31] === henrix_ is now known as henrix [08:32] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh [09:33] mpt: we're getting kernel crashes sent to daisy.ubuntu.com. I know this because the code mistakenly attempts to insert their very large core files into Cassandra. [09:34] ev, that's a problem then, because (as far as I could tell from the code) the UI for that class of error doesn't exist, so whatever UI is being used to send them is bound to be confusing. [09:35] (doesn't exist yet, anyway) [09:35] KernelCrash? [09:35] Hm, did I just read it and then completely forget it existed? :-] [09:36] * mpt looks again === doko_ is now known as doko [09:39] ev, it calls get_system_application_title(), which shows "Sorry, Ubuntu has experienced an internal error." I guess that's strictly accurate, but not the intended text. [09:41] indeed [09:41] mind that we're only seeing these a few times a day [09:41] and we don't have the ability to retrace them yet [09:42] (lp:apport, bin/apport-retrace:354) [09:42] that's not to say we shouldn't fix the dialog [09:44] Sure, though fixing bug 1033902 would be much more important if it happens much more often [09:44] Launchpad bug 1033902 in apport (Ubuntu) "Application thread crash shows application crash error alert" [Undecided,Confirmed] https://launchpad.net/bugs/1033902 [09:44] yeah, definitely [09:45] Annoying that that missed UI Freeze [09:45] ev, so do you think we're getting only a small percentage of kernel crashes from typically-reporting machines? "A few times a day" might actually be right, compared with (for example) 173/day for the current #1. [09:46] I think so. If you look at https://errors.ubuntu.com/oops-local, any exception with MaximumRetryException is likely a kernel crash. [09:49] slangasek: A ucf prompt that isn't actually displayed to you seems like it must be a package management bug rather than a bug in the package [09:51] mpt: I'll silently drop them at daisy.ubuntu.com and increment a counter for the day period so we at least know how many we would be getting [09:55] tjaalton: dpkg --remove-architecture i386 [09:57] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh, cjwatson [10:02] ev, there are four bugs apparently reducing the proportion of kernel errors reported: bug 401370, bug 480421, bug 527026, and bug 624562. [10:02] Launchpad bug 401370 in apport (Ubuntu) "when attempting to report a kernel crash, apport-gtk enter D wait state" [Undecided,New] https://launchpad.net/bugs/401370 [10:02] Launchpad bug 480421 in apport (Ubuntu) "apport won't report vanilla kernel oops" [Undecided,New] https://launchpad.net/bugs/480421 [10:02] Launchpad bug 527026 in apport (Ubuntu) "Apport is unable to report a bug on a kernel that you are not booted into" [Undecided,Confirmed] https://launchpad.net/bugs/527026 [10:02] Launchpad bug 624562 in apport (Ubuntu) "Reporting kerneloops fails with "permission denied"" [Undecided,Confirmed] https://launchpad.net/bugs/624562 [10:03] and I just reported bug 1051891 about the UI text. [10:03] Launchpad bug 1051891 in apport (Ubuntu) "Kernel crash/oops shows confusing UI text" [Undecided,New] https://launchpad.net/bugs/1051891 [10:04] mpt: to be clear, kernel crashes and kernel oops are different [10:04] the former is when you get a full kernel panic and it dumps its brain into a file (if it even can) [10:04] the latter is a sort of recoverable error [10:04] things keep chugging along and you get an OOPS! in the syslog [10:05] Ok ... they're treated the same in apport-gtk currently. [10:05] So, an oops *should* have the "Ubuntu just had an internal error" text, then [10:05] it's only a crash that shouldn't [10:05] yes, I reckon [10:05] ? [10:05] correct [10:06] at least that's my understanding [10:07] updated the bug report [10:10] fixed the specification too [10:14] cjwatson: thanks, found it on the debin wiki too, added to the askubuntu question === mcclurmc is now known as mcclurmc_away === xymox_ is now known as xymox [10:54] xnox: hey, is ubiquity still in gtk2 or using pygi? [10:55] didrocks: it's using pygi & python3 [10:55] cjwatson: currently installing quantal beta 1 to another machine from exactly the same usb stick, and seems to work great [10:55] akheron: ok, I still have a task for today to investigate it though [10:55] cjwatson: fwiw, I had to use the nomodeset kernel option with the first one [10:55] didrocks: some elements do not use width-for-height widgets, e.g. there are GtkBox here and there. [10:55] nomodeset -> not my problem [10:55] with the machine that fails [10:55] ok [10:56] akheron: I didn't mean to say that the name server was broken, BTW, only that something had gone wrong with resolver configuration within the target chroot [10:56] xnox: hum, ok, I'm wondering about bug #1049215 as gnome-bluetooth stacktrace is about using pygi as well [10:56] Launchpad bug 1049215 in gnome-bluetooth (Ubuntu) "ubiquity-bluetooth-agent crashed with ImportError in /usr/lib/python3/dist-packages/gi/__init__.py: could not import gobject (error was: EOFError('EOF read where not expected',))" [Medium,New] https://launchpad.net/bugs/1049215 [10:56] This is a plausible enough failure mode, sadly [10:56] not sure what imported gobject [10:56] cjwatson: yeah [10:56] didrocks: ubiquity doesn't even support python2 any more [10:57] didrocks: but if it's calling some external process which uses python2, that's a different mattere [10:57] -e [10:57] yeah, bluetooth-applet [10:57] cjwatson: I guess it's the case [10:57] nowt to do with ubiquity [10:57] it's pretty obvious from the traceback :) [10:57] cjwatson: hum? bluetooth-applet is using pygi [10:57] from gi.repository import GObject [10:57] ? [10:58] Wait, that's actually ubiquity's substitute bluetooth-agent [10:58] hmmm.... I totally missed that.... [10:59] didrocks: I usually sudo vi /usr/share/pyshared/gobject/constants.py and do something like raise TypeError("not static") [10:59] cjwatson: you lost me :) [10:59] this will give a proper backtrace which sub-sub-submodule imports the static bindings [10:59] didrocks: I lost myself for a bit [10:59] didrocks: ubiquity-dm fakes a desktop session and half of indicators to provide "ubuntu style session" which only shows ubiquity =) [11:00] but I didn't think bluetooth was one of them. === MacSlow is now known as MacSlow|lunch [11:01] I can run the imports at the top of ubiquity-bluetooth-agent without any problem though [11:01] Puzzling. Anyway I should get back to piloting ... [11:02] xnox: cjwatson: I confirm gnome-bluetooth is using pygi [11:02] xnox: did you reproduce it? [11:02] I've seen this strange EOFError on a totally different context recently (in a bug report); I think doko attributed it to mis-installation [11:02] bug 1029683 [11:02] Launchpad bug 1029683 in Ubuntu "import causes EOFError: EOF read where not expected" [Medium,Invalid] https://launchpad.net/bugs/1029683 [11:02] xnox: if so, you can do what pitti is telling to know which component is the guilty one :) [11:02] didrocks: if you cannot reproduce, maybe something else happened, e.g. somebody yanked their installation media hence that file was actually empty / EOF =) [11:03] possibly [11:03] pitti, wasn't this one where the reporter even did say that the machine was hanging? [11:03] but as that's the third report in a few days, I'm beginning to become suspicious [11:03] didrocks: gnome-bluetooth is irrelevant [11:03] perhaps something does create zero-byte files somewhere [11:03] * didrocks retarget on xnox's plate then :) [11:03] didrocks: casper dpkg-diverts away the bluetooth-agent from gnome-bluetooth, and replaces it with a symlink to ubiquity-bluetooth-agent [11:03] doko: no, not this one; there might be more dupes, though [11:04] cjwatson: ah ok, so the /usr/bin/ is not the one we can expect, thanks for the info :) [11:04] tumbleweed: looking at bug 1049343 and slightly puzzled by it being a sync - doesn't the reporter say there's a patch to be reapplied? and he seems to be right [11:04] Launchpad bug 1049343 in Ubuntu "FFe: Un-blacklist and sync sensors-applet 3.0.0-0.2 (universe) from Debian testing (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1049343 [11:05] didrocks: ok ;-)( [11:05] didrocks: ok ;-) [11:05] cjwatson: ah, whoops, I forgot about that [11:06] cjwatson: I did ask him on IRC to prepare the patch, a week ago, and clearly he hasn't [11:06] (and today, I just saw that it built, and remembered that it had seemed reasonable) [11:07] didrocks: looking at the code, there were GObject vs Gobject typos fixed in the past, maybe this is a bug report from an acient image?! [11:07] xnox: hum, I think you would get an import error and not this "library mixture" error one (pygtk was gobject, not Gobject) [11:08] xnox: the report makes the image version clear [11:09] didrocks: cjwatson: yeah, it's a recent image and the import is the correct gi one GObject. === tkamppeter_ is now known as tkamppeter [11:45] hum, seems I can't nominate for Quantal anymore? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1045845/+nominate [11:45] Launchpad bug 1045845 in xorg-server (Ubuntu) "12.10 guest crash on login when using 12.04 qemu-kvm with cirrus driver" [Medium,Confirmed] [11:45] didrocks: screenshot? [11:46] hmm, same for me with that link [11:47] nothing between the precise and r-series checkboxes [11:47] right, same [11:47] cjwatson: do you still want a screenshot? [11:47] Yes. [11:47] Oh, wait, I see what you mean. No. [11:48] ok :) [11:48] You can't nominate for quantal because apparently it was already nominated for quantal and that bug task was then deleted. [11:48] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1045845/+activity [11:48] Launchpad bug 1045845 in xorg-server (Ubuntu) "12.10 guest crash on login when using 12.04 qemu-kvm with cirrus driver" [Medium,Confirmed] [11:48] cjwatson: oh interested, I didn't know about that feature :) [11:48] http://people.canonical.com/~ogra/quantal.png [11:49] oh,. wow [11:49] You'll find you can nominate other bugs just fine. [11:49] ok, but I guess jamespage just nominated them by error and then reverted [11:49] It's arguably a Launchpad bug that you can't re-nominate, so please make sure that's filed. [11:49] Well, re-target. [11:49] but no way to give it back then? [11:49] Not that I can see. [11:49] Please file an LP bug. [11:49] cjwatson: will do, thanks :) [11:50] didrocks, gah - sorry - I was not aware of that bug [11:50] jamespage: well, I wasn't as well :) [11:53] bug #1051918 [11:53] Launchpad bug 1051918 in Launchpad itself "Can't renominate a bug when a nominated task was deleted" [Undecided,New] https://launchpad.net/bugs/1051918 === mcclurmc_away is now known as mcclurmc [12:10] hi [12:10] can someone help me understanding a piece of bash in a cron daily script ? it's related to the permissions on a file [12:11] it's about this version of mlocate : http://packages.ubuntu.com/precise/mlocate [12:12] Sure. What don't you understand? [12:13] hi cjwatson : I would like to know if the file /usr/bin/updatedb.mlocate is supposed to be executable. is it, or is it not ? and is the cron supposed to make it executable "on the fly" ? === _salem is now known as salem_ [12:13] it should be executable (at least it's here) [12:14] it's lines number 3 to 5 whic make me think so: http://pastebin.com/N2CWL1TR [12:14] melodie: It's shipped executable in the package. [12:14] melodie: There is no reason the cron script should need to change its permissions. [12:14] cjwatson, ok, I thank you. [12:14] geser, thank you too [12:14] The -x test there is really just "is it there", actually. -f would have been fine too but -x is a bit more exact. [12:14] all right [12:15] (Or -e, for that matter.) [12:15] But it's correct as it is. [12:15] is this package issued from Debian sid, or Debian testing ? in testing they have the same version number, but I am unable to find how the permissions are setup in the package (which bugs me) [12:16] It doesn't matter where it came from. Testing comes from unstable. [12:16] melodie: as you can remove the package (but leave the configuration files installed incl. the cron-snippet), the cron-snippet has to check if the binary is still there [12:16] I expect that the permissions are not explicitly set up at all. The compiler will emit binaries as executable right from the start. [12:16] oh ! I see ! [12:17] There's no need to override permissions explicitly when they're correct already. === MacSlow|lunch is now known as MacSlow [12:18] cjwatson, so if the permissions are not right, it can be the fault of the configurations done in the compiler ? === ara is now known as Guest39435 [12:23] Most packages will run the dh_fixperms program during building which does some normalisation of permissions and owners (by default). [12:24] melodie: Are the permissions wrong, or is this theoretical? [12:24] melodie: In fifteen years of working on Unix I have never seen the compiler get this wrong, so I don't think the theoretical point is interesting. [12:25] cjwatson, the permissions are wrong in my virtualbox machine. Your information allowed me to eliminate a possible source for this issue. the guilty one is the vbox machine. [12:25] melodie: Is this an environment that has been upgraded from some earlier version? [12:25] And does reinstalling the mlocate package fix it? [12:25] the original system has the right permissions. the spin has wrong permissions [12:26] "spin"? === cpg is now known as cpg|away [12:26] a remix if you prefer [12:26] I still don't know what you're talking about :) [12:26] *Which* remix? [12:26] a project I am training on in a vbox machine. :) [12:27] Does reinstalling the mlocate package fix it? [12:27] nothing very important but I was wondering if there was a bug somewhere [12:27] cjwatson, this could be, I am going to check. [12:27] I expect this is a bug in the remix's image build process. [12:28] I think it can also come from something in the virtualbox machine. I am not hundred percent sure that using it for remix is a good idea [12:29] cjwatson, reinstalling does fix the issue. thank you ! [12:30] cjwatson: got the embedded image of grub2 bigger with the recent package upload? because I got hit by bug #1051154 with the recent updated (it worked till now with RAID and LVM) [12:30] Launchpad bug 1051154 in grub2 (Ubuntu) "[quantal] warning: your embedding area is unusually small. core.img won't fit in it." [Undecided,Confirmed] https://launchpad.net/bugs/1051154 [12:31] geser: wouldn't be surprising. I'll look later [12:31] geser: may not be terribly fixable [12:31] 62 sectors is very little space to fit anything useful in ... [12:32] wait, "embedding area is unusually small" means there's even less than 62 sectors [12:33] I wonder if that's lying, since it doesn't match the fdisk output there [12:33] anyway, must finish piloting first. [12:35] I can add my fdisk output too to that bug later (if it helps) [12:36] sure [12:39] cjwatson: re: LP bug #978654, I believe the correct thing to do there is to leave the .decode() call for as long as pkcompat.py is python2 (i.e. 12.04/12.10). When it's ported to python 3, that change should be reverted. [12:39] Launchpad bug 978654 in aptdaemon (Ubuntu) ": 'ascii' codec can't decode byte 0xc3 in position 24: ordinal not in range(128)" [Medium,In progress] https://launchpad.net/bugs/978654 [12:40] cjwatson: it's not the only call to dbus.String(), and I don't think we want to change all the calls to include the decode() + the guard if... [12:43] @pilot out === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson [12:45] alkisg1: No, I disagree. Leaving timebombs around for ourselves is unwise. [12:45] alkisg1: The guard I suggested is safe in Python 2 as well. [12:45] alkisg1: Unless pkcompat will *never* be ported to Python 3. [12:45] cjwatson: there are multiple dbus.String() calls in the code, a wrapper function for dbus.String() should probably be defined then [12:45] In fact, there is already a python3-aptdaemon.pkcompat package. [12:46] cjwatson: my idea is that when it's ported to python3, decode() won't be needed, so it should only be there until it is [12:46] So the "it's only Python 2" argument is definitely invalid. [12:46] A better counterargument, if you wanted to avoid this, would be to demonstrate that last_update can never be assigned a Unicode string. [12:46] But I don't know whether that's true. [12:47] So, you'd vote for a call-dbus-string() wrapper for all of the calls? [12:47] Or just for this one call? [12:47] I don't know enough of the context. It would depend. [12:48] I suggest you look into how these functions are called (i.e. answer my question above). [12:48] aptdaemon$ grep -r dbus.String * | wc -l [12:48] 109 [12:48] I think that looking into 109 calls would be too much work [12:49] Well, I'm not going to sponsor a change when I'm not convinced it's safe [12:49] I.e. some wrapper would be easier. Or, just leave it without a wrapper, since it's more clearly written for python 3, and only fix that one call for the python2 in 12.04/12.10 problem [12:49] you could train your sed skills with it ;) [12:49] But since this is implementing a (presumably) defined interface, why not look into what defines that interface ... [12:50] I wouldn't have expected most of those calls to be relevant; many of them may well be operating on always-bytes data [12:50] Or, sorry, I mean always-text (Unicode) [12:50] As usual with Python 2/3 porting you need to make sure that you know whether each object is binary or text. [12:51] So the idea is that the code should be python2 compatible even if it's ported to python3? [12:52] What I don't understand is why would we want the decode() functions in a python3 port of the code [12:52] We don't want to have to maintain separate Python 2 and 3 versions. [12:52] It's a horrendous hassle. [12:53] OK, I thought the python2 version wouldn't be developed anymore [12:53] For most packages, as long as they still build Python 2 versions, they should be written in code that's compatible with both. [12:53] That's not usually how it works. [12:53] Gotcha [12:53] The Python 2 binary package comes from the same source package as the Python 3 one. [12:54] OK, then it's a bigger problem than what I have time for. I can't study someone else's code for 109 occurances of possible time bombs... [12:54] Thank you very much for your input, I'll unassign the bug [12:54] Looking at the code, it seems clearly possible for this method to receive text input. [12:55] alkisg1: I think you're overreacting [12:55] alkisg1: You don't need to do any such study [12:55] alkisg1: You're proposing a change to this one method, and it may well be that in practice this is the only method where this is a problem [12:55] cjwatson: my idea was that this would be a quick patch, and that the person undertaking the python3 port would solve it properly [12:56] alkisg1: If written in the style I suggest, this change would be harmless; it might not fix everything, but it would be an improvement [12:56] I.e. either make a wrapper function for all dbus.string calls, or fix the ones that need decoding, etc [12:56] alkisg1: You seem to be suggesting that no change should be made until it is perfect, which is not usually a wise approach [12:56] All I'm saying is that this change should be written in a way that means it's clearly not a regression [12:57] I'm not saying you need to audit all those dbus.String calls, at all [12:57] Well, currently the script isn't runnable with python3 [12:57] So it wouldn't be a regression [12:57] Which script? [12:57] pkcompat.py [12:57] The file you're editing is shipped in python3-aptdaemon.pkcompat [12:58] It may have '#!/usr/bin/env python' at the top, but it is principally a module to be imported from other programs, not principally a script to be run standalone [12:58] So I don't consider the #! line very relevant [12:59] OK, I thought it was to be revisited by someone for python3 compatibility [12:59] If you run python3 you can then say 'from aptdaemon import pkcompat' and it works [12:59] It has already been ported to Python 3 [12:59] I suspect that in fact the reported problem that you're debugging only exists in Python 2 [13:00] True, dbus.String() can accept unicode strings in python3 [13:00] So it's not a lack of port to Python 3, it's (perhaps) a slightly overenthusiastic port, if anything [13:00] dbus.String can accept Unicode strings in Python 2 [13:00] as well [13:00] What it can't accept is a Unicode string encoded as bytes [13:01] >>> dbus.String(u"é") [13:01] dbus.String(u'\xe9') [13:01] >>> dbus.String(u"é".encode("UTF-8")) [13:01] Traceback (most recent call last): [13:02] If you pass bytes to dbus.String() in Python 3, in an odd reversal of the usual situation, it doesn't crash, but it produces incorrect results due to the behaviour of str(bytes): [13:02] >>> dbus.String("é") [13:02] dbus.String('é') [13:02] >>> dbus.String("é".encode("UTF-8")) [13:02] dbus.String("b'\\xc3\\xa9'") [13:03] So this demonstrates that in both Python 2 and 3 you *must* pass text (Unicode) to dbus.String and it is incorrect in both worlds to do otherwise [13:03] Aaah I didn't realize that part [13:03] Thus, I'd suggest that perhaps you should be looking further up in the traceback heree [13:03] I did say it wrongly above (unicode instead of utf8 strings), but I thought python3 would correctly handle utf8 strings (byte sequences) [13:04] i.e. don't change last_package_setter at all - leave its interface as being defined to take Unicode strings only [13:04] What I'm saying though, is that someone needs to have a look at all those calls [13:04] My only part in this is because students get an apport dialog [13:04] For this bug, somebody needs to have a look at *this* call [13:04] Please don't let the perfect be the enemy of the good [13:04] And instead of disabling apport, I thought I'd invest a few minutes to help there [13:04] I understand the problem, and I really think it's a job for the maintainer [13:05] It shouldn't need to be [13:06] I really thank you for your time, and I'm not avoiding this due only to time constrains. I really feel that it's a bigger problem that I shouldn't tackle. It needs a better solution, and personally I'd go for a wrapper function, to avoid all possible cases at once. [13:07] I really don't think that's right [13:07] A wrapper function is missing the point [13:07] These functions are (implicitly) defined to take Unicode strings only - a wrapper function would be masking bugs elsewhere [13:07] In this case, I believe I see the bug [13:08] Look in 'def _get_id_from_version' [13:08] origin = version.origins[0].label [13:08] A wrapper function could log + fix the problems elsewhere [13:08] No [13:08] I'm not going to pursue that [13:08] I.e. have the devs notified without having the users apps breaking [13:08] I bet (though I'll check) that version.origins[0].label is bytes, not text [13:10] alkisg1: What is the URL for the PPA you used in your example (https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/978654/comments/12)? [13:10] Launchpad bug 978654 in aptdaemon (Ubuntu) ": 'ascii' codec can't decode byte 0xc3 in position 24: ordinal not in range(128)" [Medium,In progress] [13:10] cjwatson: https://launchpad.net/~ts.sch.gr/+archive/ppa/+packages === jcastro_ is now known as jcastro [13:11] Thanks [13:13] We have about 20 papercut-like problems in schools here. E.g. we can't type greek due to lightdm not supporting multiple layouts, we have aptd, colord, apport etc crashes, sshfs problems... we try to help where the fixes are simple, but we don't have time to dive + properly fix all those cases [13:14] pitti: I'm just wondering if bug #1051951 could be related to bug #952933 but I'm pretty sure I saw you and seb128 say that you would push the fix upstream to debian, it's just it has the exact same symptoms [13:14] Launchpad bug 1051951 in gvfs (Ubuntu) "sansa fuze and samsung s3 phone are both shown as usb drive not devices" [Undecided,New] https://launchpad.net/bugs/1051951 [13:14] Launchpad bug 952933 in gvfs (Ubuntu) "media players do not trigger "Open with Music Player" dialog" [Medium,Fix released] https://launchpad.net/bugs/952933 [13:14] Sure, you can do whatever you like locally of course, but this is a merge proposal into Ubuntu so I want to do the right thing and not mask bugs [13:14] So e.g. for lightdm we're using an /etc/X11/Xkbmap override, and we have to leave the proper fix up to the maintainer, even if it needs more than 1 year now [13:14] Especially since it doesn't look too hard to do the right thing here [13:15] In fact, add-apt-repository has a similar problem (still :-/) [13:16] cjwatson: Origin's label has Python's standard string type. [13:17] Indeed. [13:17] So in Python 2 that needs to be encoded if the desired type is in fact text. [13:25] tjaalton, yeah for http://people.canonical.com/~ubuntu-archive/nbs.html \o/ [13:25] what did break the build dependencies? [13:25] doko: libglu not accepted yet? [13:25] eh, that's transient [13:25] it's in NEW I think, mesa dropped it [13:26] yeah [13:26] doko: feel free to process that in NEW :) [13:26] ok, looking at it [13:26] cjwatson: Yes, and placing something like get_dbus_string() in tests/regressions/aptdaemon/core.py into a common module would be useful for fixing this aptdaemon bug. (try: return dbus.String(text), except ...: return dbus.String(text.encode("utf-8")) [13:27] juliank: Well, I think the fix in aptdaemon actually belongs several layers up. [13:29] tjaalton, all the code was in mesa before? [13:30] doko: yes [13:31] should be safe to accept [13:31] cjwatson: I don't think it can be fixed on any other level. The fact is that python-apt has a 'str' API, and python-dbus a 'unicode' API. You could change python-dbus to accept utf-8 encoded byte strings, but I don't think this is sensible. You can also change the applications to set the default encoding to UTF-8, which fixes this as well. [13:31] packaging was copied straight from it, debian/copyright should be accurate etc :) [13:32] juliank: I think you're misunderstanding me. [13:32] juliank: The fix in aptdaemon belongs at the point where it retrieves data from python-apt, not in the methods that construct dbus.Strings from values. [13:33] juliank: These are several layers apart in the call stack. [13:33] juliank: I didn't mean to say that it should not be fixed in aptdaemon; it clearly should. I meant several layers up *within aptdaemon* from where alkisg1 was suggesting. [13:34] accepted [14:02] alkisg1: It seems fairly complicated to set up a reproduction environment for this bug. Would you mind testing http://paste.ubuntu.com/1211094/, which I believe should fix it? [14:03] cjwatson: sure, give me a minute to test with the other guy that set up the reproduction environment... [14:05] Hah, although python-aptdaemon.pkcompat has actually been removed from quantal [14:05] But this won't hurt and will provide a better basis for an SRU [14:08] cjwatson: works as expected :) [14:08] (tested with python2, precise) [14:09] Hooray [14:11] alkisg1: Perhaps somebody could add a test case to the bug description, in the form required by https://wiki.ubuntu.com/StableReleaseUpdates? [14:11] I can try to [14:14] @pilot out === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [14:16] * dholbach hugs cjwatson :) [14:20] alkisg1: I've uploaded a fix to precise-proposed, pending approval. The test case will help that. :-) [14:20] cjwatson: ty, /me is still writing... :) [14:27] cjwatson: done, as well as I could write those... :) [14:40] alkisg1: thans [14:40] *thanks [14:40] np, thank you too and sorry for not doing it myself the way you pointed [14:40] np [14:41] I just feel that larger bugs should be handled by the maintainers... /me is probably just getting too old for this... :) [14:42] Well, I'm not an aptdaemon maintainer [14:42] So unless you're saying I shouldn't have handled it ... [14:42] age is not an excuse [14:42] (i think colin is older than you :P ) [14:45] I surely appreciate that you've handled it, but shouldn't the maintainer have a look at all the other 108 dbus.String() calls? [14:46] No, because that's a red herring [14:46] The problem is not dbus.String; the problem is the interaction with a different string model in python-apt [14:47] And I grepped for other uses of Origin.label, and fixed the one other case of that [14:48] bryceh, about 1050674: is this a copy of the existing driver packaging, or are these maintained somehow together? [14:48] It's sometimes a mistake to microfocus on the bottom level of the traceback - what you want is for types to be correct all the way through the program [14:49] So e.g. "BackendAuthor": dbus.String(__author__), => are we sure that won't be utf8? [14:49] Yes, because it is a hardcoded constant! [14:50] And we're sure no e.g. chinese guy will be the author in the next year? [14:51] Any future changes will be to the Python 3 code where this won't arise. [14:51] Since "..." is a Unicode type in Python 3. [14:51] I thought we wanted to maintain a python2 + python3 compatible version [14:51] Can you just drop it? [14:51] Sure [14:51] python-aptdaemon.pkcompat actually no longer exists in quantal. [14:51] I don't mean to chat just for the ...fun of it [14:52] We both have lots of things to better invest our time in :) [14:52] Thank you again. [14:52] And the reason I'm not harping on dbus.String is that any problems of that form would be *separate bugs*. [14:52] They wouldn't really be the same as this one; they would need to be addressed in entirely separate ways. [14:52] I don't think it's worth doing a full audit for that. [14:53] This bug isn't really about dbus.String, it's about incorrectly fetching information from python-apt. [14:53] So I focused on the general case of that, not on the general case of dbus.String handling. [14:53] Much appreciated; let's move on to other matters :) [14:54] I don't mean to snap; I just feel you were pushing me about a generalisation of the problem that I don't actually think is the right generalisation to be looking at. I did look at the generalised version of what I felt was the correct characterisation of the bug. [14:56] cjwatson: I honestly have/had etc no hard feelings or anything else bad for you; I also didn't mean to push anywhere etc. I _am_ actually not always understanding the way you (and all ubuntu devs) choose to handle some stuff. [14:57] That's probably because after 4 years I'm still not sure where the upstream / distro maintainer / bug triager seperation is, exactly [14:57] hi again [14:59] I think after 20 years of being upstream for some programs, it's hard for me to think as a bug reporter / distro maintainer [14:59] I do have a general question. I have tried to follow the "UbuntuFromScratch" howto at the Ubuntu website and I have almost reached the end of it (while building the way it is explained). At the end, I see things that I am almost sure I will not be able to handle without some extra help, either because I don't understand, or because it might be outdated for some parts. Is there a chan where I could get help on making a Remix (from scratch) [14:59] ? [15:00] Well, ideally upstream (who's mostly glatzor) would have addressed this, but since it's mostly a legacy Python 2 matter I decided to just go ahead and fix it and he can pick up the patch if he wants to. === salem_ is now known as _salem === hggdh_ is now known as hggdh [15:46] doko, the packaging is maintained in the same git tree as the normal driver, on its own branch. So yes to both. [15:53] * Laney is glad that he enjoys playing whack a mole on broken fontconfig configuration files === _salem is now known as salem_ [15:58] * ogra_ wonders why such a little script http://paste.ubuntu.com/1211296/ actually reserves 3MB when running it [15:58] gtk2-perl clearly got bloated since i looked last === Ursinha` is now known as Ursinha === Ursinha is now known as Ursula === Ursula is now known as Guest90196 === Guest90196 is now known as Ursinha === Guest56315 is now known as zumbi === zumbi is now known as Guest95171 === dendro-afk is now known as dendrobates === infinity_ is now known as infinity === cmagina is now known as cmagina_away [16:45] pitti: So, I assume you rejected all those lucid uploads? [16:46] pitti: If so, you missed the ones in NEW. [16:46] * infinity finds the others in the rejected queue and confirms before dumping the new ones too. === Guest95171 is now known as zumbi [17:47] I have a fix for a bug, how can I submit? [17:47] blackbug: attach a patch to that bug?! === mcclurmc is now known as mcclurmc_away [17:52]