=== Ursinha is now known as Ursinha-afk === Ursinha is now known as Guest52907 === LordOfTime is now known as TheLordOfTime === doko_ is now known as doko === chrisccoulson_ is now known as chrisccoulson [09:19] Is there anything wrong with precise desktop image publishing? cd-build-log says 'Build successfully added to the tracker', and the iso tracker is pointing to a cdimage link for 20121206 which is '404 Not Found' [09:19] Happened yesterday as well [09:20] not clear; I've poked it ... [09:20] mirroring is kind of out of our hands except for poking the trigger [09:22] Looks OK now [09:22] cjwatson: thanks === henrix_ is now known as henrix [09:55] can i assume that the britney block is for the alpha1 ? [09:55] Yes [09:56] thanks [10:02] infinity, ping [10:05] diwic: Sup? [10:05] infinity, you told me to ping you once I've uploaded a new pulseaudio for SRU into 12.04 [10:06] diwic: Mmkay. [10:06] infinity, hopefully I've managed to write nice little "Sru justifications" in every bug it fixes, but let me know if you have any questions. === mmrazik is now known as mmrazik|lunch [11:32] I think kubuntu is ready for alpha 1 [11:34] oh hmm the cdimage page says OVERSIZED, I our 1GB limit isn't marked for raring in some part of it [11:37] Riddell: the text != the actual size being checked for. [11:37] Riddell: but I thought non ubuntu-desktop images where still at 700 [11:38] we set it to a round 1GB for kubuntu in quantal but I guess that needs to be added for raring too === yofel_ is now known as yofel [11:44] hmm I don't see the limit being for quantal only in ubuntu-cdimage bin/publish-daily [11:45] yofel: another crash fix for 4.9.4? [11:45] yofel: able to handle it or need help? [11:45] * Riddell updates http://starsky.19inch.net/~jr/tmp/kubuntu-ppa-build-status.html [11:47] oh wrong channel :) [11:55] Riddell: AFAICS you never made that quantal-specific [11:55] lp:ubuntu-cdimage r897.1.1 [11:55] But it's in lib/cdimage/tree.py / lib/cdimage/tests/test_tree.py now anyway [12:04] stgraber: kubuntu is good to go for alpha 1 on i386 and amd64 modulo working out how to remove the oversized warnings on http://cdimage.ubuntu.com/kubuntu/daily-live/20121205/ [12:06] aah it is over the limit, that explains it 1000341504 bytes > SIZELIMIT=1000000000 [12:10] I think I'll bump that up to the binary 1GiB [12:17] cjwatson: could you merge in lp:~jr/ubuntu-cdimage/kubuntu-limit for that bumped limit? [12:17] xnox: cjwatson: any ETA for the fix for bug 1086339 [12:17] Launchpad bug 1086339 in ubiquity (Ubuntu) "Can not install raring desktop with manual partitioning" [Undecided,Confirmed] https://launchpad.net/bugs/1086339 [12:18] psivaa: I uploaded the fix yesterday, but, as I told gema, it's waiting for the Alpha 1 freeze to lift before it lands in images [12:19] Riddell: um, no - you're working off ancient source before the Python rewrite [12:19] oh I'm behind the times [12:19] Oh, hmm, is the public mirror out of date I wonder [12:20] I just did bzr co lp:ubuntu-cdimage [12:20] Hmm, LP is getting 403 [12:21] Grab it directly from http://people.canonical.com/~cjwatson/bzr/cdimage/mainline/ for now [12:21] Ah, there we go, never mind [12:21] lp:ubuntu-cdimage should be up to date no [12:21] w === mmrazik|lunch is now known as mmrazik [12:23] cjwatson: ack thanks [12:24] cjwatson: lp:~jr/ubuntu-cdimage/kubuntu-limit2 for the merging [12:25] Riddell: ./run-tests [12:27] cjwatson: good point, updated [12:29] Riddell: Righto, thanks - merged, deployed, and I've removed the *.OVERSIZED files [12:30] yay thanks [12:30] stgraber: kubuntu good to go [13:01] * ogra_ wonders if he just never noticed or if ppa-purge pulling in all of aptitude is a new thing === Ursinha-afk is now known as Ursinha [13:35] ogra_, my guess is that we don't pull in aptitude anymore by some other random package, that's causing you to now notice that ppa-purge does it [13:36] hmm, might be, yeah [13:38] ScottK, stgraber: no amd64+mac for kubuntu, no install tests on it [13:45] grr. sorry about all the precise Ubuntu desktop amd64 rebuilds, I'm trying to make a debian-cd tweak for secure boot and having a bit of trouble [13:53] stgraber: How close are you to pulling the release trigger? I'm wondering when I should drop my block. [14:06] good morning [14:07] ScottK: can you mark both images as ready on the tracker? [14:07] highvoltage: same ^ [14:07] stgraber: Done. [14:14] ScottK: so I'm planning to release within the next two hours as there's no pre-publishing or anything like that to do and the only thing left is moving the images, archiving quantal beta2 and sending the e-mail [14:14] OK. [14:14] How often does britney run? [14:17] ScottK: Every time the publisher does. [14:17] infinity: Thanks. [14:17] (So, every 30m, except when not) [14:18] ScottK: so I'll do the old milestone archiving now and wait for highvoltage to show up [14:18] OK. [14:19] pgraner: if you want one last look at the announcement before we release, it's pretty much ready now. http://pad.ubuntu.com/raring-alpha1-announcement [14:20] Our ssh issues from NM bug before are resolved, but we are blocked in automated testing on another bug it seems now: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1061242 [14:20] Launchpad bug 1061242 in ubiquity (Ubuntu) "apt-install fails during success-command because target environment cannot resolve DNS" [High,Confirmed] [14:20] anyone have a moment to take a look? [14:22] xnox maybe? ^ [14:23] plars: well I did notice the highlight (for ubiquity), I was somehow under impression this was fixed in quantal at one point by cjwatson to support adding ppas. [14:23] but needs checking. [14:28] I don't recall that but I'm an old man with a patchy memory :) [14:28] Oh, there was a resolvconf bug [14:28] Or related to that anyway [14:28] It wasn't anything to do with PPAs as I recall [14:29] stgraber, cool, works for me [14:29] xnox: You may be thinking of ubiquity r5671? [14:30] cjwatson: yes, that is the commit that I was thinking of. [14:30] plars: Please, whenever your team submits this kind of bug, could you include the preseed file? [14:31] cjwatson: yes, I'm getting one for you now [14:31] It's not much fun trying to guess whether it's a bug in the installer or in the preseeding commands [14:31] Thanks [14:31] cjwatson: http://jenkins.qalab:8080/view/Raring/view/Smoke%20Testing/job/raring-desktop-amd64-smoke-default/20/artifact/syslog/*view*/ [14:31] cjwatson: it used to attach it to the job as an artifact, but not at the moment, so give me just a bit [14:31] xnox: I don't have DNS for that [14:32] yes. [14:32] And am not particularly keen on spending half an hour setting it up :) [14:32] This should be in the bug [14:32] good, so announcement is ready, beta-2 has been archived and all alpha-1 bugs have been moved to the next milestone (month-2) and past milestones have been disabled [14:32] cjwatson: http://jenkins.qa.ubuntu.com/ would be the full name [14:33] plars: Looking at the raring-desktop-amd64-smoke it looks like it fails to find us.archive.ubuntu.com. But I remember somebody ( jibel ?) saying in the qalab only archive.ubuntu.com was accessible. [14:34] wait, I am wrong cause it access it just fine earlier in the run. [14:37] I'm pretty certain that's a similar kind of resolver misconfiguration. [14:38] Actually, it just looks like nothing especially cares about ensuring correct bind-mounts there. [14:39] And never really has. [14:40] You could just bracket your success command with 'mount --bind /run /target/run; ...; umount /target/run' for now. [14:41] cjwatson: should that simply be added to in-target wrapper & advertise everyone to use that? [14:41] Well, no, it's not that [14:41] in-target already does it [14:42] But there's a TODO in compat/apt-install saying that it should use in-target and currently does [14:42] n't [14:42] It must have been hard for some reason ... [14:43] (Well, saying that it should use chroot-setup, but that's the active ingredient in question) [14:44] Well this is what currently is run: [14:44] Dec 6 13:08:55 ubuntu ubiquity[3078]: log-output -t ubiquity sh -c sh utah-latecommand ; chroot /target sh -c 'apt-get install -y --force-yes openssh-server >>/var/log/utah-install 2>&1; apt-get install -y --force-yes gdebi >>/var/log/utah-install 2>&1; sed -i -e "/^exit 0$/iapt-get install -y --force-yes openssh-server >>/var/log/utah-install 2>&1; apt-get install -y --force-yes gdebi >>/var/log/utah-install 2>&1;" /etc/rc.local;'; chroot /target [14:44] sh -c 'chmod g+w /var/lib/utah/testsuites; apt-get install -y --force-yes imagemagick'; [ "$?" -eq "0" ] [14:44] Oh, yeah, that's nonsense [14:45] OK, that's totally the preseed file's fault [14:45] let me find the branch for this.... =) [14:45] So the claim in the bug that it was using apt-install was untrue [14:45] How misleading [14:46] that the current log of the fail in the jenkins desktop smoke test. [14:48] plars: Replace 'chroot /target' with 'in-target' throughout, including wherever it might be used within utah-latecommand [14:48] cjwatson: well it's lp:utah I am looking through it now. [14:48] cjwatson: cause the late command is generated from config values. [14:53] plars: what i see in jenkins does not match lp:utah code. And in lp:utah there is now "cp /etc/resolv.conf /target/etc/resolv.conf" which is also not what is wanted. [14:53] ScottK: Are you ready to drop your britney block? [14:54] Sure. Give me a minute. [14:54] cp /etc/resolv.conf /target/etc/resolv.conf> wow, that *really* won't work [14:54] * infinity finds it oddly creepy that his and cjwatson's hints files are both 119 bytes. [14:55] At least they aren't bricktext [14:55] cjwatson: you said there was a bug report? or just a discussion here? [14:55] hello stgraber [14:55] bug 1061242 [14:55] Launchpad bug 1061242 in ubiquity (Ubuntu) "apt-install fails during success-command because target environment cannot resolve DNS" [High,Confirmed] https://launchpad.net/bugs/1061242 [14:56] * highvoltage gets to it [14:56] cjwatson: Was that a comment on my changelog habits? :P [14:56] Heh, do you do that? I hadn't noticed [14:57] I don't consciously do it, so it's not always perfectly justified, but I seem to subconciously do it more often than seems sane. [14:57] * cjwatson is reminded again of debconf 0.9.10 / 0.9.11 [14:57] highvoltage: so if you're ready for release, just mark the images as ready on the tracker and take another look at the announcement. Everything else is good to go on my side, so I'll start publishing once you're done. [14:57] stgraber: edubuntu images marked as ready [14:58] cjwatson: commenting. thanks. [14:58] cjwatson: hahahaha. [14:58] I think that's the best changelog ever [15:01] infinity: Done and before the publisher run ... [15:01] ScottK: Danke. [15:01] ScottK: (It runs when the publisher's done, so you may have had a few more minutes to spare) [15:02] Though, when the publisher is only doing non-release pockets, it's dangerously close to instant. [15:02] * infinity commemorates the thaw by doing a d-i upload to let all the kernels in. [15:02] heh [15:03] open the gates! [15:03] They are open. [15:05] stgraber: AFAIK, Kubuntu is ready in all respects. Our flavour specific release announcement is done. [15:09] alright, let's start publishing that thing [15:09] \o/ [15:12] \o/ [15:12] excellent, thanks much stgraber and ScottK [15:16] * ScottK marked up the ISO tracker a bit. [15:20] rsync appears to be pretty slow today... it's been copying stuff to cdimage for almost 10 minutes now [15:22] ScottK, highvoltage: so I guess we should have everything ready by 11am EST. Torrents tend to take a little while to start working but half an hour should be enough for the seeder to import the new isos and start seeding. [15:22] ok [15:22] OK. [15:23] I have the correct tab open in my browser to put the annoucement on kubuntu.org [15:31] ScottK, highvoltage: publishing done, can you confirm that cdimage looks good for your respective products? [15:31] * stgraber tests the torrents [15:33] stgraber: I see them on http://cdimage.ubuntu.com/kubuntu/releases/raring/release, not on http://cdimage.ubuntu.com/kubuntu/releases/raring/alpha-1. [15:33] ScottK: hmm, indeed... wondering how I missed that. Fixing [15:35] that's really weird, only kubuntu got published as "release", edubuntu got published fine as alpha-1... [15:36] I knew the Kubuntu team is really efficient but not /that/ efficient. [15:37] ;) [15:38] oh and because of that, the html header is wrong too... /me fixes [15:38] ScottK: alright, that should be better now [15:39] Agreed. [15:40] stgraber: Looks good to me. [15:40] ok, so as usual bittorrent is the only problem, the seeder doesn't appear to work. I just poked IS to have them take a look [15:43] stgraber: I'm sure it works fine, but magellanic is crap. [15:43] stgraber: Note that it's still mirroring from nusakan. [15:43] infinity: yeah, but with 4 iso images I had hope it'd catch up a bit faster than usual :) [15:43] stgraber: It'll catch up. IS can't make it faster. [15:44] adconrad@nusakan:~$ netstat -n | grep :873 [15:44] tcp 0 0 91.189.89.127:873 91.189.90.143:38677 TIME_WAIT [15:44] When it stop suckling, it'll slowly catch up. [15:44] infinity: it appears to be done rsyncing now [15:45] stgraber: Yeahp, just finished, so now it'll take $some_time to do its tracker thing. [15:46] I guess it was just rsyncing the kubuntu images again after I moved them to the right directory, the edubuntu images have been announced on the tracker for a while now but without any seed, so maybe the seeding part of magellanic is stuck again :) [16:01] * ScottK notes the time and votes "GO". [16:01] Seconded. [16:01] bittorrent isn't there yet, but fine, I'll send the e-mail :) [16:02] cjwatson: Do you think the fix that has just been released for bug 1085961 will also fix bug 1080701? [16:02] Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [High,Fix released] https://launchpad.net/bugs/1085961 [16:02] Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs with 'ubuntu partman: No matching physical volumes found'" [High,Confirmed] https://launchpad.net/bugs/1080701 [16:03] cjwatson: can you let the alpha-1 announcement through to u-d-a? [16:03] psivaa: I'm not sure, sorry. It only affects situations where you were at some point presented with a pop-up question dialog [16:04] stgraber: done [16:04] Um so can I now say that Alpha 1 has been released? I want to make a thread in ubuntu Forums.. [16:04] smartboyhw: go ahead [16:04] cjwatson: thanks [16:06] thanks release team [16:07] np [16:07] alpha 1 released? [16:08] Yes [16:08] ETA on torrents? [16:08] stgraber: Thanks. [16:08] psivaa: PS "partman: no matching physical volumes found" is not an error [16:08] * TheLordOfTime was reading the scrollbacks. [16:08] I've deleted it from the bug title to avoid confusion [16:08] TheLordOfTime: whenever the seeder feels like it ;) it's an old terribly slow machine that really needs to be replaced... [16:08] heh [16:09] I advise against trying to guess which bits of the syslog are relevant in bug descriptions [16:09] okay, i'll assume the ETA is 67 years then :P [16:09] [16:09] Sadly Ubuntu Forums can't do two prefixes at once, if not I could have [edubuntu] and [kubuntu] all together [16:09] at least the tracker appears to work, so if one of the flavour really needs torrents now, they can probably start seeding by manually grabbing the .iso and the .torrent [16:09] smartboyhw, do all variants? [16:10] TheLordOfTime, yes I did [16:10] cjwatson: ok, thank you. i remember that advise, this bug was reported before that :) [16:10] psivaa: asked for more information [16:11] cjwatson: ok ill try to add that information [16:13] well, i'll check for the torrent(s) later then. in the mean time, if anyone on SRU team can spare me a few minutes, i'd like to borrow you to look at something for SRU eligibility checks. (assuming you're not as busy as you were approaching alpha1 release) [16:13] TheLordOfTime, well it is released anyway:P === balloons is now known as Guest26733 === Guest26733 is now known as help === help is now known as balloons1 === balloons1 is now known as balloons [17:02] cjwatson, infinity, slangasek: any of you has credentials for Release Notes [17:03] doh, bad copy/paste :) meant, https://release-blog.ubuntu.com/wp-login.php [17:03] I think I do [17:04] Looks like it. Send me content [17:04] sure, one sec [17:05] cjwatson: based on the previous posts: http://paste.ubuntu.com/1415124/ [17:09] stgraber: Is it a bit sad that I never even knew that blog existed? [17:09] (and it seems rather pointlessly redundant, unless its whole point is to be syndicated) [17:09] infinity: well, I don't think it's really mentioned anywhere, that doesn't help :) [17:09] it is aggregated in planet though [17:10] stgraber: done [17:10] cjwatson: thanks [17:10] infinity: syndicated> that [17:10] ogra_: Yeah, that's what I meant by "its whole point is to be syndicated". [17:10] right, i think thats the point [17:36] infinity,slangasek: ^- could you review that one? it should be the second half of the fix for the 12.04 SB installation problems stgraber reported [17:36] looking [17:37] ok, queuediff -b with ubiquity uploads overloads firefox [17:37] noted [17:37] heh, and there's no new bug ref anyway [17:38] Yeah, indeed [17:42] on raring it seems that 'quilt' is no longer part of the default install. how do i determine if that is true or just a personal problem ? [17:42] bjf: Was it ever? [17:42] I can't imagine why it would have been. [17:42] i don't think quilt's been included in any release ever by default... [17:43] (based on observations for quantal, precise, and oneiric) [17:43] infinity, well, i'm assuming so because i'm having to explicitly install it now for some testing and didn't before [17:43] It wasn't in any default seeds in precise either. [17:43] infinity, huh, maybe it was a dependency of something else i was installing and now no longer is [17:43] bjf: The only thing on my system that depends on it is bzr-builddeb. Maybe you had that installed before? [17:44] cjwatson: what are the conceivable values of altmeta here? I see it being appended to the name 'linux-signed-generic', but there are no packages from linux-meta that fit that pattern [17:46] cjwatson: ah, "-lts-quantal" I guess [17:46] cjwatson: ok, accepted. Do we need to reset the verification status of all the SRU bugs? [17:50] slangasek: -lts-quantal, indeed [17:50] slangasek: I think we just need to complete the SB verification, TBH [17:50] ok [17:51] It should already be exhaustive enough [17:51] * slangasek nods [17:52] only three of the bugs seem to have been verified yet so it probably wouldn't be a huge difference either way; I'll leave it as-is [17:53] cjwatson: so I guess I'll have a new image to test in an hour or so? :) [17:54] If you want to spin one, as I'll probably have EODed by then [17:54] Otherwise tomorrow morning [17:55] hmm, the efifb stride bug is still in limbo, isn't it [17:55] * slangasek ponders how to get that tested, since he can only reproduce it with d-i === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === henrix is now known as henrix_ [20:08] infinity, i'm trying to 'copy-proposed-kernel precise linux-lts-quantal' and i'm getting an error saying the signer of this package doesn't have upload rights [20:10] bjf: who's the signer? [20:10] stgraber, henrix [20:10] bjf: Got impatient waiting on me? [20:10] stgraber, he pumps out all the SRU kernels [20:11] infinity, i like to try my hand from time to time [20:11] stgraber@castiana:~/data/code/ubuntu-archive-tools$ ./edit-acl query -P kernel -S precise | grep quantalstgraber@castiana:~/data/code/ubuntu-archive-tools$ [20:11] bjf: Yeah, but I'll just end up rejecting yours and copying my own. :P [20:11] well, that copy/paste didn't work as well as I'd have liked ;) [20:11] but anyway, that source isn't in the kernel package set [20:11] let me fix that for you, then you can retry [20:11] bjf: try now [20:12] infinity, are you serious or not? [20:12] stgraber, that worked [20:12] stgraber, thanks [20:12] np [20:12] bjf: Partially serious, in that if I copy, they get auto-accepted, and I can keep track of my workflow better. [20:12] bjf: And since I need to do other work on copy too (it's not just accepting them), that's why I take that task. [20:12] bjf: do you have any other -quantal source I should add? (meta package maybe?) [20:13] bjf: (And why shankbot probably should assign that task to SRU, not to Kernel) [20:13] bjf: Well, more realistically, to archive admins, not SRU. [20:13] infinity, so, we used to bug an AA to do this, then we got perms to do it ourselves so we didn't have to bug an AA and now you are saying that we should always bug an AA? [20:13] bjf: You kinda have to have an AA touch them anyway, at least on ABI bumps. [20:14] bjf: And if you've noticed over the last few months, it was always me who closed out those tasks. :P [20:14] infinity, i'm assuming that at some point you might be on vacation when i need this done [20:14] haha, infinity on vacation, good one ;) [20:15] bjf: Sure, but you guys still can't accept or process them through NEW, so you still need someone else involved. [20:15] stgraber, ok, maybe he gets hit by a bus [20:15] bjf: It's doesn't have to be *me* (though it usually is), but it needs AA intervention, yes. [20:16] bjf: Getting the ability to copy didn't change that, it just changed things from me running "copy-proposed-kernel" to me running "queue accept". [20:16] And than all the same faff afterward with overrides. [20:17] infinity, ok, the proper interface is for us to nag, so nag we shall [20:17] infinity: though anyone in the SRU team has queue admin rights on -proposed, so is that a case where we could allow them to do the Newing themselves. Or do you actually want to do a full binNEW review on those packages? [20:18] stgraber: The NEWing there is occasionally complex enough that I'd prefer having an actual AA do it. [20:18] k [20:18] infinity, consider youself nagged :-) [20:18] bjf: I tend to get to it within a day or less anyway. Today seems to be a minor exception to that rule. [20:19] infinity, there's quite a pile waiting to go [20:19] bjf: Yeah, I'm looking at workflow right now. [20:27] infinity, i'll get shank-bot changed to assign the correct group if you can tell me the LP group you want assigned [20:28] bjf: It should be ~ubuntu-sru, though the people actually doing the work should also be AAs, I'm not sure the distinction matters much for the tracking. [20:29] And I think I may have upset LP with all these copies. [20:29] I only have about 1/4 of my accept emails so far. [20:31] Oo, there they are. [21:43] stgraber: oh, I thought cjwatson and I were going to flip a coin for alpha2 vs. beta1 [21:43] (for nusakan) [21:49] slangasek: You may still slip as many coins as you like. [21:49] Or flip them, if you prefer. [21:49] slangasek: there's still alpha-2 and 12.04.2 to flip coins for :) [21:50] I suspect Colin will take precise.2 just out of paranoia over SB not exploding. [21:50] I was perhaps assuming unduly that 12.04.2 counted separately === You're now known as ubuntulog [22:16] slangasek: dpkg-shlibdeps didn't pick up that skype->libssl dep on its own? Is it dlopen()ed or something crazy? [22:17] infinity: I didn't even find evidence of dlopen() in the strings [22:17] but yeah, it's not a shlibdep [22:18] skype's well-known for being deliberately obfuscated [22:18] cjwatson: even to the point that their own in-house packagers didn't know about this dep ;) [22:18] Maybe it's doing it through some QT interface that does something fancy at runtime. [22:19] could be [22:19] IIRC the potentially relevant Qt bits depend on openssl though. [22:19] 'apt-cache rdepends libssl1.0.0| grep -i qt' shows nothing relevant [22:21] (base)adconrad@cthulhu:~$ strings /usr/lib/i386-linux-gnu/libQtNetwork.so.4 | grep libssl [22:21] libssl.* [22:21] Not sure what that's all about, but that's the only libssl I find in all the rdeps. [22:21] And libqt4-network definitely doesn't depend on libssl. [22:21] OK. Then I remember wrong. [22:22] oh, you know what [22:22] https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1056494 [22:22] Launchpad bug 1056494 in qt4-x11 (Ubuntu Precise) "libqt4-network should have libssl in its depends list" [Medium,Triaged] [22:22] I knew about this bug and then forgot :P [22:22] Hey, lookie there. [22:22] hey look, I've even commented on it [22:23] with a veiled reference to skype [22:23] slangasek: So. Want to SRU QT instead of updating skype (or, I guess, we can do both, all belt-and-bracers like) [22:23] libqca2 ? [22:23] oh gah, debfx is claiming a license reason not to link against libssl [22:24] Surely, a dlopen() on a glob doesn't actually circumvent the GPL's intent there. :P [22:24] yes, exactly [22:24] so either we should just make it a dep, or we already have a problem [22:26] debfx: can you clarify what license issue you see in bug #1056494? Qt itself is LGPL so has no issue with libssl; and making it optional in the code doesn't help any when in practice we're shipping qt together with libssl in all cases [22:26] Launchpad bug 1056494 in qt4-x11 (Ubuntu Precise) "libqt4-network should have libssl in its depends list" [Medium,Triaged] https://launchpad.net/bugs/1056494 [22:28] slangasek: It's only been LGPL for ~3 years, maybe he's just living in the past slightly. :) [22:28] it could be a concern about GPL revdeps of Qt [22:29] I've always been a bit fuzzy about indirect linking being considered a derivative work if you don't actually use any of the offending functions. [22:29] Though, I suppose with an abstraction layer like qt-network, it's hard to avoid using bits if they're there. [22:30] it's not a question of derivative works [22:30] it's a condition of the GPL [22:30] Oh, er, right, I was thinking in the other direction. [22:30] Brain's not in debian-legal mode this afternoon. [22:30] Which is likely a good thing. [22:30] that reminds me, there's a mailing list somewhere where I need to go set the record straight about MongoDB :-P [22:31] slangasek: sounds like canonical-tech (mostly because 90% of the posts are about mongodb) ;) [22:34] ? [22:34] whose sync is that? [22:35] That was me. [22:35] Did you not want it out of proposed after all? [22:35] infinity: preempting the question of whether we should fix this in Qt instead? [22:35] slangasek: I think we should also fix it in QT, but it doesn't hurt to fix it in skype for now. [22:35] JFTR, Qt. QT is the thing Apple makes. [22:36] well, it's divergence from upstream and we don't really want to have to be responsible for that, but yeah [22:36] ScottK: Picky, picky. [22:37] slangasek: Well, I may have already copied it to raring a little bit. [22:37] infinity: shrug, you might as well follow through then [22:40] FWIW, libqca2-plugin-ossl is the Qt/SSL thing I was thinking of.