| kees | hallyn: say ... do you know a way other than "find / -type f -print0 | xargs -0 getcap" to find files with filesystem capabilities? it seems like "find" needs to grow -fscap like it has -perm or something | 00:08 |
|---|---|---|
| jrwren | getcap has -r for recursive search | 00:37 |
| sarnold | kees: ^^^ | 00:37 |
| slangasek | chrisccoulson: do you happen to have heard of any problems with firefox 34 leaking fds (unix sockets)? | 01:16 |
| === Nigel_ is now known as G | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| hallyn | kees: i think libcap-ng has a tool for that | 03:08 |
| hallyn | filecap /bin | 03:10 |
| pitti | Good morning | 04:31 |
| Unit193 | Howdy. | 04:31 |
| sarnold | hehe, say good night to one german friend and a few minutes later, good morning to another :) | 04:32 |
| pitti | tyhicks, jdstrand_: is bug 1402350 something you'd want to fix upstream (would make sense), or want me to just fix the apparmor.d snippet in ubuntu? | 06:58 |
| ubottu | bug 1402350 in apparmor (Ubuntu) "allow writing to systemd journal sockets" [Undecided,Triaged] https://launchpad.net/bugs/1402350 | 06:58 |
| dholbach | good morning | 08:01 |
| === happyaro1 is now known as happyaron | ||
| chrisccoulson | slangasek, I'm not aware of any such problems | 08:30 |
| chrisccoulson | that sounds like a question for the desktop team :) | 08:31 |
| Logan_ | xnox: hey, are you aware that Ubuntu Code Search has been down for a while? | 08:32 |
| === zyga-afk is now known as zyga | ||
| darkxst | Logan_, that was Laney 's? and it wasnt working properly for a long time before it went down | 09:07 |
| Laney | I didn't have the time to maintain it properly as was | 09:07 |
| Laney | anyone else could try to set up such a thing | 09:07 |
| darkxst | right now debian codesearch is sufficient for me, with them being well ahead of us | 09:08 |
| doko | Riddell, ScottK: the marble autopkg test fails, could you have a look? blocks isl and GCC, abi-compliance-checker failing | 09:14 |
| xnox | Logan_: i only provided the dns service for it, if the ip behind it does not have codesearch or anything else all i can do is publish the dns record.... | 09:26 |
| Riddell | doko: no reply from upstream about it, I think I'll just override it | 09:29 |
| Riddell | pitti: are you the dude to ask about jenkins failues? I'm wondering what to do about https://jenkins.qa.ubuntu.com/job/vivid-adt-gwenview/lastBuild/ARCH=i386,label=adt/console | 09:50 |
| pitti | Riddell: I am, yes; let me look | 09:50 |
| pitti | Riddell: ah, retried | 09:50 |
| pitti | Riddell: ... "~ppa2"? | 09:51 |
| pitti | Riddell: btw, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has quite a lot of held back updates due to real regressions (kate, kservice) | 09:51 |
| pitti | and marble | 09:52 |
| pitti | kde-runtime too | 09:52 |
| Riddell | ~ppa uploads were obviously a mistake, I'll fix that for gwenview | 09:54 |
| Riddell | yeah talking to upstreams about those regressions, nobody seems very interested so far | 09:55 |
| Riddell | pitti: kservice needs retried too? https://jenkins.qa.ubuntu.com/job/vivid-adt-kservice/lastBuild/ARCH=i386,label=adt/console | 09:58 |
| pitti | Riddell: ah, temporary xvfb uninstallability, indeed; retried | 09:59 |
| === lifeless_ is now known as lifeless | ||
| Riddell | pitti: and kate is another timeout? https://jenkins.qa.ubuntu.com/job/vivid-adt-kate/lastBuild/ARCH=amd64,label=adt/console | 10:17 |
| pitti | yeah, but of the test itself | 10:19 |
| pitti | debian/tests/testsuite.xsession: 4: debian/tests/testsuite.xsession: kdeinit4: not found | 10:19 |
| pitti | maybe because of that? | 10:19 |
| pitti | and maybe that script can become set -e to catch that earlier | 10:19 |
| Riddell | it's a bad test, kdeinit4 is part of kde4libs but this is ported to kf5 so it wouldn't be installed | 10:20 |
| pitti | Riddell: gwenview/kservice fixed again | 10:20 |
| jamespage | stgraber, hello - any opinion on https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1402763 ? | 10:52 |
| ubottu | Launchpad bug 1402763 in lxc (Ubuntu) "Multicast traffic not propating correctly over linux bridge" [Undecided,Confirmed] | 10:52 |
| jamespage | stgraber, I'm certainly stretching LXC containers a bit, but multicast is proving a little unreliable right now | 10:53 |
| Riddell | pitti: kde-runtime is a timeout issue on build server? https://jenkins.qa.ubuntu.com/job/vivid-adt-kde-runtime/lastBuild/ARCH=amd64,label=adt/console | 11:23 |
| pitti | Riddell: indeed, retrying | 11:25 |
| pitti | Riddell: sorry about those, due to the datacenter move we lost email notifications, so I didn't retry those right away | 11:26 |
| pitti | they are back now, though | 11:26 |
| pitti | (and meh for our test machines squeaking under the load -- high time to move to the cloud!) | 11:26 |
| didrocks | pitti: at least, you have your machines back, not me yet :/ | 11:29 |
| Riddell | didrocks: what have you lost? | 11:36 |
| Riddell | didrocks: did you check behind the sofa? if you lose something it's nearly always there | 11:37 |
| didrocks | Riddell: hehe, I tried to check, but my desktop vm in the DC weren't there :) | 11:39 |
| sil2100 | didrocks: hey ho! Sorry to bother you, but we need a core-dev to +1 a packaging change for address-book-app - do you have a moment? ;) | 11:49 |
| sil2100 | It's a small change and our usual person is on holidays | 11:49 |
| didrocks | sil2100: sure, fire the link :) | 11:52 |
| sil2100 | https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-2-publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-app_0.2+15.04.20141216.6~rtm-0ubuntu1.diff <- BAM! | 11:52 |
| didrocks | sil2100: +1 :) | 11:53 |
| sil2100 | Thanks :) | 11:54 |
| === _salem is now known as salem_ | ||
| jamespage | doko, around? this bug was bought to me attention this week: | 12:07 |
| jamespage | https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1081022 | 12:07 |
| ubottu | Launchpad bug 1081022 in python2.7 (Ubuntu Precise) "logging.SysLogHandler doesn't close UNIX socket when connection failed" [High,New] | 12:07 |
| jamespage | Are you happy for me to prep the SRU? | 12:07 |
| cjwatson | pitti: Would it be worth promoting python3-apport's Suggests: python3-launchpadlib to Depends, now that it exists? | 13:38 |
| pitti | cjwatson: ooh! | 13:38 |
| pitti | cjwatson: nice one, then I can finally drop the hacks which tell you to install the py2 packages, and just use that | 13:38 |
| cjwatson | I'm assuming without proof that it passes the test suite and such ... | 13:39 |
| cjwatson | pitti: thank xnox :-) | 13:39 |
| pitti | xnox: *hug* | 13:39 |
| xnox | =)))) | 13:39 |
| xnox | cjwatson: pitti: i wanted to announce it wider when i port "ubuntu-dev-tools" and "lptools" however ubuntu-dev-tools has non-trivial test-suite with mox (not ported to python3) so it took some time to port it to plain mock first. | 13:40 |
| pitti | that's bug 1153671, I update it now | 13:40 |
| ubottu | bug 1153671 in apport (Ubuntu) "Need python3-launchpadlib" [Undecided,Triaged] https://launchpad.net/bugs/1153671 | 13:40 |
| xnox | and lptools is probably imposible to port without essentially re-writting it. | 13:40 |
| xnox | because it imports bzrlib to handle command-line args, help messages and the like......... for no reason. | 13:41 |
| pitti | xnox: bug 1060734 is another one -- should that be closed now, or is the port still missing some bits? | 13:41 |
| ubottu | bug 1060734 in launchpadlib "Support for Python 3" [Low,Confirmed] https://launchpad.net/bugs/1060734 | 13:41 |
| pitti | xnox: erk yeah, argparse should certainly do fine? | 13:42 |
| pitti | cjwatson: thanks for pointing out; bug updated, assigned to me, I'll work on it in January | 13:43 |
| xnox | pitti: yeah... also launchpadlib is now fully proxy aware, so you could do autopkgtests against e.g. dogfood. | 13:43 |
| cjwatson | xnox: also the modules from ubuntu-dev-tools are used by other unpackaged scripts like ubuntu-archive-tools; I was wondering if it would be worth packaging both 2 and 3 versions of those | 13:43 |
| cjwatson | or maybe just copying the bits we use in u-a-t and dropping the dependency ... | 13:44 |
| xnox | cjwatson: so u-d-t ship a module, i was planning to package it as python-ubuntutools & python3-ubuntutools with ubuntu-dev-tools depending on them as needed. | 13:45 |
| xnox | and then port scripts to python3 as time goes by. | 13:45 |
| pitti | xnox: apport's launchpadlib backend does have a test suite, but it almost never works (at least not a year ago or so); maybe staging is better these days, worth a try | 13:45 |
| xnox | cause i think ubuntu-dev-tools also has scripts that operate against both launchpadlib & bzrlib | 13:45 |
| xnox | pitti: there is also "mocklaunchpad" that one can authenticate against and run things..... | 13:46 |
| * xnox .... actually i think it's called fakelaunchpad. | 13:46 | |
| * xnox wants to port ubuntu-dev-tools first and then announce | 13:47 | |
| xnox | as that way it would be easier to port all the other things. | 13:47 |
| pitti | hm, I can't log into staging, my SSO google auth creds aren't working there | 13:47 |
| cjwatson | xnox: yeah, that would make sense | 13:48 |
| didrocks | pitti: it's another SSO server IIRC | 13:49 |
| TheNumb | pitti: I believe you need to use your launchpad account ;-) | 13:51 |
| cjwatson | No, staging has separate SSO | 13:51 |
| pitti | didrocks: ah yes, I could add my gauth | 13:51 |
| TheNumb | really? | 13:51 |
| TheNumb | interesting | 13:51 |
| pitti | so I now have a separate 2FA account | 13:51 |
| cjwatson | Well, I mean it's still the same account but a separate SSO instance | 13:51 |
| cjwatson | And for those who use 2FA (which pitti does) you definitely have to set that up separately | 13:51 |
| cjwatson | Because otherwise things go terribly wrong on staging restores and such | 13:52 |
| pitti | wow, 20/21 successes; given that I didn't touch it in 1.5 years, that's not bad | 14:01 |
| === trewas is now known as trewas_ | ||
| === salem_ is now known as _salem | ||
| pitti | xnox: ok, I now have a fully working test suite for apport's launchpadlib backend for py2; running it for py3 revealed bug 1403524 | 14:41 |
| ubottu | bug 1403524 in python-launchpadlib (Ubuntu) "[py3] getSourcePackage() crashes with ValueError: Expecting value: line 1 column 1 (char 0)" [Undecided,New] https://launchpad.net/bugs/1403524 | 14:41 |
| pitti | i. e. I don't get very far | 14:41 |
| === jdstrand_ is now known as jdstrand | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| rbasak | @pilot in | 15:26 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | alpha 1 freeze in place | Patch Pilots: rbasak | ||
| * rbasak has too big a chunk of work to start before he finishes for Christmas in a few hours. Might as well do something useful in the meantime. | 15:26 | |
| === _salem is now known as salem_ | ||
| mark06 | how does ubuntu handle static gpl/lgpl libraries? | 16:02 |
| mark06 | for example say package foo is statically linked with gpl packages bar and baz | 16:02 |
| mark06 | is the exact source code used from bar and baz included in source package foo? at least which packages (bar and baz) and versions? | 16:03 |
| rbasak | tkamppeter: around? I'm looking at bug 1348384. | 16:08 |
| ubottu | bug 1348384 in libspectre (Ubuntu) "evince and okular do not render eps files correctly resulting in a black background" [High,Fix committed] https://launchpad.net/bugs/1348384 | 16:08 |
| rbasak | mark06: generally we avoid static linking. But maybe the Built-Using header is what you want? Prior to that we also have build logs that will tell us which versions of build dependencies were used. | 16:10 |
| mark06 | rbasak: are these logs part of the package? Built-Using is good, will check for it | 16:11 |
| rbasak | mark06: no, the logs aren't part of the package. Launchpad does publish all build logs publicly though. | 16:12 |
| mark06 | reasonable | 16:13 |
| * rbasak appreciates guests who arrive wanting to exercise their Free Software freedoms :-) | 16:15 | |
| === quadrispro_hds is now known as quadrispro | ||
| * mark06 can't find Built-Using in https://launchpad.net/ubuntu/vivid/amd64/libxml2/2.9.1+dfsg1-4ubuntu1 | 16:19 | |
| xnox | mark06: build-using is optional and indicates what sources of which packages were used to build this thing. | 16:20 |
| bdmurray | pitti: I've updated my merge proposal | 16:21 |
| xnox | mark06: generally things like compiler / bootstrappy things declare it when they build-depend on e.g. glibc-source | 16:21 |
| infinity | And generally only makes sense if there's a strong (ie: static linking) relationships between the binary and the thing it was built with. | 16:21 |
| infinity | mark06: libxml2 isn't statically linked, so it wouldn't make sense to record Built-Using. | 16:21 |
| xnox | but it's optional, and all it does is keep the src tarball in the archive (in debian at least) it practice, we have snapshots of all releases going back to the first release thus even if something is statically linked we should have sources somewhere. | 16:22 |
| mark06 | infinity: isn't libxml2 staically linked with xz? | 16:22 |
| mark06 | xnox: since it's optional, one may forget to use it when linking stuff statically? | 16:23 |
| infinity | mark06: No. | 16:23 |
| infinity | mark06: It may include a local copy of xzlib, but it doesn't statically link to the external one. | 16:24 |
| mark06 | xnox: the upstream build code could even do that without packager even noticing | 16:24 |
| xnox | mark06: no, ldd clearly says it isn't.... | 16:24 |
| infinity | xnox: Uhm, what? :) | 16:24 |
| infinity | xnox: ldd wouldn't show a static link. :P | 16:25 |
| mark06 | xnox: no for which statement? it what? | 16:25 |
| xnox | infinity: but it shows a shared one, thus it is shared linking with liblzma.so.5 ;-) | 16:25 |
| mark06 | I'm not talking about shared | 16:25 |
| xnox | mark06: why are you talking about static linking, and/or accusing things of using static linking and how do you come to such conclusion? | 16:26 |
| mark06 | xnox: since it's optional, how one will never forget to use it when linking stuff statically? | 16:26 |
| infinity | mark06: So, yes, it's true that a build system could statically link without someone noticing. This is actually pretty hard to determine after the fact. | 16:26 |
| mark06 | xnox: accusing? omg | 16:26 |
| xnox | and debian/ubuntu maintainers usually try hard to link statically as much as possible, however e.g. firefox/libreoffice do link certain things statically. | 16:27 |
| mark06 | infinity: yeah, how about before the fact? | 16:27 |
| infinity | xnox: s/as much/as little/ | 16:27 |
| mark06 | infinity: when you are in control of build ok, you need to remember to use build-using | 16:27 |
| rbasak | In general, a package that statically links by accident is buggy. Except for special cases. | 16:27 |
| rbasak | To track down these bugs, we have build logs. | 16:28 |
| rbasak | Is that not sufficient? | 16:28 |
| mark06 | infinity: but you may forget or you don't have time to read entire upstream code to tell whether upstream part of build will do something bad (static) | 16:28 |
| infinity | mark06: People make mistakes occasionally, yes. We don't have any sentient tools to prevent that. | 16:29 |
| rbasak | mark06: is your primary concern here licence compliance, or some future technical difficulty, or something else? | 16:29 |
| mark06 | rbasak: not accidentally, just not noticed (because you won't inspect entire source code to know) | 16:29 |
| infinity | mark06: Not noticed and accidentally are ultimately the same thing. | 16:29 |
| mark06 | infinity: thanks for explaining | 16:30 |
| rbasak | mark06: note that there are generally two parties here. Upstream, and the packager. The packager is responsible for policy and license compliance in the distribution. So upstreams intention might be the packager's mistake. | 16:30 |
| mark06 | infinity: how about upstream code? it is nearly impossible to know/detect if it contains static linking code | 16:30 |
| infinity | mark06: No it's not impossible. It's a package maintainer's job to know their package. | 16:31 |
| mark06 | rbasak: gpl compliance, this issue has been raised in msys2 and we wonder what linux distros do | 16:31 |
| infinity | It's usually a pretty good hint when you need libfoo-dev to build a package but you don't end up depending on libfoo. Should set off some warning bells. | 16:31 |
| rbasak | mark06: our policy is not to have static linking. That's what we do :) | 16:32 |
| infinity | It's also not rocket science to grep a build log. | 16:32 |
| mark06 | infinity: so it's implied that static linking is supposed to be avoided as much as possible? is licensing the only reason for this? | 16:32 |
| infinity | mark06: Licensing is a small part, security auditing is the much larger reason. | 16:33 |
| infinity | mark06: As well as memory footprint, etc. | 16:33 |
| infinity | mark06: Imagine the pain if every C application statically linked libc.a, as the extreme case. | 16:33 |
| rbasak | We don't want to rebuild the world if a security update to some library is required that packages compile statically against. | 16:33 |
| infinity | We'd rebuild the entire distro for every security update. | 16:33 |
| infinity | You'd also have a much more bloated runtime footprint. | 16:34 |
| mark06 | So upstreams intention might be the packager's mistake -- not sure if I get you, but upstream could include source for static stuff in tarball, so they might be correct... but you build it again and don't notice you should do that too... is this what you mean? | 16:34 |
| rbasak | I mean that upstreams may decide to statically link, and a packager may not realise it's happening and thus violate policy and maybe licensing. | 16:35 |
| mark06 | It's a package maintainer's job to know their package. -- even so, how to read entire source code to be sure? or what general steps do most of the job? | 16:35 |
| rbasak | But that's still a mistake from the distribution's part, and should be fixed. | 16:35 |
| rbasak | And in that case, I think build logs on Launchpad are fine. | 16:35 |
| infinity | mark06: If you're including the source in your tarball, that's not the sort of static tracking we were talking about previously, as you've introduced no external source dependencies. That said, it's still usually a mistake for a packaged version to use your bundled sources. | 16:36 |
| mark06 | infinity: about libfoo-dev, you can also have it installed for another reason and not notice it's a dependency | 16:36 |
| infinity | mark06: I can't tell you how individual maintainers get to know their upstream sources, as I can't speak for thousands of people. | 16:36 |
| rbasak | mark06: essentially: yes, package maintainers can inadvertently violate licensing. They can do this in a whole host of ways. When we (the distro community) discover there's a problem, generally we fix it. | 16:39 |
| rbasak | mark06: I don't see why this particular case is special, or that there's any need to mitigate this by doing something different technically, when the root cause of this hypothetical violation will be fixed when it is brought to the maintainer's attention. | 16:39 |
| mark06 | infinity: by including the static stuff in tarball I mean for license compliance (like include a tarball within another) not that the static code has been merged into the code base | 16:41 |
| infinity | mark06: If you're violating licenses with your upstream tarball, we repack it and remove the offending bits. | 16:42 |
| mark06 | mistake for a packaged version to use your bundled sources -- don't get this, then what bundle will package use if not upstream's? | 16:43 |
| mark06 | rbasak: and you have the build logs to help fixing it, this is good | 16:43 |
| infinity | mark06: To answer the second question, if you are upstream for project Foo that links to libbar, and you include a copy of libbar sources in your source and statically compile against it, we tend to instead link synamically with libbar from the archive. | 16:44 |
| infinity | dynamically* | 16:44 |
| mark06 | infinity: I mean the opposite, say you're upstream for foo and I am the packager | 16:44 |
| infinity | mark06: ...? | 16:45 |
| infinity | If I were the upstream, I wouldn't bundle a bunch of junk. Solved. ;) | 16:45 |
| mark06 | infinity: you link foo statically with bar, both are gpl... so when shipping foo.bin you need to ship foo.src alongside it... and since you use bar, you need to include bar source in foo.src (regardless of whether it's static or dynamic linking)... | 16:46 |
| rbasak | AIUI, a distribution is free to ship both foo.src and bar.src, and foo.bin and bar.bin, and dynamically link, and nothing else is required. | 16:47 |
| infinity | If you're shipping the binaries together, you need to provide sources for both, you don't need to have them in the same source tree. | 16:47 |
| mark06 | infinity: then I package foo into ubuntu, I make the package download foo.src tarball and just build it.... it happens to be that bar is a pretty common package installed in 99% of ubuntu computers | 16:47 |
| tkamppeter | rbasak, I am here | 16:47 |
| rbasak | tkamppeter: so I'm a bit confused as to why we're adding another patch in to solve this issue, if upstream reverted it. | 16:48 |
| mark06 | infinity: result is that even if usptream is alright, I'm not anymore because I didn't notice the static liking of bar | 16:48 |
| rbasak | tkamppeter: also, can we have some dep3 headers please, so we can all follow it better? | 16:48 |
| infinity | mark06: So, we're talking in circles here. I think we've already addressed these points. | 16:49 |
| infinity | mark06: It's a packaging bug if a package statically links something it shouldn't, and we report and fix those as we find them. | 16:49 |
| mark06 | by including the static stuff in tarball I mean for reference not merge into code base (in my example, add bar.src.tar.gz within foo.src.tar.gz) | 16:50 |
| tkamppeter | rbasak, so do you think should I simply revert the old patch even if that bug reappears then? | 16:50 |
| rbasak | tkamppeter: what's upstream's plan for that bug? | 16:50 |
| infinity | mark06: If it's statically linking source shipped *with* the upstream tarball, it's not a license violation, as long as it's all compatible, it's just wrong from our policy perspective if it could be dynamically linked to a distro library instead. | 16:50 |
| mark06 | infinity: did you understand my foo/bar example at least, did you get my point (notice I didn't mention a bar.bin) | 16:53 |
| tkamppeter | rbasak, I do not know, as I have never touched libspectre before. That is not really a printing-related package and I do neither know about any upstream plans nor about what Debian is doing about it. I think this first bug only got to me as they thought initially that it was a problem of Ghostscript and thenm it turned out that it is a bug of libspectre. | 16:53 |
| rbasak | mark06: in that case, the distribution ships both foo.src and bin.src. There's no requirement in the licence that one must be _in_ the other. As long as they're both shipped, it's compliant. | 16:54 |
| mark06 | infinity: by *with* I don't mean the code base | 16:54 |
| rbasak | tkamppeter: I don't think it's appropriate to push the patch into Ubuntu without it going upstream. We don't want to be maintaining that patch forever | 16:54 |
| rbasak | tkamppeter: particularly if we don't know much about it. That just makes future merges even harder, and sets us up to get stuck on the current version for fear of regressing it in the future. | 16:55 |
| mark06 | infinity: real example: foo = pidgin++ for windows, bar = gtk+... pidgin++ uses gtk but the source for the gtk used is provided in separate tarball, see https://launchpad.net/pidgin++/trunk/15.1 | 16:55 |
| infinity | mark06: How is that relevant to Ubuntu? | 16:56 |
| mark06 | infinity: however I could put gtk+ bundle zip *within* pidgin++'s source zip and ***this*** is what I meant with with | 16:56 |
| infinity | mark06: Why would you do that? | 16:56 |
| tkamppeter | rbasak, so simply drop my proposal to take it and report the problem of both bugs to libspectre upstream. Then let upstream solve it and the fix getting into Ubuntu with an upstream release. | 16:56 |
| infinity | mark06: But also, why would I care? | 16:56 |
| mark06 | infinity: man, just an example trying to explain what I say, because you started to get lost about it? | 16:57 |
| infinity | mark06: If your build system doesn't use that tarball-in-tarball, it obviously doesn't impact me, as I'm not distributing *your* binaries, only your source. | 16:57 |
| rbasak | tkamppeter: that's the easiest, yes. I'm still fine with taking patches into Ubuntu early, but only if it fits with upstream's plans. Which requires upstream bug reports, etc. | 16:57 |
| rbasak | tkamppeter: a cherry-pick from upstream is best. | 16:57 |
| tkamppeter | rbasak, can you do the bug report upstream for these two bugs? | 16:59 |
| mark06 | infinity: I have lost you.... I just wanted to explain you small points I made that you misunderstood completely, I should have not tried to explain | 16:59 |
| rbasak | tkamppeter: no - I'm not familiar with the issue! | 16:59 |
| tkamppeter | rbasak, me not either. | 16:59 |
| rbasak | tkamppeter: I'll explain in the bug. | 17:00 |
| mark06 | rbasak: is this channel publicly logged? can I paste this chat? | 17:01 |
| mark06 | ah "This channel is logged" | 17:01 |
| infinity | mark06: I disagree that I misunderstood, but okay. :P | 17:02 |
| infinity | mark06: Fundamentally, how an upstream distributes their binaries is meaningless to a distribution. How an upstream distributes their source is meaningful only if it violates our source distribution policy. | 17:03 |
| mark06 | don't you think upstream should provide clear, easily verifiable information about what is/may get linked statically? | 17:03 |
| infinity | mark06: But including random sources in your source is generally not the right way to do things, whether it's in your tree or an archive in an archive, it just bloats the download for people who don't need it. | 17:04 |
| cjwatson | we do a degree of auditing for that sort of nested-source issue as part of security auditing for things included in Ubuntu's "main" component (as opposed to "universe"), and Debian's security team does a ton of this kind of thing as well. | 17:04 |
| infinity | mark06: Sure, upstreams should do a lot of nice things. | 17:04 |
| mark06 | in development, you don't build every lib form source... you use the binaries to link with... if packaging is wrong (missing static information), am I guilty for not having inspected each lib sources for mistakes? | 17:04 |
| cjwatson | (I think they basically grep source trees for patterns they notice from libraries that are often sources of security problems.) | 17:05 |
| cjwatson | Bugs aren't guilt | 17:05 |
| mark06 | I don't think I should be made responsible for someone else's "lies" | 17:05 |
| cjwatson | That's quite an unhealthy way to look at it | 17:05 |
| infinity | mark06: What's your actual concern here? Lawyers knocking on your door if you accidentally link something you shouldn't? That's not how the world works. | 17:06 |
| rbasak | tkamppeter: commented. | 17:06 |
| cjwatson | It would be the packager's responsibility to fix, and ideally they'd catch it early, but that doesn't mean they're "guilty" for having missed it | 17:06 |
| infinity | A bug will get filed, it'll get fixed, we move on. | 17:06 |
| infinity | mark06: A packager is responsible for the sources they upload. That doesn't somehow make them terrible people if they miss something. | 17:07 |
| cjwatson | Also, library packaging can mitigate this problem by simply not providing .a files in the first place, which is true for quite a few of our library packages these days | 17:08 |
| mark06 | whether it's in your tree or an archive in an archive -- you continue to misunderstanding pretty hard.... the latter is ***only for license compliance***, you can put it alongside instead of inside if you like (I did in my project) | 17:08 |
| cjwatson | (Obviously it's still possible if source is actually copied around, but in practice that is much rarer) | 17:08 |
| cjwatson | I'm pretty sure infinity understands this problem extremely well; maybe if you consider this a communication issue rather than them fundamentally not understanding, the conversation would go easier | 17:09 |
| tkamppeter | rbasak, thanks. | 17:15 |
| mark06 | cjwatson: not sure if there are irrelevant gpl violations, smaller or bigger they're all violations and may be enforced by your local law, I doubt all jurisdictions in the world would think like "poor man he violated gpl accidentally" | 17:19 |
| mark06 | even though I tend to agree with you | 17:20 |
| rbasak | mark06: sounds like you need to get some legal advice. Courts don't work like that. | 17:20 |
| rbasak | mark06: I'm not aware of a single case where a distribution inadvertently violated a FLOSS license and it went anywhere near a court or settlement when fixed immediately. | 17:21 |
| rbasak | It doesn't happen because there are no damages in this kind of case. Damages are required to make a case. | 17:21 |
| rbasak | (in all jurisdictions I've heard of, anyway) | 17:22 |
| cjwatson | mark06: What would actually happen is you'd get a stern legal letter, and either (a) you dig your heels in and probably lose in court or (b) you remedy the violation | 17:22 |
| mark06 | rbasak: that sounds good | 17:23 |
| cjwatson | (in practice, anyone acting in good faith is unlikely to get close to the "stern legal letter" phase either, but ...) | 17:23 |
| rbasak | mark06: law does not work like software engineering. Things are not black and white. You might find it helpful to read "What Colour are your bits?" if you haven't already: http://ansuz.sooke.bc.ca/entry/23 - it doesn't exactly cover this sort of issue, but I think it does demonstrate how the law works differently from how many software engineers might expect. | 17:23 |
| cjwatson | And the whole bit where we do a bunch of auditing to try to prevent this, and will fix problems like this if they come up, is likely to look pretty good to a court. | 17:23 |
| cjwatson | mark06: Also, a bunch of the people here aren't speaking out of theory, we're speaking from ten years of this not causing Ubuntu to fall over in a heap of lawsuits :-) | 17:24 |
| mark06 | rbasak: Things are not black and white -- I know the law environment and I'm aware of this.... but this is exactly an argument in favor of mine | 17:25 |
| infinity | mark06: Copyright violations require the copyright holder to file suit. Unless you're inadvertently bundling GPL code that originated with the MPAA or RIAA, I think you're likely being paranoid about a situation (action seeking penalty rather than remedy) that isn't going to happen. | 17:28 |
| mark06 | cjwatson: good to know my concerns are somehow theoretical (at least for ubuntu) | 17:28 |
| infinity | mark06: From your upstream bundly perspective, though, I would still encourage you to distribute your extra sources beside yours, not contained within. Just to keep things small. | 17:29 |
| infinity | mark06: If I download your source, I don't need the other source. GPL compliance is about binary distribution (and consequential responsibility to cough up matching sources), I have no need for all the bundled things you used if I don't download your binaries. | 17:30 |
| rbasak | @pilot out | 17:35 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | alpha 1 freeze in place | Patch Pilots: | ||
| dobey | huh | 17:36 |
| mark06 | thanks all | 18:45 |
| slangasek | chrisccoulson: ok. I'm very aware of such a problem here ;) Guess I'll file a bug report... | 18:55 |
| chrisccoulson | slangasek, I'd recommend filing it upstream if you haven't | 20:09 |
| === salem_ is now known as _salem | ||
| === dpm is now known as dpm-afk | ||
| slangasek | chrisccoulson: ok. where's the right place to do that? | 20:38 |
| === ara is now known as Guest47294 | ||
| === mwhudson_ is now known as mwhudson | ||
| === dpm-afk is now known as dpm | ||
| zyga | kirkland: hey, hollywood is leaking processes like crazy | 23:07 |
| zyga | kirkland: the kill thing setup as interrupt handler doesn't kill the started widgets | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!