[00:03] <Hobbsee> 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] <NCommander> :-)
[00:12] <RainCT> NCommander: damn, you've got a better Firefox :)
[00:16] <ethana2> my friend bought a plushie
[00:16] <ethana2> we were considering lighting that on fire too but mozilla relented on the eula thing
[00:16] <ethana2> ;)
[00:16] <RainCT> heh
[00:17] <ethana2> 'cuteness guaranteed' by Mozilla
[00:17] <ethana2> he thought that was amusing
[00:18] <RainCT> 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] <RainCT> anyway, /me is going to bed
[00:20] <Hobbsee> RainCT: you'd have thought they'd be beyond that....
[00:22] <ethana2> heh, they're just jealous
[00:22] <RainCT> Hobbsee: heh well, but beside that they are good guys :)
[00:22] <Hobbsee> RainCT: that's true
[00:22] <ethana2> http://www.google.com/trends?q=apple%2C+ubuntu%2C+fedora%2C+suse%2C+debian
[00:22] <ethana2> look at that google trends graph; it says something and it says it very clearly
[00:24] <ethana2> http://i34.tinypic.com/24lsy38.png
[00:24] <RainCT> 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] <ethana2> any thoughts on that screenshot, by the way?
[00:26] <RainCT> (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] <ethana2> ..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] <RainCT> ethana2: what's with that screenshot?
[00:28] <RainCT> ah ok
[00:28] <ethana2> eliminating redundancy really boosts elegance
[00:28] <ethana2> 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] <ethana2> i use alt+f4 now, but obviously the window controls belong on the window
[00:30] <ethana2> ..I have a close button in the firefox menu/tool bar thingy
[00:30] <ethana2> but other apps aren't that configurable
[00:30] <ethana2> http://i35.tinypic.com/inbix2.png -- that's my firefox
[00:31] <RainCT> 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] <ethana2> the app should pass the menu to the window manager
[00:31] <ethana2> like in osx, i think
[00:31]  * NCommander still perferred Firefox when it was called Phoenix
[00:31] <ethana2> same with toolbars and such...  i don't know, still thinking about all that
[00:31] <ethana2> i want a window decorator that just draws stuff right over the window
[00:32] <ethana2> ugly, but otherwise it might take too long
[00:32] <ethana2> hack it first, rework it later
[00:32] <RainCT> uhm.. you put pidgin on top of firefox :P
[00:32] <ethana2> that corner just has a little power icon in the toolbar that closes it
[00:33] <ethana2> i took these earlier, just had the links handy
[00:33] <RainCT> oh ok
[00:33] <ethana2> 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] <RainCT> well, I'm really leaving now (I've to get up in 7 hours :P)
[00:33] <ethana2> oh, ok, good night
[00:34] <RainCT> (well, now that I think about it that's the same amount of time as I usually sleep, but it's sunday :P)
[01:35] <slangasek> superm1: reply given on bug #288294
[01:23] <ScottK> Hobbsee: You're welcome.
[01:24] <Hobbsee> ScottK: didn't think they'd need a FFe, as it was a bugfix, but :)
[01:25] <ScottK> We're into the all uploads should be discussed phase.
[01:25] <Hobbsee> oh yes, that's true.
[01:26] <Hobbsee> i haven't quite got it into my brain that we've actually released the RC yet.
[01:26] <Hobbsee> i've got the "we release on teh 30th" part
[01:26] <Hobbsee> but not the other
[02:11]  * ScottK notes that there are motu-release approved uploads in the UUS queue needing sponsorship.
[02:33] <ScottK> sebner: What are your feelings on Bug 289297?
[02:38] <stgraber> weird, I remember it working in Hardy
[02:38] <stgraber> unfortunately I don't have any DVD around to make sure of that
[02:40] <ScottK> sebner did two NMU's in Debian, so I suspect he'll know.
[07:07] <elmargol> where do I find delted packages? (deleted from the repository)
[07:58] <iulian> elmargol: Is this what you're looking for: http://people.ubuntu.com/~ubuntu-archive/removals.txt ?
[07:59]  * iulian yawns!
[08:02] <elmargol> iulian: i found it thx anyway
[08:03] <elmargol> somehow my package can not find libkdcraw  :(
[08:05] <iulian> That's weird - http://packages.ubuntu.com/source/intrepid/libkdcraw
[08:05] <elmargol> PKG_CHECK_MODULES(Kdcraw libkdcraw>=0.4.0)
[08:05] <elmargol> somehow that check does not work
[08:07] <iulian> elmargol: I don't see that version but 0.1.4
[08:08] <iulian> Morning RainCT.
[08:08] <elmargol> pool/main/k/kdegraphics/libkdcraw5_4.1.2-0ubuntu3_i386.deb
[08:10] <geser> elmargol: have you the correct -dev package in build-depends?
[08:10] <elmargol> libkdcraw-dev yes
[08:11] <geser> then you need to check which files the test excepts and why it fails
[08:11] <elmargol> https://launchpad.net/ubuntu/intrepid/+source/digikam-kde4/0.10.0~beta1-0ubuntu3 <- thats the source
[08:16] <geser> elmargol: is it worth fixing it as it got removed from intrepid?
[08:17] <elmargol> I'm not trying to fix it. I want to use the application
[08:17] <elmargol> they removed it from intrepid because it is a beta... and the version was outdated
[08:19] <geser> the old debs from LP don't work anymore?
[08:19] <elmargol> they doo... i try to build beta4... this is beta1
[08:19] <geser> ah
[08:29] <geser> elmargol: have you pkgconfig installed?
[08:30] <elmargol> pkg-config
[08:32] <geser> elmargol: look inside /usr/lib/pkgconfig/libkdcraw.pc and file a bug :/
[08:33] <geser> Version: 0.2.0-svn
[08:33] <elmargol> ok
[08:35] <geser> I didn't check if libkdcraw.pc has a bug or if libkdcraw is really just 0.2.0-svn
[08:58] <elmargol> geser: Bug #289403 can you confirm this please
[09:07] <elmargol> mmkay digikam beta4 does not work anyway since it need some deps from kde4.2
[09:07] <elmargol> guess i have to wait 6 months
[09:12] <sebner> ScottK: I synced it so no NMU. The Debian Maintainer accepts patches but the project really seems dead though
[09:13] <sebner> DktrKranz: morning =)
[09:13] <DktrKranz> hello sebner
[09:51] <RainCT_> hi iulian :)
[09:52] <RainCT_> (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] <slytherin> Can anyone tell me why powerpc does not have 2.6.27 kernel?
[10:03] <persia> 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] <slytherin> this is bad. :-( I just updated my laptop to realize the latest kernel is not there.
[10:04] <persia> slytherin, The 2.6.25 kernel should work with intrepid.  Do you know of any specific regression?
[10:05] <slytherin> no, nothing specific.
[10:05] <persia> 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] <slytherin> 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] <persia> heh.
[10:08] <persia> 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] <slytherin> persia: IIRC, the default-jdk on powerpc is openjdk as it is in better shape than cacao
[10:10] <persia> Oh, cool!  I missed that change.
[10:11]  * slytherin takes a break for about 20 minutes.
[10:19] <RainCT_> 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] <persia> RainCT, What package do I need to install to get that file?
[10:19]  * Hobbsee grabs it
[10:20] <RainCT_> persia: software-properties, it should be installed by default on Ubuntu
[10:20] <Hobbsee> RainCT_: http://pastebin.com/f60b56676
[10:20]  * persia is glad Hobbsee is grabbing it, as it saves investigation :)
[10:20] <RainCT_> thanks :)
[10:20] <Hobbsee> persia: pastebinit ftw!
[10:21] <persia> Hobbsee, Having a system that consists of something other than an onionshell of chroots helps too :)
[10:21] <Hobbsee> persia: that's true.  is your main machine not intrepid yet?
[10:22] <persia> 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] <Hobbsee> right
[10:44] <marcin_ant> hi all
[10:47] <marcin_ant> 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] <persia> 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] <marcin_ant> persia: ok, but anyway maybe I should learn how to set variables properly....
[10:49] <persia> although, considering that fdupes is run during the liveCD generation process, I'm not sure why we do that.
[10:49] <marcin_ant> persia: CDBS_NO_DOC_SYMLINKING := yes or := true not working
[10:50] <persia> marcin_ant, Oh, sure.  Make has two variable types : those evaluated when the makefile is parsed, and those evaluated when used.
[10:50] <persia> You can set the first type with := and the second type with =
[10:51] <persia> 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] <marcin_ant> persia: in debhelper.mk (cdbs rule) there is: 	[ -n "$$CDBS_NO_DOC_SYMLINKING" ]
[10:51] <persia> 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] <persia> marcin_ant, Which checks for nonzero length, so "yes", "true", and "chickens" should all be valid values.
[10:53] <marcin_ant> persia: with = or := ?
[10:56] <ivangarcia> I'm trying to upload revu, but i have GPG problem
[10:56] <ivangarcia> I created my source .deb and .changes by doing dpkg-buildpackage -uc -us -I.bzr -Idebian -Ipyc -Idistribution  -S -sa -rfakeroot
[10:57] <ivangarcia> but then sudo dput revu subdownloader_2.0.7_source.changes
[10:57] <ivangarcia> Checking Signature on .changes
[10:57] <ivangarcia> gpg: WARNING: unsafe ownership on configuration file `/home/yen/.gnupg/gpg.conf'
[10:57] <ivangarcia> gpg: no valid OpenPGP data found.
[10:57] <ivangarcia> gpg: the signature could not be verified.
[10:57] <ivangarcia> Please remember that the signature file (.sig or .asc)
[10:57] <ivangarcia> should be the first file given on the command line.
[10:57] <ivangarcia> how can I do?
[10:57] <StevenK> You should not be running dput under sudo
[10:57] <marcin_ant> persia: it doesn't want to work at all
[10:58] <ivangarcia> StevenK, it says the same without it
[10:58] <StevenK> ivangarcia: -Idebian is also a bad idea
[10:58] <StevenK> ivangarcia: "gpg: no valid OpenPGP data found." == means you didn't sign your .changes
[10:59] <persia> That comes from the -uc.  The -us is also likely to cause issues for an upload.
[10:59] <ivangarcia> how can I sign then? my changelog file in debian has correct signature
[10:59] <persia> marcin_ant, You probably have to define it with := before the includes, but as I said before, don't do that.
[10:59] <StevenK> When it says signature, it means OpenPGP signature, not e-mail signature
[11:00] <ivangarcia> Stevenk, how to force him to ask me for GPG signature when creating the .deb ?
[11:01] <persia> ivangarcia, Instead of your complicated line, use debuild -S -I -i
[11:01] <ivangarcia> hmm, now i added a new version into my changelog and it asked me for the GPG key
[11:02] <ivangarcia> persia, but I want to exclude few folders to not get inside the .deb, how to do?
[11:02] <persia> ivangarcia, That's what the -i -I does.
[11:02] <StevenK> No it doesn't
[11:03] <persia> Yes it does.
[11:03] <StevenK> -I and -i exclude folders from the source tarball. This may also exclude from the .deb, but it's side-effect
[11:03] <persia> Oh.  It's a side effect I've used previously then :)
[11:06] <ivangarcia> persia, so I have to specify the folders I want to exclude by doing -Ifolder1 -Ifolder2/subfolder3 ?
[11:06] <persia> ivangarcia, Apparently that doesn't reliably work (or at least that it works isn't a specifically intended feature).
[11:06] <slytherin1> 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] <persia> slytherin, Hmm.  libdrm changes maybe?
[11:07] <ivangarcia> persia, so in which file can I specify the subfolders that I don't want to be included inside the .deb ?
[11:07] <slytherin1> persia: Not sure. As I said I was having problem even before upgrade i.e. in hardy.
[11:08] <geser> ivangarcia: which folders are you wanting excluded from the source package?
[11:08] <persia> 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.
[11:11] <ivangarcia> 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
[11:16] <sebner> persia: ehm, got my mail? ^^
[11:17] <ivangarcia> persia, i succeded to upload to REVU, but just the .tar.gz, is that normal ? not .deb was created
[11:17] <geser> ivangarcia: you should only upload <pkg>_source.changes to REVU
[11:18] <geser> ivangarcia: you want those folder excluded from the source package? why?
[11:19] <persia> sebner, Dunno how to help you with that.  I don't really understand the package.  What specifically are you trying to accomplish?
[11:19] <ivangarcia> 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] <persia> 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] <ivangarcia> let me check some help of how to do the get-orig-source
[11:25] <persia> https://wiki.ubuntu.com/PackagingGuide/Basic#Changing%20the%20Original%20Tarball
[11:29] <slytherin1> persia: sample file attached to fop bug with instructions for conversion. :-)
[11:32] <persia> slytherin1, Excellent.  I'll take a look at that in a bit.  You've verified the fix?
[11:33] <slytherin1> 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] <persia> slytherin1, Even better!
[11:35] <sebner> persia: fixing the package ^^, however I'll talk to james_w then
[11:36] <persia> 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] <sebner> 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] <persia> sebner, OK.  Good luck.
[11:38] <sebner> thx ^^
[11:49] <marcin_ant> 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] <persia> 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] <ivangarcia> hello persia, my REVU is uploaded, what is the formal/educated procedure to ask reviewers to test it?
[12:02] <ivangarcia> it's named subdownloader_2.0.8
[12:03] <marcin_ant> persia: ok
[12:09] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497829 is good for an SRU, right?
[12:11] <persia> 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] <ivangarcia> persia, how to know the url of the REVU? the command doesn't give me any
[12:12] <slytherin> 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] <persia> Laney, Yep, unless you can cherrypick a smaller patch.
[12:13] <persia> 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] <persia> ivangarcia, Take a look at the REVU website.
[12:13] <slytherin> ok
[12:14] <Laney> I think that's the only fix in the upstream release, from the changes
[12:14] <persia> 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] <Laney> I guess I'll have a look
[12:28] <slytherin> persia: I put comment in text box and demoted antlr3. I was expecting that comment will be saved but it is not.
[12:30] <Laney> motu-release: bug #289459 needs looking at
[12:31] <persia> slytherin, You added the comment, clicked save, and pressed the green arrow and it deleted the comment?
[12:31] <slytherin> persia: No. I didn't click save. :-(
[12:32] <persia> slytherin, That's why it didn't save :)
[12:44] <ivangarcia> persian, it seems that http://revu.ubuntuwire.com/details.py?package=subdownloader
[12:44] <ivangarcia> it was uploaded by an old contributor
[12:45] <ivangarcia> but it's not the 2.0.8
[12:48] <persia> 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] <ivangarcia> hmm, the REVU login failes with a python error
[12:49] <ivangarcia> it tries to do an openid sign in from launchpad
[12:49] <ivangarcia> but when i click on Sign In, it redirects me to a python error
[12:49] <ivangarcia> i've reported the error to their REVU email.
[12:49] <ivangarcia> my key is on launchpad
[12:50] <persia> NCommander, Any chance you could look at that?
[12:50] <persia> RainCT : ivangarcia wins the prize.
[12:50] <ScottK> sebner: Does it work now?
[12:51] <persia> ivangarcia, Once you get login sorted, ask a REVU admin to requeue subdownloader_2.0.8_source.changes
[12:51] <ivangarcia> hmm, persia, is it the 1.2.9 package of subdownloader in REVU conflicting with my 2.0.8 uploaded?
[12:51] <persia> ivangarcia, Nope.  It's that login is broken.
[12:51] <persia> (or at least, your login is broken)
[12:52] <ivangarcia> hmm, how can only mine? :-) i hope they haven't put an if user==capiscuas to me
[12:52] <ivangarcia> to show that error
[12:53] <ivangarcia> 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] <persia> 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] <persia> 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] <ivangarcia> persia, can u login to revu ? or nobody can
[13:03] <persia> ivangarcia, I just logged in without any issues.  I suspect it's new accounts that can't log in.
[13:03] <nhandler> persia: I also was able to login with no issues
[13:05] <slytherin> persia: going out for few hours. If there any tasks left related to java till then drop me a message.
[13:06] <persia> 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] <sebner> ScottK: pardon?
[13:09] <slytherin> persia: yes we will make java rock in jaunty and then rename jeos as java enterprise os :-P
[13:10] <persia> heh.
[13:14] <ScottK> sebner: Bug 289297 says it's broken and useless.  After your sync's is that still true?
[13:14] <DktrKranz> ScottK, mind looking at bug 289459? Fixes an RC bug and should be trivial enough to pass
[13:14] <ScottK> sebner: Please mark in the bug.
[13:14]  * ScottK looks
[13:15] <ScottK> 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] <DktrKranz> I think new upstream is just that
[13:16] <ScottK> OK
[13:16] <persia> I thought Laney said the new upstream was just the application of the proposed Debian patch.
[13:16] <slytherin> persia: so you are taking care of fop right?
[13:16] <ScottK> He said bugfixes.
[13:16] <persia> Ah.
[13:16] <persia> slytherin, Yep.
[13:17] <ScottK> DktrKranz: If it's bugfix only, your ack is enough.
[13:17] <ScottK> Gotta run.
[13:17] <persia> slytherin, Well, I'm reviewing it.  Looks like you still need motu-release approval for the upload.
[13:18] <slytherin> 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] <persia> slytherin, Unless it's different than bug #268930
[13:19] <slytherin> persia: that is the bug I am talking about
[13:19] <persia> I don't see M-R approval.
[13:19] <persia> ScottK, Can you confirm the approval on that bug?  Assuming it tests OK, I'd like to upload.
[13:20] <slytherin> 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] <persia> slytherin, At this point, sponsoring isn't your primary blocker.
[13:28] <ScottK> persia: Done
[13:29] <persia> ScottK, Thanks.
[13:29] <ScottK> Leaving
[13:29] <persia> slytherin, I'll probably upload in the next 30 minutes.
[13:29] <persia> Have a good day ScottK
[13:30] <persia> All : if you get IRC approval from motu-release, please paste to the bug for the benefit of posterity.
[13:37] <sebner> 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] <persia> sebner, You believe not only that it's broken, but that it's unfixably broken?
[13:40] <sebner> persia: it isn't broken. the last upstream release was 5 years ago and we have plenty of *not* dead alternatives
[13:42] <persia> 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] <sebner> persia: well, I have a different opinion but nvm then
[13:44] <persia> 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] <persia> 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] <sebner> 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:46] <sebner> persia: and in debian BTS you can see: doesn't support, please implement ,..
[13:46] <persia> 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] <persia> That's different from a package just being old.
[13:47] <persia> 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] <sebner> persia: ok ok
[13:48] <persia> 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] <persia> 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] <sebner> 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] <persia> 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] <sebner> persia: but you know ... release release release
[13:51] <persia> 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] <sebner> 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] <persia> sebner, Yes, but if the package isn't broken, what's the point of removal?
[13:53] <sebner> persia: security
[13:53] <persia> sebner, as the MOTU SWAT team told you they won't work on this?
[13:53] <persia> has the security issue been raised to MOTU SWAT for consideration?
[13:54] <sebner> persia: /me is overasked. ScottK just told me to say something. Anyway I'm writing a mail to the debian maintainer
[13:55] <persia> 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] <sebner> persia: I see, /me wasn't used to it yet ^^. However, I inform you what the Debian Maintainer replied (if he does)
[13:56] <persia> 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] <sebner> persia: and if he doesn't answer? :)
[13:58] <persia> 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] <joaopinto> what's the fix for that /tmp problem ? Using a tmp inside the user's home dir ?
[13:58] <persia> 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] <Laney> DktrKranz: Can you subscribe the archive to bug
[13:58] <Laney> bug #289459?
[13:59] <persia> 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] <sebner> 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] <persia> 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] <sebner> persia: ok
[14:18] <ScottK-palm> DktrKranz: I'm nervous about virtualbox. I think we need a serious plan for watching it/SRU if we do it.
[14:24] <ScottK-palm> Back later.
[14:24] <DktrKranz> my main doubt is what "support ubuntu 8.10" means, if that prevents users from running it, I'm fine with it
[14:26] <DktrKranz> Laney, done
[14:33] <joaopinto> erm, libcups.so.2 is missing from ia32-libs
[14:41] <ScottK-palm> persia: Would you please look at Bug 275688? The bug discussion raises some licensing questions I'm not in a position to investigate.
[14:42] <ScottK-palm> Or any other motu with some bandwidth to look into it ....
[14:42] <ScottK-palm> Back later.
[14:48] <persia> 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] <persia> 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] <persia> 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] <persia> Anyone from motu-SRU have an opinion on that strategy?
[14:51] <elmargol> ? don't we accept upstream bugs anymore?
[14:52] <persia> elmargol, What do you mean?
[14:52] <elmargol> Bug #289403
[14:56] <persia> 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] <persia> elmargol, Mind you, the best way to complain would be to offer to perform this function :)
[14:57] <elmargol> I just don't care that much.. If they don't like my input. I just stop filling kde related bugs
[14:57] <persia> 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] <persia> 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] <persia> As a result, there are lots of invalidations like that one.
[15:03] <persia> 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] <persia> 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] <jdong> 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] <jdong> I have no objection to it
[15:05] <persia> !jdong
 jdong: yes, but you're FULL OF CRACK!
[15:05] <jdong> :)
[15:05] <persia> You really want to copy-back 2.2.2 to everywhere, rather than just adding licensing notes?
[15:06] <persia> It's certainly easier, but it's a *huge* testing burden.
[15:10] <jdong> is it just licensing?
[15:11] <jdong> I was under the understanding that fpc was a bit broken throughout
[15:14] <persia> 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] <persia> Further, users aren't notified of this, and so may be using fpc to ship violating code.
[15:16] <persia> 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] <persia> 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] <NCommander> 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] <persia> NCommander, backports would be useful, but don't help the bug.
[15:21] <NCommander> persia, well, we could move from backports to proposed to updates. Its been done before (clamav)
[15:21] <persia> NCommander, That's what jdong proposed above, leading to me asking the bot to quote hobbsee
[15:22] <NCommander> oh
[15:22] <NCommander> 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:23] <persia> Elbrus, which problem are you having trouble understanding?
[15:23] <NCommander> Elbrus, updating the package to 2.2.2 breaks the ABI, we need to rebuild all its depenedencies and test
[15:23] <NCommander> We release in 4 days, there simply is not enough time
[15:23] <Elbrus> what can I do to help?
[15:24] <Elbrus> persia: about the license... upstream changed it?
[15:24] <persia> 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] <NCommander> 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] <NCommander> Elbrus, we need loads of testers and sometimes porters when doing that
[15:24] <persia> Elbrus, upstream changed the license for a library that packages built with fpc link against.
[15:25] <Elbrus> persia: IIUC they did that because the original library was not free, right?
[15:25] <persia> 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] <NCommander> persia, oh, its only non-GPL rdepends that are affected?
[15:25]  * NCommander missed that bit
[15:25] <persia> 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] <persia> NCommander, Any non-GPL rdepends are violating the fpc < 2.2.2 license.
[15:26] <NCommander> persia, ick. Yeah, thats a bug
[15:27] <persia> NCommander, Indeed, but it might not require the backports model to fix : it depends on the rdepends.
[15:28] <NCommander> persia, that would be nice if so
[15:29] <persia> 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] <NCommander> Stick it in the release notes
[15:31] <NCommander> Maybe we can simply get upstream to retroactively release the library with a linking exception
[15:39] <persia> NCommander, Um. no.  That's not going to be possible.  upstream cleanroom-reimplemented the affected code because it couldn't be relicensed.
[15:39] <NCommander> persia, oh, shoot. NM
[15:39] <persia> Also, putting it in the release notes doesn't help dapper, gutsy, or hardy users.
[15:53] <NCommander> persia, point taken ;-)
[15:57] <NCommander> 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] <persia> NCommander, please read my comment from 30 minutes ago.
[15:58] <NCommander> Right, but I'm assuming if the rdepends have license incom- .... ya know, its too early for me to think about liceneses
[16:00] <persia> 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] <NCommander> Elbrus, the best way to find rdepends ona  compiler is check the depends of the compilers runtime library
[16:09] <persia> (which happens to also be the list of packages that are linked against the offending code)
[16:10] <Elbrus> in this case, would that be fp-units-rtl?
[16:12] <azeem> hrm, can somebody push wbxml2_0.9.2-5 into intrepid?
[16:12] <persia> Elbrus, I think so.
[16:12] <persia> azeem, Which bug?
[16:13] <azeem> well, Debian bug #487217, which makes libsyncml fail for most or all bluetooth mobiles
[16:14] <azeem> also #297939
[16:14] <azeem> eh
[16:14] <azeem> also #287838
[16:15] <Elbrus> hmm, imapcopy build depends on fp-compiler, but doesn't show up in the depends.
[16:16] <persia> azeem, How are these related?
[16:16] <azeem> persia: disregard #297939
[16:16] <azeem> that was a typo
[16:17] <persia> Ah..  You meant bug #267397 ?
[16:17] <azeem> well, was saying that Debian #487217 is also in LP as #287838
[16:18] <persia> bug #287838
[16:18] <persia> Anyone from MOTU-Release have an opinon on whether this is pre-release or SRU?
[16:19] <azeem> the patch is pretty well tested on Debian; while it has fixed libsyncml for quite a few people, we have not gotten any reports about regressions
[16:19] <azeem> sorry that fell through the cracks
[16:20] <persia> azeem, Well, these things happen sometimes, although it's unfortunate that it was missed for 10 weeks.
[16:21] <persia> At this point, it needs approval from the release team to be uploaded.
[16:21] <azeem> I understand
[16:21] <persia> After the release is compelted, it's probably a good candidate for SRU though : it's just a matter of determining when to do it.
[16:21]  * ScottK looks
[16:21] <azeem> mitsuhiko's issue reminded me of it
[16:22] <persia> mitsuhiko's issue is precisely the same thing.
[16:22] <azeem> yeah, reminded me as in, made me realize Ubuntu doesn't have the patch yet
[16:23] <ScottK> Will libsyncml0 need to be rebuilt?
[16:23] <azeem> no
[16:23]  * ScottK hasn't had time to readh the scrollback.
[16:24] <azeem> at least not AIUI
[16:24] <azeem> I think libwbxml2 sends garbage back or something, and the patch fixes it
[16:24] <azeem> the patch was written by the libsyncml upstream maintainer
[16:24] <ScottK> persia: If you concure the rdepends don't need a rebuild, then go ahead.
[16:25] <ScottK> concure/concur
[16:25]  * persia looks more carefully at the patch
[16:26] <ScottK> persia: I marked that in the bug, so all yours.
[16:28] <persia> Grumble.  It's another one of those annoying packages where the maintainer is doing different things in sid and lenny.
[16:29] <azeem> that'd be me :)
[16:29] <persia> azeem, Yes it would :)
[16:29] <azeem> the patch introduced in -6 seems to have caused some regressions, so I didn't push it into lenny
[16:29] <azeem> needs more investigation
[16:30] <persia> azeem, "patch"?  There's a huge chunk of changes in -6.
[16:30] <azeem> -5 should be used for Ubuntu, or the patch extracted
[16:30] <azeem> persia: well, I changed the patch system; I mean the one patch which got added on top
[16:30] <persia> I'm just reviewing now, but expect I'll ask for a sync of -5.
[16:30] <azeem> Debian #497709
[16:30] <persia> azeem, Right : it's the change of the patch system that makes it hard to review -6 quickly.
[16:31] <azeem> 17:26 < azeem> -5 should be used for Ubuntu, or the patch extracted
[16:31] <azeem> where "the patch" being the one from Debian #487217
[16:31] <persia> azeem, More generally, although I understand it's always better to have one's pet patch system, especially when taking over maintainership from another, I just think it's a risky sort of change close to release.
[16:32] <azeem> persia: actually, I just renamed the patches to have numbers in front
[16:32] <persia> Right.  487217 is the interesting bug to fix.
[16:33] <persia> Bother.  s/syncml/SYNCML/ is just an annoying thing to change for 11 -> 12.
[16:36] <persia> azeem, I don't see any changes that look ABI-dangerous.  I'll just do a bit of testing, and request a sync of -5.
[16:37] <azeem> persia: thanks
[16:38] <persia> azeem, Thanks for poking about it.
[16:39] <persia> azeem, I'm duping the bugs backwards only to keep the approval on the master bug.
[16:40] <Elbrus> bug 275688 mentions four rdepends, imapcopy is GPL-2+, hedgewars is GPL-2, libhdate is GPL-3+ and gearhead is LGPL-2+. So I guess the last one needs to be relicensed, right?
[16:40]  * Elbrus still has not found the way to FIND these (and more) rdepends...
[16:41] <Laney> FTBFS due to a library dependency being deleted: reason for updating now?
[16:41] <Laney> s/updating/syncing/
[16:41] <persia> Elbrus, Next check if anything is linked against gearhead.
[16:42] <Laney> (it has previously built in Intrepid)
[16:42] <persia> Laney, deleted in Debian, or deleted in Ubuntu?
[16:42] <Laney> persia: Both
[16:42] <persia> Which package?
[16:42] <Laney> gdis, previously depending on gtk+extra
[16:43] <Laney> There was a NMU in Debian to update the deps
[16:43] <persia> apt-cache show gdis doesn't show that dependency for me.  Does it show it for you?
[16:44] <persia> Might have been inadvertently fixed by warp10's recompile in May.
[16:46] <persia> azeem, Do you have an LP ID?
[16:46] <Laney> persia: Hmm. It still FTBFS though due to the build-dep
[16:46]  * azeem hides
[16:46] <azeem> persia: it's mbanck
[16:46] <Elbrus> gearhead is a role playing game that does not have any depends or reverse depends except it's own binaries
[16:47] <persia> Elbrus, OK.  Please report the state of the licenses, and the lack of rdepends of gearhead to the bug.  That will help the SRU team decide how they want to handle it.
[16:47] <Elbrus> persia: will do.
[16:48] <persia> azeem, Thanks.  I just want to add you to the sync bug so that if the archive admins have questions, you can answer them (as you're more familiar with the package than anyone else)
[16:49] <persia> Elbrus, And, now that the investigation is complete, it might be a good time to subscribe motu-sru, so they can decide whether they want to look at backporting or relicensing.
[16:50] <azeem> persia: k, thanks
[16:52] <Elbrus> persia: I can add motu-sru, but how do I make sure that I found all the build depends? As mentioned before, I still have not found a way to find the packages that build depend. They were mentioned in the bug report.
[16:53] <slytherin> Elbrus: if you are already running intrepid then use command reverse-build-depends
[16:53] <persia> Elbrus, grep-dctrl is the tool you want, although I forget the syntax today.
[16:53] <Elbrus> slytherin: thanks
[16:53] <Elbrus> turns up one extra package
[16:54] <persia> heh.  reverse-build-depends is just grep-dctrl wrapped in a bash script so people don't have to remember anything.
[16:54] <slytherin> persia: right, I stopped using grep-dctrl long time ago
[16:57] <persia> slytherin, Why?  You know it's a bit more flexible than reverse-build-depends, right?
[16:57] <slytherin> persia: Yes, but Most of the time All I need to find is reverse build dependencies. :-)
[16:57] <persia> Also, reverse-build-depends only checks for the contents of your current apt-cache, which may not be clean.  Running wget against archive.ubuntu.com, and piping the results into grep-dctrl is more accurate, and lets you check arbitrary architectures, etc.
[16:58] <persia> Yeah well.  Some of use don't update our apt-cache with every publisher run :)
[16:59] <persia> Anyone have a nokia phone and intrepid?
[16:59] <azeem> persia: mitsuhiko :)
[16:59] <persia> As much as I can test, bug #287838 looks good, but it'd be nice to have a real user test before we sync.
[17:00] <persia> azeem, Sure, but I'm not sure I trust mitsuhiko to also have an intrepid pbuilder or sbuild available to generate a clean binary.
[17:00] <marrow> Hi all
[17:00] <azeem> ah, I thought you had binaries lying around
[17:00] <persia> I have binaries, but no easy way to get them to anyone.
[17:00] <persia> (at least not in a trusted manner).
[17:01] <ScottK> persia: At this point I'd do an upload of the preferred package rather than request sync of an older version.
[17:02] <persia> ScottK, To avoid the chance of confusion?  OK.  I can do that.  You think simulated sync or ubuntu1?
[17:03] <ScottK> persia: I'd do ubuntu1
[17:05] <mitsuhiko> persia: just set up the system, not even build essentials :)
[17:05] <mitsuhiko> oh, and no time ^^
[17:06] <persia> mitsuhiko, I'm in UTC+9 : lack of time is purely imaginary.
[17:07] <mitsuhiko> heh
[17:07] <geser> persia: europe doesn't have more time than you have
[17:07] <persia> just having set up the system, and not being a regular Ubuntu developer is sufficient that I'm not going to tell you to test it though :)
[17:07] <persia> geser, No, but it's earlier in the day :)
[17:09] <NCommander> Does anyone know a good way to simulate a PPC (uploading a source package and getting binaries built automatically?)
[17:10] <slytherin> NCommander: what do you want to do on ppc?
[17:10] <NCommander> er, PPA
[17:10] <NCommander> d'oh
[17:11] <NCommander> slytherin, I want to generate linux-ports daily images
[17:11] <slytherin> NCommander: First clear my confusion please. Did you mean PPC (as in in powerpc) or PPA?
[17:12] <NCommander> slytherin, I'm trying to simulate a PPA so I can build PowerPC packages ;-)
[17:13] <slytherin> NCommander: I can build on my ibook. But It will take some time to setup pbuilder. I just upgraded to intrepid today.
[17:13] <NCommander> slytherin, no, I have the hardware, I'm trying to figure out a good way to do daily images for the ports kernel
[17:14] <NCommander> slytherin, that being said, I am looking for port kernel testers (yay for modern 2.6.27 kernels)
[17:14] <slytherin> NCommander: Bribe launchpad developers to add powerpc arch to PPA. :-D
[17:14] <slytherin> NCommander: I am up for testing.
[17:20] <slytherin> persia: now that openjdk is default on powerpc I hope we will not see any powerpc specific build errors in OOo.
[17:21] <persia> azeem, Does http://launchpadlibrarian.net/18922574/wbxml2-ubuntu.debdiff look reasonable to you?
[17:25] <persia> NCommander, falcon and deb-o-matic would both work, assuming you have a powerpc available.
[17:25] <NCommander> persia, cool. The one thing is I want to be able to have the binaries on one machine, and the builder be another
[17:25] <NCommander> (i.e., falcon would run on one box, and then I'd have powerpc/sparc/hppa/etc. builders elsewhere)
[17:26] <persia> NCommander, Haven't you previous experience with dak and wannabuild?
[17:26] <NCommander> persia, wanna-build and dak both requirement manual ACKing for binaries
[17:26] <persia> Dunno if either falcon or debomatic is designed for that kind of environment.
[17:26] <NCommander> Its not really what I'm looking for
[17:27] <persia> No, they require ACKing of binaries : there's no reason it can't be automated, as long as you don't care about the results.
[17:27] <NCommander> I might have to simply hack buildd to self-sign with a local GPG key, but I hate coding in perl, and working against GPG is evil
[17:27] <NCommander> persia, out of the box, there is no way to make it automatic, and my perl sucks
[17:27] <ScottK> persia: Is there a conclusion on bug 275688?
[17:27]  * NCommander was also hoping for something a little lightweight
[17:28] <persia> ScottK, It's SRU material.
[17:28] <ScottK> persia: Thanks for looking into it.
[17:28] <NCommander> I'm out to lunch
[17:28] <persia> ScottK, No problem.  Thank Elbrus who did most of the investigation.
[17:28] <ScottK> Elbrus: Thank you.
[17:29] <ScottK> NCommander: We know that.
[17:29] <ScottK> Sorry.  It had to be said.
[17:31] <persia> azeem, Could you confirm I've pulled the critical bit for bug #287838 please?
[17:31] <persia> Could someone with a Nokia phone please confirm that sync works?  I know the binaries work, but it's pointless to upload without a real test.
[17:32] <persia> (err, that sync works *with* the patch)
[17:33] <persia> Test case is just attaching your phone, and running msynctool with the updated wbxml2
[17:34]  * slytherin has to restart the machine
[17:44] <slytherin> persia: does the patch attached to bug 280679 look reasonable to you?
[17:45] <persia> slytherin, I don't really like the nested if.
[17:46] <slytherin> persia: so use case instead?
[17:46] <slytherin> wait, it will work without nested if
[17:47] <persia> How about if (icon_policy == ICON_POLICY_ALWAYS || (adapter_present = TRUE && icon_policy != ICON_POLICY_NEVER)) ?
[17:48] <slytherin> persia: yes that is what I was thinking about.
[17:48] <persia> s/ = / == /
[17:48] <persia> That makes it a one-line diff, and easier to understand the logic.
[17:49] <persia> Upstream wants that too :)
[17:49] <slytherin> persia: should I prepare debdiff, considering that it is package in main I doubt it will be accepted at this stage
[17:49] <persia> Ask in #ubuntu-motu if anyone considers it release critical.  I suspect it's SRU or Jaunty.
[17:50] <slytherin> it is certainly not critical
[17:50] <persia> If the answer is Jaunty, just push it upstream : they ought accept it fast enough that we don't need to carry a patch.
[17:50] <persia> Well, if you don't think it's critical, then just send it upstream :)
[17:51] <slytherin> persia: I am not in QA team so I can not mark the bug with low priority.
[17:51] <persia> slytherin, Ask someone in #ubuntu-bugs to set the priority
[17:52] <slytherin> ok
[17:52] <slytherin> persia: by the way, on my machine, file receiving is not working at all no matter what option I set. So I am not able to check if a simple gconf setting change is sufficient to make file receving work out of box.
[17:53] <persia> slytherin, Did it work in hardy?
[17:54] <slytherin> persia: Don't remember. I usually simply browsed the phone file system.
[17:55] <slytherin> persia: can you try it? I will tell you the gconf setting. If it works by simply changing the setting then I want to push it so that users don't have to install gnome-user-share for making it work.
[17:57] <persia> slytherin, Which setting?  Which bug?
[17:58] <slytherin> persia: setting is /apps/bluetooth-manager/receive_enabled bug I will have to hunt down
[18:01]  * NCommander glares at ScottK
[18:30] <slytherin> persia: got to go. Office tomorrow.
[18:30] <slytherin> persia: please don't forget to upload fop.
[18:33] <persia> The problem with Java is that it requires such a mess of stuff just to build source packages that it's just a pain to sponsor, especially because the specific mix of source packages required varies, so one always has to start from a clean schroot when building source, or the result can FTBFS.
[19:07]  * ScottK notes that language packs are about to hit, so if you've got something to upload, now's the time.
[19:10]  * NCommander ducks and covers
[19:14] <directhex> mono-basic lands in Unstable. huzzah.
[19:14] <NCommander> directhex, yay
[19:15] <directhex> i should remove it from revu.
[19:15] <directhex> debian got there first
[19:15] <NCommander> directhex, we can backport that to Intrepid/Hardy
[19:16] <persia> directhex, The package is "mono-basic"?
[19:16] <directhex> persia, aye
[19:16] <directhex> persia, well, the source package is.
[19:16] <persia> That's what I need to archive it :)
[19:16] <directhex> NCommander, intrepid, no worries. hardy, i dunno if mono-basic 1.9.1 will like hardy's mono 1.2.6
[19:17] <persia> NCommander, Did you see the issue earlier with a traceback trying to create a new REVU account?  Also, is it possible for REVU to remember who I am, rather than having to log in so often?
[19:17] <directhex> persia, ta. never wanted it to go in via revu really in the first place - just wanted to try & push the package *somewhere* before the freezefest started across distros
[19:17] <directhex> i failed, but nevermind ^_^
[19:17] <NCommander> persia, the later should have been fixed, and RainCT said he was working on the former
[19:18] <persia> NCommander, Well, it forgot me within a few hours.
[19:18] <persia> directhex, archived.
[19:18] <directhex> yay
[19:19] <directhex> of course, the irony is, who the hell wants a vb.net compiler in the first place? O_o
[19:19] <persia> Well, actually, perhaps someone will write a useful vb.net program.
[19:20] <directhex> i don't think anyone writing free software for linux would chose it as a language. but there's a lot of windows people who might be tempted to ubuntu if they can run their existing code, and continue to work on it
[19:21] <directhex> so it's a case where the compiler is the product for users, rather than the apps being made with it being the product for users
[19:21] <persia> I was actually thinking that some windows developer might write something interesting, and be willing to release it as free software rather than freeware after being asked nicely.
[19:22] <directhex> yeah, maybe
[19:22] <directhex> winforms ahoy :|
[19:22] <marrow> vb.net source can be compiled with mono, no?
[19:23] <directhex> marrow, with the vbnc compiler, sure.
[19:23] <directhex> marrow, where ubuntu has no vbnc
[19:24] <marrow> So with mono, only c# apps can be compiled?
[19:25] <directhex> marrow, there are a few CLI compilers in ubuntu. gmcs (c#) is one of them, vbnc (vb.net) is not
[19:27] <directhex> marrow, off the top of my head, i know ubuntu has CLI compilers for python, nemerle, java, boo, and c#
[19:28] <jdong> jscript :)
[19:29] <directhex> yes, jdong is right, that too
[19:30] <jdong> IIRC the blocker for vbnc was that for quite some time it was actually not buildable in Linux
[19:30] <jdong> there was some sort of hackery to use MS .NET framework to build one or two assemblies and inject them into the Linux build process
[19:30] <directhex> it's self-hosting now
[19:30] <jdong> yeah, now it is
[19:30] <directhex> so the package requires bootstrap binaries
[19:31] <directhex> but that's okay, or at least i heard no complaints from ftpmaster@debian
[19:31] <directhex> and joerg is usually pretty much a hardass on these things
[19:31] <persia> directhex, You still have bootstrap binaries?  I'd think that once you had it built, you'd want to upload a new version that build-depended on itself and didn't have bootstrap binaries.
[19:32] <jdong> I think the important thing to point out is VB.NET assemblies compiled on Windows / MS .NET will run on Mono if it's compatible...
[19:32] <jdong> I think the #1 usecase for VB.NET + Mono is Windows codebases that used Vb.NET
[19:32] <directhex> persia, frowned upon in debian iirc, since you can't rebuild the archive from scratch
[19:32] <persia> directhex, Hrm.  But gcc, ghc6, ...
[19:34] <directhex> persia, file a bug in debian if you're concerned about it. i just went with what i was told to
[19:35] <persia> directhex, I'm not very concerned - it's just that the practice as explained to me was different than the practice as explained to you.  Since your explanation is probably more recent, it has a better chance of being more accurate today.
[19:35] <pangloss> So, I have a question, though im not sure this is the right place for it. When 8.10 comes out, will there be significantly less people working on 8.04?
[19:36] <directhex> persia, you hear 10 different things when asking questions :)
[19:36] <directhex> pangloss, define "working on"
[19:36] <pangloss> fixing bugs
[19:36] <pangloss> triaging
[19:36] <persia> pangloss, The majority of people who stopped working on 8.04 did so when 8.10 opened for work, not when 8.10 releases.
[19:36] <pangloss> Ah
[19:37] <directhex> personally i'm waiting for 9.04 to open! sod 8.10
[19:37] <persia> pangloss, Some other people didn't stop until around 8.04.1, but many of them (and probably some others) will probably do some work towards 8.04.2 once 8.10 releases, so the number might even go up.
[19:37] <pangloss> Does that seem to be a significant problem? For instance, are there a lot of bugs that never get fixed in the older versions?
[19:37] <persia> directhex, that's just because nobody is going to approve any of your uploads before archive close :)
[19:38] <persia> pangloss, There are thousands of bugs that never get closed in older versions.
[19:38] <persia> There's no specific goal to close them all : only critical bugs get closed in released versions.
[19:38] <directhex> persia, i wouldn't expect them to. i know what "freeze" means
[19:38] <pangloss> persia, right, forgive my niavity
[19:38] <directhex> pangloss, sometimes fixing a bug is dangerous - what if your fix suddenly changes the way workarounds people have been using for months behave?
[19:39] <persia> directhex, And you've gotten stuff mostly in shape that you're not chasing loose ends for your packages.
[19:39] <directhex> pangloss, a "stable release" is meant to, well, not change. that even means bugs, excluding "it just doesn't run 'cos we messed up" bugs and security bugs
[19:39] <jdong> pangloss: fixing bugs post-release can be a risky endeavor..  typically we only try to nab the risk-free or high-impact ones after release
[19:39] <persia> pangloss, Nothing to forgive : everyone has to learn sometime.
[19:39] <jdong> pangloss: behavior change might be undesirable for admins that have been able to effortlessly work around minor kinks, and even worse sometimes fixing one thing breaks something else even more
[19:40] <persia> It's more than sometimes.
[19:40] <jdong> :) true.
[19:40] <pangloss> right, but there are various bugs that sometimes are critical
[19:40] <jdong> pangloss: because of these risks, Ubuntu has a very stringent policy regarding how updates after releases are done: https://wiki.ubuntu.com/StableReleaseUpdates
[19:40] <pangloss> are they just abandoned in the old version and fixes are implemented in the new version?
[19:41] <persia> !sru
[19:41] <persia> pangloss, No.  We try to fix critical bugs using the SRU process.
[19:41] <pangloss> jdong, thanks for the link
[19:41] <jdong> sure thing
[19:41] <pangloss> ah
[19:42] <persia> On the other hand, there's only so many developers, so they tend to only focus on either *really* critical bugs, or in preparation for update releases for LTS.
[19:42] <jdong> yeah, and this procedure is so much more tedious than hitting upload blindly on development repos that human nature tends to send developers to newer releases.
[19:43] <directhex> not forgetting that it's a royal pain in the ass developing on something you don't use
[19:43] <jdong> nonetheless from my observation important bugs do get fixed after-release at least to a satisfactory level for most users
[19:43] <persia> jdong, Well, we're not supposed to do it blindly.
[19:43] <jdong> persia: well... can you really say with a serious face that it doesn't happen a lot? :)
[19:43] <directhex> so if people upgrade to intrepid or later, the urge to fix old bugs in 8.04 is pretty much nill
[19:43] <pangloss> persia, so as a newbie to bug fixing and developing, is fixing small bugs in older versions (say 8.04 when 8.10 comes out) fruitful?
[19:44] <pangloss> or am I just bothering ubuntu-sponsors-main?
[19:44] <persia> jdong, I can say that I don't do it very often.  I can say that I encourage anyone discovering such a thing to reply to the -changes mail on -devel.  With sufficient peer pressure, the incidence ought be reduced.
[19:44] <jdong> pangloss: if you find bugs that you feel are useful to be fixed and can be done with low risk, yes, I do feel that is a good thing to do
[19:44] <persia> pangloss, Unless it's a critical bug (as defined on the SRU page), you'd do better to suggest fixes for the release-in-development.
[19:45] <jdong> persia: I trust that you don't do it often, if at all. I try not to either. But definitely I've seen plenty of uploads where I had to question if any testing was done at all before uploading
[19:45] <pangloss> ok
[19:45] <persia> jdong, I've seen uploads where the uploader said afterwards that they didn't test it.  Doesn't make it a good thing, nor something we should accept as common practice.
[19:45] <pangloss> persia, what about packages that are for debian that aren't in 8.04, but could be
[19:45] <jdong> persia: agreed
[19:45] <persia> pangloss, How do you mean?
[19:46] <pangloss> is it useless to create an ubuntu package out of it?
[19:46] <persia> Yes, completely.
[19:46] <pangloss> or something from source
[19:46] <jdong> pangloss: if you're talking about new packages for 8.04, see the backports project
[19:46] <pangloss> really?
[19:46] <persia> They all get autosynced from Debian when the next archive opens.
[19:46] <jdong> pangloss: we can take some packages from Sid and development repos to make them available for older releases
[19:46] <jdong> but please don't directly make packages for older releases.
[19:46] <persia> Once the autosync occurs, as jdong mentions, they can be backported.
[19:46] <pangloss> ah
[19:46] <jdong> https://help.ubuntu.com/community/UbuntuBackports
[19:47] <pangloss> so the add/remove programs gets repopulated with packages that are for the newer release?
[19:47] <jdong> generally for older releases, no.
[19:47] <persia> add/remove programs contains a subset of packages available in that release.
[19:47] <pangloss> right
[19:47] <pangloss> hm
[19:47] <persia> To get newer packages, one either has to enable backports and use a different package manager, or wait.
[19:48] <persia> (well, there are also other means, but from that point they get increasingly difficult or risky)
[19:48] <pangloss> so how long does it take for work to start on the next release after 8.10 comes out?
[19:48] <jdong> within a week or two
[19:49] <persia> jdong, Do we care about Debian bug #442668 for intrepid?
[19:49] <pangloss> do the devel guys enjoy 8.10 for a little or is it on to 9.04 right away?
[19:49] <pangloss> ah
[19:49] <jdong> initially uploads are blocked-ish while new compilers, etc get uploaded
[19:49] <jdong> then it's bombs away.
[19:49] <jdong> persia: err... I'm not very informed on reprepo
[19:49] <NCommander> persia, I'll bug RainCT about it, he did all that work
[19:49] <persia> jdong, You aren't?  I thought it was your tool.  Is that something else?
[19:49] <jdong> persia: prevu :)
[19:49] <persia> NCommander, OK.  Thanks.
[19:49] <persia> jdong, My apologies then :)
[19:50]  * persia demotes the bug
[19:50] <jdong> no probs :)
[19:51]  * RainCT corrects his statement from this morning: its seems like there are actually lots of Mozilla guys using Ubuntu, but they use Mac for slides because it always works with projectors
[19:51] <persia> pangloss, Some developers upgrade as soon as the new archve opens, some delay as late as beta.  Those with multiple computers may delay one or more machines even later, but there are almost no developers who are still not updated by beta on at least one machine.
[19:51] <RainCT> NCommander: uhm.. you said my name? :P
[19:51] <RainCT> if it's about the problem that new users can't login, I'm about to fix it
[19:51] <jdong> RainCT: sounds reasonable
[19:51] <jdong> RainCT: I've been guilty of booting into OS X on my Macbook for presentations too
[19:51] <pangloss> persia, thank you for the information, I appreciate it
[19:51] <jdong> I've had Xrandr explode too many times to trust it :D
[19:52] <ScottK> Did someone else from motu-release ack wine, fop, or wbxml2?
[19:53] <NCommander> RainCT, it was also cookies should be storied longer on login
[19:53] <persia> Oh, probably not fop and wbxml2 : I suspect I've been following the wrong procedure.
[19:53] <RainCT> NCommander: yeah, that's a problem with mod_python.Sessions
[19:53] <ScottK> Up through Gutsy my Kubuntu laptop worked well with projectors.
[19:53] <persia> I didn't see any traffic about wine.
[19:53] <ScottK> Hardy, not so much.
[19:54] <ScottK> YokoZar: Did you get a motu-release approval for wine?
[19:54] <RainCT> I'd suggest a patch but they've no bug tracker and I don't feel like subscribing to yet another mailing list
[19:54] <persia> Intrepid projector support is *very* broken unless your laptop happens to have exactly the same resolution as your projector, and you're willing to restart X.
[19:55] <directhex> does tilting a mouse tiltwheel still crash x on intrepid? that was a sucky regression in hardy
[19:55] <NCommander> persia, on reprepro, we can skip it if we don't mind carrying db4.3 for one more release
[19:55] <persia> NCommander, It's too late to look, which is why I marked it unimportant.
[19:56] <ScottK> persia: Is there a bug about projector support being broken that's hinted at the release notes?
[19:56] <jdong> persia: and may the overlords have mercy on your soul if compiz were running or you want to show a video :)
[19:57] <RainCT> REVU signup (ie, first login) should be working again
[19:57] <persia> ScottK, Not to my knowledge.  It's not *more* broken than it was really, just frustratingly annoying.  If you're hunting a bug, it might be listed also under "external monitor support".
[19:58] <persia> RainCT, Please reply to the ML mail :)
[19:58] <ScottK> persia: I'm only barely here and have no idea about such things on Ubuntu.  It just sounded worth a release note.
[19:58] <persia> jdong, Actually, that doesn't work so badly for the right video card.
[19:58] <persia> ScottK, It shouldn't work any better on Kubuntu : something about the way X works this cycle.
[19:59] <jdong> persia: obviously I don't have the right video card then :)
[19:59] <persia> From my (limited) exploration, it's *really* hard to get xrandr to handle two screens with different resolutions, because it wants to put all physical devices in a single logical screen.
[20:00]  * persia looks for a bug
[20:00] <persia> ScottK, Do you think it's a regression from hardy?
[20:01] <ScottK> persia: As I said, I have no idea about such things on Ubuntu.
[20:01] <ScottK> Multiple monitor support being broken was release noted in Hardy for Kubuntu, but not Ubuntu.
[20:01] <RainCT> persia: sure, done
[20:02] <persia> ScottK, Hrm.  Interesting.  So officially not a regression for Kubuntu.  Well, it's worth asking.
[20:03] <ScottK> persia: OK.  Just to make it clear, for Ubuntu, I'm not asking.
[20:04] <persia> ScottK, Understood.  I'll ask.  the information that it was release-noted for Kubuntu 8.04 and not Ubuntu is the part that makes me do that.
[20:05] <ScottK> OK
[20:06] <ScottK> It was only release noted for Kubuntu because I knew how broken it was and wrote the release note.  I thought (at the time) that the Ubuntu xrandr tool made Ubuntu OKish.
[20:07] <persia> The tool is limited to what xrandr can do, which doesn't include non-rectangular geometries.
[20:07] <YokoZar> ScottK: not yet, sorry.  I want that upload to wait until ia32-libs is fixed since Wine will need a rebuild
[20:07] <YokoZar> ScottK: been gone for the past few days and didn't realized we slipped into full freeze mode :)
[20:08] <persia> So even if Kubuntu has an xrandr widget for intrepid, it doesn't fix the underlying issue.
[20:08] <ScottK> I see.
[20:08] <ScottK> Yeah we do.  I've been trying to get a projector to give it a workout.
[20:08] <ScottK> My next chance, unfortunately, is Thursday.
[20:09] <ScottK> YokoZar: I don't know of any ia-32libs upload pending.
[20:09] <persia> Well, if it's higher resolution than your laptop, you'll run into navigation issues, and if it's lower resolution than your laptop, you'll run into scaling issues, and in either case, you'll have issues with Xv *unless* you run them in mirror mode.
[20:10] <persia> (and you'll have issues with Xv in mirror mode if you have jdong's graphics card)
[20:11] <persia> jdong, Do you get bug #206528 or bug #227048?
[20:12] <jdong> persia: I'm not sure. I get a lot more of black striped screen of doom.
[20:12] <persia> Ah, that's not just xrandr then : that's the driver.
[20:12] <jdong> indeed
[20:13] <FAJ> hi in ndiswrapper, how can i change the driver from ndiswrapper to ath_pci?
[20:13] <jdong> it makes me jealous that now it seems like both proprietary drivers are doing better....
[20:13] <persia> jdong, Hrm?  I have intel graphics, and I can do Xv in mirror mode.
[20:14] <jdong> persia: maybe it's just user error
[20:14] <jdong> my intel driver has been giving me a lot of various grief recently
[20:14] <jdong> I'm scared for my life to switch between X/Compiz and VTs
[20:14] <persia> Or maybe something changed in the last three weeks.  I don't use my external monitor because it senses wrong (even though it is the same resolution as my laptop)
[20:14] <YokoZar> ScottK: pitti is rebuilding it now
[20:16] <FAJ> hi in ndiswrapper, how can i change the driver from ndiswrapper to ath_pci?
[20:16] <FAJ> i asked in #ubuntu, with no answer
[20:17] <persia> FAJ, Are you running hardy or intrepid?
[20:17] <FAJ> hardy
[20:18] <persia> FAJ, Hmm.  That nobody in the support channel answered doesn't make the development channel a support channel.  You might try a local channel, if there is one for your area.
[20:18] <FAJ> *sigh* ok...
[20:25] <RainCT> btw, if anyone here is using Ubiquity (the Mozilla extension, not our installer), future versions are going to rock! :P
[20:27] <NCommander> jdong, ping
[20:29] <coppro> what exactly does ubiquity do?
[20:32] <pangloss> coppro, http://labs.mozilla.com/2008/08/introducing-ubiquity/
[20:32] <ScottK> YokoZar: OK.
[20:33] <RainCT> coppro: well, it sorta connects different webpages
[20:35] <RainCT> coppro: so, to put an example, if you're writing an email to a friend telling him that you'll meet him at a certan address, you can just select that address and tell ubiquity to get a map, and that'll insert a map taken from Google Maps into the mail
[20:35] <coppro> cool
[20:35] <RainCT> coppro: you can also select some text and get it translated on place (replacing the original text), and lots of other cool stuff
[20:38] <ScottK> persia: Did someone in motu-release ack your wbxml12 upload?
[20:38] <RainCT> coppro: and well, right now you can launch a dialog with a key combination and start typing the name of the action you want to do there (like with GNOME Do), but there are plans to add alternative workflows, like integration into the awesome bar or that selecting a text and then opening a new tab would not show a blank page, but instead different commands that match the text (automatically detecting what you're likely to want to do with it), and 
[20:38] <ScottK> Oh, wait.  I did.
[20:38] <coppro> the awesome bar?
[20:38] <RainCT> (did all of my message arrive?)
[20:38] <RainCT> coppro: that's the location bar in Firefox 3 :P
[20:39] <persia> ScottK, As I said before, I think I only got one ack (you) for each of fop and wbxml2
[20:39] <coppro> heh
[20:39] <coppro> ff3 is indeed awesome
[20:39] <ScottK> persia: OK.
[20:39] <ScottK> It's been a busy day.
[20:40] <persia> ScottK, Understood, and a succession of long ones, from your traffic stats.
[22:28] <ScottK-palm> Am I far off if I estimate it'll be about 6 hours for the lang packs on the I386 buildds?
[22:35] <geser> ScottK-palm: there are over 900 language-packs and if you assume around 4 minutes to build (my sample are the build times for -de and -fr) you're quite correct with 6 hours
[22:39] <geser> hmm, I guess it's to late for me do to maths :(
[22:40] <geser> s/to/too/
[22:40] <lifeless> 3600 minutes if its serial  @ 4minutes each
[22:41] <geser> that would be 60 hours or 2½ days
[22:41] <NCommander> wow
[22:41] <NCommander> hey geser
[22:42] <geser> Hi NCommander
[22:43] <geser> I guess a better way would be to monitor https://edge.launchpad.net/+builds/ and interpolate how long it takes to empty the queue
[22:44] <geser> currently there are 608 packages waiting in the queue
[22:44] <NCommander> geser, how goes it?
[22:45] <ScottK-palm> See you later. I expect we might still be able to get uploads in after.
[22:48] <geser> ScottK: afaik language-packs are scored to the bottom of the build queue so normal uploads should get processed without much delay
[22:48] <geser> ScottK-palm: afaik language-packs are scored to the bottom of the build queue so normal uploads should get processed without much delay
[22:49] <ScottK-palm> I'd appreciate it if someone would look at the post-upload discussion in Bug 288957 and make a recommendation.
[22:50] <ScottK-palm> geser: But main goes ahead of universe.  Would lang packs go ahead of universe?
[22:50] <ScottK-palm> I'll read the scrollback laterm
[22:50] <ScottK-palm> ... later.
[22:50] <persia> Langpacks are usually scored behind universe, but might be ahead today just because they're so critical.
[23:48]  * StevenK merges strongswan
[23:48] <StevenK> Even if I might be a little late
[23:55] <TheMuso> heh