| <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. | |
| <andresmujica> thanks | |
| <andresmujica> #74302 | |
| <crimsun> LP is experiencing technical difficulties atm. | |
| <andresmujica> hmm , i supposed that.. | |
| <andresmujica> ok i'll wait for a bit. | |
| *** Hobbsee_ is now known as Hobbsee | |
| <sfllaw> Hobbsee: Did you complain to #launchpad about d_jedi? | |
| <sfllaw> By the time I saw your ping, you were gone. | |
| <Hobbsee> sfllaw: yep | |
| <Hobbsee> sfllaw: yes. i do sleep occasionally, sorry :( | |
| <sfllaw> Same here. | |
| <sfllaw> :) | |
| <sfllaw> Thanks! | |
| <sfllaw> You rock. | |
| <Hobbsee> :) | |
| *** Hobbsee_ is now known as Hobbsee | |
| <TheMuso> c | |
| <Hobbsee> d | |
| <Admiral_Chicago> hmm channel is all quite | |
| <Admiral_Chicago> is LP still down? | |
| <somerville32> LP isn't down forme | |
| <Admiral_Chicago> somerville32: someone said it was "LP is experiencing technical difficulties atm." | |
| <Admiral_Chicago> so maybe the bot isn't updating the bugs or something | |
| <somerville32> Hmm... | |
| *** theCore is now known as theCore_ | |
| *** Cas_ is now known as Cas | |
| <dholbach> good morning | |
| <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? | |
| <dholbach> towsonu2003: did you ask simon about it? he does the approval normally | |
| <dholbach> (sfllaw that is) | |
| <dholbach> towsonu2003: but I saw you worked on a huge load of bugs already, I'm going to approve you now | |
| <towsonu2003> dholbach, oh okay thanks :) | |
| <towsonu2003> dholbach, is there a documentation page specific to ubuntu-qa I should read? (sorry to bother you again) | |
| <dholbach> towsonu2003: we should have one | |
| *** Cas_ is now known as Cas | |
| <towsonu2003> dholbach, I couldn't find one. I'll google a bit more then ,thanks :) | |
| <Admiral_Chicago> when is Ubugtu going to start udating from LP | |
| <dholbach> towsonu2003: ok, I didn't find anything | |
| <dholbach> towsonu2003: I'm going to add a blurb on the BugSquad page and one describing the bug statuses | |
| <towsonu2003> dholbach, thanks a lot :) | |
| <towsonu2003> dholbach, oh almost forgot, could you add a couple of notes on bug importance and when to change it? thanks again | |
| <dholbach> towsonu2003: your wish is my command | |
| <towsonu2003> dholbach, lol | |
| <dholbach> https://wiki.ubuntu.com/Bugs/Importance | |
| <dholbach> added it to https://wiki.ubuntu.com/Bugs/HowToTriage | |
| <towsonu2003> thanks a lot, I really appreciate it :) | |
| <dholbach> thanks for notifying me | |
| * dholbach hugs towsonu2003 | |
| <dholbach> added the blurbs about ubuntu-qa too | |
| <dholbach> https://wiki.ubuntu.com/BugSquad and https://wiki.ubuntu.com/Bugs/Importance | |
| * towsonu2003 hugs back dholbach | |
| <towsonu2003> great | |
| <dholbach> super | |
| <towsonu2003> I'll start reading once I'm done watching Star Trek | |
| <dholbach> hehe | |
| <dholbach> enjoy it | |
| <towsonu2003> :p | |
| <palski> Shouldn't this be "fix committed"? Bug #68074 | |
| <Ubugtu> Malone bug 68074 in curl "Seg fault when connecting" [Undecided,Confirmed] http://launchpad.net/bugs/68074 | |
| <palski> the fix is already in CVS | |
| <somerville32> Depends if the package is upstream or not | |
| <palski> bug was in upstream and fix has committed to upstream cvs | |
| <somerville32> Hmm | |
| <palski> "Fix Committed: A fix has been included in the code, but this code is not necessarily available in a released version" | |
| <somerville32> One second | |
| <crimsun> palski: it can be, yes | |
| <somerville32> I affected it upstream | |
| <somerville32> crimsun: The local source package can stay at confirmed until we do an sru? | |
| <crimsun> that'll be fine | |
| <palski> if it is fixed in feisty, wouldn't that be "fix released"? | |
| <palski> and a new bug report should be done for sru request? | |
| <somerville32> Yeah, thats probably right. | |
| <crimsun> yes, and yes | |
| <somerville32> Crimsun: Will you do the sru? | |
| <crimsun> somerville32: I don't have time atm. | |
| <somerville32> k | |
| <crimsun> are you familiar w/ the process? I don't mind walking you through it. | |
| <crimsun> more people should become familiar w/ it, really. | |
| <somerville32> Well, I'm in Windows right now (simply because I was too lazy to reboot after the last person who was on) | |
| <somerville32> And I doubt it would go well using the live cd | |
| <somerville32> I suppose I could move downstairs to my lab | |
| <crimsun> you need access to a Terminal [of choice] and some standard packaging tools (devscripts, etc.) | |
| <crimsun> it doesn't require much more | |
| <somerville32> Alrighty | |
| <somerville32> I'll be right back | |
| <palski> you really need devscripts for filling up sru? | |
| <crimsun> no, but it's quite convenient | |
| <crimsun> e.g., devscripts: /usr/bin/debdiff | |
| <somerville32> :] | |
| <somerville32> Alrighty, brb | |
| <somerville32> Crimsun: Alrighty. | |
| <crimsun> somerville32: ok, got a terminal or two open? | |
| <somerville32> Yup :) | |
| <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 ] | |
| <somerville32> Alrighty. :) | |
| <crimsun> next thing is to isolate the patch from upstream cvs that fixes the issue and to download it | |
| <somerville32> Got it | |
| <crimsun> [I presume it's http://librarian.launchpad.net/5179200/multi_expire.diff ?] | |
| * somerville32 nods. | |
| <crimsun> ok, next thing is to extract the source package [dpkg-source -x curl_7.15.4-1ubuntu2.dsc ] | |
| <crimsun> then, cwd into the root of the extracted source | |
| <somerville32> k | |
| <crimsun> at this point, it's a good idea to check if the Debianised source package uses a patch management system | |
| <crimsun> e.g., inspect debian/{control,rules} and look for the existence of debian/patches/ | |
| <crimsun> specifically: | |
| <crimsun> in debian/control, look at the Build-Depends line, and see if it uses cdbs, quilt, dpatch, etc. | |
| <crimsun> in debian/rules, look for *patch* target(s) | |
| <crimsun> and finally, if debian/patches/ exists, it's nearly always a dead giveaway that some sort of patch management system is used | |
| * somerville32 nods | |
| <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 ] | |
| <crimsun> now you need to patch the Debianised source, but you'll find there's one reject | |
| <crimsun> [patch -p1 --dry-run <../multi_expire.diff ] | |
| <crimsun> [it's always sane to test using --dry-run ] | |
| * somerville32 nods. | |
| <crimsun> at this point, you'll manually inspect the reject and hand-apply the necessary fix | |
| <somerville32> Is it possible to see where the rejection is occurring? | |
| <crimsun> yep, look at lib/multi.c.rej | |
| <crimsun> in another window, it helps to open lib/multi.c | |
| <somerville32> It didn't actually write it | |
| <crimsun> oh, right. apply it (no --dry-run) | |
| <somerville32> k | |
| <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 | |
| <crimsun> then you'll hand-insert that line into lib/multi.c | |
| <somerville32> Hmm... | |
| <crimsun> [clear so far? ] | |
| <somerville32> Yeah but I'm having a hard time matching up the reject to the new code | |
| <crimsun> right, you have to scroll up 12 lines from the original target | |
| <somerville32> I did | |
| <crimsun> ok, do you see the if(easy) { | |
| <crimsun> /* If the 'state' ... | |
| <somerville32> Yup | |
| <somerville32> Oh! | |
| <crimsun> yeah, fortunately this one was straightforward | |
| <crimsun> it can be a real PitA | |
| <somerville32> Do you see line 19 in the rej file? | |
| <somerville32> Like, 18-21 | |
| <somerville32> Where is that stuff? | |
| <crimsun> yep. Those aren't in lib/multi.c , because that was added in .5 | |
| * somerville32 boggles. | |
| <crimsun> (welcome to the joy of backporting fixes) | |
| <crimsun> note, however, that semantically the context is nearly identical in the old one [to which you're applying the fix ] | |
| <crimsun> the difference is an additional if(easy->easy_handle == ... ) | |
| <somerville32> Maybe I'm still confused | |
| <somerville32> I thought I had to add the parts with the the plus signs in front | |
| <somerville32> haha | |
| <crimsun> yes, you do | |
| <crimsun> that's the portion that failed to apply | |
| <crimsun> the significant portion that failed to apply is just one line: Curl_expire(easy->easy_handle, 0); | |
| <somerville32> Ok, thats what I thought | |
| <crimsun> so, noting the context prior and following that failed portion, you can see where to apply it | |
| <somerville32> But I don't see the other parts in that new file | |
| <crimsun> which other parts? | |
| <crimsun> (I only have one reject) | |
| <somerville32> Ok, in the rej file | |
| <somerville32> Line 6 | |
| <crimsun> right, it's not in edgy's curl source because that was added for feisty's | |
| <somerville32> So... | |
| <crimsun> (that's why it failed to apply) | |
| <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. */ | |
| <crimsun> right | |
| <somerville32> haha | |
| <somerville32> Ok | |
| <somerville32> I understand now | |
| <somerville32> You should have told me why it failed and I would have gotten it, haha | |
| <somerville32> <g | |
| <crimsun> I did 7 minutes ago ;) | |
| <somerville32> You'll have to forgive me | |
| <crimsun> no prob | |
| <somerville32> It is 6:13am here | |
| * somerville32 grins. | |
| <crimsun> 5:12a here | |
| <somerville32> Alrighty. manually patched | |
| <crimsun> ok, next, clean up the source tree by removing *.orig and *.rej | |
| <crimsun> [find -name '*.orig' |xargs rm && find -name '*.rej' |xargs rm ] | |
| <somerville32> k | |
| <crimsun> now you're ready to generate a changelog entry | |
| <somerville32> :] | |
| <crimsun> [dch -v7.15.4-1ubuntu2.1 -Dedgy-proposed ] | |
| <crimsun> (fill in the appropriate info) | |
| <somerville32> dch isn't installed | |
| <somerville32> What package do I need? | |
| <crimsun> devscripts :) | |
| <somerville32> :] | |
| <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. ] | |
| * somerville32 is a gedit fan. | |
| <somerville32> What should I say in the changelog? | |
| <crimsun> the format for a -proposed entry generally references files that were changed and why | |
| <somerville32> Example? | |
| <somerville32> * curl/lib/multi.c patched to fix bug #68074 ? | |
| <Ubugtu> Malone bug 68074 in curl "Seg fault when connecting" [Unknown,Unknown] http://launchpad.net/bugs/68074 | |
| <crimsun> e.g., http://pastebin.ca/259304 | |
| <somerville32> Do I need a @ubuntu.com e-mail address? I read somewhere that I did. | |
| <crimsun> it's not strictly necessary | |
| <crimsun> since you aren't a dev yet, you should get a core-dev to ACK the debdiff | |
| <crimsun> (you'll generate the debdiff next) | |
| <somerville32> parsechangelog/debian: error: unrecognised line, at changelog line 4 | |
| <somerville32> dch: fatal error at line 983: | |
| <somerville32> Problem executing dpkg-parsechangelog: | |
| <crimsun> make sure your syntax is correct | |
| <crimsun> note that in the pastebin, lines 5-6 are actually one line | |
| <somerville32> Ok, I fixed it | |
| <somerville32> Should I run the script again or something? | |
| <crimsun> which script are you referring to? | |
| <crimsun> (you need the changelog entry) | |
| <somerville32> dch | |
| <crimsun> you only need to run it to add the entry | |
| <somerville32> Alrighty. | |
| <somerville32> Whats next? | |
| <crimsun> since it failed, yes, you'll need to make sure the entry is there | |
| <somerville32> in debian/changelog | |
| <somerville32> ? | |
| <crimsun> yes, at the top | |
| <somerville32> It is there | |
| <somerville32> I manually edited it to fix the line break on line 4 | |
| <crimsun> excellent. Now you have to make sure you file a bug report that will be referenced, as the SRU, in the changelog | |
| <crimsun> if you wish, you can use 68074 for that | |
| <somerville32> So I don't need to file a second bug? | |
| <crimsun> not necessarily, though it helps for clarity | |
| <crimsun> SRU policy is outlined at [https://wiki.ubuntu.com/StableReleaseUpdates ] | |
| <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) | |
| <somerville32> Well, I'll open a new bug report since I said I said Daniel wouldn't get anymore e-mails, haha | |
| <crimsun> ok, just make sure you edit debian/changelog before you generate the debdiff | |
| <somerville32> Can I put the SRU bug number on it's own "asterisk"? | |
| <crimsun> if you wish to, yes. I normally reference all the Ubuntu bug #s together by topic | |
| <crimsun> (so I'd place them together) | |
| <crimsun> fault (Closes Ubuntu: #68074, _and whatever SRU bug #_). | |
| <crimsun> (note that you'd attach the debdiff to this new bug that you're filing) | |
| <crimsun> ok, since I have to scoot in a bit, I'm going to outline what else you need to do | |
| <crimsun> 1) adjust debian/changelog | |
| <crimsun> 2) generate a debdiff | |
| <somerville32> How else do I have to modify debian/changelog? | |
| <crimsun> 3) add the relevant info, including the debdiff and diffstat info, to the new bug | |
| <crimsun> debian/changelog needs to reference the SRU bug # | |
| <crimsun> (you'll see that when you reread https://wiki.ubuntu.com/StableReleaseUpdates ) | |
| <crimsun> now, generating a debdiff is quite straightforward. While in the root of the extracted source, you issue a ``debuild -S'' | |
| <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 | |
| <crimsun> you should cwd to that parent directory to generate a debdiff (the previous step just generated a Debianised source package) | |
| <crimsun> debdiff accepts several different files; I use the dscs | |
| <crimsun> ``debdiff curl_7.15.4-1ubuntu2.dsc curl_7.15.4-1ubuntu2.1.dsc >curl_7.15.4-1ubuntu2.1.debdiff'' | |
| <crimsun> and that's the debdiff that is applicable to the original edgy source package | |
| <crimsun> you'd attach that to the new bug report | |
| <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 | |
| <crimsun> (diffstat is in the diffstat package) | |
| <crimsun> diffstat curl_7.15.4-1ubuntu2.1.debdiff | |
| <crimsun> afterward, you'd attach all that info to the new bug report, following step #1 (Propose) of the SRU process | |
| <crimsun> always build and test your debdiff before subscribing the ubuntu-sru team | |
| <crimsun> (I need to return to work) | |
| * somerville32 waves. | |
| <somerville32> Gah | |
| <somerville32> It isn't working | |
| <fernando> moin all | |
| <somerville32> Hi | |
| <fernando> seb128: hi, not is gnome-vfs2 2.16.1-0ubuntu2 the latest stable? | |
| <seb128> fernando: stable = upstream stable or Ubuntu stable? | |
| <fernando> seb128: ubuntu stable | |
| <fernando> apt-cache show libgnomevfs2-0 | grep -i version | |
| <fernando> Version: 2.16.1-0ubuntu2 | |
| <seb128> there is a 2.16 | |
| <fernando> seb128: you have pached the 2.16.1-0ubuntu3 | |
| <seb128> .2.16.1-0ubuntu3 to edgy-proposed which fix the 100% CPU bug | |
| <fernando> s/pached/patched/ | |
| <fernando> seb128: ah, ok | |
| <fernando> seb128: thanks | |
| <seb128> np | |
| <seb128> does that answer your question? | |
| <seb128> you are looking for that update? | |
| <seb128> it's to "edgy-proposed", which is not part of the default sources.list | |
| <fernando> seaLne: thanks | |
| <fernando> seb128: thanks | |
| <seb128> np | |
| <somerville32> Woot. | |
| <somerville32> Got it to work | |
| <somerville32> Alrightys, times for bed | |
| * somerville32 waves. | |
| *** Cas_ is now known as Cas | |
| *** Cas_ is now known as Cas | |
| <bddebian> Boo | |
| <pirast> bddebian, boooooohooooooo! | |
| <bddebian> Hehe. Hello pirast | |
| <pirast> hi ;-) | |
| <Hobbsee> hey pirast | |
| <dholbach> sfllaw: it'd be good to announce the next hug day in your open week session | |
| <sfllaw> Yes, I think so. | |
| <sfllaw> I should probably get fridge-devel to put it up. | |
| <jonh_wendell> seb128: where is this bug nowadays: https://bugzilla.ubuntu.com/2055 ?? | |
| <joumetal> jonh_wendell Sebastian is busy now at #ubuntu-classroom. What was this bug about? | |
| <jonh_wendell> joumetal: it's a outdated bug... i'd want just a confirmation from sebastien | |
| <seb128> jonh_wendell: http://bugzilla.ubuntu.com/show_bug.cgi?id=NUMBER | |
| <seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=2055 | |
| <seb128> for that one | |
| <jonh_wendell> seb128: thanks | |
| <seb128> jonh_wendell: np | |
| <seb128> jonh_wendell: closing old bugs like that on bugzilla is not the way to go | |
| <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 | |
| <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 | |
| <seb128> jonh_wendell: you usually ask the submitter if it still gets the issue before closing something | |
| <jonh_wendell> seb128: the submitter is you; i've looked the LP bug report and it was rejected in Ubuntu | |
| <seb128> jonh_wendell: don't use the stock reply but say that to the comment in such case then :) | |
| *** omgponiezlol is now known as Admiral_Chicago | |
| <jonh_wendell> seb128: should i reopen that vino bug? | |
| <seb128> jonh_wendell: no that's fine, nobody has got it for a long time apparently | |
| <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 | |
| <jonh_wendell> seb128: sure, thanks for the tip | |
| <seb128> saying "you used an old version, I'm closing your bug" just doesn't apply for people using GNOME 2.10 | |
| <seb128> 80% of the GNOME 2.10 bugs are still valid on GNOME 2.16 probably | |
| <seb128> np! | |
| *** FeddyM is now known as Admiral_Chicago | |
| *** omgponiezlol is now known as Admiral_Chicago | |
| *** jonh_wendell_ is now known as jonh_wendell | |
| *** omgponiezlol is now known as Admiral_Chicago | |
| <Adri2000> Ubugtu dead? | |
| <Admiral_Chicago> Adri2000: i think so, Lp was having problems according to crimsun | |
| <Le-Chuck_IT1> hi all | |
| <Le-Chuck_IT1> I have a question about bug fixing in ubuntu in general | |
| <Burgwork> shoot | |
| <Le-Chuck_IT1> I see that edgy has been released quite in time | |
| <Le-Chuck_IT1> but with some bugs affecting various packages | |
| <Admiral_Chicago> yes | |
| <Le-Chuck_IT1> and I can show evidences that these bugs are really a showstopper for many people | |
| <Le-Chuck_IT1> and | |
| <Le-Chuck_IT1> can I expect that they'll ever be fixed in edgy, not in feisty | |
| <Le-Chuck_IT1> and if not | |
| <Le-Chuck_IT1> isn't this gonna repeat in feisty? | |
| <Admiral_Chicago> Le-Chuck_IT1: what kind of bugs | |
| <Admiral_Chicago> further, do you have bug reports that we can inspect | |
| <Le-Chuck_IT1> e.g. beagle (which is in universe) breaking yelp once installed | |
| <Le-Chuck_IT1> lyx | |
| <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 | |
| <Le-Chuck_IT1> which in edgy is completely broken | |
| <Le-Chuck_IT1> and the italian locales for synaptic | |
| <Le-Chuck_IT1> that have been breaking italian update-manager since a month ago | |
| <mc44> Le-Chuck_IT1: well they will likely be fixed if they prevent upgrading | |
| <Le-Chuck_IT1> well I am a bit worried by the last one | |
| <Le-Chuck_IT1> seems like the simple fix of removing a ' character | |
| <Le-Chuck_IT1> has been put apart in favour of most serious fixes | |
| <Le-Chuck_IT1> but | |
| <Le-Chuck_IT1> what does it take to change a string | |
| <Le-Chuck_IT1> and update the fix immediately | |
| <Le-Chuck_IT1> expecially because it's a "stable update" that is breaking things | |
| <mc44> Le-Chuck_IT1: is there a bug filed for this? | |
| <Le-Chuck_IT1> I can point out https://launchpad.net/distros/debian/+source/beagle/+bug/67778 for the first one I mentioned | |
| <Ubugtu> Malone bug 67778 in beagle "Search don't work with beagle" [Unknown,Fix released] | |
| <Le-Chuck_IT1> now | |
| <mc44> Le-Chuck_IT1: I mean the locale problem | |
| <Le-Chuck_IT1> yes I know :) | |
| <Le-Chuck_IT1> just pasting the other one | |
| <mc44> :) | |
| <Le-Chuck_IT1> yes there is a well know open bug | |
| <Le-Chuck_IT1> even if perhaps I am not subscribed to that since I'm not finding it | |
| <Le-Chuck_IT1> I don't know | |
| <Le-Chuck_IT1> is asking a backport the right way to proceed? | |
| <Le-Chuck_IT1> instead of an SRU which is more complicated, I mean | |
| <mc44> its depends on the problem, if it is a language pack causing it, then it is adifferent matter | |
| <Le-Chuck_IT1> yes | |
| <mc44> Le-Chuck_IT1: https://bugs.launchpad.net/distros/ubuntu/+source/update-manager/+bug/70959 ? | |
| <Le-Chuck_IT1> but consider beagle | |
| <Ubugtu> Malone bug 70959 in update-manager "update-manager doesn't install updates when Italian locale is on" [Undecided,Unconfirmed] | |
| <mc44> Le-Chuck_IT1: beagle is non critical and unlikely to be updated with an SRU | |
| <Le-Chuck_IT1> here it is! https://launchpad.net/products/update-manager/+bug/51419 | |
| <Ubugtu> Malone bug 51419 in gksu ""Install updates"-button only refreshes update list in it_IT environement" [High,Confirmed] | |
| <Le-Chuck_IT1> and of course 70959 is a duplicate of this one | |
| *** mr_pouit_ is now known as mr_pouit | |
| <Le-Chuck_IT1> I see beagle is non critical :) The point is | |
| <Le-Chuck_IT1> if software is non critical why not quick fix it expecially when it breaks more important programs? | |
| <Le-Chuck_IT1> not to be polemic | |
| <mc44> Le-Chuck_IT1: becasue it may well break many other things that are working fine | |
| <Le-Chuck_IT1> I am just trying to figure out best practices | |
| <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 | |
| <Le-Chuck_IT1> ok I surrender :) | |
| <Le-Chuck_IT1> I already went for a backport and it looks like it will be done | |
| <mc44> Le-Chuck_IT1: yay :) | |
| <Le-Chuck_IT1> ok but now: I should consider backports sort of "ubuntu quickfixed" | |
| <Le-Chuck_IT1> but it's not really so | |
| <Le-Chuck_IT1> because it's "ubuntu quickfixed with newer versions" | |
| <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 | |
| <Le-Chuck_IT1> I mean | |
| <Le-Chuck_IT1> if I had a software company with many users | |
| <Le-Chuck_IT1> I would release some fix sometime | |
| <Le-Chuck_IT1> for bugs, crashes | |
| <Le-Chuck_IT1> not only for security | |
| <mc44> Le-Chuck_IT1: its a consequence of 6 month release cycle | |
| <Le-Chuck_IT1> I understand | |
| <Le-Chuck_IT1> it's not gentoo | |
| <mc44> and limited resources | |
| <Le-Chuck_IT1> but I see novell releases fixes and does not break things (except for their ugly package manager) | |
| <Le-Chuck_IT1> maybe it's a matter that they have much more resources | |
| <Le-Chuck_IT1> the point is: I am experimenting with living like ubuntu is MY software | |
| <mc44> I think mostly it is much stricter since we broke peoples X SERVERS with an upate to dapper stable | |
| <Le-Chuck_IT1> well again this confirms that "non critical" software could be easily quick-fixed while critical software should not be touched | |
| <Le-Chuck_IT1> another problem being that I find bugs in the sofware I use every day | |
| <Le-Chuck_IT1> so I must choose either to use the development version or not to contribute at all | |
| <mc44> you can still report bugs in stable versions | |
| <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 | |
| <Le-Chuck_IT1> that's a dog eating its tail :) | |
| <mc44> see, isnt free software great :) all your bugs are fixed! | |
| <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 :) | |
| <Le-Chuck_IT1> yes but I won't benefit of the fixes until feisty which will have other bugs that will not be fixed | |
| <mc44> Le-Chuck_IT1: ah but new and exciting bugs | |
| <Le-Chuck_IT1> I left dapper for the huge number of bugs that where there and in edgy | |
| <Le-Chuck_IT1> I had to resist a lot to the temptation | |
| <Le-Chuck_IT1> because I really like ubuntu | |
| <Le-Chuck_IT1> however | |
| <Le-Chuck_IT1> not to repeat myself | |
| <Le-Chuck_IT1> perhaps backporting is the right thing to do | |
| <Le-Chuck_IT1> do you think so mc44? | |
| <sfllaw> In many cases, backporting is the right thing. | |
| <sfllaw> Although we are doing stable updates for software that has a simple patch to fix bugs. | |
| <sfllaw> For instance, you can search the verification-needed tag, which shows packages that I'm aggressively testing. | |
| <sfllaw> Those will end up in dapper-updates or edgy-updates. | |
| <Le-Chuck_IT1> I think I should try again to push the beagle cron script and lyx | |
| <Le-Chuck_IT1> s/think/feel like/ | |
| <Le-Chuck_IT1> lyx is completely useless in its current form | |
| <Le-Chuck_IT1> the dapper version was better | |
| <Le-Chuck_IT1> "Users of the official release, in contrast, expect a high degree of stability." this is what I think too | |
| <sfllaw> Your best bet is to find someone on IRC or via e-mail. | |
| <sfllaw> Discuss what the best minimal patch is to resolve the issue. | |
| <sfllaw> You can't really add features, but you can unbreak things. | |
| <Le-Chuck_IT1> and lyx is definitely not respecting this philosophy | |
| <Le-Chuck_IT1> sfllaw: the problem with lyx was gcc 4.1 | |
| <sfllaw> Is it a compilation problem? | |
| <Le-Chuck_IT1> no, it's "lots of crashes" :) that version of lyx should never have reached a stable release of ubuntu | |
| <sfllaw> Ah. I doubt you could convince anyone to go back a version. | |
| <Le-Chuck_IT1> it was a "keep version 1.3 or wait for the next release" | |
| <Le-Chuck_IT1> feisty release works well and I am ready to bet money it won't break any other pacakge | |
| <sfllaw> That one is a backport, I think. | |
| <Le-Chuck_IT1> ok, I see. I had it approved for backport today. | |
| <Le-Chuck_IT1> but | |
| <Le-Chuck_IT1> I talk with new ubuntu users almost every week here | |
| <Le-Chuck_IT1> in italy | |
| <Le-Chuck_IT1> and | |
| <Le-Chuck_IT1> they're all disappointed with the high number of bugs they encounter | |
| <sfllaw> Edgy is a not so polished release, as we put in a number of new things in a short amount of time. | |
| <Le-Chuck_IT1> e.g. that damn evince not remembering double-sided printing, that update issue and evolution autocontacts broken again :( | |
| <Le-Chuck_IT1> dapper was much worse! | |
| <Le-Chuck_IT1> don't misunderstand me | |
| <Le-Chuck_IT1> I really like edgy | |
| <Le-Chuck_IT1> it's polished in many aspects, it is the best working linux distribution on my tablet pc | |
| <Le-Chuck_IT1> and it's easy to set up | |
| <Le-Chuck_IT1> and it is quite for this reason that I am putting that much effort in finding and reporting bugs | |
| <sfllaw> Well, thank you. | |
| * mc44 hugs Le-Chuck_IT1 | |
| <Le-Chuck_IT1> it seems to me that having it working slightly well, just cleaning those evident problems that cause bad publicity, can enable us to "sell" it (in a figurative sense) to many people | |
| <dsas> Le-Chuck_IT1: Cool, the bugsquad are always looking for new members if you have some spare time every now and then? | |
| <Le-Chuck_IT1> don't thank me, it's just an experiment: living like the free software I use every day is mine, and the world is my customer :) and I shoud really avoid getting crazy after this all :) | |
| <Le-Chuck_IT1> dsas: I have not time to learn how to produce a debdiff for example | |
| <Le-Chuck_IT1> or else I would already be part of it :) | |
| <Le-Chuck_IT1> however | |
| <dsas> Le-Chuck_IT1: Nor have I, the crazy people still let me lend a hand though ;) | |
| <mc44> Le-Chuck_IT1: you dont need to do anything other than help triage bugs | |
| <Le-Chuck_IT1> yes, that's a thing I will learn | |
| <Le-Chuck_IT1> I already have links to all the "motu school" stuff :) | |
| <dsas> Le-Chuck_IT1: There are tasks sized for everyone, I think sfllaw is hosting a talk on how to get involved with the bugsquad sometime this week if you're interested. | |
| <Le-Chuck_IT1> is there a page to watch? | |
| <sfllaw> Tomorrow and Thursday. | |
| <sfllaw> Uhm, yes. | |
| <Le-Chuck_IT1> ah ok :) | |
| <sfllaw> Lemme find it. | |
| <sfllaw> Le-Chuck_IT1: https://wiki.ubuntu.com/UbuntuOpenWeek | |
| <Le-Chuck_IT1> my primary goal is still to have a distribution that I can bet my mother will be able to install alone | |
| <Seveas> sfllaw, this is ridiculous | |
| <Le-Chuck_IT1> not because I can't help my mother installing ubuntu of course :P just because sometimes people asks me about ubuntu and are still scared about issues that can leave them without an OS | |
| <crimsun> I will rephrase the dilemma in perhaps slightly different terms. | |
| <Seveas> if i *reboot* my server, the bot gets on the no-send list | |
| <crimsun> "The ratio of people to cake is too big." | |
| <Seveas> tell the admins to increase Nbounces! | |
| <mc44> crimsun: mmm cake | |
| <Le-Chuck_IT1> sfllaw: is the talk "using launchpad"? | |
| <sfllaw> Seveas: I already did. | |
| <sfllaw> Seveas: It's 50 now. | |
| <sfllaw> Seveas: You may want to get your bot to resubscribe, if it hasn't heard anything in a while? | |
| <Seveas> impossible | |
| <sfllaw> Le-Chuck_IT1: It's an overview, but there will be some LP stuff in there. | |
| <Seveas> it has to set a flag via the web interface | |
| <sfllaw> Seveas: Can it not do that? | |
| <Seveas> sure it can | |
| <Seveas> with a few horrible hacks | |
| <Seveas> whilst it's not even my fault that it's unsubscribed | |
| <Le-Chuck_IT1> maybe I'll be able to follow | |
| <sfllaw> Le-Chuck_IT1: I should think so. | |
| <sfllaw> Seveas: I don't really see any way around it. Ng asserts that he will not be hacking Mailman to get a special exception for ubugtu. | |
| <Seveas> hehe, I wouldn't dare asking for that :) | |
| <Le-Chuck_IT1> sfllaw: perhaps I will have the time to attend the talk, in the meantime I will try not to get insane thinking about the future of ubuntu :) | |
| <sfllaw> Le-Chuck_IT1: Have fun! | |
| <Ubugtu> New bug: #73542 in ssystem (universe) "Please sync ssystem (universe) from unstable (main)" [Wishlist,Confirmed] http://launchpad.net/bugs/73542 | |
| <Ubugtu> New bug: #73545 in gl-117 (universe) "Game just shut down unexpectedly" [Undecided,Unconfirmed] http://launchpad.net/bugs/73545 |