| === yofel_ is now known as yofel | ||
| === slank is now known as slank_away | ||
| === chiluk is now known as chiluk_away | ||
| === chiluk_away is now known as chiluk | ||
| === megha is now known as database | ||
| === rickspencer3_ is now known as rickspencer3 | ||
| jdstrand | micahg: re imagemagick> hi! no, I'm not actively working on it | 03:30 |
|---|---|---|
| pitti | Good morning | 05:26 |
| stgraber | good morning pitti (my usual reminder that going to sleep for a bit might be a good idea ;)) | 05:28 |
| pitti | stgraber: heh, happy to be of service :) | 05:30 |
| randimiller | Are there any mentor programs for someone that wants to start contributing? | 07:02 |
| randimiller | Looking to challenge myself a bit more, so looking at contributing to a linux distro. | 07:03 |
| xxtjaxx_ | Quick question: Ubuntu uses update-alternatives right? | 07:15 |
| infinity | xxtjaxx_: Yes. | 07:25 |
| xxtjaxx_ | infinity: Thanks | 07:30 |
| === chiluk is now known as chiluk_away | ||
| magn3ts | Would it be possible to tie into dbusmenu to dynamically insert an entry in GtkMenus across applications to create a special menu that would enable HUD like functionalities in non-Unity environments? | 08:11 |
| magn3ts | I'm assuming the same way GTK was patched to push stuff into dbusmenu, one could also patch it to create a new menu that can scrape back from dbusmenu and then provide search functionality? Or maybe if there is a libhud or something that one could directly tie into ? | 08:12 |
| magn3ts | Of course the "Developing for the HUD" sections of the wiki are bone-dry :( | 08:14 |
| dholbach | good morning | 08:30 |
| scientes | the raring daily build for 1-22 doesn't boot | 08:36 |
| scientes | live cd | 08:36 |
| scientes | or rather, mouse but no installation windows | 08:36 |
| scientes | oh wait, nvm.....just taking forever | 08:37 |
| === tkamppeter_ is now known as tkamppeter | ||
| === megha is now known as hack | ||
| === doko__ is now known as doko | ||
| Laney | bdrung: feel free to do it | 09:26 |
| Laney | don't forget to commit to the ubuntu-desktop VCS | 09:26 |
| === henrix_ is now known as henrix | ||
| === yofel_ is now known as yofel | ||
| doko | jodh, about 1103414, is this reproducible for you locally? | 11:03 |
| jodh | doko: I'll retry my build... | 11:04 |
| doko | jodh, please attach the preprocessed source, and the command line options used (and please make the build verbose by default) | 11:04 |
| jodh | doko: ack. | 11:05 |
| === Sweetsha1k is now known as Sweetshark | ||
| dholbach | @pilot in | 11:26 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === ximion is now known as ximion-afk | ||
| === _salem is now known as salem_ | ||
| === ximion-afk is now known as ximion | ||
| === ximion is now known as ximion-afk | ||
| ev | jodh: do you think we'll get upstart inotify events in raring? | 12:25 |
| jodh | ev: well, it is in plan, but more teetering on the edge than centre-stage atm. | 12:31 |
| ev | jodh: noted; thanks! | 12:33 |
| ev | mpt: whenever you have a free moment, I'd appreciate your thoughts on whether we should modify the firefox crash reporting dialog: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1064395 | 12:34 |
| ubottu | Ubuntu bug 1064395 in apport (Ubuntu) "Apport should still send reports to daisy.ubuntu.com for binaries in the blacklist" [Undecided,New] | 12:34 |
| herton | @pilot in | 12:35 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton, dholbach | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === ximion-afk is now known as ximion | ||
| === fisted_ is now known as fisted | ||
| mdeslaur | @pilot in | 13:06 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton, dholbach, mdeslaur | ||
| * dholbach hugs mdeslaur and herton | 13:08 | |
| * mdeslaur hugs dholbach | 13:08 | |
| === cpg is now known as cpg|away | ||
| dholbach | :-) | 13:08 |
| sveinse | How does the dpkg trigger work? On an ubuntu-arm precise target I see a few "Processing triggers for initramfs-tools" and often the update-initramfs is run multiple times duing the same apt-get update. Isn't the trigger mechanism built to avoid exactly that? | 13:30 |
| === Ursinha_ is now known as Ursinha | ||
| === rsalveti_ is now known as rsalveti | ||
| sveinse | And just now I installed a custom package which installs something into initramfs-tools. dpkg reports that "Processing triggers for initramfs-tools" like it should, but it does not run update-initramfs | 13:32 |
| === fisted_ is now known as fisted | ||
| === henrix is now known as henrix_ | ||
| === sraue_ is now known as sraue | ||
| === henrix_ is now known as henrix | ||
| herton | @pilot out | 13:57 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, mdeslaur | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === MacSlow|lunch is now known as MacSlow | ||
| mpt | ev, done | 14:24 |
| ev | mpt: thanks | 14:30 |
| === chiluk_away is now known as chiluk | ||
| k-s | doko: hi, do you have some minutes to query about ubuntu's linker? | 14:44 |
| k-s | doko: I'm trying to get our project (EFL) to behave in an uniform way in multiple systems, but seems I cannot get as strict as Ubuntu's linker | 14:45 |
| k-s | doko: even giving -Wl,--no-copy-dt-needed-entries -Wl,--as-needed everywhere, just on Ubunut it fails with DSO, while on Fedora, Arch and others it compiles without errors | 14:45 |
| k-s | doko: so if you know how to force the DSO everywhere, I'd like to apply this to our project | 14:45 |
| k-s | doko: is ubuntu using gold or the traditional linker? Any changes to libtool? | 14:46 |
| === slank_away is now known as slank | ||
| rbasak | k-s: I'm not confident in the answers I'd give for your questions, so best to wait for someone else. But in the meantime, are you familiar with http://wiki.debian.org/ToolChain/DSOLinking? It's what I use as a reference to fix lots of build failures. | 15:03 |
| k-s | rbasak: yeah, did look into it. | 15:04 |
| k-s | rbasak: and in the one from fedora as well | 15:04 |
| k-s | strange part is that fedora works, ubuntu doesn't (to cause the error) | 15:04 |
| rbasak | k-s: pastebin the error please? | 15:05 |
| rbasak | (and the linker command line) | 15:05 |
| k-s | rbasak: http://pastebin.com/ZnmkASs0 from an user | 15:06 |
| k-s | rbasak: the same configure/Makefile worked for Fefora, Arch and Gentoo | 15:07 |
| k-s | oops, he said there is another log, I'm waiting for his new pastebin | 15:07 |
| dholbach | can somebody please reject https://code.launchpad.net/~ben-kietzman/ubuntu/quantal/yasm/fix-for-1064341/+merge/140267? | 15:11 |
| stgraber | dholbach: done | 15:15 |
| dholbach | thanks stgraber | 15:16 |
| k-s | rbasak: http://pastebin.com/QiU4fcRp using libeet.la http://pastebin.com/CxFL0cNZ | 15:20 |
| k-s | rbasak: basically from my logs, Ubuntu's libtool isn't emitting the 'dependency_libs' parts. Although it IS used by 'relink_command' at the end, it's not being used to compile | 15:22 |
| k-s | rbasak: then I wonder: any patch to libtool? | 15:23 |
| rbasak | k-s: is eina_iterator_next defined in libeina.so.1 as it says? In that case don't you need a -leina? This is on the edge of my knowledge so I might be missing something here. | 15:23 |
| k-s | rbasak: it is | 15:24 |
| k-s | rbasak: it is in libeina, which is a dependency for libeet.la as stated in the second pastebin | 15:25 |
| k-s | rbasak: I'm not even getting in the merit if it should or not emit libeina because it's a dependency of libeet | 15:25 |
| k-s | rbasak: I'm trying to understand why your libtool is different from all other distro | 15:25 |
| k-s | rbasak: if it's a flag I can turn on, or it's a patch | 15:26 |
| dholbach | @pilot out | 15:26 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur | ||
| k-s | rbasak: will have to go for 30 min or so, please reply to my nick so I can find it when I'm back. | 15:26 |
| k-s | rbasak: thanks! | 15:26 |
| stokachu | cjwatson: i am attempting to do a merge/fix conflicts for console-setup, is that ok with you? | 15:27 |
| === k-s is now known as k-s[AWAY] | ||
| rbasak | k-s: I think we're just less liberal in accepting input that isn't quite right, which other distros (currently) don't mind about. I guess this is a libtool issue rather than directly a linker one? Now we're past the edge of my knowledge and I'll have to let someone else answer - sorry. If you don't get an answer here, please try ubuntu-devel@lists.ubuntu.com. It's moderated but you've got an on-topic Ubuntu-specific issue so it's the right venue an | 15:29 |
| rbasak | d someone should let it through. | 15:29 |
| cjwatson | stokachu: TBH I'd prefer you didn't, it's really complicated and full of very delicate interactions with the rest of the installer | 15:29 |
| cjwatson | stokachu: For many packages I'd be fine, but console-setup is one where experience has taught me I need to line-by-line the whole thing | 15:29 |
| stokachu | ok no worries, so ill just pick another package then | 15:29 |
| stokachu | cjwatson: how about aptitude? looks to be only diff changes | 15:31 |
| stokachu | mterry: do you mind if i work on the merge fixes for aptitude? | 15:33 |
| mterry | stokachu, please do :) | 15:33 |
| stokachu | cool thanks! | 15:33 |
| mterry | stokachu, it might be complicated too, I don't recall | 15:33 |
| stokachu | mterry: the report shows 2 files needing change | 15:34 |
| mterry | stokachu, k | 15:34 |
| cjwatson | stokachu: "only diff changes"? | 15:36 |
| cjwatson | stokachu: But it's fine by me | 15:36 |
| doko | k-s, rbasak: the .la file references a file i n /home/<something> while you /opt/lib/<something> is searched. are these incompatible libs? looks like a local issue | 15:36 |
| stokachu | cjwatson: yea the report just showed 2 files with diff conflicts | 15:36 |
| rbasak | doko: BTW, while you're here, when do you next plan to merge python2.7 please? Bug 1097783 causes a genshi FTBFS, now fixed (trivially) in upstream 2.7 tip. Nothing urgent, but there's a second cause for the genshi FTBFS there's no point in fixing until python is fixed. | 15:40 |
| ubottu | bug 1097783 in genshi (Ubuntu) "re module apis return longs now" [High,Triaged] https://launchpad.net/bugs/1097783 | 15:40 |
| rbasak | Or we could cherry-pick it I suppose. Not worth it if you're planning another merge though. | 15:40 |
| mdeslaur | do we still need to set the pocket to -proposed for SRUs to stable releases, or does that get handled automatically now? | 15:47 |
| Laney | it'll get rewritten | 15:47 |
| cjwatson | Yeah, you can do either | 15:50 |
| cjwatson | I've been getting into the habit of just writing "precise" | 15:51 |
| stokachu | mterry: so when i do a merge with bzr merge debianlp:aptitude everything applies cleanly :\ | 15:55 |
| stokachu | but the report shows conflicts so is the report outdated on merges.ubuntu.com? | 15:55 |
| cjwatson | merges.ubuntu.com is not necessarily as smart as bzr | 15:55 |
| mterry | Yeah. I don't typically use bzr for merges, so I'm not as familiar with its workflow, but I could believe it knows better. Still probably good to double check that the changes you would have made are in the merged bzr branch too | 15:56 |
| stokachu | ok ill use the grab-merge tool and compare, if everything is good ill create a merge bug for this ok/ | 15:57 |
| stokachu | *? | 15:57 |
| cjwatson | Daviey: do you think somebody on the server team could verify that the fix for bug 901600 meets your needs? | 16:01 |
| ubottu | bug 901600 in grub2 (Ubuntu Precise) "Allow /etc/default/grub overriding via /etc/default/grub.d/" [High,Fix committed] https://launchpad.net/bugs/901600 | 16:01 |
| cjwatson | shouldn't take very long | 16:01 |
| stokachu | mterry: interesting, doing grab-merge has the latest changes but debianlp does not | 16:02 |
| cjwatson | You might want to just ignore bzr for this if it's out of date | 16:02 |
| stokachu | ok | 16:02 |
| === ev_ is now known as ev | ||
| xnox | stokachu: do bzr merge => generate debdiffs against debian & compare with previous old ubuntu to old debian debdiff. | 16:13 |
| xnox | stokachu: sometimes bzr is smart and actually does merge everything right. | 16:13 |
| cjwatson | xnox: bzr merge doesn't help when the import into lp:debian/... has failed :) | 16:13 |
| xnox | =)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) | 16:14 |
| cjwatson | Hmm, but it looks up to date | 16:14 |
| === salem_ is now known as _salem | ||
| cjwatson | stokachu: So, I'm not sure what you mean; debianlp:aptitude is version 0.6.8.2-1 which is what's in Debian unstable | 16:15 |
| cjwatson | stokachu: I think you must have misread someething ... | 16:15 |
| stokachu | cjwatson: yea i did :\ | 16:15 |
| stokachu | i did check the diff again just to make sure. and since no changes are needed do i still need to go through creating a merge bug? | 16:16 |
| xnox | lp:debian/experimental/aptitude is also up to date with what's idling in the experimental. | 16:16 |
| xnox | stokachu: are you implying aptitude is now insync?! | 16:16 |
| xnox | stokachu: or the debdiff is the same, sans new changelog entry. | 16:17 |
| stokachu | xnox: so basically when doign a grab-merge it shows 2 file conflicts, bug when i did a bzr merge from debianlp it applied cleanly | 16:17 |
| stokachu | so i dont think i need a new changelog entry or anything | 16:18 |
| stokachu | unless I need to specify that this was a correct merge through bzr and not through merges.u.c | 16:18 |
| Laney | You will do; it likely means that it (thinks it) figured out how to merge everything by itself. | 16:18 |
| xnox | stokachu: we upload package into ubuntu. new upload must be higher version, and it needs to have a changelog entry. | 16:18 |
| Laney | Do double check that what it did is what you expect though | 16:19 |
| xnox | stokachu: and the changelog entry should still document remaining (same as before) ubuntu delta. | 16:19 |
| stokachu | ok gotcha | 16:19 |
| doko | jodh, new upstart still doesn't configure with --disable-silent-rules | 16:20 |
| === k-s[AWAY] is now known as k-s | ||
| k-s | doko: back, the /opt is the ./configure --prefix=/opt. It should look just into build | 16:21 |
| doko | but apparently it doesn't | 16:22 |
| k-s | doko: the command 'libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -Wextra -Wl,--copy-dt-needed-entries,--no-as-needed -o bin/eet/eet bin/eet/bin_eet_eet-eet_main.o -fvisibility=hidden -fdata-sections -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing -Wl,--as-needed -Wl,--no-copy-dt-needed-entries lib/eet/libeet.la' just references the local file | 16:22 |
| k-s | doko: do you patch libtool or something like that? | 16:22 |
| doko | afaik, no. and the diff to debian is available too | 16:23 |
| === _salem is now known as salem_ | ||
| k-s | doko: diff of my libtool and ubuntu's is quite relevant | 16:28 |
| k-s | doko: thins like link_all_deplibs. Do you think it's an option or is it a patch? | 16:29 |
| doko | k-s, if you know that it's relevant, then please don't speculate, just point to a particular thing, and maybe fix it | 16:29 |
| k-s | doko: I'm checking with the ubuntu user if that's the problem. :-) | 16:30 |
| k-s | doko: then i still don't know | 16:30 |
| === ev_ is now known as ev | ||
| k-s | doko: he acks that changing link_all_deplibs from no to unknown fixes it | 16:31 |
| k-s | doko: unknown = yes according to libtool info page. | 16:31 |
| doko | then it really looks like an issue with --as-needed. is the software packaged? then I could have a look, but not without it | 16:32 |
| k-s | doko: but I wonder why this ends as 'no' in ubuntu, not in other | 16:32 |
| k-s | doko: not packaged yet, it's still under development | 16:33 |
| k-s | doko: as for the libtool, I'm more interested to know why the variable has different value | 16:33 |
| k-s | doko: and how I can force it to be the same everywhere, be it no (like in ubuntu) or yes/unknown (like in fedora/arch) | 16:33 |
| doko | k-s: look at the changelog. | 16:33 |
| stokachu | is the changelogs url still http://changelogs.ubuntu.com/changelogs? | 16:34 |
| doko | bah, just get the source | 16:34 |
| stokachu | looks like aptitude needs a small modification to point to ubuntu's changelog server | 16:34 |
| cjwatson | it's a very old Debian patch | 16:34 |
| cjwatson | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191425 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199423 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=238681 | 16:34 |
| ubottu | Debian bug 191425 in libtool "Links explicitly with dependent shared libraries" [Wishlist,Fixed] | 16:34 |
| ubottu | Debian bug 199423 in libtool "libtool tries (unnecessarily) to link explicitly with dependent shared libraries" [Wishlist,Fixed] | 16:34 |
| ubottu | Debian bug 238681 in libtool "librrd0-dev: libtool cannot link to librrd because of bad dependencies" [Wishlist,Fixed] | 16:35 |
| cjwatson | (I think.) Predates Ubuntu. | 16:35 |
| cjwatson | And makes a big difference to the huge pile of unnecessary (and sometimes harmful) DT_NEEDED entries you end up with on other systems. | 16:35 |
| cjwatson | harmful> particularly in cases where the indirectly-linked library changes its SONAME, which does happen | 16:36 |
| k-s | doko: it's confirmed to be 'debian/patches/link_all_deplibs.patch' | 16:41 |
| cjwatson | stokachu: It already had that modification in the Ubuntu delta against Dbian | 16:42 |
| cjwatson | *Debian | 16:42 |
| doko | k-s: I think it's an upstream bug. | 16:42 |
| k-s | doko: interesting enough there is one changelog entry disabling some tests because applying this patch breaks libtool's testsuite, the author mentions it is a bug in testsuite | 16:42 |
| doko | /usr/bin/ld: bin/eet/bin_eet_eet-eet_main.o: undefined reference to symbol 'eina_iterator_next' | 16:42 |
| doko | /usr/bin/ld: note: 'eina_iterator_next' is defined in DSO /opt/lib/libeina.so.1 so try adding it to the linker command line | 16:42 |
| doko | /opt/lib/libeina.so.1: could not read symbols: Invalid operation | 16:42 |
| k-s | doko: indeed, I can solve this by adding lib/eina/libeina.la to LIBADD | 16:42 |
| doko | but you don't explicitly link against -leina. you rely on libeet linked against -leina | 16:43 |
| k-s | doko: but as I said I'm more interested to know why this was being done in Ubunut/Debian and not on other distros | 16:43 |
| k-s | doko: seems this patch is the reason | 16:43 |
| doko | which is expected with no-add-needed | 16:43 |
| doko | k-s, no, the default behaviour is just hiding the upstream bug | 16:44 |
| cjwatson | Debian has a history of caring very deeply about incremental upgradeability, and that's the sort of thing that tends to make it more likely that you'll encounter problems with indirect linkage | 16:44 |
| cjwatson | If you don't care about that you can just rebuild everything and mask the problem | 16:44 |
| k-s | doko: yes, this is true. But the major issue is the libtool script being different. | 16:46 |
| cjwatson | k-s: Do I understand correctly that you're using eina functions in the objects that you're linking with libeet, as well as in libeet itself? | 16:47 |
| k-s | doko: what I wanted to do is to force every builder to get the same results with the same flags | 16:47 |
| xnox | k-s: with --add-needed --no-as-needed LDFLAGS you can override ubuntu/debian default behaviour. which will not hurt to guarantee if you wish to use that everywhere. | 16:47 |
| k-s | doko: so if some other !ubuntu developer commits... he will do it right and not break ubuntu-ers | 16:47 |
| xnox | k-s: run buildbots on ubuntu which revert/reject commits ;-) | 16:48 |
| k-s | xnox: unfortunately not, because link_all_deplibs=no is being set independently of that linker flag | 16:48 |
| xnox | (launchpad daily builds can be used as well) | 16:48 |
| xnox | hmm... | 16:48 |
| k-s | xnox: maybe a better libtool patch would be to check for this flag? (and maybe it would be accepted upstream?) | 16:48 |
| doko | xnox, doesn't look an as-needed issue on first sight | 16:49 |
| doko | k-s: no better fix upstream | 16:49 |
| k-s | doko: as i said? | 16:49 |
| cjwatson | copy-dt-needed-entries/as-needed can't really influence this because the problem is whether libtool passes excess objects to the linker or not | 16:49 |
| doko | right, but if it passes these excess objects, then it hides thecopy-dt-needed-entries issue | 16:50 |
| cjwatson | indeed | 16:51 |
| cjwatson | libtool's autoconf support doesn't appear to provide a way to e.g. override that behaviour on the configure command line | 16:51 |
| doko | and this seems to happen with the upstream libtool, not with the debian one. I can't find any upstream forwarding for this issue | 16:51 |
| cjwatson | so I think the only way to do what k-s is asking for (an upstream build forced to link_all_deplibs=no - which of course would only work at all on certain architectures) would be to patch libtool before generating configure, or patch configure, or patch config.status after generating configure and then re-run | 16:52 |
| k-s | I wonder if there was any discussion, because 2 patches at least are quite old: link_all_deplibs.patch and deplibs_binary.patch | 16:53 |
| cjwatson | google brings up e.g. http://www.mail-archive.com/libtool@gnu.org/msg06328.html | 16:53 |
| cjwatson | https://lists.gnu.org/archive/html/libtool/2004-11/msg00455.html better link | 16:54 |
| cjwatson | at the time the Debian maintainer was either libtool upstream or one of them | 16:54 |
| cjwatson | it would've been around that time, anyway | 16:55 |
| cjwatson | I can understand why they might be conservative about changing it, though; it's the sort of thing that needs a degree of coordination and distro support | 16:55 |
| === sraue_ is now known as sraue | ||
| mdeslaur | @pilot out | 17:00 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| dobey | barry: eww; why did you hack the oneconf setup.py that way instead of fixing the broken debian/rules? | 17:36 |
| dobey | doko: could i get you to look at https://code.launchpad.net/~dobey/ubuntu/raring/twisted/fix-pygtkcompat/+merge/144550 please? the new twisted combined with new pygobject is causing ubuntuone pieces to crash on start. thanks | 17:56 |
| doko | dobey, sure, looks fine | 17:57 |
| === fisted_ is now known as fisted | ||
| barry | dobey: well, the problem was that the executables were getting installed by setup.py into /tmp/usr/bin for both py2 and py3, so the last one installed would "win", and i didn't want to be order dependent. this way, it's explicit in the setup.py, which makes sense to me since the executables should only be expected to work with py3 | 18:04 |
| dobey | barry: but working around the problem by hacking setup.py means people who want to use it with python2 (say people who want to backport the new version to older ubuntu), get no scripts. and order dependence is a big part of packaging, so it should be dealt with there. this is a problem with the reocmmended packaging for something to support both 2 and 3, and so oneconf isn't the only thing that's going to hit this issue. | 18:06 |
| barry | dobey: in that case, consider the setup.py hack to be a quick fix for a critical problem. the real fix will probably entail changing the --root on the install and fixing the .install paths. however, you'll still have the issue that the change can't be completely backported anyway since something in debian/ will have to be changed anyway. so, is it better to change debian/rules (probably to change which executables are deleted) or | 18:10 |
| barry | better to change setup.py? | 18:10 |
| xnox | dobey: inherintly easy to backport should not be a priority, but rather a nice to have criteria though. The amount of stuff ported to python3 since precise is enormous, including leaf packages dropping python2 support. | 18:10 |
| xnox | barry: artificially limiting package in setup.py is not nice. | 18:11 |
| dobey | xnox: i'm not talking about backporting the package. i'm talking about pulling the bzr branch and doing ./setup.py install | 18:12 |
| xnox | barry: in devscripts, I run full build machinery for python3, but for python2 I simply use dh_install to move the one python2 module r-dependencies need into correct installation location. | 18:12 |
| barry | xnox: i'm not convinced its artificial though | 18:13 |
| xnox | barry: is the new pybuild stuff uploaded into raring? and how does that deal with py2&3 scripts. | 18:13 |
| dobey | xnox: whether or not it is a priority, hacking setup.py in such a way is not good practice and should be generally discouraged; fixing the debian/rules would be the better fix | 18:13 |
| barry | xnox: not yet. i was trying to get feedback on mitya's branch from doko first | 18:13 |
| barry | fwiw, the only reason we re-enabled py2 support at all is for s-c and we're trying to rectify that | 18:14 |
| xnox | doko: do you want to review the new features of python-defaults (pybuild) or are you ok for that being sponsored (since nothing in the archive depends on it ;-) ) | 18:14 |
| xnox | barry: well same way I had to reenable devscripts python2, because of ubuntu-dev-tools ;-) | 18:15 |
| barry | xnox: perhaps :) anyway, once s-c is fully on py3, i would like to eliminate py2 support for oneconf | 18:16 |
| xnox | barry: https://launchpadlibrarian.net/128484331/devscripts_2.12.6ubuntu1_2.12.6ubuntu2.diff.gz | 18:16 |
| xnox | The "meat" of this patch is in the one line "+scripts/devscripts /usr/lib/python2.7/dist-packages/" in the debian/install. | 18:16 |
| xnox | Note how I totally disregard 2.6 and lower. The other extra bit I did is call dh_python2 helper and clean up __pycache__ and that was it. | 18:17 |
| barry | xnox: the problem here is that setup.py installs scripts (i.e. executables) for both py2 and py3 into the same location. the bug was because py2 got installed after py3 so "won" but the scripts are not intended to work with py2, only py3. so i still think it's reasonable to make that explicit in the setup.py | 18:18 |
| xnox | barry: does s-c need python2 scripts? | 18:18 |
| xnox | or just python modules? | 18:18 |
| barry | xnox: just 'import oneconf' | 18:19 |
| xnox | hence don't run setup.py with python2 at all. | 18:19 |
| barry | xnox: because if it was shelling out to run the scripts, it wouldn't care :) | 18:19 |
| dobey | barry: i don't think that's appropriate for the setup.py; i think it's appropriate to fix the ordering in debian/rules :) | 18:19 |
| xnox | forget about all the best python2 packaging practices and do hacks instead =) | 18:20 |
| barry | xnox: that seems more radical than making the compatibility explicit in setup.py, doesn't it? | 18:20 |
| * xnox goes to make a merge proposal. | 18:20 | |
| dobey | barry: it's a packaging problem; not an upstream source problem | 18:20 |
| xnox | barry: you just broke python4 support =) | 18:20 |
| * barry shudders | 18:20 | |
| xnox | actually a real problem, each python transition we have to fix packages that hard-coded << X.Y for no reason. | 18:21 |
| stokachu | mterry: I uploaded a merge request (bug 1103541) if you've got time for any comments on it etc | 18:21 |
| ubottu | bug 1103541 in aptitude (Ubuntu) "Please merge aptitude 0.6.8.2-1(main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1103541 | 18:21 |
| barry | dobey: i disagree. as i say, the scripts are (currently) not intended to work with py2, only py3. isn't that an "upstream" issue (i won't say "problem") | 18:21 |
| xnox | barry: not intended or do not work at all. | 18:21 |
| xnox | ? | 18:21 |
| barry | xnox: yes, that's a real problem, and i'm not holding my breath for py4 :) | 18:21 |
| dobey | barry: surely they are intende to work with it; they do work with it; the intent is from the packaging side (you don't want to package the python2 bits), not from the upstream side (if python2 isn't intendted to work upstream, then it should just sys.exit() if python3 isn't used, and put /usr/bin/python3 in all the hashbangs) | 18:22 |
| barry | xnox: not tested, and i don't think they need to work with py2. maybe didrocks has a different opinion, but he seemed fine with that when we talked about it previously. the re-porting to py2 of the library was just a concession (and hopefully temporary) to s-c's current state of affairs | 18:22 |
| dobey | is oneconf even useful outside the context of software-center? | 18:23 |
| barry | dobey: /usr/bin/python3 *is* in the shebangs. dh_python2 overwrites them. yes, we can fix that, but no, the scripts *don't* work with py2 which is why the bug was filed | 18:23 |
| barry | dobey: yes, but only s-c imports the oneconf library | 18:23 |
| barry | dobey: and anything shelling the oneconf executables doesn't care, as long as the executables have the right shebang lines, which they now do :) | 18:24 |
| didrocks | barry: we don't really care for the binary to run python3 or python2, so just whatever is the best in your opinion, I guess py3 ;) | 18:24 |
| barry | didrocks: agreed! and now they do. :) | 18:24 |
| barry | my point being: the executables do not need to run py2, and running them with py2 doesn't work. the *only* reason the package even cares about py2 is because s-c does 'import oneconf' so we have to support that in the library (only) for now | 18:25 |
| dobey | why doesn't running them with py2 work? | 18:25 |
| barry | it's untested :) | 18:26 |
| xnox | in that case a well written script will fail verbosely in the users face if they do try to run in py2, despite "not being intended". | 18:26 |
| dobey | python /usr/bin/oneconf-query works fine here :) | 18:26 |
| barry | dobey: head /usr/bin/oneconf-query | 18:26 |
| dobey | barry: yes it has the 3.3 shebang; but what has that got to do with anything if i'm running a specific python version explicitly? :) | 18:27 |
| dobey | why is it 3.3 instead of just "python3" btw? | 18:27 |
| xnox | yeah 3.3 is wrong as well ;-) | 18:27 |
| barry | dobey: ah, nothing then. i still say that the we should not claim to support running those scripts under py2 | 18:28 |
| barry | fwiw, upstream shebang is `/usr/bin/env python3` as it should be. it gets rewritten | 18:28 |
| barry | by the build process | 18:28 |
| seb128 | barry, didrocks: I guess that apport triggering for oneconf-query every time I install a package is a known issue? | 18:29 |
| didrocks | seb128: I assigned the bug to barry | 18:29 |
| seb128 | didrocks, thanks, I assumed it would be a known issue ;-) | 18:29 |
| seb128 | barry, any ETA on the fix? | 18:29 |
| barry | seb128: what's the bug #? | 18:29 |
| didrocks | I guess is was what he uploaded yesterday evening though | 18:29 |
| dobey | well, given that python practice is generally to not have any logic in the scripts, and that all the logic is in modules, and scripts are supposed to just do from foo import main; main(); then there is no claim to make or not to make :) | 18:29 |
| seb128 | barry, dunno, look to the bugs assigned to you? ;-) | 18:30 |
| dobey | seb128: the new oneconf is in the archive; upgrade? :) | 18:30 |
| dobey | or are you using a slow mirror? | 18:30 |
| barry | dobey: that's not how oneconf-query is currently written | 18:30 |
| seb128 | the error is: /usr/bin/oneconf-query: 'GNUTranslations' object has no attribute 'ugettext' | 18:31 |
| barry | but i agree it's good practice. a total rewrite wasn't on my radar :) | 18:31 |
| seb128 | let me try to upgrade | 18:31 |
| seb128 | dobey, I upgraded this morning, let me retry | 18:31 |
| dobey | barry: i see that, but having setup.py install scripts doesn't have anything to do with making a claim to support something, either :) | 18:31 |
| * xnox is going for a oneline fix. | 18:31 | |
| dobey | seb128: oh, that's a different crash | 18:31 |
| LIDH | Hello, I have Ubuntu 12.10 and a POS system EBN X-950 with touchscreen (EgalaxyTouch according to the manual), so, i tried $lsusb and it doesn't list the touchscreen controller. If I do a screen /dev/ttyS[0-4] can't get any input from the touchscreen. Already did $ modprobe -r usbtouchscreen and still doesn't detect, any ideas what's the problem? | 18:31 |
| dobey | seb128: i am not seeing that though | 18:32 |
| * xnox just saw that with tests while building oneconf. | 18:32 | |
| seb128 | barry, bug #1103192 | 18:32 |
| ubottu | Error: Launchpad bug 1103192 could not be found | 18:32 |
| seb128 | dobey, ii oneconf 0.3.2 all synchronize your configuration da | 18:33 |
| seb128 | dobey, seems the current version | 18:33 |
| seb128 | barry, bug #1103192 | 18:33 |
| barry | seb128: got it. i'll work on that | 18:33 |
| seb128 | ubottu, wake up bot ;-) | 18:33 |
| ubottu | seb128: I am only a bot, please don't think I'm intelligent :) | 18:33 |
| dobey | barry: anyway, i think doing what you did to setup.py in order to "fix" the issue, sets a bad example for what people should do when they encounter the same issue with other packages that need to install both py2 and py3 versions of modules, and which have scripts | 18:33 |
| seb128 | barry, thanks | 18:33 |
| bdmurray | seb128: is there someone on the desktop team who can look at bug 1101326? | 18:34 |
| ubottu | bug 1101326 in consolekit (Ubuntu) "console-kit-daemon appears to consume 2GB of memory" [High,New] https://launchpad.net/bugs/1101326 | 18:34 |
| xnox | dobey: i have a merge proposal with a simpler fix comming shortly. | 18:34 |
| seb128 | bdmurray, consolekit is a foundation bit, maybe ask slangasek? | 18:34 |
| slangasek | heh, ok | 18:34 |
| barry | dobey: i'm not so sure. let's take ubuntu packaging out of the picture. just say you're writing an upstream package where the library supports py2 and py3, but the executables it creates only supports one version or the other. how would you solve that? | 18:34 |
| xnox | seb128: we were hoping somebody might want that hot potato on the desktop side =) | 18:35 |
| seb128 | no, the last one who was enough into plumbing for those issue in desktop was pitti | 18:35 |
| seb128 | we don't have anyone with ck clues atm | 18:35 |
| slangasek | understood | 18:35 |
| LIDH | anyone to help me with the touchscreen? | 18:35 |
| seb128 | slangasek, xnox: sorry about that... | 18:35 |
| xnox | barry: if only setup.py metadata and pypi tags supported "supported versions per-module & scripts" | 18:35 |
| dobey | barry: if the modules support both, the scripts should support both; all code, whether in scripts or modules, should be tested, and the tests should past under all versions of python you claim to support, regardless of whether it's scripts or modules. all code should adhere to the same standards | 18:35 |
| xnox | in a standard way. | 18:36 |
| dobey | barry: but then again, all the ubuntuone packages are maintained in this way :) | 18:36 |
| barry | dobey: maybe, but that's an upstream decision, and there may be reasons why they don't or can't or won't do that. again, for callers of the cli, the shebang python version should never matter | 18:37 |
| stokachu | barry: would python-tz be something I could help on? | 18:37 |
| dobey | barry: well it does, because "/usr/bin/env python[3]" breaks virtualenv and is bad practice, no? | 18:38 |
| barry | stokachu: hi. what would you like to work on? python3-tz is in the archive currently | 18:38 |
| tion_ | how do i dist-upgrade to 12.10? | 18:39 |
| stokachu | barry: i was just looking at the outstanding merges and python-tz shows debian at 2012c-1 and last upload 2011k-0ubuntu6 | 18:39 |
| xnox | tion_: support for stable release (12.10) is in the #ubuntu channel. | 18:40 |
| barry | dobey: right, but fwiw, /usr/bin/env should never be in the shebang for production scripts. it's a known issue for virtualenvs, but there isn't any common solution for it. folks just hack around such things when they need to | 18:40 |
| barry | stokachu: that would be great! | 18:40 |
| stokachu | barry: ok cool ill work on that today | 18:41 |
| dobey | barry: anyway, i didn't want to have a lengthy argument about it. just point out that it seems like the wrong fix and sets bad precedence. it would seem very odd to me for any upstream to decide to only support python2 with only part of their code, and python3 with all of it. if upstream doesn't want to support python2 then don't ship any python2 bits and only package it as requiring python3 :) | 18:41 |
| toabctl | jbicha, can you have a look at lp:1102096 please? | 18:41 |
| * dobey has enough problems to deal with right now from other upstreams doing some dumb things | 18:42 | |
| dobey | and need to get lunch. bbiab | 18:42 |
| barry | dobey: originally oneconf was a pure py3 port that dropped py2, but then i realized s-c still imported it. but i get what you're saying, and sorry to be so obstinate about it. do feel free to at least file a bug, and if we don't just drop py2 support before then, i'll keep it on the radar | 18:42 |
| LIDH | How do I get Ubuntu 12.10 to detect more than 4 COM Ports? | 18:42 |
| barry | dobey: i think that's a constant of the universe (upstreams doing dumb things :). and i speak of course as one of those dumb upstreamers :) | 18:43 |
| dobey | :) | 18:44 |
| LIDH | How do I get Ubuntu 12.10 to detect more than 4 COM Ports? | 18:44 |
| barry | anyway, i'd rather put the effort into getting s-c on py3, but i certainly would be happy to review a m-p :) | 18:44 |
| ogra_ | LIDH, this is not a support channel, try #ubuntu | 18:45 |
| xnox | LIDH: support is in #ubuntu . Also please be patient and don't repost your question that often. | 18:45 |
| xnox | LIDH: also don't post in multiple channels simultaniously ;-) | 18:45 |
| bdmurray | slangasek: looking at bug 1096022 I'm trying to use the apt-clone file to recreate it and running into issues with either apt-clone or aptdaemon... | 18:50 |
| ubottu | bug 1096022 in update-manager (Ubuntu) ""E:Error, pkgProblemResolver::Resolve generated breaks" during lucid->precise universe upgrade of amd64" [Medium,Triaged] https://launchpad.net/bugs/1096022 | 18:50 |
| jbicha | toabctl: yes I saw the bug but I'm not able to duplicate it here | 18:52 |
| jbicha | toabctl: maybe you could post your graphics driver & hardware and whether you're using PPAs | 18:53 |
| stokachu | stupid question, i ran a bzr merge and it renamed files to filename.BASE|THIS i assume THIS is from the merged repo? | 18:53 |
| stokachu | and they aren't exactly diffs but are they meant to replace the whole file? | 18:54 |
| bdmurray | barry: about that software-center merge proposal... | 18:57 |
| barry | bdmurray: i was just going to ask you about that :) | 18:57 |
| toabctl | jbicha, I don't use any relevant ppas. I also posted my graphics hardware (Intel Corporation Mobile 4 Series Chipset) to the bug report | 18:58 |
| barry | bdmurray, xnox do you just need it merged or do you need it uploaded? | 18:58 |
| bdmurray | barry: merged, I can do the uploading and SRU work | 18:59 |
| barry | bdmurray: nod | 18:59 |
| slangasek | bdmurray: what kind of issues? | 18:59 |
| bdmurray | segfaults in apt-clone | 19:00 |
| slangasek | fun | 19:01 |
| bdmurray | er or libpat-pkg-libc6.10-6 | 19:01 |
| bdmurray | oh psivaa do you a script to setup the system in bug 1096022 I could use? | 19:01 |
| ubottu | bug 1096022 in update-manager (Ubuntu) ""E:Error, pkgProblemResolver::Resolve generated breaks" during lucid->precise universe upgrade of amd64" [Medium,Triaged] https://launchpad.net/bugs/1096022 | 19:01 |
| slangasek | bdmurray: backtraces? | 19:04 |
| barry | bdmurray: crap. i also have insufficient permissions to push it after the team reassignment. i suggest bugging dobey (only direct team member currently on this channel afaict) | 19:06 |
| dobey | barry, bdmurray: merged | 19:36 |
| jrr | Does apt-get build-dep generally work for ubuntu packages? I'm getting a bunch of missing libraries when trying to rebuild gnome-control-center. | 19:36 |
| bdmurray | dobey: thanks | 19:37 |
| sarnold | jrr: do you also have the build-essential package installed? | 19:37 |
| xnox | jrr: it should. unless your source package != distro you are running. | 19:38 |
| jrr | 12.10, and whatever "apt-get source gnome-control-center" pulled down | 19:38 |
| xnox | jrr: e.g. apt-get build-dep only gives you build-deps as declared in the highest version of the source package from deb-src lines, it doesn't know about unreleased changes in the distro / upstream. | 19:38 |
| dobey | barry: if you feel like merging/uploading something though, https://code.launchpad.net/~dobey/ubuntu/raring/twisted/fix-pygtkcompat/+merge/144550 could use it :) | 19:39 |
| xnox | jrr: do you have full build-log? | 19:39 |
| jrr | yeah, hold on I'll redo the whole flow and pastebin it | 19:39 |
| stgraber | kees: hey, are you around? | 19:40 |
| dobey | hmm, what's the best way to go about converting a native package in ubuntu, to not be a native package? | 19:44 |
| jrr | xnox: forgive the syntax highlighting http://pastebin.com/t396MTJM | 19:45 |
| jrr | first time trying to rebuild a package; naively trying to ./configure and make | 19:46 |
| jrr | if that's not the correct way to do it, I welcome correction =] | 19:46 |
| xnox | jrr: that's not how one rebuilds a package. | 19:46 |
| xnox | jjr: ./debian/rules build | 19:46 |
| xnox | jrr: fakeroot ./debian/rules binary | 19:47 |
| xnox | run these two commands in clean unpacked source. | 19:47 |
| xnox | ... or there is a helper to do that. | 19:47 |
| dobey | or set up pbuilder or sbuild, so you can build it in a clean chroot | 19:47 |
| xnox | $ debuild | 19:47 |
| xnox | jrr: note that debian/rules is just a makefile, although usually uses black magic (cdbs or dh) | 19:48 |
| stokachu | jrr: I like to use http://askubuntu.com/questions/53014/why-use-sbuild-over-pbuilder as reference | 19:48 |
| stokachu | just for the commands not for which is better :P | 19:48 |
| jrr | "./debian/rules build" ends in the same "/usr/bin/ld.bfd.real: cannot find -lgtk-3" etc | 19:49 |
| jrr | this was after a fresh apt-get source | 19:49 |
| jrr | here's a new pastebin http://pastebin.com/iD7sT4Hd | 19:53 |
| stokachu | barry: i uploaded a merge for bug 1103644, though i think this could easily be a sync but the documentation on sync's didnt state it had to be since it is before debian import freeze | 19:57 |
| ubottu | bug 1103644 in python-tz (Ubuntu) "Please merge python-tz 2012c-1 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1103644 | 19:57 |
| stokachu | unless im reading it wrong | 19:57 |
| infinity | dobey: Native -> non-native is simple. Have your unpacked source, put the orig.tar.gz in the parent directory, make sure the new version in debian/changelog is sane, debuild -S. Boom non-native. | 19:58 |
| seb128 | hum, ubuntu-defaults-image hangs for me | 19:58 |
| seb128 | does anyone knows where are the sources it tries to use defined? | 19:59 |
| seb128 | strace indicates it hangs trying to contact 91.189.88.40 which is drescher.canonical.com | 19:59 |
| dobey | infinity: right; that bit is easy; i mean more in the context of how it may break the world with respect to UDD | 20:00 |
| infinity | jrr: What does "dpkg-checkbuilddeps" say? | 20:00 |
| infinity | dobey: Sneezing breaks UDD. I'm not sure I'd care much. :P | 20:00 |
| jrr | infinity: nothing | 20:01 |
| infinity | dobey: (But, in this case, I don't see why it should break, UDD imports unpacked sources, not diffs, how it's unpacked should be irrelevant) | 20:01 |
| dobey | infinity: right, but some branches are special, no? when Vcs-Bzr: is used and such? | 20:02 |
| jrr | with return code of zero | 20:02 |
| dobey | of course, the branch that Vcs-Bzr: points to, is currently not there, so i guess it won't be too bad | 20:02 |
| seb128 | hum, great, I simply can't contact archive.ubuntu.com ... is that working for others? | 20:03 |
| xnox | jrr: are you cross-coompilng or using some funny linker? | 20:03 |
| xnox | jrr: it works fine here on quantal for me. | 20:03 |
| sarnold | seb128: responds to ping, http | 20:03 |
| barry | dobey: sure. i've got it in my browser tab now :) | 20:03 |
| xnox | jrr: e.g. why is it .real linker =/ | 20:04 |
| xnox | dobey: UDD handles source package format changes just fine. | 20:04 |
| seb128 | sarnold, can brower http://archive.ubuntu.com in a web browser? | 20:04 |
| seb128 | bah, it works for chinstrap, I guess it's my connection | 20:04 |
| sarnold | seb128: ubuntu/ .. | 20:04 |
| seb128 | sarnold, thanks | 20:04 |
| jrr | xnox: I have arm-linux-gnueabi-gcc installed.. maybe it messed with some symlinks? | 20:06 |
| xnox | jrr: it shouldn't. | 20:06 |
| jrr | ohhhh I know what it is | 20:07 |
| jrr | I had my gcc and g++ replaced with hacky scripts calling inserting -m32 | 20:08 |
| jrr | sorry about that! | 20:08 |
| xnox | that makes sense...... | 20:08 |
| jtaylor | mterry: you (co-)wrote the pycurl py3 test? | 20:10 |
| jtaylor | I've got a few issues/questions with it | 20:10 |
| jrr | I was building some stuff that didn't respect env CFLAGS | 20:10 |
| mterry | jtaylor, I may have helped port it to py3, IIRC | 20:10 |
| jtaylor | mterry: tornados testsuite fails on it | 20:11 |
| jtaylor | invalid arguments to: curl.setopt(pycurl.URL, utf8(request.url)) | 20:11 |
| jtaylor | where utf8 outputs bytes | 20:11 |
| jtaylor | it works if it would pass in unicode, I guess thats an issue of tornados testsuite#? | 20:12 |
| jrr | xnox: okay, got it rebuilt. Time to start chasing the bug.. thanks! | 20:12 |
| jtaylor | also something crashes when one tab completes Curl() from ipython, still need to check what goes wrong there | 20:12 |
| seb128 | hum | 20:13 |
| seb128 | it failed with that error, this time | 20:13 |
| seb128 | chroot: failed to run command '/usr/bin/env': No such file or directory | 20:13 |
| seb128 | wth | 20:13 |
| mterry | jtaylor, hm | 20:15 |
| mterry | jtaylor, it's been a while, let me look at code real quik | 20:16 |
| jtaylor | mterry: ipythons issue: hasattr(pycurl.Curl(), "trait_names"), throws SystemError | 20:19 |
| jtaylor | on quantal, I'll quickly test raring | 20:20 |
| mterry | jtaylor, ah I just grabbed this patch from upstream's tracker, and maybe modified it a bit to work. But still, let me dig into why it's failing | 20:21 |
| jtaylor | there too | 20:21 |
| === jsalisbury_ is now known as jsalisbury | ||
| jtaylor | filed bug 1103667 for the latter issue | 20:24 |
| ubottu | bug 1103667 in pycurl (Ubuntu) "python3 pycurl hasattr throws SystemError" [Undecided,New] https://launchpad.net/bugs/1103667 | 20:24 |
| mterry | jtaylor, so I'm thinking that the utf8 issue is a fault with tornado's testsuite, and I'm confused about the ipythons thing. So 'trait_names' is a method that ipython looks for to provide tab-complete info? Why would it not being there throw an error? | 20:27 |
| jtaylor | don't know, thats pycurls issue | 20:27 |
| jtaylor | hasattr must not throw an exception | 20:28 |
| jtaylor | (I think it even eats them in python2) | 20:28 |
| jtaylor | hasattr works if it actually has the attribute | 20:29 |
| jtaylor | it only fails if it doesn't exist | 20:29 |
| mterry | jtaylor, ah yeah I see it in python console, hasattr is bogus | 20:29 |
| stgraber | kees: unping. Sent an e-mail to the Debian BTS instead (libseccomp related) | 20:29 |
| mterry | jtaylor, working on a patch | 20:32 |
| stgraber | jdstrand: if you have a few minutes for a quick re-review, I updated the state of bug 1082431 | 20:34 |
| ubottu | bug 1082431 in libseccomp (Ubuntu) "[MIR] libseccomp" [Undecided,In progress] https://launchpad.net/bugs/1082431 | 20:34 |
| jtaylor | mterry: concerning the setopt, aparently the python2 variant accepts utf8 | 20:34 |
| jtaylor | mterry: wouldn't it make sense when the python3 wrapper accepts python unicode and decodes that to utf8? | 20:35 |
| jtaylor | instead of having people do that before calling setopt | 20:35 |
| mterry | jtaylor, you mean accept utf8 and decode it to unicode? | 20:35 |
| mterry | jtaylor, the way this patch is written, the python3 API is all native strings (i.e. unicode) | 20:36 |
| jtaylor | mterry: no, accept python3 string (which is (any?') unicode encoding and pass it to curl in what it expects (utf) | 20:36 |
| jtaylor | mterry: but in which encoding? and what does curl want? | 20:36 |
| mterry | jtaylor, python3 strings are not utf8 (bytes) but rather 'pure' unicode | 20:36 |
| jtaylor | is python3 string encoding even fixed? python3.3 has variable internal encoding | 20:36 |
| jtaylor | what do you understand as pure unicode? | 20:37 |
| dobey | py3 strings are unicode. they can be utf-8, utf-16, ucs-2, or whatever, as long as it's unicode. for pure bytes, there's the bytes object still | 20:37 |
| jtaylor | I'd be surprised when curl accepts a PyUnicodeString (or whatever its named) | 20:37 |
| mterry | jtaylor, I don't know the internals, but Python3 makes a distinction between bytes and strings. You said the utf8() function is returning strings, so that's the problem (at least assuming this Python3 patch's API is sensible) | 20:37 |
| mterry | Which is what we're discussing I guess | 20:37 |
| jtaylor | no, utf8 returns bytes | 20:38 |
| mterry | jtaylor, I'm sorry. I meant bytes there | 20:38 |
| mterry | jtaylor, rest of the sentence is the same | 20:38 |
| jtaylor | wait now I get it | 20:38 |
| mterry | dobey, right. But 's'.encode('utf8') is no longer a Python3 string, but a bytes object | 20:39 |
| jtaylor | hm ok it looks like a tornado issue | 20:39 |
| jtaylor | I'll file a bug | 20:39 |
| mterry | Despite being utf8 under the hood. That's what I meant | 20:39 |
| mterry | jtaylor, again, this python3 patch's API may not be 'official'. It's not yet accepted upstream | 20:39 |
| mterry | jtaylor, but it's what we're using for now anyway | 20:40 |
| jtaylor | yeah, I'll just file it so upstream knows about the issue | 20:41 |
| mterry | jtaylor, is there a bug for the ipython issue? I believe I've fixed it | 20:41 |
| jtaylor | mterry: bug 1103667 | 20:41 |
| ubottu | bug 1103667 in pycurl (Ubuntu) "python3 pycurl hasattr throws SystemError" [Undecided,New] https://launchpad.net/bugs/1103667 | 20:41 |
| mterry | jtaylor, upload pending for that one | 20:43 |
| jtaylor | thx | 20:43 |
| stgraber | kees, hallyn: I guess I should have test built on i386 too (just did amd64), anyway, looks like we have a test failure with libseccomp on i386. I'm really not familiar with that stuff, so if one of you has a clue as to exactly what's failling and whether we should care: https://launchpadlibrarian.net/129232657/buildlog_ubuntu-raring-i386.libseccomp_1.0.1-1ubuntu1_FAILEDTOBUILD.txt.gz | 20:45 |
| stgraber | I'll try to reproduce here in a minute to make sure it's not somehow buildd-related, though if it was, I'd have expected amd64 to fail too, which it didn't. | 20:46 |
| stgraber | kees, hallyn: note that ERRORs are ignored, only FAILURE are considered fatal | 20:47 |
| jdstrand | stgraber: I've got it on my list, but I'll wait for this to get resolved | 20:48 |
| jtaylor | mterry: will you comment on the upstream bug? | 20:48 |
| stgraber | jdstrand: thanks. | 20:48 |
| mterry | jtaylor, the python3 one or did you file a separate bug for the issue? | 20:48 |
| jtaylor | mterry: I was thinking adding it to the python3 patch in upstreams bug | 20:49 |
| jtaylor | where it originates from in the first place | 20:49 |
| mterry | jtaylor, makes sense, will do | 20:49 |
| hallyn | stgraber: will look in a min | 20:50 |
| hallyn | stgraber: is that the libseccomp i'll get with pull-lp-source right now? | 20:56 |
| stgraber | hallyn: yep | 20:56 |
| hallyn | k | 20:56 |
| stgraber | hallyn: the only change I pushed in that last version is running tests/regression post-build and that's what found a failure on i386 | 20:56 |
| stgraber | so if there's an actual bug, then we already have it in the archive... | 20:56 |
| hallyn | stgraber: (hopefully kees sees it and looks at it, but i'm waiting on a raring i386 install to test on) | 21:13 |
| stgraber | hallyn: I'm running the build here in a raring container (on the raring kernel though, so should be similar to the buildd) | 21:14 |
| kees | hallyn, stgraber: already testing it for a -2 upload ;) | 21:18 |
| kees | it takes tooooo long to build now ;) | 21:18 |
| dupondje | It should be possible to copy files from 1 gvfs mount to another no? | 21:19 |
| stgraber | kees: hehe, yeah, it's making the build at least 10x slower :) | 21:24 |
| stgraber | hallyn, kees: reproduced the test failure on i386 here, so it doesn't appear to be buildd-specific at least | 21:25 |
| kees | stgraber: oh! let me try too... | 21:26 |
| stgraber | hallyn, kees: if you don't want to wait 10min for the tests to run, "./regression -b 17-reset" will run just the failing batch. There should be a single failure at 14-reset%%007-00001 | 21:28 |
| stgraber | s/17/14/ ^ | 21:28 |
| kees | stgraber: confirmed | 21:37 |
| kees | Test 14-reset%%007-00001 result: FAILURE bpf_sim resulted in ALLOW | 21:37 |
| stgraber | kees: was that on a Debian or Ubuntu system? (just curious on whether it's the distro that somehow broke something) | 21:38 |
| kees | stgraber: that's on debian unstable i386 | 21:38 |
| kees | may be a missing dep, though, since I also see errors about missing /usr/include/asm/unistd.h | 21:38 |
| stgraber | yeah we've got those on Ubuntu too, though they result on ERROR lines as those tests fail to run (or so is my interpretation at least) and I've got those on amd64 too without the failure | 21:39 |
| * kees scratches his head | 21:39 | |
| kees | it should be part of linux-libc-dev | 21:40 |
| kees | oh, debian is missing the symlink for /usr/include/asm | 21:40 |
| === salem_ is now known as _salem | ||
| stgraber | kees: manually making the symlink between /usr/include/asm-generic and /usr/include/asm gets me an extra FAILURE in 14-reset | 21:43 |
| stgraber | "4-reset%%002-00000 result: FAILURE bpf_sim resulted in KILL" | 21:44 |
| kees | whee | 21:44 |
| kees | okay, found the bad use of /usr/include/asm/unistd.h | 21:48 |
| kees | stgraber: fixing that got rid of the errors for me, but 007-0001 still failed. I'll keep digging | 21:49 |
| slangasek | Sweetshark: hi, I talked with seb128 yesterday about the libreoffice precise SRU needing changelog fixups and a reupload; I've rejected the previous upload based on this, when a new version hits the queue feel free to ping me for an expedited review | 21:54 |
| hunnicutt | Hello | 21:58 |
| hunnicutt | I would like to compile nm-applet from source using the same command-line for "configure" used to compile with Ubuntu 12.04 | 21:59 |
| hunnicutt | I have the nm-applet 0.9.4.1, fetched from git. But I don't know how to build this for GTK-2, it seems to create a shared library which pulls in GTK 3 | 21:59 |
| hunnicutt | I've searched for a Wiki page telling me what arguments I might provide to configure, but not found one. | 22:02 |
| cjwatson | Not the sort of thing that goes in wiki pages, really | 22:03 |
| hunnicutt | where does it go? | 22:04 |
| stgraber | in the packaging (debian/rules) | 22:04 |
| cjwatson | The package's debian/rules is responsible for deciding how to configure the package | 22:04 |
| cjwatson | You can either try to run the packaging against git, or you can look at a build log to see what it did | 22:04 |
| barry | is anybody successfully using r145 of lp:auto-package-testing on raring today? | 22:04 |
| cjwatson | https://launchpadlibrarian.net/99824547/buildlog_ubuntu-precise-i386.network-manager-applet_0.9.4.1-0ubuntu2_BUILDING.txt.gz in this case | 22:05 |
| cjwatson | So that's --libexecdir=/usr/lib/NetworkManager --enable-more-warnings=no --enable-indicator added to a batch of reasonably default options - unfortunately dh_auto_configure doesn't print what it's doing by default, so let me find it for you | 22:05 |
| hunnicutt | Thanks this is really helpful. | 22:06 |
| dobey | gah, so the new glib breaks anything trying to build docs with gtk-doc :( | 22:06 |
| hunnicutt | It's possible I should give you a higher-level overview. I'm trying to figure out the best way to fix an upstream bug in gnome.org sources and make the patch available to Ubuntu 12.04 | 22:06 |
| cjwatson | Well, most of the default options in dh_auto_configure are filesystem layout stuff | 22:07 |
| cjwatson | --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-maintainer-mode --disable-dependency-tracking | 22:08 |
| cjwatson | If you just want to install to the default of /usr/local or some prefix in your home directory, then you can omit that and just use the package-specific options I gave above | 22:08 |
| hunnicutt | I tried to build with no special arguments and as a result (after sudo make install) I had built a libnm-gtk which produces the following GTK warning and dies: | 22:09 |
| cjwatson | You should learn how to build packages in general if you're planning on fixing them, though - https://wiki.ubuntu.com/UbuntuDevelopment#Packaging has a bunch of links | 22:09 |
| hunnicutt | gtk-error that is | 22:09 |
| hunnicutt | Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported | 22:09 |
| cjwatson | I doubt there's any guarantee that an unmodified nm-applet from git will work on 12.04 | 22:09 |
| hunnicutt | OK thanks | 22:10 |
| cjwatson | Or an unmodified anything in general, particularly across GTK+ 2/3 porting | 22:10 |
| hunnicutt | Interesting, that makes it more difficult to fix in upstream. | 22:10 |
| hunnicutt | But I will go read this info about packages. | 22:10 |
| hunnicutt | Thanks. Mostly I don't have a lot of time to expend on this right now, but a particular papercut is wasting enough time that I want to patch it. | 22:11 |
| cjwatson | Though this does seem backwards, since nm-applet in precise was GTK+ 3 | 22:11 |
| hunnicutt | oh wait is this simply b/c I have gtk-2.0-dev on my machine and not gtk-3.0-dev? | 22:11 |
| cjwatson | Quite possibly; you *must* satisfy build-dependencies of a package | 22:12 |
| cjwatson | It may be worth a little up-front investment to learn how to use a proper "build package in clean chroot with just its build-dependencies" tool such as sbuild | 22:12 |
| sarnold | cjwatson++ | 22:13 |
| cjwatson | But failing that (and it is certainly some investment to figure out how to use that kind of workflow against upstream, and may be painful for desktop-ish things in particular where you might want to have your X session handy), at least do 'sudo apt-get build-dep network-manager-gnome' | 22:13 |
| cjwatson | Certainly for stuff I work on upstream I only do chroot builds when I'm building packages to install and test, not for routine development | 22:14 |
| === henrix is now known as henrix_ | ||
| hunnicutt | I'll look at sbuild, thanks. and that apt-get is fabulous. Who knows, maybe I will just put a unified diff in the bug report. I just want nm-applet to cease with so many open dialogs. :) Long-term I'd love to contribute more effectively but for now I am mostly trying to make money with this system involving desktop apps, so that's where my focus is. | 22:15 |
| hunnicutt | hmm apt-get build-dep says I lacked as follows: | 22:16 |
| hunnicutt | dh-autoreconf dh-translations libappindicator3-dev libdbusmenu-glib-dev | 22:16 |
| hunnicutt | libgnome-bluetooth-dev libgtk-3-dev | 22:16 |
| hunnicutt | let that be a lesson to me. | 22:16 |
| cjwatson | Looks like nm-applet tries to autodetect GTK+ 2 or 3 at build time by default (unless you use --with-gtkver=3), so build-dependencies would certainly explain it. It defaults to trying 3 then 2. | 22:16 |
| cjwatson | I should also say that the network-manager-applet package has a number of patches against upstream. | 22:17 |
| hunnicutt | ruh ro | 22:17 |
| cjwatson | If you're trying to get a working tree you can experiment with rather than "compare against upstream behaviour", you'd be better served building the actual Ubuntu package | 22:18 |
| infinity | kees: Err, wait. What? What's trying to include /usr/include/asm/* ? | 22:18 |
| infinity | kees: I mean, instead of including <asm/*> which will let the compiler not be silly. | 22:18 |
| hunnicutt | that's great to know. | 22:18 |
| cjwatson | Install ubuntu-dev-tools and run 'pull-lp-source network-manager-applet precise' and you'll get an unpacked source tree with the Ubuntu patches auto-applied - they're in debian/patches/ and managed using quilt | 22:19 |
| hunnicutt | I won't be sad to compare with upstream, but I see that I want to learn about the packaging system much more. | 22:19 |
| kees | infinity: yes, a testsuite was doing gcc -E -dM /path/ instead of echo ".h" | gcc -E -dM - | 22:19 |
| kees | (I've found and fixed it now) | 22:19 |
| hunnicutt | wut it's that easy? | 22:19 |
| hunnicutt | thanks | 22:19 |
| infinity | kees: Oh, good. I didn't get all the context on a quick backscroll skim, I was just gearing up for some sort of protracted battle wherein I got to call someone names for blaming headers and/or toolchains. | 22:20 |
| infinity | kees: Thanks for ruining my fun. | 22:20 |
| infinity | kees: Jerk. | 22:20 |
| infinity | kees: :) | 22:20 |
| cjwatson | Getting a proper version-controlled tree is rather more package-specific and I wouldn't want to guess in this case without more investigation, but you can always blat it into a DVCS locally. | 22:20 |
| cjwatson | Patch application varies among packages, unfortunately; network-manager-applet is using the current best practice for patch management in source packages, though. | 22:21 |
| cjwatson | So you will see some other methods if you do lots of packaging work, but the older ones are gradually dying out. | 22:21 |
| cjwatson | (Sorry if this is way too much information.) | 22:22 |
| hunnicutt | nope this was excellent. I had been looking for a brain-dump on how to do this, but didn't expect there to be this command line that pulled the ubuntu source. I mean; that's perfect, mostly. | 22:23 |
| hunnicutt | Also did not realize this channel was the place to get started... | 22:23 |
| infinity | Yeah, pull-{lp,debian}-source are awesome, now that I've trained my fingers to use them. | 22:23 |
| infinity | hunnicutt: This channel isn't the place to get started, #ubuntu-motu is. But it seems Colin was feeling helpful. :) | 22:24 |
| hunnicutt | motu? | 22:24 |
| cjwatson | stupid name :) | 22:24 |
| cjwatson | "masters of the universe". (I think there's actually #ubuntu-packaging nowadays.) | 22:24 |
| infinity | There may also be an ubuntu-mentors or similar. | 22:25 |
| infinity | Arguably, this needs a looking at and consolodation. :P | 22:25 |
| hunnicutt | well I wouldn't want to wind up some place too pedantic-sounding. | 22:25 |
| cjwatson | The problem is we keep doing half of a consolidation - the half that goes "OK, let's create a new thing with a better name" | 22:25 |
| cjwatson | This is arguably less than totally ideal | 22:25 |
| infinity | cjwatson: Dude, we can totally solve it with one last rename. | 22:26 |
| cjwatson | One more layer of indirection, right? | 22:26 |
| infinity | Absolutely. | 22:26 |
| mwhudson | maybe a bot that forwards conversation from one place to another? | 22:27 |
| mwhudson | maybe multiple bots? | 22:27 |
| mwhudson | nothing can go wrong there right? | 22:27 |
| infinity | mwhudson: On a scale of one to things you shouldn't joke about, that rates an argh. | 22:30 |
| slangasek | an argh, plus or minus fwibble | 22:31 |
| hunnicutt | tsk it seems like I have some different gcc version, while I'm at it. I had forgotten that I needed to turn off warnings-as-errors to compile this nm-applet | 22:31 |
| hunnicutt | Whereas the right way is perhaps to correct these warnings before fixing the bug which affects me. | 22:31 |
| hunnicutt | oh, joy | 22:32 |
| hunnicutt | ahh, not the problem is that I lack libindicator-3-dev and therefor ENABLE_INDICATOR is not defined and therefore compile error due to actual bug that doesn't appear for a compile with all the needed dependencies. | 22:36 |
| kees | infinity: heheh :) | 22:53 |
| === fisted_ is now known as fisted | ||
| dobey | anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/raring/gtk-doc/fix-type-init/+merge/144605 please? | 23:26 |
| === cpg|away is now known as cpg | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!