[00:00] * xnox will drop out of network for a moment [00:00] It'll depend on /etc/hosts though [00:03] 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:07] $ lsmod | grep ipv6 [00:08] xnox: is /etc/resolv.conf identical on both? [00:08] (suspecting that one might be a desktop machine with dnsmasq and not the other) [00:08] true [00:08] the latter statement. One is a server the other is a desktop [00:09] it wouldn't really surprise me that dnsmasq is returning that localhost record (manpage doesn't really help though) [00:09] how would I get a "clean" network environment on my desktop? chroot / sbuild? [00:10] xnox: for that test, does it actually need to bind against localhost? couldn't it bind against :: that'd bind everything? [00:10] hmmm... let me check the code [00:12] stgraber: yeap it's a bash script and I can easily change ::1 to :: [00:12] but the build will take a while, since I don't have unpurged one locally [00:14] 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] 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:15] int n = ::getaddrinfo(node, service, &hints, &sa.addrInfo); [00:15] if (n != 0) [00:15] throw Exception(QPID_MSG("Cannot resolve " << sa.asString(false) << ": " << ::gai_strerror(n))); [00:15] would you like print statements? =) [00:16] Finished on 2012-06-09 (took 35 minutes, 28.7 seconds) [00:16] it will be a while until my laptop gets to test results.... [00:17] cause 35min is on launchpad buildd [00:17] 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] =)))))) [00:17] ;-) [00:20] stgraber: how would you pass a port and :: ? [00:21] :::port is a valid ipv6 address... [00:21] host ::1:34980 works, maybe that's why it's failing.... [00:21] as in it's an IP address... [00:22] xnox: it depends, some software use [::]: for that [00:22] hmm [00:26] ok good night === chica is now known as trinikrono [02:13] hey guys. where should i go if i want to talk about developing apps for ubuntu, specifically the ubuntu app competition going on === badfox is now known as s-box === s-box is now known as raju === gerard0 is now known as gerardo [03:38] Good morning [03:51] stgraber, cjwatson, kees: argh, did we have a TB meeting last night? calendar fail, sorry === jalcine is now known as Jacky [06:40] 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:45] RAOF: I wasn't sure if the changes file needed a -v or not.. will do [06:46] RAOF: done === nijaba_ is now known as nijaba [07:17] good morning [07:17] dholbach: good morning [07:18] hey xnox [07:27] dholbach: you probably want to schedule me for patch piloting ;-) or does the 'first month free' rule apply? [07:28] haha [07:28] yes, good point - let me see where I squeeze you in :) === mnepton is now known as mneptok === thegodfather is now known as fabbione === RAOF_ is now known as RAOF [07:50] pitti: ping [07:51] hello ximion [07:51] ximion: ah, couldn't respond this morning, you were offline [07:51] pitti: hi! have you read what I wrote yesterday? [07:51] ah, okay :-) [07:52] 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] so if you want to remove it, please go ahead (but it's the only one that works with all the ubuntu plugins) [07:53] @pilot in === 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 [07:53] yep, agreed - we already removed it upstream after ~5 months of inactivity, but then glatzor did many changes, so I included it again [07:54] 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] pitti: which functionality is covered by Ubuntu plugins? [07:55] * ximion thinks it's very bad that everyone is unable to reach glatzor at this important phase [07:55] 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:56] mvo: can you upload the changes in GPK from the experimental branch to Debian experimental if you've time? :-P [07:56] 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] the second and third are specific to aptdaemon, I think [07:57] while WHAT_PROVIDES plugins are defined by packagekit, and also supported by aptdaemon [07:57] yes - what-provides is also supported by aptcc, as it is a official requirement [07:58] right, just not the python plugins; I figure we'd have to have an entirely separate implementation of these there [07:58] the language stuff is tracked as bug 238634 as far as I know [07:58] 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] it's not just language-pack-*, it's all language support packages [07:58] fonts, dictionaries, spell checkers, and the like [07:58] installing libo on a system with French and German support should install libo-help-{de,fr} [07:59] we could add that to aptcc I guess, added to my TODO (but not in time for Debian) [07:59] the software-center plugin is a little odd, mvo, do you know what it does? [07:59] ximion: doesn't PK have a generic plugin support? [08:00] ximion: it seems more appropriate to define this as plugins instead of adding distro specific package knowledge to the upstream code [08:00] 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] we use the plugins e.g. to generate a desktop-file-cache or to check for running applications, or for Listaller support... [08:01] the plugins have just to be written in C at time, which doesn't seem to be liked by Ubuntu :P [08:02] 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 === smoser` is now known as smoser [08:03] ximion: it's "install all i18n support related to the package you just want to install", to be precise [08:03] but yes [08:03] so if the generic PK plugins support this kind of plugin, it could be written in C for PK in theory [08:04] 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] TBH it's not very likely that Ubuntu will do this as long as aptdaemon is the preferrred PK API implementation [08:04] 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] if we would switch to PK only, that'd be a different story, of course [08:05] ximion: right; that's exactly what the language-selector plugin implements [08:05] 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:06] wouldn't a generic PK plugin make it available for all backends? [08:06] 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] pitti: yes [08:07] that's the whole point of it :-) [08:07] 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:08] ximion: it allows adding system-wide license keys [08:08] mvo: does it add new DBus API for that? [08:09] ximion: iirc it does, need to look at the code to be sure === 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: [08:10] 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] 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:15] (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:27] 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:29] mvo: you mean the license-key-management? [08:33] ximion: yes [08:36] mvo: Ooh, I was going to do that this morning [08:36] 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] mvo: The section needs to be "raw-ddtp-tarball", not "translated-package-descriptions", or LP will reject it [08:37] mvo: And maybe "Section: admin" or something, since "Section: base" is dead and gone === tkamppeter_ is now known as tkamppeter [08:37] * cjwatson checks the section list [08:37] Ah, "Section: localization" surely :) [08:38] 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:39] mvo: http://paste.ubuntu.com/1060404/ if you don't already have the .dput.cf fragment [08:44] cjwatson: I read part of the discussion about debian/copyright yesterday, and I have to agree that I strongly dislike it [08:45] 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:46] technical ppl want to focus on technical things, not a load of administrativae [08:47] IMO it's a huge barrier to entry [08:48] 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] I must have missed the discussion - was there anything specific to dislike about writing debian/copyright? [08:51] dholbach: No, just that people don't like doing it, apparently. :P [08:51] right [08:51] Chipzz: I'm not sure the discussion is even worth entering into. We're not going to suddenly drop debian/copyright. [08:52] pitti: I think you want to test virtualbox-guest-dkms instead of virtualbox-dkms in ubuntu-drivers-common. [08:52] infinity, let's go shopping :) [08:52] debfx: well, I guess we might want both [08:52] dholbach: *blink* [08:52] infinity: well I wasn't saying that ubuntu should do that, just giving my reason for disliking it [08:53] 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] 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:55] dholbach, infinity, we should drop debian/copyright, and no, I'm not trolling ;-) [08:55] 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:56] well at least the copyright owners part of it [08:56] having license infos is useful [08:56] 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] 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:57] infinity: surely that doesn't require you to account for the copyright of every single file in the source package? [08:57] 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] infinity, well, I can still see the value of that part [08:57] Chipzz: It requires you to at least account for the copyright of everything that gets compiled into your binary bits, sure. [08:57] infinity, where the copyright holders just doesn't make any sense [08:58] seb128: I suspect an IP lawyer may disagree with you. [08:59] 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] 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] 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] 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] seb128: On, I know they get out of date. That's no excuse for dropping them, it's reasoning for fixing them. [09:00] 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] infinity, we could as well compute a grepped list, it would be closer from really than the old static outdated one [09:01] seb128: And, as Colin mentioned before, if debian/copyright were actually machine-writable, we'd be doing that. [09:01] Yeah, i don't think i have ever updated a debian/copyright post-NEW [09:01] infinity, I was not there when that was discussed so sorry I'm out of context on that discussion ;-) [09:01] 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] seb128: Not all of us are so lucky. [09:02] infinity, I'm not, but any bad scripting would give a list as good as what the current static copyright files are [09:02] infinity: etherboot maintainers went to great effort to make upstream have a function to output the licence of each file! [09:03] 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] seb128: I agree entirely. So don't do that. [09:03] infinity, reality is that most of our archive is maintained this way [09:04] 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] I guess there is an educational issue there [09:05] 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] nobody ever convinced me of the fact that updating that list is useful [09:05] and it's the most boring job ever [09:05] Yeah, it's not fun. Or exciting. [09:05] so I just don't see why I would ever want to spend time on that [09:05] and I guess it's the same for lot of people [09:05] 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] I do - not 100% reliably but I do update it [09:06] I regard it as professionalism [09:06] Not everything about software integration is fun to everyone. [09:06] Exactly [09:07] 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] seb128: I really wish you would stop making rubbish unsupported "90%" assertions. [09:07] or it's not important, and why bother people with paper work they don't want to be doing? [09:07] Lots of people do update these files. You're not 90%, nor is the desktop team. :-) [09:07] 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] I don't have numbers and so I'm not quoting them. Please do us the same courtesy. [09:08] infinity: *that* [09:08] infinity: good night! [09:08] cjwatson, ok, fair enough, it would be an interesting pool to do amount the ubuntu-dev set [09:09] I would be interested in the result [09:09] 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] 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] 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] Chipzz: Do you upload packages to Ubuntu [09:09] ? [09:09] Or Debian? [09:10] cjwatson: I don't. but if I ever were too, that woudl discourage me [09:10] Then I'm sorry but I don't think you're in the relevant subset of people [09:10] cjwatson: no offence taken [09:10] 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] 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] cjwatson: I've thought about quite a lot, never got off my ass and did anything about it === fabo_ is now known as fabo [09:11] seb128: I wonder why 'grep 2012 gnome*/copyright' produces non-zero hits then ;-) [09:11] (which is also why I'm idling here) [09:11] (in /usr/share/doc/) [09:11] cjwatson, because the pkg-gnome in Debian do it, mbiebl especially [09:11] cjwatson: I have, however, contributed some patches and fixes in the past [09:11] cjwatson, and we sync regularly [09:11] seb128: Great, we merge enough from them that that'll make it not too out of date then [09:12] 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:13] 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] cjwatson, I'm not sure how problematic having those infos outdated is... [09:14] The BSD licence explicitly requires it [09:14] I dunno, I kind of feel that managing to violate the BSD licence is a sign you're doing it wrong [09:14] cjwatson: tbh the only thing that I have ever seen producing a licence is dhcpcd [09:15] Displaying a licence interactively or whatever is a different matter [09:16] (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:17] 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] Then maybe they're violating the BSD licence [09:17] Or maybe they just ship extra docs in rpms or something [09:17] they probably aren't dealing with it [09:17] 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] I suspect a lot of distro's are [09:17] I don't care much about rpm packaging so I've never looked [09:18] ask directhex about copyright auditing new packages [09:18] 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] I generally feel it's easier to do it by hand than to add in some wobbly stack of auditing stuff [09:19] my experience is that only debian cares about actually following the license requirements for things [09:19] 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] 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:20] Laney, i wonder if the java packagers ever lifted my openjdk dep5, from src:ikvm [09:20] seb128: Sure, I don't argue that it isn't boring [09:20] Many things are [09:20] tumbleweed: /usr/lib/cdbs/licensecheck2dep5 | diff? ;-) [09:21] 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] Sure, but the answer isn't "hey, let's violate licences" [09:21] "that'll be more fun" [09:21] I'm all for automation [09:22] cjwatson: I don't think anyone is getting any fun out violating licenses :P [09:22] Chipzz: Then stop arguing that we should. [09:22] cjwatson, how bad would be a "grep -i copyright * -r > COPYRIGHT" done during the build? [09:22] seb128: It's not unheard of [09:23] You might want to be a *little* more selective [09:23] changing debian/copyright during build is certainly wrong [09:23] 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] it coudl be a debian/rules update-copyright rule [09:23] pitti: binary copyright files don't have to be identical to debian/copyright [09:23] pitti, well, the license doesn't see that the copyright owner list needs to be in debian/copyright [09:23] see->say [09:23] 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] 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:24] Binary copyright files are shipped with the binary package which generally doesn't [09:24] I've certainly had cases where I generated the latter automatically [09:24] right, no arguing about that; but it still seems more robust to do it at package update time [09:24] It's workable too, yes [09:31] 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:32] 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:33] 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] TheMuso: That's the plan, and we've made good progress. [09:34] 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] infinity: Ok I'll take that as a yes at this point then. [09:35] It's still challenging, but it's still the plan. [09:35] I think we have a decent chance of making it. [09:35] Ok thanks. [09:35] 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:36] pitti: Yes, but joanie just wants a status update as to whether we are really still pushing this forward. [09:36] "self-fulfilling prophecy" :) [09:39] TheMuso: OK, and the simple answer there is yes. [09:40] cjwatson: Figured as much, thanks. [09:42] cjwatson: I generate the upload now, its going to take a little bit as its quite a bit of data [09:47] mvo: Right, thanks. Let me know when you've done it as dogfood doesn't process uploads automatically [09:49] cjwatson: 20/200mb uploaded so far, I let you know when its done [09:50] cjwatson: I should probably have just generate the upload for main instead of the combined one [09:50] oh well [09:50] Won't hurt to test the lot [09:50] * mvo nods [09:50] IIRC no other package includes multiple custom uploads [09:50] Ought to work but good to check [09:50] cjwatson: it will be perfect on the first upload anyway ;) [09:51] cjwatson: yeah, I think you are right, its the only one and previously I just did the uploads individually too not combined [09:51] Right - if you hadn't, they'd have been rejected [09:52] The loophole that allows binary-only custom uploads only works for a single custom file [09:52] (AFAICS) [09:52] oh, interessting [09:53] This is a bit of Soyuz I never knew was there [09:53] Even having objective evidence that it worked it took me a while to find it [09:54] (NascentUpload:process, the "Single Custom Upload detected" bit) [09:54] * mvo nods [09:54] I'd like to delete that once this new approach works, since I do think it's a dodgy loophole [09:54] I haven't had any interaction with this part since the custom upload for the ddtp stuff was added in ~2005 [09:55] Yeah, bzr blame for it went way back [09:55] Typical for Soyuz code of that vintage in that it was all mushed together with other work [09:56] * cjwatson wonders how many tests will fail if I nuke that [09:57] 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] k2dep5 . I don't see DFSG or the http://www.ubuntu.com/project/about-ubuntu/licensing changing any time soon [09:58] 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] xnox, I don't see any manual listing done in their specs [09:58] licensecheck isn't very accurate, but still useful [09:59] xnox, like we do in debian/copyright [10:00] 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] xnox, ok, thanks for the infos ;-) [10:01] np [10:05] 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] 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:06] Of course that doesn't help if upstream copyright notices are only in source files and not in upstream documentation [10:06] 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:07] 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:08] cjwatson: true, generally fedora/suse install all docs of COPYING, LICENSE etc [10:10] 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] that's pretty dependant on upstreams to give it to us in a useful form [10:11] seb128: I'm sure /usr/lib/cdbs/licesecheck2dep5 is right up GNOME package-set street ;-) === enrico_ is now known as enrico [10:11] xnox, it might well be ;-) [10:11] tumbleweed, grep -i copyright in the source get you a long way I think ;-) [10:11] I do find that $VCS log/blame is 1000 times better than tarball drops [10:12] back in the day it was more pain! [10:12] seb128: right, but still requires manual review [10:12] what about all the license lines below Copyright ... [10:12] 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:13] unfortunately, most upstreams care about this less than we do. so we end up doing the legwork [10:21] cjwatson: ddtp-translation uploaded === MacSlow is now known as MacSlow|lunch [11:14] mvo: thanks, https://dogfood.launchpad.net/ubuntu/+source/ddtp-translations - should build any year now, dogfood being what it is [11:30] Riddell, hey - any objections to https://code.launchpad.net/~logan/ubuntu/quantal/cagibi/new-upstream/+merge/111411? it looked alright to me AFAICS [11:35] 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] Debian bug 673085 in ftp.debian.org "RM: adept -- RoQA; RC buggy, unmaintained, low popcon" [Normal,Open] [11:36] ScottK, ^ maybe you know something about the two questions above too [11:36] We mirror removals across eventually, although that tends not to happen so much if the package is modified in Ubuntu [11:37] Though that's not the case here [11:37] Ah, but it has reverse-depends [11:38] Admittedly just a recommends from mythtv-database and a depends from ichthux-desktop (which is forever out of date) [11:40] ok, I'll send an email to ubuntu-devel and CC the relevant people [11:43] dholbach: looking [11:45] thanks Riddell [11:45] cjwatson: ichthux-desktop is dead, i'd remove it [11:46] directhex, Laney: is there any way somebody could try to get the banshee SRU bugs verified? [11:46] dholbach: yep cagibi is good [11:46] * xnox speaking as a provider with the core packages for ichthux-desktop, cjwatson [11:46] Riddell, ok, will upload - thanks [11:46] xnox: If you can speak authoritatively for it, perhaps you could file a removal request bug (against the package, subscribe ubuntu-archive) [11:46] Then we have an audit trail [11:47] dholbach: yes indeed adept can go [11:47] cjwatson: ok. I will CC' a couple of people from sword-devel who may be still in touch with them [11:47] (as far as kubuntu is concerned) [11:47] right-o [11:48] mvo_: https://dogfood.launchpadlibrarian.net/103960082/buildlog_ubuntu-quantal-i386.ddtp-translations_20120626.1_BUILDING.txt.gz looks OK [11:49] 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:50] dholbach: mythtv is happy to drop it. [11:50] dholbach, island trips are just overrated ;-) [11:50] dholbach, you are happier around with us [11:50] seb128, I'm happy for you to stay in rainy miserable France :-P [11:50] dholbach: Heh. [11:51] Daviey, do you think you could do an upload to remove the reference to it? [11:51] then it's just ichthux left [11:51] cjwatson: great, so time for a real upload? [11:51] dholbach, heh, it's not raining today (yet)! ;-) [11:52] mvo_: Well, let's check that it publishes first [11:52] dholbach: i'm doing that :) [11:52] Daviey, awesome [11:54] * mvo_ nods [11:58] dholbach: i'm working on removing ichthux form the archive ;-) [12:13] mvo_: So yeah, that works fine on dogfood [12:13] 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:15] cjwatson: sure, uploading now [12:16] Yay === MacSlow|lunch is now known as MacSlow [12:16] Now I will understand how translated package descriptions work [12:17] I have a begineer's question about proposing a merge to an Ubuntu package : kexec-tools [12:17] seb128: don't know. hyperair, can you do it or do you know who can? [12:18] should I propose the merge on lp:ubuntu/kexec-tools or to the version specific lp:ubuntu/precise/kexec-tools ? === zyga is now known as zyga-afk [12:19] caribou: for next development release propose to lp:ubuntu/$package [12:19] Laney: do what? [12:20] caribou: for SRU fixes to the individual release lp:ubuntu/$series/package [12:20] xnox: but if it is to fix a but in the current release ? [12:20] caribou: current release in development is quantal. and bugs should be fixed there first. [12:20] xnox: fine, that's what I understood. Then get the fix SRUEd to Precise [12:21] caribou: yes, following the http://wiki.ubuntu.com/StableReleaseUpdates [12:21] caribou: note the handy bug template for the SRU request [12:22] xnox: yes, I've done that already. Still waiting for it to be done in Lucid after a few months... [12:22] maybe I should talk to someone [12:23] caribou: about?! [12:23] caribou: what bug are you trying to fix? [12:24] the other SRU was about a vm-builder fix that is in Precise and wanted in Lucid [12:24] caribou: do you have a bug number for that one? [12:25] xnox: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/531599 [12:25] 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] hyperair: verify the banshee sru(s) [12:25] banshee has an sru? [12:25] i thought raof acked that already because banshee's got the microrelease exception [12:25] ?!?!?!?!?!?! https://launchpad.net/ubuntu/+source/banshee/2.4.1-3ubuntu1~precise1 [12:26] do you still have to verify it? [12:26] no? [12:26] you for sure have if you want it moved to -updates and not kicked out [12:26] MREs still require verification [12:26] not sure how it works with the MRE [12:26] it's on the wiki page for MREs [12:26] the MRE just makes it a valid candidate for a SRU [12:26] it doesn't mean you don't have to follow SRU rules ;-) [12:27] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [12:27] It's a relaxation, not a free pass [12:27] ah [12:27] i see. [12:28] hmmmm [12:28] so which bug would constitute as the headline bug? [12:28] it's had several SRUs; I'm surprised this is surprising :P [12:28] you need to verify all the bugs listed on http://people.canonical.com/~ubuntu-archive/pending-sru.html [12:28] the 3 of them [12:29] it will not move to update until they are all verified [12:29] Laney: it's surprising because it was accepted without me doing anything the last time. [12:29] it's likely the qa team or somebody verified the bugs for you last time === _salem is now known as salem_ [12:29] that doesn't seem to happen this time though [12:29] it's there for 2 weeks and none is flagged verified [12:32] right [12:33] the microrelease exception page says something about how bugs are considered to be fixed if their upstream bugs are fixed [12:33] can i assume so? [12:33] there still needs to be some regression testing on the actual .debs [12:34] upstream testing is required, but not sufficient for MREs [12:34] there is build dependencies, tool chains, packaging helpers, and the packaging itself which can go wrong [12:35] okay. [12:40] 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] 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] 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] Launchpad bug 919200 in lightdm (Ubuntu) "Doesn't know system default layout/variant" [High,Fix released] https://launchpad.net/bugs/919200 === vibhav_ is now known as vibhav [12:42] alkisg, hey, out of sending a patch I'm not sure, it will require somebody who has time to look at it [12:42]