| * xnox will drop out of network for a moment | 00:00 | |
| cjwatson | It'll depend on /etc/hosts though | 00:00 |
|---|---|---|
| xnox | for all I know `$ host localhost` on precise returns both 127.0.0.1 and ::1, on quantal it returns 127.0.0.1 and Host localhost not found: 3(NXDOMAIN) twice | 00:03 |
| xnox | $ lsmod | grep ipv6 | 00:07 |
| stgraber | xnox: is /etc/resolv.conf identical on both? | 00:08 |
| stgraber | (suspecting that one might be a desktop machine with dnsmasq and not the other) | 00:08 |
| xnox | true | 00:08 |
| xnox | the latter statement. One is a server the other is a desktop | 00:08 |
| stgraber | it wouldn't really surprise me that dnsmasq is returning that localhost record (manpage doesn't really help though) | 00:09 |
| xnox | how would I get a "clean" network environment on my desktop? chroot / sbuild? | 00:09 |
| stgraber | xnox: for that test, does it actually need to bind against localhost? couldn't it bind against :: that'd bind everything? | 00:10 |
| xnox | hmmm... let me check the code | 00:10 |
| xnox | stgraber: yeap it's a bash script and I can easily change ::1 to :: | 00:12 |
| xnox | but the build will take a while, since I don't have unpurged one locally | 00:12 |
| stgraber | the error message still looks odd, I'm not exactly sure of what it's trying to do, so I'm not even sure using :: would make any difference... | 00:14 |
| stgraber | from that error, it seems to just rely on "::1" working which should always be true on a system with a loopback and ipv6 enabled, it doesn't seem to rely on localhost resolving to ::1 | 00:14 |
| xnox | int n = ::getaddrinfo(node, service, &hints, &sa.addrInfo); | 00:15 |
| xnox | if (n != 0) | 00:15 |
| xnox | throw Exception(QPID_MSG("Cannot resolve " << sa.asString(false) << ": " << ::gai_strerror(n))); | 00:15 |
| xnox | would you like print statements? =) | 00:15 |
| xnox | Finished on 2012-06-09 (took 35 minutes, 28.7 seconds) | 00:16 |
| xnox | it will be a while until my laptop gets to test results.... | 00:16 |
| xnox | cause 35min is on launchpad buildd | 00:17 |
| stgraber | I guess I'll take a look tomorrow if you can't figure it out before I get to it. It's still technically a bank holiday here and I have some !work stuff on my todo ;) | 00:17 |
| xnox | =)))))) | 00:17 |
| xnox | ;-) | 00:17 |
| xnox | stgraber: how would you pass a port and :: ? | 00:20 |
| xnox | :::port is a valid ipv6 address... | 00:21 |
| xnox | host ::1:34980 works, maybe that's why it's failing.... | 00:21 |
| xnox | as in it's an IP address... | 00:21 |
| stgraber | xnox: it depends, some software use [::]:<port> for that | 00:22 |
| xnox | hmm | 00:22 |
| xnox | ok good night | 00:26 |
| === chica is now known as trinikrono | ||
| will | hey guys. where should i go if i want to talk about developing apps for ubuntu, specifically the ubuntu app competition going on | 02:13 |
| === badfox is now known as s-box | ||
| === s-box is now known as raju | ||
| === gerard0 is now known as gerardo | ||
| pitti | Good morning | 03:38 |
| pitti | stgraber, cjwatson, kees: argh, did we have a TB meeting last night? calendar fail, sorry | 03:51 |
| === jalcine is now known as Jacky | ||
| RAOF | SpamapS: Would you mind uploading your juju 0.5+bzr531-0ubuntu1.2 to precise-proposed again, but with the last two changelog entries in the .changes file? That way I can accept it over the top of the existing version in proposed, and we can verify the 0.1 bug that requires the fix in 0.2 to verify. | 06:40 |
| SpamapS | RAOF: I wasn't sure if the changes file needed a -v or not.. will do | 06:45 |
| SpamapS | RAOF: done | 06:46 |
| === nijaba_ is now known as nijaba | ||
| dholbach | good morning | 07:17 |
| xnox | dholbach: good morning | 07:17 |
| dholbach | hey xnox | 07:18 |
| xnox | dholbach: you probably want to schedule me for patch piloting ;-) or does the 'first month free' rule apply? | 07:27 |
| dholbach | haha | 07:28 |
| dholbach | yes, good point - let me see where I squeeze you in :) | 07:28 |
| === mnepton is now known as mneptok | ||
| === thegodfather is now known as fabbione | ||
| === RAOF_ is now known as RAOF | ||
| ximion | pitti: ping | 07:50 |
| pitti | hello ximion | 07:51 |
| pitti | ximion: ah, couldn't respond this morning, you were offline | 07:51 |
| ximion | pitti: hi! have you read what I wrote yesterday? | 07:51 |
| ximion | ah, okay :-) | 07:51 |
| pitti | ximion: so I have no strong opinion on the apt backend; I added the plugin support and some other fixes upstream, but as we currently use aptdaemon in ubuntu and you use aptcc for Debian it's probably not very well maintained | 07:52 |
| pitti | so if you want to remove it, please go ahead (but it's the only one that works with all the ubuntu plugins) | 07:52 |
| dholbach | @pilot in | 07:53 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach | ||
| ximion | yep, agreed - we already removed it upstream after ~5 months of inactivity, but then glatzor did many changes, so I included it again | 07:53 |
| ximion | if the backend does not work, it's a bit useless, so removing it for Debian Wheezy is the best way to go, as I can't fix the issues mentioned in time, and if someone fixes them, there would be massive changes needed, where I'm not sure if ftpmasters will ack them | 07:54 |
| ximion | pitti: which functionality is covered by Ubuntu plugins? | 07:54 |
| * ximion thinks it's very bad that everyone is unable to reach glatzor at this important phase | 07:55 | |
| mvo | cjwatson: r79 of my apt-ddtp-tools has a proper source package now in the package/ subdir, let me know when/how we can test the upload (i.e. should this be uploaded to some staging first ) | 07:55 |
| ximion | mvo: can you upload the changes in GPK from the experimental branch to Debian experimental if you've time? :-P | 07:56 |
| pitti | ximion: we already discussed this, the WHAT_PROVIDES plugins, language-selectors "add language support packages as virtual dependencies", and the software-center plugin (I don't know exactly what that does) | 07:56 |
| pitti | the second and third are specific to aptdaemon, I think | 07:56 |
| pitti | while WHAT_PROVIDES plugins are defined by packagekit, and also supported by aptdaemon | 07:57 |
| ximion | yes - what-provides is also supported by aptcc, as it is a official requirement | 07:57 |
| pitti | right, just not the python plugins; I figure we'd have to have an entirely separate implementation of these there | 07:58 |
| ximion | the language stuff is tracked as bug 238634 as far as I know | 07:58 |
| ubottu | Launchpad bug 238634 in packagekit (Ubuntu) "gimp (or any other gnome app) should pull in the respective language-pack-gnome-*" [Wishlist,Triaged] https://launchpad.net/bugs/238634 | 07:58 |
| pitti | it's not just language-pack-*, it's all language support packages | 07:58 |
| pitti | fonts, dictionaries, spell checkers, and the like | 07:58 |
| pitti | installing libo on a system with French and German support should install libo-help-{de,fr} | 07:58 |
| ximion | we could add that to aptcc I guess, added to my TODO (but not in time for Debian) | 07:59 |
| ximion | the software-center plugin is a little odd, mvo, do you know what it does? | 07:59 |
| pitti | ximion: doesn't PK have a generic plugin support? | 07:59 |
| pitti | ximion: it seems more appropriate to define this as plugins instead of adding distro specific package knowledge to the upstream code | 08:00 |
| ximion | pitti: it has, and it's pretty powerful - but PK plugins aren't backend specific (although you could add apt-specific stuff to them) | 08:00 |
| ximion | we use the plugins e.g. to generate a desktop-file-cache or to check for running applications, or for Listaller support... | 08:00 |
| ximion | the plugins have just to be written in C at time, which doesn't seem to be liked by Ubuntu :P | 08:01 |
| ximion | pitti: the backends can ontian whatever they want, and if the feature is apt-specific, we don't need to add stuff to the generic abstraction layer. But you're right, a generic "install everything for language X" makes sense, and I think we already have this | 08:02 |
| === smoser` is now known as smoser | ||
| pitti | ximion: it's "install all i18n support related to the package you just want to install", to be precise | 08:03 |
| pitti | but yes | 08:03 |
| pitti | so if the generic PK plugins support this kind of plugin, it could be written in C for PK in theory | 08:03 |
| ximion | we have a LANGUAGE_SUPPORT what-provides type, which is supposed to return all l18n packages for pkgs currently installed on the system | 08:04 |
| pitti | TBH it's not very likely that Ubuntu will do this as long as aptdaemon is the preferrred PK API implementation | 08:04 |
| pitti | we likely won't maintain two plugins that do the same time, especially not if the PK plugin takes 10 times the effort and is not being used by default | 08:04 |
| pitti | if we would switch to PK only, that'd be a different story, of course | 08:04 |
| pitti | ximion: right; that's exactly what the language-selector plugin implements | 08:05 |
| ximion | so we wouldn't even need a plugin - cool :-) (but I don't remember that language-support is implemented in aptcc... so that needs to be done) | 08:05 |
| pitti | wouldn't a generic PK plugin make it available for all backends? | 08:06 |
| ximion | pitti: well, it depends on how fast aptd can catch up with the changes PK makes. To be honest, I'm not a fan of the aptd approach, but as long as it is working I also don't see a need for switching | 08:06 |
| ximion | pitti: yes | 08:06 |
| ximion | that's the whole point of it :-) | 08:07 |
| ximion | at time, it's already in the specs as recommendation to implement for backends. backends can implement it, but they don't need to: http://gitorious.org/packagekit/packagekit/blobs/master/docs/provides-component-naming.txt#line62 | 08:07 |
| mvo | ximion: it allows adding system-wide license keys | 08:08 |
| ximion | mvo: does it add new DBus API for that? | 08:08 |
| mvo | ximion: iirc it does, need to look at the code to be sure | 08:09 |
| === lindbohm.freenode.net changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| ximion | pitti: we did massive changes on PK API during the last development period (to make PK ready for beeing used for a software-center, I'm working on a distro-sgnostic variant as part of a GSoC project), and as soon as these changes hit Ubuntu without adjustments on aptd, this will fail very bad... | 08:10 |
| ximion | mvo: hmm... okay - then it might be not so trivial to implement it as 3rd-party PackageKit plugin, but it's still possible, I guess | 08:10 |
| ximion | (if you can give hughsie (PK author) a good use-case, he'll also likely accept proposals for PK changes, if they don't violate some PK concept rules) | 08:15 |
| mvo | ximion: it would be nice to have this, I know its not a huge use-case for most people, but some apps require that | 08:27 |
| ximion | mvo: you mean the license-key-management? | 08:29 |
| mvo | ximion: yes | 08:33 |
| cjwatson | mvo: Ooh, I was going to do that this morning | 08:36 |
| ximion | mvo: I can look into this and see what is required to add it - probably we really need to expose a new DBus API, don't know if hughsie would like that (but he might be willing to add it or allow plugins to register new DBus signals) | 08:36 |
| cjwatson | mvo: The section needs to be "raw-ddtp-tarball", not "translated-package-descriptions", or LP will reject it | 08:36 |
| cjwatson | mvo: And maybe "Section: admin" or something, since "Section: base" is dead and gone | 08:37 |
| === tkamppeter_ is now known as tkamppeter | ||
| * cjwatson checks the section list | 08:37 | |
| cjwatson | Ah, "Section: localization" surely :) | 08:37 |
| cjwatson | mvo: Other than that, could you upload this to dogfood? Bonus points if you upload it to precise-proposed there so that I can use it for QA of that other change later on | 08:38 |
| cjwatson | mvo: http://paste.ubuntu.com/1060404/ if you don't already have the .dput.cf fragment | 08:39 |
| Chipzz | cjwatson: I read part of the discussion about debian/copyright yesterday, and I have to agree that I strongly dislike it | 08:44 |
| Chipzz | the bottom line for me (and I am guessing a lot of other ppl who're opposed to it too) is that I am a technical person, not a librarian or secretary (I hope this doesn't come of as too derogatory) | 08:45 |
| Chipzz | technical ppl want to focus on technical things, not a load of administrativae | 08:46 |
| Chipzz | IMO it's a huge barrier to entry | 08:47 |
| Chipzz | also, while I can see the value of having it for ubuntu's partners' sake, that argument doesn't hold for debian. And if I'm not mistaken, debian/copyright was introduced by debian, not ubuntu? | 08:48 |
| dholbach | I must have missed the discussion - was there anything specific to dislike about writing debian/copyright? | 08:48 |
| infinity | dholbach: No, just that people don't like doing it, apparently. :P | 08:51 |
| dholbach | right | 08:51 |
| infinity | Chipzz: I'm not sure the discussion is even worth entering into. We're not going to suddenly drop debian/copyright. | 08:51 |
| debfx | pitti: I think you want to test virtualbox-guest-dkms instead of virtualbox-dkms in ubuntu-drivers-common. | 08:52 |
| dholbach | infinity, let's go shopping :) | 08:52 |
| pitti | debfx: well, I guess we might want both | 08:52 |
| infinity | dholbach: *blink* | 08:52 |
| Chipzz | infinity: well I wasn't saying that ubuntu should do that, just giving my reason for disliking it | 08:52 |
| Chipzz | in my personal opinion, even given the argument about ubuntu's partners, it's a pure waste of time. but that's my 2 cents | 08:53 |
| infinity | Chipzz: Sure, I'm just pointing out that this is one of those cases where having an opinion (and expressing it) won't particularly matter. It's almost up there with "Hey, I noticed an RPM versus dpkg discussion, and I'd like to chime in that I also don't like dpkg, so maybe Ubuntu should switch." | 08:53 |
| seb128 | dholbach, infinity, we should drop debian/copyright, and no, I'm not trolling ;-) | 08:55 |
| infinity | Chipzz: I didn't follow the original discussion, but the partner-auditing thing, while nice, isn't the reason for debian/copyright at all. | 08:55 |
| seb128 | well at least the copyright owners part of it | 08:56 |
| seb128 | having license infos is useful | 08:56 |
| infinity | Chipzz: The reason for it is because it's included in BINARY packages, which we distribute to users without source (and without the original license) attached. | 08:56 |
| debfx | pitti: testing all dkms packages would be good but I'm not sure u-drivers-common is the right place since not all those modules are drivers. | 08:56 |
| Chipzz | infinity: surely that doesn't require you to account for the copyright of every single file in the source package? | 08:57 |
| infinity | seb128: I suspect the license portion is the one people with complex mish-mash packages complain about the most. GNOME folks are lucky in their licensing consistency. ;) | 08:57 |
| seb128 | infinity, well, I can still see the value of that part | 08:57 |
| infinity | Chipzz: It requires you to at least account for the copyright of everything that gets compiled into your binary bits, sure. | 08:57 |
| seb128 | infinity, where the copyright holders just doesn't make any sense | 08:57 |
| infinity | seb128: I suspect an IP lawyer may disagree with you. | 08:58 |
| seb128 | infinity, well then we need to fix our packages and spend time updating those infos, I bet than 90% of packages have a totally useless and outdated copyright holders list | 08:59 |
| infinity | Changing the format of a work (ie: source->binary, or, say, VHS->DVD) doesn't mean you get to drop the copyright notices. | 08:59 |
| Chipzz | infinity: and while I'm aware that my opinion carries very little to no weight, expressing my opinion at least allows me to voice another -1 to the whole thing | 08:59 |
| seb128 | infinity, what we have is worth that what we would get by running a script that grep through the source and build a list on fly | 08:59 |
| infinity | seb128: On, I know they get out of date. That's no excuse for dropping them, it's reasoning for fixing them. | 08:59 |
| seb128 | infinity, it's not a matter of excuse, but we need to stop pretending those infos have any value, when most package made a list 10 years ago when they went through NEW that they never updated since | 09:00 |
| seb128 | infinity, we could as well compute a grepped list, it would be closer from really than the old static outdated one | 09:00 |
| infinity | seb128: And, as Colin mentioned before, if debian/copyright were actually machine-writable, we'd be doing that. | 09:01 |
| Daviey | Yeah, i don't think i have ever updated a debian/copyright post-NEW | 09:01 |
| seb128 | infinity, I was not there when that was discussed so sorry I'm out of context on that discussion ;-) | 09:01 |
| infinity | seb128: If you happen to maintain something with really well-formed and uniform headers in every source file that allow you, specifically, to automagically generate copyright, do so, by all means. | 09:01 |
| infinity | seb128: Not all of us are so lucky. | 09:01 |
| seb128 | infinity, I'm not, but any bad scripting would give a list as good as what the current static copyright files are | 09:02 |
| Daviey | infinity: etherboot maintainers went to great effort to make upstream have a function to output the licence of each file! | 09:02 |
| seb128 | infinity, like having a list of who was copyright owner 10 years ago in version 0.1 of a software that changed 15 time upstreams since and saw 50 contributors is of no use | 09:03 |
| infinity | seb128: I agree entirely. So don't do that. | 09:03 |
| seb128 | infinity, reality is that most of our archive is maintained this way | 09:03 |
| infinity | Maintaining debian/copyright is part of a maintainer's "job". Like staying policy compliant, and other such things. Saying "most people don't do it, so I don't wanna either" doesn't help. | 09:04 |
| seb128 | I guess there is an educational issue there | 09:04 |
| infinity | Yeah, it's a crap part of the job, but hey, we all review upstream diffs anyway, right? I notice when copyright headers get changed. | 09:05 |
| seb128 | nobody ever convinced me of the fact that updating that list is useful | 09:05 |
| seb128 | and it's the most boring job ever | 09:05 |
| infinity | Yeah, it's not fun. Or exciting. | 09:05 |
| seb128 | so I just don't see why I would ever want to spend time on that | 09:05 |
| seb128 | and I guess it's the same for lot of people | 09:05 |
| infinity | I'm sure lots of people could say the same for keeping policy-compliant, or fixing FTBFS bugs introduced by toolchain changes, or, or. | 09:05 |
| cjwatson | I do - not 100% reliably but I do update it | 09:05 |
| cjwatson | I regard it as professionalism | 09:06 |
| infinity | Not everything about software integration is fun to everyone. | 09:06 |
| cjwatson | Exactly | 09:06 |
| seb128 | well, either it's important and we have an issue that most of our maintainer don't do it and we should try to fix that | 09:07 |
| cjwatson | seb128: I really wish you would stop making rubbish unsupported "90%" assertions. | 09:07 |
| seb128 | or it's not important, and why bother people with paper work they don't want to be doing? | 09:07 |
| cjwatson | Lots of people do update these files. You're not 90%, nor is the desktop team. :-) | 09:07 |
| infinity | On a lighter note, as I exit this conversation and head to bed, here's how I feel about "fun": http://25.media.tumblr.com/tumblr_m5sm5tDckY1r2yrpho1_500.jpg | 09:07 |
| cjwatson | I don't have numbers and so I'm not quoting them. Please do us the same courtesy. | 09:07 |
| lifeless | infinity: *that* | 09:08 |
| Chipzz | infinity: good night! | 09:08 |
| seb128 | cjwatson, ok, fair enough, it would be an interesting pool to do amount the ubuntu-dev set | 09:08 |
| seb128 | I would be interested in the result | 09:09 |
| seb128 | cjwatson, and I do believe the number will be way lower in Ubuntu than in Debian if we were going to do a pool in both sets | 09:09 |
| cjwatson | If I had to make intuitive guesses, I would say that the likelihood is more that 90% of packages change so rarely that their debian/copyright files are entirely up to date and have been for years. :-) | 09:09 |
| Chipzz | seb128: 10:45 < Chipzz> the bottom line for me (and I am guessing a lot of other ppl who're opposed to it too) is that I am a technical person, not a librarian or secretary (I hope this doesn't come of as too derogatory) | 09:09 |
| cjwatson | Chipzz: Do you upload packages to Ubuntu | 09:09 |
| cjwatson | ? | 09:09 |
| cjwatson | Or Debian? | 09:09 |
| Chipzz | cjwatson: I don't. but if I ever were too, that woudl discourage me | 09:10 |
| cjwatson | Then I'm sorry but I don't think you're in the relevant subset of people | 09:10 |
| Chipzz | cjwatson: no offence taken | 09:10 |
| seb128 | cjwatson, let's say I don't think I've seen anyone doing copyright updates in the desktop set of Ubuntu in years (I can speak for this set since I watch uploads) | 09:10 |
| tumbleweed | I don't see how one can safely run a linux distribution without carefully evaluating and documenting the license of every package, and that means keeping it up to date | 09:10 |
| Chipzz | cjwatson: I've thought about quite a lot, never got off my ass and did anything about it | 09:10 |
| === fabo_ is now known as fabo | ||
| cjwatson | seb128: I wonder why 'grep 2012 gnome*/copyright' produces non-zero hits then ;-) | 09:11 |
| Chipzz | (which is also why I'm idling here) | 09:11 |
| cjwatson | (in /usr/share/doc/) | 09:11 |
| seb128 | cjwatson, because the pkg-gnome in Debian do it, mbiebl especially | 09:11 |
| Chipzz | cjwatson: I have, however, contributed some patches and fixes in the past | 09:11 |
| seb128 | cjwatson, and we sync regularly | 09:11 |
| cjwatson | seb128: Great, we merge enough from them that that'll make it not too out of date then | 09:11 |
| cjwatson | Most of the non-desktop teams do much less in the way of uploading new upstreams directly, maybe with the exception of stuff like openstack | 09:12 |
| seb128 | cjwatson, for those we merge yes, it doesn't change what I was saying, in our Ubuntu contributor set I don't think I've seen anyone doing an update of the copyright owner in years, so we have likely outdated files in that set ... i.e if that's an issue that needs to be sorted somebody should raise it | 09:13 |
| seb128 | cjwatson, I'm not sure how problematic having those infos outdated is... | 09:13 |
| cjwatson | The BSD licence explicitly requires it | 09:14 |
| cjwatson | I dunno, I kind of feel that managing to violate the BSD licence is a sign you're doing it wrong | 09:14 |
| Chipzz | cjwatson: tbh the only thing that I have ever seen producing a licence is dhcpcd | 09:14 |
| cjwatson | Displaying a licence interactively or whatever is a different matter | 09:15 |
| cjwatson | (Obviously the BSD licence doesn't explicitly require debian/copyright, but it does require preserving copyright notices in binary distributions, and we don't normally include copyright notices anywhere other than the copyright file) | 09:16 |
| seb128 | cjwatson, I'm wondering how i.e fedora is dealing with that, they don't have any copyright info in their spec files | 09:17 |
| cjwatson | Then maybe they're violating the BSD licence | 09:17 |
| cjwatson | Or maybe they just ship extra docs in rpms or something | 09:17 |
| directhex | they probably aren't dealing with it | 09:17 |
| seb128 | cjwatson, just being curious at this point if somebody has a way to semi-automatically generate them which could save us the manual work ;-) | 09:17 |
| Chipzz | I suspect a lot of distro's are | 09:17 |
| cjwatson | I don't care much about rpm packaging so I've never looked | 09:17 |
| Laney | ask directhex about copyright auditing new packages | 09:18 |
| cjwatson | seb128: There are certainly tools that have tried to do this kind of thing for licences (e.g. licensecheck, fossology); I've never looked at whether they do it for copyright notices too | 09:18 |
| * Laney sniggers | 09:18 | |
| cjwatson | I generally feel it's easier to do it by hand than to add in some wobbly stack of auditing stuff | 09:18 |
| directhex | my experience is that only debian cares about actually following the license requirements for things | 09:19 |
| directhex | experiences with fedora and suse folks suggests they don't really bother | 09:19 |
| * tumbleweed would find a tool that compared licencecheck output with a DEP-5 coprygiht file handy | 09:19 | |
| * tumbleweed should write one | 09:19 | |
| seb128 | cjwatson, well, doing it by hand once is fine, having the discipline to keep doing those check every time you update a package to a new version start being boring work after a while | 09:19 |
| directhex | Laney, i wonder if the java packagers ever lifted my openjdk dep5, from src:ikvm | 09:20 |
| cjwatson | seb128: Sure, I don't argue that it isn't boring | 09:20 |
| cjwatson | Many things are | 09:20 |
| Laney | tumbleweed: /usr/lib/cdbs/licensecheck2dep5 | diff? ;-) | 09:20 |
| seb128 | cjwatson, well, every step which is not fun is something that could discourage contributors to join or stay so the less annoying work we have the better... | 09:21 |
| cjwatson | Sure, but the answer isn't "hey, let's violate licences" | 09:21 |
| cjwatson | "that'll be more fun" | 09:21 |
| cjwatson | I'm all for automation | 09:21 |
| Chipzz | cjwatson: I don't think anyone is getting any fun out violating licenses :P | 09:22 |
| cjwatson | Chipzz: Then stop arguing that we should. | 09:22 |
| seb128 | cjwatson, how bad would be a "grep -i copyright * -r > COPYRIGHT" done during the build? | 09:22 |
| cjwatson | seb128: It's not unheard of | 09:22 |
| cjwatson | You might want to be a *little* more selective | 09:23 |
| pitti | changing debian/copyright during build is certainly wrong | 09:23 |
| cjwatson | Some way to get that into DEP-5 form would be good eventually, since there is some pressure to do that across the board eventually for mechanical analysis | 09:23 |
| pitti | it coudl be a debian/rules update-copyright rule | 09:23 |
| cjwatson | pitti: binary copyright files don't have to be identical to debian/copyright | 09:23 |
| seb128 | pitti, well, the license doesn't see that the copyright owner list needs to be in debian/copyright | 09:23 |
| seb128 | see->say | 09:23 |
| cjwatson | The requirements are different - debian/copyright is shipped with the source package which already includes whatever copyright notices are present in the source package | 09:23 |
| pitti | cjwatson: right, but it seems a lot less error prone to do it when updating the package and inspecting the result before committing it | 09:23 |
| cjwatson | Binary copyright files are shipped with the binary package which generally doesn't | 09:24 |
| cjwatson | I've certainly had cases where I generated the latter automatically | 09:24 |
| pitti | right, no arguing about that; but it still seems more robust to do it at package update time | 09:24 |
| cjwatson | It's workable too, yes | 09:24 |
| infinity | SpamapS: Oh, while it's fresh in my mind, before I go to sleep and forget about it. Your fixes for #986892 probably should be coordinated with the security team and targetted at -security, not -proposed. | 09:31 |
| infinity | SpamapS: Because, otherwise, any security updates of MySQL (or other affected packages) won't build with the new apparmor/debhelper, and will suffer the same issue. | 09:32 |
| TheMuso | Is anybody able to tell me with any certenty whether we are likely to only have python 3 on the desktop image for 12.10? The stuff I care about, orca, at-spi, speech-dispatcher is done, with liblouis and brltty still be done... Orca upstrea are enquiring since python 3 is not a GNOME goal this cycle. | 09:33 |
| infinity | TheMuso: That's the plan, and we've made good progress. | 09:33 |
| TheMuso | SO it comes down to how much extra work is required, and if the target is unlikely to be met, whether its worth pursuing as hard. | 09:34 |
| TheMuso | infinity: Ok I'll take that as a yes at this point then. | 09:34 |
| cjwatson | It's still challenging, but it's still the plan. | 09:35 |
| cjwatson | I think we have a decent chance of making it. | 09:35 |
| TheMuso | Ok thanks. | 09:35 |
| pitti | TheMuso: didn't they say they would keep master at py3, and the 3.6 branch at py2? It should not be too hard to actually keep identical code there | 09:35 |
| TheMuso | pitti: Yes, but joanie just wants a status update as to whether we are really still pushing this forward. | 09:36 |
| pitti | "self-fulfilling prophecy" :) | 09:36 |
| cjwatson | TheMuso: OK, and the simple answer there is yes. | 09:39 |
| TheMuso | cjwatson: Figured as much, thanks. | 09:40 |
| mvo | cjwatson: I generate the upload now, its going to take a little bit as its quite a bit of data | 09:42 |
| cjwatson | mvo: Right, thanks. Let me know when you've done it as dogfood doesn't process uploads automatically | 09:47 |
| mvo | cjwatson: 20/200mb uploaded so far, I let you know when its done | 09:49 |
| mvo | cjwatson: I should probably have just generate the upload for main instead of the combined one | 09:50 |
| mvo | oh well | 09:50 |
| cjwatson | Won't hurt to test the lot | 09:50 |
| * mvo nods | 09:50 | |
| cjwatson | IIRC no other package includes multiple custom uploads | 09:50 |
| cjwatson | Ought to work but good to check | 09:50 |
| mvo | cjwatson: it will be perfect on the first upload anyway ;) | 09:50 |
| mvo | cjwatson: yeah, I think you are right, its the only one and previously I just did the uploads individually too not combined | 09:51 |
| cjwatson | Right - if you hadn't, they'd have been rejected | 09:51 |
| cjwatson | The loophole that allows binary-only custom uploads only works for a single custom file | 09:52 |
| cjwatson | (AFAICS) | 09:52 |
| mvo | oh, interessting | 09:52 |
| cjwatson | This is a bit of Soyuz I never knew was there | 09:53 |
| cjwatson | Even having objective evidence that it worked it took me a while to find it | 09:53 |
| cjwatson | (NascentUpload:process, the "Single Custom Upload detected" bit) | 09:54 |
| * mvo nods | 09:54 | |
| cjwatson | I'd like to delete that once this new approach works, since I do think it's a dodgy loophole | 09:54 |
| mvo | I haven't had any interaction with this part since the custom upload for the ddtp stuff was added in ~2005 | 09:54 |
| cjwatson | Yeah, bzr blame for it went way back | 09:55 |
| cjwatson | Typical for Soyuz code of that vintage in that it was all mushed together with other work | 09:55 |
| * cjwatson wonders how many tests will fail if I nuke that | 09:56 | |
| xnox | seb128: cjwatson: infinity: Chipzz: Fedora/OpenSUSE are very explicit on copyright and licenses. All spec files are copyright assigned. All spec files have License Tags (not necessary full copyright headers / per file). And in some ways I find OpenSUSE/Fedora archives to be more restrictive e.g. aircrack is banned. As pointed out by tumbleweed and Laney `licensecheck` tool does generate automated output and there is also /usr/lib/cdbs/licensechec | 09:57 |
| xnox | k2dep5 . I don't see DFSG or the http://www.ubuntu.com/project/about-ubuntu/licensing changing any time soon | 09:57 |
| seb128 | xnox, the question was rather "is fedora providing the list of copyright owners of the source with their rpms, and how do they build that list" | 09:58 |
| seb128 | xnox, I don't see any manual listing done in their specs | 09:58 |
| tumbleweed | licensecheck isn't very accurate, but still useful | 09:58 |
| seb128 | xnox, like we do in debian/copyright | 09:59 |
| xnox | seb128: for fedora it's easier since RedHat owns the copyright for most things. And no they do not list copyright owners of the source with the rpms, last time I did RPM packaging (~2009 or something) | 10:00 |
| seb128 | xnox, ok, thanks for the infos ;-) | 10:00 |
| xnox | np | 10:01 |
| cjwatson | Fedora are more likely to ship upstream COPYING files and such than we are, though - Debian has a tradition of excluding things like COPYING because debian/copyright covers it | 10:05 |
| cjwatson | e.g. http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/releases/17/Fedora/i386/os/Packages/m/man-db-2.6.0.2-6.fc17.i686.rpm%5Bpeek%5D and compare with /usr/share/doc/man-db/ | 10:05 |
| cjwatson | Of course that doesn't help if upstream copyright notices are only in source files and not in upstream documentation | 10:06 |
| xnox | seb128: I have been twice in legalish action due to copyrights: once it was settle outside the court, the other time my hosting got terminate due to receiving immediate notice for take down | 10:06 |
| xnox | due to Ubuntu & Debian growing popularity, I can see how we are becoming more of a target for such actions from minor to large scale. | 10:07 |
| xnox | cjwatson: true, generally fedora/suse install all docs of COPYING, LICENSE etc | 10:08 |
| seb128 | xnox, right, I guess the real way forward there is to make it easier to have those infos uptodate than to rely on people to do tedious manual work | 10:10 |
| tumbleweed | that's pretty dependant on upstreams to give it to us in a useful form | 10:10 |
| xnox | seb128: I'm sure /usr/lib/cdbs/licesecheck2dep5 is right up GNOME package-set street ;-) | 10:11 |
| === enrico_ is now known as enrico | ||
| seb128 | xnox, it might well be ;-) | 10:11 |
| seb128 | tumbleweed, grep -i copyright in the source get you a long way I think ;-) | 10:11 |
| xnox | I do find that $VCS log/blame is 1000 times better than tarball drops | 10:11 |
| xnox | back in the day it was more pain! | 10:12 |
| tumbleweed | seb128: right, but still requires manual review | 10:12 |
| tumbleweed | what about all the license lines below Copyright ... | 10:12 |
| seb128 | tumbleweed, well, having something to review is better than having something to build manually from scratch | 10:12 |
| * tumbleweed just looks for copyright when reviewing new upstraem diffs | 10:12 | |
| tumbleweed | unfortunately, most upstreams care about this less than we do. so we end up doing the legwork | 10:13 |
| mvo | cjwatson: ddtp-translation uploaded | 10:21 |
| === MacSlow is now known as MacSlow|lunch | ||
| cjwatson | mvo: thanks, https://dogfood.launchpad.net/ubuntu/+source/ddtp-translations - should build any year now, dogfood being what it is | 11:14 |
| dholbach | Riddell, hey - any objections to https://code.launchpad.net/~logan/ubuntu/quantal/cagibi/new-upstream/+merge/111411? it looked alright to me AFAICS | 11:30 |
| dholbach | Riddell, also I just ran into https://code.launchpad.net/~scarneiro/ubuntu/quantal/adept/fix-invalid-brace.expansions/+merge/111331 and saw that adept was removed from Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673085) - should it be removed from Ubuntu as well? | 11:35 |
| ubottu | Debian bug 673085 in ftp.debian.org "RM: adept -- RoQA; RC buggy, unmaintained, low popcon" [Normal,Open] | 11:35 |
| dholbach | ScottK, ^ maybe you know something about the two questions above too | 11:36 |
| cjwatson | We mirror removals across eventually, although that tends not to happen so much if the package is modified in Ubuntu | 11:36 |
| cjwatson | Though that's not the case here | 11:37 |
| cjwatson | Ah, but it has reverse-depends | 11:37 |
| cjwatson | Admittedly just a recommends from mythtv-database and a depends from ichthux-desktop (which is forever out of date) | 11:38 |
| dholbach | ok, I'll send an email to ubuntu-devel and CC the relevant people | 11:40 |
| Riddell | dholbach: looking | 11:43 |
| dholbach | thanks Riddell | 11:45 |
| xnox | cjwatson: ichthux-desktop is dead, i'd remove it | 11:45 |
| seb128 | directhex, Laney: is there any way somebody could try to get the banshee SRU bugs verified? | 11:46 |
| Riddell | dholbach: yep cagibi is good | 11:46 |
| * xnox speaking as a provider with the core packages for ichthux-desktop, cjwatson | 11:46 | |
| dholbach | Riddell, ok, will upload - thanks | 11:46 |
| cjwatson | xnox: If you can speak authoritatively for it, perhaps you could file a removal request bug (against the package, subscribe ubuntu-archive) | 11:46 |
| cjwatson | Then we have an audit trail | 11:46 |
| Riddell | dholbach: yes indeed adept can go | 11:47 |
| xnox | cjwatson: ok. I will CC' a couple of people from sword-devel who may be still in touch with them | 11:47 |
| Riddell | (as far as kubuntu is concerned) | 11:47 |
| dholbach | right-o | 11:47 |
| cjwatson | mvo_: https://dogfood.launchpadlibrarian.net/103960082/buildlog_ubuntu-quantal-i386.ddtp-translations_20120626.1_BUILDING.txt.gz looks OK | 11:48 |
| dholbach | I hate it when I get spam related to holidays - I always think I just won a trip to a far-flung island - what a disappointment | 11:49 |
| Daviey | dholbach: mythtv is happy to drop it. | 11:50 |
| seb128 | dholbach, island trips are just overrated ;-) | 11:50 |
| seb128 | dholbach, you are happier around with us | 11:50 |
| dholbach | seb128, I'm happy for you to stay in rainy miserable France :-P | 11:50 |
| iulian | dholbach: Heh. | 11:50 |
| dholbach | Daviey, do you think you could do an upload to remove the reference to it? | 11:51 |
| dholbach | then it's just ichthux left | 11:51 |
| mvo_ | cjwatson: great, so time for a real upload? | 11:51 |
| seb128 | dholbach, heh, it's not raining today (yet)! ;-) | 11:51 |
| cjwatson | mvo_: Well, let's check that it publishes first | 11:52 |
| Daviey | dholbach: i'm doing that :) | 11:52 |
| dholbach | Daviey, awesome | 11:52 |
| * mvo_ nods | 11:54 | |
| xnox | dholbach: i'm working on removing ichthux form the archive ;-) | 11:58 |
| cjwatson | mvo_: So yeah, that works fine on dogfood | 12:13 |
| cjwatson | mvo_: Can you upload that to real quantal and start using it for all stable updates from here on, and I'll close the loophole you were using? | 12:13 |
| mvo_ | cjwatson: sure, uploading now | 12:15 |
| cjwatson | Yay | 12:16 |
| === MacSlow|lunch is now known as MacSlow | ||
| cjwatson | Now I will understand how translated package descriptions work | 12:16 |
| caribou | I have a begineer's question about proposing a merge to an Ubuntu package : kexec-tools | 12:17 |
| Laney | seb128: don't know. hyperair, can you do it or do you know who can? | 12:17 |
| caribou | should I propose the merge on lp:ubuntu/kexec-tools or to the version specific lp:ubuntu/precise/kexec-tools ? | 12:18 |
| === zyga is now known as zyga-afk | ||
| xnox | caribou: for next development release propose to lp:ubuntu/$package | 12:19 |
| hyperair | Laney: do what? | 12:19 |
| xnox | caribou: for SRU fixes to the individual release lp:ubuntu/$series/package | 12:20 |
| caribou | xnox: but if it is to fix a but in the current release ? | 12:20 |
| xnox | caribou: current release in development is quantal. and bugs should be fixed there first. | 12:20 |
| caribou | xnox: fine, that's what I understood. Then get the fix SRUEd to Precise | 12:20 |
| xnox | caribou: yes, following the http://wiki.ubuntu.com/StableReleaseUpdates | 12:21 |
| xnox | caribou: note the handy bug template for the SRU request | 12:21 |
| caribou | xnox: yes, I've done that already. Still waiting for it to be done in Lucid after a few months... | 12:22 |
| caribou | maybe I should talk to someone | 12:22 |
| xnox | caribou: about?! | 12:23 |
| xnox | caribou: what bug are you trying to fix? | 12:23 |
| caribou | the other SRU was about a vm-builder fix that is in Precise and wanted in Lucid | 12:24 |
| xnox | caribou: do you have a bug number for that one? | 12:24 |
| caribou | xnox: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/531599 | 12:25 |
| ubottu | Launchpad bug 531599 in vm-builder (Ubuntu Lucid) "device mappings for partitions not removed after build using --raw, leading to filesystem corruption" [Undecided,Fix committed] | 12:25 |
| Laney | hyperair: verify the banshee sru(s) | 12:25 |
| hyperair | banshee has an sru? | 12:25 |
| hyperair | i thought raof acked that already because banshee's got the microrelease exception | 12:25 |
| Laney | ?!?!?!?!?!?! https://launchpad.net/ubuntu/+source/banshee/2.4.1-3ubuntu1~precise1 | 12:25 |
| Laney | do you still have to verify it? | 12:26 |
| hyperair | no? | 12:26 |
| seb128 | you for sure have if you want it moved to -updates and not kicked out | 12:26 |
| cjwatson | MREs still require verification | 12:26 |
| Laney | not sure how it works with the MRE | 12:26 |
| cjwatson | it's on the wiki page for MREs | 12:26 |
| seb128 | the MRE just makes it a valid candidate for a SRU | 12:26 |
| seb128 | it doesn't mean you don't have to follow SRU rules ;-) | 12:26 |
| cjwatson | https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions | 12:27 |
| cjwatson | It's a relaxation, not a free pass | 12:27 |
| hyperair | ah | 12:27 |
| hyperair | i see. | 12:27 |
| hyperair | hmmmm | 12:28 |
| hyperair | so which bug would constitute as the headline bug? | 12:28 |
| Laney | it's had several SRUs; I'm surprised this is surprising :P | 12:28 |
| seb128 | you need to verify all the bugs listed on http://people.canonical.com/~ubuntu-archive/pending-sru.html | 12:28 |
| seb128 | the 3 of them | 12:28 |
| seb128 | it will not move to update until they are all verified | 12:29 |
| hyperair | Laney: it's surprising because it was accepted without me doing anything the last time. | 12:29 |
| seb128 | it's likely the qa team or somebody verified the bugs for you last time | 12:29 |
| === _salem is now known as salem_ | ||
| seb128 | that doesn't seem to happen this time though | 12:29 |
| seb128 | it's there for 2 weeks and none is flagged verified | 12:29 |
| hyperair | right | 12:32 |
| hyperair | the microrelease exception page says something about how bugs are considered to be fixed if their upstream bugs are fixed | 12:33 |
| hyperair | can i assume so? | 12:33 |
| pitti | there still needs to be some regression testing on the actual .debs | 12:33 |
| pitti | upstream testing is required, but not sufficient for MREs | 12:34 |
| pitti | there is build dependencies, tool chains, packaging helpers, and the packaging itself which can go wrong | 12:34 |
| hyperair | okay. | 12:35 |
| alkisg | There's probably a design issue about keyboard layout handling in accountsservice and lightdm, they assume that the "primary keyboard layout" is just one layout, while e.g. Greek requires both "us,gr" (and also the ability to switch between them with alt+shift). | 12:40 |
| alkisg | I filed LP bug #1016409 about it and commented on LP bug #919200 (which is supposedly fixed, but not for Greek) - is there anything more I could do to help in solving the issue? | 12:40 |
| ubottu | Launchpad bug 1016409 in lightdm (Ubuntu) "Default XKBLAYOUT is not used, so new users only have "en" layout" [Undecided,New] https://launchpad.net/bugs/1016409 | 12:40 |
| ubottu | Launchpad bug 919200 in lightdm (Ubuntu) "Doesn't know system default layout/variant" [High,Fix released] https://launchpad.net/bugs/919200 | 12:40 |
| === vibhav_ is now known as vibhav | ||
| seb128 | alkisg, hey, out of sending a patch I'm not sure, it will require somebody who has time to look at it | 12:42 |
| alkisg | seb128: as it needs redesigning and changing their API, I'm not sure I could send a proper patch without first talking about it with some of the devs there :-/ | 12:42 |
| seb128 | alkisg, try talking to mterry when he gets online | 12:42 |
| alkisg | Thank you seb128 | 12:43 |
| seb128 | alkisg, he should be online soon | 12:43 |
| seb128 | yw | 12:43 |
| alkisg | OK, I'll be online for hours, np | 12:43 |
| === zyga-afk is now known as zyga | ||
| mvo_ | cjwatson: its in the real archive now, lets see how that goes | 12:53 |
| cjwatson | Thanks, I'll look at it in NEW in a bt | 12:55 |
| cjwatson | *bit | 12:55 |
| ScottK | dholbach: Kill it. | 12:56 |
| === zyga is now known as zyga-food | ||
| === slomo_ is now known as slomo | ||
| cyphermox_ | @pilot in | 13:13 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox_ | ||
| === zyga-food is now known as zyga | ||
| mio | Hi, when using subprocess.call to open a txt file in Linux, I am getting permission denied error. I don't want to use sudo in code, any other way? | 13:26 |
| === yofel_ is now known as yofel | ||
| cjwatson | mio: it's unlikely to have anything to do with sudo; subprocess.call opens executables, not documents | 13:32 |
| cjwatson | mio: Perhaps try subprocess.call(["xdg-open", "whatever.txt"]) | 13:33 |
| mio | right thanks, xdg-open worked :) | 13:34 |
| === tsimpson_ is now known as tsimpson | ||
| jibel | pitti, I published latest rev of auto package testing and refreshed the base vm. ubuntu-drivers-common is running with multiverse enabled. | 13:51 |
| pitti | jibel: merci beaucoup | 13:51 |
| xnox | dholbach: ichthux upsteam and all users contacted (exactly 3 people). Nobody is aware that it (a) exists (b) used by anyone | 13:55 |
| xnox | sent emails to devel mailing lists and stuff | 13:55 |
| xnox | so after a grace period ~ 1 week we can remove it from the archive | 13:55 |
| dholbach | xnox, so shall we for now just remove it from the depends and let the ichthux team deal with any other necessary cleanup? | 13:55 |
| xnox | dholbach: well, yeah I can do that now to unblock. But yeah the whole ichthux is going so there is no harm in leaving it in un-installable state | 13:56 |
| xnox | dholbach: there was literarly no activity since 2009 on that 'respin' | 13:57 |
| dholbach | ok, I'm happy either way | 13:57 |
| dholbach | Michael Hall is giving a session at Ubuntu App Developer Week at 16:00 UTC (#ubuntu-classroom) to cover some (non-Quickly) packaging tools - would anyone be available to be around and help out with some questions which might come in? | 13:58 |
| smoser | anyone running quantal want to try to crash their browser? https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1017761 | 13:58 |
| ubottu | Launchpad bug 1017761 in firefox (Ubuntu) "firefox page load makes X consume all cpu, firefox OOMS" [Undecided,New] | 13:58 |
| smoser | i'd like to see if that is "just me" | 13:58 |
| === manjo` is now known as manjo | ||
| xnox | I googled for "germinate seeds" and the youtube results were utterly unhelpful for changing ubuntu seeds! | 14:00 |
| dholbach | jelmer, are you OK with https://code.launchpad.net/~logan/ubuntu/quantal/bzr-builder/0.7.3/+merge/109506 going into quantal? | 14:01 |
| Daviey | xnox: I assume you have read https://wiki.ubuntu.com/SeedManagement ? | 14:01 |
| xnox | Daviey: yeah, yeah I did =) I just wanted the bzr branch =) as I don't have it checkout handy | 14:01 |
| jibel | smoser, it works here with FF 14.0~b9+build1-0ubuntu1 | 14:02 |
| jelmer | dholbach: hi Daniel, let me have a look | 14:02 |
| dholbach | jelmer, it looked OK to me - I just wanted to make sure you didn't have any other plans | 14:02 |
| jelmer | dholbach: it seems okay to me too | 14:03 |
| dholbach | great | 14:03 |
| jelmer | dholbach: thanks for sponsoring that upload :) | 14:03 |
| dholbach | de nada :) | 14:04 |
| smoser | jibel, thanks. i wonder which of my addons is making it go crazy | 14:05 |
| dholbach | @pilot out | 14:06 |
| * dholbach hugs cyphermox_ | 14:09 | |
| cyphermox_ | dholbach: hey | 14:10 |
| dholbach | :) | 14:10 |
| cyphermox_ | re: handoff ;) | 14:10 |
| cyphermox_ | https://code.launchpad.net/~cr3/ubuntu/quantal/checkbox/0.14/+merge/111701; set to Merged? | 14:10 |
| cr3_ | dholbach: thanks for merging checkbox, all converted to python3! | 14:11 |
| cyphermox_ | cr3 was confused by bugs being closed but the branch not merged; I told him about the importer ;) | 14:11 |
| cr3_ | barry: ^^^ | 14:11 |
| * cr3_ is easily confused | 14:11 | |
| dholbach | cr3_, yeah, it looks like quite a bit of work :) | 14:11 |
| cyphermox_ | bah | 14:11 |
| cr3_ | dholbach: yeah, hardware testing needs to read a lot of byte information which is now a big deal with python :) | 14:12 |
| barry | cr3_: looking for a review? | 14:14 |
| cr3_ | barry: nope, just letting you know that checkbox was converted to python3. one more package to cross off your list :) | 14:14 |
| barry | cr3_: has the new version been merged/uploaded? | 14:15 |
| cr3_ | barry: yep, thanks to dholbach | 14:15 |
| barry | cr3_, dholbach: you guys *rock*. thanks! | 14:15 |
| cr3_ | barry: I believe there's still a dependency on python-apport and python-apt, not sure why though | 14:15 |
| barry | cr3_: both of those are already ported, i.e. python3-{apt,apport} | 14:16 |
| * barry loves seeing rows go green | 14:17 | |
| cr3_ | barry: might there be a ppa with python3-apport for precise? | 14:17 |
| barry | cr3_: ah, for precise. not that i know of :( | 14:18 |
| barry | cr3_: it might make sense to try to create one though. i don't want to spend a ton of time working on backports, but let me see if it's easy | 14:18 |
| cjwatson | IMO you can't realistically do Python 3-directed development against precise. Make your code bilingual so that you can keep it working with Python 2 in precise and Python 3 in quantal. | 14:18 |
| cjwatson | (I mean you can in some cases, but when you run into missing ports the right answer is to switch to quantal rather than spending lots of time backporting stuff) | 14:19 |
| barry | cjwatson: your py3 command-not-found branch is merged right? but looks like it wasn't uploaded yet. do you know what the status is of that? | 14:20 |
| smoser | jibel, thanks for testing. i just tested and i die an immediate, horrible death. | 14:21 |
| stark | Hi, I am writing my first Ubuntu app and these two bugs are getting in my way --> Bug #390508, Bug #663726 Please please fix them I want to submit app to showdown | 14:23 |
| ubottu | Launchpad bug 390508 in notify-osd (Ubuntu) "notifyOSD ignores the expire timeout parameter" [Wishlist,Confirmed] https://launchpad.net/bugs/390508 | 14:23 |
| ubottu | Launchpad bug 663726 in notify-python (Ubuntu) "pynotify.set_timeout() ignores timeout" [Undecided,Confirmed] https://launchpad.net/bugs/663726 | 14:23 |
| cjwatson | barry: Yes - I thought mvo said he was going to upload it | 14:23 |
| jibel | smoser, does it crash in safe-mode ? | 14:24 |
| cjwatson | mvo_: ^- | 14:24 |
| stark | is there any workaround to override default timeout in notify-send? | 14:25 |
| seb128 | stark, no, and it's not a bug | 14:25 |
| seb128 | stark, notifications have been designed to be consistent | 14:26 |
| cr3_ | barry: might you happen to know how to tell setup() to install some files under /usr/lib*? I have some compiled scripts currently installed under /usr/share, using setup(data=...), whereas those scripts should actually be under /usr/lib* | 14:26 |
| mvo_ | barry: feel free to upload, I had hoped that we can get a updated command-not-found-data package too, but that seems to be a problem as the replacement of rooerky is not fully ready yet, i.e. I don't have a ~mvo there yet to store the results, so the current automation will not work | 14:26 |
| smoser | jibel, seems not to. | 14:27 |
| xnox | cjwatson: do you have a stash of bzr branch ichthux seed from the updates you have been doing? or can I somehow rerun it from the tarball | 14:27 |
| barry | mvo_: okay. obviously i can't upload to debian yet, but will do ubuntu asap | 14:27 |
| cjwatson | xnox: No, that isn't one of the centrally managed seeds | 14:28 |
| xnox | cjwatson: well the old branch still works for checkout but it doesn't have your changes, ok. Am I ok to just sed through the changes? =/ | 14:28 |
| barry | cr3_: well, it's probably not correct to do that in setup.py because that's not cross-platform. (the new py3.3 packaging will allow us to do stuff like this, but that doesn't help you now, and some of that may actually not land in 3.3) | 14:29 |
| cjwatson | xnox: Uh, that's not possible | 14:29 |
| stark | seb128: I am writing a desktop recorder and I want a notification that displays user specified delay in seconds before the recording starts. The default timeout is around 5-6 seconds and if user specifies 0 seconds, the notification will be still displayed for 6 seconds :( And it will get recorded in video | 14:29 |
| xnox | cjwatson: ok. sorry. | 14:29 |
| cjwatson | xnox: I didn't make any seed changes; all I did was rebuild against the current archive | 14:29 |
| cjwatson | Using https://code.launchpad.net/~ichthux-dev/ichthux-seeds/ichthux.lucid | 14:29 |
| cjwatson | Though it's clearly broken that there are no newer seeds - that was a hack | 14:29 |
| xnox | hmm... ok. but they explicetely add adept which is going | 14:29 |
| xnox | away. | 14:30 |
| cjwatson | Ideally, get somebody to branch the seeds for quantal and then remove it | 14:30 |
| cr3_ | barry: hm, so should I have a Makefile that would call setup.py, and then have debian/rules use that Makefile? | 14:30 |
| seb128 | stark, check with mpt (he's a designer and worked on notify-osd) but I guess you should probably have that count somewhere in your software ui and not use the system notifications then | 14:30 |
| cjwatson | Failing that, you could edit the output files manually before upload, as long as we remove the package shortly after that | 14:31 |
| barry | cr3_: hang on. lots of conversations going on at once ;) | 14:31 |
| cr3_ | barry: no worries :) | 14:32 |
| mpt | stark, org.freedesktop.notifications is not a good way of doing a countdown -- not least because you can't update it each second. I suggest doing a custom overlay for that. The Kazam developers are working on something similar, so maybe you could share code. | 14:32 |
| === cr3_ is now known as cr3 | ||
| stark | mpt: Not doing a countdown, just alerting the user. Anyway will check out Kazam, thanks | 14:36 |
| === cyphermox_ is now known as cyphermox | ||
| dholbach | SpamapS, do you know who could have a look at https://code.launchpad.net/~n-muench/ubuntu/quantal/open-vm-tools/open-vm-tools.may-merge.final2/+merge/111497 and https://code.launchpad.net/~n-muench/ubuntu/quantal/open-vm-tools/open-vm-tools.may-merge.final/+merge/111310? | 15:16 |
| tumbleweed | dholbach: whoops, that should have been on my todo list | 15:21 |
| * tumbleweed reviewed the first couple of rounds | 15:21 | |
| dholbach | tumbleweed, cool | 15:22 |
| bdmurray | pitti: I forget during Precise was there an issue with the mapping between binary and source packages in apport? | 15:24 |
| pitti | bdmurray: bug 993810 ? | 15:37 |
| ubottu | Launchpad bug 993810 in apport (Ubuntu Precise) "apport-collect broken (with source pkg name != binary pkg name?)" [Undecided,Fix committed] https://launchpad.net/bugs/993810 | 15:37 |
| SpamapS | dholbach: looking | 15:38 |
| dholbach | SpamapS, it seems like tumbleweed also wanted to have a look | 15:38 |
| SpamapS | ahh | 15:38 |
| dholbach | whoever gets to it first :) | 15:38 |
| * SpamapS defers looking for a few minutes | 15:38 | |
| tumbleweed | won't be me right now | 15:38 |
| dholbach | SpamapS, tumbleweed: I received https://twitter.com/NMinker/status/216957211002404865 | 15:39 |
| SpamapS | infinity: also re apparmor fixes in proposed.. I am wondering, should we do no-change rebuilds on all of apparmor's reverse-build-deps so that all of the postrm's are correct, just in case the apparmor profiles change hands sometime between 12.04 and 14.04? | 15:40 |
| tumbleweed | dholbach: hrm, last I saw of it was https://code.launchpad.net/~n-muench/ubuntu/quantal/open-vm-tools/open-vm-tools.may-merge3b/+merge/109264 and that appears to have been deleted | 15:41 |
| tumbleweed | I commented on it saying "offline for a week, someone else review, please" | 15:41 |
| SpamapS | dholbach: I'm not sure what the problem is. We're behind in sponsoring, definitely, but I don't understand at all what it is we can do differently | 15:42 |
| tumbleweed | he does seem to like creating new branches after each review comment... | 15:43 |
| dholbach | SpamapS, don't take it personally - I can understand the submitter though: if I have to wait days or weeks for some feedback for work I did, it's obviously not ideal | 15:43 |
| dholbach | but we need more hands on deck in terms of sponsoring | 15:43 |
| dholbach | today I did my piloting shift and I easily ticked off ~20 sponsoring items which were trivial and anybody could have taken care of them beforehand | 15:44 |
| bdmurray | pitti: no, I was wondering about the +filebug link creation | 15:44 |
| tumbleweed | his creating a new branch every time he fixes something will keep him fairly far down the lits | 15:44 |
| dholbach | tumbleweed, it might also be a misunderstanding | 15:45 |
| dholbach | but yeah, it might have a "*bump* anyone out there?" effect as well :) | 15:45 |
| dholbach | ...depending on where you start looking in the queue | 15:45 |
| SpamapS | What I'm confused about is that I *think* he has gotten the package in sync.. or at least, one of the messages claims as much | 15:46 |
| * SpamapS debdiffs w/ debian version | 15:46 | |
| tumbleweed | I think he's having a fairly hard time with preparing a merge proposal in bzr | 15:47 |
| tumbleweed | the second attempt had the inter-ubuntu-version delta described in the changelog. I had to point out each debian-ubuntu delta to get it mentioned | 15:47 |
| * tumbleweed is glad to see a 3rd-party application at the top of https://errors.ubuntu.com/ :) | 15:50 | |
| pitti | bdmurray: hm, I'm not aware of a bug there | 15:53 |
| * Laney eyes 1:0.156.14.5+elementary2~precise1+elementary2~precise1+elementary2~precise1 | 15:53 | |
| hyperair | whoa. | 15:54 |
| hyperair | that sounds like a runaway script | 15:54 |
| Laney | makes me want to runaway :-) | 15:54 |
| bdmurray | pitti: okay, thanks | 15:54 |
| micahg | dholbach: you sponsored some stuff that shouldn't have been during alpha 2 freeze :) | 16:04 |
| dholbach | ugh, I hope I didn't break anything :) | 16:05 |
| micahg | infinity: SpamapS: re mysql fixes, anything in -updates would be included in the next security update | 16:09 |
| micahg | infinity: SpamapS: it should only go to -security now if it's a regression in a previous security update | 16:10 |
| SpamapS | micahg: I think infinity was commenting on the fact that we need to make sure my apparmor fix lands in -updates before your next mysql security update. | 16:15 |
| SpamapS | but I could be wrong | 16:15 |
| micahg | ok | 16:16 |
| xnox | psusi: why did you set bug 1012946 'in progress'? are you working on resolving it / providing an updated patch? | 16:21 |
| ubottu | Launchpad bug 1012946 in parted (Ubuntu Quantal) "dm-part-sync.patch breaks creating multiple partitions on a LVM volume" [High,In progress] https://launchpad.net/bugs/1012946 | 16:21 |
| === deryck is now known as deryck[lunch] | ||
| === jamespage is now known as hazmat_mk2 | ||
| === hazmat_mk2 is now known as jamespage | ||
| dupondje | eclipse is uninstallable ? :s | 16:26 |
| === ChanServ changed the topic of #ubuntu-devel to: Quantal A2 prep | Archive: please use -proposed | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox_ | ||
| === badfox is now known as raju | ||
| infinity | SpamapS, micahg: No, I was referring to the fact that fixing debhelper/apparmor in -updates does no good if you then do a MySQL security update. | 16:32 |
| infinity | SpamapS, micahg: Since -security doesn't build against -updates, and you're relying on your build-deps to make MySQL happy. | 16:32 |
| SpamapS | infinity: oh! | 16:33 |
| SpamapS | I didn't not know that the builds were not done w/ updates | 16:34 |
| SpamapS | ok, so yeah we need to copy that to security, right? | 16:34 |
| infinity | SpamapS: Yes, but you need security sign-off before we do, we don't just copy SRUs to security willy-nilly. | 16:34 |
| SpamapS | I figured as much | 16:35 |
| === beuno_ is now known as beuno | ||
| dupondje | meh, eclipse is ftbfs :( | 17:06 |
| psusi | xnox: branches linked and merge requested already | 17:07 |
| xnox | psusi: awesome! | 17:08 |
| xnox | psusi: I will review it tomorrow hopefully. got to go now | 17:08 |
| dobey | anyone can think of a reason why dpkg-buildpackage would not be applying patches in a 3.0 (quilt) package? | 17:15 |
| micahg | infinity: oh, I thought the fix was in the mysql package | 17:17 |
| psusi | dobey: are you sure it is actually in 3.0 (quilt) format, and not 1.0 with quilt? | 17:18 |
| infinity | dobey: Is it using --single-debian-patch? | 17:19 |
| micahg | SpamapS: yeah, infinity is right, please coordinate with mdeslaur | 17:19 |
| dobey | psusi: yes. i just checked source/format to confirm even. | 17:20 |
| dobey | infinity: i'm not passing that argument anywhere | 17:20 |
| infinity | dobey: Which package? | 17:20 |
| dobey | infinity: and it's my package, so also weird. dirspec | 17:20 |
| infinity | dobey: Patch is in patches/series? | 17:21 |
| dobey | realised the one i just uploaded to quantal-proposed is ftbfs due to new pep8 warning about more stuff, and made a patch, but it's not getting applied | 17:21 |
| dobey | it is, yes | 17:21 |
| infinity | dobey: Also, when you 'dpkg-buildpackage', you don't mean you expect it to be applied on build, right? | 17:21 |
| infinity | dobey: It's applied when unpacking with dpkg-source. | 17:22 |
| dobey | infinity: surely it has to be applied when built | 17:22 |
| dobey | infinity: i stuck a patch in, did bzr bd, then building it in a quantal chroot | 17:22 |
| dobey | and no patch | 17:22 |
| mdeslaur | infinity, SpamapS: what's the issue? we need to rebuild the apparmor package in -security? | 17:23 |
| dobey | i've done this a hundred times and it's worked fine before. so it not working now makes no sense | 17:23 |
| infinity | dobey: If you dpkg-buildpackage -S, and then dpkg-source -x the resulting .dsc, does it get applied? | 17:23 |
| infinity | mdeslaur: dh_apparmor needs to be updated (so, apparmor in one series, dehelper in another, AFAIK) so future MySQL builds don't have issues. | 17:24 |
| dobey | infinity: yes | 17:24 |
| infinity | mdeslaur: (And potentially other things, I don't know if anyone's looked at the impact yet) | 17:24 |
| mdeslaur | infinity: do you have a bug #? | 17:24 |
| infinity | mdeslaur: http://pad.lv/986892 | 17:25 |
| ubottu | Launchpad bug 986892 in debhelper (Ubuntu Oneiric) "mysql-server postrm breaks apparmor profile for later versions on purge" [High,In progress] | 17:25 |
| infinity | dobey: Then it seems to be working as designed. | 17:25 |
| dobey | infinity: wonder why it isn't getting applied when doing pbuilder-quantal blah.dsc then | 17:26 |
| infinity | dobey: Erm, if the .dsc is the result of the above dpkg-buildpackage -S, it certainly should be. | 17:26 |
| micahg | dobey: did you bzr add the file? | 17:27 |
| infinity | Not that I use pbuilder, but I assume it just does a dpkg-source -x like anything else. | 17:27 |
| dobey | huh | 17:27 |
| dobey | micahg: yes | 17:28 |
| dobey | ok wtf | 17:28 |
| dobey | infinity: actually, in the pbuilder dpkg-source does say it's getting applied. but the thing it fixes is still failing. which is weird | 17:28 |
| alkisg | mterry: hi there, would you have time to talk about AccountsService/LightDM wrt keyboard layouts? I think there's a design issue there resulting in LP bug #1016409 and LP bug #919200 (basically keyboard layout is now broken for Greeks unless they manually add them from gnome-control-center, but even then layout switching doesn't work in lightdm). X defaults are not respected in any case. | 17:28 |
| ubottu | Launchpad bug 1016409 in lightdm (Ubuntu) "Default XKBLAYOUT is not used, so new users only have "en" layout" [Undecided,New] https://launchpad.net/bugs/1016409 | 17:28 |
| ubottu | Launchpad bug 919200 in lightdm (Ubuntu) "Doesn't know system default layout/variant" [High,Fix released] https://launchpad.net/bugs/919200 | 17:28 |
| mdeslaur | SpamapS, infinity: ok, so when I do the next mysql security updates, I'll also update the dh_apparmor stuff at the same time | 17:29 |
| dobey | and it certainly fixes it, otherwise the branch i pulled the patch from, wouldn't have landed in our upstream trunk, which is running the exact same tests on quantal | 17:30 |
| barry | mvo_, cjwatson you've done releases from lp:~ubuntu-core-dev/command-not-found/ubuntu before. what's the best way to merge lp:command-not-found into the former for release? or do you do it some other way? (i want to use the same procedure you've used before) | 17:31 |
| dobey | anyone know if the 3.4 (or 3.5) kernel is getting backported to 12.04 anytime soon? i thought i understood it would be from UDS | 17:54 |
| === deryck[lunch] is now known as deryck | ||
| micahg | dobey: I thought that happened after release | 17:57 |
| dobey | after quantal final release you mean? | 17:57 |
| micahg | yes | 17:57 |
| dobey | maybe i should just upgrade to quantal on this machine then | 17:59 |
| infinity | dobey: Yeah, only released kernels are backported. But you can install quantal's kernel on precise without any backporting. | 17:59 |
| dobey | also. is there a way to make pbuilder-dist NOT destroy the chroot directory when it fails? | 18:00 |
| micahg | dobey: --preserve-buildplace ? | 18:06 |
| dobey | micahg: apparently not. it doesn't unpack the chroot into a new PID directory underneath the build dir, but tries to use the build dir itself if i do that, and fails to create files because there's no directory structure | 18:08 |
| dobey | :-/ | 18:10 |
| micahg | yeah, man page clarifies what it really does :( | 18:10 |
| mvo_ | barry: I would suggest using the ~ubuntu-core-dev/command-not-found/ubuntu branch and just run bzr-buildpackage from there | 18:14 |
| dobey | what the heck is goin on. | 18:14 |
| barry | mvo_: except that i don't think that branch has cjwatson's py3 support | 18:14 |
| mvo_ | barry: meh, ok, let me actually look at the situation | 18:15 |
| barry | mvo_: sorry ;) | 18:15 |
| mvo_ | barry: haha, no I need to appologize for making suggestions without really investigating | 18:15 |
| dobey | if i do "bzr bd" the dpkg-source during that build doesn't say it's applying the patch. if i do "bzr bd -S -- -sa" it also mentions nothing about the patch, but if i "dpkg-source -x" on the resulting .dsc, it clearly says it applies the patch (and it does, by looking at the resulting directory) | 18:16 |
| barry | dobey: maybe add DH_VERBOSE=1 to d/rules? | 18:16 |
| dobey | barry: doesn't seem to tell me anything extra/new | 18:18 |
| dobey | the patch is clearly not getting applied during dh_clean | 18:19 |
| infinity | dobey: The patch isn't applied during clean, or during build at all. | 18:21 |
| infinity | dobey: Only during unpack. | 18:21 |
| infinity | dobey: That's how v3-quilt packages work. | 18:21 |
| dobey | dpkg-source happens during dh_clean; i don't see any dpkg-source before that in the log | 18:22 |
| === zyga is now known as zyga-afk | ||
| infinity | dobey: Uh, what? | 18:24 |
| mvo_ | barry: all ready now, if you don't mind I upload in a bit | 18:24 |
| cjwatson | barry: I've not done an upstream merge of c-n-f before, which is one of the reasons I haven't done so this time :-) | 18:24 |
| infinity | dobey: You're suffering layering issues here. | 18:24 |
| dobey | oh now i see the one before and it says it's applying the patch | 18:24 |
| infinity | dobey: dpkg-source unpackage source. dh_clean runs from debian/rules. | 18:24 |
| infinity | dobey: Clearly, B can't happen before A. :P | 18:24 |
| dobey | infinity: i'm suffering from something driving me freakin insane | 18:24 |
| cjwatson | infinity: while you're right, I think buildpackage is *also* meant to ensure that patches are applied | 18:25 |
| barry | mvo_: go for it :) cjwatson yeah ;) | 18:25 |
| mvo_ | cjwatson: all taken care of now, the upstream branch diverged a bit, but I think its all good now (fingers crossed) | 18:25 |
| cjwatson | mvo_: great, thanks | 18:25 |
| mvo_ | barry, cjwatson: should be a matter of bzr merge lp:command-not-found in the future from now on | 18:25 |
| mvo_ | (for the upstream merge) | 18:25 |
| barry | mvo_: perfect, that's what i would have thought, but the conflicts made me nervous :) | 18:26 |
| infinity | cjwatson: I'm not sure I've ever noticed this behaviour, but it could be because I always follow the hack->sourcepkg->build workflow. | 18:26 |
| cjwatson | yeah | 18:26 |
| mvo_ | barry: yep | 18:27 |
| barry | mvo_: thanks. i can't wait to turn another row green! | 18:28 |
| mvo_ | barry: https://launchpad.net/ubuntu/+source/command-not-found/0.3ubuntu1 :) | 18:29 |
| mvo_ | and ftbfs! joy! | 18:29 |
| barry | mvo_: good enough for me! thanks | 18:29 |
| * mvo_ fixes | 18:29 | |
| barry | urg ;) | 18:29 |
| mvo_ | just b-d updates it seems like python-apt -> python3-apt etc | 18:30 |
| barry | mvo_: yeah. probably also python3-distutils-extra | 18:30 |
| mvo_ | yes | 18:30 |
| * barry returns to the pain-inducing xapian port | 18:31 | |
| mvo_ | barry: \o/ | 18:31 |
| mvo_ | barry: is the concensus from upstream now *how* to approach it? last I checked there was a bit of uncertainty, no? | 18:31 |
| barry | mvo_: still is unfortunately. | 18:32 |
| mvo_ | :/ | 18:32 |
| dobey | how can i upload stuff to people.ubuntu.com? | 18:33 |
| cyphermox | dobey: use sftp | 18:33 |
| dobey | i just get "connection closed by remote host" | 18:33 |
| cyphermox | dobey: you also need to put the files under pu | 18:35 |
| cyphermox | *public_html if you want them to be accessible | 18:35 |
| dobey | yeah, the obvious bits are obvious, but i can't establish a connection | 18:36 |
| cyphermox | ok | 18:36 |
| cyphermox | it's reachable without issues from here | 18:36 |
| dobey | hrmm | 18:37 |
| dobey | ssh_exchange_identification: Connection closed by remote host | 18:37 |
| dobey | that's all i can get | 18:37 |
| dobey | anyway | 18:39 |
| dobey | infinity: can you tell me if i'm totally crazy or not then? http://people.gnome.org/~dobey/dirspec/ | 18:41 |
| infinity | dobey: I can tell you that without looking. | 18:41 |
| infinity | dobey: (But yeah, let me poke. | 18:41 |
| infinity | ) | 18:41 |
| dobey | heh | 18:41 |
| infinity | dobey: 403. | 18:42 |
| Laney | dobey: sftp -vvv people.ubuntu.com — look for suspicious output? | 18:42 |
| dobey | infinity: fixed | 18:42 |
| dobey | Laney: it just loads the certs locally, spins a few seconds, then fails with the connection closed; i guess maybe my ssh key isn't on there | 18:44 |
| infinity | dobey: Patch gets applied, package still fails to build. | 18:45 |
| infinity | HAHAHA. | 18:45 |
| dobey | what? | 18:45 |
| infinity | dobey: Uhm. So, your "pep8 --repeat . setup.py" invocation is leading to it checking the cached unpatched copy in .pc/ | 18:46 |
| dobey | wtf | 18:46 |
| dobey | sigh | 18:46 |
| dobey | oh of course | 18:47 |
| dobey | crap | 18:47 |
| infinity | http://lucifer.0c3.net/~adconrad/dirspec_3.99.1-0ubuntu2-amd64-20120626-1243 | 18:47 |
| dobey | yeah i see that now | 18:47 |
| dobey | :( | 18:48 |
| kees | hello MIR folks ... can someone approve this? I'd like to get XPS support into evince. https://bugs.launchpad.net/ubuntu/+source/libgxps/+bug/965467 | 18:51 |
| dobey | infinity: thanks. grmbl srcdr == builddir builds. | 18:51 |
| ubottu | Launchpad bug 965467 in libgxps (Ubuntu) "[MIR] Please transfer libgxps 0.2.2-1 (universe) to main" [Undecided,Confirmed] | 18:51 |
| kees | now I wish I didn't step down from the MIR team. ;) | 18:52 |
| dobey | that reminds me of a couple MIRs i need to do | 18:53 |
| infinity | dobey: pep8 take an --exclude= | 18:54 |
| infinity | dobey: Adding --exclude=.pc should do. (testing now) | 18:54 |
| dobey | yeah | 18:54 |
| dobey | i already made a patch to do that also | 18:54 |
| infinity | dobey: Yeah, that worked for me. | 18:56 |
| dobey | and uploaded, finally. thanks again | 18:57 |
| hallyn | stgraber: hm, i can't tell if i have a bug in my code, or if i'm just having kernel bugs (on ec2) | 19:03 |
| stgraber | hallyn: doing what? | 19:04 |
| mvo_ | barry: eh, so: dh $@ --with=python3 calls "dh_auto_clean: python setup.py clean -a returned exit code 1 | 19:05 |
| mvo_ | " that does not looks quite right if I want a pure py3 package does it? | 19:05 |
| mvo_ | barry: what am I missing :) ? | 19:05 |
| hallyn | stgraber: seems just starting containers | 19:05 |
| barry | mvo_: you need dh_clean_override and not up-call to dh_clean :) | 19:05 |
| mvo_ | barry: *cough* | 19:05 |
| mvo_ | really? | 19:05 |
| barry | mvo_: yep | 19:05 |
| barry | http://wiki.debian.org/Python/LibraryStyleGuide | 19:05 |
| barry | http://wiki.debian.org/Python/AppStyleGuide | 19:06 |
| barry | mvo_: dh does not know how to handle python3 yet :( | 19:06 |
| barry | and `dh $@ --with python3` is *not* enough to make it work | 19:06 |
| hallyn | stgraber: http://paste.ubuntu.com/1061318/ doesn't look good, but that doesn't 'mean it's not my fault :) | 19:06 |
| dobey | barry: is fixing that one of the goals for 12.10? | 19:06 |
| barry | mvo_: the up-calls in those examples only work if you are providing both a py2 and py3 version. remove the up-calls if it's py3 only | 19:07 |
| infinity | barry: Maybe that should be fixed, instead of entrenching awful overrides all over? | 19:07 |
| barry | dobey: no. debian has a gsoc project working on python multibuild, but honestly i don't know what the status is. being a gsoc project, i don't have high hopes ;). it's something we should get involved in, but probably no time for 12.10 | 19:07 |
| hallyn | smb: ^ | 19:07 |
| hallyn | smb: is http://paste.ubuntu.com/1061318/ something known? | 19:08 |
| barry | infinity: agreed, but see ^^ for the sad state of current affairs | 19:08 |
| stgraber | hallyn: fun ;) I don't think I tried lxc on 3.5 yet, maybe that kernel is broken somehow | 19:08 |
| barry | infinity: at least, when/if pymultibuild works, the overrides won't break, and then we can go back and clean things up during normal package maintenance (ha ha) | 19:08 |
| hallyn | stgraber: d'oh, maybe that's it | 19:09 |
| infinity | barry: Fair enough. I dunno, one would think fixing dh_auto_clean would be vaguely trivial for someone who knows the issue. | 19:09 |
| hallyn | stgraber: in any case i intend to wait a bit to push that lxc :) you weren't in any hurry for your fix, or were you? | 19:09 |
| hallyn | (i've pushed my additional pits to your tree, which isn't quite right, but it's what i did...) | 19:09 |
| dobey | things like this really should be fixed *before* pushing everyone to py3 :) | 19:09 |
| barry | infinity: you probably want to fix things consistently, iow, you don't want to eliminate the dh_clean up-call problem w/o also fixing dh_auto_build and dh_auto_install (which has some of the same problems) | 19:10 |
| barry | dobey: well, that's what we get for trying to be aggressive. the perfect is the enemy of the good. /me reaches for other cliches | 19:10 |
| infinity | barry: True. But it's probably all reasonably trivially-derived from the X-Python headers, and easily cascaded down through the stack. | 19:11 |
| dobey | even when dh is fixed to work with python3 without a billion overrides, i doubt it will be perfect | 19:11 |
| stgraber | hallyn: nope, no hurry. Anyway, we're talking about landing stuff in -proposed, not like anyone would use that until post-alpha2 then | 19:11 |
| stgraber | hallyn: so might as well wait till Thursday and push directly to quantal (once the freeze is lifted) | 19:12 |
| mvo_ | barry: meh, ok, this is a bit more work than I had hoped for 21:00 in the evening, I will leave it for now, its almost ready, I think simply building py2,py3 is the simplest approach for now | 19:12 |
| dobey | i just like it when the ducks are in somewhat of a row, even if it's curvy | 19:12 |
| barry | dobey: since dh is written in perl, that is assured | 19:12 |
| dobey | well at least it's not in python | 19:12 |
| dobey | then it'd have to deal with all the string parsing insanity to support both python2 and python3 | 19:13 |
| dobey | not a fun road, that one | 19:13 |
| barry | mvo_: if you want to push a branch, i can take a crack at it for the rest of my day | 19:14 |
| slangasek | hallyn: hi - so on bug #974584... this is the same bug we discussed a couple weeks ago? | 19:25 |
| ubottu | Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584 | 19:25 |
| slangasek | hallyn: I'm actually confused as to why we would block on the Debian maintainer for this | 19:25 |
| slangasek | (though in any case, the git repo is maintained in Debian's collab-maint, so I can commit the fix as soon as we're sure it's right) | 19:25 |
| hallyn | slangasek: yup, same one | 19:30 |
| hallyn | stgraber: I suppose making a file under /usr/share/doc/examples/ executable is against policy? (i'll check...) drat | 19:31 |
| infinity | hallyn: There's no reason to have something in examples executable unless you intend to run it from a maintainer script or something, in which case, it belongs in /usr/share/package, since /usr/share/doc shouldn't be referred to by scripts. | 19:32 |
| stgraber | hallyn: I guess you could move it to /usr/share/lxc/example-hooks/ or something similar then | 19:33 |
| stgraber | or just /usr/share/lxc/hooks/ but I guess some people would think that these would be hooks being run for all containers | 19:34 |
| hallyn | think i do like /usr/share/lxc/hooks better... but i'll defer | 19:34 |
| hallyn | stgraber: multiple hooks work jsut fine, btw | 19:36 |
| hallyn | oops, i need to not litter mtab from the mount hook. | 19:38 |
| hallyn | and yeah it looks like a kernel bug on amazon's images. not having a problem elsewhere. i think it may have to do with ebtables | 19:40 |
| slangasek | hallyn: I think I've missed the justification for why, in a chroot, we would ever want /run/shm to be a symlink to /dev/shm. Is that because it's the only way to ensure things referencing /dev/shm and things referencing /run/shm (all 0 of them currently) see the same view? | 19:41 |
| slangasek | hallyn: it would help me to see laid out what all the correct end states are | 19:47 |
| hallyn | slangasek: if /dev is bind-mounted from the host ina chroot, then we don't want to mess with its dev/shm | 19:48 |
| hallyn | so, we could do nothing, rather than symlinking it to /run/shm | 19:49 |
| hallyn | so yeah it' sso that anything you run in the chroot without exiting/reentering it will talk to each other if using /dev/hsm and /run/shm | 19:51 |
| slangasek | hallyn: but then we should check if /dev/shm is bind mounted rather than if /dev is bind mounted, no? | 19:52 |
| slangasek | hallyn: because /dev could be bind mounted while /dev/shm is either a) an empty mountpoint or b) a symlink to /run/shm, which would resolve within the chroot | 19:52 |
| hallyn | slangasek: no, the point is not to mess up the contents of /dev on the host | 19:52 |
| hallyn | heh, good point, it could make a circular symlink | 19:53 |
| hallyn | so perhaps, if /dev is a mountpoint in a chroot, we just do nothing? | 19:53 |
| hallyn | tbh i'm not sure what sort of case you'd have where /dev is a mountpoint and yo'ure in a chroot | 19:53 |
| hallyn | schroot i guess | 19:53 |
| slangasek | let me jot some thoughts into the bug | 19:54 |
| hallyn | slangasek: thanks | 19:55 |
| tkamppeter | In bug 1017507 a user writes "question # 200800" without link. Is there a way to find this question? Searching for question numbers in askubuntu does not work. | 19:56 |
| ubottu | Launchpad bug 1017507 in cups (Ubuntu) "Cannot run updates on my system without getting errors" [Undecided,New] https://launchpad.net/bugs/1017507 | 19:56 |
| tkamppeter | question #200800 | 19:56 |
| micahg | tkamppeter: it's linked in the bug | 19:57 |
| tkamppeter | Found it, nicely hidden at the lower right. Thanks. | 19:57 |
| slangasek | hallyn: posted to bug #974584 | 20:08 |
| ubottu | Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584 | 20:08 |
| dobey | whee, and no way to make pbuilder use proposed afaict :-/ | 20:11 |
| micahg | dobey: use a hook to enable it | 20:12 |
| dobey | well, no easy way | 20:12 |
| cjwatson | zul: Hm, was just moving python-glanceclient to main in response to its approved MIR, and in the process noticed that it FTBFS - did you notice that? | 20:27 |
| hallyn | slangasek: thanks. | 20:27 |
| zul | cjwatson: i thought it got fixed, ill fix it right now | 20:27 |
| cjwatson | ta | 20:27 |
| slangasek | hallyn: please check my reasoning :-) | 20:27 |
| hallyn | slangasek: I will, however I'm ducking out now. I'll think through this tonight | 20:30 |
| slangasek | hallyn: ok, cheers :) | 20:31 |
| geofft | what's the repo for the uefi secure boot shim mjg59 et al have been working on? | 20:34 |
| cjwatson | https://github.com/mjg59/shim | 20:34 |
| geofft | thanks | 20:36 |
| ScottK | jelmer: How long is it going to take to get Bug #1014570 fixed? Since bzr 2.5.1 is now in precise-updates it's suddenly more urgent to fix the regression. | 20:37 |
| ubottu | Launchpad bug 1014570 in bzr (Ubuntu Quantal) "bzr: Unable to sign commits: "no terminal at all requested"" [High,Triaged] https://launchpad.net/bugs/1014570 | 20:37 |
| ScottK | !regression | 20:37 |
| ScottK | !regression-alert | 20:38 |
| ubottu | cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 20:38 |
| ScottK | See the bug I just pinged jelmer about. | 20:38 |
| ScottK | It was filed last week, but not in reference to the precise SRU until after I copied bzr to precise updates today. | 20:39 |
| ScottK | I don't think it's a blacklisting situation, but we need to get it sorted. | 20:39 |
| slangasek | hmm, tagging fail :( | 20:40 |
| xnox | ScottK: the SRU was fixing a GPG signing bug 847388 | 20:44 |
| ubottu | Launchpad bug 847388 in bzr (Ubuntu Precise) ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Medium,Fix released] https://launchpad.net/bugs/847388 | 20:44 |
| xnox | so the code from the same region was touched | 20:44 |
| ScottK | xnox: Yes and apparently, in the process, broke it the other way. | 20:44 |
| ScottK | slangasek: Since you were the first Canonical person to respond can you be the one that starts the incident report, etc? | 20:45 |
| * ScottK doesn't know all the details about such stuff. | 20:45 | |
| slangasek | ScottK: I'm not sure an incident report makes sense in this case TBH | 20:46 |
| ScottK | slangasek: OK. I thought it was done for all regressions, but I'm the new guy on the team. | 20:47 |
| slangasek | incident reports are a lot of overhead, and I expect the conclusion we would draw here is "we need better compliance with regression tagging and we need better reporting of tagged bugs on the SRU team report" | 20:47 |
| slangasek | a conclusion I don't feel the need to write a novel to reach | 20:47 |
| slangasek | jelmer: ^^ for reference, the key tag that puts this on the SRU team's radar is either 'regression-proposed' or 'regression-update' | 20:49 |
| ScottK | Mentioning it the relevant bug is nice too. | 20:50 |
| xnox | what's the story about ARM and libOpenGL? | 21:09 |
| ScottK | We have GLES on armel/armhf. | 21:18 |
| xnox | ScottK: does that mean that the software should be patched / support GLES or arm-any builds disabled? | 21:24 |
| ScottK | Yes, but I'd only disable building packages that are ~never going to get ported. | 21:25 |
| infinity | xnox: Yeah, don't just disable things willy-nilly. A build failure is a nice reminder that porting is needed. | 21:31 |
| infinity | (I wish more people would realise this) | 21:31 |
| xnox | infinity: yeah, I found it crap that so many packages did a delta to disable arm, yet the GLES was fixed in debian and I was just syncing | 21:37 |
| xnox | syncpackage into quantal-proposed is using *full* changelog, instead of realising that it should only include since proposed. | 21:38 |
| xnox | syncpackage into quantal-proposed is using *full* changelog, instead of realising that it should only include since quantal release. | 21:38 |
| infinity | xnox: Hrm? Debian doesn't default to GLES on ARM unless something changed recently. | 21:38 |
| xnox | infinity: hmmm not sure, the debian/changelog did say fix GLES or arm =/ need to find it again then | 21:39 |
| xnox | maybe someone was overjealous taking ubuntu patches? =) | 21:40 |
| micahg | xnox: re syncpackage, yeah, that's known, not sure if there's a bug | 21:40 |
| * micahg can't seem to find a bug | 21:43 | |
| === salem_ is now known as _salem | ||
| xnox | infinity: ScottK : is it hard to port from OpenGL -> GLES? | 22:10 |
| lifeless | xnox: only if you use opengl facilities | 22:11 |
| lifeless | xnox: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ | 22:12 |
| xnox | lifeless: please elaborate | 22:12 |
| lifeless | xnox: have a read of that url | 22:12 |
| xnox | ok | 22:12 |
| xnox | lifeless: thank you very much, very informative. | 22:17 |
| xnox | I am correct to say that OpenGL is converging with OpenGL ES in 4.1 and latter? | 22:21 |
| infinity | xnox: Define converging? | 22:26 |
| infinity | xnox: GLES will always be based on GL (GLES 3.x is based on GL 3.3), but unless GL drops all support for features GLES doesn't have, they'll never "converge". | 22:26 |
| xnox | infinity: porting to 2.0ES helps porting to 4.1 | 22:27 |
| infinity | xnox: And no one wants to drop support for anything, ever, because they don't want to break old software. | 22:27 |
| xnox | right. ok. | 22:27 |
| infinity | xnox: Sure, porting to a newer GLES (or a newer GL) helps in porting to the other. | 22:27 |
| xnox | OpenGL 4.1 has this on wikipedia "Full compatibility with OpenGL for Embedded Systems (OpenGL ES) 2.0 APIs" | 22:27 |
| xnox | yeap, yes that's what I meant infinity . | 22:27 |
| infinity | xnox: And porting to *just* GLES tends to make things "just work" (though without fewer features available to you) on GL4+ | 22:27 |
| infinity | s/without/with/ | 22:28 |
| infinity | xnox: Right, yes. GL4.1 is a superset of GLES2.0, but that's not helpful if your GL4.x program does Super Fancy Things. | 22:29 |
| xnox | ah =) ok | 22:29 |
| infinity | xnox: Then again, there's little excuse, outside of video games and 3D rendering software, to do things on a desktop that GLES can't do. | 22:29 |
| xnox | infinity: "avogadro: Molecular Graphics and Modelling System" probably qualifies as "3D rending software" | 22:30 |
| infinity | xnox: Yeah, there will be a few here and there. | 22:30 |
| infinity | xnox: Blender could be another that has a legitimate need for full desktop GL. | 22:31 |
| infinity | (THough, most open source GL stuff is so old that it's probably GL1.3 compliant, which means a quick port from old APIs to new APIs means it'll magically work on GLES2.0) | 22:31 |
| xnox | ok. I'm intrigued and want to do a port of something in my spare time | 22:32 |
| infinity | xnox: Pick something that's a KDE/QT application, since those have no choice but to be ported or rot. | 22:35 |
| === bjsnider_ is now known as bjsnider | ||
| Riddell | infinity: why's that? | 22:37 |
| infinity | Riddell: Because QT is linked to GLES, and that kinda bubbles up. | 22:37 |
| infinity | Riddell: Trying to build a GL application against a GLES QT ends in tears. | 22:37 |
| xnox | Riddell: on arm-any that is we are talking about | 22:38 |
| xnox | porting KDE/QT apps sounds great to pick C++ and Qt and OpenGL at the same time ;) win | 22:40 |
| Riddell | yeah applications should support both gl and gles which is hardly an easy thing to do | 22:40 |
| infinity | Riddell: It's not hard to write them that way from the get-go, it's a bit of a pain to fix after the fact. | 22:41 |
| infinity | (And sometimes, I just cheat and throw some #ifdef magic around and move on with my life) | 22:42 |
| Riddell | infinity: so doesn't the same issue affect gtk or nux? | 22:42 |
| infinity | Riddell: nux, yes. | 22:43 |
| infinity | Riddell: GTK, no. It doesn't directly do abusive things. | 22:43 |
| infinity | Riddell: And gnome-shell links against cogl, which does effin' magical GL/GLES backend mapping, so YOU DON'T HAVE TO CARE (or be a 3D programmer). | 22:43 |
| infinity | Riddell: All in all, I think gnome-shell wins here. | 22:43 |
| Riddell | interesting | 22:43 |
| infinity | Granted, if your application needs to do fancy stuff, you need to link libGL directly and do your crazy fancy stuff. | 22:44 |
| infinity | But I'd contend that for "desktop effects" type of 3D rendering, cogl has your bases covered, and is a lovely shim to "not having to give a crap about how any of it works." | 22:44 |
| robert_ancell | infinity, can you get libgee-0.8 out of NEW? It's just a versioned copy of libgee with the latest update | 22:50 |
| infinity | robert_ancell: Why are we versioning these source packages? Is there value in having the old one around? | 22:52 |
| robert_ancell | infinity, upstream versioned it, so so should we | 22:53 |
| infinity | robert_ancell: I'm not sure I agree with that statement. :P | 22:53 |
| robert_ancell | infinity, also it means we can keep the archive sane without manually updating 70 packages today | 22:53 |
| infinity | robert_ancell: The previous one was just "libgee". | 22:53 |
| robert_ancell | infinity, and you should be able to have both libgee-0.8-dev and libgee-dev installed at the same time | 22:54 |
| infinity | robert_ancell: The archive remains sane if you upload "libgee_0.7.x" as well, the old libraries stick around as long as something depends on them. | 22:54 |
| infinity | But, *shrug* | 22:54 |
| xnox | robert_ancell: multiple co-installable -dev packages are rarely supported without a meta libfoo-defaults package, ala gcc / postgres / boost where you might end up supporting multiple major versions simultaneously on LTS timeframes. | 22:55 |
| infinity | robert_ancell: If the APIs are wildly incompatible, I guess that makes some sense. If they're not, having a versioned -dev package means touching every build-dep for a transition that could have just been rebuilds. | 22:56 |
| * xnox is not sure how *big* libgee is.... judging by the name gee doesn't sound giant | 22:56 | |
| infinity | xnox: Oh, it happens more than you'd think. | 22:56 |
| infinity | xnox: But I try to discourage it when I see it, unless there's good reason. | 22:56 |
| xnox | *sigh* | 22:56 |
| infinity | (gtk2 and gtk3 come to mind) | 22:56 |
| robert_ancell | but what is the problem? | 22:57 |
| infinity | (and qt3 and qt4) | 22:57 |
| xnox | robert_ancell: the problem is that instead of doing no-change rebuilds, you actually have to modify the build-deps. | 22:57 |
| infinity | robert_ancell: If the API isn't horribly broken, it just makes more sense to build libgee-dev from the new package, rather than having coinstallable versioned -dev packages. | 22:57 |
| xnox | s/libfoo-1-dev/libfoo-2-dev/ | 22:57 |
| robert_ancell | xnox, but we modify those anyway when we change the (>= 0.16) to (>= 0.18) | 22:57 |
| infinity | robert_ancell: We don't actually want multiple versions of most libraries around. | 22:58 |
| xnox | robert_ancell: why?! shlibs depends will do that for you for the resulting binary packages | 22:58 |
| cjwatson | robert_ancell: You'll understand when you do a shift on +1maint ;-) | 22:59 |
| infinity | Also, upstream changed their SOVER scheme? Cute. | 22:59 |
| cjwatson | At scale, being able to just do no-change uploads of stuff is much easier than having to change the package name being build-depended on | 22:59 |
| infinity | We've gone from libgee2 to libgee-0.8-0 | 22:59 |
| * xnox want's to bash libtool manual against something or someone | 22:59 | |
| RAOF | xnox: To be fair, the libtool manual is a bit of an impenetrable morass. | 23:00 |
| micahg | still no reason to version the source unless we're keeping both around | 23:00 |
| xnox | RAOF: it's think and heavy enough for bashing. I'm not intending to force people to read it ;-) | 23:00 |
| xnox | I remember someone tried to do /usr/include/libfoo/1/*.h and /usr/include/libfoo/2/*.h and actually have people hardcode #include <libfoo/1/bla.h> | 23:01 |
| robert_ancell | micahg, except for the exact problem we have with poppler changing their api all the time. If upstreams versions their libraries correctly like libgee and we match it then we never get unbuildable and uninstallable packages. | 23:01 |
| * xnox cried | 23:01 | |
| robert_ancell | We just need to have a good process for reaping old versions | 23:02 |
| xnox | robert_ancell: yes and the good process is symbols versioning | 23:02 |
| cjwatson | Our process for that is pretty much fine, but it works even better when you don't have to create a new source package. | 23:02 |
| micahg | robert_ancell: I don't see how having a versioned source helps unless you're keeping both around | 23:02 |
| cjwatson | I'm entirely with infinity on that. Sometimes it's necessary, but if it isn't absolutely necessary, please avoid it. | 23:02 |
| robert_ancell | xnox, except that doesn't work when loads of packages ftbfs due to the -dev package no longer matching | 23:03 |
| infinity | robert_ancell: Surely, the goal is to move to the new version. I only see 5 dropped symbols here between 0.6 and 0.8 so, while it's an API break, porting things should be trivial. | 23:03 |
| infinity | robert_ancell: And we want things to FTBFS and need fixing, rather than shipping 7 versions of a library. | 23:03 |
| infinity | (Yes, really). | 23:04 |
| micahg | xnox: you should bump build-depends if an FTBFS patch changes uses a new API | 23:04 |
| xnox | micahg: that is true. I was working under assumptions of sane stable abi/api library maintainers | 23:04 |
| * xnox wonders why 5 symbols were dropped..... | 23:05 | |
| robert_ancell | xnox, because upstreams don't want to drag around legacy stuff forever. They just want to make a new versions and drop cruft | 23:06 |
| infinity | xnox: Not everyone is libc. ;) | 23:07 |
| infinity | API breakages happen. We deal with them. | 23:07 |
| xnox | I am surprised that libgee is actually a gnome'ish thing. gobject & gtk have very very stable api's with proper depreciation cycles etc. | 23:08 |
| cjwatson | Though I do think some upstream library maintainers are a bit arrogant in their assessment of the worth of application developers' / packagers' time vs. the "cruft". | 23:08 |
| cjwatson | "Getting rid of my kilobyte of compatibility code is worth you spending several hours porting stuff" | 23:09 |
| infinity | robert_ancell: Anyhow. If this is how Debian plans to maintain it too, fine, I'm all for keeping deltas low. But since it's not in Debian yet, I'm guessing that perhaps they'll follow our lead (or, they'll pick an unversioned source and -dev name because that's the usual way to go). | 23:09 |
| xnox | robert_ancell: where did libgee 0.8 come from ? I only see 0.7 at http://ftp.gnome.org/pub/GNOME/sources/libgee/ | 23:09 |
| infinity | xnox: 0.7 is the pre-release of 0.8 | 23:09 |
| robert_ancell | infinity, I ran it past #debian-gnome and they said version | 23:09 |
| infinity | xnox: (0.7 is what robert_ancell uploaded) | 23:09 |
| xnox | infinity: ah, ok. | 23:09 |
| robert_ancell | xnox, 0.7 is the unstable release in the 0.8 series (GNOME versioning) | 23:10 |
| infinity | xnox: Standard GNOME operating procedure. | 23:10 |
| infinity | robert_ancell: Alright, if this is how they plan to maintain it, I'll accept it like this. But I expect this won't be used as an excuse to avoid transitioning all the rdeps. :P | 23:11 |
| infinity | And hey, there's only 70 of them. | 23:11 |
| robert_ancell | infinity, nope | 23:11 |
| xnox | infinity: upstream git repo has explicit support for co-installing 0.6 & 0.8, so it looks intentional | 23:11 |
| robert_ancell | xnox, yes, it is | 23:13 |
| mbiebl | infinity: since the .pc file is versioned, there is no chance an unversioned -dev file would work without sourceful changes | 23:13 |
| * xnox scons is entertaining in calling configure to run clean, just saying.... | 23:13 | |
| mbiebl | sourceful changes to the rdeps, I mean | 23:14 |
| infinity | mbiebl: Bleh. And, while that's true, that also seems like a poor decision. :P | 23:14 |
| infinity | mbiebl: Oh well. | 23:15 |
| seb128 | yet a poor upstream decision | 23:15 |
| xnox | I will run abicheck on the libgee to check how much is actually incompatible and see if they can maintain the cruft as deprecated. | 23:15 |
| seb128 | not really ours... | 23:15 |
| xnox | since it's pre-release still, maybe they can be convinced to sanity | 23:15 |
| infinity | seb128: Yeah, I realise. Since now upstream configure scripts will look for pkg-config foo-0.8, and we sure as heck don't want to patch all of those. | 23:15 |
| infinity | seb128: Though, we could provide some symlink magic and still have one true -dev package. | 23:16 |
| * infinity thinks we need to lock some Debian library maintainers and release/ftpmaster/transition-type people in a room with a bunch of upstream library developers and wait for a few hours. | 23:16 | |
| StevenK | And then end up with a bunch of orpahned software? | 23:17 |
| mneptok | the buffet would be gone. and? | 23:17 |
| xnox | infinity: symlink magic is just delegating the trouble to security/sru/backport | 23:17 |
| micahg | hrm? | 23:17 |
| infinity | xnox: Hrm? I don't see how it would affect security/SRU at all. | 23:17 |
| infinity | xnox: And backporting is going to be a no-go period with every rdep having its configure and build-deps changed. | 23:18 |
| micahg | and backport shouldn't be affected either if the build-depends are versioned properly | 23:18 |
| infinity | xnox: (Well, sourceful backports would be needed) | 23:18 |
| xnox | infinity: about locking people up: they will end up designing go & doing static linkin ;-) | 23:18 |
| seb128 | infinity, trust me I don't like it either, it's clearly bogus upstream behaviour | 23:18 |
| seb128 | but it doesn't really make sense to try to work around upstream in our packaging in such cases | 23:18 |
| mbiebl | using API version only really works well if you do it like glib or gtk on be very strict about breaking it | 23:19 |
| seb128 | we should rather aim at teaching upstream how to do it correctly ;-) | 23:19 |
| mbiebl | bumping it with each new GNOME major release would be painful, indeed | 23:19 |
| seb128 | vala is annoying in that regard | 23:20 |
| seb128 | it leads us to have often 3 vala versions around | 23:20 |
| mbiebl | seb128: nod | 23:20 |
| mbiebl | and chasing down all rdeps is time consuming as hell on each new upstream release | 23:21 |
| xnox | libgee is written in vala... maybe that's why the break?!...... | 23:24 |
| robert_ancell | xnox, it's kind of a companion library to vala | 23:24 |
| infinity | robert_ancell: And you win an implicit pointer conversion FTBFS. | 23:30 |
| infinity | robert_ancell: (probably just a missing include somewhere) | 23:31 |
| infinity | robert_ancell: 5 implicit declarations during the build. Fixing even the ones that don't break the build would be swell. | 23:32 |
| kees | infinity: oh! you're on MIR, can you approve this one? 965467 | 23:34 |
| infinity | kees: My god, it quotes wikipedia. | 23:35 |
| kees | hehe | 23:35 |
| kees | my mom needs xps reading support. ;) | 23:36 |
| xnox | bug 965467 | 23:36 |
| ubottu | Launchpad bug 965467 in libgxps (Ubuntu) "[MIR] Please transfer libgxps 0.2.2-1 (universe) to main" [Medium,Confirmed] https://launchpad.net/bugs/965467 | 23:36 |
| infinity | kees: Your mom runs Quantal? | 23:37 |
| infinity | kees: My mom can barely sort out the TV remote. | 23:37 |
| slangasek | your mom's so quantal, she ____ | 23:40 |
| kees | infinity: she doesn't yet, but will in a few months :) | 23:41 |
| infinity | kees: Fair enough. | 23:42 |
| infinity | kees: Are you planning to make sure the desktop team hasn't forgotten about these magical evince/xps plans? | 23:42 |
| kees | infinity: once xps is in main, yeah, I'll chase down the --enable-xps option in the evince build. | 23:42 |
| infinity | kees: The rationale seems sane to me. I'm just going to give the packages a once or twice-over. | 23:42 |
| kees | infinity: okay, cool | 23:42 |
| infinity | kees: If you want to get an evince in -proposed with that flag flipped, go to town. | 23:47 |
| infinity | kees: I'll promote the lib once I'm sure it'll stick (cause I don't really feel like fighting with people over promotion/demotion over and over again in component-mismatches) :P | 23:47 |
| infinity | kees: And I assume our evince is maintained in bzr, so do be a dear and commit there too. | 23:48 |
| infinity | kees: Your mom will be proud that you touch software she actually uses. | 23:49 |
| infinity | (My parents seem to be deeply unimpressed with what I do, unless I tell them I'm fixing a bug in Firefox or Thunderbird, cause they know what those are!) | 23:50 |
| JontheEchidna | My dad always tells me to fix his KDE bugs :P | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
