[12:15] <Ubugtu> New bug: #71609 in util-linux (main) "Can't unmount UUID= volume as a user" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71609
[12:16] <Ubugtu> New bug: #73399 in Ubuntu "The audio is cut when the HD "itches"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73399
[12:16] <Ubugtu> New bug: #73400 in Ubuntu "kubuntu show all directorires of "/"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73400
[12:21] <Ubugtu> New bug: #73401 in sun-java5 (multiverse) "current working directory not set correctly when launching JAR file" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73401
[12:45] <Ubugtu> New bug: #73403 in firefox (main) "Firefox shutdown while trying to save an .gif image" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73403
[02:32] <andresmujica> i cannot access the bug reports... i want to mark #73402, #73404 and #73405 asduplicates, but couldn't access there... pls someone mark those as dups.
[02:33] <andresmujica> thanks
[02:33] <andresmujica> #74302
[02:33] <crimsun> LP is experiencing technical difficulties atm.
[02:34] <andresmujica> hmm , i supposed that..
[02:34] <andresmujica> ok i'll wait for a bit.
[04:03] <sfllaw> Hobbsee: Did you complain to #launchpad about d_jedi?
[04:03] <sfllaw> By the time I saw your ping, you were gone.
[04:04] <Hobbsee> sfllaw: yep
[04:04] <Hobbsee> sfllaw: yes.  i do sleep occasionally, sorry :(
[04:04] <sfllaw> Same here.
[04:04] <sfllaw> :)
[04:04] <sfllaw> Thanks!
[04:04] <sfllaw> You rock.
[04:05] <Hobbsee> :)
[04:50] <TheMuso> c
[04:50] <Hobbsee> d
[04:54] <Admiral_Chicago> hmm channel is all quite
[04:54] <Admiral_Chicago> is LP still down?
[04:56] <somerville32> LP isn't down forme
[04:58] <Admiral_Chicago> somerville32: someone said it was "LP is experiencing technical difficulties atm."
[04:59] <Admiral_Chicago> so maybe the bot isn't updating the bugs or something
[04:59] <somerville32> Hmm...
[06:45] <dholbach> good morning
[06:51] <towsonu2003> I've got a question, I applied to ubuntu-qa a few weeks ago -how long does it get to get approval or denial?
[06:52] <dholbach> towsonu2003: did you ask simon about it? he does the approval normally
[06:52] <dholbach> (sfllaw that is)
[06:52] <dholbach> towsonu2003: but I saw you worked on a huge load of bugs already, I'm going to approve you now
[06:53] <towsonu2003> dholbach, oh okay thanks :)
[06:57] <towsonu2003> dholbach, is there a documentation page specific to ubuntu-qa I should read? (sorry to bother you again)
[07:04] <dholbach> towsonu2003: we should have one
[07:06] <towsonu2003> dholbach, I couldn't find one. I'll google a bit more then ,thanks :)
[07:08] <Admiral_Chicago> when is Ubugtu going to start udating from LP
[07:08] <dholbach> towsonu2003: ok, I didn't find anything
[07:09] <dholbach> towsonu2003: I'm going to add a blurb on the BugSquad page and one describing the bug statuses
[07:09] <towsonu2003> dholbach, thanks a lot :)
[07:10] <towsonu2003> dholbach, oh almost forgot, could you add a couple of notes on bug importance and when to change it? thanks again
[07:11] <dholbach> towsonu2003: your wish is my command
[07:12] <towsonu2003> dholbach, lol
[07:16] <dholbach> https://wiki.ubuntu.com/Bugs/Importance
[07:19] <dholbach> added it to https://wiki.ubuntu.com/Bugs/HowToTriage
[07:23] <towsonu2003> thanks a lot, I really appreciate it :)
[07:23] <dholbach> thanks for notifying me
[07:24] <dholbach> added the blurbs about ubuntu-qa too
[07:24] <dholbach> https://wiki.ubuntu.com/BugSquad and https://wiki.ubuntu.com/Bugs/Importance
[07:24] <towsonu2003> great
[07:24] <dholbach> super
[07:24] <towsonu2003> I'll start reading once I'm done watching Star Trek
[07:24] <dholbach> hehe
[07:24] <dholbach> enjoy it
[07:24] <towsonu2003> :p
[09:41] <palski> Shouldn't this be "fix committed"?  Bug #68074
[09:41] <Ubugtu> Malone bug 68074 in curl "Seg fault when connecting" [Undecided,Confirmed]  http://launchpad.net/bugs/68074
[09:43] <palski> the fix is already in CVS
[09:45] <somerville32> Depends if the package is upstream or not
[09:46] <palski> bug was in upstream and fix has committed to upstream cvs
[09:48] <somerville32> Hmm
[09:50] <palski> "Fix Committed: A fix has been included in the code, but this code is not necessarily available in a released version"
[09:51] <somerville32> One second
[10:15] <crimsun> palski: it can be, yes
[10:16] <somerville32> I affected it upstream
[10:17] <somerville32> crimsun: The local source package can stay at confirmed until we do an sru?
[10:17] <crimsun> that'll be fine
[10:17] <palski> if it is fixed in feisty, wouldn't that be "fix released"?
[10:18] <palski> and a new bug report should be done for sru request?
[10:19] <somerville32> Yeah, thats probably right.
[10:21] <crimsun> yes, and yes
[10:24] <somerville32> Crimsun: Will you do the sru?
[10:24] <crimsun> somerville32: I don't have time atm.
[10:24] <somerville32> k
[10:25] <crimsun> are you familiar w/ the process? I don't mind walking you through it.
[10:25] <crimsun> more people should become familiar w/ it, really.
[10:27] <somerville32> Well, I'm in Windows right now (simply because I was too lazy to reboot after the last person who was on)
[10:28] <somerville32> And I doubt it would go well using the live cd
[10:28] <somerville32> I suppose I could move downstairs to my lab
[10:29] <crimsun> you need access to a Terminal [of choice]  and some standard packaging tools (devscripts, etc.)
[10:29] <crimsun> it doesn't require much more
[10:30] <somerville32> Alrighty
[10:30] <somerville32> I'll be right back
[10:30] <palski> you really need devscripts for filling up sru?
[10:31] <crimsun> no, but it's quite convenient
[10:31] <crimsun> e.g., devscripts: /usr/bin/debdiff
[10:31] <somerville32> :] 
[10:32] <somerville32> Alrighty, brb
[10:39] <somerville32> Crimsun: Alrighty.
[10:40] <crimsun> somerville32: ok, got a terminal or two open?
[10:40] <somerville32> Yup :)
[10:41] <crimsun> ok, first thing is to grab the edgy source package [wget http://archive.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.15.4-1ubuntu2.dsc http://archive.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.15.4.orig.tar.gz http://archive.ubuntu.com/ubuntu/pool/main/c/curl/curl_7.15.4-1ubuntu2.diff.gz ] 
[10:42] <somerville32> Alrighty. :)
[10:42] <crimsun> next thing is to isolate the patch from upstream cvs that fixes the issue and to download it
[10:44] <somerville32> Got it
[10:44] <crimsun> [I presume it's http://librarian.launchpad.net/5179200/multi_expire.diff ?] 
[10:45] <crimsun> ok, next thing is to extract the source package [dpkg-source -x curl_7.15.4-1ubuntu2.dsc ] 
[10:45] <crimsun> then, cwd into the root of the extracted source
[10:46] <somerville32> k
[10:46] <crimsun> at this point, it's a good idea to check if the Debianised source package uses a patch management system
[10:47] <crimsun> e.g., inspect debian/{control,rules} and look for the existence of debian/patches/
[10:47] <crimsun> specifically:
[10:47] <crimsun> in debian/control, look at the Build-Depends line, and see if it uses cdbs, quilt, dpatch, etc.
[10:48] <crimsun> in debian/rules, look for *patch* target(s)
[10:48] <crimsun> and finally, if debian/patches/ exists, it's nearly always a dead giveaway that some sort of patch management system is used
[10:49] <crimsun> [in this case of curl, there's none used, so you'll patch the Debianised source directly. Normally if a patch management system is used, you'll generate the patch targeted for the specific system ] 
[10:51] <crimsun> now you need to patch the Debianised source, but you'll find there's one reject
[10:51] <crimsun> [patch -p1 --dry-run <../multi_expire.diff ] 
[10:51] <crimsun> [it's always sane to test using --dry-run ] 
[10:53] <crimsun> at this point, you'll manually inspect the reject and hand-apply the necessary fix
[10:54] <somerville32> Is it possible to see where the rejection is occurring?
[10:55] <crimsun> yep, look at lib/multi.c.rej
[10:55] <crimsun> in another window, it helps to open lib/multi.c
[10:55] <somerville32> It didn't actually write it
[10:55] <crimsun> oh, right. apply it (no --dry-run)
[10:56] <somerville32> k
[10:57] <crimsun> once you inspect the lib/multi.c alongside lib/multi.c.rej , you'll see that the actual one-liner (the comments notwithstanding) needs to be applied 12 lines above
[10:58] <crimsun> then you'll hand-insert that line into lib/multi.c
[11:01] <crimsun> [clear so far? ] 
[11:01] <somerville32> Hmm...
[11:01] <somerville32> Yeah but I'm having a hard time matching up the reject to the new code
[11:02] <crimsun> right, you have to scroll up 12 lines from the original target
[11:02] <somerville32> I did
[11:02] <crimsun> ok, do you see the if(easy) {
[11:02] <crimsun>  /* If the 'state' ...
[11:03] <somerville32> Yup
[11:03] <somerville32> Oh!
[11:03] <crimsun> yeah, fortunately this one was straightforward
[11:03] <crimsun> it can be a real PitA
[11:04] <somerville32> Do you see line 19 in the rej file?
[11:04] <somerville32> Like, 18-21
[11:04] <somerville32> Where is that stuff?
[11:04] <crimsun> yep. Those aren't in lib/multi.c , because that was added in .5
[11:05] <crimsun> (welcome to the joy of backporting fixes)
[11:05] <crimsun> note, however, that semantically the context is nearly identical in the old one [to which you're applying the fix ] 
[11:06] <crimsun> the difference is an additional if(easy->easy_handle == ... )
[11:06] <somerville32> Maybe I'm still confused
[11:07] <somerville32> I thought I had to add the parts with the the plus signs in front
[11:07] <somerville32> haha
[11:07] <crimsun> yes, you do
[11:07] <crimsun> that's the portion that failed to apply
[11:08] <crimsun> the significant portion that failed to apply is just one line:  Curl_expire(easy->easy_handle, 0);
[11:08] <somerville32> Ok, thats what I thought
[11:08] <crimsun> so, noting the context prior and following that failed portion, you can see where to apply it
[11:08] <somerville32> But I don't see the other parts in that new file
[11:08] <crimsun> which other parts?
[11:08] <crimsun> (I only have one reject)
[11:09] <somerville32> Ok, in the rej file
[11:09] <somerville32> Line 6
[11:09] <crimsun> right, it's not in edgy's curl source because that was added for feisty's
[11:10] <somerville32> So...
[11:10] <crimsun> (that's why it failed to apply)
[11:10] <somerville32> I only have to add  Curl_expire(easy->easy_handle, 0); under nice to put the easy_handle in a good known state when this returns. */
[11:10] <crimsun> right
[11:10] <somerville32> haha
[11:10] <somerville32> Ok
[11:10] <somerville32> I understand now
[11:11] <somerville32> You should have told me why it failed and I would have gotten it, haha
[11:11] <somerville32> <g
[11:11] <crimsun> I did 7 minutes ago ;)
[11:11] <somerville32> You'll have to forgive me
[11:11] <crimsun> no prob
[11:11] <somerville32> It is 6:13am here
[11:12] <crimsun> 5:12a here
[11:12] <somerville32> Alrighty. manually patched
[11:12] <crimsun> ok, next, clean up the source tree by removing *.orig and *.rej
[11:13] <crimsun> [find -name '*.orig' |xargs rm && find -name '*.rej' |xargs rm ] 
[11:13] <somerville32> k
[11:14] <crimsun> now you're ready to generate a changelog entry
[11:14] <somerville32> :] 
[11:15] <crimsun> [dch -v7.15.4-1ubuntu2.1 -Dedgy-proposed ] 
[11:16] <crimsun> (fill in the appropriate info)
[11:16] <somerville32> dch isn't installed
[11:16] <somerville32> What package do I need?
[11:16] <crimsun> devscripts :)
[11:16] <somerville32> :] 
[11:18] <crimsun> [oh, emacs has tools for this, but I'm not familiar with that mode. If you're an emacs fan, you'll want to ask someone who uses emacs. ] 
[11:19] <somerville32> What should I say in the changelog?
[11:20] <crimsun> the format for a -proposed entry generally references files that were changed and why
[11:20] <somerville32> Example?
[11:22] <somerville32>   * curl/lib/multi.c patched to fix bug #68074 ?
[11:22] <Ubugtu> Malone bug 68074 in curl "Seg fault when connecting" [Unknown,Unknown]  http://launchpad.net/bugs/68074
[11:23] <crimsun> e.g., http://pastebin.ca/259304
[11:24] <somerville32> Do I need a @ubuntu.com e-mail address? I read somewhere that I did.
[11:24] <crimsun> it's not strictly necessary
[11:25] <crimsun> since you aren't a dev yet, you should get a core-dev to ACK the debdiff
[11:26] <crimsun> (you'll generate the debdiff next)
[11:26] <somerville32> parsechangelog/debian: error: unrecognised line, at changelog line 4
[11:26] <somerville32> dch: fatal error at line 983:
[11:26] <somerville32> Problem executing dpkg-parsechangelog:
[11:26] <crimsun> make sure your syntax is correct
[11:26] <crimsun> note that in the pastebin, lines 5-6 are actually one line
[11:27] <somerville32> Ok, I fixed it
[11:27] <somerville32> Should I run the script again or something?
[11:27] <crimsun> which script are you referring to?
[11:27] <crimsun> (you need the changelog entry)
[11:27] <somerville32> dch
[11:27] <crimsun> you only need to run it to add the entry
[11:28] <somerville32> Alrighty.
[11:28] <somerville32> Whats next?
[11:28] <crimsun> since it failed, yes, you'll need to make sure the entry is there
[11:28] <somerville32> in debian/changelog
[11:28] <somerville32> ?
[11:28] <crimsun> yes, at the top
[11:28] <somerville32> It is there
[11:28] <somerville32> I manually edited it to fix the line break on line 4
[11:29] <crimsun> excellent. Now you have to make sure you file a bug report that will be referenced, as the SRU, in the changelog
[11:29] <crimsun> if you wish, you can use 68074 for that
[11:29] <somerville32> So I don't need to file a second bug?
[11:30] <crimsun> not necessarily, though it helps for clarity
[11:30] <crimsun> SRU policy is outlined at [https://wiki.ubuntu.com/StableReleaseUpdates ] 
[11:32] <crimsun> ok, now that you have the appropriate fix applied and the changelog entry, you need to generate a debdiff to attach to #68074 (or whichever new bug report you open, if you choose)
[11:32] <somerville32> Well, I'll open a new bug report since I said I said Daniel wouldn't get anymore e-mails, haha
[11:33] <crimsun> ok, just make sure you edit debian/changelog before you generate the debdiff
[11:34] <somerville32> Can I put the SRU bug number on it's own "asterisk"?
[11:34] <crimsun> if you wish to, yes. I normally reference all the Ubuntu bug #s together by topic
[11:35] <crimsun> (so I'd place them together)
[11:35] <crimsun> fault (Closes Ubuntu: #68074, _and whatever SRU bug #_).
[11:39] <crimsun> (note that you'd attach the debdiff to this new bug that you're filing)
[11:39] <crimsun> ok, since I have to scoot in a bit, I'm going to outline what else you need to do
[11:39] <crimsun> 1) adjust debian/changelog
[11:40] <crimsun> 2) generate a debdiff
[11:40] <somerville32> How else do I have to modify debian/changelog?
[11:40] <crimsun> 3) add the relevant info, including the debdiff and diffstat info, to the new bug
[11:40] <crimsun> debian/changelog needs to reference the SRU bug #
[11:40] <crimsun> (you'll see that when you reread https://wiki.ubuntu.com/StableReleaseUpdates )
[11:42] <crimsun> now, generating a debdiff is quite straightforward. While in the root of the extracted source, you issue a ``debuild -S''
[11:43] <crimsun> that command generates several files in the parent directory, curl_7.15.4-1ubuntu2.1.diff.gz , curl_7.15.4-1ubuntu2.1.dsc , curl_7.15.4-1ubuntu2.1_source.build , curl_7.15.4-1ubuntu2.1_source.changes
[11:44] <crimsun> you should cwd to that parent directory to generate a debdiff (the previous step just generated a Debianised source package)
[11:44] <crimsun> debdiff accepts several different files; I use the dscs
[11:44] <crimsun> ``debdiff curl_7.15.4-1ubuntu2.dsc curl_7.15.4-1ubuntu2.1.dsc >curl_7.15.4-1ubuntu2.1.debdiff''
[11:45] <crimsun> and that's the debdiff that is applicable to the original edgy source package
[11:46] <crimsun> you'd attach that to the new bug report
[11:46] <crimsun> I also find it useful to include diffstat output, so whichever archive admin is reading the SRU can get a quick overview of the invasiveness of the patch
[11:47] <crimsun> (diffstat is in the diffstat package)
[11:47] <crimsun> diffstat curl_7.15.4-1ubuntu2.1.debdiff
[11:48] <crimsun> afterward, you'd attach all that info to the new bug report, following step #1 (Propose) of the SRU process
[11:49] <crimsun> always build and test your debdiff before subscribing the ubuntu-sru team
[11:50] <crimsun> (I need to return to work)
[12:05] <somerville32> Gah
[12:05] <somerville32> It isn't working
[12:13] <fernando> moin all
[12:15] <somerville32> Hi
[12:33] <fernando> seb128: hi, not is gnome-vfs2 2.16.1-0ubuntu2 the latest stable?
[12:33] <seb128> fernando: stable = upstream stable or Ubuntu stable?
[12:34] <fernando> seb128: ubuntu stable
[12:34] <fernando> apt-cache show libgnomevfs2-0 | grep -i version
[12:34] <fernando> Version: 2.16.1-0ubuntu2
[12:34] <seb128> there is a 2.16
[12:34] <fernando> seb128: you have pached the 2.16.1-0ubuntu3
[12:34] <seb128> .2.16.1-0ubuntu3 to edgy-proposed which fix the 100% CPU bug
[12:34] <fernando> s/pached/patched/
[12:34] <fernando> seb128: ah, ok
[12:34] <fernando> seb128: thanks
[12:36] <seb128> np
[12:36] <seb128> does that answer your question?
[12:36] <seb128> you are looking for that update?
[12:36] <seb128> it's to "edgy-proposed", which is not part of the default sources.list
[12:39] <fernando> seaLne: thanks
[12:39] <fernando> seb128: thanks
[12:39] <seb128> np
[12:47] <somerville32> Woot.
[12:47] <somerville32> Got it to work
[12:47] <somerville32> Alrightys, times for bed
[03:54] <bddebian> Boo
[04:09] <pirast> bddebian, boooooohooooooo!
[04:09] <bddebian> Hehe.  Hello pirast
[04:10] <pirast> hi ;-)
[04:11] <Hobbsee> hey pirast
[05:39] <dholbach> sfllaw: it'd be good to announce the next hug day in your open week session
[05:40] <sfllaw> Yes, I think so.
[05:40] <sfllaw> I should probably get fridge-devel to put it up.
[05:45] <jonh_wendell> seb128: where is this bug nowadays: https://bugzilla.ubuntu.com/2055 ??
[05:48] <joumetal> jonh_wendell Sebastian is busy now at #ubuntu-classroom. What was this bug about?
[05:48] <jonh_wendell> joumetal: it's a outdated bug... i'd want just a confirmation from sebastien
[05:49] <seb128> jonh_wendell: http://bugzilla.ubuntu.com/show_bug.cgi?id=NUMBER
[05:49] <seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=2055
[05:49] <seb128> for that one
[05:51] <jonh_wendell> seb128: thanks
[05:54] <seb128> jonh_wendell: np
[06:19] <seb128> jonh_wendell: closing old bugs like that on bugzilla is not the way to go
[06:19] <seb128> jonh_wendell: I don't really care about that vino bug, but it's likely some bugsquad guy will remove your rights if you keep doing that
[06:20] <seb128> jonh_wendell: you can't close a bug because it has been reported with an old version, but don't get automagically fixed with new versions
[06:20] <seb128> jonh_wendell: you usually ask the submitter if it still gets the issue before closing something
[06:21] <jonh_wendell> seb128: the submitter is you; i've looked the LP bug report and it was rejected in Ubuntu
[06:22] <seb128> jonh_wendell: don't use the stock reply but say that to the comment in such case then :)
[06:40] <jonh_wendell> seb128: should i reopen that vino bug?
[06:40] <seb128> jonh_wendell: no that's fine, nobody has got it for a long time apparently
[06:40] <seb128> jonh_wendell: I would just have closed it with a comment saying that the Ubuntu bug is closed and it seems to not happen with the new version
[06:41] <jonh_wendell> seb128: sure, thanks for the tip
[06:41] <seb128> saying "you used an old version, I'm closing your bug" just doesn't apply for people using GNOME 2.10
[06:41] <seb128> 80% of the GNOME 2.10 bugs are still valid on GNOME 2.16 probably
[06:41] <seb128> np!
[11:16] <Adri2000> Ubugtu dead?
[11:22] <Admiral_Chicago> Adri2000: i think so, Lp was having problems according to crimsun
[11:33] <Le-Chuck_IT1> hi all
[11:33] <Le-Chuck_IT1> I have a question about bug fixing in ubuntu in general
[11:33] <Burgwork> shoot
[11:34] <Le-Chuck_IT1> I see that edgy has been released quite in time
[11:34] <Le-Chuck_IT1> but with some bugs affecting various packages
[11:34] <Admiral_Chicago> yes
[11:34] <Le-Chuck_IT1> and I can show evidences that these bugs are really a showstopper for many people
[11:34] <Le-Chuck_IT1> and
[11:35] <Le-Chuck_IT1> can I expect that they'll ever be fixed in edgy, not in feisty
[11:35] <Le-Chuck_IT1> and if not
[11:35] <Le-Chuck_IT1> isn't this gonna repeat in feisty?
[11:35] <Admiral_Chicago> Le-Chuck_IT1: what kind of bugs
[11:35] <Admiral_Chicago> further, do you have bug reports that we can inspect
[11:35] <Le-Chuck_IT1> e.g. beagle (which is in universe) breaking yelp once installed
[11:35] <Le-Chuck_IT1> lyx
[11:35] <mc44> Le-Chuck_IT1: yes, there will always be bugs in released distros that will not be fixed as fixing them may break more things
[11:36] <Le-Chuck_IT1> which in edgy is completely broken
[11:36] <Le-Chuck_IT1> and the italian locales for synaptic
[11:36] <Le-Chuck_IT1> that have been breaking italian update-manager since a month ago
[11:37] <mc44> Le-Chuck_IT1: well they will likely be fixed if they prevent upgrading
[11:37] <Le-Chuck_IT1> well I am a bit worried by the last one
[11:37] <Le-Chuck_IT1> seems like the simple fix of removing a ' character
[11:38] <Le-Chuck_IT1> has been put apart in favour of most serious fixes
[11:38] <Le-Chuck_IT1> but
[11:38] <Le-Chuck_IT1> what does it take to change a string
[11:38] <Le-Chuck_IT1> and update the fix immediately
[11:38] <Le-Chuck_IT1> expecially because it's a "stable update" that is breaking things
[11:38] <mc44> Le-Chuck_IT1: is there a bug filed for this?
[11:39] <Le-Chuck_IT1> I can point out https://launchpad.net/distros/debian/+source/beagle/+bug/67778 for the first one I mentioned
[11:39] <Ubugtu> Malone bug 67778 in beagle "Search don't work with beagle" [Unknown,Fix released] 
[11:39] <Le-Chuck_IT1> now
[11:39] <mc44> Le-Chuck_IT1: I mean the locale problem
[11:39] <Le-Chuck_IT1> yes I know :)
[11:40] <Le-Chuck_IT1> just pasting the other one
[11:40] <mc44> :)
[11:40] <Le-Chuck_IT1> yes there is a well know open bug
[11:40] <Le-Chuck_IT1> even if perhaps I am not subscribed to that since I'm not finding it
[11:41] <Le-Chuck_IT1> I don't know
[11:41] <Le-Chuck_IT1> is asking a backport the right way to proceed?
[11:41] <Le-Chuck_IT1> instead of an SRU which is more complicated, I mean
[11:42] <mc44> its depends on the problem, if it is a language pack causing it, then it is adifferent matter
[11:43] <Le-Chuck_IT1> yes
[11:43] <mc44> Le-Chuck_IT1: https://bugs.launchpad.net/distros/ubuntu/+source/update-manager/+bug/70959 ?
[11:43] <Le-Chuck_IT1> but consider beagle
[11:43] <Ubugtu> Malone bug 70959 in update-manager "update-manager doesn't install updates when Italian locale is on" [Undecided,Unconfirmed] 
[11:43] <mc44> Le-Chuck_IT1: beagle is non critical and unlikely to be updated with an SRU
[11:45] <Le-Chuck_IT1> here it is! https://launchpad.net/products/update-manager/+bug/51419
[11:45] <Ubugtu> Malone bug 51419 in gksu ""Install updates"-button only refreshes update list in it_IT environement" [High,Confirmed] 
[11:45] <Le-Chuck_IT1> and of course 70959 is a duplicate of this one
[11:46] <Le-Chuck_IT1> I see beagle is non critical :) The point is
[11:46] <Le-Chuck_IT1> if software is non critical why not quick fix it expecially when it breaks more important programs?
[11:46] <Le-Chuck_IT1> not to be polemic
[11:47] <mc44> Le-Chuck_IT1: becasue it may well break many other things that are working fine
[11:47] <Le-Chuck_IT1> I am just trying to figure out best practices
[11:47] <Le-Chuck_IT1> yes but it's not the case for that bug: the bug is in a cron script, the cron script is wrong, it's breaking yelp
[11:47] <Le-Chuck_IT1> ok I surrender :)
[11:48] <Le-Chuck_IT1> I already went for a backport and it looks like it will be done
[11:48] <mc44> Le-Chuck_IT1: yay :)
[11:48] <Le-Chuck_IT1> ok but now: I should consider backports sort of "ubuntu quickfixed"
[11:49] <Le-Chuck_IT1> but it's not really so
[11:49] <Le-Chuck_IT1> because it's "ubuntu quickfixed with newer versions"
[11:50] <Le-Chuck_IT1> and I am still disappointed with the fact that broken workflow in the stable release will remain broken for months even when the fix is known
[11:50] <Le-Chuck_IT1> I mean
[11:50] <Le-Chuck_IT1> if I had a software company with many users
[11:50] <Le-Chuck_IT1> I would release some fix sometime
[11:50] <Le-Chuck_IT1> for bugs, crashes
[11:50] <Le-Chuck_IT1> not only for security
[11:50] <mc44> Le-Chuck_IT1: its a consequence of 6 month release cycle
[11:50] <Le-Chuck_IT1> I understand
[11:51] <Le-Chuck_IT1> it's not gentoo
[11:51] <mc44> and limited resources
[11:51] <Le-Chuck_IT1> but I see novell releases fixes and does not break things (except for their ugly package manager)
[11:51] <Le-Chuck_IT1> maybe it's a matter that they have much more resources
[11:52] <Le-Chuck_IT1> the point is: I am experimenting with living like ubuntu is MY software
[11:52] <mc44> I think mostly it is much stricter since we broke peoples X SERVERS with an upate to dapper stable
[11:53] <Le-Chuck_IT1> well again this confirms that "non critical" software could be easily quick-fixed while critical software should not be touched
[11:54] <Le-Chuck_IT1> another problem being that I find bugs in the sofware I use every day
[11:54] <Le-Chuck_IT1> so I must choose either to use the development version or not to contribute at all
[11:55] <mc44> you can still report bugs in stable versions
[11:55] <Le-Chuck_IT1> I did this intensively and many times I found that bugs where already reported and fixed in upstream, feisty or debian testing
[11:56] <Le-Chuck_IT1> that's a dog eating its tail :)
[11:56] <mc44> see, isnt free software great :) all your bugs are fixed!
[11:56] <Le-Chuck_IT1> Don't want to bore anyone with this chat, however it is important for me to understand what's the ubuntu mood about these issues :)
[11:56] <Le-Chuck_IT1> yes but I won't benefit of the fixes until feisty which will have other bugs that will not be fixed
[11:57] <mc44> Le-Chuck_IT1: ah but new and exciting bugs
[11:57] <Le-Chuck_IT1> I left dapper for the huge number of bugs that where there and in edgy
[11:57] <Le-Chuck_IT1> I had to resist a lot to the temptation
[11:57] <Le-Chuck_IT1> because I really like ubuntu
[11:57] <Le-Chuck_IT1> however
[11:57] <Le-Chuck_IT1> not to repeat myself
[11:57] <Le-Chuck_IT1> perhaps backporting is the right thing to do
[11:58] <Le-Chuck_IT1> do you think so mc44?
[11:58] <sfllaw> In many cases, backporting is the right thing.
[11:58] <sfllaw> Although we are doing stable updates for software that has a simple patch to fix bugs.
[11:58] <sfllaw> For instance, you can search the verification-needed tag, which shows packages that I'm aggressively testing.
[11:58] <sfllaw> Those will end up in dapper-updates or edgy-updates.
[11:59] <Le-Chuck_IT1> I think I should try again to push the beagle cron script and lyx
[11:59] <Le-Chuck_IT1> s/think/feel like/
[12:00] <Le-Chuck_IT1> lyx is completely useless in its current form
[12:00] <Le-Chuck_IT1> the dapper version was better
[12:00] <Le-Chuck_IT1> "Users of the official release, in contrast, expect a high degree of stability." this is what I think too
[12:00] <sfllaw> Your best bet is to find someone on IRC or via e-mail.
[12:01] <sfllaw> Discuss what the best minimal patch is to resolve the issue.
[12:01] <sfllaw> You can't really add features, but you can unbreak things.
[12:01] <Le-Chuck_IT1> and lyx is definitely not respecting this philosophy
[12:01] <Le-Chuck_IT1> sfllaw: the problem with lyx was gcc 4.1
[12:01] <sfllaw> Is it a compilation problem?
[12:01] <Le-Chuck_IT1> no, it's "lots of crashes" :) that version of lyx should never have reached a stable release of ubuntu
[12:02] <sfllaw> Ah.  I doubt you could convince anyone to go back a version.
[12:02] <Le-Chuck_IT1> it was a "keep version 1.3 or wait for the next release"
[12:02] <Le-Chuck_IT1> feisty release works well and I am ready to bet money it won't break any other pacakge
[12:02] <sfllaw> That one is a backport, I think.
[12:03] <Le-Chuck_IT1> ok, I see. I had it approved for backport today.
[12:03] <Le-Chuck_IT1> but
[12:03] <Le-Chuck_IT1> I talk with new ubuntu users almost every week here
[12:03] <Le-Chuck_IT1> in italy
[12:03] <Le-Chuck_IT1> and
[12:04] <Le-Chuck_IT1> they're all disappointed with the high number of bugs they encounter
[12:04] <sfllaw> Edgy is a not so polished release, as we put in a number of new things in a short amount of time.
[12:04] <Le-Chuck_IT1> e.g. that damn evince not remembering double-sided printing, that update issue and evolution autocontacts broken again :(
[12:05] <Le-Chuck_IT1> dapper was much worse!
[12:05] <Le-Chuck_IT1> don't misunderstand me
[12:05] <Le-Chuck_IT1> I really like edgy