[01:06]  * Hobbsee waves
[01:14] <LaserJock> hi Hobbsee
[01:15] <Hobbsee> LaserJock!
[01:49] <LordKow> is there an easier way to check on accepted new/update packages (not in repos yet) than using the mailing lists?
[01:50] <Hobbsee> hardy-changes?
[01:50] <Hobbsee> although that's a mailing list, it's probably the easiest way
[01:51] <ajmitch> there was an rss feed of it
[01:51] <LordKow> ah okay
[01:52] <LordKow> building new totem with the ubuntu patches. i think the launchpad integration will work properly but i will find out shortly :P
[01:56] <LordKow> sad that my laptop has almost 2x more processing power than my desktop and my desktop is 2x old-school opterons
[01:59] <LordKow> hm build depends for totem seem to be out of date
[02:00] <LordKow> make: dh_iconcache: Command not found
[02:00] <StevenK> LordKow: That isn't a Build-Depends issue. Change that command to dh_icons
[02:01] <LordKow> ah okay, well totem is still out of date then ;)
[02:01] <LordKow> yea i forgot about the switchover
[02:01]  * Hobbsee didnt know dh_iconcache got taken out already.
[02:01] <LordKow> what was used before dh_iconcache? debian changelog says "use dh_iconcache" for one of the updates
[02:02] <Hobbsee> nothing, iirc.
[02:03] <Hobbsee> then ubuntu implemented dh_iconcache, and then debian eventually implemented dh_icons, so we're switching to that, as it's better anyway
[02:04] <LordKow> new version of debhelper was merged today, probably removed dh_iconcache
[02:05] <Hobbsee> hum.  then our rebuild tests will bail out.
[02:05] <LordKow> that will help filter out dh_iconcache from packages a lot quicker, maintainers wont be able to build the package unless they fix it :)
[02:05] <Hobbsee> for everything that still has dh_iconcache
[02:05] <Hobbsee> ubuntu has no maintainers, per se.
[02:05] <LordKow> update the packages...?
[02:06] <emgent> heya people
[02:06] <LordKow> Hobbsee, let me rephrase "the ubuntu maintainers". debian should take care of most of it
[02:06] <LordKow> however i doubt all of the packages will be updated before upstream merge freeze
[02:06] <Hobbsee> the ones that make it onto mom will be.
[02:06] <Hobbsee> as in, merge-o-matic
[02:07] <Hobbsee> however, the ones after...they'd be a good newcomer candidate.
[02:07] <LordKow> ah i always wondered what does the merging, i figured it was automatic
[02:07] <Hobbsee> there are tools which help, but it's all manual.
[02:08] <Hobbsee> see merges.ubuntu.com/universe.html
[02:08] <LordKow> i suppose there would be insane amounts of breakage if we let upstream merging be done automatically
[02:08] <LordKow> probably with dependencies more than anything else
[02:09] <Hobbsee> yeah.  i dont trust the merge-o-matic stuff that much :)
[02:09] <Hobbsee> occasionally it comes out with absolute crack.
[02:09] <Hobbsee> like, starting tarball sizes of 5mb from ubuntu, 5mb from debian.  resulting diff:  15mb.
[02:09] <LordKow> lol
[02:10] <Hobbsee> feel free to get involved, if you like
[02:11] <LordKow> well im quite busy with school stuff but hopefully I'll be able to squeeze out a few package updates than can get sponsored
[02:11] <LordKow> *that
[02:14] <Hobbsee> dear compiz, please stop falling over, kthxbye.
[02:14] <Hobbsee> no, this apparently *isnt* compiz.
[02:15] <Hobbsee> yes it is.
[02:33] <Hobbsee> any buildd admins around?
[02:33] <Hobbsee> lamont: maybe?
[02:33] <lamont> Hobbsee: I'm hiding.
[02:33] <lamont> since I need to figure out why your ppa build didn't like you
[02:34] <Hobbsee> lamont: can you boost the priorities of firefox-3.0 please?  https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=firefox-3.0&build_state=all
[02:34] <Hobbsee> lamont: "soyuz is on crack" is an acceptable answer.
[02:35] <Hobbsee> lamont: i'll give you longer before asking about the other, if you bump the prio of that firefox.  how's that?  :)
[02:35] <lamont> can't bump hppa or ia64.
[02:35] <lamont> others set to 10000
[02:35] <Hobbsee> excellent, thanks.
[02:36] <lamont> ia64 bumped too.
[02:37] <lamont> hppa kinda needs a working java to build xulrunner, so um.. sucks to be us
[02:37] <lamont> interesting.  greasemonkey script failed me
[02:38] <Hobbsee> yeah
[02:38] <Hobbsee> hah
[02:40] <lamont> there
[02:40]  * lamont applied a *=100 filter
[02:41] <Hobbsee> :)
[02:53] <LordKow> i hate it when i make a stupid mistake and spend 2 hours waiting for a package to compile and have it fail in the end simply because i forgot to update the .dsc after i made changes :-/
[02:54] <bddebian> I know that feeling
[02:56] <Hobbsee> ccache ftw!
[02:57] <LordKow> dont have the disk space :(
[03:30] <LordKow> "Totem Movie Player 2.21.2" yay
[04:54] <Hobbsee> mdz: er...https://bugs.edge.launchpad.net/ubuntu/+source/landscape-client/+bug/163030 might be something you're interested in.
[04:54] <ubotu> Launchpad bug 163030 in landscape-client "Against Ubuntu Promise" [Undecided,New]
[04:54] <Hobbsee> looks like you were teh uploader.
[05:00]  * tonyyarusso subscribes
[05:01] <tonyyarusso> Launchpad and Landscape being proprietary are pretty high up on the list of things that irk me with Ubuntu atm.
[06:37] <warp10> Hi all!
[06:45] <dholbach> good morning
[06:45] <Hobbsee> guten morgen, dholbach
[06:47] <dholbach> hey Hobbsee
[07:28] <\sh> slangasek, bug #161193 commented...I could be wrong, please check :)
[07:28] <ubotu> Launchpad bug 161193 in xclass "[MoM Merge] xclass 0.9.2-3ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/161193
[08:12] <slangasek> \sh: why would there be problems upgrading from dapper?
[08:13] <slangasek> \sh: my analysis showed there were zero overlapping files between the two packages
[08:40] <pitti> Good morning
[08:40] <geser> Hi pitti
[08:42] <warp10> pitti: Hi boss!
[08:42] <pitti> hey geser, hey warp10
[08:43] <pitti> warp10: /me != boss :)
[08:43] <warp10> pitti: :D
[08:53] <seb128> is there any known toolchain issue on amd64?
[08:53] <mhb> hi pitti
[08:54] <seb128> hum, in fact not amd64 specific
[08:54] <seb128> there is quite some packages I synced from Debian which ftbfs on "undefined reference to `ceil'"
[08:54] <seb128> but they built correctly in Debian
[08:55] <seb128> "undefined reference to `floorf'" also in the log
[09:00] <pitti> hey mhb, how are you?
[09:01] <mhb> pitti: I'm having an exam in 4 hours, so a bit nervous, but fine otherwise ... and how are you? I have noticed you've completed the r-m-rewrite spec, the DB idea sounds quite nice
[09:03] <pitti> mhb: oh, good luck with your exam then! I'm quite good, grinding through the large heap of work that UDS created :)
[09:06] <mhb> pitti: by the way, my account on r-m-hackers is about to expire. I guess it'd be nice of you to renew it for some time, provided you still want my help :o)
[09:06] <pitti> mhb: oh, sure
[09:07] <pitti> mhb: how's that?
[09:10] <mhb> pitti: https://edge.launchpad.net/~restricted-manager-hackers I guess through the Members link from here
[09:12] <\sh> slangasek, ok...so I think we change the merge to a sync...and we are clean
[09:13] <Treenaks> hmm.... bug 163042
[09:13] <ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Undecided,New] https://launchpad.net/bugs/163042
[09:14] <seb128> doko_: around?
[09:14] <mhb> pitti: by the way, the wiki page is not really clear on how the UI abstraction will be handled ... are we going to provide a fixed number of abstract dialogs (like ConfirmDialog, FirmwareSelectDialog) for the handlers? If so, how many and which?
[09:16] <lool> seb128: Do you have an example package?
[09:16] <pitti> mhb: yes, all the workflow, dialog types, etc should be in the abstract UI; implementations should not do any decisions nor workflow
[09:16] <seb128> lool: nautilus-cd-burner
[09:17] <seb128> lool: include math.h makes no difference, that's weird
[09:17] <lool> seb128: It sounds from your description that -lm is missing, but historically ld in Debian/Ubuntu would add it automatically
[09:17] <lool> Perhaps it's stricter now
[09:18] <seb128> well, it used to work and work on Debian
[09:18] <seb128> whatever was added -lm should keep doing so ;-)
[09:18] <seb128> doko_: ^
[09:18] <seb128> did anything change in the toolchain that could make that -lm is not used on build now?
[09:19] <lool> seb128: We have a CVS snapshot of 2.18.1 while Debian has 2.18
[09:19] <seb128> lool: cvs of what?
[09:19] <lool> binutils
[09:19] <seb128> ah
[09:20] <lool> But yeah, doesn't sound like a change we should do in Ubuntu first
[09:20] <seb128> I'll wait for a reply from doko
[09:21] <Treenaks> Are there Security/samba people? People are seeing dead nmbd's after the latest Samba security upgrade (bug 163042)
[09:21] <ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/163042
[09:21] <\sh> dear developers, we have a problem with security regarding dapper and a very vital package named ethereal (or newer name wireshark)
[09:22] <\sh> in dapper we have ethereal 0.99.0 which is the last release under the name ethereal and all future releases are named wireshark
[09:23] <lool> seb128: I got some build logs with this error as well now :)
[09:24] <\sh> now we have some security flaws in 0.99.0 which are fixed in 0.99.2...the problem with that, there is no real way to fix those security issues in 0.99.0 without diffing 0.99.0 to 0.99.2 and carry a very big patch with us... (rational: they are changing not only the project name, no they are changing as well some prefixes of variables from ETH_ (for ethereal) to WS_ (for wireshark))
[09:24] <seb128> lool: from Debian or Ubuntu?
[09:24] <lool> seb128: Ubuntu
[09:24] <seb128> ok
[09:25] <\sh> so, what do you think is the best way to fix this package...it's vital and for sysadmins and network people important.
[09:27] <pitti> \sh: I don't really think we can give a good answer to this; it's universe for a reason, and if you rely on anything in an universe as old as dapper's, you have a major problem (likewise with clamav, php apps, etc.)
[09:28] <pitti> \sh: if it is feasible to put the latest wireshark into dapper and name it 'ethereal' to avoid NEW packages, we can talk about this, though
[09:28] <pitti> but if it breaks any behaviour, config files, etc., then the only remaining option that I see is a backport
[09:28] <\sh> pitti, well, for any other release it's easy to backport the fixes...but for dapper, it's special because of the change of the project
[09:29] <pitti> \sh: so merely changing the package name doesn't work?
[09:29] <pitti> it also changes config file names/paths, etc/
[09:29] <pitti> ?
[09:30] <\sh> pitti, I'll have to check other files to answer this question, but reading the source for the important parts, I wonder if they didn't even change names of config files or something else
[09:30] <pitti> \sh: quite likely if they are that thorough
[09:31] <pitti> \sh: however, patching that might be significantly easier than trying to backport all the security fixes
[09:32] <\sh> pitti, I tryed to bump only the files which are affected, but they really do indeep changes, as I said, changing struct names from ETH_ to WS_ etc. which gives me a real headache
[09:32] <Fujitsu> Ewww.
[09:33] <\sh> as an example btw: http://anonsvn.wireshark.org/viewvc/viewvc.py/releases/wireshark-0.99.2/epan/dissectors/packet-gsm_a.h?view=diff&r1=18755&r2=17982&diff_format=h
[09:36] <torkel> \sh: you can't just do s/WS_/ETH_/g to trim the diff?
[09:36] <\sh> torkel, that's something I'm trying to do now
[09:42] <lool> slangasek: Is there a technical page which the changes in JeOS WRT to e.g. a server install?  I guess less packages installed and a different kernel flavor, but I'm not even sure
[09:59] <\sh>  oh I'M really doomed...let's do the easy things first...feisty and edgy
[10:01] <lool> Hmm http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=python-gobject-doc&version=hardy&arch=all lists djpig as contact address; I guess he might not want to be contacted for packages.ubuntu.com; do I file a ticket for IS?  Or a launchpad bug against some team?
[10:01] <dholbach> lool: he takes care of that page
[10:02] <dholbach> (iirc)
[10:02] <lool> dholbach: Oh ok; fine then, thanks
[10:02] <dholbach> np
[10:02] <dholbach> although I think we should have that functionality in LP :)
[10:03] <mdz> Hobbsee: thanks for bringing my attention to it; I've clarified in the bug
[10:03] <Hobbsee> mdz: you're welcome.  now i just have to find the bug #, to see what you said :)
[10:03] <mdz> Hobbsee: bug 163030
[10:03] <ubotu> Launchpad bug 163030 in landscape-client "Against Ubuntu Promise" [Undecided,Invalid] https://launchpad.net/bugs/163030
[10:03] <Hobbsee> thanks
[10:04] <Hobbsee> mdz: ahh, so you sneakily avoid the issue of the *client*.
[10:04] <Hobbsee> er, the host.
[10:05] <Fujitsu> Hobbsee: Of course.
[10:05] <Fujitsu> Server, you mean?
[10:05] <Hobbsee> yes.  *that's* the word i was looking for.
[10:05] <Fujitsu> Heh.
[10:05] <Hobbsee> i swear, the idea of exams on saturdays screws up my brain.
[10:06]  * Fujitsu had his last exam a few hours ago, so hah!
[10:09] <mdz> Hobbsee: Landscape is a web service which can be used in conjunction with a client.  The client is part of Ubuntu and free software.  The service is something which is offered for a fee.
[10:10] <Hobbsee> mdz: okay, i didn't realise my brain was *that* broken.  i knew that, i really did :)
[10:10] <mdz> Hobbsee: is there anything unclear about it?  I don't think the press release got into this level of detail
[10:10] <Hobbsee> mdz: no, it's clear.  it's just my brain on crack, due to these damned exams.
[10:10] <highvoltage> since there's some talk on landscape, where can I ask for the testers support? the landscape interface pointed me to landscape-devel@lists.canonical.com, but posting there is only for members.
[10:10] <mdz> Fujitsu: any questions about landscape?
[10:11] <Hobbsee> mdz: you ask that, and he'll say "Will you open source it, and if so, when?"
[10:11] <Hobbsee> :)
[10:11]  * Fujitsu doubts it.
[10:11] <Fujitsu> mdz: The client is entirely useless without the service, presumably?
[10:12] <mdz> Fujitsu: it's designed to be used with our implementation, though the protocol is open and could presumably be used with other software if someone implemented it
[10:13] <Fujitsu> mdz: Aha, thankyou for clarifying that.
[10:13] <mdz> but the service isn't offered for free, any more than telephone support is
[10:13] <Fujitsu> Right, and that is reasonable.
[10:14] <Fujitsu> Hobbsee: I'm not against *any* Canonical projects being non-free, just essential deficient stuff like LP.
[10:14] <Hobbsee> Fujitsu: heh.  heh.  heh.
[10:15] <seb128> Fujitsu: maybe not the right chan to troll? ;-)
[10:15]  * Hobbsee does not comment, as mdz is around.
[10:15] <Hobbsee> seb128: it was related to previous discussion
[10:16] <seb128> Hobbsee: well calling LP deficient is still somewhat trollish
[10:16] <Hobbsee> seb128: tell me that when you *don't* have chinstrap access.
[10:16] <seb128> Hobbsee: I don't have chinstrap access
[10:16] <Hobbsee> oh?  i thought you did, to log into drescher to do archive admin stuff?
[10:16] <Hobbsee> or have they changed the machines?
[10:17] <Fujitsu> seb128: How is it trollish?
[10:17] <seb128> Hobbsee: you didn't ask me if I have access, you asked me to tell you I don't have access which I did ;-)
[10:17] <Fujitsu> Haha.
[10:17]  * Hobbsee gives seb128 a penalty card.  LYING!
[10:18] <seb128> Fujitsu: you might not like launchpad it doesn't make it deficient
[10:18] <Hobbsee> seb128: you missed the "when" in there.
[10:18] <seb128> Hobbsee: indeed ;-)
[10:18] <Hobbsee> seb128: :)
[10:18] <Hobbsee> seb128: it's deficient when it's bugs stop me from doing ubuntu stuff.
[10:18] <seb128> like what?
[10:18] <Fujitsu> Right, there are a annoying bugs, so it is deficient.
[10:18] <Hobbsee> archive admin, for one.
[10:18] <Hobbsee> various other things as well
[10:19] <Fujitsu> Erm, -a
[10:19] <Mithrandir> software is buggy, news at 11.
[10:19]  * Mithrandir hides.
[10:19] <seb128> Fujitsu: you can call everything deficient using that criterium
[10:19] <Fujitsu> Mithrandir: Software is taking a long time to get unbuggy, even with 35 devs.
[10:19] <Hobbsee> Fujitsu: no, annoying bugs != deficient.  missing critical features == deficient.
[10:19] <seb128> Hobbsee: that's called bugged and Ubuntu is as deficient as launchpad
[10:19] <Hobbsee> seb128: i can fix one, and not the other :)
[10:20] <Hobbsee> but oh well.
[10:20] <seb128> what make you start this troll again?
[10:20]  * Hobbsee throws a thunderbolt at Mithrandir :)
[10:20] <seb128> I think launchpad not being opensource yet has already been discussed
[10:20] <seb128> is there a point to start again on the ubuntu chan?
[10:20] <seb128> that's rather OT for Ubuntu
[10:21] <Fujitsu> seb128: It was relevant to the previous discussion.
[10:22] <Hobbsee> seb128: if you must know, it was discussions on landscape, and mdz asking if we wanted clarification on that.  that, is of course partially non-free, which led to the comment about it being acceptable for canonical to have propriatory stuff.  would you like a pastebin?
[10:22] <seb128> Fujitsu: I was not there for the discussion apparently, still calling LP deficient is trollish
[10:22] <Hobbsee> and this isnt?  :)
[10:22] <seb128> Hobbsee: no thanks, I would just like to not have yet another discussion about LP having some bugs and being closed source there, that has been discussed enough and I don't think the discussion will bring us anything
[10:22] <mdz> Fujitsu: Launchpad will be open source, though the matter of when is complex
[10:23] <Hobbsee> mdz: and how much
[10:23] <Hobbsee> but, you're right, i have better things to do.
[10:23] <Fujitsu> mdz: I know, and I've read the reasons that have been cited, and I find them somewhat reasonable.
[10:24] <mdz> Hobbsee: I don't think there is any question about how much
[10:24] <mdz> there's no third-party IP in it as far as I'm aware
[10:25] <Fujitsu> mdz: Isn't there? I was sure that previous versions of the policy mentioned that Soyuz would remain non-free, as it will always be a service sold to other distros.
[10:27] <mdz> Fujitsu: I'm happy to discuss this, but please take it to #launchpad
[10:27] <mdz> seb128 is right
[10:28] <Fujitsu> mdz: True, this has drifted well offtopic now.
[10:49] <doko_> seb128: -lm isn't added automatically for C, just for C++
[10:49] <seb128> doko_: the same package built in gutsy and debian, something is the toolchain changed
[10:50] <seb128> doko_: did -lm used to be added for C?
[10:50] <doko_> seb128: maybe another library was linked against -lm before?
[10:50] <seb128> yeah, might be, I'm just trying to figure which one ;-)
[11:42] <seb128> mvo: you should send this toshset change to Debian or do a QA upload there and ask for syncing ;-)
[11:48] <mvo> seb128: I send the patch upstream already
[11:49] <seb128> mvo: ah ok, I looked to the BTS only
[11:50] <mvo> seb128: hm, at least it should be sent, I got no reply from debian bts yet
[12:01] <dholbach> MOTU Q&A session in #ubuntu-classroom now
[12:30] <pitti> tepsipakki: hm, I thought mesa 7.0.2-2ubuntu1 wouldn't need gcc-3.4 any more? it still uses it on i386/amd64/lpia?
[12:32] <tepsipakki> right, I didn't drop those yet, need to get a confirmation from the kernel guys..
[12:34] <tepsipakki> pitti: or do you think we could drop them right away?
[12:35] <pitti> tepsipakki: no, if you need soem confirmation, please get it
[12:35] <pitti> tepsipakki: I just thought that was already settled after our conversation from yesterday
[12:36]  * pitti hugs tepsipakki, thanks
[12:38]  * tepsipakki hugs pitti back
[13:11] <Hobbsee> cjwatson_: ping @ ubuntu-devel ML question
[13:18] <directhex|bsp> cjwatson_, did you read my review of current ps3 linux distributions?
[13:23] <DktrKranz> pitti, could you please have a look at bug 103489? It has already uploaded and needs to be accepted.
[13:23] <ubotu> Launchpad bug 103489 in ggz-gtk-games "[SRU] [can-not-install] file overwrite error" [Medium,Confirmed] https://launchpad.net/bugs/103489
[13:26] <pitti> DktrKranz: I'll get to that today (SRU run is still on my plan)
[13:26] <DktrKranz> pitti: thanks
[13:35] <cjwatson_> directhex|bsp: no?
[13:35] <cjwatson_> Hobbsee: pong
[13:36] <Hobbsee> cjwatson: ubuntu-devel@l.u.c is moderated by if you're a part of ubuntu-dev or not.  how does it get this list of who's in ubuntu-dev?  namely, do new MOTU's get added manually to the whitelist, or does it do some launchpad foo?
[13:37] <directhex|bsp> cjwatson, http://gaming.hexus.net/content/item.php?item=10273 - nobody did very well
[13:37] <cjwatson> Hobbsee: that's a good question and not one where I know the answer. elmo ought to know
[13:38] <Hobbsee> cjwatson: surely not!  you're supposed to know everything :)
[13:38] <Mithrandir> Hobbsee: it's synced automagically, I believe.
[13:39] <pochu> add me to ~motu and I'll test :-)
[13:39] <Hobbsee> Mithrandir: in which case, why does norsetto keep getting moderated?
[13:39] <cjwatson> directhex|bsp: OK, I've repaired (and continue to be in the process of repairing) some of your issues for Ubuntu, but haven't spent the time to produce custom versions of Xubuntu 7.10
[13:40] <Mithrandir> Hobbsee: is he sending from an address associated with his LP account?
[13:40] <directhex|bsp> cjwatson, all the problems stated were on ubuntu also, it was just a bit slower due to gnome's extra memory requirements. network, resolution, etc
[13:40] <Hobbsee> Mithrandir: come on launchpad.  dont time out.   load the page.  good launchpad.
[13:41] <Hobbsee> Mithrandir: it's his third confirmed email, yes.
[13:41] <Mithrandir> Hobbsee: hm, then I defer to cjwatson's advice to talk to our sysadmins who might be able to shed some light on the issue.
[13:41] <cjwatson> directhex|bsp: FWIW: current custom Ubuntu 7.10 CDs (not in the obvious place, but there's a link from the obvious place) document the video mode stuff in the CD boot loader message, the networking thing is a hal bug that I think I've mostly fixed and just need to QA properly, I'm not sure why Gnash isn't automatically offered but maybe that's a Xubuntu thing?
[13:41] <Hobbsee> Mithrandir: fair enough
[13:42] <Hobbsee> elmo: ping, and i promise i wont start ranting again :)
[13:42] <directhex|bsp> cjwatson, i may look at the question again when 8.04 is stable (by then, maybe the fedora lot will have pulled their thumbs out of their arses and stuck otheros.bld on the install media, so i can consider it for comparison)
[13:42] <cjwatson> directhex|bsp: I do agree that we haven't spent enough time on it, and I posted a call for development help recently
[13:43] <directhex|bsp> cjwatson, yes, i read it, hence making you aware of my article
[13:43] <directhex|bsp> cjwatson, if it makes you feel any better, nobody else was any better overall
[13:43]  * cjwatson nods
[13:44] <directhex|bsp> frankly, some of the issues i found on all three distros were baffling.
[13:56] <seb128> so guys, we (desktop team, but there is nothing desktop specific there) want to start using some sort of tags in the patches
[13:56] <seb128> to have informations like the corresponding ubuntu bug number, the upstream one, a description of the patch, etc
[13:57] <seb128> does anybody has an opinion on the format that should take and the naming?
[13:57] <\sh> keescook, bug #132915 -> feisty and edgy debdiffs attached, dapper is not going to be fixed...
[13:57] <ubotu> Launchpad bug 132915 in wireshark "WireShark versions prior to 0.99.6 vulnerability" [High,In progress] https://launchpad.net/bugs/132915
[13:57] <seb128> I was thinking to something like
[13:58] <seb128> ubuntulog: http://launchpad.net/bugs/nnnnnn
[13:58]  * seb128 slaps the completion
[13:58] <seb128>  Ubuntu: http://launchpad.net/bugs/nnnnnn
[13:58] <seb128>  GNOME: http://bugzilla.gnome.org/nnnnnn
[13:59] <seb128> Description: what the change is doing
[14:00] <seb128> do we want those standardized so they can be automatically listed by some tools maybe, etc?
[14:00] <Fujitsu> seb128: As in dpatch patches?
[14:01] <seb128> Fujitsu: nothing dpatch specific, as in any patch system you want to use, simple-patchsys, quilt, dpatch
[14:01] <Fujitsu> But that sort, right.
[14:01] <seb128> everything we store in debian/patches
[14:01] <seb128> and which theorically should be send upstream and documented
[14:02] <seb128> we should also have a tag to indicate that a change is distribution specific (customization for example)
[14:49] <pitti> seb128: I'd do s/GNOME/Upstream/
[14:49] <pitti> seb128: and perhaps add Debian:
[14:50] <seb128> pitti: I was pondering if we should get a tag by bug tracker or just an upstream one
[14:50] <seb128> pitti: like to list all the bugzilla.gnome.org bugs
[14:51] <seb128> pitti: but that would be easy enough to do using upstream and filtering on bugzilla.gnome.org then
[14:51] <pitti> seb128: I wouldn't define more tags than necessary
[14:51] <seb128> ok
[14:51] <pitti> seb128: yeah, that's what I was thinking, you can filter on teh bug tracker host name
[14:51] <seb128> so Ubuntu, Debian, Upstream
[14:51] <seb128> and Ubuntu-specific
[14:51] <pitti> seb128: FYI, the Debian kernel guys do something similar
[14:51] <seb128> and Description
[14:52] <pitti> seb128: technically, Debian is just an upstream too, but since it is so exceptionally important for us that might justify a separate tag
[14:52] <pitti> seb128: otherwise I like it
[14:53] <seb128> pitti: right, but it's a special upstream, and that means we can use the same tagging on Debian
[14:53] <pitti> right
[14:54] <seb128> I'll mail ubuntu-devel about the suggestions, thank you for the comments
[15:39] <Robot101> has some big backlog of security updates just been unplugged?
[15:39] <Robot101> there have been like 100 in the past 2-3 days
[15:40] <pitti> dholbach: why did you do a gutsy-wallpapers upload to hardy? I thought that was obsolete?
[15:40] <dholbach> pitti: so it's installable in parallel with ubuntu-wallpapers
[15:40] <pitti> ah, I see
[15:41] <cjwatson> Robot101: last week and the week before, the security team were at conferences in Massachusetts
[15:42] <cjwatson> Robot101: so I expect that it's "get back home, work on CVEs"
[15:42] <\sh> more openldap security fun....:(
[15:51] <Skiessi> when nvidia-glx-new gets updated to work with the newest xserver-xorg-core?
[16:04] <dholbach> pitti: ubuntu-gdm-themes uploaded
[16:05] <dholbach> pitti: ubuntu-artwork should depends on ubuntu-gdm-themes and ubuntu-wallpapers now too
[16:09] <pitti> dholbach: accepted
[16:09] <dholbach> pitti: thanks A LOT
[16:09]  * dholbach hugs super-pitti
[16:10] <pitti> no problem :)
[16:10]  * pitti hugs dholback
[16:10] <dholbach> :-)
[16:13]  * pitti kicks out a whole lot of old crap from -proposed; yay, back to sanity!
[16:13] <pochu> doko: I've done your mono merge, hope you don't mind.
[16:14] <pitti> mvo: what will happen with bug 47044? there's still an outstanding question
[16:14] <ubotu> Launchpad bug 47044 in apt "apt cant work with disable proxy" [Medium,Fix committed] https://launchpad.net/bugs/47044
[16:15] <pitti> and it needs verification
[16:15] <pitti> and it's sitting there for 290 days already
[16:17] <mvo> pitti: sorry, I look at it and answer your question
[16:17]  * pitti hugs mvo, thanks
[16:22] <pitti> bdmurray, mvo, ogasawara: main SRUs in -proposed which are more than half a year old and did not get any testing feedback from reporters are a good candidate for removal from -proposed IMHO; do you agree?
[16:22] <pitti> bdmurray, mvo, ogasawara: (I already cleaned up all the universe stuff)
[16:23] <pitti> common sense applied, of course
[16:23] <ogasawara> pitti: sounds reasonable to me
[16:30] <pitti> mvo: FYI, you have some verification bug mail for update-manager{,-core} now
[16:30] <mvo> pitti: in my inbox?
[16:30] <mvo> pitti: let me check
[16:30] <pitti> (not that urgent, but a gentle reminder)
[16:39] <mvo> pitti: I can't do the verification for #47044 myself, but I will update the report to follow the new verification steps guidelines
[16:40] <pitti> mvo: thanks
[16:40] <pitti> mvo: also, if you test the actual -proposed package yourself, that's still a valuable piece of feedback at least forme
[16:40] <pitti> s/forme/for me/
[16:42] <bddebian> Heya
[16:54] <lamont> dear bip.  please quit dying. kthxbye
[16:58] <mvo> pitti: #47044 updated
[17:00] <pitti> mvo: aaaah, that makes sense
[17:00] <pitti> mvo: I programmed Python for too long :)
[17:00] <pitti> incidentally that's the very same trap that StevenK and I fell into recently
[17:00]  * pitti ← hasn't touched C++ for > 5 years :(
[17:01] <pitti> mvo: so, verification should be easy now
[17:01]  * pitti hugs mvo
[17:03] <mvo> pitti: cheers, what are the other outstanding ones for u-m?
[17:04] <pitti> http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[17:04] <pitti> bug  #109216 and bug #109290
[17:04] <ubotu> Launchpad bug 109216 in update-manager "upgrade not possible with 0.45.3" [Undecided,Fix committed] https://launchpad.net/bugs/109216
[17:04] <ubotu> Launchpad bug 109290 in update-manager "update-manager core should support proposed updates" [Medium,Fix committed] https://launchpad.net/bugs/109290
[17:04] <pitti> mvo: those are all of your's, I think
[17:05] <pitti> mvo: in a few hours the page should be much smaller, BTW
[17:10] <mvo> pitti: thanks, checking
[17:24] <slangasek> lool: you may want to ask soren about that (differences between JeOS and server); there's also a tentative seed for it now
[17:24] <frafu> Hello, I am new to patching and am currently stuck. Here is my problem: On launchpad there is a project written in C called mousetweaks. Release 0.2.6 has been published and in the meantime a typo has been fixed in launchpad. I downloaded the unified diff to patch the debian source package I am trying to build. But when I try to apply the dpatch that I created from the diff, it tells me that it does not find the file.
[17:25] <slangasek> \sh_away: will you retitle the xclass bug to a sync request, or do you want me to just take it from here?
[17:25] <frafu> Could anybody please help?
[17:25] <pochu> frafu: use 'patch -pX <your_patch.dpatch', where X is a number
[17:26] <pochu> frafu: btw #ubuntu-motu is a better place for that question :)
[17:26] <pitti> frafu: https://wiki.ubuntu.com/MOTU/School/PatchingSources should help you
[17:27] <\sh> re
[17:29] <frafu> I thought to use dpatch, and there are 2 patches that I have to apply. Will I be able to use -pX in the debian rules file?
[17:32] <frafu> pochu: why is the number of dirs dires to strip wrong? What can I do to get a patch that works from the root dir of the package without indicating a -pX ?
[17:33] <cjwatson_> surely for a typo it would be less effort just to edit the source directly rather than spending ages messing with a patch system
[17:33] <cjwatson> patch systems are worthwhile if you have fairly substantial numbers of fairly long-lived patches against upstream
[17:33] <cjwatson> but for a simple typo backported from upstream, it isn't worth it
[17:34] <pwnguin> patch systems are wierd. there's already a diff.gz
[17:34] <pwnguin> and now you want to hide more inside that?
[17:35] <cjwatson> I understand why people end up using them for, as I said, fairly substantial numbers of fairly long-lived patcheds
[17:35] <cjwatson> gah
[17:35] <cjwatson> ()(although I would
[17:35] <cjwatson> (although I would prefer to replace that with better infrastructure, long-term)
[17:35] <pwnguin> i wonder how git's working out for joey hess
[17:35] <frafu> In fact,there is a second more complicated patch to apply; it gives me the same error.
[17:37] <frafu> I have prepared a page with more info, if someone can have a look:
[17:37] <frafu> http://paste.ubuntu-nl.org/44761/
[17:38] <frafu> Is there a way to create the patch so that no -pX is necessary?
[17:39] <cjwatson> dpatch should supply the -pX itself
[17:39] <cjwatson> are you trying to apply the patch by hand here?
[17:39] <cjwatson> (in any case, I still think dpatch is overkill in your case and you are making a rod for your own back)
[17:40] <cjwatson> oh, I think I see your problem, anyway
[17:40] <frafu> yes, with 'dpatch apply-all' to test the patch
[17:40] <cjwatson> dpatch probably tries -p1 first and there is a ChangeLog at the root
[17:41] <cjwatson> don't use that dpatch patch-template business
[17:41] <cjwatson> instead, use dpatch-edit-patch
[17:43] <frafu> Could you please tell me shortly how to use dpatch-edit-patch? Can I feed the diff from launchpad to dpatch-edit-patch?
[17:43] <cjwatson> so you do 'dpatch-edit-patch fix_typo_in_po_de'
[17:43] <cjwatson> it will give you a shell
[17:43] <cjwatson> in an unpacked copy of the source package
[17:44] <cjwatson> you apply the patch to that tree, and exit; it will deal with generating the .dpatch file and putting it in the right place
[17:44] <cjwatson> btw, this is all in the URL pitti gave you earlier. Have you read through that?
[17:44] <cjwatson> if not, please do so, and then go to #ubuntu-motu if you have further problems
[17:47] <frafu> cjwatson:  thanks. I will try what you suggested and read pitti's link
[17:52] <IntuitiveNipple> Anyone got suggestions as to what I should look for. Whilst booting UML Gutsy it mounts root but during init reports "findfs: Unable to resolve 'UUID=XXXX' " for the / and /home, mountpoint+mount report failure, and from the maintenance shell there's no /dev/ubd* or /dev/disk/by-uuid/
[17:53] <ogra> looks like it doesnt wait long enought for the devices
[17:53] <ogra> (just a guess)
[17:55] <dajhorn> IntuitiveNipple: (You'll get plonked by asking support questions here).  Gutsy broke UUID handling on many of my servers.  Try it LABEL instead.
[17:55] <IntuitiveNipple> I'm trying to ensure we have a working UML... this looks to be the last part of the puzzle
[17:59] <IntuitiveNipple> Nope, LABEL doesn't help. It looks as if no 'disk' nodes are being created
[18:06] <IntuitiveNipple> Ahhh... would it help to have udev installed?
[18:07] <pitti> tepsipakki, bryce: all the x client packages on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt (source and binary demotion) can be kicked out of the archive entirely, right?
[18:28] <bryce> pitti, yes that's correct.  I'm not sure why -elographics is on that list, but everything else is now maintained in other packages
[18:30] <dajhorn> Where can I go to watch vmware-server foodfight that is happening?  Ticket activity is happening without commentary.
[18:34] <desertc> Greetings, could I get your opinion on this question:
[18:34] <desertc> http://ubuntuforums.org/showthread.php?t=614769
[18:35] <cjwatson> desertc: you might want to say what it's about so that not everyone has to visit the URL to find out
[18:35] <desertc> I hate to fill the channel with a cut and paste.
[18:35] <cjwatson> summarise
[18:35] <cjwatson> you certainly shouldn't cut and paste it
[18:36] <desertc> That is what I did on the link...
[18:36] <jdong> desertc: you are asking a support question in that thread
[18:36] <cjwatson> there are 235 people in this channel with hundreds of different interests
[18:36] <ogra> desertc, you miss the difference between the gutsy-security and gusy-updates repos
[18:37] <jdong> desertc: as ogra just said, disable gutsy-updates and only enable gutsy-security in the Software Sources Manager
[18:37] <jdong> or /etc/apt/sources.list
[18:37] <cjwatson> when posting a link, you need to say briefly what it's about in order that the people who are interested can look, rather than everyone
[18:37] <ogra> desertc, what you want is to disable gutsy-updates ... that way you*ll only get critical fixes
[18:37] <jdong> cjwatson: his thread asks if there is a way to only get Security updates rather than Recommended Updates too
[18:37] <desertc> jdong: Yes, exactly!  So, in doing so, will there be any issue with the security updates expecting a "recommended" update being in place?
[18:38] <ogra> yeah, without having to read the forum it would have been easier and saved some ram in my 60+ tabs firefox win
[18:38] <jdong> (and yes, desertc, it'd be nice if you can give one-line summaries without forcing people to click a link)
[18:38] <jdong> desertc: no. they are designed to be independent of each other
[18:38] <desertc> jdong: I will keep this in mind for future communications.
[18:38] <cjwatson> jdong: sure, I wanted him to tell me ;-)
[18:38] <cjwatson> or, well, tell us
[18:38] <desertc> jdong: Thank you very much.  I really appreciate the advice.
[18:38] <cjwatson> desertc: jdong's *nearly* right
[18:38] <cjwatson> desertc: -security doesn't require -updates, but -updates may require -security
[18:39] <cjwatson> desertc: indeed, packages in -security are normally pushed into -updates as well
[18:39] <desertc> Good luck with your endeavors to bring Free Software to human beings, all.
[18:39] <cjwatson> so to all intents and purposes -security is a subset of -updates
[18:39] <jdong> as always cjwatson knows best :)
[18:40] <jdong> "If so, then I may simply leave the Update Manager service off and wait until the next version within 6 months. The Linux OS is hardened enough that I would feel confident doing so."
[18:40] <jdong> urgh he left
[18:40] <jdong> was just gonna tell him that's not a good assumption to make
[18:41] <cjwatson> tell him in the forums
[18:42] <jdong> yep just did
[18:44] <jdong> cjwatson: quick question of curiousity, there's often backports that I reject because they b-d on a newer version of a library that isn't strictly necessary (i.e. used to force a build against the newer version in the development distro)... I'm wondering if we can work out some kind of procedure for handling these
[18:44] <jdong> i.e. either loosening the dep in Universe, or a trivial source-change backport
[18:45] <jdong> which ever is easier on you guys :)
[18:49] <cjwatson> jdong: loosening the build-dep can cause some problems down the line, particularly if an architecture is behind; I'd rather have somebody who cares about backports in core-dev so that they can do source-change uploads when necessary
[18:49]  * cjwatson -> dinner
[18:51] <jdong> cjwatson: ok, good point, there's a few members that are in core-dev so that route sounds good for now; thanks for your time
[18:52] <SEJeff> Would I be correct in assuming someone from Canonical is aware of the fact that security.ubuntu.com is returning 403 when trying to download samba updates?
[18:52] <pipegeek> weeeeeird
[18:52] <elmo> SEJeff: yes, the update causes a regression, the 403 is deliberate.  a fixed package is being worked on
[18:53] <SEJeff> elmo, ok good. Just making sure
[18:53] <dajhorn> elmo: For how much time was the dud package available?
[18:53] <pipegeek> I mentioned what I thought to be a bug in compiz-fusion in here a while ago---when the system was under load while compiz was running, x would crash within a few minutes (I've been testing with some trivial mencoder task)
[18:54] <elmo> dajhorn: I don't know offhand, sorry
[18:54] <pipegeek> Turns out that's not accurate; it only happens when there's a cpu-intensive task *running in yakuake*.
[18:54] <dajhorn> elmo: Np.  (My dev boxes got it.) *shrug*
[18:54] <pipegeek> Just wanted to say that "aloud".  Off to launchpad
[18:55] <pipegeek> Sweet!  And the bug already exists!
[18:55] <pipegeek> :D
[18:55] <pipegeek> and has since feisty :-\
[18:55] <jdong> if people don't mind me asking.... how did this samba regression happen?
[18:55] <pipegeek> errgh, sorry for giving you strace of my brain
[18:55] <pipegeek> ta ta
[18:55] <jdong> it seems to be a crash-on-start or crash-on-trivial-usecase
[18:56] <jdong> was the update not verified on these two releases?
[19:00] <Lutin> is there a good reason not to sync fltk ? (just asking because a debian package that fixes the ubuntu changes was released a month ago, but didn't get synced)
[19:01] <Kmos> Lutin: http://packages.qa.debian.org/f/fltk.html -> this one? it's removed
[19:02] <Lutin> Kmos: fltk1.1 actually
[19:02] <Kmos> ah :)
[19:07] <cjwatson> dajhorn: about 11 hours
[19:07] <dajhorn> cjwatson: Ty.
[19:08] <cjwatson> SEJeff: for the record you can always assume that 403 from security.u.c means "busted package, we're working on it"
[19:09] <SEJeff> cjwatson, ok. Just wanted to make sure someone was aware of it
[19:09] <cjwatson> it is part of the procedure for dealing with such breakage and there is no other situation in which that happens
[19:09] <cjwatson> (short of wildly implausible bugs)
[19:09] <SEJeff> cjwatson, Isn't that what qa is for?
[19:09] <cjwatson> SEJeff: of course, but there is always a need for a fallback
[19:10] <cjwatson> SEJeff: by their nature, security updates cannot be QAed as widely as normal updates, and sometimes things go wrong; even then, sometimes things slip through the net
[19:11] <SEJeff> cjwatson, I figured Canonical had an automated testing suite. Not to dog on you or anything... but things like the xorg update debacle in Feisty are unacceptable for a distro this big.
[19:11] <SEJeff> Keep up the good work
[19:11] <slangasek> SEJeff: Samba upstream and Red Hat have the same bug in their security update
[19:11] <jdong> I made a comment on the bug report (bug #163042) about this...
[19:11] <ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Critical,In progress] https://launchpad.net/bugs/163042
[19:12] <jdong> am I correct in understanding that on Dapper applying this patch results in Samba not starting at all?
[19:12] <cjwatson> SEJeff: this procedure was put in place after the X update problems in Dapper (which I suspect may be what you mean)
[19:12] <SEJeff> cjwatson, yes. Ok good
[19:12] <SEJeff> Get the distros mixed up. Have played with it since Warty
[19:12] <cjwatson> and in general we significantly tightened procedures after that
[19:13] <cjwatson> one item slipping through the net does not mean that the procedures suck. obviously we review each failure to see how we could have avoided it
[19:13] <slangasek> SEJeff: for the issue that's affecting feisty and gutsy, that is; for the bug that's specific to dapper/edgy, that's our fault, but there's not much sense in making a fixed package available that fixes that problem without also fixing the smbfs problem, for which we're still waiting on upstream...
[19:14] <SEJeff> bugs are inevitable. It isn't anyone's fault as it is just part of the game.
[19:15] <slangasek> bugs may be inevitable on the whole, but that's not a reason for us to not take responsibility for them :)
[19:19] <keescook> jdong: no, it didn't show up in Dapper testing.  it takes a specific configuration.
[19:23] <jdong> keescook: ah, ok, that's good to hear
[19:27] <minghua> jdong: May I poke you again for bug 160361?
[19:27] <ubotu> Launchpad bug 160361 in gutsy-backports "Please backport scim-hangul 0.3.1-1ubuntu1 from hardy" [Undecided,New] https://launchpad.net/bugs/160361
[19:41] <jdong> minghua: ah sure lemme take a look at that
[19:41] <jdong> minghua: taken care of, sorry for the long delay
[19:42] <minghua> jdong: Thanks!
[20:06] <Mez> er, what the ****
[20:06] <Mez> Err http://security.ubuntu.com gutsy-security/main libsmbclient 3.0.26a-1ubuntu2.1
[20:06] <Mez>   403 Forbidden
[20:07] <slangasek> Mez: a security update that was pulled due to an undetected regression; see above
[20:07] <Mez> slangasek, can't see above
[20:07] <slangasek> ok, then see bug #163042 :)
[20:07] <ubotu> Launchpad bug 163042 in samba "nmbd crashes after routine Dapper upgrade" [Critical,In progress] https://launchpad.net/bugs/163042
[20:07] <cjwatson> Mez: 403 from the archive always means "broken update, we are working on it, no need to tell us"
[20:08] <Mez> cjwatson, cool, thanks... not actually come across it before... but I guess thats caus eI usually run the dev versions :d
[20:08] <Mez> think this is the longest I've stayed on the current release1
[20:08] <Mez> o_O Hobbsee is part of ubuntu-archive?
[20:08] <Mez> uber :D
[20:32] <nenolod> hi.
[20:32] <nenolod> oh, already reported.
[20:32] <nenolod> :P
[20:32] <somerville32> lol
[20:32] <somerville32> A lot of noise of this
[20:34] <somerville32> s/of/from
[20:50] <emgent> heya people :)
[21:15] <puzzud> puzzud: Hey guys, it appears some samba files were uploaded/created today that I can not access... are the file permissions correct with:  http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient_3.0.26a-1ubuntu2.1_i386.deb  ?
[21:15] <drarem> so i have glade and anujta, is that all i need for gtkmm or is there another recommended route to go?  I want to make cross-compatible applications (using the ftp lib stuff) and a nice gui
[21:16] <cjwatson> puzzud: the update was broken and has been withdrawn deliberately to avoid breaking more people's stable systems; a fix is being worked on
[21:16] <drarem> in glade, how do you resize those controls??
[21:27] <puzzud> cjwatson: do you think it will take long?
[21:27] <cjwatson> puzzud: I cannot give you a time estimate, but it's being worked on pretty hard
[21:27] <cjwatson> puzzud: the version you have is fine though; the security problem was "just" a denial of service and not believed to be exploitable, so don't panic
[21:29] <puzzud> o shit
[21:29] <puzzud> sorry
[21:29] <keescook> puzzud: new versions should be available in about 3 hours, I'd guess.
[21:30] <puzzud> thx keescook, my kubuntu system is now in a sort of mixed chaotic state with dependencies on the broken samba
[21:30] <jdstrand> puzzud: updates have been uploaded and are currently building
[21:31] <Chipzz> heh
[21:31] <Chipzz> is this normal?
[21:31] <Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/smbclient_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
[21:31] <Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
[21:31] <Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-common_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
[21:31] <puzzud> Chipzz: yea
[21:31] <Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient_3.0.26a-1ubuntu2.1_i386.deb  403 Forbidden
[21:31] <puzzud> Chipzz: fixes are being worked on a broken update
[21:31] <keescook> puzzud: you should be able to force downgrades   apt-get install samba=3.0.22-1ubuntu4.2 etc
[21:31] <keescook> (e.g. for edgy)
[21:32] <cjwatson> Chipzz: discussed about ten or fifteen lines above your question
[21:32] <puzzud> maybe I should change the topic again and put the samba info in there ;)
[21:33] <puzzud> hehe
[21:33] <Chipzz> cjwatson: just outside of my what was visible on my screen apparently ;)
[21:34] <cjwatson> when it's something that might be considered commonly visible, a little use of scrollback wouldn't go amiss
[21:34]  * Chipzz pleeds guilty
[22:04] <somerville32> Wouldn't it be a good idea to put debootstrap for hardy in the ubuntu developer team PPA?
[22:05] <somerville32> That way instead of downloading it manually, developers can add it to their sources list and always have the most up to date copy
[22:08] <jdong> somerville32: I could've sworn I backported debootstrap from hardy to gutsy already....
[22:08] <LaserJock> yeah, generally it's backported
[22:09] <jdong> debootstrap | 1.0.7~gutsy1 | gutsy-backports | source, all
[22:09] <somerville32> I guess I did it before it was backported
[22:09] <cjwatson> I also backported it to dapper+edgy+feisty this evening
[22:10] <cjwatson> so people can pin it from -backports
[22:12] <jdong> awesome, thanks cjwatson :)
[22:32] <LaserJock> keescook: are USNs sent out after a fix has been released?
[22:38] <keescook> LaserJock: yes -- there are some automated systems that expect to be able to download the mentioned files, etc.
[22:43] <LaserJock> keescook: so is there any good way of seeing security TODO stuff for Universe at this time? without grubbing around a lot
[22:43] <LaserJock> Fujitsu might know
[22:44] <LaserJock> keescook: and is all security for Main apps handled by Canonical?
[22:48] <Fujitsu> LaserJock: Hi. There's no easy way to see it, because LP is braindead. There's no way to search on a security flag, and no way to search a subscriber's bug list by component.
[22:49] <LaserJock> Fujitsu: so there's really no way to have a list of CVEs for Universe?
[22:49] <Fujitsu> You can search a project/distro/distroseries for a subscriber's bugs by component, but then you need to perform 6 separate searches, and a number of the bugs will be displayed a large number of times, due to another LP bug.
[22:49] <Fujitsu> LaserJock: You *can* search for bugs with CVEs linked, but that's not all of them.
[22:50] <Fujitsu> And we haven't got anywhere near all of them filed... because LP's CVE tracking features are braindead.
[22:50] <LaserJock> hmm, that's a bit ... suboptimal :-)
[22:51] <LaserJock> what's done for Main?
[22:51] <Fujitsu> ubuntu-security gets emailed about all security bugs, I guess.
[22:51] <Fujitsu> But non-Canonical people can't be on ubuntu-security, so we will never be emailed about universe bugs.
[22:52] <LaserJock> hmmm, again suboptimal for Universe
[22:52] <LaserJock> can we get any data from Debian?
[22:52] <Fujitsu> Slightly, yes.
[22:52] <Fujitsu> That's what I was working on last night.
[22:53] <Fujitsu> I've attacked their security tracker so that it tracks feisty/gutsy/hardy too.
[22:53] <LaserJock> ok
[22:55] <Fujitsu> LaserJock: Wanting to help with getting universe slightly less completely insecure and dangerous?
[22:56] <LaserJock> not sure yet
[22:56] <LaserJock> I'm actually more interested in some Main packages
[22:56] <LaserJock> but maybe :-)
[22:57] <sistpoty> Fujitsu: btw.: who can upload to security pockets for universe nowadays?
[22:57] <Fujitsu> sistpoty: keescook.
[22:57] <Fujitsu> As well as jdstrand and infinity, I guess.
[22:57] <sistpoty> Fujitsu: ah... does that hinder current security updates?
[22:58] <Fujitsu> Not so much normally, but with UDS and AllHands there is a fairly large backlog.
[23:01] <keescook> LaserJock: I haven't found a good way to look a subscription AND universe package lists.  :(
[23:02] <keescook> LaserJock: Canonical is committed to fixing issues in main, but help is always appreciated.  :)  There is a lot of work to be done.
[23:02] <LaserJock> keescook: but how does one help if they are a community dev?
[23:03] <Fujitsu> LaserJock: Find a bug, attach a debdiff. Same as universe.
[23:03] <keescook> LaserJock: I'm hoping (next week if I can managed it) to publish the ubuntu CVE tracker in a more searchable form.  LP's handling of CVEs isn't quite ready for useful reports yet.
[23:03] <Fujitsu> Or a lot of debdiffs, as we now have a lot of releases.
[23:03] <LaserJock> can I see the bugs?
[23:03] <Fujitsu> Unless they're embargoed.
[23:03] <Fujitsu> Which not many are.
[23:03] <keescook> LaserJock: as Fujitsu says.
[23:03] <Fujitsu> keescook: We have a CVE tracker?
[23:03] <Kopfgeldjaeger> n8
[23:03] <Fujitsu> LP's is useless, and feature requests to make it useful have been open for 2.5 years.
[23:04] <keescook> Fujitsu: here'
[23:04] <keescook> erk
[23:04] <keescook> LaserJock: here's the URL I use: http://tinyurl.com/2gjo2q
[23:04] <keescook> Fujitsu: yeah, it's in a bzr tree: http://people.ubuntu.com/~pitti/bzr/ubuntu-cve/
[23:05] <LaserJock> keescook: yikes, that's quite a list
[23:05] <Fujitsu> keescook: What do you think of trying to take some data from Debian's security-tracker?
[23:05] <LaserJock> obviously some are more important than others :-)
[23:05] <Fujitsu> They maintain a list of NFUs, etc, which would be nice to share.
[23:05] <keescook> Fujitsu: we already try to share.  What I'm hoping to do is publish sort of a "merged view"
[23:05] <Fujitsu> keescook: I didn't know that existed.
[23:05] <keescook> kind of like MoM but for security updates.
[23:06] <Fujitsu> keescook: That would be really great. If you want any help, I'd be glad to, as it's probably better than hacking up the secure-testing code to do Ubuntu releases too.
[23:08] <keescook> Fujitsu: right, my first step was to actually examine the secure-testing code.  I wanted to work as closely as possible to their svn, but it's not optimized for note-taking and lots of packages/releases.  The debian kernel-sec tracker's layout was better for that.
[23:08] <keescook> so I ended up modelling it after that.
[23:10] <Fujitsu> keescook: Is there another branch somewhere, or have you just not commited updates for a couple of months.
[23:10] <Fujitsu> *?
[23:11] <keescook> Fujitsu: I think the working directory isn't being updated, but if you "bzr branch" from it, it should have very recent commits
[23:12] <Fujitsu> keescook: Ah, right, pushes don't update the working copy.
[23:12] <keescook> One piece of code that didn't get finished in the re-arch is the changelog parser.  Then it can warn about or assist in closing CVEs where a changelog entry is found.
[23:12] <Fujitsu> keescook: Does it scan *-changes?
[23:13] <keescook> Fujitsu: the prior code actually browsed the changelog tree on the archive, and spidered the Debian changelog URLs.  it's a bit heavy.  :P
[23:14] <Fujitsu> ... ouch.
[23:14] <Fujitsu> I guess it works if it runs in the DC, though.
[23:15] <Amon_Re> Hey peeps
[23:15]  * Amon_Re is looking for any good instructions on building .deb files
[23:15] <Fujitsu> Amon_Re: -> #ubuntu-motu (see /topic)
[23:15] <jpatrick> !packaging > Amon_Re
[23:16] <Amon_Re> thx mates ;)
[23:16] <Lutin> keescook: just wanted to make sure : do you have changes to dsniff planned (in hardy) ? otherwise, I'll request a sync
[23:17] <keescook> Lutin: nothing from me, if the ubuntu changes are in Debian, yeah, for for a sync.
[23:17] <Lutin> keescook: ok
[23:41] <Burgundavia> LaserJock: you finished your PHD yet? Do we need to stage an intervention?
[23:44]  * Fujitsu notes that this unstable/development release is actually unstable for him.
[23:51] <cjwatson> keescook: btw, I'll try to get to the openssh thing soon and get it fixed in hardy
[23:51] <cjwatson> I'd rather do it by upgrading wholesale to 4.7 though