[14:04] <decker-christian>  /msg nickserv identify decker-christian $cd121%Irc
[14:04] <roadmr> decker-christian: you'll probably have to change your password :(
[14:05] <decker-christian> :D
[14:05] <decker-christian> I think so too...
[14:06] <penguin42> you can use 122
[14:06] <decker-christian> how can i change it?
[14:06] <penguin42>  /msg nickserv help     should tell you
[14:17] <decker-christian> I think Bug #1448924 can be triaged
[14:19] <penguin42> decker-christian: OK, and what do you think it should be set as for importance - https://wiki.ubuntu.com/Bugs/Bug%20importances
[14:21] <decker-christian> Medium or High
[14:21] <penguin42> now say why
[14:22] <penguin42> decker-christian: Looking at that Importance definition which one does it fit into based on those defs
[14:26] <decker-christian> I think it's necessary that the watchdog works as it used to be in a preview version. I think it is high because it is a problem with an essential hardware component.
[14:27] <decker-christian> previous
[14:30] <penguin42> decker-christian: So I was going to say Medium; because I'd classify a watchdog as a non-essential component - also if I understand his bug report it's got a simple workaround (I think he's just saying you have to reeenable the service?)
[14:31] <decker-christian> Okay.
[14:33] <penguin42> done, and I've added a suggestion;  if the problem is only that it's not starting the service at each startup then a systemctl enable   might fix that
[14:34] <decker-christian> I cannot change the Importance form Undecided to Medium? When I think a bug can be triaged. I came here and give an advice
[14:35] <penguin42> decker-christian: Yep, I've changed it, thanks
[14:35] <decker-christian> Okay. Thanks
[14:45] <decker-christian> Bug #1448913. I think it can be triaged and importance is high because the functionality of the application is broken. (Sending the picture in the wrong direction isn't good).
[14:48] <decker-christian> Bug #1448924 is just a missing feature so Importance is Wishlist
[14:55] <decker-christian> Sorry wrong number Bug #1449233
[14:55] <aikidouke> firewall-applet for vivid behavior when launched from dash is different than running sudo firewall-config from terminal, could this be a bug?
[15:08] <decker-christian> Bug #1449144 : Can be triaged. Importance is low, because it have an easy work-around
[15:13] <decker-christian> Bug #1449025 : Can be triaged. I think importance is low, because it have an easy work-around by remove and reinstall. But I'm not sure if it is a problem from skype
[16:45] <melodie> hi
[16:56] <melodie> has someone tested zram-config in Vivid lately?
[17:13] <ogra_> melodie, didrocks did the systemd switch for it ... perhaps there are still bugs ... whats wrong ß
[17:13] <ogra_> ?
[17:14] <ogra_> https://launchpad.net/ubuntu/+source/zram-config/0.3
[17:14] <melodie> hi ogra_
[17:15] <melodie> I have several issues with it and I am trying to see how to deal with the bug reports to do
[17:15] <melodie> ogra_ would you rather say systemctl should be used for start/stop restart, or better "service" or better swapon/swapoff?
[17:16] <ogra_> well, file them against the package and make didrocks aware of them
[17:16] <melodie> the first two fail to restar
[17:16] <melodie> t
[17:16] <melodie> to restart
[17:16] <ogra_> in the systemd world you want to use systemctl
[17:16] <melodie> the last fails to use the same priority as the main start script
[17:16] <ogra_> swapon/off wouldnt work if zram isnt properly set up first
[17:16] <melodie> ogra_ yes, that's what I thought so I will act consequently for the bug report :D
[17:17] <melodie> ogra_ it works more or less, but with errors
[17:17] <ogra_> right, he should fix that then :)
[17:17] <melodie> is didrocks coming here sometimes?
[17:18] <melodie> is he Adam Conrad, the man whose name is everywhere in the files?
[17:20] <penguin42> melodie: https://launchpad.net/~didrocks
[17:20] <penguin42> melodie: https://launchpad.net/~adconrad
[17:21] <penguin42> melodie: Generally searching for peoples launchpad account gets you their irc nick
[17:21] <melodie> thanks penguin42
[17:21] <melodie> I'll try to carve that in memory
[17:32] <decker-christian> hello, just a short question. If I write in here that a bug can be triaged, is it for sure that someone will look at them or is it better to wait until some response in here.
[17:32] <teward> decker-christian: either or, it also depends on the triager looking at it whether it qualifies.
[17:33] <teward> however i'm hesitant to touch any bug in the partner repos, especially since Skype has to fix the problem (that's not necessarily editable packaging)
[17:36] <decker-christian> Okay. But how to handle bugs like that one? Just ignore isn't the solution, or=
[17:36] <decker-christian> ?
[17:38] <penguin42> yeh it's OK to ignore a bug if you don't know what to do with it; although if you have a dozen that are absolutely certainly the same then I'd probably start duping them if I was really sure they were the same bug
[17:38] <penguin42> there are plenty of bugs in the sea
[17:42] <decker-christian> Okay.
[17:53] <teward> agreed with penguin42
[17:55] <melodie> ogra_ bug 1449665 bug 1449678
[18:39] <melodie> I am struggling with an error after an upgrade in a virtual machine: "invoke-rc.d: unknown initscript, /etc/init.d/modemmanager not found."
[18:40] <melodie> http://pastebin.com/edycCS1U
[18:40] <melodie> would someone have a suggest so I can fix it?
[18:43] <melodie> solved: touch is my friend
[18:52] <decker-christian> Bug #1448913. I think it can be triaged and importance is high because the functionality of the application is broken. (Sending the picture in the wrong direction isn't good).
[18:54] <teward> decker-christian: another restricted bug, and one which I don't think we should be messing with.  I know there are devs who watch the fglrx bugs pretty closely.  (Like partner repo items, I'm hesitant to just mark that "triaged" and change the importance if only because it's something that has more than just a 'bug' implications)
[19:11] <decker-christian> should i mark it then as invalid?
[19:12] <teward> decker-christian: no, leave it alone, is my suggestion
[19:13] <decker-christian> t
[19:14] <teward> decker-christian: I also don't think it's capable of 'triaged' yet - if it were me going at it i'd need more specific data, but i'm also not an fglrx expert
[19:14] <teward> (I leave that to the canonical people0
[19:17] <decker-christian> teward: I didn't get it. Why are there so much bugs which should be ignored? How can I (as amateur) know which ones are relvant and which ones are not. I see a bug an think someone should care about it.
[19:21] <teward> decker-christian: As I said before, some triagers are more comfortable changing things vs. others.
[19:21] <teward> Me, I prefer to leave the restricted stuff (drivers) and partner stuff (closed source) to people more familiar with triage for that
[19:23] <teward> decker-christian: especially since driver bugs may just be hardware related compared to actual bugs exploding (and fglrx issues are driver bugs, and in theory it could cause other issues if not handled right)
[19:23] <teward> the fact i'm around and commenting means nothing, others may choose to triage per your requests after me, however I tend to think that unless driver bugs are confirmed by you, you may want to tread lightly around them
[19:23] <teward> decker-christian: that's just my take on it.
[19:23] <teward> decker-christian: however, I would suggest, starting out, that you start by focusing on packages you have an interest in
[19:25] <teward> looking at the fglrx one, i'll maybe set it to "Medium" but I don't think it's triageable - i say Medium because neither Chrome or Spotify are actually in Ubuntu
[19:25] <teward> Especially since "all other apps are fine" per the description and original poster
[19:26] <decker-christian> okay. thanks for your advice. I just started yesterday so I'm still learning ;)
[19:27] <teward> decker-christian: i started in 2012 with bug triage as a part of bugsquad, with a special interest in bugs in certain packages, but also in bugs which impacted me regularly (rare but it does happen).
[19:27] <teward> kinda started taking over nginx bug triage (server package) due to my interest there, but that's a moot point at this point
[19:28] <teward> my point is even I still learn, too, it's a continual process
[19:28] <teward> my best advice is start with packages that interest you rather than a random selection/subset of bugs
[19:28] <teward> maybe even work with bugs that aren't special-hardware based, or such.  Skype is an ehhhhh tossup in my opinion, because that's closed source...
[19:28] <teward> but the point still stands :0
[19:28] <teward> :)  *
[19:29] <decker-christian> I think that is a good advice :).
[19:29] <teward> (it is ultimately up to the bugcontrol persons you reach whether to 'triaged' or not, either they may not be fluent enough in the package to make that judgement, or they may have reservations in messing with restricted or closed source stuff such as in partner, etc.
[19:30] <teward> decker-christian: you may also be interested in the Hundred Papercuts project - https://wiki.ubuntu.com/One%20Hundred%20Papercuts
[19:30] <teward> https://launchpad.net/hundredpapercuts is the LP group.  But it's still a nice 'getting started' point.
[19:31] <teward> but my best advice is to start with packages you like or have an interest in, rather than random-picking of bugs.  Granted, I sometimes go after bugs that are likely feature request bugs, those're the easiest to triage xD
[19:34] <decker-christian> Okay. I think I will find my way to get involved :)