=== }Relic{ is now known as [Relic] === ara is now known as Guest99538 === jrib is now known as Guest30479 === Guest30479 is now known as jrib === cipher is now known as Guest11081 [13:32] hey pedro_ [13:33] hello brendand! [13:33] pedro_ - i got an email today about my bug-control membership expiring. do i need to do anything? [13:34] brendand, you just did it :-P, give me a second and i'll renew it [13:36] brendand, all done [13:36] hggdh, hello to you Sir! [13:37] jibel, salut! :-) [13:37] pedro_: salutaciones (??) [13:37] jibel: salut [13:38] and Happy New Year! [13:38] New year? did i lost the Chinese new year again? [13:38] LOL [13:39] no, today is hosh hoshanah, Jewish new year [13:40] AH! then [13:40] hggdh, micahg Happy New Year! :-) [13:40] pedro_: why, thank you, same to you :-) [13:57] Hey pedro_ hggdh micahg and all [13:58] hggdh, you're too early, New Year starts at sundown IIRC [13:58] (although it's already sundown somewhere) === plars is now known as plars-away [14:27] jibel: why wait? [14:28] and yes, it is officially at sundown today === ara is now known as Guest78845 === mvo_ is now known as mvo [15:42] thanks pedro_, just a little less that 8 hours away :) [16:23] hggdh: morning, getting in touch with you to prevent my ubuntu-bugcontrol membership from expiring, as per an email I got today :) [16:27] roadmr: looking. Will cost you a beer ;-) [16:28] hggdh: UDS is coming, so the timing is good :) [16:30] roadmr: done [16:30] hggdh: awesome, thanks a bunch! [16:30] roadmr: the pleasure is ours... we appreciate the help === yofel_ is now known as yofel [17:49] so is there an easy way to grab the version of a package from launchpad? [17:49] pedro_, might be? [17:49] pedro_, not easy, but I think so [17:50] * Ursinha goes through the docs [17:50] might consider bdmurray knows the answer already [17:50] so my first thought was to start looking at the dates and comparing those [17:50] like a bug fixed upstream with no change for a year probably would be also fixed in our packages [17:51] so it has an upstream bugtask, which is closed, and an Ubuntu one? [17:51] One thing I did with needs-packaging bugs with two that were similar was say in bug A "hey look at bug B" and in bug B "say hey look at bug A" [17:51] and an Ubuntu task which remains open [17:52] In the hopes that people interested in the bugs and already subscribed would merge them [17:52] this worked surprisingly well and would be a good first step [17:52] but i can hit some false positives with software with no recent tarballs [17:52] which we just pick 'some' fixes and not the whole repository [17:53] so that's why I'd like to also consider the version number to try to avoid that [17:53] * Ursinha tries to understand how it works [17:54] pedro_, can you give me a bug as example so I can visualize that? [17:54] please [17:54] Ursinha, visualize what part? [17:55] I don't have an example right now of the second part i was describing [17:55] sorry, the first one, that would be a real positive [17:55] if that can be said [17:55] :) [17:55] sure, one sec [17:56] bug 105874 [17:56] pedro_: Bug 105874 on http://launchpad.net/bugs/105874 is private [17:56] no is not :-P [17:56] lol [17:56] bug 115634 [17:56] pedro_: Bug 115634 on http://launchpad.net/bugs/115634 is private [17:57] haha the bot hate me [17:57] bug 1 [17:57] bdmurray: Bug 1 on http://launchpad.net/bugs/1 is private [17:57] wtf [17:57] anyways there's the link, the bug is not private , just too old [17:57] that means it's failing [17:57] with something as a timeout [17:57] i blame hggdh [17:57] * bdmurray grabs pitchfork [17:58] haha [17:59] pedro_, the upstream bugtask is necessarily linked to an upstream bug? as bug 115634 [17:59] Launchpad bug 115634 in gedit-plugins (Ubuntu) (and 1 other project) "include *bib in gedit comment plug-in" [Wishlist,Triaged] https://launchpad.net/bugs/115634 [17:59] ha, what [18:00] bug 1 [18:00] Launchpad bug 1 in tilix (and 28 other projects) "Microsoft has a majority market share (affects: 946) (dups: 2) (heat: 4488)" [High,New] https://launchpad.net/bugs/1 [18:00] yeah, bot hates you both :P [18:07] Ursinha: not necessarily. Some upstreams do not have a BTS we can link to (for example, bug 860871) [18:07] Launchpad bug 860871 in ntfs-3g (Ubuntu) (and 1 other project) "typo in error string regarding cluster references (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/860871 [18:09] pedro_: you might check and see if bryce has done any work in this area [18:15] bdmurray, ok, will ask him and also check in arsenal just in case they have something similar there [18:16] pedro_: bug 423817 is desktop right? [18:16] Launchpad bug 423817 in brother-cups-wrapper-common (Ubuntu) "brcupsconfpt1 assert failure: *** buffer overflow detected ***: /usr/Brother/Printer/dcp560cn/cupswrapper/brcupsconfpt1 terminated (affects: 97) (dups: 66) (heat: 710)" [High,Triaged] https://launchpad.net/bugs/423817 [18:17] bdmurray, more like a MOTU/Till [18:21] hggdh, in that case, how do we know if there's a fix upstream? [18:21] pedro_, Ursinha: fyi I'm working on a search-bugs --package --consolidate script for every package with a pattern [18:22] bdmurray, great [18:22] bdmurray, ie: we don't have to use --package=ubuntu anymore? [18:23] no something that runs regularly seeing if any new desktop couch bugs came in matching a pattern [18:23] Ursinha: it depends. In the example I gave, the bug & the patch were communicated to upstream in what seems the single way they accept it; I do not know if they will ever tell us anything more [18:23] so parse bugpatterns.xml for packages and run search-bugs --package package --tags apport-crash --consolidate [18:23] bdmurray, ah that's cool :-) [18:23] hggdh, but do we proactively look for fixes? [18:24] hggdh: I believe the starting point for this is ubuntu bugs with a bug watch that is fix released [18:24] hggdh: so your silly bug wouldn't be in the list [18:24] lol [18:24] bdmurray is mean [18:24] Ursinha: sometimes -- for example, coreutils -- you open a bug via email (to bug-coreutils@gnu.org); looking at the thread you will know if it was accepted [18:24] hggdh: again with the corner cases [18:24] oh it's because hggdh is celebrating the New Year? [18:24] bdmurray: er, *your* silly bug ;-) I just proposed a patch :-) [18:25] ssh don't tell [18:25] LOL [18:26] bdmurray: indeed. But Ursinha's question was if we *always* link to an upstream BTS. The answer is no, and two corner cases shown [18:26] bdmurray, he made his point :) [18:27] hggdh: okay I guess I missed something then [18:27] Ursinha: we *should* look proactively to fixes; if an upstream is marked fix released, we should consider applicability for us -- perhaps a sync from Debian, etc [18:27] hggdh, right. I wanted to know how do we do that currently, if we do [18:28] * hggdh thinks we do not, not really [18:28] right [18:28] darn it! My AWS instance just died a horrible death on reboot :-( [18:30] so, a case we can cover now: bugs that have linked upstream bugs and are fix released, and have ubuntu tasks opened [18:30] having this is a starting point, right? [18:31] pedro_, how do you do that manually today? [18:32] Ursinha, which part? the searching ? the seeing if the fix is included in our package or not? [18:33] how do you get the first list of bugs that you'll go through checking case by case [18:33] i've wrote an script to do it, before that i was doing the search on lp which eek... [18:35] pedro_, can I see it? I want to have an idea on the query you're running.. [18:35] Ursinha, ubuntu.searchTasks(bug_supervisor=team, status_upstream='resolved_upstream', order_by='-heat'): [18:36] hm, okay [18:36] and since that returns a lot of false positives, i'm also checking the remote_status [18:36] of the bug_watch object [18:44] hm [18:44] fix released in launchpad that are not resolved upstream? [18:52] pedro_, the remote_status needs to be what to be valid? [18:53] it needs to be 'RESOLVED FIXED' [18:53] okay [18:54] pedro_, what's the difference between closed fixed and resolved fixed? [18:55] or any other resolved? [18:55] there's also only "fixed" [18:58] Ursinha, it's different between upstream BTS, in Bugzilla at least (freedesktop, gnome) its resolved fixed [18:58] in Debian i think its 'done' [18:59] so not sure from where its that closed fixed [18:59] and yes there's plenty of other resolved status [19:00] at least to the BTS i'm looking at there is: resolved fixed, resolved duplicate, resolved invalid, resolved no a bug, wontfix ,etc [19:00] s/no/not [19:01] right, so it varies [19:02] I can look at the BTS of the packages that show different values and see the expected ones [19:31] Ursinha: most of this will have been mapped by the LP folks -- LP translates between the upstream status and ours, so they should have a mapping available for those we know [19:34] After asking the reporter about some more information (I suspected it might be a duplicate), I forgot about bug 770373 for a while and it expired. Any ideas what I should to with? Reopen to new? [19:34] Launchpad bug 770373 in etherape (Ubuntu) "etherape does not work after installation (affects: 1) (heat: 3)" [Undecided,Expired] https://launchpad.net/bugs/770373 [19:35] hjd: looking [19:36] hjd: in this case the OP answered, but did not change the status from Incomplete to New -- so it automagically expired [19:36] hjd: you can reopen it (move status to New) and keep on [19:39] hggdh: reopened it now. [19:39] hjd: thank you for helping, BTW :-) [19:40] I have to admit I am not really sure what to do with this bug in the future, but I'll leave it open and hopefully someone will come along and sort it out. [19:45] hjd: well, I am confused as well w.r.t. the OP [19:46] 's response [20:29] bug 858119 sounds like a good thing to me [20:29] Launchpad bug 858119 in ubuntu "the antenna wi-fi does not ignite (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/858119 [20:30] Houston we're ready to launch the antenna [20:30] heh === plars-away is now known as plars === plars is now known as plars-away