=== 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 [03:30] micahg: re imagemagick> hi! no, I'm not actively working on it [05:26] Good morning [05:28] good morning pitti (my usual reminder that going to sleep for a bit might be a good idea ;)) [05:30] stgraber: heh, happy to be of service :) [07:02] Are there any mentor programs for someone that wants to start contributing? [07:03] Looking to challenge myself a bit more, so looking at contributing to a linux distro. [07:15] Quick question: Ubuntu uses update-alternatives right? [07:25] xxtjaxx_: Yes. [07:30] infinity: Thanks === chiluk is now known as chiluk_away [08:11] 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:12] 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:14] Of course the "Developing for the HUD" sections of the wiki are bone-dry :( [08:30] good morning [08:36] the raring daily build for 1-22 doesn't boot [08:36] live cd [08:36] or rather, mouse but no installation windows [08:37] oh wait, nvm.....just taking forever === tkamppeter_ is now known as tkamppeter === megha is now known as hack === doko__ is now known as doko [09:26] bdrung: feel free to do it [09:26] don't forget to commit to the ubuntu-desktop VCS === henrix_ is now known as henrix === yofel_ is now known as yofel [11:03] jodh, about 1103414, is this reproducible for you locally? [11:04] doko: I'll retry my build... [11:04] jodh, please attach the preprocessed source, and the command line options used (and please make the build verbose by default) [11:05] doko: ack. === Sweetsha1k is now known as Sweetshark [11:26] @pilot in === 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 [12:25] jodh: do you think we'll get upstart inotify events in raring? [12:31] ev: well, it is in plan, but more teetering on the edge than centre-stage atm. [12:33] jodh: noted; thanks! [12:34] 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] Ubuntu bug 1064395 in apport (Ubuntu) "Apport should still send reports to daisy.ubuntu.com for binaries in the blacklist" [Undecided,New] [12:35] @pilot in === 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 [13:06] @pilot in === 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 [13:08] * dholbach hugs mdeslaur and herton [13:08] * mdeslaur hugs dholbach === cpg is now known as cpg|away [13:08] :-) [13:30] 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? === Ursinha_ is now known as Ursinha === rsalveti_ is now known as rsalveti [13:32] 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 === fisted_ is now known as fisted === henrix is now known as henrix_ === sraue_ is now known as sraue === henrix_ is now known as henrix [13:57] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, mdeslaur === henrix is now known as henrix_ === henrix_ is now known as henrix === MacSlow|lunch is now known as MacSlow [14:24] ev, done [14:30] mpt: thanks === chiluk_away is now known as chiluk [14:44] doko: hi, do you have some minutes to query about ubuntu's linker? [14:45] 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] 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] doko: so if you know how to force the DSO everywhere, I'd like to apply this to our project [14:46] doko: is ubuntu using gold or the traditional linker? Any changes to libtool? === slank_away is now known as slank [15:03] 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:04] rbasak: yeah, did look into it. [15:04] rbasak: and in the one from fedora as well [15:04] strange part is that fedora works, ubuntu doesn't (to cause the error) [15:05] k-s: pastebin the error please? [15:05] (and the linker command line) [15:06] rbasak: http://pastebin.com/ZnmkASs0 from an user [15:07] rbasak: the same configure/Makefile worked for Fefora, Arch and Gentoo [15:07] oops, he said there is another log, I'm waiting for his new pastebin [15:11] can somebody please reject https://code.launchpad.net/~ben-kietzman/ubuntu/quantal/yasm/fix-for-1064341/+merge/140267? [15:15] dholbach: done [15:16] thanks stgraber [15:20] rbasak: http://pastebin.com/QiU4fcRp using libeet.la http://pastebin.com/CxFL0cNZ [15:22] 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:23] rbasak: then I wonder: any patch to libtool? [15:23] 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:24] rbasak: it is [15:25] rbasak: it is in libeina, which is a dependency for libeet.la as stated in the second pastebin [15:25] 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] rbasak: I'm trying to understand why your libtool is different from all other distro [15:26] rbasak: if it's a flag I can turn on, or it's a patch [15:26] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur [15:26] 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] rbasak: thanks! [15:27] cjwatson: i am attempting to do a merge/fix conflicts for console-setup, is that ok with you? === k-s is now known as k-s[AWAY] [15:29] 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] d someone should let it through. [15:29] 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] 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] ok no worries, so ill just pick another package then [15:31] cjwatson: how about aptitude? looks to be only diff changes [15:33] mterry: do you mind if i work on the merge fixes for aptitude? [15:33] stokachu, please do :) [15:33] cool thanks! [15:33] stokachu, it might be complicated too, I don't recall [15:34] mterry: the report shows 2 files needing change [15:34] stokachu, k [15:36] stokachu: "only diff changes"? [15:36] stokachu: But it's fine by me [15:36] k-s, rbasak: the .la file references a file i n /home/ while you /opt/lib/ is searched. are these incompatible libs? looks like a local issue [15:36] cjwatson: yea the report just showed 2 files with diff conflicts [15:40] 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] bug 1097783 in genshi (Ubuntu) "re module apis return longs now" [High,Triaged] https://launchpad.net/bugs/1097783 [15:40] Or we could cherry-pick it I suppose. Not worth it if you're planning another merge though. [15:47] do we still need to set the pocket to -proposed for SRUs to stable releases, or does that get handled automatically now? [15:47] it'll get rewritten [15:50] Yeah, you can do either [15:51] I've been getting into the habit of just writing "precise" [15:55] mterry: so when i do a merge with bzr merge debianlp:aptitude everything applies cleanly :\ [15:55] but the report shows conflicts so is the report outdated on merges.ubuntu.com? [15:55] merges.ubuntu.com is not necessarily as smart as bzr [15:56] 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:57] ok ill use the grab-merge tool and compare, if everything is good ill create a merge bug for this ok/ [15:57] *? [16:01] Daviey: do you think somebody on the server team could verify that the fix for bug 901600 meets your needs? [16:01] 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] shouldn't take very long [16:02] mterry: interesting, doing grab-merge has the latest changes but debianlp does not [16:02] You might want to just ignore bzr for this if it's out of date [16:02] ok === ev_ is now known as ev [16:13] stokachu: do bzr merge => generate debdiffs against debian & compare with previous old ubuntu to old debian debdiff. [16:13] stokachu: sometimes bzr is smart and actually does merge everything right. [16:13] xnox: bzr merge doesn't help when the import into lp:debian/... has failed :) [16:14] =)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) [16:14] Hmm, but it looks up to date === salem_ is now known as _salem [16:15] 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] stokachu: I think you must have misread someething ... [16:15] cjwatson: yea i did :\ [16:16] 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] lp:debian/experimental/aptitude is also up to date with what's idling in the experimental. [16:16] stokachu: are you implying aptitude is now insync?! [16:17] stokachu: or the debdiff is the same, sans new changelog entry. [16:17] 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:18] so i dont think i need a new changelog entry or anything [16:18] unless I need to specify that this was a correct merge through bzr and not through merges.u.c [16:18] You will do; it likely means that it (thinks it) figured out how to merge everything by itself. [16:18] stokachu: we upload package into ubuntu. new upload must be higher version, and it needs to have a changelog entry. [16:19] Do double check that what it did is what you expect though [16:19] stokachu: and the changelog entry should still document remaining (same as before) ubuntu delta. [16:19] ok gotcha [16:20] jodh, new upstart still doesn't configure with --disable-silent-rules === k-s[AWAY] is now known as k-s [16:21] doko: back, the /opt is the ./configure --prefix=/opt. It should look just into build [16:22] but apparently it doesn't [16:22] 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] doko: do you patch libtool or something like that? [16:23] afaik, no. and the diff to debian is available too === _salem is now known as salem_ [16:28] doko: diff of my libtool and ubuntu's is quite relevant [16:29] doko: thins like link_all_deplibs. Do you think it's an option or is it a patch? [16:29] 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:30] doko: I'm checking with the ubuntu user if that's the problem. :-) [16:30] doko: then i still don't know === ev_ is now known as ev [16:31] doko: he acks that changing link_all_deplibs from no to unknown fixes it [16:31] doko: unknown = yes according to libtool info page. [16:32] 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] doko: but I wonder why this ends as 'no' in ubuntu, not in other [16:33] doko: not packaged yet, it's still under development [16:33] doko: as for the libtool, I'm more interested to know why the variable has different value [16:33] 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] k-s: look at the changelog. [16:34] is the changelogs url still http://changelogs.ubuntu.com/changelogs? [16:34] bah, just get the source [16:34] looks like aptitude needs a small modification to point to ubuntu's changelog server [16:34] it's a very old Debian patch [16:34] 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] Debian bug 191425 in libtool "Links explicitly with dependent shared libraries" [Wishlist,Fixed] [16:34] Debian bug 199423 in libtool "libtool tries (unnecessarily) to link explicitly with dependent shared libraries" [Wishlist,Fixed] [16:35] Debian bug 238681 in libtool "librrd0-dev: libtool cannot link to librrd because of bad dependencies" [Wishlist,Fixed] [16:35] (I think.) Predates Ubuntu. [16:35] 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:36] harmful> particularly in cases where the indirectly-linked library changes its SONAME, which does happen [16:41] doko: it's confirmed to be 'debian/patches/link_all_deplibs.patch' [16:42] stokachu: It already had that modification in the Ubuntu delta against Dbian [16:42] *Debian [16:42] k-s: I think it's an upstream bug. [16:42] 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] /usr/bin/ld: bin/eet/bin_eet_eet-eet_main.o: undefined reference to symbol 'eina_iterator_next' [16:42] /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] /opt/lib/libeina.so.1: could not read symbols: Invalid operation [16:42] doko: indeed, I can solve this by adding lib/eina/libeina.la to LIBADD [16:43] but you don't explicitly link against -leina. you rely on libeet linked against -leina [16:43] 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] doko: seems this patch is the reason [16:43] which is expected with no-add-needed [16:44] k-s, no, the default behaviour is just hiding the upstream bug [16:44] 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] If you don't care about that you can just rebuild everything and mask the problem [16:46] doko: yes, this is true. But the major issue is the libtool script being different. [16:47] 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] doko: what I wanted to do is to force every builder to get the same results with the same flags [16:47] 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] doko: so if some other !ubuntu developer commits... he will do it right and not break ubuntu-ers [16:48] k-s: run buildbots on ubuntu which revert/reject commits ;-) [16:48] xnox: unfortunately not, because link_all_deplibs=no is being set independently of that linker flag [16:48] (launchpad daily builds can be used as well) [16:48] hmm... [16:48] xnox: maybe a better libtool patch would be to check for this flag? (and maybe it would be accepted upstream?) [16:49] xnox, doesn't look an as-needed issue on first sight [16:49] k-s: no better fix upstream [16:49] doko: as i said? [16:49] 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:50] right, but if it passes these excess objects, then it hides thecopy-dt-needed-entries issue [16:51] indeed [16:51] libtool's autoconf support doesn't appear to provide a way to e.g. override that behaviour on the configure command line [16:51] 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:52] 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:53] 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] google brings up e.g. http://www.mail-archive.com/libtool@gnu.org/msg06328.html [16:54] https://lists.gnu.org/archive/html/libtool/2004-11/msg00455.html better link [16:54] at the time the Debian maintainer was either libtool upstream or one of them [16:55] it would've been around that time, anyway [16:55] 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 === sraue_ is now known as sraue [17:00] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === henrix is now known as henrix_ === henrix_ is now known as henrix [17:36] barry: eww; why did you hack the oneconf setup.py that way instead of fixing the broken debian/rules? [17:56] 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:57] dobey, sure, looks fine === fisted_ is now known as fisted [18:04] 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:06] 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:10] 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] better to change setup.py? [18:10] 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:11] barry: artificially limiting package in setup.py is not nice. [18:12] xnox: i'm not talking about backporting the package. i'm talking about pulling the bzr branch and doing ./setup.py install [18:12] 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:13] xnox: i'm not convinced its artificial though [18:13] barry: is the new pybuild stuff uploaded into raring? and how does that deal with py2&3 scripts. [18:13] 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] xnox: not yet. i was trying to get feedback on mitya's branch from doko first [18:14] fwiw, the only reason we re-enabled py2 support at all is for s-c and we're trying to rectify that [18:14] 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:15] barry: well same way I had to reenable devscripts python2, because of ubuntu-dev-tools ;-) [18:16] xnox: perhaps :) anyway, once s-c is fully on py3, i would like to eliminate py2 support for oneconf [18:16] barry: https://launchpadlibrarian.net/128484331/devscripts_2.12.6ubuntu1_2.12.6ubuntu2.diff.gz [18:16] The "meat" of this patch is in the one line "+scripts/devscripts /usr/lib/python2.7/dist-packages/" in the debian/install. [18:17] 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:18] 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] barry: does s-c need python2 scripts? [18:18] or just python modules? [18:19] xnox: just 'import oneconf' [18:19] hence don't run setup.py with python2 at all. [18:19] xnox: because if it was shelling out to run the scripts, it wouldn't care :) [18:19] 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:20] forget about all the best python2 packaging practices and do hacks instead =) [18:20] 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] barry: it's a packaging problem; not an upstream source problem [18:20] barry: you just broke python4 support =) [18:20] * barry shudders [18:21] actually a real problem, each python transition we have to fix packages that hard-coded << X.Y for no reason. [18:21] mterry: I uploaded a merge request (bug 1103541) if you've got time for any comments on it etc [18:21] 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] 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] barry: not intended or do not work at all. [18:21] ? [18:21] xnox: yes, that's a real problem, and i'm not holding my breath for py4 :) [18:22] 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] 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:23] is oneconf even useful outside the context of software-center? [18:23] 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] dobey: yes, but only s-c imports the oneconf library [18:24] 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] 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] didrocks: agreed! and now they do. :) [18:25] 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] why doesn't running them with py2 work? [18:26] it's untested :) [18:26] 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] python /usr/bin/oneconf-query works fine here :) [18:26] dobey: head /usr/bin/oneconf-query [18:27] 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] why is it 3.3 instead of just "python3" btw? [18:27] yeah 3.3 is wrong as well ;-) [18:28] dobey: ah, nothing then. i still say that the we should not claim to support running those scripts under py2 [18:28] fwiw, upstream shebang is `/usr/bin/env python3` as it should be. it gets rewritten [18:28] by the build process [18:29] barry, didrocks: I guess that apport triggering for oneconf-query every time I install a package is a known issue? [18:29] seb128: I assigned the bug to barry [18:29] didrocks, thanks, I assumed it would be a known issue ;-) [18:29] barry, any ETA on the fix? [18:29] seb128: what's the bug #? [18:29] I guess is was what he uploaded yesterday evening though [18:29] 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:30] barry, dunno, look to the bugs assigned to you? ;-) [18:30] seb128: the new oneconf is in the archive; upgrade? :) [18:30] or are you using a slow mirror? [18:30] dobey: that's not how oneconf-query is currently written [18:31] the error is: /usr/bin/oneconf-query: 'GNUTranslations' object has no attribute 'ugettext' [18:31] but i agree it's good practice. a total rewrite wasn't on my radar :) [18:31] let me try to upgrade [18:31] dobey, I upgraded this morning, let me retry [18:31] 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] seb128: oh, that's a different crash [18:31] 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:32] seb128: i am not seeing that though [18:32] * xnox just saw that with tests while building oneconf. [18:32] barry, bug #1103192 [18:32] Error: Launchpad bug 1103192 could not be found [18:33] dobey, ii oneconf 0.3.2 all synchronize your configuration da [18:33] dobey, seems the current version [18:33] barry, bug #1103192 [18:33] seb128: got it. i'll work on that [18:33] ubottu, wake up bot ;-) [18:33] seb128: I am only a bot, please don't think I'm intelligent :) [18:33] 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] barry, thanks [18:34] seb128: is there someone on the desktop team who can look at bug 1101326? [18:34] bug 1101326 in consolekit (Ubuntu) "console-kit-daemon appears to consume 2GB of memory" [High,New] https://launchpad.net/bugs/1101326 [18:34] dobey: i have a merge proposal with a simpler fix comming shortly. [18:34] bdmurray, consolekit is a foundation bit, maybe ask slangasek? [18:34] heh, ok [18:34] 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:35] seb128: we were hoping somebody might want that hot potato on the desktop side =) [18:35] no, the last one who was enough into plumbing for those issue in desktop was pitti [18:35] we don't have anyone with ck clues atm [18:35] understood [18:35] anyone to help me with the touchscreen? [18:35] slangasek, xnox: sorry about that... [18:35] barry: if only setup.py metadata and pypi tags supported "supported versions per-module & scripts" [18:35] 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:36] in a standard way. [18:36] barry: but then again, all the ubuntuone packages are maintained in this way :) [18:37] 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] barry: would python-tz be something I could help on? [18:38] barry: well it does, because "/usr/bin/env python[3]" breaks virtualenv and is bad practice, no? [18:38] stokachu: hi. what would you like to work on? python3-tz is in the archive currently [18:39] how do i dist-upgrade to 12.10? [18:39] barry: i was just looking at the outstanding merges and python-tz shows debian at 2012c-1 and last upload 2011k-0ubuntu6 [18:40] tion_: support for stable release (12.10) is in the #ubuntu channel. [18:40] 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] stokachu: that would be great! [18:41] barry: ok cool ill work on that today [18:41] 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] jbicha, can you have a look at lp:1102096 please? [18:42] * dobey has enough problems to deal with right now from other upstreams doing some dumb things [18:42] and need to get lunch. bbiab [18:42] 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] How do I get Ubuntu 12.10 to detect more than 4 COM Ports? [18:43] 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:44] :) [18:44] How do I get Ubuntu 12.10 to detect more than 4 COM Ports? [18:44] 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:45] LIDH, this is not a support channel, try #ubuntu [18:45] LIDH: support is in #ubuntu . Also please be patient and don't repost your question that often. [18:45] LIDH: also don't post in multiple channels simultaniously ;-) [18:50] 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] 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:52] toabctl: yes I saw the bug but I'm not able to duplicate it here [18:53] toabctl: maybe you could post your graphics driver & hardware and whether you're using PPAs [18:53] stupid question, i ran a bzr merge and it renamed files to filename.BASE|THIS i assume THIS is from the merged repo? [18:54] and they aren't exactly diffs but are they meant to replace the whole file? [18:57] barry: about that software-center merge proposal... [18:57] bdmurray: i was just going to ask you about that :) [18:58] 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] bdmurray, xnox do you just need it merged or do you need it uploaded? [18:59] barry: merged, I can do the uploading and SRU work [18:59] bdmurray: nod [18:59] bdmurray: what kind of issues? [19:00] segfaults in apt-clone [19:01] fun [19:01] er or libpat-pkg-libc6.10-6 [19:01] oh psivaa do you a script to setup the system in bug 1096022 I could use? [19:01] 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:04] bdmurray: backtraces? [19:06] 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:36] barry, bdmurray: merged [19:36] 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:37] dobey: thanks [19:37] jrr: do you also have the build-essential package installed? [19:38] jrr: it should. unless your source package != distro you are running. [19:38] 12.10, and whatever "apt-get source gnome-control-center" pulled down [19:38] 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:39] 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] jrr: do you have full build-log? [19:39] yeah, hold on I'll redo the whole flow and pastebin it [19:40] kees: hey, are you around? [19:44] hmm, what's the best way to go about converting a native package in ubuntu, to not be a native package? [19:45] xnox: forgive the syntax highlighting http://pastebin.com/t396MTJM [19:46] first time trying to rebuild a package; naively trying to ./configure and make [19:46] if that's not the correct way to do it, I welcome correction =] [19:46] jrr: that's not how one rebuilds a package. [19:46] jjr: ./debian/rules build [19:47] jrr: fakeroot ./debian/rules binary [19:47] run these two commands in clean unpacked source. [19:47] ... or there is a helper to do that. [19:47] or set up pbuilder or sbuild, so you can build it in a clean chroot [19:47] $ debuild [19:48] jrr: note that debian/rules is just a makefile, although usually uses black magic (cdbs or dh) [19:48] jrr: I like to use http://askubuntu.com/questions/53014/why-use-sbuild-over-pbuilder as reference [19:48] just for the commands not for which is better :P [19:49] "./debian/rules build" ends in the same "/usr/bin/ld.bfd.real: cannot find -lgtk-3" etc [19:49] this was after a fresh apt-get source [19:53] here's a new pastebin http://pastebin.com/iD7sT4Hd [19:57] 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] 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] unless im reading it wrong [19:58] 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] hum, ubuntu-defaults-image hangs for me [19:59] does anyone knows where are the sources it tries to use defined? [19:59] strace indicates it hangs trying to contact 91.189.88.40 which is drescher.canonical.com [20:00] 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] jrr: What does "dpkg-checkbuilddeps" say? [20:00] dobey: Sneezing breaks UDD. I'm not sure I'd care much. :P [20:01] infinity: nothing [20:01] 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:02] infinity: right, but some branches are special, no? when Vcs-Bzr: is used and such? [20:02] with return code of zero [20:02] of course, the branch that Vcs-Bzr: points to, is currently not there, so i guess it won't be too bad [20:03] hum, great, I simply can't contact archive.ubuntu.com ... is that working for others? [20:03] jrr: are you cross-coompilng or using some funny linker? [20:03] jrr: it works fine here on quantal for me. [20:03] seb128: responds to ping, http [20:03] dobey: sure. i've got it in my browser tab now :) [20:04] jrr: e.g. why is it .real linker =/ [20:04] dobey: UDD handles source package format changes just fine. [20:04] sarnold, can brower http://archive.ubuntu.com in a web browser? [20:04] bah, it works for chinstrap, I guess it's my connection [20:04] seb128: ubuntu/ .. [20:04] sarnold, thanks [20:06] xnox: I have arm-linux-gnueabi-gcc installed.. maybe it messed with some symlinks? [20:06] jrr: it shouldn't. [20:07] ohhhh I know what it is [20:08]