[08:39] <astraljava> Hey guys. eylul sorry I've been away quite a lot lately. I'll try to keep up with the times better now. :)
[12:04] <eylul> astraljava: no need to apologize. this is volunteer work. we all do have to put other things into priority from time to time.  nice to see you back through
[19:15] <OvenWerks> hmm, no one here?
[19:19] <krytarik> OvenWerks: In 10 mins.
[19:26] <eylul> yup
[19:26] <eylul> in 4 minutes. *goes to dig up the meetingology notes*
[19:27] <eylul> I'll drop a reminder to the ML
[19:28] <krytarik> eylul: Please don't.
[19:28] <eylul> why?
[19:28] <krytarik> Because 2 mins before start again?
[19:28] <eylul> yeah just to say we are starting now
[19:28] <eylul> *shrugs*
[19:28] <eylul> some people lose track of time
[19:31] <eylul> #startmeeting "UbuntuStudio weekly check-in"
[19:31] <meetingology> Meeting started Tue Jan 17 19:31:20 2017 UTC.  The chair is eylul. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[19:31] <meetingology> Available commands: action commands idea info link nick
[19:31] <OvenWerks> unfortunately I am on my way out da door...
[19:31] <eylul> ovenwerks is this time not working for you anymore?
[19:32] <eylul> #chair krytarik
[19:32] <meetingology> Current chairs: eylul krytarik
[19:33] <eylul> I guess this one will be pretty quick if it is just two of us
[19:33] <krytarik> Yeah.
[19:33] <eylul> alright so..
[19:35] <eylul> so far I have website, controls update,  new tester, 16.04.2.. I feel like I am missing something
[19:35] <krytarik> New docs contributor - albeit not there yet.
[19:35] <eylul> cool
[19:36] <eylul> alright..  lets start with contributors. then move to other things.
[19:36] <eylul> #topic new contributors
[19:37] <eylul> so we have a tester, and they are active so far, I had a talk with them about using KVM setup. we should in general reroute people to using gnome-boxes or virtualbox if they want to do VM testing
[19:38] <eylul> or at least gnome-boxes worked fine until a few months ago might have more to say on that after seeing how things go with _SleePer_'s setup
[19:39] <eylul> did the docs person show up since the initial IRC chat yet?
[19:39] <krytarik> Yeah, but only to drop off shortly after again.
[19:40] <krytarik> I.e. no interaction happened since.
[19:40] <eylul> oh ok. it might be perhaps good policy to redirect people to introduce themselves in ML?
[19:41] <krytarik> That's overrated and over the top imo.
[19:41] <eylul> why?
[19:42] <krytarik> I mean sure, can suggest that - but I personally didn't either, and it might be stumbling block for some other too.
[19:42] <eylul> oh I am not saying it as a requirement, neither did I
[19:42] <eylul> just as a, it will be easier for us to get back to you if you can't catch us online way
[19:45] <eylul> anyway
[19:46] <eylul> welcome newcomers. :)
[19:46] <eylul> alright next topic I suppose ;D
[19:46] <eylul> #topic website
[19:47] <eylul> krytarik: you mentioned you are considering contacting the community council about the saga of lost ticket?
[19:48] <krytarik> Yeah, like suggested in a previous meeting.  And since Set doesn't seem to get back anytime soon..
[19:49] <eylul> I'll try to talk to sakrecoer again sometime in next period but yes, I think we should pretend at this point that he won't be here at least in next 2 weeks period
[19:51] <eylul> you probably know where I am going with this.. do you think you could contact the community council?
[19:53] <krytarik> Since over mail seems to be their prefered of contact, I guess it'd be nice if we could work out a proper mail together.
[19:55] <eylul> alright
[19:56] <eylul> ok so you just want to draft that now in the meeting?
[19:56] <krytarik> Nah, sometime after.
[19:56] <eylul> ok
[19:58] <eylul> i do have actually an outline
[19:59] <eylul> so we can do it after the meeting, or at another time that works better for you :)
[19:59] <krytarik> Well, if you wish, since it's just the two of us anyway... :P
[20:00] <eylul> well I find it easier to get things done right after meeting otherwise it becomes this thing to procrastinate :P
[20:00] <krytarik> So yeah, right after the meeting then.
[20:00] <eylul> :)
[20:00] <krytarik> And you send the mail! :P
[20:01] <eylul> lol alright
[20:01] <eylul> :)
[20:01]  * eylul is trying to figure out how to do an action point
[20:03] <eylul> #action eylul and krytarik will draft the email about the ticket to community council. eylul will send the email
[20:03] <meetingology> ACTION: eylul and krytarik will draft the email about the ticket to community council. eylul will send the email
[20:03] <eylul> alright
[20:03] <eylul> so
[20:03] <krytarik> \o/
[20:03] <eylul> :) we actually have an action
[20:04] <eylul> #topic controls
[20:04] <eylul> much on this, beyond what is already on ML just a shoutout to Ovenwerks for his work on the controls
[20:05] <eylul> I know there are differences of opinion on how to achieve best usability of the tool but from what I see there is overall positivity about seeing progress on the project
[20:07] <eylul> on my side, I think I finally got the wacom setup utility part of the design down to something that can actually be achieved by a single person, so starting to put together a UI mockup for that
[20:07] <eylul> more on that on next check-in
[20:11] <eylul> alright anything else on this other than \o/ before we move on to the next topic? (btw I remembered what I forgot) :)
[20:13] <krytarik> Nope - nice work on this, you two!
[20:13] <eylul> :)
[20:13] <eylul> I am really excited about this.
[20:15] <eylul> alright so
[20:16] <eylul> #topic 16.04.2
[20:16] <eylul> krytarik you mentioned the release was delayed. do you know to when?
[20:17] <krytarik> Nope, that wasn't announced yet.
[20:17] <eylul> ok
[20:17] <eylul> can you email the ML or drop it to IRC when/if you see it?.
[20:17] <eylul> you seem to be better than most of us at keeping track of deadlines on ubuntu end :)
[20:17] <krytarik> Sure.
[20:18] <krytarik> (The latter then, that is.)
[20:18] <eylul> (I assumed so ;D)
[20:18] <krytarik> :D
[20:18] <eylul> just tag my name so that I can see it :)
[20:18] <krytarik> Sure!
[20:19] <eylul> Ross is probably watching the deadline on his end, but I figure if our tester is around, we can redirect them to use some of their testing time on that.
[20:19] <krytarik> Definitely.
[20:19] <eylul> :) a VR test is better than nothing
[20:19] <krytarik> Virtual Reality?..
[20:20] <eylul> VM
[20:20] <krytarik> lol
[20:20] <eylul> *giggles*
[20:20] <eylul> yeah that right there is pretty much indication of how fried my brain is at the moment
[20:20]  * eylul pointedly not thinking about deadlines
[20:20] <eylul> ok so.. anything else that needs to be done on that front?
[20:21] <krytarik> Well, mail to the list when details are there, of course - but other than that, not yet.
[20:23] <eylul> ok
[20:23] <eylul> alright
[20:24] <eylul> so bonus topic the one I forgot, which is not so much more than a squee really
[20:24] <eylul> #topic krita
[20:24] <krytarik> !info krita
[20:24] <krytarik> !info krita zesty
[20:24] <eylul> yup
[20:24] <krytarik> That.
[20:24] <eylul> essentially
[20:25] <eylul> for context <IP_ADDRESS> is the most up to date version at the moment
[20:25] <eylul> I'll keep an eye to see if krita has a new release between now and then, but even if there is one, and we can't pull it in, this is a good place to be.
[20:25] <eylul> also the package is updating regularly which is great to see
[20:26] <eylul> this does however means, it needs to be tested, before zesty release :)
[20:27] <eylul> but anyway. \o/ on that.
[20:27] <eylul> Alright
[20:28] <eylul> anything else on this topic before we close, and anything else we need to discuss before finalizing this meeting?
[20:29] <krytarik> Doesn't seem so.
[20:30] <eylul> alright in that case
[20:30] <eylul> #topic closing
[20:31] <eylul> I am a bit worried about my ability to make it to a meeting to tuesday 31st
[20:31] <eylul> *goes to check something at callendar*
[20:34] <eylul> actually before the closing
[20:35] <eylul> #undo
[20:35] <meetingology> Removing item from minutes: TOPIC
[20:35] <eylul> #topic uploader or lack ther eof
[20:35] <eylul> #undo
[20:35] <meetingology> Removing item from minutes: TOPIC
[20:35] <eylul> #topic uploader or lack thereof
[20:35] <eylul> thanks
[20:35] <eylul> mt
[20:38] <krytarik> So a gentle reminder that following the sudden departure of Kaj at the end of last cycle, and no alternatives coming forward yet, we still need a new uploader for our packageset.
[20:39] <krytarik> Otherwise, we can only get things uploaded through sponsoring.
[20:40] <eylul> *nods*
[20:40] <eylul> thanks krytarik
[20:40] <krytarik> Sure.
[20:40] <eylul> alright so
[20:40] <eylul> #topic closing
[20:41] <eylul> #action next meeting January 31st 19:30UTC (2 weeks from now, same time)
[20:41] <meetingology> ACTION: next meeting January 31st 19:30UTC (2 weeks from now, same time)
[20:41] <eylul> #help: eylul needs somebody to run the meeting mid february as she might not be able to make it, or fully make it.
[20:42] <krytarik> I guess that'd be me then, in case. >_>
[20:43] <eylul> :) I'll try to drop by at least for part of it, I just am not sure at the moment so planning contigencies. :)
[20:43] <eylul> thanks. alright
[20:44] <eylul> #endmeeting
[20:44] <meetingology> Meeting ended Tue Jan 17 20:44:02 2017 UTC.
[20:44] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntustudio-devel/2017/ubuntustudio-devel.2017-01-17-19.31.moin.txt
[20:44] <krytarik> eylul: As usual, thanks for running the meeting! :)
[20:44] <eylul> thank you for being here :)
[20:44] <krytarik> \o/
[20:45] <eylul> alright let me quickly email the meeting minutes to ML then shall we draft this email?
[20:45] <eylul> (and if yes, where shall we draft it?)
[20:45] <eylul> (it shouldn't take too long)
[20:46] <krytarik> Uhh, I guess throwing forth and back a one-liner or something should be fine - here or in PM.
[20:47] <eylul> *cringes* oh-kay
[20:47] <krytarik> Well, we can create a pad for that too, of course.
[20:47] <eylul> pad might be better tbh
[20:48] <eylul> I don't want to have a giant log of us fixing grammar errors on us-devel :D
[20:49] <krytarik> Sure!
[20:49] <eylul> can you start one? :)
[20:49] <krytarik> I'll try!
[20:52]  * eylul waits
[20:54] <krytarik> → http://pad.ubuntu.com/geoTruY5t4
[20:57] <eylul> alright I am there
[21:22] <OvenWerks> sorry about that. no is not the right answer to "lets go for lunch"
[21:58] <eylul> lol Ovenwerks. can you come over to the etherpad to help us out?
[21:58] <eylul> Krytarik and I are stuck over a grammar thing
[22:24] <eylul> ok nvm we sorted it out
[23:21] <krytarik> eylul: Ping!  There we go: https://lists.ubuntu.com/archives/ubuntu-release/2017-January/003998.html
[23:22] <eylul> lol
[23:22] <eylul> nice and thanks


[02:18] <studio-user828> In ubuntustudio, do they have an option to record the screen?
[08:56] <studio-user484> heya, how do you get the splash screen settings for log out, the image is not centered and all to the right side, and i would like to center it, how does one do that ?


[02:50] <lotuspsychje> good morning
[03:46] <lotuspsychje> Bashing-om EoflaOE UWN material: https://www.omgubuntu.co.uk/2019/09/nvidia-optimus-linux-switching-applet
[03:51] <Bashing-om> lotuspsychje: Will look :)
[04:21] <lotuspsychje> guiverc: whats sappeiros issue?
[04:21] <guiverc> lotuspsychje, no idea; i'm just joining in; black screen
[04:52] <Bashing-om> lotuspsychje: AMD vega10 graphics ,, think the solution is 19.10 :)
[04:52] <lotuspsychje> we have a few ryzen bugs with kernels too
[04:53] <lotuspsychje> 4.19 to the rescue
[10:10] <marcoagpinto> Hello
[10:10] <lordievader> 👋
[10:11] <marcoagpinto> I have been working on the British speller :)
[10:11] <marcoagpinto> I am depressed but I am doing community work
[12:20] <BluesKaj> howdy all
[12:20] <marcoagpinto> BluesKaj! My dear beloved brother!  You can also use "rmadison mumble" to find all available versions
[15:13] <hggdh> but it is interesting that ubot* did not respond
[16:08] <marcoagpinto> hey EoflaOE and lotuspsychje!
[16:16] <EoflaOE> Hello marcoagpinto
[16:16] <marcoagpinto> :)
[16:17] <EoflaOE> How are you doing and how is your project marcoagpinto?
[16:17] <marcoagpinto> right now I am feeling less depressed, thanks for asking. :)
[16:17] <marcoagpinto> what's up?
[16:18] <EoflaOE> I am doing fine, but something is blocking me from releasing a new version of KS with the chat function in the remote debugger
[16:18] <marcoagpinto> ohhhhh :((((
[16:19] <EoflaOE> However I have made a question about it in StackOverflow, and hopefully devs will answer.
[16:21] <marcoagpinto> today I have coded a new feature into Proofing Tool GUI, but I won't release an update since it isn't worth going through all the process of updating the webpage, compile for Windows+Linux, create SHA-512, signing, etc
[16:21] <marcoagpinto> :)
[16:21] <EoflaOE> Nice. And what would it do?
[16:21] <marcoagpinto> let me upload a screenshot
[16:23] <marcoagpinto> EoflaOE: https://i.imgur.com/M3ZIoSJ.png
[16:23] <marcoagpinto> basically it has two new columns: "% match" and "status"
[16:23] <marcoagpinto> not a great improvement to spend hours on a release
[16:25] <EoflaOE> Yes, I saw that.
[16:43] <marcoagpinto> ahhhh... in a future version I want to allow to export dictionaries as .oxt/.xpi
[16:43] <marcoagpinto> :)
[16:43] <marcoagpinto> I have already drawn on paper the GUI
[16:50] <lotuspsychje> hggdh: saw this article earlier https://www.omgubuntu.co.uk/2019/09/mumble-chat-app-new-version
[16:52] <lotuspsychje> i recall we had a factoid, but its !teamspeak
[16:56] <marcoagpinto> >:)
[16:57] <marcoagpinto> I have two or three block notes full of ideas!!!!
[16:57] <marcoagpinto> :)
[16:57] <marcoagpinto> I just don't have time to do it all
[17:06] <hggdh> lotuspsychje: yes, mumble 1.3.0 is already available on Disco and Eoan
[17:06] <lotuspsychje> neat
[18:05] <OerHeks> ukuu <ubottu> Sorry, I don't know anything about ukuu .. can we make a factoid for this?
[18:07] <tomreyn> might be good to have
[18:07] <tomreyn> maybe we need !doesnotwork also
[18:07] <lotuspsychje> gui, easy, external ppa and mess with kernels, ideal combo!
[18:14] <OerHeks> feed us random blogs, UKUUUUUUUUUUUU
[18:15] <lotuspsychje> lol
[18:15] <OerHeks> order ORDER!!!
[18:19] <tomreyn> isnt that what they were yelling on titanic while it sunk?
[18:19] <lotuspsychje> UKUUUU
[18:21] <tomreyn> :) i guess ukuu is okay, i'd prefer less complex utilities to handle mainline kernels, though. and thnk that ukuu users whould seek support from the developer if they need any.
[18:21] <tomreyn> (after all he seems to try to make some coin this way)
[18:22] <lotuspsychje> would have been nice to have in the official repos
[18:24] <daftykins> serves a job that doesn't exist xD
[18:27] <tomreyn> there is a use case where you want to stay on (keep upgrading to, upon availability) the latest mainline kernel, namely when you run so recent hardware that it's not supported in HWE(-edge) nor the latest ubuntu release. that's rare, but can happen.
[18:29] <lotuspsychje> like the lot of ryzen users we getting :p
[18:29] <lotuspsychje> https://www.forbes.com/sites/jasonevangelho/2019/07/09/the-current-state-of-amd-ryzen-3000-cpus-and-radeon-rx-5700-gpus-on-linux/#3f8fa952939a
[18:29] <tomreyn> i was thinking we had decided to ignore jasonevangelho and forbes as sources of tech news
[18:30] <lotuspsychje> also found https://ubuntuforums.org/showthread.php?t=2425799
[18:30] <daftykins> shock: new hardware doesn't work well
[18:31] <lotuspsychje> :p
[19:45] <Bashing-om> UWN595 is on the streets: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue595 :D


[08:02] <brijithmac> When I tried to set up turbo gears in Ubuntu 9.10 it failed. please check the link http://ubuntuforums.org/showthread.php?t=1315117you can see a link to the documentation that I used..


[14:21] <je1> Hi, just moved to xubuntu 15.10 from manjaro, everything working fine apart from processor fan revving for short intervals, google not really helping, any help appreciated, thanks.
[16:53] <MichaelTunnell> are the application categories in MenuLibre, when choosing a category to add, using the freedesktop.org category standards?
[17:42] <xubuntu57w> I am running xubuntu 15.10 on a dell inspiron 1545 laptop and I have no audio. Can anyone help me?
[17:46] <Artemis3> xubuntu57w, can you open a console and use alsamixer?
[17:46] <Artemis3> terminal
[17:50] <xubuntu57w> I looked for that but couldn't find it
[17:53] <xubuntu57w> How do I do that in terminal?
[17:54] <DrCool> open a terminal and type  alsamixer
[17:55] <xubuntu57w> okay it opened in terminal, what next?
[17:56] <xubuntu57w> I see in ubuntu software center I can install GNOME ALSA Mixer. Should I install that?
[17:56] <DrCool> so when you typed alsamixer nothing cam eup?
[17:56] <DrCool> came up
[17:57] <xubuntu57w> Yes - S/PDIF >S/PDIF 1 S/PDIF 2
[17:57] <xubuntu57w> and some info
[17:58] <xubuntu57w> I am using old analog speakers, but it says HDMI.
[17:59] <DrCool> look for either Master or PCM to be all the way down or does either say MM?
[17:59] <DrCool> usually something is turned down or on MM (mute)
[18:00] <DrCool> I think if any say  MM you might unmute them by pressing "M" just to see if that helps.
[18:00] <DrCool> and turn them up all the way by using the arrow keys.
[18:00] <xubuntu57w> All 3 say "00"
[18:01] <DrCool> and all are 100% to start?
[18:02] <DrCool> and also make sure to scroll to the right, there are some that will be off screen, probably.
[18:04] <xubuntu57w> If I type M, then the switch from 00 to MM, typing M again sets them back to 00
[18:04] <xubuntu57w> I tried scrolling to the right, but it only changes the 3 settings
[18:05] <flocculant> 00 is zero volume - what happens if you use the up arrow key?
[18:06] <xubuntu57w> nothing changes when i hit the up or down arrows
[18:06] <DrCool> 00 is "on" , MM is muted.
[18:07] <DrCool> so switch to 00 then use the up arrow key.
[18:07] <DrCool> the bar should go from green, to white to red at the top.
[18:13] <xubuntu57w> That doesn't work. I installed GNOME ALSA Mixer and several headphone settings were set to mute and turned way down, but I unmuted them and slid the slider all the way up and that didn't work either.
[18:17] <DrCool> have you tried more than one headphone jack?
[18:20] <xubuntu57w> I only have one. By selecting f6 and trying the different sound cards (?) I found the one with the sliders. All were turned way up
[18:21] <DrCool> maybe this...I don't know much more.  https://help.ubuntu.com/community/SoundTroubleshooting
[18:22] <xubuntu57w> thanks for trying tho
[20:03] <xubuntu32w> hello
[20:04] <xubuntu32w> I have a question.  I'm pretty new to linux, I'm wanting to make sure xubuntu will work on my older desktop
[20:05] <xubuntu32w> I am running it now on live usb
[20:05] <xubuntu32w> and I can't get it to connect to internet
[20:06] <xubuntu32w> it seems the only network adapter it can find is my ether net card, but I'd like to use wifi
[20:06] <xubuntu32w> I have a net gear wnda3100v2 wifi adapter
[20:07] <xubuntu32w> so I can use the terminal,  but I don't know all the commands
[20:07] <xubuntu32w> thanks for any help
[20:08] <Unit193> You've got a Broadcom BCM4323, then.
[20:08] <Unit193> !bcm
[20:08] <xubuntu32w> Ok I'll look thx
[20:09] <Unit193> Not too hard, but does require you to do a little setup.


[01:01] <hggdh> Ampelbein, you are doing a good work, old bugs are as worthy as new ones. And yes, many reporters will complain it took us quite a long time to get there
[01:01] <hggdh> such is life
[01:01] <hggdh> mrooney, makes sense, I think. Go ahead and change it
[01:02] <mrooney> I think we need a wiki page for complainers :)
[01:04] <mrooney> explaining paradigms for non-free OSes simply don't apply to a free OS like Ubuntu, where it is very rare someone is getting paid to work on a piece of software. and since it is open source, the best thing they can do for an issue they care about is learn how to fix it and do so
[01:04] <hggdh> one single wiki page will not be enough ;-)
[01:05] <mrooney> haha, I know
[01:06] <mrooney> something like WhyIsntMyBugFixed could be useful
[01:07] <mrooney> Ampelbein: just read your stuff, yes I think what you are doing is great, as long as you can "take the heat" of some users, it will improve everything in the end. it is better IMO to get a reply asking why it has taken so long, than leave someone waiting indefinitely
[01:07] <james_w> just subscribe them to the ubuntu-bugs mailing list for a day
[01:07] <mrooney> james_w: brilliant :)
[01:36] <mrooney> okay I have thinking about this stock response change a little more
[01:37] <mrooney> "Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it in its current state..." doesn't make grammatical sense, as the `it` is sort of ambiguous and assuming it refers to the bug, that doesn't make semantic sense, the state of the bug isn't what needs to be changed
[01:38] <mrooney> what about just changing "Unfortunately we can't fix it, because your description didn't include enough information." to "Unfortunately we can't fix it without more information."?
[01:43] <hggdh> mrooney, this is indeed better
[01:44] <mrooney> okay, that is used in 8 of the responses, I will just adjust all of them? obviously it is easy to change later :)
[06:09] <tuxmaniac> good morrning folks
[06:44] <dholbach> good morning
[06:58] <techno_freak> dholbach, morning
[06:58] <dholbach> hi techno_freak
[07:02] <mattik> Hello, how is it possible, that I have reported many bugs what is marked duplicated newer one? Is there some people who try to collect more karma and ubuntuteros who help they?
[07:02] <dholbach> mattik: the age of a bug is not relevant when deciding which bug is a duplicate of which other bug
[07:02] <mattik> why
[07:02] <dholbach> mattik: which contains more information is much more important
[07:03] <mattik> ok
[07:03] <dholbach> so if bug A is forward upstream already, has clear instructions how to reproduce, etc, bug B is likely to be made a duplicate of A
[07:04] <mattik> but who decide it
[07:05] <dholbach> whoever triages the bug and finds out about a duplicate
[07:08] <mattik> ok, I agree
[07:10] <elmargol> the guys from the linux action show are flaming about the ubuntu bugtracker :(
[07:12] <dholbach> elmargol: do you have a link to that?
[08:03] <mouz> dholbach: it might be (i could not find the flaming itself) somewhere here: http://www.jupiterbroadcasting.com/?cat=4
[08:04] <dholbach> mh
[10:10] <mcas> good morning
[10:21] <nullack> Hi everyone :) I just joined the team, Ive been testing professionally for 12 years and have related experience in release management, problem management, ITIL, etcetc
[10:22] <nullack> Anyway where is the bug management policies? The wiki is pretty brief on reporting bugs and Im getting inconsistencies from some devs on bugs Im involved on
[10:34] <dholbach> hi nullack - did you check out  https://help.ubuntu.com/community/ReportingBugs ?
[10:34] <nullack> Yes I did, I need deeper info :) Anyway Im now looking at the IRC chat logs from the KB it has some info
[10:34] <seb128> hey nullack, thanks for the good bug work ;-)
[10:35] <seb128> nullack: about upstream bugs, things like "software is using too much ressources" are not usually distro changes, especially for gedit which has no distro change
[10:35] <nullack> I dont have credentials to move the importance for bug 257818 - according to the bug policy as stated in the IRC chat log "High importance: This is a bug that has a severe impact on a small portion of Ubuntu users. It makes a default Ubuntu installation generally unusable." and it should be this priority. Can someone please change it, the dev is wrong
[10:36] <seb128> nullack: looks like that's something which never worked right?
[10:36] <seb128> nullack: you are the first one to complain about that, it might be annoying for some usecase but that's not something most users run into
[10:36] <nullack> Sebastien how can we gaurentee that it isnt due to customisation in debian or Ubuntu? And it only recently came into existence when no gedit chages were made very recently
[10:36] <seb128> nullack: and that's not something the ubuntu team has ressources to work on, so fighting over bug settings will not make a difference
[10:37] <nullack> Sebastien, please Im not fighting :) Im simply looking to apply the Ubuntu policy
[10:37] <seb128> nullack: a new gedit has been uploaded some days ago which uses gio
[10:37] <nullack> I understand your reasons but thats not the policy
[10:37] <seb128> you are using intrepid?
[10:37] <nullack> Yes I am mate
[10:37] <seb128> no gedit changed a lot
[10:37] <seb128> they ported the code to gio
[10:38] <seb128> and I uploaded that new version some days ago
[10:38] <seb128> s/no/so
[10:38] <nullack> Yeah I know, but I didnt have the issue until very recently
[10:38] <seb128> maybe a gio thing
[10:38] <nullack> I was synched to your change no problems then
[10:38] <seb128> like you mounted a share which is low latency
[10:38] <seb128> and it doesn't handle that correctly
[10:39] <seb128> that would require somebody having the issue to use sysprof or similar to know what is going on
[10:39] <nullack> I will look into that, can we please quickly discuss the deinterlace issue?
[10:40] <seb128> nullack: gedit didn't change after the new version update (and a svn change backport), and there is no distro patch there, so I doubt the issue is specific to ubuntu, but right not easy to determine for users
[10:40] <seb128> nullack: right, first what you call policy are guidelines
[10:40] <nullack> Yeah Ive reported it upstream anyway :)
[10:40] <seb128> the maintainers decide on what are the appropriate settings
[10:40] <seb128> is that something which ever working using totem-gstreamer?
[10:40] <nullack> No its not
[10:41] <seb128> ok, so it's something which is not a regression
[10:41] <nullack> Yes my friend, no regression
[10:41] <seb128> and you are the first one to complain in several years of ubuntu
[10:41] <seb128> now I can understand it's frustrating in your usecase
[10:41] <nullack> Most people just install mplayer or VLC
[10:41] <seb128> but that's not a high priority for our userbase
[10:41] <nullack> Hmm, I understand, but I think I need to make a point
[10:42] <nullack> It does effect the userbase, quite a bit, but people go and work around it by installing vlc or mplayer
[10:42] <nullack> People rubbish gstreamer / vlc for the deinterlacing reason, and also other stuff like the stream bug I reported
[10:43] <nullack> I want to support the default Ubuntu build with my tests and this is why Im one of the few who have reported these bugs instead of installing vlc or mplayer
[10:44] <nullack> The user impact of not being able to deinterlace wrecks use cases like watching digital TV thats interlaced and using footage shot on interlaced cameras
[10:44] <seb128> nullack: I don't agree about that, we get lot of people reporting totem bugs
[10:45] <seb128> I just think 98% of users play avi, wmv, or mpeg files
[10:45] <nullack> Ok, well I will defer to your judgement since youve seen my point of view :) If your really, really sure
[10:45] <seb128> ok, let's be clear
[10:45] <seb128> - it sucks
[10:45] <seb128> - it's not trivial to fix
[10:45] <seb128> - the ubuntu team doesn't write the software and doesn't have the ressources to work on this right now
[10:46] <seb128> so the settings are not making any difference
[10:46] <seb128> I think it's doesn't make the installation un-usable
[10:47] <seb128> "# A cosmetic/usability issue that does not limit the functionality of an application "
[10:47] <seb128> that would be low
[10:47] <seb128> "# A bug that has a moderate impact on a core application. "
[10:47] <seb128> that would be medium
[10:47] <seb128> it's somewhere between those
[10:47] <seb128> but as said picking on or the other is not going to make a difference
[10:48] <nullack> Higher priorities might make a difference to an ethusiast whos looking at what the key issue are, but as you say its not trivial to fix
[10:49] <nullack> I think not being able to watch interlaced DVB is serious, same with camera footage, but your view is that those use cases are not common
[10:49] <elmargol> dholbach, on the latest podcast... reporting bugs is a waste of time for you and for the developers
[10:50] <seb128> nullack: I don't know what DVB is and I think 95% of users just want youtube videos or divx movies yes
[10:50] <nullack> Its Digital Video Broadcasts :) mostly Free to air TV thats sometimes broadcast in interlaced format
[10:51] <dholbach> elmargol: maybe mail the link of the podcast to ubuntu-buqsquad@ along with the minute when that occurs - maybe somebody better than me can approach the producers of the podcast and have a chat with them about it
[10:51] <seb128> nullack: and I don't think anybody looking at fixing hard issues will look at the ubuntu bug trackers, people working on gstreamer will do that upstream
[10:51] <nullack> Ive added test files and info upstream
[10:51] <seb128> cool
[10:51] <seb128> anyway the importance is suggestive there
[10:52] <nullack> I now understand your reasons and accept the policy are guidelines, thanks for your time Sebastien
[10:52] <seb128> and if users want to get their issues considered they should let us know about it those rather than switching softwares
[10:52] <nullack> I agree, thats what I was trying to do
[10:52] <nullack> And besides, MOTU dont keep ffmpeg and mplayer up to date
[10:52] <seb128> right, and I consider your bug, but you are the only one who raised that as a real issue so far
[10:53] <seb128> another topic ;-)
[10:53] <seb128> part of that is due to debian, ffmpeg is the debian version
[10:53] <seb128> and there is also a manpower issue there, MOTU is way understaffed for the work to do
[10:53] <nullack> Yeah their swamped
[10:54] <seb128> btw about the file-roller chmod issue, I agree low was maybe not appropriate, though basic users don't know how to use sudo and user who do should know better than running graphical tools using it
[10:54] <elmargol> dholbach, I'll that
[10:54] <seb128> but thanks for sending it upstream and getting it fixed
[10:55] <seb128> new GNOME tarballs are due today so it'll be fixed in intrepid
[10:55] <nullack> No worries Sebastien, Im pleased you agree with my reasons why that particular bug was pretty nasty :)
[10:55] <nullack> Great, were looking forward to testing it Ive got a few peeps on the forums lined up ready for it
[10:59] <elmargol> dholbach, sadly I have to agree an some parts :( I have some verry old bugreports and since they are not easy to fix they get ignored
[11:04] <elmargol> #55496 2006-08-07
[11:04] <elmargol> Bug #103210 2007-04-05
[11:07] <mcas> can someone please look at bug 258588
[11:07] <mcas> i think this should be medium or high importance but i cannot change it
[11:08] <gnomefreak> mcas: i see a few issues with -5
[11:08] <mcas> ok
[11:08] <gnomefreak> file system is read only so cant get X working due to that
[11:09] <mcas> i forgot to search for duplicate bugs. sorry
[11:09] <gnomefreak> but it upgrades fine. browser is slow
[11:09] <gnomefreak> mcas: i havent filed a bug yet
[11:09] <mcas> ah ok
[11:10] <mcas> and my suggestions about the importance... do you think its ok?
[11:10] <gnomefreak> im assuming its stopping you from upgrading the kernel is due to its issues but i havent looked at logs yet
[11:11] <mcas> ok
[11:28] <nullack> Anyone: When I have a bug that I already linked upstream, and upstream decide that its a duplicate of an existing other bug, LP says bugwatch for the upstream bug is invalid. How do I point the LP bug to the new upstream path? Trying it the usual way doesnt work, thanks
[11:38] <nullack> Ah! Ive got it. Its the little yellow icon that allows to change the bug watch details next to the bug watch panel in LP in case anyone else has run into this :)
[11:40] <anakron> Hi all
[12:57] <mrooney> can anyone recommend a course of action for bug 250497?
[12:57] <nullack> WinTesting1
[12:58] <mrooney> the reporter says it hasn't happened recently and guessed it was fixed in a recent update, however the package hasn't been updated since months before his report
[12:58] <mrooney> do I just mark as Invalid and ask him to re-open if he experiences the issue again?
[12:58] <Hobbsee> i would - it could well be pebkac
[12:59] <Hew> mrooney: I'd mark it invalid and use the standard response from https://wiki.ubuntu.com/Bugs/Responses
[13:03] <mrooney> Hobbsee: pebkac?
[13:04] <Hobbsee> !google pebkac
[13:04] <Hobbsee> aww
[13:04] <Hobbsee> problem exists between keyboard and chair
[13:04] <mrooney> Hobbsee: :)
[13:05] <nullack> lol
[13:06] <seb128> mrooney: right, close the bug and ask him to reopen if he gets the issue again
[13:12] <mrooney> Hew, seb128: thanks!
[13:45] <nullack> Ping Sebastien : Gnome dont want to use ffdeinterlace for a work around to the current deinterlacing and it appears I wont be able to convince them. Get the feeling they are not keen on ffmpeg. Perhaps by October the newer gstreamer bad plugins and playbin2 will be happening
[13:53] <seb128> nullack: let's see, not really something ubuntu can change in a distribution specific way
[13:55] <nullack> No, next cycle should be much better though with playbin2, resindvd, deinterlace support - gstreamer coming of age :)
[13:55] <seb128> right
[14:51] <bddebian> Boo
[14:53] <pedro_> buuu
[14:55] <bddebian> :)
[15:37] <nullack> Anyone: Ive found a bunch of bugs in Intrepid with gnome not recognising certain file extensions as multimedia files by default and the second related issue being that although I have all the necessary demuxers and decoders installed, I dont get thumbnails generated as gnome doesnt know they are video. Im not sure, is this an upstream bug or one I should report in LP?
[15:38] <qense> This could indeed be an upstream bug. However, I would report it at LP. The Bugsquad nows Ubuntu better than upstream and can ask for the right files. If it turns out to be caused by something else, the report won't go lost.
[15:39] <qense> It's also good for us to have an overview of bugs in Ubuntu. ;)
[15:39] <nullack> Ok Ill kick it off in LP and consider bugwatching it to a new one in gnomes bugzilla
[15:40] <qense> I'd add first the files requested in https://wiki.ubuntu.com/DebuggingProcedures and wait for the Bugsqua to respond.
[15:41] <nullack> Not too much there thats relevant https://wiki.ubuntu.com/DebuggingGNOME :) Its ok, I know the gnome revision Im on and can provide details
[15:41] <qense> OK
[15:44] <nullack> What package in gnome controls the desktop file extension stuff?
[15:44] <qense> I'm not even sure if it's gnome at all, I just realized that some things are handled by shared-mime-info.
[15:45] <nullack> Even on KDE?
[15:47] <qense> At the moment it's just being used my ROX and GNOME, but they expect KDE to change soon too. I'm not sure about KDE 4.1 though, I'm running hardy.
[15:47] <nullack> ok well I will put the package as shared-mime-info because I honestly dont know what packages this is for
[15:48] <qense> It could be a bug in the GNOME handling.
[15:48] <qense> It's a database.
[15:49] <nullack> Sebastien might be busy, maybe I should leave it blank till a gnome guru is available
[15:49] <seb128> nullack: could you describe the bug?
[15:49] <nullack> lol
[15:49] <nullack> Hi mate
[15:49] <nullack> There is two issues
[15:50] <nullack> One, some common multimedia file types are not associated with their extensions as video by default
[15:50] <seb128> which ones?
[15:50] <nullack> Heres my list one sec
[15:50] <seb128> do you have an example?
[15:51] <nullack> So far I have ps. ts and mqv being missing
[15:51] <nullack> Minor as user can open with, but as you know I have reported a bug on that as well
[15:51] <seb128> I still didn't understand this open with bug but let's talk about that later
[15:52] <nullack> TS and PS especially are very common types
[15:52] <seb128> .ts like the video dvd thing?
[15:52] <seb128> .ps for a video? namespace conflict ...
[15:52] <nullack> Its a transport stream so it is many things, but one of them is video dvd
[15:53] <nullack> Well see alot more ts and people get into DVB more
[15:53] <seb128> .ts is a defined type
[15:53] <seb128>   <mime-type type="application/x-linguist">
[15:53] <seb128>     <comment>message catalog</comment>
[15:53] <nullack> Gnome errors with an error dialogue saying there is no application of this type
[15:54] <seb128> nothing claims this mimetype
[15:54] <seb128> ok, so way it works
[15:54] <nullack> Error test is Could not display (filepath and name)
[15:54] <seb128> shared-mime-info define known mimetype
[15:54] <seb128> see /usr/share/mime/packages/freedesktop.org.xml
[15:54] <seb128> it can using filenames and content for that
[15:55] <nullack> Do you agree its a bug?
[15:55] <seb128> then .desktop in /usr/share/applications list the mimetype they can open
[15:55] <seb128> well
[15:55] <nullack> So root cause .desktop is missing ts app?
[15:55] <seb128> it requires somebody who has a clue about the format to open a freedesktop bug on shared-mime-info
[15:55] <seb128> including an example of possible
[15:55] <seb128> no
[15:55] <seb128> first we should know what you call .ts
[15:56] <nullack> A transport steam file
[15:56] <seb128> shared-mime-info knows "application/x-linguist" which are .ts
[15:56] <nullack> is x-linguist common?
[15:57] <seb128> no clue
[15:57] <seb128> I've never used any I think
[15:57] <nullack> Ive never heard of it and IMHO most people would think video when someone said .ts
[15:57] <seb128> anyway
[15:57] <seb128> that's purely upstream request
[15:58] <seb128> so
[15:58] <seb128> https://bugs.freedesktop.org/enter_bug.cgi?product=shared-mime-info
[15:58] <seb128> open a bug there
[15:58] <nullack> Righto, upstream
[15:58] <seb128> describing the mimetype you want to be added
[15:58] <seb128> and attach an example if possible
[15:58] <nullack> Ready for the second issue?
[15:58] <seb128> they will want to know how the format is called
[15:58] <seb128> where it's used
[15:58] <seb128> and if the content is specific
[15:58] <seb128>
[15:58] <seb128> yes
[15:58] <nullack> Ok
[15:58] <seb128> what is the next one?
[15:59] <nullack> 2nd one is I have the right demuxers and decoders installed but gnome fails to thumbnail them, even though totem plays them through gstreamer no problems
[15:59] <nullack> These are TS's, MKV's, SWF's and MQV's
[16:00] <seb128> gconf-editor, desktop, gnome, thumbnailers
[16:00] <seb128> you have a list of formats to thumbnail there
[16:00] <nullack> Right I can look that up :)
[16:01] <seb128> those need a mimetype again, so .ts will not work until defined in shared-mime-info
[16:01] <seb128> there is a /desktop/gnome/thumbnailers/video@x-matroska/command so those should work though
[16:01] <seb128> verify if they have the correct mimetype in the nautilus dialog
[16:02] <seb128> otherwise for those which are not listed that's a totem upstream bug
[16:02] <nullack> Nautilus opens MKVs into Totem and plays them fine
[16:02] <nullack> No tumbnails though
[16:02] <seb128> look to /desktop/gnome/thumbnailers/video@x-matroska/command in gconf-editor
[16:02] <seb128> and try running the command on a command line
[16:02] <nullack> Ok one moment
[16:03] <seb128> verify also that they have the correct mimetype in nautilus too
[16:04] <nullack> Sebastien do you know the syntax for the path, the command in gconfeditor has input variables
[16:05] <nullack> e.g. /desktop/gnome/thumbnailers/video@x-matroska/command
[16:05] <nullack> No man pages for it either
[16:06] <nullack> Ah got it, executing is spat out the parameters
[16:09] <seb128> nullack: command source destination
[16:10] <seb128> nullack: there is a timeout so if the thumbnailing is too slow for this format that might be the issue
[16:11] <nullack> nullack@PPP:/mnt/vault/Film/Tests$ gnome-video-thumbnailer -j Mushishi24-head.mkv 1.jpg
[16:11] <nullack> gnome-video-thumbnailer couldn't process file: 'Mushishi24-head.mkv'
[16:11] <nullack> Reason: Took too much time to process.
[16:11] <nullack> Your spot on :)
[16:12] <seb128> I think we already got some bug about that issue
[16:12] <nullack> Ok so 1st is an upstream bug and second is a feature not a bug
[16:12] <seb128> not sure what we can do though
[16:12] <nullack> Buy me a faster machine? what ya reckon? hehe
[16:12] <seb128> bumping the timeout would mean increase ressource usage for that
[16:12] <nullack> Exactly
[16:12] <seb128> and optimizing the thumbnail might not be trivial
[16:13] <nullack> Yes it is H.264 and until we have AVC GPU acceleration my sys struggles
[16:13] <seb128> but that sounds quite some work for a low importance issue so not likely a priority
[16:13] <nullack> Agreed, Im dropping the second item
[16:14] <nullack> Would you like to discuss the open with later, I know your busy
[16:14] <seb128> that's fine, I can discuss while updates are building
[16:14] <nullack> Its a usability thing, low priority
[16:15] <nullack> My thinking is...
[16:15] <nullack> Gstreamer is installed by default
[16:15] <nullack> So choosing between Movie Player and Movie Player (gstreamer) is no choice
[16:15] <nullack> It confuses a user
[16:15] <seb128> I've no such options
[16:16] <seb128> I've only "movie player" listed
[16:16] <seb128> and then xine and mplayer because I installed those
[16:16] <nullack> They are there by default, I did a special clean install of Alpha 4
[16:16] <seb128> that's weird
[16:16] <nullack> As well, that link I sent you to the forum many others have it
[16:16] <nullack> Yeah it is
[16:16] <nullack> Would installing gstreamer plugins do it?
[16:16] <seb128> where do you get those? in the context menu?
[16:17] <nullack> Right mouse click video file, choose open with, and observe those two options in the list of apps to open the video with
[16:18] <nullack> Specifically it is Open With Other Application
[16:18] <seb128> do you have any mimetype in /usr/share/applications/totem-gstreamer.desktop?
[16:19] <nullack> lemme grep it one sec
[16:20] <nullack> Are you sure your going into the seperate dialog box with the heading Open With and not just the right mouse click window?
[16:20] <seb128> those should be equivalent
[16:21] <seb128> and yes, I tried on a .avi
[16:21] <nullack> Ive got lots of entries in different languages in that desktop file
[16:21] <nullack> I will post a screenshot right now to show you, one moment please
[16:21] <seb128> look into /usr/share/applications/mimeinfo.cache the avi line for example
[16:21] <seb128> video/x-avi=totem.desktop;mplayer.desktop;
[16:21] <seb128> is what I get here
[16:23] <nullack> nullack@PPP:/mnt/vault/Film/Tests$ cat /usr/share/applications/mimeinfo.cache | grep avi
[16:23] <nullack> video/x-avi=totem.desktop
[16:23] <nullack> nullack@PPP:/mnt/vault/Film/Tests$
[16:24] <seb128> nullack: and in .local?
[16:24] <seb128> grep avi .local -R?
[16:24] <nullack> No movie apps, other stuff
[16:25] <seb128> did you try on a .avi?
[16:25] <nullack> The thing is, once you right mouse click, go into Open With other Application ...  noting the three dots means its going into a new window
[16:25] <seb128> and you have a gstreamer entry listed?
[16:25] <nullack> Its not just the right mouse menu
[16:25] <nullack> No gstreamer is listed in the right click menu
[16:25] <seb128> oh
[16:26] <seb128> you are speaking about the dialog to pick an application
[16:26] <nullack> Yes sir
[16:26] <seb128> not the "open with" tab in the properties dialog
[16:26] <nullack> Its the "open with" window
[16:26] <seb128> I was thinking about the tab in the property dialog
[16:26] <seb128> ok, I can confirm the issue now
[16:26] <nullack> Sorry
[16:27] <nullack> Can you see it now?
[16:27] <seb128> not your fault, just a misunderstanding there
[16:27] <seb128> yes
[16:27] <seb128> I just never use this dialog usually
[16:27] <nullack> The thing is because some video mime types arent recognised a user has to go into this menu to fix video playback
[16:28] <nullack> To force it
[16:28] <seb128> I usually open totem and dnd things to it
[16:28] <seb128> but right, this dialog is there and should be fixed
[16:28] <nullack> Yeah, alternative workflows
[16:28] <seb128> this issue is a packaging one
[16:28] <nullack> Can I do anything else to help?
[16:28] <seb128> that's due to the "make possible to install xine and gstreamer variants together"
[16:29] <seb128> you can try to work on a patch if you want ;-)
[16:29] <seb128> hum, the .desktop has a NoDisplay=true, maybe nautilus should respect that
[16:30] <nullack> I have alot to learn about packaging and really my professional skills are in test management / release management / problem management not configuration management
[16:31] <seb128> nullack: I've a fix, those should use Hidden=true rather than NoDisplay=true, will fix in the next upload
[16:31] <nullack> Great thanks my friend, will test when you deliver the goodness in updates
[16:31] <seb128> nullack: ok, keep the good work on bugs then and let other people come with changes, that works too ;-)
[16:31] <seb128> thanks for your interest in this issues
[17:10] <nullack> Ping Pedro : Thankyou for adding your comment to 250021 but I do not think that a new file roller has been committed for build - I have not received any emails about it and I dont see it in the build farm
[17:10] <nullack> #250021
[17:12] <seb128> bug #250021
[17:13] <pedro_> nullack: according to upstream that doesn't affect trunk
[17:13] <pedro_> that's why i marked as fix committed
[17:13] <seb128> nullack: we use "fix commited" when the bug is fixed upstream so we know what to close in the next version update
[17:13] <pedro_> at the desktop (gnome) fix committed  = fixed upstream also
[17:14] <pedro_> indeed
[17:14] <nullack> Ok, I understand, not intuitive but Ill follow the standards :0 Since our tree isnt their tree
[17:14] <nullack> Sorry Pedro, thanks for your help on this bug :)
[17:14] <pedro_> nullack: you're welcome, thanks for following up ;-)
[17:16] <awalton_laptop> is anyone from the bug squad around that could renew my membership?
[17:17] <Igorot> awalton_laptop: ask bdmurray
[17:17] <awalton_laptop> Igorot, thanks
[17:21] <pedro_> awalton_laptop: renewed
[17:21] <awalton_laptop> pedro_, thanks
[17:22] <pedro_> you're welcome
[17:51] <nullack> Ping someone at Canonical : I think packages,ubuntu.org has lost the plot it tells me that my search for ffmpeg packages in intrepid and hardy are not found
[17:51] <nullack> You have searched for packages that names contain ffmpeg in suite(s) intrepid, all sections, and all architectures.
[17:51] <nullack> Sorry, your search gave no results
[17:52] <nullack> Edit: No Ive lost the plot - time for coffee - I forgot to put search by package name
[17:54] <nullack> lol edit2: it has :)
[17:54] <nullack> Internal Server Error
[17:54] <nullack> The server encountered an internal error or misconfiguration and was unable to complete your request.
[17:54] <nullack> Please contact the server administrator<EMAIL_ADDRESS>and inform them of the time the error occurred, and anything you might have done that may have caused the error.
[17:54] <nullack> More information about this error may be available in the server error log.
[18:33] <chrisccoulson> just having a look through some of the expirable bugs. i've just come across bug 217760
[18:34] <chrisccoulson> personally, i think thats a bad idea, but what does everyone else think?
[18:34] <pheeror> as isv (read adobe) sux hard, it's not so bad idea
[18:35] <hggdh> argh, LP is slow...
[18:35] <chrisccoulson> it is a bad idea. we shouldn't give users an easy way of installing packages that have been specifically built for 32-bit architecture on a 64-bit machine
[18:36] <hggdh> well, there are builds for this
[18:36] <chrisccoulson> the packages should be re-packaged to install on a 64-bit architecture. that is already the case with adobe (which is installable from medibuntu on 64-bit)
[18:36] <pheeror> take in consideration that amd64 is backward compatible with x86
[18:36] <pheeror> yes sure
[18:36] <pheeror> my bad
[18:36] <chrisccoulson> but 32-bit packages will contain files in /usr/lib. installing these on a 64-bit machine is almost guaranteed to cause breakage
[18:37] <chrisccoulson> hggdh, what did you mean about there are builds for this?
[18:37] <pheeror> indeed, i've misunderstood the issue
[18:37] <hggdh> for example, ia32
[18:37] <hggdh> (and I do run both 32 and 64 bits on my laptop)
[18:38] <pheeror> btw is it possible to install ff x86-32 with that evil flash on amd64 hardy?
[18:38] <pheeror> (by one or two commands)
[18:38] <chrisccoulson> i thought so, thanks. do you think that bug 217760 should be set to won't fix?
[18:38] <hggdh> if a specific package/library needs to be built for 32 bits on a 64bits architecture, this has to be requested
[18:39] <hggdh> darn it, my browser refuses to go online right now
[18:39] <chrisccoulson> yeah, i agree with you. i definately don't think we should enable an easy way to pull packages from a repository built for 32-bit architectures on to a 64-bit machine
[18:41] <hggdh> this is usually not a good idea. I have done that before, but by copying the necessary individual libraries over to /usr/lib32, and stitching the resulting mess by hand
[18:42] <chrisccoulson> me too. could you mark the bug report as 'wont fix' please? :) i can't do that unfortunately
[18:44] <james_w> hey chrisccoulson, thanks for working on the gnome-session bug
[18:44] <chrisccoulson> no problem! sorry i havent responded yet.
[18:45] <chrisccoulson> i think yours is probably the better solution, as it is more consistent with the rest of the code
[18:45] <james_w> it does seem to be
[18:45] <james_w> shall I forward it to upstream?
[18:45] <chrisccoulson> you can do. i already attached my patch to the upstream report actually, but nobody has commented yet
[18:46] <james_w> ah, ok, I should have looked
[18:55] <chrisccoulson> james_w, are you familiar with bug 235698?
[18:59] <james_w> chrisccoulson: I don't think so
[18:59] <james_w> why?
[19:00] <chrisccoulson> ah, ok. it's been fixed in intrepid, and i was going to ask if you knew whether it was going to be fixed in hardy as a SRU?
[19:00] <seb128> chrisccoulson: not likely, it's a non issue for hardy, the only reason users notice is apport
[19:01] <chrisccoulson> ah, ok. thanks for that seb128
[19:18] <chrisccoulson> seb128, what do you think about blacklisting gvfs-fuse-daemon in apport? it might stop people who have enabled apport from reporting new bugs...
[19:19] <seb128> chrisccoulson: there is not a lot of recent duplicates and I would prefer to backport the patch for this specific issue rather than workaround it this way
[19:20] <chrisccoulson> the only reason i suggested that was because i got the impression it probably wasn't going to be fixed in hardy
[19:21] <seb128> chrisccoulson: and?
[19:21] <seb128> chrisccoulson: do you think it's important to fix there? it should create no real issue
[19:23] <chrisccoulson> i was just trying to think of a way to reduce the number of people reporting that bug from hardy, but, like you said - there aren't that many recent duplicates anyway, so it's probably a non-issue
[19:28] <seb128> chrisccoulson: apport also has a list of known bugs in bzr, so you can add an entry there and user will be pointed to this bug when trying to open a new duplicate
[19:30] <chrisccoulson> seb128: i didn't know that actually. thanks!
[19:30] <seb128> you're welcome
[20:00] <_stink_> I'm new-ish to bug triage. Bug 154621 is apparently a well known KDE issue, with solutions and other info available in more than one KDE bug (75828 and 70624, e.g.). Other info at http://ur1.ca/30z. I'd like to add these links to the LP bug and close it somehow.  Is invalid the right status?
[20:01] <_stink_> those KDE bug #s are at bugs.kde.org
[20:02] <yuriy> _stink_: there is an "also affects project" link to link the reports together
[20:02] <yuriy> _stink_: if there are other reports about it in launchpad, you can pick a "main" one and mark the others as duplicates
[20:03] <yuriy> _stink_: and add all relevant information to the main report in a comment  if it's not already there
[20:04] <_stink_> yuriy: ok. i don't see other LP bugs on the same issue, just bugs at bugs.kde.org.  so i'll put the info in a comment on this bug.
[20:04] <yuriy> _stink_: if it is an actual bug, and can be confirmed in other reports, invalid is not the right status
[20:04] <yuriy> _stink_: right, that's what "also affects project" is for
[20:04] <_stink_> yuriy: the KDE bug reports about this don't consider it an open bug. they are old reports and amount to telling the user to config correctly
[20:04] <_stink_> ok
[20:05] <_stink_> which is why i thought it should be closed somehow in LP
[20:05] <yuriy> oh
[20:05] <yuriy> well, that may be correct then, but comment carefully
[20:05] <_stink_> ok, thanks
[20:05] <_stink_> i'll be nice :)
[21:53] <dupondje> https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/258797
[21:53] <dupondje> would be cool if it was added, now audacious is useless imo :)
[21:55] <bdrung> dupondje: may be I have a look at it
[21:55] <dupondje> tested and successfully working :)
[22:26] <bdrung> dupondje: can you give me the link to the bugreport from the upstream project?
[22:27] <dupondje> bdrung: http://bugzilla.atheme.org/show_bug.cgi?id=42
[22:28] <bdrung> dupondje: thx
[22:29] <dupondje> without the patch audacious creates logfile with size of 1gb/10mins or something :p
[22:29] <dupondje> quite crap :P
[22:30] <bdrung> dupondje: what do i have to do to reproduce this bug or does this happen right on the start?
[22:31] <dupondje> think u need to load files in the playlist
[22:32] <bdrung> k, i'll try it
[22:32] <dupondje> and I got ARTIST - TITLE as playlist info ...
[22:40] <bdmurray> hggdh_: Do you remember what we said about needs-packaging bugs that are already packaged for debian?  change to sync request?
[22:41] <LaserJock> bdmurray: that's what it was originally, but then we decided to take that out
[22:41] <LaserJock> bdmurray: do you think it should go back in?
[22:42] <bdmurray> LaserJock: maybe, I wrote a script this weekend that found a fair number of n-p bugs that are already packaged for debian
[22:42] <LaserJock> well
[22:42] <LaserJock> to me it depends on the intent of the bug
[22:43] <LaserJock> if they are saying "I want this software in" I'd invalidate it
[22:43] <LaserJock> but if they're saying "I know it's in debian, I just want the latest version" I'd maybe turn it into a "upgrade" bug
[22:44] <LaserJock> but I'd avoid turning them into sync requests because that's a more defined process bug
[22:44] <LaserJock> bdmurray: does that make sense?
[22:45] <bdmurray> not really
[22:45] <LaserJock> heh
[22:45] <LaserJock> what would be the purpose of the bug then, if the software is already in Debian?
[22:46] <LaserJock> unless there's more to the story it's probably useless
[22:47] <LaserJock> and I'd rather have people do investigation first before doing a sync bug
[22:47] <dupondje> its about my bug ? ;)
[22:47] <LaserJock> so I think it's counter-productive to try to turn needs-packaging into sync bugs
[22:48] <bdmurray> right, but I could run requestsync for the the bug, invalidate the n-p bug and point them the at the sync request bug to subscribe to
[22:48] <LaserJock> but I don't want people using requestsync unless they know what they're doing
[22:48] <bdmurray> I said "I could run requestsync"
[22:49] <LaserJock> people should at a minimum test build the debian package in sbuild/pbuilder before submitting requestsync
[22:49] <LaserJock> ah
[22:49] <LaserJock> well, that'd be a lot of work on your part
[22:49] <LaserJock> or wait
[22:50] <bdmurray> https://wiki.ubuntu.com/SyncRequestProcess doesn't say anything about sbuild/pbuilder
[22:50] <LaserJock> if these packages are in Debian but not in Ubuntu then nothing should be done at all really, depending on the stage of release
[22:51] <LaserJock> packages are semi-automatically imported in that case
[22:51] <bdmurray> Right, but we are past Import Freeze now
[22:51] <LaserJock> so we shouldn't be filing sync bugs for those unless there's a good reason
[22:52] <LaserJock> I'm not sure when the archive admins stop importing new sources
[22:52] <bdmurray> I'll check with them then
[22:53] <LaserJock> but SyncRequestProcess should probably have something about test building
[22:53] <LaserJock> currently it's implied
[22:53] <jpds> LaserJock: If the person running requestsync is not a member of the MOTU team, they will first need approval of the u-(m|u)-s team.
[22:53] <LaserJock> jpds: exactly, I don't think we should fill up the queue with low-priority bugs
[22:54] <jpds> Good point.
[22:54] <LaserJock> I'd rather people do some work on it first to make sure it's worth the sponsors time
[22:54] <bdmurray> So I should just forget about those?
[22:55] <LaserJock> honestly I don't think it's worth your time to file sync requests
[22:56] <bdmurray> Okay, so I am at a point we are know something should be done w/ 10 bugs or so but just shouldn't do anything?
[22:57] <LaserJock> in a reply to invalidating you might point people to SyncRequestprocess and say something like "This software has already been packaged in Debian. If it is not available in the current Ubuntu development version feel free to follow [sync wikii page]"
[22:58] <LaserJock> bdmurray: which bugs are you talking about?
[23:01] <bdmurray> bug 255110, bug 151564, bug 198048, bug 181084, bug 230453, bug 255106, bug 255402, bug 141171, bug 204711
[23:03] <bdrung> dupondje: i cannot repproduce it.
[23:05] <dupondje> strange
[23:05] <bdrung> dupondje: with wich filetype does this bug appears?
[23:05] <dupondje> if u google the error, tons of people have it
[23:05] <dupondje> .MP3
[23:05] <bdrung> i will test with mp3
[23:06] <LaserJock> bdmurray: you're saying you have ~ 10 needs-packaging bugs now in your list of New/Undecided ?
[23:06] <LaserJock> s/Undecided/Unkown/
[23:10] <vadi2> A pair of people after an update of ubuntu got their themes broken, and I'm not sure how to fix it. The question has been open for quite a while: https://answers.launchpad.net/ubuntu/+question/38900
[23:10] <bdmurray> LaserJock: no, I'm saying I've discovered that those needs-packaging bugs are already packaged in Debian
[23:11] <bdrung> dupondje: still not
[23:11] <LaserJock> bdmurray: oh, right
[23:11] <dupondje> what version using ? :)
[23:11] <LaserJock> bdmurray: I'm guessing a few of them are people who've filed a bug in both Ubuntu and Debian
[23:12] <bdrung> dupondje: 1.5.1-2ubuntu2
[23:12] <dupondje> same :x
[23:12] <bdrung> does it also happen on other file types?
[23:13] <LaserJock> bdmurray: so are you wanting to mark them Invalid or no?
[23:13] <dupondje> http://pastebin.ubuntu.com/38616/
[23:13] <dupondje> this is my conf
[23:16] <bdrung> dupondje: where do i have to put it?
[23:16] <LaserJock> Invalidating a needs-packaging bug that's In Progress is a bit troublesome, but people can reopen them if they've got a reason to
[23:16] <dupondje> /home/<user>/.config/audacious/config
[23:18] <dupondje> also see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491655
[23:24] <bdrung> dupondje: with your config audacious does not start. there is no alsa device, because i run intrepid in a virtual machine. therefore i use null output instead of alsa
[23:28] <dupondje> oh :s well dunno, try loading ALOT of MP3 files
[23:29] <dupondje> +1000
[23:29] <dupondje> but I gtg now
[23:29] <dupondje> pm me if u have questions


[04:20] <guiverc> uwn: editor email sent; only summaries in planet (rest listed), scripts run -- but any errors or anything detected on wiki, please tell me.
[20:51] <tsimonq2> guiverc: Thanks!


[08:50] <Unit193> http://bugs.debian.org/798912 - http://mentors.debian.net/package/libmpris2client
[08:57] <knome> ochosi, hah, well, mostly moving postponed items there, or items that have raised up from items this cycle but aren't realistic now
[08:57] <knome> bluesabre, that works for me, though if it's tomorrow, then it's bad :P
[08:57] <knome> and friday is badish as well..
[08:58] <knome> and saturday or sunday might be just as bad
[08:58] <knome> but i'll try to be there!
[10:27] <bluesabre> knome: so... that leaves thursday then?
[10:27] <bluesabre> oh wait
[10:28] <bluesabre> today is wednesday
[10:50] <bluesabre> Unit193: pin
[10:50] <bluesabre> g
[10:51]  * Unit193 pins bluesabre up on the board.
[10:51] <bluesabre> yay
[10:51] <bluesabre> I think
[10:51] <bluesabre> :D
[10:51] <bluesabre> want your opinion...
[10:51] <bluesabre> https://launchpad.net/xfpanel-switch/1.0/1.0.1
[10:52] <bluesabre> would you agree that this new version would not need a freeze exception for feature freeze or UI freeze?
[10:52] <bluesabre> since it has no new features or changes the UI
[10:52] <bluesabre> only adds templates and fixes bugs
[10:54] <Unit193> Templates could be seen as a new feature.  Is the template system new, or just "hey, now we ship files it already supported!"?
[10:55] <bluesabre> it was already there, just no preinstalled templates
[10:56] <bluesabre> https://launchpad.net/xfpanel-switch/1.0/1.0.0
[10:57] <Unit193> Alright, I'd personally think that'd be fine then, since it's not a new feature to break.  If you did go for FFe, would think it'd be quick and painless though.
[10:57] <bluesabre> yeah
[10:58] <bluesabre> just hard to write the FFe (any new features?? well nothing really)
[10:59] <bluesabre> thanks for your opinion! :D
[11:01] <Unit193> Hah, sure.
[12:54] <knome> bluesabre, lol... yeah, it kind of only leaves sat OR sun, but i don't know which yet
[12:54] <knome> bluesabre, i have the sameish with mon/tue, i don't know which one doesn't work for me yet
[16:01] <flocculant> jjfrv8: thanks for confirming that shutdown hang :)
[16:24] <drc> flocculant: Shutdown works on (my) hardware.
[16:25] <flocculant> yep - thanks - confirms my suspicion - virtual issue again ;)
[16:25] <drc> Nope, got rid of it the last time Canonical really ticked me off a while ago..
[16:26] <drc> That's why I couldn't report the Network Monitor thingie.
[16:28] <flocculant> ok - would have been useful to get a good report on the tracker
[16:37] <flocculant> bluesabre knome: perhaps not worry about knocking a meeting out quickly just because beta
[16:37] <flocculant> I'd mail the two groups anyway on Monday - possibly also users this time
[16:37] <knome> mhm
[16:38] <knome> as i said, i can do one either or monday or tuesday - i just don't know which yet..
[16:40] <flocculant> yea
[16:41] <flocculant> I'm easy - other than beta I've nto got anything to bring up
[16:41] <knome> me neither really
[16:41] <knome> and since we plan not to do the team updates..
[16:41] <knome> well, maybe that's one
[16:41] <knome> kick off the voting for that
[16:41] <flocculant> not sure if I'd said the tracker multiple team things was working out ok or not - but it is for me :)
[16:42] <knome> heh, good :)
[16:42] <flocculant> yea perhaps - or just take it to m/l straight away
[16:42] <knome> i will make sure you can link to any filter state you want
[16:42] <flocculant> voting always ends up on m/l anyway
[16:42] <knome> well actually, you can already, but you need to construct the url manually
[16:42] <flocculant> yep - that might help
[16:42] <knome> the syntax is:
[16:43] <knome> http://tracker.xubuntu.org/#tab-details/[filters]
[16:43] <flocculant> knome: probably not going to do that
[16:43] <knome> where [filters] is one (or more of):
[16:43] <knome> a=assigneenick
[16:43] <knome> text=search
[16:43] <flocculant> I'd have so many different bookmarks I'd end up ignoring them :)
[16:43] <knome> s=specificationname
[16:43] <knome> if you specify multiple assignees, separate by comma
[16:43] <knome> eg. a=knome,flocculant
[16:44] <flocculant> right
[16:44] <knome> and if you specify multiple filters, specify by +
[16:44] <knome> eg. a=flocculant+text=qa
[16:44] <knome> but yeah, i'll make sure you will always have a link to the current filter sooner or later
[16:44] <knome> statuses aren't filtered yet... or sort
[16:45] <flocculant> the thing is - that almost all other bp's are ones that I would look at together at some point - all impact on qa in some way
[16:45] <knome> ;)
[16:45] <flocculant> or rather be things that qa needs to know
[16:46] <knome> yep
[16:46] <flocculant> just not all at the same time :)
[16:46] <knome> heh
[16:46] <knome> yeah
[16:46] <knome> it's possible i'll reintroduce the work item stuff in the overview in a way or another
[16:46] <knome> but that's in the bottom of the list tbh
[16:46] <knome> maybe something that shows open items quickly
[16:47] <flocculant> mmm
[16:48] <flocculant> I'm not convinced it's need now really
[16:48] <knome> yeah - what did i tell you :)
[16:48] <flocculant> well
[16:48] <knome> i wanted to merge it and the details tab from the moment i split them up...
[16:48] <flocculant> well
[16:48] <knome> :D
[16:48] <flocculant> you told me things after I'd told you it was just a pita to me now ;)
[16:49] <knome> haivng hard time acknowledging i was right? ;)
[16:49] <knome> *having too
[16:49] <knome> hahah, those things were on the works already then
[16:49] <knome> i wouldn't have done a dumbed down details page
[16:49] <flocculant> having a hard time working out why you'd think I have suddenly acquired esp :D
[16:49] <knome> or something that didn't replace the features in overview
[16:50] <knome> esp?
[16:50] <flocculant> extra sensory perception
[16:50] <knome> hah
[16:50] <flocculant> ie mind reading ...
[16:50] <flocculant> :D
[16:50] <knome> mm..
[19:25] <flocculant> pleia2: funnily enough I was thinking along those lines too "it looks like a great initiative that may be valuable enough to be replicated by the flavors"
[19:26] <pleia2> :D
[19:26] <pleia2> great minds, sir
[19:26] <flocculant> :)
[19:36] <knome> what?
[19:36] <pleia2> https://lists.ubuntu.com/archives/ubuntu-community-team/2015-September/000813.html
[19:37] <pleia2> the Unity desktop team is doing a series of Bug Bonanzas leading up to 16.04
[19:37] <pleia2> they have it very nicely organized :)
[19:37] <knome> mhm
[19:44] <flocculant> the only obvious difference being we'd have 2 or 3 people arrive to help ;)
[19:45] <knome> haha
[19:45] <knome> instead of 4 or 5 for ubuntu
[19:45] <pleia2> haha, now now :)
[19:45] <flocculant> ha ha ha
[19:47] <knome> pleia2, well it's the truth... :P
[19:56] <flocculant> well - me out for the day now - night all
[20:00] <pleia2> night flocculant
[20:58] <ochosi> evening all
[21:35] <knome> ok everybody, you can now get a permalink to any of the pages
[21:35] <knome> err, to any filters
[21:35] <knome> see the permalink button there
[21:36] <knome> (it'll appear when you add filters)
[21:37] <knome> it doesn't save sort - yet
[22:05] <knome> ok, sort is saved and applied now as well


[00:17] <xnox> qtdeclarative-opensource-src seems to have a weird binary split. For binaries that are in main, only those on i386/amd64/armhf are in main powerpc/ppc64el/arm64 are in universe which makes other packages depwait on powerpc/ppc64el/arm64
[00:19] <infinity> xnox: Can fix.
[00:20] <infinity> Though, I don't see this...
[00:20] <infinity> Oh, cause it's in proposed, and my report only does the release pocket.
[00:20]  * infinity hunts and fixes manually.
[00:22] <xnox> infinity: yeah, it's quite confusing. Ideally we'd have an architecture-mismatches-proposed.txt report or something like that.
[00:23] <infinity> No, ideally this wouldn't happen at all. :P
[00:23] <xnox> =))))))))))))))))))
[00:23] <infinity> But it's another fun side-effect of some bugs with copying from PPAs.
[00:23] <infinity> Also, whee.  Maximising a window under LIM gives you NO MENUS.
[00:23] <infinity> I kinda expected the top bar to become my menu/title bar...
[00:24] <xnox> infinity: for me there are menus, they are just below the top bar, cause window is maximazied underneath it.....
[00:24] <infinity> xnox: "below", as in Z-index, or you have a fat top bar?
[00:24] <xnox> "Z-index"
[00:24] <infinity> Cause it may well be Z below, but how would I know? :P
[00:25] <xnox> but somehow at the moment i have both LIM and global menus simultaneously =/
[00:25] <infinity> Cute trick.
[00:25] <infinity> Alright, overrides fixed, as of the next publisher run.
[00:37] <infinity> xnox: Do you know if there's already a bug for the LIM Z-Index I HAZ NO MENUS OR BUTTONS thing?
[00:37] <infinity> Given all the users would wouldn't know how to use Alt-Space or similar, I guess they'd just be stuck with that window forever.
[00:37] <xnox> infinity: i only saw seb128 saying they have dozens of bugs / duplicates about LIM and Lock Screen.
[00:38] <infinity> Hrm, my screel lock seems to be fine.
[00:38]  * infinity does one more pass on qt5 component mismatches.
[00:38] <xnox> infinity: the most hallarious one is that one needs to use indicator to get unstuck from: alt+tab, release tab, keep pressing alt, press ctrl+l
[00:39] <xnox> infinity: input keeps going into the session, yet lock screen is the highest on the Z-order and thus one can't see anything, nor unlock the lock screen =)
[00:40] <infinity> xnox: Hahaha.  Cute.
[00:41] <infinity> xnox: Doesn't seem like something I'd do by accident, but fun to do on purpose.  If I was at a sprint right now, I'd so be locking people's machines that way and waiting for passwords in IRC.
[01:06] <xnox> infinity: thanks for promotions, looks much better now. But why is this still failing? https://launchpad.net/ubuntu/+source/qt3d-opensource-src/5.0~git20130731-0ubuntu2
[01:13] <cjwatson> xnox: that's just lack of upstream architecture support, isn't it?
[01:13] <cjwatson> oh, it's a different failure from before
[01:13] <xnox> cjwatson: it's failing to install dependencies, no?
[01:14] <cjwatson> it is now, but previously in the PPA it failed with a real build error later
[01:14] <cjwatson> so it isn't going to do better even if you fix this
[01:14] <xnox> =(
[01:14] <xnox> porter box doesn't have -proposed enabled, so isn't that useful either =(
[01:15] <cjwatson> any of the recent qt5 landings were already tried on all arches; they're probably being retried again in the primary archive, but are unlikely to do better
[01:15] <xnox> cjwatson: ok, there was architecture-component missmatch in proposed which infinity fixed now.
[01:16] <cjwatson> yeah, I saw
[01:16] <xnox> let me retrace my steps from proposed-migration report where i thought it might be a problem blocking the migration (once the block is lifted)
[01:19] <cjwatson> hm, yeah, there is something still wrong
[01:20] <cjwatson> attacking with chdist
[01:20] <cjwatson> ah, this one is arch-indep
[01:21]  * cjwatson promotes libqt5core5a qtbase5-doc-html to main
[01:21] <infinity> I already got those.
[01:21]  * cjwatson ctrl-cs quickly
[01:21] <infinity> In my last pass.
[01:21] <cjwatson> lucky my internet is slow ;-)
[01:21] <infinity> I think...
[01:21] <cjwatson> https://launchpad.net/ubuntu/trusty/i386/libqt5core5a doesn't show it
[01:22] <infinity> Yeah, maybe not.
[01:22] <infinity> The names all look the same.
[01:22] <infinity> Ahh, indeed, those two are on c-m-p, they weren't before.  Or I missed them in my copy and waste run.
[01:22] <infinity> Weird.
[01:23] <infinity> Carry on.
[01:23] <cjwatson> ok, doing
[01:23] <xnox> qtsensors5-dev looks weirdly split as well.
[01:24] <infinity> Anything that was NEW in those arches probably is.
[01:24] <infinity> Let me see.
[01:24] <xnox> (it's in main on primary arches, universe on ports arches)
[01:24] <xnox> http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt for -proposed would be nice =)))
[01:24] <infinity> xnox: I'll get the qtsensors ones.
[01:25] <xnox> infinity: thanks.
[01:26] <infinity> Alright, that source package is sorted.
[01:28]  * infinity hunts for more.
[01:30] <infinity> Alright, found more. :P
[01:35] <infinity> Okay, missed that publisher run.  As of the next, I think all of qtdeclarative's rdeps should be in a sane state.
[01:57] <xnox> cjwatson: so qt3d build on ppc64el fails on embedded copy of assimp, which did build fine in the archive, i wonder why embedded 3rdparty copy is used.
[01:58] <cjwatson> ok, but probably best not to ask me :-)
[02:41] <xnox> compiles well, after porting, and only two test failures on .3ds file format. will poke that more tomorrow.
[02:41]  * xnox Zzzzz
[03:02] <darkxst> I suppose its getting too late now to have any change of bug 1228765 happening?
[03:02] <ubot2> Launchpad bug 1228765 in unity-control-center (Ubuntu) "[FFe] Implement DisplayConfig dbus interface and transition to gnome-desktop 3.10" [Low,In progress] https://launchpad.net/bugs/1228765
[03:11] <slangasek> darkxst: has this been coordinated with the Ubuntu Desktop team?  The two linked branches for the unity packages are both marked 'disapprove'
[03:12] <slangasek> I also don't understand the claim in the bug description that the move to 3.10 was blocked by the unity forks of g-s-d and g-c-c... it sounds like these "forks" are *still* entangled (and therefore blocking)
[03:12] <slangasek> (so, what was the point in forking if they still have to be upgraded in lockstep?)
[03:12] <darkxst> slangasek, desktop team wouldn't consider this work unstill things were forked
[03:13] <darkxst> the whole point of forking was so ubuntu GNOME can have g-s-d/g-c-c 3.10
[03:13] <slangasek> darkxst: I'm talking about the merge proposals that were specifically raised on the unity-control-center and unity-settings-daemon packages, which are the forked versions
[03:14] <slangasek> if they're forked, why are they tied into this FFe request?
[03:14] <darkxst> right, they need to be patched for the new gnome-desktop api
[03:14] <darkxst> and they got marked disapproved because Noskcaj proposed merges without an FFe
[03:16] <slangasek> I would want to see an explicit ack from the Desktop team that they're happy with letting this in, before I would sign off on this
[03:16] <slangasek> obviously we don't want to be holding back Ubuntu-Gnome, but we are past FF and I'm not in a position to evaluate the impact on the desktop
[03:19] <darkxst> they were ok with it when I proposed the FFe (a couple of weeks ago), but I can check with them if still ok
[03:20] <slangasek> darkxst: that's not how I understand the comments in the bug log, where a member of the desktop team last week is calling it 'risky'
[03:21] <darkxst> its seb's whole 1 step at a time policy, that made this end up so late!
[03:25] <darkxst> I wanted to land this stuff a month ago, but Seb said it had to wait for u-s-d to be done
[03:27] <slangasek> well, whatever the reason, it's now in a place where it needs a FFe; and I don't think any member of the release team is going to say "yes" to an FFe if the affected flavors are saying "no"
[03:31] <slangasek> (and if it does require a new version of bluez, like bug #1267909 suggests, that's a whole new level of due diligence required)
[03:31] <ubot2> Launchpad bug 1267909 in unity-control-center (Ubuntu) "Update Bluetooth panel" [Wishlist,Triaged] https://launchpad.net/bugs/1267909
[03:32] <darkxst> slangasek, no intention to update BlueZ this cycle
[03:33] <darkxst> all bluetooth changes were reverted in our packaging so it works fine with gnome-bluetooth 3.8
[03:34] <slangasek> ah, and I see now that you said so on the bug - sorry for overlooking
[03:38] <darkxst> anyway I will chat again with desktop team tonight and see if they will still ack this
[08:54] <darkxst> infinity, around?
[10:01] <didrocks> anyone available from the RT to override some packages for migrating?
[10:03] <didrocks> (5.2 migration)
[11:15] <Riddell> didrocks: yo, what's it need?
[11:15] <didrocks> Riddell: hey, I had to go with the "removing binary packages" that will be reintroduced in next upload anyway (as the Qt 5.2 transition is big, I'm trying to ensure that we are well advanced before EOD)
[11:16] <didrocks> I check all rdepends, and it won't introduce uninstallable packages
[11:16] <didrocks> (as most of them are just new build in -proposed)
[11:22] <Riddell> didrocks: let me know if I can help
[11:22] <didrocks> Riddell: yeah, will do, thanks for the offer :)
[11:38] <xnox> uploaded remaining 6 packages that didn't rebuild against libqt5core5a yet.
[11:39] <xnox> that should make britney more happy about qt5.2 transition.
[11:47] <didrocks> xnox: oh, Mirv did you miss those ^
[11:47] <didrocks> I saw cordova-ubuntu
[11:48] <didrocks> xnox: hum, why wallch?
[11:48] <didrocks> it's qt4
[11:49] <didrocks> same for qgo, isn't it?
[11:53] <Mirv> didrocks: yes, it's possible, only last week I added peg-e, pokerth, mediscanner2 (which was new user as well)
[11:54] <Mirv> and phonon
[11:54] <Mirv> my fault was to use reverse build depends checks only most of the time
[11:55] <Mirv> plus generally having enough stuff to do all the time to remember to check whether http://pad.ubuntu.com/qt52-dependencies was complete
[11:56] <Mirv> not that I'd have seemingly found qgo anyway
[11:58] <Mirv> I did see those phonon plugins, then forgot about them after I built the phonon itself :) nice that none of those missed ones were too big
[12:01] <xnox> didrocks: wallch 4.0-0ubuntu3 depends on libqt5core5 (>= 5.0.2), libqt5gui5 (>= 5.0.2), libqt5network5 (>= 5.0.2), libqt5webkit5, libqt5widgets5 (>= 5.0.2)
[12:01] <xnox> didrocks: thus it's qt5, and totally needed rebuild for libqt5core5a.
[12:02] <Mirv> ah, so there's a 4.0 wallch in -proposed and that's why reverse-depends doesn't show it or qgo?
[12:02] <xnox> didrocks: dito qgo.
[12:02] <Mirv> and 3.0 was Qt4
[12:02] <didrocks> xnox: ah, so they were stuck in proposed already
[12:02] <xnox> didrocks: Mirv: yes, all of those were packages that were stuck in proposed, and got build against libqt5core5.
[12:02] <Mirv> thanks xnox for spotting all of those
[12:02] <didrocks> ok, making sense then
[12:03] <didrocks> xnox: so, they were just being blocked I guess, not blocking Qt 5.2 migration itself?
[12:03] <xnox> Mirv: well, proposed-migration did =) then I wrote a ben transition tracker that generate a list for me ;-) it's not like I scanned the archive by hand ;-)
[12:03] <didrocks> as previous version in release were 4.0, they will just not migrated
[12:04] <xnox> didrocks: i don't know, but these rebuilds should lower the uninstallable count and make the proposed-migratin page look more sane.
[12:04] <xnox> didrocks: e.g. with libav britney was blocking on "leaf packages like above" for a long time, until it didn't and allows NBS into release pocket.
[12:05] <xnox> didrocks: i hope you didn't do any removals to force qt5.2 transition in, did you?
[12:06] <xnox> yeah, the list is now very small.
[12:06] <xnox> i'll wait for phonon to build and then it should be clear what remaining couple of packages are that britney points out.
[12:07] <xnox> cause e.g. britney still thinks that " ubuntu-touch" would become uninstallable =))))))
[12:07] <didrocks> xnox: we had to remove some packages, this was discussed already as it's temporary and agreed on
[12:07] <didrocks> (arm64/ppc64el and powerpc)
[12:08] <xnox> didrocks: which ones were those? i don't see how those could be blocking qt5 transition, given that most of qt5 never built on those.
[12:08] <xnox> (qtdeclarative and up)
[12:08] <didrocks> xnox: qtdeclarative is fine, but not the sdk
[12:08] <xnox> oh, right.
[12:09] <didrocks> xnox: and there is another MP to fix the sdk, but colin told to go ahead and do that once the transition is done
[12:09] <xnox> cool, there still looks something odd with libaccounts/signon stack though.
[12:09] <didrocks> yeah, I did remove for libaccounts/signon
[12:09] <didrocks> so should be fine
[12:09] <didrocks> (part of the same set blocked by sdk and have no rdepends)
[12:10] <didrocks> xnox: tell me if you see anything else bad, multiple eyes help :)
[12:12] <mdeslaur> hrm, the archive is busticated
[12:13] <mdeslaur> libdbusmenu-qt in now available, but was built against qt5.2 that's still in -proposed
[12:13] <didrocks> I didn't touch that one
[12:13] <didrocks> weird that it migrated?
[12:13] <mdeslaur> yeah, quite weird
[12:14] <didrocks> waow, you're right
[12:14] <xnox> well, britney goes by uninstall count, thus removing a package can trade _anything_ into the release pocket.
[12:14] <didrocks> ah I know, there are some magic IIRC
[12:14] <didrocks> to remove the dep on qt5
[12:14] <didrocks> so that we can have appmenu without bringing the whole qt4 and qt5 on the image
[12:14] <didrocks> so that's why :/
[12:14] <xnox> yeah, it is weird, it only _suggests_ qt5 libs.
[12:14] <didrocks> yep
[12:15] <didrocks> IIRC, that was that, was years ago (when appmenu was introduced)
[12:15] <didrocks> xnox: hum, all those plugin on i386 is worrisome
[12:15] <mdeslaur> I have a funny feeling this is going to break people
[12:15] <mdeslaur> (well, it already broke ubuntu-sdk)
[12:15] <didrocks> mdeslaur: yeah, and depends how long we are going to take before the transition ends
[12:16] <xnox> didrocks: i wonder if it's just a hint missing, or something like that.
[12:16] <mdeslaur> bug 1292487
[12:16] <ubot2> Launchpad bug 1292487 in libdbusmenu-qt (Ubuntu) "libdbusmenu-qt can't resolve symbols" [Undecided,New] https://launchpad.net/bugs/1292487
[12:17] <didrocks> xnox: yeah, can be, we need to try a chdist?
[12:18] <xnox> didrocks: right there are hints missing, you'd want to hint for e.g.
[12:19] <xnox> didrocks: signon-plugin-oauth2 to go in together with qtbase-opensource-src
[12:19] <didrocks> xnox: I never did that (only block/unblock) in britney, mind doing or guiding me? :)
[12:19] <xnox> didrocks: and i think that's it.
[12:19] <didrocks> xnox: you just apt-get install both btw to confirm it?
[12:20] <didrocks> mdeslaur: just for the note, if it's the only transient issue with this migration involving 122 packages, I will be happy ;)
[12:20] <xnox> yeah, they are installable. plus hints are not forcing anything, it's just telling britney to consider the packages together in the analysis. So it would still validate that they are installable.
[12:20] <didrocks> xnox: ok, I just:
[12:20] <didrocks> hint signon-plugin-oauth2 qtbase-opensource-src
[12:20] <didrocks> or something else?
[12:22] <xnox> didrocks: it's like this: easy ubuntu-settings/14.04.4 gnome-session/3.9.90-0ubuntu11
[12:22] <xnox> so:
[12:23] <xnox> didrocks: wait that will not work =)
[12:23] <didrocks> xnox: easy qtbase-opensource-src/5.2.1+dfsg-1ubuntu7 account-plugin-evernote/0+14.04.20140113.2-0ubuntu1?
[12:23] <didrocks> weird
[12:23] <didrocks> account-plugin-evernote is already in the release pocket
[12:24] <xnox> didrocks: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html  signon-plugin-oauth2  has not satisfiable dependencies on arm64.
[12:24] <didrocks> ah yeah, making sense that all plugins fail
[12:24] <xnox> didrocks: which i think means that sigon-plugin-oauth2 should be removed on arm64 from trusty-release.
[12:24] <didrocks> xnox: let me check rdepends
[12:24] <xnox> didrocks: or better, fixed.
[12:24] <didrocks> xnox: all that will be fixed in a second time
[12:25] <didrocks> let's get everything in, there is already a followup silo for the sdk
[12:25] <xnox> didrocks: so all are valid candidates, which is good, but signon-plugin-oauth2 on arm64.
[12:25] <didrocks> xnox: yeah, I didn't grep multiple times the file to get to that state TBH :)
[12:25] <didrocks> so account-plugin-tools
[12:25] <didrocks> ok, only ubuntu-touch as a rdepends
[12:26] <xnox> didrocks: account-plugin-tools is arch:all, that's fine for it to not be installable on one arch =)
[12:26] <didrocks> yeah, arch:all
[12:26] <xnox> and there is no ubuntu-touch on arm64.
[12:26] <didrocks> so ok, seems only signon-plugins-oauth2
[12:26] <didrocks> really? striking news! ;)
[12:27] <xnox> didrocks: do you want me to upload ubuntu-touch-meta which builds on arm64? i can totally do this +)))))))
[12:27] <didrocks> xnox: tsssssssss ;)
[12:27]  * xnox dch -i "Didrocks said I should do this..."
[12:27] <didrocks> ahah
[12:27] <xnox> i'll sponsor it with your name ! =)
[12:28] <didrocks> xnox: I bet you will be so evil to do that ;)
[12:28]  * didrocks flushed signon-plugin-oauth2
[12:28] <didrocks> ok, so arm64 will be happy
[12:28] <xnox> yeah, so next britney run, hopefully it will migrate.
[12:29] <didrocks> yeah, let's see ;)
[12:31] <didrocks> xnox: at least, when I had my block, it was easy to grep on "didrocks"
[12:49] <didrocks> common britney, refresh!
[12:49] <didrocks> come on*
[12:50] <xnox> 12:53?!
[12:50] <didrocks> xnox: prediction of 30 minutes + 21s? :p
[12:51] <xnox> didrocks: it will take more than 21s for britney to process the migration, if it migrates stuff =)
[12:51] <didrocks> xnox: yeah, so you mean the longer we wait, the more hopeful we can be? :p
[12:52] <didrocks> xnox: in case I removed the packages before it took them into account :p
[12:52] <xnox> not this time =(
[12:52] <xnox> the package is removed, yet britney still thinks it's out of date.
[12:52] <didrocks> argh, refreshed
[12:52] <didrocks> yeah
[12:53] <xnox> oh!
[12:53] <xnox> yeah =)
[12:53] <xnox> Valid candidate =)
[12:53] <didrocks> hum
[12:53] <didrocks> still failed
[12:53] <didrocks> failed: qtbase-opensource-src
[12:53] <xnox> SUCCESS (129/0)
[12:53] <didrocks> ah
[12:53] <xnox> loads of stuff did migrate.
[12:53] <didrocks> yeah :)
[12:53] <didrocks> why the stenza after then?
[12:54] <xnox> oh, there are NBS left around.
[12:54] <didrocks> xnox: I'm not sure to follow you where you are seeing that
[12:54] <xnox> didrocks: britney treis to remove "old packages" but that's mostly a lie in britneys brain, as those actions are not hooked up to launchpad api whats-so-ever.
[12:54] <didrocks> ahah
[12:54] <didrocks> ok, making sense
[12:56] <xnox> published in release pocket =) no idea if it timedout doing copies, thus one publisher run might be partial ;-)
[12:58] <xnox> didrocks: well done, sir! =) now the cleanup can proceed.
[12:58] <didrocks> xnox: thanks for your help as well!
[12:58] <didrocks> xnox: I'll still retake the list
[12:58] <didrocks> and grep against next -excuses
[12:59] <didrocks> to ensure nothing is left
[13:18] <xnox> didrocks: we definately need another publishing cycle, as quite a few things didn't manage to finish copying. e.g. http://people.canonical.com/~ubuntu-archive/nbs.html is full of lies =)
[13:18] <didrocks> xnox: yeah, seeing that, I've my grep ready as well :p
[13:18] <xnox> what do you grep and how? =)
[13:19] <didrocks> for p in `cat package_list`; do grep $p update_excuses.html; done
[13:22] <xnox> retrying qtmultimedia-oepnsource-src on powerpc, hopefully sagari will do better (e.g. the one test-suite failure is not seen in debian build)
[13:30] <didrocks> yeah :)
[14:01] <apw> it seems that something odd happened maintainer side for hv-kvp-daemon-init, and in 0.4 they inadvertantly reintroduced the i386 build and then removed it, this has triggered an NBS on i386 for the later versions
[14:10] <xnox> apw: affirmative.
[14:10] <xnox> didrocks: could you please remove  hv-kvp-daemon-init version 0.4ubuntu0 suite trusty-proposed arch i386
[14:10] <xnox> it's not-built-from source, yet we have no NBS report for things in -proposed.
[14:17] <xnox> infinity: didrocks: please promote qt3d-oepnsource-src binaries on arm64/powerpc/ppc64el into main where same binaries are in main on other arches. (e.g. all packages but qtdeclarative5-qt3d-plugin)
[14:17] <xnox> $ rmadison -S qt3d-opensource-src | grep trusty
[14:19] <seb128> xnox, looking
[14:19] <xnox> seb128: thanks.
[14:22] <seb128> xnox, done
[14:22] <xnox> seb128: thanks. both requests? =)
[14:23] <seb128> xnox, no, the nbs thing seemed lower priority :p
[14:24] <xnox> seb128: but but it's needed for Microsoft Hyper-V hypervisor support.
[14:24] <xnox> seb128: what can I do for you to process that one as well? =)
[14:25] <seb128> xnox, looking...
[14:25] <seb128> $ ./remove-package -s trusty-proposed -a i386 -m "NBS" hv-kvp-daemon-init
[14:25] <seb128> Removing packages from trusty-proposed:
[14:25] <seb128> 	hv-kvp-daemon-init 0.4ubuntu3 in trusty
[14:25] <seb128> 		hv-kvp-daemon-init 0.4ubuntu3 in trusty amd64
[14:25] <seb128> hum
[14:25] <xnox> no.
[14:25] <seb128> what did I do wrong? ;-)
[14:25] <xnox> $ rmadison -S hv-kvp-daemon-init | grep trusty
[14:25] <xnox>  hv-kvp-daemon-init | 0.3ubuntu9         | trusty           | source, amd64
[14:25] <xnox>  hv-kvp-daemon-init | 0.4ubuntu0         | trusty-proposed  | i386
[14:25] <xnox>  hv-kvp-daemon-init | 0.4ubuntu3         | trusty-proposed  | source, amd64
[14:26] <xnox> seb128: i only wanted the 0.4ubuntu0 and i386 removed.
[14:26] <seb128> oh, -b
[14:26] <seb128> xnox, I know, I was just wondering why it was listing amd64
[14:26] <seb128> I did "n" that btw
[14:26]  * xnox is not a trained AA at all, so i'm not sure about the utils much.
[14:27] <seb128> I got confused, change-override defaults to binaries
[14:27] <seb128> remove-package is the opposite, you need to -b
[14:27] <xnox> yeah, -b seems to do the right things.
[14:27] <seb128> $ ./remove-package -s trusty-proposed -a i386 -m "NBS" -b hv-kvp-daemon-init
[14:27] <seb128> Removing packages from trusty-proposed:
[14:27] <seb128> 	hv-kvp-daemon-init 0.4ubuntu0 in trusty i386
[14:27] <seb128> Comment: NBS
[14:27] <seb128> Remove [y|N]? y
[14:28] <seb128> xnox, ^ done
[14:28] <xnox> apart from: lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized, for me =)
[14:28] <xnox> seb128: yeah, looks good! thanks =)
[14:28] <seb128> yw!
[14:42] <cjwatson> xnox: FYI the touch-release people are only supposed to have permissions to block/unblock, not to apply arbitrary hints
[14:45] <xnox> cjwatson: ok, i thought didrocks was normal-release as well. I guess AAs are not actually included in ~ubuntu-release, despite the large overlap.
[15:09] <apw> seb128, thanks
[15:09] <seb128> yw!
[16:54] <infinity> Anyone object to me breaking our "never release on Fridays" rule for tzdata, so I don't forget about it later and anger Turkey? :P
[17:09] <ScottK> infinity: Please go ahead.
[17:29] <infinity> Have our tools become sentient?
[17:29] <infinity>   [ CI bot ]
[17:29] <infinity>   * fixes the segfault occuring when the scale factor is < 1.0 (LP:
[17:29] <infinity>     #1288166)
[17:30] <mdeslaur> oh wow, can I fork that for a CVE fixing bot?
[17:57] <dbarth> hey there
[17:58] <dbarth> slangasek: hi, i guess that will fall on your plate somehow, but i'm trying to make sure you guys are aware of the FFE request for Oxide
[17:58] <dbarth> on the desktop
[17:58] <dbarth> https://bugs.launchpad.net/libunity-webapps/+bug/1290535
[17:58] <ubot2> Launchpad bug 1290535 in webbrowser-app (Ubuntu) "[FFE] Webapps support for the new Oxide container" [Undecided,New]
[18:00] <dbarth> alex-abreu can fill you in later in the day if you need info/status
[18:07] <slangasek> dbarth: thanks for the info
[18:11] <xnox> infinity: yes they have. =) i've noticed a few uploads like that ;-)
[18:12] <xnox> infinity: at times, it steals my commits like that, because they are merged up due to conflicts and thus somehow the change gets attributed to the ci bot committer, instead of myself.
[20:42] <rsalveti> can someone help getting qtcreator-plugin-cmake promoted?
[20:47] <infinity> rsalveti: Yeahp.
[20:47] <infinity> But first, explain this:
[20:47] <infinity> +Depends: libc6
[20:49] <rsalveti> thanks
[20:49] <rsalveti> yeah, not sure yet
[20:49] <rsalveti> oh, it's indeed in the dep list of debian/control
[20:50] <infinity> rsalveti: Yes, that's just plain wrong.
[20:50] <rsalveti> indeed
[20:50] <infinity> rsalveti: Looks like dh_shlibdeps needs to be called to scan the plugin .so directory.
[20:50] <infinity> Let me experiment a tad.
[20:50] <rsalveti> great, thanks
[20:51] <infinity> Erm, lolz.
[20:51] <infinity> override_dh_shlibdeps:
[20:51] <infinity>         # Qt Creator does not have shlibs, so this hack is needed to build this plugin
[20:51] <infinity>         dh_shlibdeps -XlibCMakeProjectManager.so
[20:51] <infinity> And that's why it has broken deps.
[20:51] <infinity> WHY?
[20:52]  * infinity tests without that to see what they were trying to work around.
[20:53] <slangasek> is that a package in the archive and who can I have drawn and quartered?
[20:53] <infinity> slangasek: Yes, and pick someone.
[20:53] <infinity> slangasek: It's qtcreator-plugin-cmake
[20:54] <infinity> Looks like you get to stab Mirv.
[20:54] <slangasek> man
[20:55] <slangasek> infinity: how did you assign blame?  These are all ppa copies, so launchpad shows nothing of who did what. :P
[20:55] <infinity> slangasek: changelog.
[20:55] <infinity> Anyhow, this is what happens without the hack:
[20:55] <infinity> dpkg-shlibdeps: error: no dependency information found for /usr/lib/x86_64-linux-gnu/qtcreator/libExtensionSystem.so.1 (used by debian/qtcreator-plugin-cmake/usr/lib/x86_64-linux-gnu/qtcreator/plugins/QtProject/libCMakeProjectManager.so)
[20:55] <slangasek> am I looking at the wrong package?
[20:56] <infinity> Why the solution wasn't to FIX THE PACKGAE PROVIDING THE LIBRARY, I don't know.
[20:56] <slangasek> no, I'm sure I cut'n'pasted qtcreator-plugin-cmake right
[20:56] <slangasek> and bzoltan != Mirv
[20:56] <infinity> slangasek: https://launchpad.net/ubuntu/+source/qtcreator-plugin-cmake/3.0.1-0ubuntu4 ?
[20:56] <infinity> Looks Mirvy to me.
[20:56] <slangasek> oh, because my apt-get source didn't look at -proposed, I really should fix that
[20:57] <infinity> pull-lp-source, FTW.
[20:57] <infinity> Lets you get rid of deb-src lines in sources.list too, which is a big win.
[20:58] <slangasek> but then I have to trust https instead of gpg
[20:58] <slangasek> (how's that for an off-the-cuff post-hoc rationalization?)
[20:58] <Mirv> yep, me, the new upload just added the comment, and the manual dependency as suggested at ci-eng
[20:59] <Mirv> it's the same as lp:qtcreator-plugin-ubuntu, from where the SDK Team copied the packaging
[20:59] <infinity> Mirv: Really?  Who suggested a manual dep on libc6, so I can poke them with a broadsword?
[21:00] <infinity> It seems there are attempts all over here to shoot yourselves in the foot.
[21:00] <infinity> From qtcreator:
[21:00] <infinity> override_dh_makeshlibs:
[21:00] <infinity>         # qtcreator doesn't provide any public libraries
[21:00] <infinity> So, if it's not public, why are other packages linking to it?
[21:00] <infinity> If it is public, why are you skipping shlibs?
[21:01] <infinity> This is pretty black and white.
[21:05] <infinity> Mirv: So, I'm not entirely joking.  We should hunt down the origin of this manual libc6 dep and educate the person who was giving bad advice.
[21:05] <Mirv> infinity: http://irclogs.ubuntu.com/2014/03/14/%23ubuntu-ci-eng.html#t09:09
[21:05] <infinity> Mirv: And we also need to fix this "no shlibs for libraries that other packages are obviously linking with" mess.
[21:05] <Mirv> it was probably not very well studied suggestion
[21:05] <Mirv> within all the multitaskin at that point of time
[21:06] <Mirv> infinity: upstream doesn't support 3rd party plugins, so it's a hack made by sdk team to be able to have something to build against
[21:06] <Mirv> and to not need to ship the plugins in qtcreator source
[21:06] <infinity> Mirv: If these are pure plugins, and you expect the qtcreator dep to satisfy all the deps it needs, that might be fine, but you still don't need a libc6 dep.
[21:07] <infinity> Mirv: Unless you honestly think someone's going to sort out how to run dpkg and install qtcreator without having a C library installed.
[21:07] <ScottK> There's even a lintian check for this.  http://lintian.debian.org/tags/package-depends-on-hardcoded-libc.html
[21:07] <Mirv> yeah, it was substituting a lintian error with a warning
[21:08] <Mirv> I guess it was the lintian error that made didier want to push to change something, just that the something was worse than not doing it
[21:09] <infinity> Mirv: So, my take would be that qtcreator should have a shlibs that makes anything with a plugin dep depend on qtcreator >= $upstream, and then you could get all your deps from dpkg.
[21:09] <Mirv> anyway, bzoltan + zbenjamin can look at it next week
[21:09] <Mirv> a bug would be welcome, 11pm here
[21:09] <infinity> This is quite important, as a plugin could depend on OTHER external libraries, and you're now skipping resolving those.
[21:10] <infinity> I might do better than a bug, and instead submit patches.  We'll see how much my anger fuels me.
[21:10] <Mirv> thanks
[22:59]  * infinity keeps boggling at this packaging...
[23:00] <roaksoax> infinity: howdy! did you happen to upgrade the firmware on the P8?
[23:00] <infinity> +DEB_LDFLAGS_MAINT_APPEND  = -Wl,--as-needed
[23:00] <roaksoax> err
[23:00] <roaksoax> nevermind
[23:00] <infinity> ^-- If only that were the toolchain default or something.
[23:00] <infinity> roaksoax: The firmware I was asked not to upgrade?
[23:00] <infinity> Err, also, ECHAN.


[07:36] <mup> Bug #1707850 opened: [2.2] MAAS should not mark a node as "Deployed" when cloud-init has some failures <MAAS:New> <https://launchpad.net/bugs/1707850>
[08:06] <mup> Bug #1707850 changed: [2.2] MAAS should not mark a node as "Deployed" when cloud-init has some failures <MAAS:Won't Fix> <https://launchpad.net/bugs/1707850>
[10:47] <digv> which Minimum Kernel should I choose if I want 4.4.* kernel for Maas machine deployment?
[14:56] <pmatulis> 4.4?
[17:25] <mup> Bug #1707971 opened: MAAS becomes unstable after rack controller restart <cdo-qa> <cdo-qa-blocker> <foundation-engine> <MAAS:New> <https://launchpad.net/bugs/1707971>
[19:58] <mup> Bug #1707999 opened: pod VM fails to PXE boot after receiving multiple DHCP offers <cdo-qa> <cdo-qa-blocker> <foundation-engine> <MAAS:New> <https://launchpad.net/bugs/1707999>
[20:23] <danielsouzasp> hello guys, my company is looking for someone who has expirience with MAAS for a project, do you know someone?