[00:24] <Megaqwerty> RAOF: I think I figured it out, as it appears to be working. It was actually quite simple, I just had to run sudo pbuilder create --mirror "http://xnv3.xandros.com/xs2.0/pkg" --distribution "xs2.0-xn"
[01:17] <bddebian> Heya gang
[01:18] <RAOF> Howdie bddebian
[01:18] <bddebian> Hi RAOF
[01:18]  * RAOF is confused.  Why doesn't 'howdie' tab-autocomplete?
[01:19] <bddebian> heh
[01:19] <RAOF> That'd be totally awesome.  Baysian tab-autocomplete for irc :)
[01:22] <RAOF> How shall I abuse this laptop today?  Trying ext4?  Seeing how much works with nouveau-gallium?  Manually installing xorg git on / again?
[01:22] <jussio1> ext4 :D
[01:23] <protonchris> I vote for ext4
[01:23] <frenchy_> Hi All!
[01:24] <RAOF> The problem there is I'd need to rebuild the kernel with ext4 enabled :)
[01:24] <jussio1> RAOF: get on it then :D
[01:25]  * jussio1 wonders what he is still doing  up...
[01:25] <jussio1> @now helsinki
[01:25] <ubotu> Current time in Europe/Helsinki: March 23 2008, 03:25:14 - Next meeting: Server Team in 3 days
[01:26] <frenchy_> Just installed Hardy beta, went to update my package (me-tv) in universe and the old control file says 'unstable' (as synced from debian) ... but ... uupdate has changed it to 'hardy'.  What am I supposed to do here?
[01:26] <frenchy_> Does it really matter?
[01:29] <adrian2002ca> so how do i get started developing...im a pretty good programmer, pretty new to ubuntu(a month)...ive looked at the wiki and I still don't know how to get an <experienced developer to help me along>
[01:31] <adrian2002ca> anyone?
[01:31] <persia> adrian2002ca: The best way is to start working on some bugs, and ask specific questions if you get stuck.  Others in the channel will likely provide advice of one sort or another.
[01:32] <persia> As you develop a specific area of interest or focus, you will find a group of people working on similar things with whom you will develop closer relationships.
[01:32] <frenchy_> adrian2002ca: Did you want to develop something new?
[01:33] <persia> adrian2002ca: You might want to take a look at https://wiki.ubuntu.com/MOTU/Contributing for some guidelines on processes and hints, and https://MOTU/TODO for some lists of things that need doing.
[01:34] <adrian2002ca> i'm not sure(although i would like to take some of my ideas and make them into programs), i guess doing bugs would help with the <initiation>
[01:36] <persia> adrian2002ca: Well, it depends on the sort of developer you wish to be.  This channel is mostly concerned with maintenance programming for Ubuntu universe, which is lots of bugfixes and integration work, rather than new programs.
[01:37] <adrian2002ca> persia: sounds good, since i shall start here :D
[01:37] <adrian2002ca> so what languages are used mostly C++?
[01:37]  * slangasek twitches
[01:38] <adrian2002ca> lol what???
[01:38] <slangasek> working with C++ code might account for most of the *time* spent, anyway... :)
[01:38] <adrian2002ca> oo sounds good
[01:38] <slangasek> it sounds good to work with a language that's time-consuming?
[01:39] <slangasek> if you're talking about packaging work, the top languages to know are POSIX shell, make, and python
[01:39] <adrian2002ca> naw, it just means that i dont have to learn a new language
[01:40] <adrian2002ca> and those are the ones i need to learn then\
[01:40] <frenchy_> adrian2002ca: I haven't time to argue the pros and cons of programming but C++ is fine.  I have a project written in C++, took me 6 months, 1 developer.  And it's better than a lot I've seen.
[01:40] <slangasek> that would depend on where you end up getting involved
[01:41] <adrian2002ca> ok guys...let the crunching begin :)
[01:41] <slangasek> if you're trying to contribute to a package whose build scripts are written in python, knowing python is relevant.  If you're trying to fix a bug in debian/rules, that's make.  A lot of packaging bugs are fixed without doing any actual programming at all.
[01:43] <frenchy_> adrian2002ca: I'm getting the impression that you are more of a programmer (like myself).  Interested in creating software rather than packaging.
[01:43] <frenchy_> adrian2002ca: Happy to be corrected.
[01:43] <adrian2002ca> frenchy_:  yes, that's correct
[01:43] <RAOF> Hobbsee, Fujitsu: If you're interested, it seems I've managed to get a little bit more attention for our xorg bug: https://bugs.freedesktop.org/show_bug.cgi?id=14449
[01:44] <adrian2002ca> im a bit new to ubuntu in general
[01:44] <ubotu> Freedesktop bug 14449 in Server/general "A key gets stuck in OpenGL applications" [Major,New]
[01:44] <persia> adrian2002ca: bug #200406 is a crasher bug in a c++ program, if you want to take a look at that.
[01:44] <ubotu> Launchpad bug 200406 in torcs "torcs-bin crashed with SIGSEGV in GfParmGetStr()" [Medium,New] https://launchpad.net/bugs/200406
[01:44] <adrian2002ca> persia: ill see what i can do ..ill get back to you...dont expect much :P
[01:45] <frenchy_> adrian2002ca: There are plenty of ways to contribute.  Just remember though, in general, people don't code for Ubuntu, they code for linux/unix.  Then someone packages it for ubuntu afterwards.
[01:45] <slangasek> frenchy_: for me-tv: assuming you intend to continue maintaining it in both Debian and Ubuntu (which I recommend), you'll need to change the target dist in the changelog back to 'unstable' for upload to Debian; packages that list "hardy" there get rejected, since it's an invalid target
[01:45] <persia> adrian2002ca: No problem.  This is of the harder class of C++ programming intensive bugs.  There are lots of easier bugs out there, some of which also are C++ bugs.  Good luck.
[01:46] <slangasek> frenchy_: I guess that the uupdate script in Ubuntu has been modified to use the Ubuntu dist names, maybe, or invokes a script which does
[01:46] <adrian2002ca> persia: thanks :D
[01:46] <frenchy_> slangasek: Cheers.  Understood.  But I was trying to update my PPA when this happened.  i.e not a proper upload to hardy.
[01:47] <slangasek> frenchy_: well, for a ppa you need to use the Ubuntu release names as well, yes
[01:47] <slangasek> since the ppa has to know which version of Ubuntu to build against
[01:47] <frenchy_> slangasek:  Ta.
[01:47] <adrian2002ca> frenchy_:  oh yea, im still new to the whole community
[01:50] <frenchy_> slangasek: Yeah, I hadn't thought that through.  I understand what's gone on now.  Thanks again.
[01:51] <bddebian> persia: boswars is in now
[01:51] <emgent> heya people
[01:52] <bddebian> Hello emgent
[01:52] <adrian2002ca> so my first question is: am i right when i assume that StacktraceSource.txt along with the source file would be the most important docs to look at?
[01:52] <persia> bddebian: Excellent.  Are you filing the FFe so we can drop bos and statagus, or do you need someone else to do it?
[01:52] <persia> adrian2002ca: Yes.  Precisely.
[01:53] <adrian2002ca> persia: engouraging, thank you
[01:53] <bddebian> persia: Hmm, I hadn't really thought about it
[01:54] <persia> bddebian: Hmm.  To ask a different question, is it worth pushing boswars for hardy?  The website made it look good, but if it needs polishing, intrepid might be better.
[01:56] <bddebian> Probably
[01:56] <persia> Well then, congrats anyway :)
[01:58] <Fujitsu> FFes are needed even for bugfix releases now, aren't they?
[01:59] <persia> No.  Only for feature freeze exceptions.
[01:59] <Fujitsu> `Up through Alpha 6, if a MOTU believes upload of a new upstream release that just has bug fixes in it is warranted, they may upload it using this process:'
[01:59] <persia> Hmm...
[02:00] <persia> I still don't think it's a FeatureFreezeException, but I didn't think all uploads needed motu-release review until RCFreeze.  Anyone around from motu-release to clarify the current viscosity of Hardy?
[02:01] <adrian2002ca> persia: in StacktraceSource.txt, an entry like #7  0x0000000000401189 in _start ()  is not an error right?
[02:02] <adrian2002ca> persia: unless it says error underneath?
[02:02] <persia> adrian2002ca: No.  It's just a report that in frame 7 in the stack, the program was at location 0x0000000000401189 processing the function call _start ().  The crash happened in frame 0.  The other frames can give you context to track down the problem.
[02:03] <adrian2002ca> persia: aaahhh, that makes sense...
[02:03] <adrian2002ca> ...download ing source now(146 MB of it) and just making sure i know what im doing lol
[02:03] <Hobbsee> persia: i would have expected RC.
[02:03] <persia> Personally, I find Stacktrace.txt to be the most helpful, as it contains also the values for the variables, which can help to understand the problem.  Many times variables are used before they are set, etc.
[02:04] <persia> Hobbsee: Could you expand on that a little?
[02:04] <bddebian> persia: Of course I haven't tried to build it on hardy yet.  It's a large package :-(
[02:04] <Hobbsee> persia: i would have expected that all uploads needed motu-release review after RC>
[02:05] <Fujitsu> Hobbsee: Do I need to file a full-blown FFe request for a security fix release, now?
[02:05] <Hobbsee> persia: just like all main uploads will need review after the rc freeze
[02:05] <slangasek> in this case, the variables show you that the innermost frame has a first argument of 0x0 being passed to it as the "handle", which isn't supposed to happen and causes a null pointer dereference
[02:05] <Hobbsee> well, rc freeze.
[02:06] <persia> Hmmm...  I don't see an explicit RC Freeze listed in the release schedule this time.  Is it 10th April?
[02:06] <persia> slangasek: When do you expect to declare the RC Freeze?
[02:06] <Hobbsee> slangasek: would be able to tell you
[02:07] <Hobbsee> Fujitsu: i doubt it.
[02:08] <slangasek> persia: pre-announced at RC minus 10 days; https://wiki.ubuntu.com/ReleaseCandidateProcess
[02:08] <Hobbsee> slangasek: most people won't know about that link.  it only became public last cycle :)
[02:08] <Fujitsu> Hobbsee: The wiki page says I should, but I've seen people avoid it more recently.
[02:08] <slangasek> Hobbsee: that's fine, I'm just doing my part to disseminate it opportunistically :-)
[02:08] <Hobbsee> Fujitsu: can you put it on the meeting agenda?
[02:08] <Hobbsee> slangasek: :)
[02:09] <persia> slangasek: Thanks.  Any chance you could add 7th April to https://wiki.ubuntu.com/HardyReleaseSchedule (us peons aren't supposed to edit the schedule).
[02:09] <Fujitsu> Hobbsee: We'll probably have hit another freeze by then.
[02:09] <slangasek> yes, a bit inconsistent to have the BetaFreeze on there but not the RCFreeze, innit?
[02:10] <Hobbsee> Fujitsu: it's friday
[02:11] <Fujitsu> Hobbsee: OK, I'll file an FFe now, and add it to the agenda.
[02:11] <Hobbsee> thanks
[02:11] <slangasek> alas, there's no page in the wiki yet that properly describes the RCFreeze.  But there's a page for some guy named Mark Freeze...
[02:13] <Hobbsee> RAOF: please add, to the LP plugin, a thing that will let us search for projects.
[02:14] <slangasek> persia: done
[02:14] <persia> slangasek: Thank you.
[02:15] <protonchris> Anybody up for sponsoring a sync?  https://bugs.launchpad.net/ubuntu/+source/libgdamm3.0/+bug/190744
[02:15] <ubotu> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [High,Confirmed]
[02:15] <ScottK2> emgent: Are you up for another set of security fixes?
[02:15] <persia> Ah.  FinalFreeze.  Good name.
[02:15]  * persia hunts for Acts of God to use as upload excuses
[02:15] <Hobbsee> hehe
[02:16] <ScottK2> God made me type dput?
[02:17] <bddebian> heh
[02:25] <Fujitsu> Is "upstream is stupid and rewrites gigantic chunks of code in security updates, so it's always good to have the latest version at release" a valid reason for a FFe for a security+featureful new upstream?
[02:30] <frenchy_> Fujitsu: Ha, don't we have that same problem with FireFox.
[02:30] <frenchy_> ?
[02:31] <slangasek> Fujitsu: it's a good reason to /ask/ for an FFe... :)
[02:35] <adrian2002ca> quick question...when i see this in the bug report: /usr/games/torcs: line 52: 17394 Segmentation fault (core dumped)  $LIBDIR/torcs-bin -l $LOCAL_CONF -L $LIBDIR -D $DATADIR $*.. , what file is the line number referring to?
[02:36] <slangasek> to /usr/games/torcs
[02:37] <adrian2002ca> oh, so its the binary...
[02:37] <adrian2002ca> i get it...nvm then
[02:37] <slangasek> /usr/games/torcs is not a binary, it's a script
[02:38] <persia> adrian2002ca: Actually, /usr/games/torcs is a shell script that sets some variables, and calls /usr/games/torcs-bin
[02:39] <adrian2002ca> persia: ahh..makes sense
[02:39] <adrian2002ca> all in all, that line number is thus not useful to me ]
[02:40] <adrian2002ca> unless i was reverse engineering to a much greater extent(no source)
[02:42] <adrian2002ca> ok bunny coming......gotta go lol
[02:43] <slangasek> ...bunny?
[02:43] <keescook> easter!
[02:43]  * persia has never seen some leave due to incipient bunny attack before
[02:43] <slangasek> keescook: which is tomorrow...?
[02:44] <keescook> slangasek: maybe he's in the future!
[02:44] <Fujitsu> Hey keescook.
[02:44] <slangasek> this explains everything
[02:44] <keescook> hiya Fujitsu
[02:46] <Fujitsu> Does someone from the mozillateam know about the ~60 CVEs that their packages are polluting the CVE lists with?
[02:46] <Fujitsu> (just for Hardy, that is)
[02:47] <keescook> Fujitsu: I think jdstrand was quizzing asac about it earlier in the weak.
[02:48] <Fujitsu> And 32 open sun-java* CVEs.
[02:48] <Fujitsu> Those two together make ~30% of the open Hardy CVEs.
[02:48] <keescook> yeah.  I was going to ask doko about java on monday
[02:48] <slangasek> "before you can be released with hardy, you must answer me these questions three, about a CVE..."
[02:50] <Fujitsu> It'd be really nice if LP finally got around to importing Debian bugs, and we could track CVEs there.
[02:50] <slangasek> somehow I don't think that will help much for java or mozilla :)
[02:51] <Fujitsu> It'd help for the other 210.
[02:51] <slangasek> tru
[02:54] <Fujitsu> keescook: Why is opera appearing in the Hardy universe list in the u-c-t report?
[03:21] <jdong> slangasek: updating hal seems to have fixed it :)
[03:21] <keescook> Fujitsu: urhmm... I only see opera in the "Partner" repo
[03:23] <Fujitsu> I see CVE-2008-1080 in opera on the universe list here.
[03:23] <ubotu> Opera before 9.26 allows user-assisted remote attackers to read arbitrary files by tricking a user into typing the characters of the target filename into a file input. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1080)
[03:23] <Fujitsu> Maybe it's because it's not actually in Hardy yet.
[03:23] <Fujitsu> So doesn't have PARTNER as a note.
[03:24] <Fujitsu> And it's not in main, so won't have SUPPORTED. So might well default to universe.
[03:24] <keescook> Fujitsu: ah! it might be due to not being able to "see" the partner source archive map.
[03:25] <keescook> Fujitsu: I have a local mirror, so I use ~/.source_map to define the mirror tree locations
[03:25] <keescook> when loading from the apt cache, there isn't a good way to get all the source lines for partner
[03:25] <keescook> (see scripts/source_map.py code)
[03:25] <Fujitsu> Ahh.
[03:25] <keescook> it's kind of hacky
[03:26] <keescook> I'm presently working on a makefile that will export the entire set of files into a browseable html tree too
[03:26] <Fujitsu> Is there any reason to keep kfreebsd bits in the archive when we don't have a kfreebsd port?
[03:26] <Fujitsu> keescook: That would be very nice indeed.
[03:27] <Fujitsu> At the moment there are a number of places one has to check for notes, and u-c-t's isn't browser-accessible.
[03:27] <keescook> Fujitsu: yeah, precisely.  and hopefully before Wed I'll have it publically published
[03:28] <Fujitsu> I noticed you appeared to be planning that soon. Very good.
[03:28] <keescook> :)
[03:32] <protonchris> Fujitsu or keescook:  Either of you two up for sponsoring a sync?  Motu-release has already approved.  https://bugs.launchpad.net/ubuntu/+source/libgdamm3.0/+bug/190744
[03:32] <ubotu> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [High,Confirmed]
[03:34] <slangasek> jdong: great; can you mention that in the bug report, so we can keep track?
[03:34] <keescook> protonchris: I can't at the moment -- I'm about to run out for a late dinner.
[03:35] <protonchris> keescook: thanks anyway.  What's for dinner?
[03:35] <keescook> protonchris: we're thinking Thai.  mmm noodles
[03:35] <protonchris> keescook: nice.
[03:36] <protonchris> I had some vietnamese for lunch.
[03:39] <keescook> protonchris: excellent!  there's a Pho place about a mile away that I try to visit a lot :)
[03:51] <jdong> slangasek: sure thing
[03:53] <adrian2002ca> so i am currently looking over the 200406 bug and i am asking myself which files are the source files I should look at...any suggestions?
[03:55] <RAOF> adrian2002ca: The stacktrace suggests that mainmenu.cpp will be involved _somewhere_.  In general, grep is your friend.
[03:55] <adrian2002ca> just trying to establish a set of actions i could use to try solving a problem
[03:55] <RAOF> adrian2002ca: As in "grep GfParmGetStr **/*.cpp"
[03:56] <adrian2002ca> RAOF: aaahhh...i shall look for it....argh...so many directories :D
[03:56] <RAOF> That's what either -R or **/* is for :)
[03:56] <RAOF> (Depending on how cool your shell is).
[03:57] <adrian2002ca> oh,im not at home so im on the win machine lol...ill save that for later though :P
[03:59] <RAOF> Oh, dear.  You may want to install cygwin to get some sort of sane environment there :)
[04:00] <adrian2002ca> lol...i got bloodshed dev-C for IDE, just so i can take a peek at the code :)
[04:00] <emgent> ScottK2: now i'm here
[04:00] <emgent> :)
[04:01] <emgent> if you have some security bug to solve, for me, feel free to send mail.
[04:01] <emgent> now i have to go, sorry for delay
[05:17] <slytherin> doko: I have one problem. ant depends on java-virtual-machine & java2-runtime. But the main task of ant (compilation) needs a jdk (java-compiler). There is no package in openjdk-* which provides java-compiler. So one can not use ant fully with openjdk. Please let me know if I should file a bug for this and against which package (my guess is openjdk).
[06:34] <ScottK2> emgent: Have a look at the libnet-dns-perl sync that was just done.  The packages in Dapper/Edgy/Feisty/Gutsy need to be examined to see if they have the same problem.
[06:34] <ScottK2> slytherin: Earlier I was assuming it was a virtual package.  I didn't check to see if it actually was.
[06:38] <Fujitsu> ScottK2: I've seen you've done quite a few security-related syncs. When you do so, please ensure that you notify emgent or I so we can tell the CVE tracker about them.
[06:45] <ScottK2> Fujitsu: IIRC I've only done one and I think I linked the cve in the bug.  Do I need to do more?
[06:46] <Fujitsu> ScottK2: That unfortunately doesn't notify anyone. Perhaps subscribe motu-swat.
[06:47] <ScottK2> Fujitsu: OK.  Will do.
[06:47] <Fujitsu> ScottK2: It should notify someone, but that would make sense.
[06:48] <ScottK2> Well it turns out I'm not credible to have an opinion on Launchpad because I don't subscribe to the perspective that the U/I is improving.
[06:49] <ScottK2> Fujitsu: I don't file Launchpad bugs anymore because I'm not credible, so there's no point.
[06:50] <ScottK2> It turns out having an a strong feeling about the inherent fineness of CSS over tables is an essential prerequisite for being able to understand.
[06:50] <Hobbsee> ScottK2: no, you're not credible, because you don't have an open-enough mind.
[06:50] <ScottK2> Fujitsu: motu-swat subscribed on the one I did.
[06:50] <Fujitsu> ScottK2: Thanks.
[06:50] <ScottK2> Hobbsee: Well I do know what I like and LP is not moving towards it (U/I design wise).
[07:40] <slytherin> ScottK2: The main problem I am facing is that even if I install openjdk-*, when I install ant it will still pull gcj.
[07:45] <slytherin> ScottK2: Ahh, the latest update solves the problem partially. Now I need to file bug against ant.
[08:21] <Iulian> G'morning
[08:27] <slytherin> Iulian: Can you please change your nick to something else. I can't figure out whether it starts with 'I' or 'l'. :-)
[08:28] <Fujitsu> slytherin: Not using a serif font, then?
[08:29] <slytherin> Fujitsu: I am using whichever pidgin uses by default
[08:29] <Fujitsu> Ah. Pidgin. That would explain it.
[08:30] <\sh> moins
[08:33] <slytherin> Fujitsu: I used to use xchat long time back. But due to the multi-protocol functionality I use pidgin. Of course I only use it for IRC and gtalk and will probably move to empathy when it matures.
[08:33]  * Fujitsu uses irssi and Gajim.
[08:33] <Fujitsu> I used to use irssi+bitlbee, but decided to try Gajim, and liked it.
[08:33]  * \sh is scared by pidgin and kopete, too :)
[08:34] <Fujitsu> I like Kopete. But not for IRC.
[08:34] <\sh> na..multiprotocol clients are not my thing...everything works over xmpp
[08:35] <\sh> ...building wine 0.9.58...
[08:35] <Fujitsu> I only have use for MSNP and XMPP, but use a transport, so it's all XMPP. Gajim must be about the best XMPP client.
[08:36] <\sh> next to psi on the qt side of life :)
[08:36] <slytherin> Fujitsu: and what is your opinion of gossip?
[08:37] <\sh> and hopefully for ibex we get ejabberd 2.x and hopefulle the irc transport is much better, I'll start to use gajim + irc transport ;)
[08:40] <Fujitsu> slytherin: I couldn't get it working when I tried.
[08:41] <Iulian> slytherin: Hehe
[08:41]  * Iulian is using irssi
[08:44]  * \sh goes back to sleep and comes back later...
[08:48] <Iulian> slytherin: Ohh, btw, that package needs notify-sharp which is not packaged yet. I can't get it to work without it.
[08:48]  * Iulian waits for slomo__ to package notify-sharp :)
[08:53] <Iulian> The report is pretty old - see bug 139356 and debian bug 354876
[08:53] <ubotu> Launchpad bug 139356 in ubuntu "[needs-packaging] Please package notify-sharp" [Wishlist,Incomplete] https://launchpad.net/bugs/139356
[08:53] <ubotu> Debian bug 354876 in wnpp "ITP: notify-sharp -- CLI bindings for libnotify" [Wishlist,Open] http://bugs.debian.org/354876
[09:09] <sebner> Good morning and Happy Easter (for them who care) :)
[09:29] <Nafallo> hehe. hilights :-P
[09:30]  * Nafallo blames Fujitsu and \sh_away ;-)
[09:33] <frenchy_> Good evening ladies and gents, I'm awaiting testers for my application (could take days) ... in the meantime I was wondering if I could look at a couple of bugs.  I'm a C/C++ guy.
[09:34] <frenchy_> Also, what's the goal here?  Are we still fixing things for Hardy?
[09:34] <Fujitsu> Nafallo: You highlight Gajim, then?
[09:34] <Fujitsu> frenchy_: For another month, yes.
[09:34] <Nafallo> Fujitsu: ye :-)
[09:34] <Fujitsu> I'm not sure what else we would be doing before Hardy release.
[09:35] <frenchy_> Fujitsu: I though that we'd be all done-and-dusted ... you know, on top of things ...
[09:35] <frenchy_> Ha ... just kidding.
[09:36] <frenchy_> Can anyone suggest a couple for me to look at?
[10:14] <asac> Fujitsu: where is the list of open CVEs for hardy?
[10:15] <Fujitsu> asac: I'll push the HTML somewhere. Wait a sec.
[10:16] <Fujitsu> asac: http://people.ubuntuwire.com/~fujitsu/cves.html.
[10:16] <asac> Fujitsu: where do you get them from?
[10:17] <Fujitsu> asac: ubuntu-cve-tracker. It will be publicly announced within the next few days, I believe.
[10:17] <asac> ok
[10:17] <asac> i haven't been asked about those
[10:17] <asac> just about a few that were not properly documented for the stable releases
[11:51] <frenchy_> Ok then, can someone tell me where I get of my ass and do it myself?
[11:51] <frenchy_> https://bugs.edge.launchpad.net/ubuntu/hardy/+bugs?
[11:52] <persia> frenchy_: http://people.ubuntu.com/~ubuntu-archive/NBS/, http://builder.ubuntuwire.com:9998/dist/hardy/arch/i386, http://qa.ubuntuwire.com/bugs/rcbugs/ should be enough links to start.  Please complain again when you run out :)
[11:57] <frenchy_> persia: Thanks.
[11:57] <frenchy_> persia: I just found this page, https://wiki.ubuntu.com/MOTU/TODO/Bugs is that a good parent page?
[11:58] <frenchy_> persia: http://people.ubuntu.com/~ubuntu-archive/NBS/ ... what am I supposed to do with that?
[11:58] <frenchy_> persia: It's just a list of files.
[11:59] <persia> frenchy_: Each of those is a package that is no longer built from the current sources in the repositories.
[11:59] <persia> For those where the size is not 0, the file provides a list of everything that depends on the specified package.
[12:00] <persia> All of those need to be migrated to not depend on the packages no longer built from source.
[12:01] <persia> https://wiki.ubuntu.com/MOTU/TODO/Bugs is also a good source.  There's lots of things to do :)
[12:01] <frenchy_> persia: So pick the biggest file and go?
[12:01] <persia> Yep :)
[12:01] <Hobbsee> persia: slangasek should be able to refresh the NBS list, on request, too
[12:02] <persia> (And always remember when updating a package to check the bugs page for that package to see if someone else is working on the package, or if there are other bugs that can easily be fixed at the same time (respecting the current state of freezes)
[12:02] <persia> )
[12:02] <persia> Hobbsee: Doesn't that happen automatically every 6 hours anyway?
[12:03] <Hobbsee> unsure
[12:03] <frenchy_> persia: Got it.
[12:15] <frenchy_> Can I do this from Gutsy?  The wireless on my Hardy Beta is broke real good.
[12:16] <sistpoty> hi folks
[12:16] <sebner> persia: was my reminder mail ok? And do you even *recieved* it?
[12:16] <persia> For some of it, yes.  For others, maybe not.
[12:16] <persia> sebner: Yes to both counts.
[12:16] <sebner> persia: ok. thx :)
[12:17] <sebner> aloha sistpoty
[12:17] <sistpoty> hi sebner
[12:18] <sebner> sistpoty: archive admins rock. 13 syncs done from me
[12:18] <sebner> sistpoty: this night :)
[12:18] <sistpoty> heh
[12:27] <frenchy_> persia: Anyone: So am I to late for https://edge.launchpad.net/ubuntu/+source/clutter-gtk/0.4.0-1 loks like it was marked SUPERSEDED.
[12:28] <persia> Superceded would mean you are indeed too late.
[12:28] <frenchy_> There's no bugs page ... Am I looking at the right thing?
[12:28] <frenchy_> persia: Cool ... next.
[12:28] <persia> https://bugs.launchpad.net/ubuntu/+source/clutter-gtk/ (although there are none shown)
[12:29] <Iulian> Does anyone have any ideas about what I can use instead of http://paste.ubuntu.com/6009/plain/
[12:30] <Iulian> I'm using libglade2-0 because libglade-2.0 is a virtual package.
[12:31] <jeromeg> Iulian: i think that you need to add the -dev version of the package to build
[12:32] <Iulian> jeromeg: Ok, what about gtk+-2.0 and Wand gmodule-2.0?
[12:32] <jeromeg> Iulian: libglade2-dev
[12:32] <jeromeg> should be ok
[12:32] <jeromeg> libgtk2.0-dev
[12:33] <jeromeg> i'm searching the others, 2 sec
[12:34] <Iulian> Ok, thank you!
[12:34] <jeromeg> no problem
[12:35] <jeromeg> Iulian: what are oyu packaging ?
[12:35] <jeromeg> *you
[12:36] <jeromeg> Iulian: libglib2.0-dev for gmodule-2.0
[12:36] <Iulian> gollage - http://gollage.sourceforge.net/
[12:39] <jeromeg> Iulian: for wand it should be libmagick9-dev
[12:39] <jeromeg> or libgraphicsmagick1-dev
[12:39] <Iulian> jeromeg: I have imagemagick already
[12:39] <jeromeg> the -dev package ?
[12:39] <Iulian> Nop
[12:40] <jeromeg> Iulian: build deps needs the -dev packages to build your package
[12:40] <jeromeg> Iulian: then you put the normal packages required as dependencies in the dep field
[12:41] <jeromeg> Iulian: does it work now ?
[12:41]  * Iulian is trying
[12:41] <jeromeg> ok
[12:41] <jeromeg> to find those packages easily, install apt-file
[12:41] <jeromeg> then do sudo apt-file update
[12:41] <jeromeg> and apt-file search wand for example
[12:42] <jeromeg> it will show you all packages containing a wand file
[12:49] <Iulian> Woohoo!
[12:50] <jeromeg> Iulian: works ?
[12:50] <Iulian> Yeah, finally.
[12:50] <Iulian> Thanks
[12:50] <jeromeg> no problem
[13:48] <afflux> sebner: morning :)
[13:50] <afflux> sebner: seems like you forgot to remove the link to your englisch-german dictionary in the motu meeting announcement ;)
[13:50] <sebner> afflux: omg. I hate copy and past xD
[13:50] <afflux> hehe :)
[13:51] <sebner> afflux: good afternoon, btw ;)
[15:41] <amarillion> Hey, how can I get debuild to ignore a .git directory?
[15:41] <amarillion> I've tried debuild -I.git but that doesn't work
[15:42] <persia> amarillion: That's specifically supposed to work.  Maybe you need a space?
[15:43] <james_w> amarillion: -i is probably what you want
[15:43] <james_w> plain -i already excludes .git so there's no need to specify it.
[15:44] <james_w> and -I is slightly different, see dpkg-source(1)
[15:44] <amarillion> Yeah, I didn't really understand the documentation about -i and -I
[15:44] <amarillion> but just -i works, thanks
[15:45] <sistpoty> hm... I guess I start to like bzr :)
[15:46] <james_w> sistpoty: why?
[15:46] <sistpoty> james_w: it finally does what I want (because I know how to do it right now *g*)
[15:46] <james_w> sistpoty: ah :-)
[16:27] <mohi> hi :)
[16:27] <mohi> would someone PLEASE help me? http://pastebin.ubuntu.com/6020/
[16:33] <civija> mohi: for support please go to #ubuntu channel
[16:34] <mohi> civija: they told me this is a bug and I should ask you! :s
[16:34] <emgent> ScottK2: do you remember a sync bug to libnet-dns-perl ?
[16:35] <sistpoty> mohi: can you file a bug against php5 please, with that output? (https://bugs.launchpad.net/ubuntu/+source/php5/+bugs) thanks!
[16:37] <mohi> sistpoty: sure dear :) but do you thing its related to php5? I think the pakage "libapache2-mod-php5" cant be configured by debconf! ???
[16:37] <mohi> think*
[16:37] <sistpoty> mohi: yes, and the source package of this package is php5 ;)
[16:37] <mohi> sistpoty: aha! ok! am I supposed to just paste the contents of paste bin there?
[16:38] <sistpoty> mohi: maybe add what you think might be related (e.g. giving answers in debconf or s.th.)
[16:39] <sistpoty> mohi: so the output should give pretty much clue of what's going on there already
[16:39] <sistpoty> s/so/though/
[16:39] <mohi> aha! :) thanks sistpoty. and dont you know what should I do for this? ;)
[16:41] <ScottK2> emgent: Bug 201454
[16:41] <ubotu> Launchpad bug 201454 in libnet-dns-perl "Please sync libnet-dns-perl 0.63-1 (universe) from Debian unstable (main)." [Medium,Fix released] https://launchpad.net/bugs/201454
[16:41] <sistpoty> mohi: not using php :P (seriously: now, I don't have too much clue about that perl error, but you could always try to fix the script, lives in /var/lib/dpkg/info/libapache2-mod-php5.postinst)
[16:41] <sistpoty> no instead of now even
[16:43] <mohi> aha.. thanks sistpoty :) (BTW its the Persian new year, Happy Norouz) ;) http://en.wikipedia.org/wiki/Nowruz
[16:43] <sistpoty> thanks :)
[16:43] <mohi> I'll show you my report soon.
[16:50] <slytherin> ScottK2: the build url you specified on the catch-all pycentral bug is not working
[16:50]  * ScottK2 looks
[16:50] <ScottK2> slytherin: Working for me.  Try http://builder.ubuntuwire.com:9998/job/19850
[16:51] <ScottK2> ... as an example
[16:51] <slytherin> ScottK2: The url in bug description does not specify a jib number
[16:52] <RainCT> slytherin: you've to replace the x with the job number
[16:52] <mohi> sistpoty: i did : https://bugs.launchpad.net/ubuntu/+source/php5/+bug/205608
[16:52] <RainCT> slytherin: which you will find below in the report
[16:52] <slytherin> RainCT: oh, so it is different for each package. I didn't understand that
[16:52] <emgent> ScottK2: ok big thanks, i will work to it
[16:52] <sistpoty> mohi: thanks!
[16:52] <mohi> ;)
[16:54] <slytherin> RainCT: ScottK2: psyco build fine on my machine. Should I mark it invalid or does any one of you want to confirm?
[17:35] <ScottK2> Fujitsu: Would you please look at http://builder.ubuntuwire.com:9998/job/15994 and see if you can give me a hint where to go with that.  Is that a rebuild issue?
[17:35] <ScottK2> slytherin: Invalid.   Whatever it was that caused it to fail, it wasn't the python-central transition.
[17:47] <nixternal> ScottK2: bug 205631
[17:47] <ubotu> Launchpad bug 205631 in smb4k "Hardy Feature Freeze Exception for smb4k" [Undecided,New] https://launchpad.net/bugs/205631
[17:47] <nixternal> we have to many *release* teams :p  I subscribed ubuntu-release by accident :)
[17:58]  * porthose waves to everyone
[17:58] <porthose> Is Gdebi installed on the standard Ubuntu system
[18:03] <slytherin> porthose: yes.
[18:04] <sistpoty> nixternal: does it still need to mangle /etc/sudoers?
[18:04] <porthose> slytherin: thx
[18:11] <nixternal> sistpoty: it makes changes to /etc/sudoers, but it shouldn't mangle it
[18:12] <sistpoty> nixternal: it shouldn't make changes to it as well... that's quite scary imho
[18:12] <nixternal> the newer version is using the updated smb4k_cat system
[18:13] <nixternal> if it doesn't make the changes, then smb4k will never work
[18:14] <sistpoty> nixternal: why?
[18:18] <nixternal> advanced functionality really
[18:20] <emgent> ScottK2: yes, all vulnerable to CVE-2007-6341, i will attach debdiff, now i'm complete tests
[18:20] <ubotu> Net/DNS/RR/A.pm in Net::DNS 0.60 build 654, as used in packages such as SpamAssassin and OTRS, allows remote attackers to cause a denial of service (program "croak") via a crafted DNS response. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6341)
[18:20] <nixternal> it was fine last year when keescook and myself fixed it... keescook actually did a security check on it and it was published on the smb4k website...so if he says it is good, then it is good...he knows more about that stuff than I could ever know
[18:21] <emgent> hi \sh :)
[18:21] <sistpoty> nixternal: ok, if there was a security check done on it, that's good enough for me (though it's still a very, very, very broken design per se)
[18:21] <\sh> moins
[18:21] <sistpoty> hi \sh
[18:22] <\sh> emgent: I decided that you have to take the wireshark cve update :)
[18:22] <\sh> i won't make it because of time
[18:23] <\sh> emgent: bug #172283 I'm happy to discuss this with you...
[18:23] <ubotu> Launchpad bug 172283 in wireshark "[wireshark] multiple vulnerabilities" [Medium,Confirmed] https://launchpad.net/bugs/172283
[18:24] <nixternal> sistpoty: oh I totally agree
[18:24] <emgent> \sh: sure
[18:24] <sistpoty> heh
[18:24] <emgent> -hardened ?
[18:25] <\sh> emgent: I don't mind to discuss this here...because it could be interesting to others as well
[18:25] <emgent> ok cool
[18:25] <emgent> just a moment i go to see DSA
[18:25] <\sh> emgent: forget DSA
[18:25] <\sh> emgent: it is easy
[18:25] <\sh> emgent: and a bit delicate :)
[18:26] <\sh> emgent: learn yourself the ways of cherry picking crazy wireshark patches ;)
[18:26] <emgent> 17 CVEs good :)
[18:26] <\sh> na easy
[18:27] <\sh> emgent: i have severy patches already harvested from there
[18:27] <\sh> several even
[18:27] <\sh> emgent: ok...ready to start?
[18:28] <emgent> ok, sure, i saw CVE
[18:28] <\sh> nice :)
[18:29] <\sh> emgent: wireshark doesn't have a good patch system..they are allways working on trunk...so everything you pick from there, is mostly "new"
[18:29] <\sh> emgent: or fixed stuff
[18:29] <\sh> emgent: read the announcements, from wireshark for new versions, and attached to the usual CVE info websites
[18:29] <\sh> emgent: let's start with CVE-2007-6438
[18:29] <ubotu> Unspecified vulnerability in the SMB dissector in Wireshark (formerly Ethereal) 0.99.6 allows remote attackers to cause a denial of service via unknown vectors.  NOTE: this identifier originally included MP3 and NCP, but those issues are already covered by CVE-2007-6111. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6438)
[18:30] <emgent> ok
[18:30] <\sh> emgent: correspondent wireshark advisory: http://www.wireshark.org/security/wnpa-sec-2008-01.html
[18:31] <\sh> oh sorry that's the new one ;)
[18:31] <emgent> uhm
[18:31] <emgent> wnpa-sec-2007-03
[18:31] <\sh> right
[18:31] <\sh> most of the stuff is already fixed
[18:32] <\sh> and invalid (regarding CVE)
[18:32] <emgent> now we working to gutsy?
[18:32] <\sh> emgent: yes
[18:33] <emgent> ok just a moment, i should download :)
[18:33] <\sh> for hardy I'll push 0.99.8 :)
[18:33] <emgent> heheh cool :)
[18:34] <\sh> emgent: ok 2007-6438 is mentioned in the 2007-03 advisory as line "The SMB dissector could crash.  (Bug 2019) Versions affected: 0.99.6 "
[18:34] <ubotu> Launchpad bug 2019 in mrtg "Mrtg's html documentation lacks two images" [Low,Confirmed] https://launchpad.net/bugs/2019
[18:34] <\sh> lol...forget ubotu :)
[18:34]  * emgent downloading wireshark_0.99.6rel.orig.tar.gz
[18:34] <emgent> hahha
[18:35] <emgent> ok i'm ready
[18:35] <\sh> ok..patch system is dpatch
[18:36] <emgent> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2019
[18:36] <\sh> emgent: so for the 2007er CVEs we are going with patches named: "13_*" and for the 2008 we will go with "20_*"
[18:37] <emgent> ok  it's true
[18:37] <\sh> emgent: ok...so far...you see at the end of the bug report the svn revision number...copy it, and go to the SVN browser..
[18:38] <\sh> emgent: developers infos and then somewhere around "browse svn tree"
[18:38] <\sh> emgent: so it means here:  http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/
[18:39] <\sh> emgent: enter the revision number in the upper part and wait
[18:39] <emgent> yes i'm in :)
[18:40] <\sh> mostly the dissectors are broken
[18:40] <\sh> and those you find in epan/dissectors/
[18:41] <emgent>  Removed some unnamed unions, reported by Andrew Hood.
[18:41] <\sh> yepp..that's it
[18:42] <emgent> wireshark anonsvn it's very slow
[18:42] <emgent> s/it\'s/is/
[18:42] <\sh> yepp
[18:42] <emgent> ok i'm in
[18:42] <\sh> fun part is to find the revision to diff against
[18:43] <emgent> uhm, true
[18:44]  * sebner hugs \sh! nexuiz 2.4 is great :)
[18:44] <\sh> you'll find it in the source files of the version of wireshark you working on
[18:44] <\sh> emgent: in the $Id header
[18:45] <emgent> yes, i was understand, just a moment :)
[18:46] <emgent> ok
[18:47] <emgent> you like control all in espan/dissector ?
[18:47] <\sh> emgent: good...for this you can just diff against the rev before the needed commit
[18:47] <\sh> emgent: hmm?
[18:49] <\sh> emgent: there is one flaw you have to address, don't introduce new stuff which the wireshark people added already from the rev of your sourcecode and the security fix commit
[18:49] <emgent> oh ok
[18:50] <\sh> emgent: so only fix the stuff mentioned in the CVE or actually try to backport those fixes to your current wireshark version...you'll see this won't be easy sometimes
[18:50] <emgent> yes no problem \sh
[18:50] <\sh> emgent: for 2007-4638 we check this out: http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/epan/dissectors/packet-smb.c?r1=23412&r2=23593&pathrev=23593
[18:50] <emgent> yes i'm in
[18:50] <\sh> that's the diff view we are interested in
[18:51] <\sh> so now dpatch-edit-patch 13_CVE-2007-6438 13_CVE-2007-6111
[18:51] <ubotu> Unspecified vulnerability in the SMB dissector in Wireshark (formerly Ethereal) 0.99.6 allows remote attackers to cause a denial of service via unknown vectors.  NOTE: this identifier originally included MP3 and NCP, but those issues are already covered by CVE-2007-6111. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6438)
[18:51] <ubotu> Multiple unspecified vulnerabilities in Wireshark (formerly Ethereal) allow remote attackers to cause a denial of service (crash) via (1) a crafted MP3 file or (2) unspecified vectors to the NCP dissector. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6111)
[18:51] <\sh> the last CVE file is the last in 00list ;)
[18:52] <emgent> ok, np i will do and saw also other CVE
[18:53] <\sh> now patch epan/dissectors/packet-smb.c according to the diff view you see on the svn browser..don't use the patch view, it's broken
[18:54] <emgent> about 2007 i will use 13_* and for 2008 CVEs 20_*
[18:54] <emgent> ok cool
[18:56] <\sh> when you are finished you leave the dpatch-edit-patch environment and add the patch file to the 00list and add a new changelog entry for version 0.99.6rel-3ubuntu0.2
[18:57] <\sh> you'll see examples of the layout in 0.99.6rel-3ubuntu0.1 :)
[18:57] <\sh> just stick to it
[18:59] <emgent> yes i know, but i prefer quilt
[18:59] <emgent> :)
[18:59] <\sh> you don't have quilt...you'll stick with dpatch
[19:00] <emgent> yes i saw patchsystem
[19:00] <emgent> :)
[19:01] <\sh> ok..you do the other patches...now
[19:02] <\sh> there are some dups of already fixed CVEs...you'll find them here http://paste.ubuntu.com/6024/
[19:02] <emgent> sure, i will ping you when work is complete, thanks :)
[19:02] <\sh> emgent: 2007-6439 is also an dupe
[19:03] <\sh> emgent: be carefull...you'll come along CVE-2008-1071
[19:03] <ubotu> The SNMP dissector in Wireshark (formerly Ethereal) 0.99.6 through 0.99.7 allows remote attackers to cause a denial of service (crash) via a malformed packet. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1071)
[19:03] <\sh> emgent: and that's where it starts to getting tricky
[19:03] <nixternal> ScottK2: all testing done with smb4k...it seems it only killed 3 Windows boxes, but that is good right? :p
[19:04] <\sh> emgent: they rewrote the whole snmp dissector source
[19:04] <\sh> emgent: and now it's your turn to check gutsy version if it's vulnerable at all...because there is one version of 0.99.6 which isn't
[19:05] <\sh> emgent: bug http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2144
[19:05] <\sh> emgent: attached to this bug there is a snmp paket which you can inject into wireshark of gutsy and check if it's vulnerable
[19:05] <\sh> if not...mark it in the changelog
[19:05] <emgent> ok
[19:06] <\sh> if yes, you have to decide if you replace the snmp stuff completly
[19:07] <\sh> I discussed this with kees already...and normally we should backport...but the rewrite of the snmp stuff was done in 0.99.7 and the bugfix is for this very special version so there is sometimes no way to backport
[19:07] <\sh> so..now for some more advise regarding fixing "dapper" version of wireshark
[19:08] <\sh> the dapper release was the first release of wireshark under this name...formerly known as ethereal
[19:09] <emgent> yes
[19:09] <\sh> so you'll find some function names and structs named "ethereal_*" and "wireshark_*" they tried to get rid of the ethereal namespace totally...but for this version they didn't succeed in time...
[19:10] <\sh> emgent: when you find functionnames or struct names (which is more likely) which starts with wireshark in the fix, and you don't find those in the dapper version, try to replace wireshark_ with ethereal_ and check again
[19:12] <emgent> uhm dapper became short-supported, is good work in it too ?
[19:13] <emgent> anyway no problem, i go out for 10 mins, than i complete wiresark work
[19:13] <emgent> thanks \sh
[19:13] <\sh> emgent: well, TBH I don't care about the dapper version anymore...because it's a mess...
[19:13] <\sh> emgent: I would go with backports for wireshark in dapper
[19:13] <slangasek> Hobbsee: I'm not sure where the NBS button is
[19:14] <\sh> emgent: just add your stuff to the bugreport..I'll happy to review it
[19:14] <\sh> put a "be" between 'll and happy
[19:17] <ScottK2> nixternal: ;-)
[19:19] <nixternal> hehe
[19:20] <ScottK2> nixternal: Say something along the lines of "I'm subscribed as a bug contact for the package and will track it and deal with any regressions." in the bug and I'll ack it.  Bonus points if that's actually true.
[19:21] <nixternal> oh, I am the contact for smb4k...I have been working with upstream on it for 2 years now :)
[19:21] <nixternal> ie. look at the doco :p
[19:23] <ScottK2> nixternal: Just say that in the bug.
[19:23] <nixternal> done
[19:23] <ScottK2> K
[19:23] <nixternal> For Source Package "smb4k" in Ubuntu:
[19:23] <nixternal> Richard Johnson
[19:24] <nixternal> that's how I knew of the most recent /etc/sudoers corruption bug
[19:24] <nixternal> all of my subscripts gets flagged as important and automatically get created as a task in Kontact
[19:31] <ScottK2> nixternal: Ack'ed.  Go harass sistpoty now.
[19:31] <sistpoty> ScottK2, nixternal: heh, I already gave my ack ;)
[19:32] <nixternal> hehe
[19:35] <ScottK2> nixternal: Go for it then.
[19:39] <nixternal> already done..no messing around here :)
[19:39] <protonchris> sistpoty: Are you up for looking at a sync request and protentially sponsoring an upload?  (Bug 190744)  I ask because you have commented on that bug before.
[19:39] <ubotu> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [High,Confirmed] https://launchpad.net/bugs/190744
[19:39]  * emgent back
[19:40] <sistpoty> protonchris: sure
[19:40] <protonchris> sistpoty: thanks.  Let me know if I need to add any info to the bug.
[19:40] <sistpoty> protonchris: sure, will do
[19:41] <emgent> \sh: ok very good :)
[19:42]  * \sh goes to hunt for dinner...bbl
[19:43] <emgent> lol :)
[20:30] <sistpoty> protonchris: sorry, was busy... you should explain the ubuntu delta and why it can be dropped for the sync request
[20:30] <sistpoty> protonchris: which is already answered in the bug report, but would be good to get the detail in short right next to the actual entry requesting the sync again
[20:34] <sistpoty> protonchris: oh, and please change the bug title to s.th. like "please sync libgdamm3.0 (3.0.0-2) from unstable/main to universe"
[20:34] <sistpoty> protonchris: if you've done so, please subscribe ubuntu-archive, who will do the sync then
[20:39] <protonchris> sistpoty: thanks.  will do.
[20:40] <siretart>  
[20:40] <emgent> hi siretart :)
[20:46] <siretart> hey emgent
[22:01] <xtknight> what's that program that helps you determine the patch system being used?
[22:03] <RainCT> xtknight: what-patch
[22:03] <RainCT> xtknight: (it's in package ubuntu-dev-tools)
[22:03] <xtknight> ah thx
[22:06] <xtknight> if i were to fix a program's About Box freezing, and its Help->Manual menu not working, and if the program used a patch system, would these have to be two .patch files?
[22:08] <civija> xtknight: if they are small patches you can put them in single patch file
[22:08] <xtknight> ok.
[22:08] <civija> if they are bigger then it is better to split them
[22:13] <xtknight> why would there be a .patch file in the root of the package's source.
[22:13] <xtknight> not sure what patch system that indicates
[22:14] <xtknight> like gnome-schedule-1.0.0/gnome-schedule_1.0.0-1.2ubuntu1.patch   is this even valid?
[22:15] <RainCT> xtknight: that wouldn't be any Debian patch system at all
[22:16] <xtknight> RainCT, http://rafb.net/p/fHhazX38.html
[22:16] <RainCT> xtknight: afaik it would be either a patch which is included in the upstream source, or someone messed up the source package
[22:16] <xtknight> that's the top of my changelog
[22:16] <xtknight> there's already an ubuntu1 patch but the version is still 1.0.0-2
[22:16] <xtknight> when i did dch -i it made mine ubuntu1?
[22:17] <civija> xtknight: ignore that patch in root dir
[22:18] <RainCT> xtknight: Hardy has version 2.0.2-0ubuntu1. Are you sure that you have downloaded the right sources?
[22:18] <xtknight> RainCT, i am patching for Gutsy
[22:19] <RainCT> xtknight: Ah. You can try but I don't think that this will be accepted then
[22:19] <xtknight> RainCT, oh, no?
[22:19] <xtknight> that's how ive always done it..hmm
[22:19] <xtknight> well it's fixing a bug not introducing a new feature
[22:19] <xtknight> it's universe
[22:20] <xtknight> or do we only bother patching LTS releases that are old, and not other old releaes?
[22:20] <RainCT> xtknight: only security fixes and fixex avoiding data lose are allowed as far as I know, but I haven't much experience with SRUs so I might be wrong
[22:21] <xtknight> Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
[22:21] <xtknight> i think mine fits under this
[22:22] <RainCT> oh, is that new?
[22:22] <xtknight> https://wiki.ubuntu.com/StableReleaseUpdates
[22:22] <xtknight> i've never really heard the word SRU much though
[22:22] <xtknight> i've always just  posted patches and subcribing motu, never had a problem with that
[22:22] <xtknight> i dont know if the policy has since changed
[22:23] <civija> xtknight: did you check is the bug fixed in newer (hardy) version of package?
[22:23] <xtknight> civija, would we backport the newer hardy package to gutsy if it was fixed there?
[22:24] <\sh> ScottK: pyopengl doesn't give me any FTBFS stuff..builds fine
[22:24] <xtknight> or would we make another patch for hardy
[22:24] <xtknight> if it wasn't fixed
[22:24] <StevenHarperUk> hi guys I have raised a Feature Freeze Exception #205728 - its for a bad bug - can anyone take a look
[22:24] <ScottK2> \sh: Did the build log show anything useful?
[22:25] <xtknight> err.... what i mean is, should i post the small gutsy patch to 1.0.0, or backport hardy 2.0.0 to gutsy if that version is fixed?
[22:25] <RainCT> xtknight: seems like it has changed since the last time I looked at it, great :)
[22:25] <ScottK2> xtknight: SRU policy is not new.
[22:25] <ScottK2> xtknight: Patch 1.0.0
[22:26] <\sh> ScottK2: depends on what do you mean with useful?
[22:26] <xtknight> civija, when you say ignore the patch in the root dir, should my new revision still be ubuntu1?
[22:26] <\sh> ScottK2: if you mean: all files are installed in the correct position, looks like :)
[22:26] <ScottK2> \sh: As in can you tell why if FTBFS in the test and see if it's still relvant
[22:26] <civija> xtknight: yes
[22:26] <xtknight> k thx
[22:27] <civija> xtknight: dch -i does exactly that
[22:27] <StevenHarperUk> \sh: could you look at my feature freeze bug exception #205728
[22:27] <\sh> ScottK2: Can't find source for pyopengl_3.0.0~b1-0ubuntu2
[22:27] <\sh> ScottK2: that was the bug on builder
[22:27] <\sh> bug #205728
[22:27] <ubotu> Launchpad bug 205728 in easycrypt "FeatureFreeze Exceptions for easycrypt-0.2.2.9" [Undecided,New] https://launchpad.net/bugs/205728
[22:28] <ScottK2> \sh: Lovely.  Thanks for looking into it.  It's invalid then.
[22:28] <\sh> ScottK2: already set it
[22:29] <ScottK2> Great.
[22:29] <\sh> StevenHarperUk: we uploaded 0.2.2.8 only 2 days ago
[22:29] <StevenHarperUk> \sh: yeh I know its a bad bug just discovered
[22:29] <\sh> StevenHarperUk: I think it's more a bugfix release, right?
[22:29] <ScottK2> StevenHarperUk: If the new version is only bugfix, no FFe needed.  Just use than standard sponsoring process.
[22:29] <StevenHarperUk> \sh: I'd rather it didnt exist, but it does so im trying to fix it
[22:30] <\sh> StevenHarperUk: so I would subscribe just u-u-s to it
[22:30] <StevenHarperUk> I have doe that, but its now linked to the freeze exception
[22:30] <StevenHarperUk> Is that reverable
[22:30] <StevenHarperUk> *reversable
[22:31] <RainCT> StevenHarperUk: just add a comment explaining that it's bugfix only
[22:31] <\sh> StevenHarperUk: where do I find the source etc?
[22:31] <StevenHarperUk> what do I do with the feature freeze exception : mark it invalid?
[22:31] <StevenHarperUk> Its all in the comments
[22:32] <StevenHarperUk> https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/205722
[22:32] <ubotu> Launchpad bug 205722 in easycrypt "Candidate revision easycrypt_0.2.2.9-0ubuntu1" [Undecided,Confirmed]
[22:32] <StevenHarperUk> Source available at
[22:32] <StevenHarperUk> http://www.squeezedonkey.com/svn/linux/trunk/releases/easycrypt/src
[22:32] <\sh> StevenHarperUk: sponsoring it...
[22:33] <StevenHarperUk> \sh: thanks
[22:33] <RainCT> StevenHarperUk: ah, just mark the FFe bug as invalid
[22:33] <StevenHarperUk> RainCT: I have ta
[22:34] <StevenHarperUk> Thanks everyone :P for you help and advice
[22:34] <sebner> Fujitsu: You can stop working on turba2!!! I completed the sync request made by someone back in feb. This sync should fix the permission issues! I saw to late that you are working on it. Sry! :)
[22:35] <StevenHarperUk> Ta everyone : and BYE
[22:35] <sebner> StevenHarperUk: bye
[22:36] <xtknight> when one subscribes ubuntu-universe-sponsors does anybody actually see it or do you need to lobby for a sponsor?
[22:37] <civija> they see it
[22:37] <RainCT> xtknight: sponsors check the list of bugs u-u-s is subscribed to when they get bored ;)
[22:37] <xtknight> ahh
[22:38] <ScottK2> xtknight: Some lobbying is OK, but excessive lobbying tends to get you ignored.
[22:38] <xtknight> yea i wouldn't resort to that until a few months or so
[22:39] <xtknight> just wondered
[22:42] <ScottK2> For new package reviews it's useful to let people know you're around as those often need discussion.   For upgrades and new revisions it's less helpful.
[22:42] <\sh> ScottK2: if you have time, please ack bug #205737
[22:42] <ubotu> Launchpad bug 205737 in wireshark "[FFe] wireshark 0.99.8" [Undecided,New] https://launchpad.net/bugs/205737
[22:44] <\sh> ok...time to hit the bed
[22:44] <\sh> cu tomorrow
[22:44] <ScottK2> \sh_away: Acked
[22:45] <ScottK2> sistpoty: You might want to look at ^^^ wireshark FFe too.
[22:48] <Fujitsu> ScottK2: That's a bug in the package.
[22:49] <sebner> Fujitsu: ah, got my message?
[22:49] <Fujitsu> sebner: I did. What gives you the idea that that fixed the issue?
[22:49] <Fujitsu> The CVE was fixed in 2.1.7-1.
[22:50] <Fujitsu> Not 2.1.4-1.
[22:50] <Fujitsu> Although I see emgent is working on it, hmm.
[22:50] <sebner> Fujitsu: bug #194653
[22:50] <ubotu> Launchpad bug 194653 in turba2 "[FFe] Please sync turba2 2.1.7-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/194653
[22:50] <sebner> Fujitsu: I'm working on it ;)
[22:50] <Fujitsu> Ah, I see.
[22:50] <Fujitsu> OK, I see now. THanks.
[22:51] <sebner> Fujitsu: np. :)
[22:52] <Fujitsu> Right, now to convince mplayer to build.
[22:52] <Fujitsu> ScottK2: Thanks for the wireshark ack, that'll close off a few CVEs that I was looking at.
[22:56] <sebner> ScottK: ah DAMN. SRY. again and again. always the same mistakes .... :(
[22:57] <ScottK2> Fujitsu: Great.  Now lean on sistpoty.
[22:57] <ScottK2> sebner: It's OK.
[22:58]  * sistpoty looks
[22:58] <sebner> ScottK: I'm on the way
[22:58] <Fujitsu> ScottK2: You said about that bugfix-only releases still didn't need an FFe. I believe FreezeExceptionProcess says that can only happen until Alpha 6.
[22:58] <Fujitsu> s/about/above/
[22:59] <ScottK2> Fujitsu: IIRC that got changed when it was discussed at the MOTU meeting and changed, but I don't recall for sure.  Don't break stuff and I won't complain.
[23:00] <Fujitsu> ScottK2: OK, thanks.
[23:00] <Fujitsu> That makes things easier.
[23:04] <sistpoty> \sh_away: wireshark ack'd, please go ahead
[23:04] <sebner> ScottK: updated
[23:04] <sebner> good night folks
[23:05] <Fujitsu> Night sebner.
[23:05] <sistpoty> gn8 sebner
[23:06] <RainCT> good night
[23:09] <sistpoty> good night RainCT
[23:12] <LaserJock> ScottK: ping
[23:13] <Fujitsu> LaserJock: He's ScottK2 today.
[23:13] <ScottK2> Only until I go downstairs.
[23:15] <ScottK2> LaserJock: What's up?
[23:15] <LaserJock> ScottK2: regarding schooltool, I'm not sure that closing all the bugs is the way to go. Not a big deal, but it seems that when schooltool comes back that those bugs should be still living, no?
[23:15] <ScottK2> Is it coming back?
[23:15] <Fujitsu> LaserJock: I'm not sure about that.
[23:16] <Fujitsu> schooltool is coming back, but it's very, very different.
[23:16] <ScottK2> I didn't invalid them, but marked won'tfix.  That seems pretty accurate as we won't fix them.
[23:17] <LaserJock> ScottK2: ah, I thought you invalidated them
[23:17] <LaserJock> Fujitsu: true, but we want to make sure that those bugs are addressed