[06:50] <evaluate> Hello.
[06:52] <evaluate> 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?
[13:58] <hggdh> evaluate: should not be long. YOu can also pop in #ubuntu-community-team and ask him directly ;-)
[13:58] <hggdh> evaluate: I mean, his nick is on, I _think_ he is on
[13:59] <evaluate> nah, don't want to bug him, I was just curios how long this usually takes...
[14:01] <hggdh> no problems. jcastro is usually quite responsive to upstream requests
[14:10] <paultag> evaluate: what kind of control?
[14:12] <evaluate> paultag, for example I can't set the importance of bugs or set them to 'Won't fix' or 'Triaged'...
[14:12] <evaluate> hggdh, I have to go in ~20 minutes, I'll ask him when I'm back.
[14:13] <paultag> evaluate: when you say "my package", does this mean an Ubuntu package that you uploaded?
[14:13] <hggdh> evaluate: np, welcome
[14:13] <paultag> or your own project on LP
[14:13] <evaluate> paultag, I'm the developer of the program and I'm also the maintainer of it in Debian.
[14:13] <paultag> evaluate: so when you ask Jorge, you're asking to join bug control
[14:14] <hggdh> yes
[14:14] <evaluate> paultag, that I did already.
[14:14] <paultag> evaluate: usually this has a process, but exceptions are made. He had to do the same for me and my debian packages
[14:14] <paultag> then I ended up actually doing bug work
[14:15] <hggdh> paultag: upstream maintainers have an expedited track
[14:15] <paultag> hggdh: aye
[14:16] <evaluate> BTW, is there something like 'Debian Maintainer' in Ubuntu, in the sense that I can get upload permissions for a specific package?
[14:16] <hggdh> evaluate: there is, but it will be a bit more involved
[14:16] <paultag> evaluate: yes but it's not used much
[14:17] <paultag> it's easier (honestly) to just do MOTU
[14:17] <hggdh> yeah
[14:17] <paultag> evaluate: if you get your DDship, you can get MOTU
[14:18] <evaluate> 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] <paultag> evaluate: that's not the right process, use `requestsync'
[14:18] <paultag> evaluate: upload to debian, then request sync. this is after DIF
[14:18] <evaluate> 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] <paultag> right now it should sync as it goes
[14:19] <paultag> decoder: cool. Well, focus on debian side, ubuntu plays nice
[14:19] <paultag> decoder: syncs are easy, you don't need upload rights for that
[14:20] <evaluate> But syncs are also done manually by someone, right?
[14:20] <paultag> evaluate: not for the first few months
[14:20] <hggdh> only later on
[14:20] <evaluate> But the package needs to be changed in order to work properly in Ubuntu.
[14:20] <evaluate> I mean, it needs an extra dependency...
[14:21] <paultag> evaluate: then fix the debian directory
[14:21] <paultag> evaluate: you should know (being a package manatainer) that you can set extra deps based on dpkg --vendor
[14:21] <paultag> sorry, dpkg-vendor
[14:22] <evaluate> paultag, well, I didn't know that, but I'll look into it.
[14:22] <paultag> 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] <paultag> evaluate: check fluxbox if you need an example
[14:22] <evaluate> Sounds good.
[14:22] <evaluate> paultag, will do. Thanks!
[14:22] <paultag> evaluate: rock on!
[14:26] <evaluate> ok, have to go now. See you later and thanks for the help!
[15:56] <guillemhs> hello,
[15:57] <guillemhs> does it exist an apport-collect tutorial?
[16:03] <charlie-tca> guillemhs: tutorial for using apport-collect or for how it collects the information?
[16:03] <guillemhs> tutorial for using apport-collect
[16:04] <charlie-tca> just type       apport-collect --help        in a terminal
[16:04] <guillemhs> ok
[16:05] <charlie-tca> It is mainly a way to get the logs for a bug report, so the normal usage is     apport-collect BUGNUMBER
[16:05] <guillemhs> BUGNUMBER is the launchpad id?
[16:05] <guillemhs> it means that first i have to enter manually the bug title and the initial comment, no?
[16:06] <charlie-tca> BUGNUMER is the launchpad bug report number, such as 726229
[16:06] <charlie-tca> for bug 726229
[16:06] <ubot4> 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] <JFo> guillemhs, are you asking how to initially file a bug or add data?
[16:06] <JFo> apport collect is for adding data to an existing bug
[16:08] <charlie-tca> If you have to enter a bug title and comment, please use      ubuntu-bug PACKAGE     instead to file the report initially
[16:10] <guillemhs> can i add an apport-collect to a bug that it is not mine?
[16:11] <guillemhs> for example, i am testing an specific package
[16:11] <guillemhs> this paquet crashes
[16:11] <guillemhs> this package crashes
[16:11] <guillemhs> then i run ~# ubuntu-bug PACKAGE
[16:12] <guillemhs> then i rum ~# apport-collect BUGNUMBER_from_the_PACKAGE no?
[16:12] <guillemhs> run, sorry
[16:14] <guillemhs> is this the initial reporting procedure?
 <JFo> hello?
[16:21] <guillemhs> charlie-tca JFo hello?
[16:22] <JFo> guillemhs, it will depend on the package and the maintainer's policies for adding data to a bug that isn't yours
[16:22] <JFo> what package is it?
[16:23] <guillemhs> now i was just asking because i was testing gwyddion
[16:23] <guillemhs> a then i try to use apport-collect to automate the reporting bug process
[16:24] <micahg> 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] <ubot4> 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] <jibel> micahg, I just reproduced it in a VM before adding the comment to be sure.
[16:25] <micahg> jibel: weird
[16:25] <jibel> micahg, indeed, and users are still reporting duplicates.
[16:26] <micahg> jibel: I get this when I try to build eclipse on oneiric: http://pastebin.ubuntu.com/612318/
[16:26] <charlie-tca> 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] <charlie-tca> You will not then add a comment or summary
[16:26] <guillemhs> ok, i see
[16:27] <guillemhs> thanks
[16:27] <JFo> what charlie-tca said :)
[16:27] <charlie-tca> It might decide not to allow you to add, in which case, you have to do it manually
[16:27] <guillemhs> and how can i do it manually?
[16:27] <charlie-tca> using a comment to say you have the issues, then attaching the logs one at a time
[16:32] <guillemhs> ok, but apport-collect selects the correct files and just shows the correct log lines
[16:32] <guillemhs> how can i do this manually?
[16:32] <charlie-tca> guillemhs: right
[16:33] <charlie-tca> you have to select the files yourself, according to what is already attached to the bug or what the triager requested
[16:33] <charlie-tca> They are in /var/log
[16:34] <guillemhs> ah ok
[16:34] <guillemhs> i get it
[16:34] <guillemhs> i was thinking if apport-collect can be executed and collecting the most current information
[16:35] <guillemhs> log information and then in an automated way upload that info into launchpad
[16:35] <JFo> that is what it does, yes
[16:47] <guillemhs> ok, thanks both of you
[16:52] <JFo> my pleasure guillemhs :)
[16:58] <trinikrono> charlie-tca: how do i get apport to save the log files again?
[16:58] <trinikrono> was it --save ?
[16:58] <charlie-tca> huh?
[16:58] <charlie-tca> yw, guillemhs
[16:59] <charlie-tca> apport should save the files automatically
[16:59] <charlie-tca> or I don't understand the question, trinikrono
[16:59] <guillemhs> in which directory are those automatically saved files?
[17:00] <trinikrono> instead of sending the bugreport to launchpad, i know there is option to save the files
[17:00] <trinikrono> i just cant remember =\
[17:00] <charlie-tca> It will automatically save them to /var/crash
[17:01] <charlie-tca> trinikrono: you meaqn
[17:01] <charlie-tca> you mean     apport-cli -p <package name> --save bug.crash
[17:07] <trinikrono> yes charlie-tca that is exactly what i mean
[17:07] <trinikrono> only thing is it saves it to what ever folder you are in the terminal
[17:08] <trinikrono> i was trying out what is saved with different hooks
[17:08] <charlie-tca> got it. Blame it on fatigue from UDS still interfering with my brain cells
[17:10] <trinikrono> charlie-tca: i made https://wiki.ubuntu.com/DebuggingPlymouth can you please advise if i left out anything
[17:10] <trinikrono> first time i did a debugging page
[17:10] <charlie-tca> I am not an expert on such pages, but I will look at it
[17:11] <trinikrono> you can do anything :D
[17:12] <charlie-tca> The file created by this command in a terminal : cat /boot/grub/menu.lst > menu.lst
[17:13] <charlie-tca> is invalid. under grub2, there is no menu.lst
[17:13] <charlie-tca> (we have had grub2 since karmic, I think)
[17:14] <charlie-tca>  2011-05-24  09:03
[17:14] <charlie-tca>  charlie@wecan:  ~  $ cat /boot/grub/menu.lst > menu.lst
[17:14] <charlie-tca> cat: /boot/grub/menu.lst: No such file or directory
[17:14] <trinikrono> o.o!
[17:16] <braiam> trinikrono: it's /boot/grub/grub.cfg
[17:17] <charlie-tca> 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] <trinikrono> i am trying to get help on that part of it
[17:18] <charlie-tca> Maybe modify https://wiki.ubuntu.com/Bugs/Responses#Freeze%20during%20boot%20or%20shutdown%20screen
[17:18] <charlie-tca> to fit it
[17:18] <trinikrono> i tried using plymouth:debug
[17:18] <trinikrono> and it does not show anything in the desktop
[17:20] <charlie-tca> or copy https://wiki.ubuntu.com/Plymouth#Enabling%20Logging into the standard response
[17:20] <trinikrono> thanks braiam :D
[17:20] <charlie-tca> It wo
[17:20] <charlie-tca> it won't display on the desktop, it will be:
[17:20] <charlie-tca> Once the system has booted, you can view all the Plymouth debug output in file var/log/plymouth-debug.log.
[17:21] <charlie-tca> so look in /var/log/plymouth-debug.log after you boot with plymouth:debug
[17:21] <trinikrono> charlie-tca: put that in the debugging section
[17:21] <charlie-tca> no, in the standard response lines
[17:22] <charlie-tca> rather, Stock Reply
[17:22] <trinikrono> ok
[17:22] <charlie-tca> so when we ask the reporter to do it, we are telling them how to do it and where the log is
[17:22] <trinikrono> it will need to adjust somewhat
[17:23] <charlie-tca> Yup, it is a wiki, enclose the entire procedure in {{{ }}}
[17:23] <trinikrono> the stock reply i put was from a actual bug report
[17:23] <trinikrono> i was looking at a few of them
[17:23] <charlie-tca> I will add it
[17:25] <trinikrono> hmm
[17:25] <trinikrono> the apport hook does not collect the grub.cfg
[17:31] <charlie-tca> done, looks good now
[17:32] <charlie-tca> If the hook obtained it, you wouldn't need it in debugging, would you?
[17:33] <trinikrono> the hook doesnt
[17:33] <charlie-tca> 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] <charlie-tca> Do we have a standard response for debugging Plymouth?
[17:35] <trinikrono> nope
[17:36] <trinikrono> thats the thing
[17:36] <trinikrono> the wikipage still had uplash
[17:36] <trinikrono> so penguin told me to make the debugging page for it
[17:36] <trinikrono> now it looks better thanks charlie-tca
[17:36] <trinikrono> you really are super lol
[17:38] <charlie-tca> Okay, I will get it added to https://wiki.ubuntu.com/Bugs/Responses too
[17:39] <charlie-tca> It's easy to review pages, but much harder to create them
[17:42] <trinikrono> for me it was easy to make and hard to get reviewed
[18:41] <njin> hello can someone look at bug 787055 thanks
[18:41] <ubot4> 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
[19:27] <njin> hello, does someone experiencing a disruptive oneiric update ? compiz segfault with error4 inlibunityshell
[19:29] <Pici> njin: Have you asked in #ubuntu+1?
[19:30] <njin> Pici: thanks i'm going to ask
[20:27] <evaluate> How can I set a bug as won't fix for natty and another state for oneiric?
[20:29] <evaluate> 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] <micahg> evaluate: only bug control can set won't fix (also, a task has to be added first)
[20:30] <micahg> evaluate: which bug?
[20:31] <evaluate> 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] <ubot4> 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] <micahg> 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] <evaluate> I see. And after the nomination is accepted, I can set the states?
[20:33] <micahg> evaluate: yes
[20:33] <evaluate> Cool.
[20:34] <micahg> 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] <evaluate> 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] <micahg> evaluate: k, tasks accepted, please add those comments when you won't fix it
[20:40] <evaluate> Sure. Thanks!