[00:03] ScottK: oh, thanks. [00:09] * RainCT shows asac his shiny Firefox t-shirt :P [00:11] * NCommander turns asac into a fox and then lights him on fire [00:11] :-) [00:12] NCommander: damn, you've got a better Firefox :) [00:16] my friend bought a plushie [00:16] we were considering lighting that on fire too but mozilla relented on the eula thing [00:16] ;) [00:16] heh [00:17] 'cuteness guaranteed' by Mozilla [00:17] he thought that was amusing [00:18] btw, someone save me.. I've been all the evening with 3 KDE developers! ;'( (ah, and there was a conversation like "-ubuntu sucks -ehm.. I'm an Ubuntu developer" xDDD) [00:18] anyway, /me is going to bed [00:20] RainCT: you'd have thought they'd be beyond that.... [00:22] heh, they're just jealous [00:22] Hobbsee: heh well, but beside that they are good guys :) [00:22] RainCT: that's true [00:22] http://www.google.com/trends?q=apple%2C+ubuntu%2C+fedora%2C+suse%2C+debian [00:22] look at that google trends graph; it says something and it says it very clearly [00:24] http://i34.tinypic.com/24lsy38.png [00:24] it was curious to see that most presentations were done using Macs (I've only seen one that didn't use Mac - but Ubuntu :)) [00:25] any thoughts on that screenshot, by the way? [00:26] (ah, it's also curious that the presentation done with Ubuntu was about to be done on a Mac -as it was already connected to the projector- but the presentation got mad there and switched slides like it wanted XD) [00:26] ..after the bug i filed on window-picker-applet gets fixed, my next problem will be figuring out how to combine menu and toolbars [00:28] ethana2: what's with that screenshot? [00:28] ah ok [00:28] eliminating redundancy really boosts elegance [00:28] and if you're going to move something to the top panel, the title and icon are it, /not/ the menu bar [00:29] * RainCT is not sure about how practical that is (as if I wanted to close a window I'd have to click on it and then move the pointer back to the top of the screen to click on the X - well, I'd just do Alt+F4, but anyway :P) [00:29] i use alt+f4 now, but obviously the window controls belong on the window [00:30] ..I have a close button in the firefox menu/tool bar thingy [00:30] but other apps aren't that configurable [00:30] http://i35.tinypic.com/inbix2.png -- that's my firefox [00:31] yeah, but that could be difficult to achieve, as the window manager is adding the controls to he border, not to the application itself [00:31] the app should pass the menu to the window manager [00:31] like in osx, i think [00:31] * NCommander still perferred Firefox when it was called Phoenix [00:31] same with toolbars and such... i don't know, still thinking about all that [00:31] i want a window decorator that just draws stuff right over the window [00:32] ugly, but otherwise it might take too long === doko_ is now known as doko [00:32] hack it first, rework it later [00:32] uhm.. you put pidgin on top of firefox :P [00:32] that corner just has a little power icon in the toolbar that closes it [00:33] i took these earlier, just had the links handy [00:33] oh ok [00:33] you of course don't need a search field 'cause you can just dump search terms into the AB and your ISP will take you right to the page [00:33] well, I'm really leaving now (I've to get up in 7 hours :P) [00:33] oh, ok, good night [00:34] (well, now that I think about it that's the same amount of time as I usually sleep, but it's sunday :P) === sylvaing_ is now known as sylvaing [01:35] superm1: reply given on bug #288294 [01:35] Launchpad bug 288294 in hal "Dell HAL Bluetooth kill switch doesn't operate properly on several platforms" [Undecided,New] https://launchpad.net/bugs/288294 [01:23] Hobbsee: You're welcome. [01:24] ScottK: didn't think they'd need a FFe, as it was a bugfix, but :) [01:25] We're into the all uploads should be discussed phase. [01:25] oh yes, that's true. [01:26] i haven't quite got it into my brain that we've actually released the RC yet. [01:26] i've got the "we release on teh 30th" part [01:26] but not the other [02:11] * ScottK notes that there are motu-release approved uploads in the UUS queue needing sponsorship. [02:33] sebner: What are your feelings on Bug 289297? [02:33] Launchpad bug 289297 in ogle "I nominate ogle for immediate removal from Ubuntu repositories." [Undecided,New] https://launchpad.net/bugs/289297 [02:38] weird, I remember it working in Hardy [02:38] unfortunately I don't have any DVD around to make sure of that [02:40] sebner did two NMU's in Debian, so I suspect he'll know. === not_rly is now known as oely_owl === oely_owl is now known as orly_owl [07:07] where do I find delted packages? (deleted from the repository) [07:58] elmargol: Is this what you're looking for: http://people.ubuntu.com/~ubuntu-archive/removals.txt ? [07:59] * iulian yawns! [08:02] iulian: i found it thx anyway [08:03] somehow my package can not find libkdcraw :( [08:05] That's weird - http://packages.ubuntu.com/source/intrepid/libkdcraw [08:05] PKG_CHECK_MODULES(Kdcraw libkdcraw>=0.4.0) [08:05] somehow that check does not work [08:07] elmargol: I don't see that version but 0.1.4 [08:08] Morning RainCT. [08:08] pool/main/k/kdegraphics/libkdcraw5_4.1.2-0ubuntu3_i386.deb [08:10] elmargol: have you the correct -dev package in build-depends? [08:10] libkdcraw-dev yes [08:11] then you need to check which files the test excepts and why it fails [08:11] https://launchpad.net/ubuntu/intrepid/+source/digikam-kde4/0.10.0~beta1-0ubuntu3 <- thats the source [08:16] elmargol: is it worth fixing it as it got removed from intrepid? [08:17] I'm not trying to fix it. I want to use the application [08:17] they removed it from intrepid because it is a beta... and the version was outdated [08:19] the old debs from LP don't work anymore? [08:19] they doo... i try to build beta4... this is beta1 [08:19] ah [08:29] elmargol: have you pkgconfig installed? [08:30] pkg-config [08:32] elmargol: look inside /usr/lib/pkgconfig/libkdcraw.pc and file a bug :/ [08:33] Version: 0.2.0-svn [08:33] ok [08:35] I didn't check if libkdcraw.pc has a bug or if libkdcraw is really just 0.2.0-svn [08:58] geser: Bug #289403 can you confirm this please [08:58] Launchpad bug 289403 in kdegraphics "/usr/lib/pkgconfig/libkdcraw.pc contains wrong version number" [Undecided,New] https://launchpad.net/bugs/289403 [09:07] mmkay digikam beta4 does not work anyway since it need some deps from kde4.2 [09:07] guess i have to wait 6 months [09:12] ScottK: I synced it so no NMU. The Debian Maintainer accepts patches but the project really seems dead though [09:13] DktrKranz: morning =) [09:13] hello sebner === asac_ is now known as asac [09:51] hi iulian :) [09:52] (uhm.. dunno why I've started IRC at home if then I don't take my USB stick with putty to be able to connect to it XD) [10:02] Can anyone tell me why powerpc does not have 2.6.27 kernel? [10:03] slytherin, Because nobody ported it in time. I hear NCommander has prepared a 2.6.27 for powerpc, but that was done too late in the cycle for inclusion in intrepid. [10:04] this is bad. :-( I just updated my laptop to realize the latest kernel is not there. [10:04] slytherin, The 2.6.25 kernel should work with intrepid. Do you know of any specific regression? [10:05] no, nothing specific. [10:05] OK. If you find something, it can be fixed. Last I knew, 2.6.25 was known working, and 2.6.26 had some regressions. 2.6.27 might be nice, but it needs more testing at least. [10:08] I will let you know if there is anything broken in 2.6.25. Of course the laptop started after almost 6 months so I have no memories of how good it was before. [10:08] heh. [10:08] Good to hear you have it working again. You might also want to play with cacao, which I understand should be pretty polished by now. [10:09] persia: IIRC, the default-jdk on powerpc is openjdk as it is in better shape than cacao [10:10] Oh, cool! I missed that change. [10:11] * slytherin takes a break for about 20 minutes. [10:19] Can someone paste the content of /usr/lib/python2.5/site-packages/softwareproperties/gtk/DialogMirror.py, please? (I'm on a public Win PC right now and so can't get it myself :P). [10:19] RainCT, What package do I need to install to get that file? [10:19] * Hobbsee grabs it [10:20] persia: software-properties, it should be installed by default on Ubuntu [10:20] RainCT_: http://pastebin.com/f60b56676 [10:20] * persia is glad Hobbsee is grabbing it, as it saves investigation :) [10:20] thanks :) [10:20] persia: pastebinit ftw! [10:21] Hobbsee, Having a system that consists of something other than an onionshell of chroots helps too :) [10:21] persia: that's true. is your main machine not intrepid yet? [10:22] It's intrepid, but perhaps not in the regular way. I'm planning a reinstall in a week or two to make it less confusing. [10:23] right [10:44] hi all === DrKranz is now known as DktrKranz [10:47] I have a question how can I set CDBS_NO_DOC_SYMLINKING variable in rules file to get rid of debian-changelog-file-is-a-symlink warnings in lintian? [10:48] marcin_ant, Just ignore debian-changelog-file-is-a-symlink : that's acceptable in Ubuntu, and CDBS shouldn't do that in Debian. [10:49] persia: ok, but anyway maybe I should learn how to set variables properly.... [10:49] although, considering that fdupes is run during the liveCD generation process, I'm not sure why we do that. [10:49] persia: CDBS_NO_DOC_SYMLINKING := yes or := true not working [10:50] marcin_ant, Oh, sure. Make has two variable types : those evaluated when the makefile is parsed, and those evaluated when used. [10:50] You can set the first type with := and the second type with = [10:51] Oh. IF you want to figure out what format to use for variable values in CDBS, you have to either pull it from your grimoire, ask for runes, or read the CDBS source. The last is usually best. [10:51] persia: in debhelper.mk (cdbs rule) there is: [ -n "$$CDBS_NO_DOC_SYMLINKING" ] [10:51] Each variable is a little different, so it's hard to give a general guideline, and I don't know the format for that one, as I think it's useless. [10:52] marcin_ant, Which checks for nonzero length, so "yes", "true", and "chickens" should all be valid values. [10:53] persia: with = or := ? [10:56] I'm trying to upload revu, but i have GPG problem [10:56] I created my source .deb and .changes by doing dpkg-buildpackage -uc -us -I.bzr -Idebian -Ipyc -Idistribution -S -sa -rfakeroot [10:57] but then sudo dput revu subdownloader_2.0.7_source.changes [10:57] Checking Signature on .changes [10:57] gpg: WARNING: unsafe ownership on configuration file `/home/yen/.gnupg/gpg.conf' [10:57] gpg: no valid OpenPGP data found. [10:57] gpg: the signature could not be verified. [10:57] Please remember that the signature file (.sig or .asc) [10:57] should be the first file given on the command line. [10:57] how can I do? [10:57] You should not be running dput under sudo [10:57] persia: it doesn't want to work at all [10:58] StevenK, it says the same without it [10:58] ivangarcia: -Idebian is also a bad idea [10:58] ivangarcia: "gpg: no valid OpenPGP data found." == means you didn't sign your .changes [10:59] That comes from the -uc. The -us is also likely to cause issues for an upload. [10:59] how can I sign then? my changelog file in debian has correct signature [10:59] marcin_ant, You probably have to define it with := before the includes, but as I said before, don't do that. [10:59] When it says signature, it means OpenPGP signature, not e-mail signature [11:00] Stevenk, how to force him to ask me for GPG signature when creating the .deb ? [11:01] ivangarcia, Instead of your complicated line, use debuild -S -I -i [11:01] hmm, now i added a new version into my changelog and it asked me for the GPG key [11:02] persia, but I want to exclude few folders to not get inside the .deb, how to do? [11:02] ivangarcia, That's what the -i -I does. [11:02] No it doesn't [11:03] Yes it does. [11:03] -I and -i exclude folders from the source tarball. This may also exclude from the .deb, but it's side-effect [11:03] Oh. It's a side effect I've used previously then :) === ivangarcia_ is now known as ivangarcia [11:06] persia, so I have to specify the folders I want to exclude by doing -Ifolder1 -Ifolder2/subfolder3 ? [11:06] ivangarcia, Apparently that doesn't reliably work (or at least that it works isn't a specifically intended feature). [11:06] persia: a problem on my laptop. Not a regression as I was having same problem even before upgrade. There is some sort of kernel panic which causes complete freeze if using GUI. If using CLI it only shows some error and continues. [11:07] slytherin, Hmm. libdrm changes maybe? [11:07] persia, so in which file can I specify the subfolders that I don't want to be included inside the .deb ? [11:07] persia: Not sure. As I said I was having problem even before upgrade i.e. in hardy. [11:08] ivangarcia: which folders are you wanting excluded from the source package? [11:08] ivangarcia, I'm not sure. I mostly work with the two-stage create-source-package, build-source-package process, rather than the create-source-and-binary-packages process. === Czessi__ is now known as Czessi [11:11] geser, for example I have a "distribution" folder that I don't want to include there, and also a images .png folder i want to exclude === jscinoz_ is now known as jscinoz [11:16] persia: ehm, got my mail? ^^ [11:17] persia, i succeded to upload to REVU, but just the .tar.gz, is that normal ? not .deb was created [11:17] ivangarcia: you should only upload _source.changes to REVU [11:18] ivangarcia: you want those folder excluded from the source package? why? [11:19] sebner, Dunno how to help you with that. I don't really understand the package. What specifically are you trying to accomplish? [11:19] well, distribution folder contains the .exe binary files and some images are already compiled into a py file, so i don't need them. [11:21] ivangarcia, If those aren't regenerated during the build, you might have to delete them from the orig.tar.gz in debian/rules get-orig-source to comply with the rule that all binaries should be compiled. [11:24] let me check some help of how to do the get-orig-source [11:25] https://wiki.ubuntu.com/PackagingGuide/Basic#Changing%20the%20Original%20Tarball [11:29] persia: sample file attached to fop bug with instructions for conversion. :-) [11:32] slytherin1, Excellent. I'll take a look at that in a bit. You've verified the fix? [11:33] persia: yes not with the new version of package but by adding just the necessary jar file in classpath in fop shell script. [11:34] slytherin1, Even better! === slytherin1 is now known as slytherin [11:35] persia: fixing the package ^^, however I'll talk to james_w then [11:36] sebner, That's probably best, if you're not sure what needs doing. I'd like to push the fix before it becomes an SRU, but it looks like it needs deep understanding to know which is the right thing to do. [11:37] persia: exactly, but like I said I'll talk to james_w again and then I'll fix it (maybe not with the best solution but fix is fix). If I have problems I'll tell you anyhow [11:38] sebner, OK. Good luck. [11:38] thx ^^ [11:49] persia: thank you for help, unfortunately I cannot see any way to avoid symlinking so I will ignore these lintian warnings, propably it's just cdbs bug [11:59] marcin_ant, It's a lintian bug in Ubuntu : the CDBS change is intentional. That it can't be disabled might be a CDBS bug, but nobody is going to care. [12:02] hello persia, my REVU is uploaded, what is the formal/educated procedure to ask reviewers to test it? [12:02] it's named subdownloader_2.0.8 [12:03] persia: ok [12:09] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497829 is good for an SRU, right? [12:09] Debian bug 497829 in sendxmpp "[sendxmpp] Syntax for specifying the connection host does not work" [Serious,Closed] [12:11] ivangarcia, paste the URL here, and ask for a review. Don't do this more than once in 24 hours, or people get annoyed. RIght now, most people will probably ignore it, as everyone is looking at release-critical stuff for intrepid. [12:12] persia, how to know the url of the REVU? the command doesn't give me any [12:12] persia: antlr3 from Debian builds fine in Ubuntu pbuilder and introduces antlr3-gcj package. The RC bug is not present in Ubuntu version. It was just and FTBFS bug after introduction of -gcj package. [12:12] Laney, Yep, unless you can cherrypick a smaller patch. [12:13] slytherin, If it's not present in intrepid, we don't care. Please mark it "Doesn't affect intrepid". We'll fix it right for jaunty. Thanks for looking. [12:13] ivangarcia, Take a look at the REVU website. [12:13] ok [12:14] I think that's the only fix in the upstream release, from the changes [12:14] Laney, In that case, maybe it's safe. You might prepare a debdiff and ask someone in MOTU Release if they would approve it. [12:14] I guess I'll have a look === nhandler_ is now known as nhandler [12:28] persia: I put comment in text box and demoted antlr3. I was expecting that comment will be saved but it is not. [12:30] motu-release: bug #289459 needs looking at [12:30] Launchpad bug 289459 in sendxmpp "Please sync sendxmpp 1.14-1 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/289459 [12:31] slytherin, You added the comment, clicked save, and pressed the green arrow and it deleted the comment? [12:31] persia: No. I didn't click save. :-( [12:32] slytherin, That's why it didn't save :) [12:44] persian, it seems that http://revu.ubuntuwire.com/details.py?package=subdownloader [12:44] it was uploaded by an old contributor [12:45] but it's not the 2.0.8 [12:48] ivangarcia, It appears that subdownloader_2.0.8_source.changes was rejected. Is your key in launchpad? Had you logged into REVU before you uploaded? [12:48] hmm, the REVU login failes with a python error [12:49] it tries to do an openid sign in from launchpad [12:49] but when i click on Sign In, it redirects me to a python error [12:49] i've reported the error to their REVU email. [12:49] my key is on launchpad [12:50] NCommander, Any chance you could look at that? [12:50] RainCT : ivangarcia wins the prize. [12:50] sebner: Does it work now? [12:51] ivangarcia, Once you get login sorted, ask a REVU admin to requeue subdownloader_2.0.8_source.changes [12:51] hmm, persia, is it the 1.2.9 package of subdownloader in REVU conflicting with my 2.0.8 uploaded? [12:51] ivangarcia, Nope. It's that login is broken. [12:51] (or at least, your login is broken) [12:52] hmm, how can only mine? :-) i hope they haven't put an if user==capiscuas to me [12:52] to show that error [12:53] well, persia, I hope they fix it soon, by the way, can anybody delete that subdownloader 1.2.9 package uploaded long time ago? [12:53] ivangarcia, I doubt it's just you. I have sufficient access to discover the problem, but not enough to fix it (and don't really understand the code anyway). You'll have to wait for a REVU Hacker to look at the traceback and fix it, or look at it yourself, and file a patch. [12:54] No need to delete the old package. The new package will show up anyway. Nice to see different approaches to packaging anyway, and provides a pointer to someone who might help you if you would like a hand. [12:59] persia, can u login to revu ? or nobody can [13:03] ivangarcia, I just logged in without any issues. I suspect it's new accounts that can't log in. [13:03] persia: I also was able to login with no issues [13:05] persia: going out for few hours. If there any tasks left related to java till then drop me a message. [13:06] slytherin, Should be fine : most of the big stuff is done, and Java didn't make first-class for intrepid anyway : at least what is there is a *huge* improvement over hardy. [13:06] ScottK: pardon? [13:09] persia: yes we will make java rock in jaunty and then rename jeos as java enterprise os :-P [13:10] heh. [13:14] sebner: Bug 289297 says it's broken and useless. After your sync's is that still true? [13:14] Launchpad bug 289297 in ogle "I nominate ogle for immediate removal from Ubuntu repositories." [Undecided,New] https://launchpad.net/bugs/289297 [13:14] ScottK, mind looking at bug 289459? Fixes an RC bug and should be trivial enough to pass [13:14] Launchpad bug 289459 in sendxmpp "Please sync sendxmpp 1.14-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/289459 [13:14] sebner: Please mark in the bug. [13:14] * ScottK looks [13:15] DktrKranz: It looks like the RC bug fix is in the NMU Prior. If the new upstream isn't clearly a small bugfix release, the NMU diff should be cherrypicked. [13:16] I think new upstream is just that [13:16] OK [13:16] I thought Laney said the new upstream was just the application of the proposed Debian patch. [13:16] persia: so you are taking care of fop right? [13:16] He said bugfixes. [13:16] Ah. [13:16] slytherin, Yep. [13:17] DktrKranz: If it's bugfix only, your ack is enough. [13:17] Gotta run. [13:17] slytherin, Well, I'm reviewing it. Looks like you still need motu-release approval for the upload. [13:18] persia: IIRC, ScottK already gave approval few days ago. I was discussing the bug with geser then and he asked me to verify the fix. [13:18] slytherin, Unless it's different than bug #268930 [13:18] Launchpad bug 268930 in fop "FOP fails with java.lang.ClassNotFoundException: org.w3c.dom.svg.SVGDocument" [Undecided,Confirmed] https://launchpad.net/bugs/268930 [13:19] persia: that is the bug I am talking about [13:19] I don't see M-R approval. [13:19] ScottK, Can you confirm the approval on that bug? Assuming it tests OK, I'd like to upload. [13:20] persia: me has to go. if it is not done by the time I return I will chase it with help from geser. [13:28] slytherin, At this point, sponsoring isn't your primary blocker. [13:28] persia: Done [13:29] ScottK, Thanks. [13:29] Leaving [13:29] slytherin, I'll probably upload in the next 30 minutes. [13:29] Have a good day ScottK [13:30] All : if you get IRC approval from motu-release, please paste to the bug for the benefit of posterity. [13:37] ScottK: the last sync just prevent a FTBFS. I still support the removal (outdated, upstream dead, alternatives). Should I add a comment or is it enough that I told it to you /here? [13:39] sebner, You believe not only that it's broken, but that it's unfixably broken? [13:40] persia: it isn't broken. the last upstream release was 5 years ago and we have plenty of *not* dead alternatives [13:42] sebner, There are programs I use several times a week that meet that description. Packages should at least be broken or known dangeously buggy to be removed. [13:43] persia: well, I have a different opinion but nvm then [13:44] sebner, Well, if you could point at a bug that made it hard to maintain, or broken for users, or something, I'd support removal. I'm all for dropping cruft. I just don't believe that packages become useless just because they are old, or because upstream is inactive. [13:45] sebner, When you say "it's not broken", that immediately makes me question the value of removal. What problem is solved by removing it? [13:45] persia: sure old packages aren't useless but 5 years is heavy (at least for me)... It seems also Debian is thinking of that .. security -> debian 496425 [13:45] Debian bug 496425 in ogle "The possibility of attack with the help of symlinks in some Debian packages" [Grave,Open] http://bugs.debian.org/496425 [13:46] persia: and in debian BTS you can see: doesn't support, please implement ,.. [13:46] sebner, An open security bug on a package that is dead upstream and nobody offering to fix it would be grounds for removal in my book. Security is important. [13:46] That's different from a package just being old. [13:47] There are hundreds of packages in Ubuntu that have not been uploaded since the archive was made public. Some of these are fairly useful packages, but don't need any work, because they aren't broken. [13:48] persia: ok ok [13:48] If any of these packages get bugs, the bugs should be fixed. If it is determined that a bug is critical and unfixable (nobody knows how or cares enough to fix it, including upstream), then the package becomes a candidate to be dropped, as a means of fixing the bug. [13:49] That it still has a Debian maintainer (hasn't been orphaned) is one of the things that makes me thing someone might care. [13:49] persia: I see, if Debian Maintainer is still active (He hasn't answered on the bug reoprts for a while) I'll talk to him about the removal [13:50] Right. If he wants to maintain it, then there's someone interested, and it should be kept (as long as he can maintian it). [13:50] persia: but you know ... release release release [13:51] Yes, but release doesn't mean we stop fixing bugs : that's why we have an SRU process. Plus, you tell me this package isn't broken, so I fail to see how it's important for release. [13:52] persia: but we can't remove packages after release. and we still don't know if it's activily maintained or not (also if it's not orphaned yet) [13:52] sebner, Yes, but if the package isn't broken, what's the point of removal? [13:53] persia: security [13:53] sebner, as the MOTU SWAT team told you they won't work on this? [13:53] has the security issue been raised to MOTU SWAT for consideration? [13:54] persia: /me is overasked. ScottK just told me to say something. Anyway I'm writing a mail to the debian maintainer [13:55] sebner, OK. I'm just asking lots of questions because I don't see any convincing rationale, and I don't see any unfixable bugs. [13:56] persia: I see, /me wasn't used to it yet ^^. However, I inform you what the Debian Maintainer replied (if he does) [13:56] sebner, No need to inform me. If the maintainer decides to remove, just link the Ubuntu removal bug to the Debian removal bug. If the maintainer doesn't want to remove, appropriately triage the Ubuntu removal bug :) [13:57] persia: and if he doesn't answer? :) [13:58] sebner, Well, then we go back to my other questions. If there is an unfixable bug, or it's otherwise known buggy, I don't have an issue with removal. [13:58] what's the fix for that /tmp problem ? Using a tmp inside the user's home dir ? [13:58] I just don't want to start removing stuff because upstream is inactive, as then I'll be surprised one day because someone removed something I use, for which the alternatives aren't quite right. [13:58] DktrKranz: Can you subscribe the archive to bug [13:58] bug #289459? [13:58] Launchpad bug 289459 in sendxmpp "Please sync sendxmpp 1.14-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/289459 [13:59] joaopinto, or using a tmpfile library that doesn't hardcode paths, and makes sure it's safe to use the file before using it. [13:59] persia: I totally understand (though there are lots of alternatives with more feature :P). However we'll see what happens. thx for teaching me :) [14:00] sebner, In this case, I suspect that removal is probably correct, but there might be a couple features that ogle has that others don't have that are interesting. I remember that it worked well over VNC last time I played with it (maybe 6-7 years ago) : dunno if it still does, but I think a lot of the others use video accelleration, and might not work as well over VNC. [14:01] persia: ok === Igorot is now known as ManyakisAko === ManyakisAko is now known as Igorot [14:18] DktrKranz: I'm nervous about virtualbox. I think we need a serious plan for watching it/SRU if we do it. [14:24] Back later. [14:24] my main doubt is what "support ubuntu 8.10" means, if that prevents users from running it, I'm fine with it [14:26] Laney, done [14:33] erm, libcups.so.2 is missing from ia32-libs [14:41] persia: Would you please look at Bug 275688? The bug discussion raises some licensing questions I'm not in a position to investigate. [14:41] Launchpad bug 275688 in fpc "Please sync fpc 2.2.2-3 (universe) with patch from bug #260464" [Wishlist,Incomplete] https://launchpad.net/bugs/275688 [14:42] Or any other motu with some bandwidth to look into it .... [14:42] Back later. [14:48] Regarding 275688 : I'm not sure what to do. It needs a method to notify the users of the licensing issue, and potentially has viral impact on all rdepends. [14:49] I'm tempted to defer to SRU because of the rdepends testing requirements, and look at the new upstream to avoid the issue, rather than trying to force through all the packages now (even with just licensing changes) and hope for the best, but this might have other implications. [14:50] Given that the issue also affects dapper, gutsy, and hardy, I don't see much advantage to rushing. [14:51] * persia wonders when feisty will not only be officially not supported, but no longer show in rmadison [14:51] Anyone from motu-SRU have an opinion on that strategy? [14:51] ? don't we accept upstream bugs anymore? [14:52] elmargol, What do you mean? [14:52] Bug #289403 [14:52] Launchpad bug 289403 in kdegraphics "/usr/lib/pkgconfig/libkdcraw.pc contains wrong version number" [Undecided,Invalid] https://launchpad.net/bugs/289403 [14:56] elmargol, Well, complain to the KDE Desktop triage team. Both GNOME and KDE Desktop triage teams tend to ask people to file upstream because they are pulling from upstream directly, and don't typically have time to do all the linking and bug forwarding stuff that are done in other areas. [14:56] elmargol, Mind you, the best way to complain would be to offer to perform this function :) [14:57] I just don't care that much.. If they don't like my input. I just stop filling kde related bugs [14:57] elmargol, Well, for bugs in core GNOME or KDE, it's just best to file upstream, until the teams have the time to actually care about launchpad. [14:58] Someone needs to track the upstream bugs, and track when they get closed in Ubuntu, and it's a lot of work, and nobody seems to want to do it. [14:58] As a result, there are lots of invalidations like that one. [15:03] devfil_, jdong DktrKranz : any issues with me deferring bug #275688 to SRU? My understanding is that it needs a fresh upload and recompile of all rdepends, or review and possible relicensing of all rdepends, plus user notification that only GPL binaries can be produced by fpc. [15:03] Launchpad bug 275688 in fpc "Please sync fpc 2.2.2-3 (universe) with patch from bug #260464" [Wishlist,Incomplete] https://launchpad.net/bugs/275688 [15:03] Fix for Jaunty would be new upstream and rdepends recompile, so it's not a case of pulling the fix from the current dev release. [15:04] persia: ok, I think then we should do the old Jaunty fix, then copy to Intrepid like we did for azureus and friends [15:04] I have no objection to it [15:05] !jdong [15:05] jdong: yes, but you're FULL OF CRACK! [15:05] :) [15:05] You really want to copy-back 2.2.2 to everywhere, rather than just adding licensing notes? [15:06] It's certainly easier, but it's a *huge* testing burden. [15:10] is it just licensing? [15:11] I was under the understanding that fpc was a bit broken throughout [15:14] That bug is that anything compiled by fpc must be released under the GPL, which may or may not be true for the current archive. [15:15] Further, users aren't notified of this, and so may be using fpc to ship violating code. [15:16] I'm not sure whether it's better to fix fpc in the old releases to be capable of compiling non-GPL code, or just to notify users. [15:16] I'm also not sure if the current set of packages built with fpc is all GPL : if there's anything non-GPL there, we're in violation, and need to either relicense the package, or recompile with a non-viral fpc. [15:20] persia, we could backport 2.2.2 to Intrepid, although I dunno how much a help that will be. *isn't completely clear on the licensing issue ATM* [15:20] NCommander, backports would be useful, but don't help the bug. [15:21] persia, well, we could move from backports to proposed to updates. Its been done before (clamav) [15:21] NCommander, That's what jdong proposed above, leading to me asking the bot to quote hobbsee [15:22] oh [15:22] soryy [15:22] * NCommander is a little decaffinated [15:22] * Elbrus reported bug 275688, but has trouble understanding the problem at the moment (apart from the freeze). [15:22] Launchpad bug 275688 in fpc "Please sync fpc 2.2.2-3 (universe) with patch from bug #260464" [High,Confirmed] https://launchpad.net/bugs/275688 [15:23] Elbrus, which problem are you having trouble understanding? [15:23] Elbrus, updating the package to 2.2.2 breaks the ABI, we need to rebuild all its depenedencies and test [15:23] We release in 4 days, there simply is not enough time [15:23] what can I do to help? [15:24] persia: about the license... upstream changed it? [15:24] Elbrus, First, check the packages that are built with fpc : make sure they are all GPL. If not, we need to chase those. [15:24] Elbrus, we can't do anything at the moment, but what I think we're planning to do (persia/jdong, correct me if I'm strong) is state the transition as a backport [15:24] Elbrus, we need loads of testers and sometimes porters when doing that [15:24] Elbrus, upstream changed the license for a library that packages built with fpc link against. [15:25] persia: IIUC they did that because the original library was not free, right? [15:25] NCommander, We can do investigation. There's no need to push 2.2.2 back to earlier releases if there are no non-GPL rdepends : we can just add a note for users warning them of the issue. [15:25] persia, oh, its only non-GPL rdepends that are affected? [15:25] * NCommander missed that bit [15:25] Elbrus, My reading was that the original library was GPL, and didn't have any exceptions allowing users to link against it for non-GPL code, so that anything compiled with fpc < 2.2.2 *must* be GPL. [15:26] NCommander, Any non-GPL rdepends are violating the fpc < 2.2.2 license. [15:26] persia, ick. Yeah, thats a bug [15:27] NCommander, Indeed, but it might not require the backports model to fix : it depends on the rdepends. [15:28] persia, that would be nice if so [15:29] NCommander, Well, it still needs a notification update to users of some sort. I don't even know how we would announce that sort of thing. [15:30] Stick it in the release notes [15:31] Maybe we can simply get upstream to retroactively release the library with a linking exception [15:39] NCommander, Um. no. That's not going to be possible. upstream cleanroom-reimplemented the affected code because it couldn't be relicensed. [15:39] persia, oh, shoot. NM [15:39] Also, putting it in the release notes doesn't help dapper, gutsy, or hardy users. [15:53] persia, point taken ;-) [15:57] persia, assuming there are license incompabilities and such, I take it we're probably going to want to backport and release to gutsy, hardy, and intrepid? (in reverse order) [15:58] NCommander, please read my comment from 30 minutes ago. [15:58] Right, but I'm assuming if the rdepends have license incom- .... ya know, its too early for me to think about liceneses [16:00] Also, it depends on the nature of the license incompatibilities : it might be less invasive to relicense one of the rdepends (e.g. ISC -> GPL) rather than do a backport. Needs investigation. [16:07] * Elbrus is trying to find the build-depend packages, but wonders if he needs more than the reverse depends shown by apt-cache showpkg? [16:09] Elbrus, the best way to find rdepends ona compiler is check the depends of the compilers runtime library [16:09] (which happens to also be the list of packages that are linked against the offending code) [16:10] in this case, would that be fp-units-rtl? [16:12] hrm, can somebody push wbxml2_0.9.2-5 into intrepid? [16:12] Elbrus, I think so. [16:12] azeem, Which bug? [16:13] well, Debian bug #487217, which makes libsyncml fail for most or all bluetooth mobiles [16:13] Debian bug 487217 in libwbxml2-0 "libwbxml2-0: Several SyncML flaws" [Important,Closed] http://bugs.debian.org/487217 [16:14] also #297939 [16:14] eh [16:14] also #287838 [16:15] hmm, imapcopy build depends on fp-compiler, but doesn't show up in the depends. [16:16] azeem, How are these related? [16:16] persia: disregard #297939 [16:16] that was a typo [16:17] Ah.. You meant bug #267397 ? [16:17] Launchpad bug 267397 in wbxml2 "Sync package with debian" [Undecided,New] https://launchpad.net/bugs/267397 [16:17] well, was saying that Debian #487217 is also in LP as #287838 [16:17] Debian bug 487217 in libwbxml2-0 "libwbxml2-0: Several SyncML flaws" [Important,Closed] http://bugs.debian.org/487217 [16:18]