=== dzup is now known as homoluminous === braiam_ is now known as braiam [06:50] Hello. [06:52] I would like to have more control over the bugs for my package and thus I have gone through https://wiki.ubuntu.com/UbuntuBugControl and sent Jorge Castro a message on launchpad around 2 days ago. Any idea how long it'll take to get a response? === yofel_ is now known as yofel === zyga is now known as zyga-afk [13:58] evaluate: should not be long. YOu can also pop in #ubuntu-community-team and ask him directly ;-) [13:58] evaluate: I mean, his nick is on, I _think_ he is on [13:59] nah, don't want to bug him, I was just curios how long this usually takes... [14:01] no problems. jcastro is usually quite responsive to upstream requests [14:10] evaluate: what kind of control? [14:12] paultag, for example I can't set the importance of bugs or set them to 'Won't fix' or 'Triaged'... [14:12] hggdh, I have to go in ~20 minutes, I'll ask him when I'm back. [14:13] evaluate: when you say "my package", does this mean an Ubuntu package that you uploaded? [14:13] evaluate: np, welcome [14:13] or your own project on LP [14:13] paultag, I'm the developer of the program and I'm also the maintainer of it in Debian. [14:13] evaluate: so when you ask Jorge, you're asking to join bug control [14:14] yes [14:14] paultag, that I did already. [14:14] evaluate: usually this has a process, but exceptions are made. He had to do the same for me and my debian packages [14:14] then I ended up actually doing bug work [14:15] paultag: upstream maintainers have an expedited track [14:15] hggdh: aye [14:16] BTW, is there something like 'Debian Maintainer' in Ubuntu, in the sense that I can get upload permissions for a specific package? [14:16] evaluate: there is, but it will be a bit more involved [14:16] evaluate: yes but it's not used much [14:17] it's easier (honestly) to just do MOTU [14:17] yeah [14:17] evaluate: if you get your DDship, you can get MOTU [14:18] Well, since I already package the program for Debian myself, and I also have a PPA which I actively maintain, I guessed it would be easier for everyone if I just upload them to ubuntu too. [14:18] evaluate: that's not the right process, use `requestsync' [14:18] evaluate: upload to debian, then request sync. this is after DIF [14:18] paultag, well, currently I'm very busy, not sure if I can get more involved with Debian atm, and my mentor said he will only advocate when he sees that I have more packages or that I'm more involved... [14:18] right now it should sync as it goes [14:19] decoder: cool. Well, focus on debian side, ubuntu plays nice [14:19] decoder: syncs are easy, you don't need upload rights for that [14:20] But syncs are also done manually by someone, right? [14:20] evaluate: not for the first few months [14:20] only later on [14:20] But the package needs to be changed in order to work properly in Ubuntu. [14:20] I mean, it needs an extra dependency... [14:21] evaluate: then fix the debian directory [14:21] evaluate: you should know (being a package manatainer) that you can set extra deps based on dpkg --vendor [14:21] sorry, dpkg-vendor [14:22] paultag, well, I didn't know that, but I'll look into it. [14:22] evaluate: in the rules, check if vendor is ubuntu, if so set the extra dep, and add that to the control dep lines [14:22] evaluate: check fluxbox if you need an example [14:22] Sounds good. [14:22] paultag, will do. Thanks! [14:22] evaluate: rock on! [14:26] ok, have to go now. See you later and thanks for the help! [15:56] hello, [15:57] does it exist an apport-collect tutorial? [16:03] guillemhs: tutorial for using apport-collect or for how it collects the information? [16:03] tutorial for using apport-collect [16:04] just type apport-collect --help in a terminal [16:04] ok [16:05] It is mainly a way to get the logs for a bug report, so the normal usage is apport-collect BUGNUMBER [16:05] BUGNUMBER is the launchpad id? [16:05] it means that first i have to enter manually the bug title and the initial comment, no? [16:06] BUGNUMER is the launchpad bug report number, such as 726229 [16:06] for bug 726229 [16:06] Launchpad bug 726229 in emerald (Ubuntu) "emerald crashed with SIGSEGV in decor_quads_to_property() (affects: 94) (dups: 10) (heat: 495)" [High,Triaged] https://launchpad.net/bugs/726229 [16:06] guillemhs, are you asking how to initially file a bug or add data? [16:06] apport collect is for adding data to an existing bug [16:08] If you have to enter a bug title and comment, please use ubuntu-bug PACKAGE instead to file the report initially [16:10] can i add an apport-collect to a bug that it is not mine? [16:11] for example, i am testing an specific package [16:11] this paquet crashes [16:11] this package crashes [16:11] then i run ~# ubuntu-bug PACKAGE [16:12] then i rum ~# apport-collect BUGNUMBER_from_the_PACKAGE no? [16:12] run, sorry [16:14] is this the initial reporting procedure? [16:20]

hello? [16:21] charlie-tca JFo hello? [16:22] guillemhs, it will depend on the package and the maintainer's policies for adding data to a bug that isn't yours [16:22] what package is it? [16:23] now i was just asking because i was testing gwyddion [16:23] a then i try to use apport-collect to automate the reporting bug process [16:24] jibel: re bug 779174, I did an upgrade the way you suggested and did not have that issue, I have a new issue with ca-certificates-java in a chroot, also, I think it only affects people that previously upgraded [16:24] Launchpad bug 779174 in openjdk-6 (Ubuntu Oneiric) (and 1 other project) "package ca-certificates-java 20110426 failed to install/upgrade during upgrade to Oneiric: fix path to libnss3 for multiarch (affects: 26) (dups: 18) (heat: 182)" [Critical,Triaged] https://launchpad.net/bugs/779174 [16:25] micahg, I just reproduced it in a VM before adding the comment to be sure. [16:25] jibel: weird [16:25] micahg, indeed, and users are still reporting duplicates. [16:26] jibel: I get this when I try to build eclipse on oneiric: http://pastebin.ubuntu.com/612318/ [16:26] guillemhs: to add to the already reported bug, use apport-collect BUGNUMBER, but you will have to be subscribed to the bug report [16:26] You will not then add a comment or summary [16:26] ok, i see [16:27] thanks [16:27] what charlie-tca said :) [16:27] It might decide not to allow you to add, in which case, you have to do it manually [16:27] and how can i do it manually? [16:27] using a comment to say you have the issues, then attaching the logs one at a time [16:32] ok, but apport-collect selects the correct files and just shows the correct log lines [16:32] how can i do this manually? [16:32] guillemhs: right [16:33] you have to select the files yourself, according to what is already attached to the bug or what the triager requested [16:33] They are in /var/log [16:34] ah ok [16:34] i get it [16:34] i was thinking if apport-collect can be executed and collecting the most current information [16:35] log information and then in an automated way upload that info into launchpad [16:35] that is what it does, yes [16:47] ok, thanks both of you [16:52] my pleasure guillemhs :) [16:58] charlie-tca: how do i get apport to save the log files again? [16:58] was it --save ? [16:58] huh? [16:58] yw, guillemhs [16:59] apport should save the files automatically [16:59] or I don't understand the question, trinikrono [16:59] in which directory are those automatically saved files? [17:00] instead of sending the bugreport to launchpad, i know there is option to save the files [17:00] i just cant remember =\ [17:00] It will automatically save them to /var/crash [17:01] trinikrono: you meaqn [17:01] you mean apport-cli -p --save bug.crash [17:07] yes charlie-tca that is exactly what i mean [17:07] only thing is it saves it to what ever folder you are in the terminal [17:08] i was trying out what is saved with different hooks [17:08] got it. Blame it on fatigue from UDS still interfering with my brain cells [17:10] charlie-tca: i made https://wiki.ubuntu.com/DebuggingPlymouth can you please advise if i left out anything [17:10] first time i did a debugging page [17:10] I am not an expert on such pages, but I will look at it [17:11] you can do anything :D [17:12] The file created by this command in a terminal : cat /boot/grub/menu.lst > menu.lst [17:13] is invalid. under grub2, there is no menu.lst [17:13] (we have had grub2 since karmic, I think) [17:14] 2011-05-24 09:03 [17:14] charlie@wecan: ~ $ cat /boot/grub/menu.lst > menu.lst [17:14] cat: /boot/grub/menu.lst: No such file or directory [17:14] o.o! [17:16] trinikrono: it's /boot/grub/grub.cfg [17:17] We should explain more detail how to use plymouth:debug for reporters. They have to know how to add it to boot options, or we will get back a lot of How do i's [17:18] i am trying to get help on that part of it [17:18] Maybe modify https://wiki.ubuntu.com/Bugs/Responses#Freeze%20during%20boot%20or%20shutdown%20screen [17:18] to fit it [17:18] i tried using plymouth:debug [17:18] and it does not show anything in the desktop [17:20] or copy https://wiki.ubuntu.com/Plymouth#Enabling%20Logging into the standard response [17:20] thanks braiam :D [17:20] It wo [17:20] it won't display on the desktop, it will be: [17:20] Once the system has booted, you can view all the Plymouth debug output in file var/log/plymouth-debug.log. [17:21] so look in /var/log/plymouth-debug.log after you boot with plymouth:debug [17:21] charlie-tca: put that in the debugging section [17:21] no, in the standard response lines [17:22] rather, Stock Reply [17:22] ok [17:22] so when we ask the reporter to do it, we are telling them how to do it and where the log is [17:22] it will need to adjust somewhat [17:23] Yup, it is a wiki, enclose the entire procedure in {{{ }}} [17:23] the stock reply i put was from a actual bug report [17:23] i was looking at a few of them [17:23] I will add it [17:25] hmm === zyga-afk is now known as zyga [17:25] the apport hook does not collect the grub.cfg [17:31] done, looks good now [17:32] If the hook obtained it, you wouldn't need it in debugging, would you? [17:33] the hook doesnt [17:33] That is for the information that gets missed, normally, along with a bit of explanation about how to get the information developers need to work the bug [17:35] Do we have a standard response for debugging Plymouth? [17:35] nope [17:36] thats the thing [17:36] the wikipage still had uplash [17:36] so penguin told me to make the debugging page for it [17:36] now it looks better thanks charlie-tca [17:36] you really are super lol [17:38] Okay, I will get it added to https://wiki.ubuntu.com/Bugs/Responses too [17:39] It's easy to review pages, but much harder to create them [17:42] for me it was easy to make and hard to get reviewed === deryck is now known as deryck[lunch] [18:41] hello can someone look at bug 787055 thanks [18:41] Launchpad bug 787055 in linux (Ubuntu) "Bridge network device showing lots of dropped packets (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/787055 === deryck[lunch] is now known as deryck [19:27] hello, does someone experiencing a disruptive oneiric update ? compiz segfault with error4 inlibunityshell [19:29] njin: Have you asked in #ubuntu+1? [19:30] Pici: thanks i'm going to ask [20:27] How can I set a bug as won't fix for natty and another state for oneiric? [20:29] IIRC I've seen this done on other bugs, I just can't see how I would do it. It seems that 'Nominate for series' doesn't give me an option to set different states for different releases. [20:30] evaluate: only bug control can set won't fix (also, a task has to be added first) [20:30] evaluate: which bug? [20:31] micahg, I got accepted in bug-control but still I can't see a way to set different states for different releases. Bug #782248 [20:31] Launchpad bug 782248 in clipit (Ubuntu) "items do not fall into the menu (affects: 1) (heat: 283)" [Undecided,Incomplete] https://launchpad.net/bugs/782248 [20:32] evaluate: you can nominate a bug for a release which you did, you need either an ubuntu-driver or someone with upload rights to accept the nomination (like me) [20:32] I see. And after the nomination is accepted, I can set the states? [20:33] evaluate: yes [20:33] Cool. [20:34] evaluate: BTW, you don't have to explicitly open a task for a previous release unless you think other people want it/will do it later, I can just reject the natty task if you don't plan on fixing it [20:36] I thought about setting it to 'Won't fix' on natty, to make it obvious that I wouldn't want to release a fix for it in natty since 1. there's a pretty easy workaround for it and 2. I have made modifications in the newer releases that will somewhat fix the situation for oneiric. [20:39] evaluate: k, tasks accepted, please add those comments when you won't fix it [20:40] Sure. Thanks! === yofel_ is now known as yofel