[12:37] <Pici> updated !aptitude to mention multiarch issues.
[14:51] <IdleOne> oulu is a familiar nick
[14:53] <Myrtti> it's a city in Finland, probably where this person is from
[14:53] <Myrtti> judging from IP address
[14:53] <IdleOne> yeah, I meant more like the nick brings to mind bad feeling
[14:53] <Pici> IdleOne: you don't like Finland?
[14:53] <Myrtti> I've not seen it before
[14:54] <IdleOne> Pici: I have no dislike for any country. I also would like to visit finland at some point soon
[14:54] <Pici> IdleOne: I'm just joking :)
[14:54] <bazhang> helsinki is awesome
[14:54] <IdleOne> Pici: ino, me too :P
[14:55] <IdleOne> I read a friend is going to be moving there soon
[14:57] <IdleOne> We has logs for the UDS IRC session yesterday. I would like to see what horrible decisions were taken :)
[14:57] <IdleOne> ?
[15:02] <oCean> http://ubottu.com/uds-logs
[15:02] <tsimpson> also on irclogs.ubuntu.com
[15:02] <tsimpson> and audio on audio.ubuntu.com :)
[15:06] <IdleOne> it is a little confusing not having the audio and the text in sync
[15:13] <tsimpson> IdleOne: well, that very discussion takes place near the end of the session
[15:16] <IdleOne> tsimpson: sorry, which discussion?
[15:17] <tsimpson> about a better way to have all these things tied together
[15:17] <IdleOne> ah.
[15:17] <tsimpson> rather than having IRC + audio stream + pad, having it all in one place
[15:18] <IdleOne> that would be good. What about for replay after the fact though, would there be a way to listen/view the audio and text in sync?
[15:19] <tsimpson> I guess it would be possible, just probably non-trivial to implement
[15:19] <tsimpson> but AlanBell is the one to ask about that
[15:20] <AlanBell> I am?
[15:20] <IdleOne> you are now!
[15:20] <tsimpson> what's it called.. ether light?
[15:20] <IdleOne> you have been voluntold
[15:20] <AlanBell> yay
[15:20] <AlanBell> etherpad-lite
[15:20] <tsimpson> that one, yeah :)
[15:21] <IdleOne> basically we would need a video of the chat and etherpad with the audio track
[15:21] <AlanBell> audio and pad playback in sync, interesting idea
[15:22] <AlanBell> yeah, could be done
[15:22] <IdleOne> get on it!
[15:22] <tsimpson> I could see (in vague terms) that it could be possible, with HTML5 + JS one could connect the timing of the audio with timings of chat+edits
[15:22] <AlanBell> patches welcome
[15:22] <tsimpson> but, I'd not like to be the one to implement it
[15:22] <AlanBell> you don't need to connect the timings, just start at the same time and play in real time
[15:22] <IdleOne> AlanBell: I think canonical should get on the ball with this :)
[15:23] <tsimpson> AlanBell: well, I was also thinking about seeking
[15:23] <AlanBell> as long as you don't pause one of them
[15:23] <AlanBell> ah, seeking might be a challenge
[15:23] <tsimpson> meh, let's just write a flash applet :P
[15:23] <AlanBell> \o/
[15:23] <IdleOne> haha
[15:23] <Pici> flash :(
[15:24] <IdleOne> I'll be back before this banana hits the ground. ZOOOOM ZOOOOM ZOOOOOOOOOM.
[15:24] <AlanBell> audio.ubuntu.com is looking good this time
[15:25] <IdleOne> irc session is the 17:00 one right?
[15:27] <AlanBell> doesn't seem to be
[15:30] <AlanBell> http://audio.ubuntu.com/quantal/grand-ballroom-f/2012-05-10/11/grand-ballroom-f_2012-05-10_110001.ogg
[15:34] <AlanBell> there is a more detailed "etherpad-lite / OMG they are turning off IRC!!!/o\" session at 17:00 today, which is um, probably 01:00 UTC
[15:36] <tsimpson> should be 00:00 UTC
[15:38] <tsimpson> DST needs to go away, too much confusion in my head
[15:44] <bazhang> troll detected
[15:44] <bazhang> "sweetie"
[15:44] <Pici> yeah
[15:44] <Pici> Glad they're leaving.
[15:45] <AlanBell> thanks tsimpson
[16:57] <AlanBell> not at 17:00 it is at 16:15
[17:29] <jpds> http://is.gd/z9dg3z
[17:29] <jpds> This explains a lot.
[17:31] <IdleOne> jpds: WTF!!!
[17:33] <jpds> IdleOne: LOL: http://is.gd/ScjvI9
[17:37] <Pici> wow
[17:38] <IdleOne> that is not surprising though, many people are not very internet lingo savvy and use lol or wtf wrong
[17:38] <IdleOne> especially them old folks, like 40 year olds. that is old right?
[17:39] <IdleOne> by the way jpds I had no idea you felt this way. LOL to you too.
[17:42] <jpds> IdleOne: That was LOL haha.
[17:49] <Flannel> AlanBell: It's not "zomg theyre turning off IRC" it's "Why not integrate with IRC instead of supplanting it--that way people can still choose to use IRC if they desire"
[17:50] <Pici> Whats happening?
[17:51] <Flannel> Pici: I'm just replying to something from the scrollback
[18:57] <AlanBell> Flannel: yes, something like that
[18:57] <AlanBell> but we need people to make that happen, nobody has committed to putting in the effort on that task as yet
[19:35] <Flannel> AlanBell: of course, but it's a community-wide thing.  I'm not sure when the IRC Team became the guardians of UDS infrastructure; if we volunteered for it, I must've been absent that day.
[19:39] <IdleOne> agreed.
[19:40] <AlanBell> Flannel: well it is more me than the team
[19:41] <AlanBell> I presented etherpad 2 years ago at UDS for integration in summit and I wrote the meeting page bit of summit with the embedded pad
[19:48] <Flannel> AlanBell: Do you think etherpad development would've been better served with a separate meeting then?  Instead of trying to squeeze it into an IRC team meeting, give it its own title so interested parties can become involved.  As far as I can see, it wasn't even mentioned in the description of the IRC meetings.
[19:51] <guntbert> Hi hardworking ops  --  I'm still worrying about !clone. As aptitude is reported to not play nice with multiarch systems there seems to be a danger of damaging the "new" system. (but I have no idea at all how to accomplish the same without aptitude...)
[19:52] <IdleOne> thought pici added some info
[19:52] <IdleOne> !clone
[19:52] <IdleOne> !cloning
[19:53] <guntbert> !-cloning
[19:53] <Flannel> guntbert: What is a multiarch system?  I know what those words mean, but am not familiar with that term
[19:53] <IdleOne> !automate
[19:54] <IdleOne> Flannel: install ia32libs to 64 bit so you can install xchat-common:i386
[19:54] <guntbert> Flannel: as far as I understood ubuntu has done away with the 32bit/64bit separation, and therefore many packages are now suitable for both
[19:54] <IdleOne> so you can prefer 32bit app if you so chose
[19:55] <IdleOne> aiui
[19:55] <Flannel> That sounds like a horrible mess!
[19:56] <genii-around> Does the old way of dpkg --get-selections > file     .. dpkg --set-selections < file and then apt-get -u dselect-upgrade   still work?
[19:56] <IdleOne> genii-around: should
[19:57] <Pici> !aptitude
[19:57] <Flannel> IdleOne: will that have the same 32/64 problem?
[19:57] <IdleOne> Flannel: really don't know
[19:58] <Flannel> I'd rather stick with something with known problems instead of going to something with unknown problems :)
[19:58] <Flannel> since, as far as I know, the dpkg thing will still have the original issue of "now it thinks I explicitly want ALL these packages" instead of knowing what it brought in as a dependency, etc.
[19:58] <IdleOne> the devil you know...
[19:59] <jussi> doesnt the SW center now have some method of doing it?
[19:59] <IdleOne> it does
[19:59] <IdleOne> so did synaptic
[19:59] <jussi> so why dont we just describe that?
[19:59] <jussi> (for the clone factoid)
[20:00] <IdleOne> well, we should. cli purist will complain about the lack of cli command in the factoid
[20:00] <Flannel> Is that going to have the same multiarch problem?
[20:00] <IdleOne> that might be a good thing though if it is causing problems
[20:00] <Flannel> (also, it sounds like this needs to become a factoid pointing to a wiki page)
[20:01] <IdleOne> guntbert: you want to get on figuring the best way of doing this and editing the factoid?
[20:01] <Flannel> since it looks like we're going to wind up with multiple solutions, each of them imperfect in their own special way
[20:01] <IdleOne> or the best ways (plural)
[20:02] <guntbert> IdleOne: not really to be honest, my ability with apt & co is still, well very low
[20:02] <IdleOne> guntbert: can you provide the GUI way in Unity, or make a wiki page with screenshots?
[20:03]  * IdleOne is not running Unity
[20:04] <IdleOne> how hard is it to remember what apps you installed!
[20:04] <Tm_T> our guides should not use aptitude, but apt-get
[20:04] <guntbert> IdleOne: until now I didn't even know that there is a GUI way... -ah unity - I have it used just for a week after 11.10
[20:04] <Flannel> For the time being, lets add a warning to the factoid.  That way there's some sort of information about the potential for problems.
[20:04] <Tm_T> (if commandline tool is needed, that is)
[20:04] <IdleOne> Flannel: agreed.
[20:04] <Tm_T> Flannel: I would rather have it containing apt-get instead of aptitude
[20:05] <IdleOne> who has apt-fu to translate the aptitude command?
[20:05] <Flannel> Tm_T: well, dpkg had the "removes information" problem, so aptitude became the preferred method for this, because it worked.
[20:05] <Flannel> there is no apt-get command, it's dpkg.
[20:05] <Tm_T>  dpkg --get-selections > file     .. dpkg --set-selections < file and then apt-get -u dselect-upgrade
[20:05] <guntbert> IdleOne: apt-get has no "search" command
[20:05] <Tm_T> ah, yes
[20:05] <IdleOne> hmm
[20:05] <Tm_T> but anyway
[20:06] <IdleOne> back to providing a warning I guess
[20:06]  * Tm_T doesn't like unsupported package management tools
[20:06] <Tm_T> and I consider aptitude unsupported currently
[20:06] <Flannel> aptitude isn't unsupported, it's just not installed by default.
[20:07] <jussi> guntbert: apt-cache search
[20:08] <Tm_T> jussi: doesn't search by package state I think
[20:08] <Tm_T> gotta get some sleep, so good night (:
[20:08] <IdleOne> night Tm_T, sleep well
[20:08] <jussi> yeah, Im thinking similar. nini.
[20:08] <IdleOne> good night jussi
[20:09] <guntbert> apparently I cannot contribute to this discussion in a constructive way after igniting it - so I'll be on my way  :-)  have a nice time (and please edit !automate to point to !clone instead of !cloning)
[20:09] <guntbert> g'night
[20:10] <Flannel> !clone
[20:11] <Flannel> We still need to resolve it, but as a temporary warning....
[20:13] <AlanBell> Flannel: the etherpad thing does have a separate meeting, at 16:15 local time today. I also mentioned it at the end of the IRC meeting, and in more detail in the community round table and in quite a lot of other places
[20:13] <AlanBell> I didn't dedicate much time to it in the IRC team meeting, I think we talked about it in the 3 minute countdown
[20:14] <AlanBell> so that is 3 hours from now
[20:14] <Flannel> AlanBell: Ah yes, so it does.  I just heard you talking about it in the meeting yesterday, and apparently can't use my eyeballs.  I thought you were referring to the IRC meeting this morning.
[20:15] <AlanBell> no, the "IRC workshops" one today was about openweek and developer week


[15:39] <Radow> is their a simplified way to add the ubuntu studio packages to my ubuntu desktop install?
[22:18] <user42> can't dist-upgrade to 17.10, do i have to change something?
[22:18] <user42> update, upgrade, dist-upgrade, no new distro listed
[22:19] <krytarik> !upgradeofflts | user42: This?
[22:20] <user42> was 17.04 a LTS?
[22:20] <krytarik> No.
[22:22] <user42> ok, its running throug do-release-upgrade
[22:23] <user42> i wonder what exactly the difference to apt-get dist-upgrade is
[22:24] <krytarik> !dist-upgrade
[22:27] <user42> oh, k, thx
[22:28] <user42> ot: sometimes wireless is a problem, DLspeed: 1.4B/s - 12kb/s
[22:28] <user42> anyway thx for the help :D gn8
[22:28] <krytarik> Sure, have fun!


[15:25] <xnox> jodh: I am at a loss how come that test passes on a real system but not in the vm as started by run-adt-test.
[15:26] <jodh> xnox: alas writing the code is easy in comparison to diagnosing test failures :)
[15:27] <jodh> xnox: we need to identify the test that creates the file in question and see why it isn't being removed as expected.
[15:27] <jodh> xnox: you could always compare the autopkgtest env with non-VM env with... procenv :-)
[15:28] <xnox> the test is correct.
[15:28] <xnox> let me add a print statement to see if it takes the assumed code path in the vm.
[15:32] <jodh> xnox: actually - remember to take care with inserting any debug code since you're in a TEST_ALLOC_FAIL() block and nih_debug et al allocate memory (http://upstart.ubuntu.com/cookbook/#gotchas). You may need to use a basic write(2).
[15:33] <xnox> thanks =)
[15:35] <jodh> xnox: just a sec - that test looks wrong - there is no call to waitpid() in the non-failure scenario.
[15:37] <jodh> xnox: we should wait for the pid, then delete the log file in dirname/<job>.log if job_process_spawn() did not fail.
[15:39] <xnox> jodh: I thought that the point of the test is that allocation_fails to succeed the test.
[15:41] <xnox> unless I got it utterly wrong.
[16:45] <jodh> xnox: http://upstart.ubuntu.com/cookbook/#test-alloc-fail is a bit of a 'mind bender', but the loop _will_ succeed once. And that is the problem iteration - there is a race.
[16:46] <jodh> xnox: so, I suspect if you waitpid() when test_alloc_failed is not set, you'll see the test fail on all systems since the rmdir will fail as by that time, the job has finished and written the log file in the directory the test is attempting to delete.
[16:46] <jodh> xnox: so, the correct fix I think is: waitpid(), then unlink the log file for the non-failure iteration.
[16:48] <xnox> jodh: ok. I understand your solution. Can you explain what the test is testing for in this case then?
[16:48] <jodh> xnox: you'll need to construct the name of the logfile using nih_local and nih_sprintf(). See examples in the code relating to the 'expected' variable.
[16:50] <jodh> xnox: well it's supposed to be testing that a simple job which produces output can be handled in all error scenarios. But it really could do with a bit of improvement.
[16:52] <jodh> xnox: namely, we should assert that on success, that the log file is written and the contents are correct.
[16:52] <xnox> jodh: ok. Thank you for the information, I will try to poke it.
[16:52] <jodh> xnox: so you could add a call to CHECK_FILE_EQ().
[16:53] <jodh> xnox: and feel free to add some more comments if you want ;-)
[16:53] <jodh> xnox: thanks


[00:02] <micahg> asac: is FF3.5b4 being backported to Jaunty?
[00:08] <BUGabundo> micahg: wasn't it already?
[00:08] <BUGabundo> oh nevermind I just use PPAs
[00:08] <BUGabundo> so got confused
[00:08] <micahg> BUGabundo: no, the version in jaunty is pre4
[00:09] <micahg> preb4
[00:09] <BUGabundo> ah
[00:09] <BUGabundo>   Installed: 3.5~b5~hg20090503r25075+nobinonly-0ubuntu1~umd1
[00:09] <BUGabundo>   Installed: 3.6~a1~hg20090503r27958+nobinonly-0ubuntu1~umd1
[00:10] <micahg> you're using a ppa
[00:10] <micahg> https://launchpad.net/ubuntu/+source/firefox-3.5
[00:10] <BUGabundo> micahg: I know! I told you that on the second line :)
[00:10] <micahg> yep
[01:16] <micahg> BUGabundo: I found out why I can't get it
[01:17] <micahg> the packages didn't build yet :)
[03:36] <slavsun> hi
[03:36] <slavsun> Does anyone know how to add a field (for example Middle Name) to the address book in Thunderbird ?
[03:36] <slavsun> is it possible ?
[10:20] <asac> slavsun: not without looking. sorry.
[10:20] <asac> if you find out let us know ,)
[10:26] <slavsun> it seems to me that it is impossible
[10:26] <slavsun> and very difficult thing to implement
[10:26] <slavsun> )
[10:27] <asac> slavsun: so you want to implement that?
[10:27] <asac> i dont think its that difficult ;) ... but would have to look
[10:30] <slavsun> I'm not a programmer unfortuately
[11:55] <asac> welcome dpm_
[11:56] <dpm_> hi asac :)
[11:56] <asac> did you get the mail I just CCed you on?
[11:56] <dpm_> just checking...
[11:56] <asac> hmm
[11:56] <asac> seems i have mail problems again
[11:56] <asac> argh
[11:58] <dpm_> asac: I got the message, thanks. It seems your mail is ok
[12:01] <asac> dpm: i fixed it ;)
[12:02] <dpm> good ;)
[12:55] <gnomefreak> how do you find out what kernel point release you are on?
[13:11] <asac> gnomefreak: uname -a
[13:11] <asac> gnomefreak: or look at the package version
[13:11] <asac> but to see what you are currently running use uname -a
[13:27] <gnomefreak> asac: uname -a doesnt give me 2.6.28-11.30-generic 2.6.28-11-generic
[13:28] <gnomefreak> that .30 or .42 is what i need to find out
[13:28] <gnomefreak> maybe synaptic can tell me
[13:29] <gnomefreak> i have a eeling .30 is what is cuasing these system halt problems
[13:29] <gnomefreak> s/eeling/feeling s/cuasing/causing
[13:33] <gnomefreak> it shows -11.42 but that cant be right this is a clean install never touched until now installed using ISO from april 11th
[13:53] <gnomefreak> ha it is the kernel causing this issue
[13:57] <gnomefreak> asac: post something to indenti please it seems gwibber is confused between indenti and twitter the colors are all wrong and random, im going for a smoke
[13:59] <asac> hmm
[13:59] <asac> not sure i am running plain jaunty version
[14:03] <gnomefreak> i had upsate in jaunty to 2.6.28-11.15 from .14 but .14 shits down properly i didnt update because i need a working test case
[14:05] <gnomefreak> damn lets fix that. s/upsate/update s/shits/shuts
[14:05]  * gnomefreak needs spell check in irssi
[15:12] <gnomefreak> ok it looks like my first eye surgery will be on june 8th than i have to wait at the very least 2 weeks before they do other eye depending on how i heal. so month of june i will be ina nd out depending on how i see. possibly into july
[15:13] <gnomefreak> people need to stop using google-agenda-provider it is broken or it just breaks sunbird/lightning builds
[15:41] <asac> gnomefreak: eye surgery? is that a laser thing?
[15:42] <asac> or something caused by accident?
[15:42] <gnomefreak> asac: no its cataracs(sp) remove lens and replace it
[16:03] <tonyyarusso> Could someone please explain to me what warranty the "This might void your warranty!" warning on about:config is referring to, considering that the MPL reads "COVERED CODE IS PROVIDED UNDER THIS LICENSE ON AN "AS IS" BASIS, WITHOUT WARRANTY OF ANY KIND< EITHER EXPRESSED OR IMPLIED,..."?
[16:04] <asac> tonyyarusso: well. its just a warning and has probably no real legal effect
[16:05] <tonyyarusso> but why on earth is it there?
[16:05] <asac> i guess its just a wording folks thought was appropriate
[16:05] <asac> tonyyarusso: to make a point
[16:05] <tonyyarusso> hmmm
[16:05] <asac> users reading that might understand "yeah, this is bad"
[16:05] <micahg> asac: is there anything I can to do help with the build for ff3.5b4?
[16:06] <asac> micahg: for jaunty?
[16:06] <tonyyarusso> Might just be me, but I think it would make a ton of sense to come up with a wording that doesn't involve the word "warranty".  Otherwise you may have to deal with the unintended consequence of people getting the impression that if they don't mess with it they DO have a warranty, you know?
[16:06] <micahg> either
[16:06] <asac> micahg: its already in karmic
[16:06] <asac> i plan to push that to -proposed or -security ... have to decide still
[16:07] <gnomefreak> anyone using seamonkey 1 and or 2 i need somethi9ng tested
[16:07] <micahg> It didn't build in amd64
[16:07] <micahg> https://launchpad.net/ubuntu/karmic/+source/firefox-3.5/3.5~b4+nobinonly-0ubuntu1
[16:07] <asac> tonyyarusso: could be. personally, i dont have a strong opinion about this. imo its an upstream decision
[16:07] <asac> if you think its bad filing a bug upstream would be appropriate with better suggestions
[16:07] <tonyyarusso> asac: Fair enough.
[16:08] <asac> micahg: yeah. probably a transistional issue. let me retry
[16:08] <micahg> ok
[16:08] <micahg> thanks
[16:08] <micahg> I can install from karmic repos
[16:08] <tonyyarusso> ("But yapping here or using Launchpad is so much easier than tracking down where to do it upstream!")
[16:08] <gnomefreak> may cause bugs that mozilla cant fix ;)
[16:08] <micahg> once it's rebuilt
[16:08] <gnomefreak> asac: ubufox doesnt give that dialog?
[16:08] <asac> micahg: did xulrunner-1.9 build?
[16:09] <asac> tonyyarusso: file a bug against bugzilla.mozilla.org ... against firefox -> general ;)
[16:09] <micahg> yep
[16:09] <micahg> oops
[16:09] <micahg> wrong version
[16:09] <micahg> it's <IP_ADDRESS>
[16:10] <micahg> 1.9.1 is the one for 3.5
[16:10] <micahg> nope, not for amd64
[16:10] <asac> yeah
[16:11] <gnomefreak> failed for 64bit and built for rest of archs?
[16:11] <micahg> http://launchpadlibrarian.net/26299637/buildlog_ubuntu-karmic-amd64.xulrunner-1.9.1_1.9.1~b4%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:11] <micahg> no, not all of the archs, just i386 and lpia
[16:12] <gnomefreak> oh
[16:12] <micahg> gnome and gtk deps are out of date
[16:12] <gnomefreak> its deps not xulrunner
[16:12] <micahg> right
[16:12] <micahg> or so it seems
[16:13] <gnomefreak> karmic has these versions it seems so maybe its just PPA that failed let me check all of them
[16:15] <gnomefreak> the versions are too high karmi has lower versions
[16:16] <micahg> so how did i386 and lpia build?
[16:16] <gnomefreak> they should be >= 2.24 or around that anyway
[16:17] <gnomefreak> micahg: not sure that is a goo question but if you policy each one you will see karmic versions are 2.24 where the ones in PPA are 2.13 or 2.1*
[16:18] <gnomefreak> libgnomecanvas2-dev should be 2.26.0-1 not >=2.6 just one exampler
[16:18] <gnomefreak> -r
[16:19] <asac> micahg: ok all builds are retried
[16:19] <gnomefreak> those need to be fixed in the gtk and gnomeui libs
[16:19] <asac> if they fail again let me know
[16:19] <gnomefreak> asac: they willl unless you changed something
[16:20] <asac> gnomefreak: the failure is understood
[16:20] <gnomefreak> >= 2.6.0 is greater than 2.26
[16:20] <asac> no need to investigate
[16:20] <asac> it was a temporary issue
[16:20] <gnomefreak> oh
[16:20] <asac> libcairo-dev not being fulfillable because they were in universe
[16:20] <asac> thats fixed afaik and so hopefully respin now works
[16:21] <gnomefreak> ah ok
[16:21] <gnomefreak> that makes sense
[16:22] <gnomefreak> i didnt look high enough before
[16:24] <gnomefreak> asac: ment to ask where would {python:version} get its version from? what source file
[16:24] <gnomefreak> well for that fact any {*:version} depend
[16:28] <gnomefreak> yes i know python may have a different file listing them but i am not seeing it
[16:30] <gnomefreak> i would have thought it would use version installed on system
[16:52] <micahg> what type of info should I request for bug 367706
[16:53] <micahg> do I need to start with a backtrace?
[16:53] <asac> micahg: that should be fixed by now
[16:53] <asac> micahg: we had a problem with toolchain when karmic opened
[16:53] <micahg> updating packages now
[16:54] <asac> micahg: hmm. but user says its jaunty
[16:54] <asac> micahg: we need a strace -f -eopen firefox 2>&1 | tee /tmp/ffox.log.txt
[16:54] <asac> i have the feeling it pulls in some files the user installed somewhere in the /usr hirarchy manually at some point
[16:55] <micahg> ok
[16:55] <micahg> asac: just have the user attach?
[16:56] <asac> micahg: yeah. ask him to start firefox like that and attach the log after it crashed
[16:56] <asac> besides from that bus errors are really rare on x86 architectures
[16:56] <asac> either its a complete messed up binary
[16:56] <asac> or its a hardware issue usually
[16:57] <micahg> oops
[16:57] <micahg> should have had him do apport collect as well so we know what version
[16:57] <asac> micahg: maybe. i think the strace will show that he is running something messed up
[16:57] <micahg> ok
[16:58] <micahg> I'll wait and see
[16:58] <asac> either a manually installed firefox ... or he has some locally installed libs and so on
[16:58] <micahg> strace will show that?
[16:58] <asac> micahg: the strace command above shows all the files firefox opens during its run ... so yeah it will reveal what the user is running
[16:58] <asac> or if the user has libs in /usr/local or something
[16:59] <asac> micahg: try it ;)
[16:59] <micahg> wow, that's a cool tool
[16:59] <asac> its often helpful if things dont go away with fresh profile and still sound too fatal to be true
[16:59] <asac> i mean if it was a real issue then we would get flooded by bugs ;)
[17:02] <micahg> indeed
[17:02] <micahg> what's the difference between strace and backtrace?
[17:05] <asac> micahg: strace lets you monitor syscalls
[17:05] <asac> backtrace is a way to look at the call stack of a program
[17:05] <asac> which is a snapshot
[17:05] <asac> usually at the time a crash happens
[17:05] <asac> but you can also gdb into a program and get a backtrace at any point of time
[17:05] <asac> micahg: syscalls are simplified speaking the communication between userspace (program) and kernel
[17:06] <asac> so with strace you can guess what the program is doing
[17:07] <micahg> ok, that's good to know
[17:11] <asac> for us its usually just useful to see which files the firefox actually uses
[17:11] <asac> you can find out if user has some bogus flashplugins installed somewhere and so on
[19:35] <micahg> asac: when I tried to upgrade FF3.5, it didn't require the new xulrunner
[21:04] <micahg> asac: when I tried to upgrade FF3.5, it didn't require the new xulrunner
[21:08] <asac> micahg: yeah
[21:08] <asac> does it work anyway?
[21:08] <micahg> I didn't try
[21:08] <asac> we didnt bump minimum version i think
[21:08] <micahg> I wanted to check with you first
[21:08] <asac> which hopefully is ok
[21:08] <micahg> well, minimum is 1.9.1~b4~
[21:09] <micahg> so it didn't ask me to upgrade from preb4
[21:09] <asac> yes. but does firefox-3.5 stil start/work ?
[21:09] <micahg> I'll try it
[21:09] <micahg> hold on
[21:09] <asac> if its broken we should have bumped the minimum version
[21:09] <asac> otherwise its ok to not bump the minimum version
[21:09] <asac> overly tight dependencies are not really good practice usually
[21:10] <micahg> I thought FF and xulrunner were tight though?
[21:11] <micahg> This is a nice touch: Please restart all running instances of firefox-3.5, or you will experience problems.
[21:11] <micahg> but, I think maybe it should actuall pause the install until the user confirms
[21:11] <micahg> I fyou use the GUI install, you won't even see that line
[21:13] <micahg> all the major stuff works
[21:13] <micahg> but, I would think I want the fixes in xulrunner as well
[21:13] <micahg> isn't that the core for ff?
[21:21] <asac> micahg: in our main browser with ubufox we display a notificatrion "restart" and button to restart
[21:22] <micahg> ok, cool, but ubufox doesn't work on 3.5 yet ;)
[21:22] <asac> micahg: if you have ubufox, try sudo touch /var/lib/update-notifier/user.d/firefox-3.0-restart-required
[21:22] <asac> micahg: no its not compatible yet. my fault
[21:22] <micahg> that's ok
[21:22] <micahg> just want to make sure it's in teh final version
[21:23] <micahg> oops
[21:23] <micahg> I just installed xulrunner-1.9.1~b4
[21:23] <micahg> Could not find compatible GRE between version 1.9.1b4pre and 1.9.1b4pre.
[21:24] <asac> micahg: did the install finish?
[21:24] <micahg> yep
[21:24] <asac> once ~b4 is completely installed it should work
[21:24] <asac> hmm
[21:24] <yamo> hi
[21:24] <asac> well firefox needs to be ~b4 too
[21:24] <asac> but we have no real mechanism except Breaks: to enforce rdepends
[21:24] <micahg> both are
[21:24] <asac> which causes lots of collateral damage
[21:24] <asac> so we dont do that
[21:25] <asac> micahg: are you sure it still happens after all has finished?
[21:25] <micahg> I think it's a config issue in the xulrunner package
[21:25] <micahg> Could not find compatible GRE between version 1.9.1b4pre and 1.9.1b4pre.
[21:25] <micahg> they're the same
[21:25] <micahg> and not the version I have anymroe
[21:25] <asac> micahg: dpkg -L xulrunner-1.9.1 | grep gre.d
[21:25] <asac> please paste the content of the file that comes out of that
[21:26] <micahg> /etc/gre.d
[21:26] <micahg> /etc/gre.d/1.9.1b4.system.conf
[21:26] <micahg> oops
[21:26] <micahg> sorry
[21:26] <asac> the content?
[21:26] <micahg> [1.9.1b4]
[21:26] <micahg> GRE_PATH=/usr/lib/xulrunner-1.9.1b4
[21:26] <micahg> xulrunner=true
[21:26] <micahg> abi=x86_64-gcc3
[21:26] <asac> hmm
[21:26] <asac> yeah
[21:26] <asac> messy
[21:26] <asac> so we should have bumped the build-depends lower version
[21:26] <asac> of firefox
[21:26] <asac> too bad
[21:27] <micahg> no, this is after I upgrade xulrunner
[21:27] <micahg> is there something else I need to upgradE>
[21:28] <micahg> both xulrunner and FF3.5 are at b4
[21:28] <asac> micahg: no. the firefox-3.5 build is messed up because we dont have opened up the maxVersion yet
[21:28] <micahg> ah
[21:28] <micahg> ok
[21:28] <asac> micahg: edit /usr/lib/firefox-3.5b4/application.ini
[21:29] <asac> and change maxVersion
[21:29] <micahg> http://www.mozilla.org/projects/firefox/3.5b4/whatsnew/
[21:29] <micahg> worked :)
[21:30] <asac> micahg: ok uploading
[21:30] <micahg> I've gotta go
[21:30] <micahg> I can do more testing tonight
[21:30] <micahg> mail me from LP if you need me to check anything else
[21:31] <asac> micahg: sure. dont know if there is anything to test for today though
[21:31] <micahg> ok
[21:31] <micahg> tytl
[21:31] <micahg> ttyl
[21:31] <asac> cu
[21:31] <micahg> thanks for the help
[21:32] <micahg> I'm assuming this is better than filing bugs?
[21:32] <asac> sometimes the turnaround is quicker
[21:32] <micahg> ok
[21:32] <asac> if its something like this min/max version thing i certainly want to know in person ;)
[21:32] <micahg> gtg
[21:32] <micahg> ok
[21:32] <micahg> will keep in mind
[21:47] <asac> micahg: are you subscribed to the mozilla-bugs mailing list?
[21:48] <asac> micahg: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mozillateam-bugs
[22:42] <jcastro> asac: check this out yo: http://code.google.com/p/gears/issues/detail?id=335
[22:42] <jcastro> asac: so I was thinking a nice gears/prism bundle for karmic would be awesome.
[22:45] <asac> jcastro: let me puncture this potential mess ;)
[22:46] <asac> to see how much blood comes out of it
[22:46] <BUGabundo> cwillu: ping
[22:46] <jcastro> asac: heh, yeah
[22:47] <jcastro> asac: I got it all working manually before I moved to 64 bit
[22:47] <asac> what i see still looks insane ;)
[22:47] <jcastro> asac: so theoretically it works
[22:47] <asac> the svn has a full copy of all libs in the world ;)
[22:47] <BUGabundo> LOL
[22:47] <BUGabundo> uau
[22:47] <jcastro> asac: so it's like all the other google stuff then. :p
[22:47] <BUGabundo> now I know where to look when I need one
[22:47] <asac> jcastro: yeah. actually i think the gears tree is the chromium tree
[22:48] <jcastro> I think it is too
[22:48] <asac> or read somewhere that the copied the gears tree to work on chromium ;)
[22:48] <asac> so seems at least they noticed that maintaining duplicates is a mess ;)
[22:48] <asac> A    gears-read-only/third_party/gecko_1.8/osx/gecko_sdk/include/private/pprthred.h
[22:48] <asac> lol
[22:49] <asac> there is full gecko_1.8 ;)
[22:49] <asac> aka ffox 2
[22:49] <asac> oh false alert ... its just the sdk
[22:49] <jcastro> look at the things you go through to bring offline gmail and calendar to the masses!
[22:50] <asac> hmm
[22:50] <asac> i will add that to the mozilla related karmic list i guess
[22:50] <asac> will the svn checkout ever end?
[22:50] <jcastro> <3
[22:50] <asac> i guess i can get a beer first
[22:51] <asac> at least its past gecko1.9 now ;)
[22:52] <asac> jcastro: so has chrome this gears thing integrated by default?
[22:52] <asac> do you know?
[22:52] <jcastro> yes
[22:52] <jcastro> but it doesn't work in linux yet
[22:52] <jcastro> so if you go into chromium and try to enable offline access it doesn't work
[22:57] <asac> yeah
[22:57] <asac> ok
[22:57] <asac> just was wondering in general
[22:58] <jcastro> asac: I think a nice offline-capable thing for laptops would be compelling
[22:59] <jcastro> asac: then we can just avoid the evolution/thunderbird conversations!
[23:00] <BUGabundo> eheh
[23:01] <BUGabundo> but those Mozilla already allows us to even set FF to use NM offline state?
[23:09] <asac> BUGabundo: dont understand what you mean
[23:09] <jcastro> yeah dude seriously
[23:09] <asac> BUGabundo: ffox 3 has offline state detection through NM
[23:10] <asac> BUGabundo: ffox 3.5 and later has it disabled by default
[23:10] <asac> thats upstream decision not our
[23:10] <asac> jcastro: whats the gmail market share? are there other webapps than google ones that support gears already?
[23:10] <BUGabundo> asac: I know. that's why I stated if upstream reverted
[23:10] <jcastro> I don't know, do you want me to find out?
[23:10] <jcastro> the other one would be calendar
[23:11] <BUGabundo> asac: WP does and a few others
[23:11] <jcastro> that are packaged via prism in the archive I mean
[23:11] <asac> jcastro: well. if its just google, the its just a missing feature ... if the world started using this then we block innnovation ;)
[23:11] <jcastro> oh, other sites use gears, I was talking about the stuff that's in the archive already that can use it
[23:11] <asac> BUGabundo: upstream reverted because there were too many loud voices complaining that NM tells offline if they dont use NM
[23:12] <BUGabundo> asac: wasn't that a 3.0.x bug and latter fixed?
[23:12] <asac> BUGabundo: no, firefox later has online/offline detection turned off
[23:12] <asac> i dont call that a fix
[23:12] <asac> they just stopped innovate in that area ... which needs to be fixed by providing something better than NM for online/offline detection
[23:13] <BUGabundo> ok
[23:13] <BUGabundo> good to know
[23:13] <BUGabundo> now I'll stop nagging, before jcastro gets even madder at me ;)
[23:14] <jcastro> I'm not mad, I just can't understand anything you say
[23:14] <jcastro> asac: I'm prepared to convince you at UDS with beers as to why this is a good idea
[23:15] <asac> jcastro: its a great idea ;) ... the problem is that the resources are finite ... i hope we can put this under the chromium umbrella as some parts of third_party definitly needs to be figured there too
[23:15] <jcastro> maybe we can build it out of the chromium tree or something
[23:15] <jcastro> cool, I just wanted it on your radar to discuss at UDS
[23:16] <jcastro> so you can tell me no in person, heh
[23:17] <asac> if we could get rid of the gecko sdk copies we would manage to eliminate 300M from the tarball ;)
[23:17] <asac> thats about half of the size
[23:17] <asac> from what i see that seems doable and even upstreamable i guess
[23:17] <BUGabundo> jcastro: really? is my written English *that* bad? I know that sometimes I don't express my self clearly, but that statement makes me wonder where the prob is!
[23:18] <asac> maybe we can get rid of the v8 thrid party tree which is 158M
[23:18] <asac> ;)
[23:18] <asac> this probably isnt used for the xulrunner build anyway
[23:18] <asac> (i hope)
[23:19] <asac> holy crap ... why does gears ship sound stuff?
[23:19] <asac> jcastro: ? did you ever hear any sound comning out of it ;)
[23:25] <BUGabundo> nope
[23:25] <BUGabundo> asac: more probs for the audio team ? LOL
[23:26] <dtchen> please no.
[23:29] <BUGabundo> dtchen: ehehehehe
[23:37] <asac> i enjoy great sound after updateing to proposed
[23:37] <BUGabundo> asac: great
[23:37] <BUGabundo> didn't it already hit -updates?
[23:39] <asac> not sure ;)
[23:40] <dtchen> asac: your symptoms were likely resolved due to linux, not really pulseaudio
[23:40] <dtchen> unfortunately, so many HDA controllers are broken. what constituted an improvement for you was a nasty regression for others.
[23:41] <asac> hmm
[23:41] <BUGabundo> dtchen: eheh
[23:42] <dtchen> asac: see /proc/version_signature
[23:44] <asac> yeah. i didnt doubt i got the fix through linux
[23:59]  * asac out for today


[06:00] <mborzecki> morning
[06:39] <zyga> Hey mborzecki
[06:42] <mborzecki> zyga: hey
[06:42] <mborzecki> zyga: see you've had a productive weekend?
[06:49] <zyga> Busy on my bije
[06:49] <zyga> Bike
[06:49] <zyga> I did 27km yesterday
[06:49] <zyga> Other than that just house work :-)
[06:51] <zyga> How was your weekend
[07:05] <mborzecki> zyga: quite packed, didn't manage to do do anyting i planned, but did plenty of unplanned stuff
[07:09] <mborzecki> zyga: oh, and finally was able to try the kimchi i made, turned out quite good :)
[07:10] <zyga> This week is bug fix week for me
[07:10] <zyga> Plenty of little things to resolve
[07:10] <zyga> I will be in the office before 9:30, I still have one kid to handle and send to school
[07:11] <mborzecki> btw. shouldn't we update the opensuse images to 15.1 now?
[07:12] <zyga> Yeah
[07:15] <mborzecki> again, 2019-03-25 06:27:04 Error preparing google:opensuse-15.0-64 :
[07:15] <mborzecki> it'd gcc now, https://paste.ubuntu.com/p/KRpjVpwndT/ wtf?
[07:16] <mborzecki> we're using zypper in -y, that should be non interactive
[07:16] <mborzecki> maybe we should allow downgrades?
[07:35] <mborzecki> mvo: morning
[07:36] <mvo> hey mborzecki
[07:36] <mborzecki> https://github.com/snapcore/snapd/pull/6644 simple PR <--- should fix opensuse package installs
[07:36] <mborzecki> btw. github triggers don't work anymore?
[07:36] <mvo> mborzecki: looking
[07:36] <mvo> mborzecki: oh?
[07:36] <mvo> mborzecki: how do you mean they don't work anymore? manual trigger? or travis picking up tests on changed prs?
[07:37] <mborzecki> mvo: or just mup_ is silent
[07:38] <mvo> mborzecki: aha, mup probably unhappy
[07:38] <mvo> mup_: hi
[07:39] <mvo> mborzecki: yeah, I think mup_ needs a restart, maybe niemeyer can restart mup for us :)
[08:04] <pstolowski> morning
[08:05] <mborzecki> pstolowski: hey
[08:11] <zyga> back in the office
[08:11] <zyga> how are you chaps?
[08:14] <mvo> hey zyga and pstolowski
[08:14] <mvo> zyga: good, good!
[08:17] <mborzecki> https://status.opensuse.org/ says there is partial outage of mirroring infra, but it's nto clear what that means exactly
[08:18] <mborzecki> isn't opensuse using metalink now?
[08:19] <mvo> iirc yes
[08:21] <mborzecki> ehh, so zypper times out on gcp, but works just fine locally, either a different mirror, or gcp has some caching behind the scenes
[08:26] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6485/files#r268526837
[08:28] <abeato> mvo, morning! is the fix for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728 in the core snap already?
[08:29] <mborzecki> zyga: adding the file is too simple :)
[08:29] <zyga> mborzecki: wrong coment
[08:29] <zyga> mborzecki: the one at the top
[08:29] <zyga> I'm not talking about the one 20 days ago
[08:29] <mborzecki> ah, i see now
[08:33] <mvo> abeato: it was initially, the backport of #8803 - however when we did a SRU validation we noticed that it breaks (segfaults) under some circumstance, this is an upstream bug and lead to PR#11121 which was a bit harder to backport. I just finished the xenial build and will now run the package against our autopkgtests, if that is successful I will push to the PPA and for the SRU
[08:33] <mvo> abeato: sorry that it takes a bit, its delicate code and the "heart" of systemd (deeep in the job handling) so we are a bit cautious
[08:34] <abeato> mvo, nw, indeed it is something to be very careful about, thanks
[08:34] <mvo> abeato: do you already get asked? I will update the bug with the info here
[08:35] <mborzecki> zyga: hm maybe i should just drop that last commit, too many things to check to find out whether snapd or core is used, extracting directly from source does away with all this
[08:35] <abeato> mvo, not yet, but maybe today they were going to ask, so I wanted to know the current status
[08:35] <zyga> mborzecki: shall we prototype "snap tool snap-{confine,seccomp,discard-ns}
[08:35] <zyga> I would love not to have to source dirs.sh
[08:38] <mvo> abeato: yeah, the updated debdiff for xenial should be in the SRU bug today and I think we will push it to the "edge" core snap for testing
[08:38] <abeato> mvo, nice!
[08:38] <mborzecki> zyga: would that work reliably with core.experimental.snapd-snap?
[08:40] <mvo> abeato: I will also test i386 with spread, for 8803 this was the one where the segv manifested itself
[08:43] <mborzecki> hmmm https://forum.snapcraft.io/t/gadget-snaps-for-mtd-devices/10554
[08:43] <zyga> mborzecki: I saw that
[08:43] <abeato> hm, interesting that it was in i386, was that second issue something provoked by the first change or something completely unrelated?
[08:44] <zyga> afaik not supported :/
[08:44] <mborzecki> zyga: yeah, we had a similar issue with mender, started with just block device support, but then people came asking for mtd
[08:45] <zyga> the only way I would see this work is ubifs or something simialar to map mdt to block devices
[08:45] <mborzecki> mhm
[08:45] <mborzecki> even some of the implicit structure labels would make sense if aplied to volumes
[08:50] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6629#pullrequestreview-218199245
[08:51] <pstolowski> zyga: ty!
[08:51] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6634#issuecomment-476095124
[09:11] <mborzecki> arrrgh Package glibc-32bit-2.26-lp<IP_ADDRESS>.x86_64 (openSUSE-Leap-15.0-Update) seems to be corrupted during transfer. Do you want to retry retrieval?
[09:12] <pedronis> pstolowski: hi, I had to contracdict a comment zyga made in 6629
[09:12] <pstolowski> pedronis: just saw it, sure, thanks!
[09:39]  * Chipaca ⇝ more coffee
[09:41]  * tobias_ says hi
[09:51] <thresh> Wimpress, ping rpi & vlc
[09:52] <Wimpress> thresh: o/
[09:53] <Wimpress> Building VLC for the Pi requires two things.
[09:53] <mborzecki> just me or does github feel slow adding comments today?
[09:54] <Wimpress> libraspberry-dev and libraspberry0, only available for armhf.
[09:54] <Wimpress> And the MMAL patches for VLC, which currently only available for VLC 3.0.6
[09:56] <thresh> that's weird it needs patches, since we do ship mmal in the code
[09:56] <thresh> in 3.0, that is, and in 4.0 (the upcoming version)
[09:56] <Wimpress> thresh: Patches are here - https://github.com/RPi-Distro/vlc in debian/patches
[09:57] <thresh> that's a big patch
[09:57] <Wimpress> Yep.
[09:58] <niemeyer> mvo: I'm off today, but will give mup some love when I get back home later today
[09:58] <niemeyer> sorry for the trouble there
[10:00] <mvo> niemeyer: thank you and sorry for bothering you on your day off
[10:01] <niemeyer> mvo: np, thanks for letting me know
[10:08] <dot-tobias> What's the best way to debug snap hooks? I'm adding some commands to a post-install hook and would like to identify thinkos or unexpected errors without the whole “install old rev, build new rev, install new rev, repeat”. I found “snap run --hook”, but since my hook contains “snapctl stop --disable my-snap.my-service”, it complains about “unknown flag: disable”. I presume it's something to do how the hook is called by
[10:08] <dot-tobias>  “snap run”, the same command in my install hook runs without complaints.
[10:11] <Chipaca> dot-tobias: it looks like snapctl stop doesn't have a --disable
[10:12] <Chipaca> the help might be wrong though
[10:12]  * Chipaca looks inside
[10:12] <Chipaca> ah look at that, it does
[10:13] <dot-tobias> Chipaca: That's what I've been wondering as well (comparing “snapctl help” with “snap help stop”), got it from here: https://forum.snapcraft.io/t/support-for-snapctl-stop-start-restart-services/1908/17?u=tobias
[10:13] <dot-tobias> And the disable flag works fine in an install hook; presumably as well in the post-refresh – just throws the error if called with “snap run --hook=post-refresh my-snap”
[10:15] <dot-tobias> Chipaca: And if I interpret https://github.com/snapcore/snapd/pull/5777 correctly, the fix that keeps disabled services disabled after refresh is not in yet, right?
[10:15] <Chipaca> correct
[10:22] <zyga> pstolowski: https://bugs.launchpad.net/snapd/+bug/1606674 is something you could assign to yourself
[10:22] <dot-tobias> Chipaca: As for my initial question, just figured out that I can run “snap try” over an already mounted try snap and it will run like a refresh – including hooks. The snapctl command works fine with --disable.
[10:22] <zyga> pstolowski: the serial port hotplug work seems like good test case for desktop users
[10:23] <Chipaca> dot-tobias: 'run --hook' is internal, AFAIK without the context setting up that's done by snapd before calling it, things will fail
[10:24] <Chipaca> dot-tobias: but yes both 'snap try' and 'snap install --dangerous ./some-local.snap' are actually refreshes
[10:24] <Chipaca> dot-tobias: i mean of a previously installed thing with the same name
[10:28] <dot-tobias> Chipaca: Noted 😊 http://www.addletters.com/pictures/bart-simpson-generator/bart-simpson-generator.php?line=I+won%27t+assume+undocumented+CLI+flags+are+always+public.
[10:29] <Chipaca> dot-tobias: undocumented are probably fine; undocumented and explicitly hidden, are … who knows :-)
[10:29] <Chipaca> OTOH the completion thing doesn't hide hidden flags
[10:29] <Chipaca> … or does it
[10:29]  * Chipaca checks
[10:29] <zyga> mborzecki: perhaps something you can update https://bugs.launchpad.net/snapd/+bug/1750872 :)
[10:30] <mborzecki> haha
[10:30]  * zyga mvo: this is probably fixed now, right? https://bugs.launchpad.net/snapd/+bug/1791182
[10:30] <Chipaca> mborzecki: an excellent opportunity to use "whelm"
[10:33]  * zyga pstolowski: wasn't this fixed already? https://bugs.launchpad.net/snapd/+bug/1806447
[10:33] <thresh> Wimpress, doesnt look mergeable in such a form, I mean thousands lines of code, copied avcodec.c plugin, zero commit logs...
[10:34] <thresh> maybe if split properly, and submitted by someone who cares and who wrote it, we can go forward
[10:34] <mvo> zyga: yes, I think this is fixed
[10:34] <zyga> mvo: should I update it or will you?
[10:38]  * zyga Chipaca: UX bug on snap info: https://bugs.launchpad.net/snappy/+bug/1814971 I believe this should be fixed now?
[10:38]  * zyga pstolowski: I believe this is fixed now, right? https://bugs.launchpad.net/snappy/+bug/1812751
[10:38] <mvo> zyga: please do
[10:38] <zyga> sure
[10:39] <Chipaca> zyga: fixed how?
[10:39] <zyga> Chipaca: isatty vs pipe
[10:39] <zyga> the arrows become ^ when piped
[10:39] <zyga> so ... parsable )
[10:39] <zyga> :)
[10:39] <Chipaca> zyga: that's not what that bug is about
[10:40] <Chipaca> it even mentions carets as equivalently unparsable
[10:40] <zyga> ah, I see now
[10:40] <Chipaca> and I agree, the channel map is not meant to be parseable
[10:40] <Chipaca> (the bug calls them carrots, which I refuse to edit)
[10:40] <MattJ> :)
[10:40] <zyga> thanks, I'll leave it as is
[10:40] <Chipaca> zyga: in fact just last week I was saying "yeah that is not meant to be parseable really"
[10:41] <Chipaca> or words to that effect
[10:41] <pedronis> Chipaca: yes, the only solution to that bug is --format
[10:41] <Chipaca> or talk-to-the-hand^Wsocket
[10:41] <Wimpress> thresh: I was in a meeting.
[10:41] <Chipaca> talking to the socket is really not hard nor unfriendly
[10:42] <Wimpress> thresh: I have good contacts at the Raspberry Pi Foundation. I'll see if I can get them to submit clean PRs upstream.
[10:42] <zyga> we have a loooot of bugs to go through
[10:43] <Chipaca> zyga: https://forum.snapcraft.io/t/use-of-snap-command-line-in-scripts-other-programs/10471/2 fwiw
[10:43]  * Chipaca hugs zyga
[10:43]  * zyga looks
[10:43]  * zyga hugs Chipaca back :)
[10:43] <Chipaca> zyga: we don't have bugs! we have … features that are trying their best
[10:45] <thresh> Wimpress, np, and thanks!
[10:52] <pstolowski> zyga: i've updated the two bugs you asked (both fixed)
[10:53] <zyga> pstolowski: super, thank you!
[10:54] <zyga> mborzecki: a small bug you could assign to yourself for tracking
[10:54] <zyga> mborzecki: https://bugs.launchpad.net/snappy/+bug/1574103
[10:54] <zyga> I think your work will fix it
[10:56] <zyga> pstolowski: does this ring a bell? I recall something similar happening recently: https://bugs.launchpad.net/snappy/+bug/1805170
[10:57] <zyga> degville: a typo in docs, probably stale by now but perhaps you can have a quick look? https://bugs.launchpad.net/snapd/+bug/1801735
[11:02] <pstolowski> zyga: yes, we've been considering enhancing snapctl to show changed values for current transaction. no concrete plan as far as snapctl is concerned. should be easy to add
[11:08] <degville> zyga: yep, of course - looking now.
[11:10] <mvo> hey degville! nice to see you :)
[11:11] <degville> mvo: thanks! good to be back :)
[11:13] <pedronis> Chipaca: some small comments on 6635
[11:17] <mborzecki> so the opensuse install fix PR did not fail on opensuse, but this failed instead: https://paste.ubuntu.com/p/XWMd4vMGVw/
[11:18] <mborzecki> isn't there a ticket about that?
[11:20]  * pstolowski lunch
[11:24] <zyga> mborzecki: yes, mvo is working on that
[11:25] <zyga> mvo: https://bugs.launchpad.net/snapd/+bug/1769669 looks like something that was fixed now, shall I mark it as such?
[11:25] <zyga> (at least based on the forum chatter)
[11:31] <Chipaca> pedronis: on it
[11:32] <mvo> zyga: yeah, this should be more robust now
[11:32] <zyga> mvo: shall I close the bug?
[11:33] <mvo> zyga: +1
[11:38] <zyga> mvo: halp
[11:39] <zyga> mvo: do we have a regression?
[11:39] <zyga> https://www.irccloud.com/pastebin/8c8TlMgh/
[11:39] <zyga> --extrausers broke on core
[11:39] <zyga> (core16)
[11:44] <mvo> zyga: this is edge? let me check
[11:44] <mborzecki> zyga: i'm guesing this is where it broke https://people.canonical.com/~mvo/core-changes/html/edge/2.38r6678_2.38+git1203.52b6d65~ubuntu16.04.1r6685.html
[11:45] <zyga> mvo: that's the critical pr that fixes master
[11:45] <zyga> mvo: from maciej
[11:45] <mvo> mborzecki: indeed
[11:45] <mvo> zyga: yeah on it
[11:45] <zyga> mborzecki: when exactly?
[11:45] <mborzecki> 6673 seem sok
[11:45] <mborzecki> seems ok
[11:45] <zyga> mborzecki: before 1:4.2-3.1ubuntu5.4
[11:45] <zyga> (version from hell)
[11:46] <mvo> zyga: let me sort this out
[11:46] <zyga> super, thank you!
[11:47] <mvo> zyga: there must be some confusion, my original SRU added all the missing patches :/
[11:47] <zyga> yeah
[11:47] <zyga> that's why I'm puzzled
[11:47] <zyga> maybe CVE fix dropped them?
[11:47] <mvo> zyga: anyway, fix should be there soon
[11:47] <zyga> or maybe image ppa woe?
[11:47] <zyga> I don't get it
[11:57] <mvo> zyga: I think the PPA is confused, I manually uploaded a no-change version to hopefully fix it
[11:58] <mvo> zyga: this version was briefly in ppa:snappy-dev/image but then I removed it again because I wanted to SRU the full version with all pending changes to the real archive instead of the PPA (I did that on friday but iirc no sru review yet)
[11:58] <mvo> zyga: anyway, hopefully a gentle kick will fix it
[11:59] <mborzecki> ok, so this, then opensuse branch, then merge master to the PRs and we can finally start seeing some green :P
[11:59] <zyga> mvo: ideally the fix is that the main version in the archive is ok
[11:59] <zyga> mvo: and we can drop this from the ppa forever
[11:59] <Chipaca> mborzecki: things are broken right now?
[12:00]  * Chipaca was about to push
[12:00] <mborzecki> Chipaca: yeah
[12:00] <zyga> mvo: shadow failed to upload in the snappy-dev/ubuntu/image ppa just now
[12:00] <zyga> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/16527935
[12:01] <Chipaca> mborzecki: I'll hold back then :-)
[12:01] <Chipaca> maybe i should have lunch
[12:05] <pedronis> pstolowski: I mand an high-level remark in 6629
[12:05] <pedronis> *made
[12:08] <mvo> zyga: yeah, its more confused, I uploaded anohter fix
[12:09] <mvo> zyga: main archive>yeah, I was working on exactly that, i.e. SRU our two pending patches plus the new userdel one
[12:09] <mvo> zyga: its iirc in unapproved
[12:09] <zyga> mvo: there's a thing I need to discuss with you
[12:09] <zyga> mvo: maybe after you are done with this you could give me a ping?
[12:09] <mvo> zyga: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= (fwiw)
[12:10] <mvo> zyga: we can talk in ~2min, just want to double check the build and then trigger core rebuild
[12:13] <mvo> zyga: I'm in the standup channel
[12:13] <zyga> joining
[12:26] <pstolowski> pedronis: thanks
[12:30] <mvo> new core build triggered, should be ready in some minutes with fixed useradd
[12:39] <cachio> Chipaca, hey
[12:39] <Chipaca> cachio: 'sup
[12:39] <cachio> I am testing the core revert test
[12:39] <Chipaca> cachio: ok
[12:39] <cachio> perhaps you can help me
[12:39] <cachio> after I refresh the core snap
[12:40] <cachio> it cannot make a snap refresh
[12:40] <Chipaca> did it reboot after refreshing?
[12:40] <cachio> I see an error like https://paste.ubuntu.com/p/nJkkcVhVWy/
[12:40] <Chipaca> cachio: is this on core, or on classic?
[12:40] <cachio> yes
[12:40] <cachio> it is core
[12:40] <cachio> core 16
[12:41] <Chipaca> cachio: ah, that looks like a network issue
[12:41] <cachio> could it be related to the catalog refresh?
[12:41] <Chipaca> cachio: what's in the log? (is it running with DEBUG_SNAPD_HTTP)
[12:41] <Chipaca> or was it SNAPD_DEBUG_HTTP
[12:41] <cachio> I added core to ping api.snapcraft.io before make the refresh
[12:42] <cachio> and it can reach the endpoint
[12:42] <Chipaca> the logs should have more info about what's going on
[12:42] <Chipaca> if debug is on
[12:42] <cachio> it I wait like a minute the snap refresh command does not fail anymore
[12:43] <cachio> I'll add the debug in that case
[12:43] <Chipaca> cachio: you're not running with SNAPD_DEBUG already?
[12:43] <cachio> no
[12:43] <cachio> Chipaca, the test is running in a vm inside other vm in google
[12:44] <cachio> Chipaca, it is part of the nested test suite
[12:44] <Chipaca> cachio: what's in the logs _without_ debug?
[12:44] <Chipaca> or does the vm die
[12:45] <cachio> it is running without debug beacuse I test the core which I get from edge
[12:45] <cachio> on that suite
[12:49] <Chipaca> cachio: but can you get the logs?
[12:50] <cachio> Chipaca, yes
[12:50] <Chipaca> cachio: please do
[12:50] <Chipaca> cachio: even without debug there might be something useful
[12:51] <cachio> Chipaca, I am running again the test
[12:51] <cachio> I'll have the logs in 5 minutes
[12:53] <pstolowski> cachio: hey, #6491 fails repeatedly on google:ubuntu-14.04-64:tests/main/interfaces-daemon-notify and it's unclear why (it's completely unrelated to the PR); do you have a moment to help with that?
[12:54] <cachio> pstolowski, hi, checking
[12:59] <mborzecki> off to pick up the kids
[13:13] <cachio> pstolowski, I see errors related to opensuse which I am trying to fix
[13:14] <cachio> pstolowski, I think best is disable it until the solution is in place
[13:14] <pstolowski> cachio: yes, this time opensuse failed as well. but the problem is that test i mentioned, it failed many times in a row
[13:15] <cachio> I am executing it now
[13:15] <cachio> seems to be something new
[13:16] <cachio> pstolowski, I am trying to reproduce it here
[13:17] <pstolowski> cachio: ta! it seems something with journal cursor? but it's unclear why it's failing on the PR which adds this nested vm test
[13:19] <cachio> pstolowski, it is not related to your change
[13:32] <cachio> Chipaca, the logs are not good :( https://paste.ubuntu.com/p/GFtrm7TWYf/
[13:32] <Chipaca> cachio: sigh
[13:32] <cachio> I have a debug session on that machine
[13:33] <cachio> could I get something else?
[13:36] <Chipaca> cachio: if you do the refresh agian does it work?
[13:37] <pedronis> cachio: both mvo and me made some comments in 6625
[13:38] <cachio> Chipaca, yes
[13:39] <Chipaca> cachio: sounds like actual network hiccup, then
[13:39] <Chipaca> cachio: can you turn on debug permanently in the nested tests? (you can do it by just adding a file)
[13:41] <cachio> pedronis, I saw those, I'll answer and start a new test for ssh config
[13:43] <cachio> Chipaca, Environment=SNAPD_DEBUG_HTTP=7 SNAPD_DEBUG=1 is ok for the config¡
[13:43] <cachio> ?
[13:44] <Chipaca> cachio: yes
[13:44] <Chipaca> cachio: it goes in a [Service] section
[13:45] <cachio> Chipaca, /etc/systemd/system/snapd.service.d/local.conf ?
[13:45] <Chipaca> cachio: y
[14:05] <cachio> niemeyer, hey, could you please take a look to https://github.com/snapcore/spread/pull/75
[14:19] <zyga> pedronis: can you ack / change https://github.com/snapcore/snapd/pull/6636#discussion_r268661433 after the call please?
[14:21] <pedronis> zyga: done
[14:33] <mborzecki> cachio: https://github.com/snapcore/snapd/pull/6644
[14:34] <cachio> mborzecki, I'll try that
[14:34] <cachio> thanks
[14:37] <cachio> Chipaca, https://paste.ubuntu.com/p/Dw4vPh9PpY/
[14:38] <cachio> Chipaca, api.snapcraft.io works before make snap refresh
[14:40] <zyga> I need to grab lunch and maybe exercise a bit, I will be back later
[14:40] <mborzecki> off to pick up the kids
[14:40] <mborzecki> damn, wrong terminal
[14:41] <niemeyer> cachio: Heya
[14:41] <niemeyer> Will look tomorrow.. off today
[14:43] <mborzecki> mvo: restarted #6644 too early probably as it failed with --extrausers again, running it again
[14:44] <Chipaca> cachio: it looks like the network wasn't fully up?
[14:46] <Chipaca> cachio: dns was failing at 14:22:19, and still at 14:22:23, then that came up by 14:22:24 but still not healthy
[14:46] <mvo> mborzecki: ok
[14:46] <Chipaca> cachio: how are you testing you can reach api.snapcraft.io?
[14:47] <cachio> Chipaca, https://paste.ubuntu.com/p/KKHXZgxJCm/
[14:50] <cachio> Chipaca, does it make sense?
[14:50] <Chipaca> cachio: the output of 'snap debug connectivity' would be helpful, if you could
[14:51] <Chipaca> cachio: and you could 'while ! snap debug connectivity; do sleep 1; done'
[14:51] <cachio> Chipaca, https://paste.ubuntu.com/p/3JfKfZb4wc/
[14:51] <cachio> this is what I have
[14:52] <cachio> I could print all the output, but I need to rexecute
[14:54] <Chipaca> cachio: I mean, with what you have, my veredict is the network had a hiccup
[14:54] <Chipaca> cachio: it happening every time makes me think it's actually something in the vm that hasn't finished coming up
[14:54] <Chipaca> cachio: but I don't know
[14:58] <cachio> Chipaca, ok, makes sense
[14:59] <cachio> I'll try to install a snap and see if it works or fail
[15:00] <mborzecki> mvo: fwiw, i ran google:ubuntu-core-16-64:tests/main/ubuntu-core-create-user separately now, so i expect #6644 to be green this time :)
[15:08] <mvo> mborzecki: cool
[15:08] <cachio> mborzecki, seems to work well the change for opensuse
[15:09] <cachio> I'm updating the image now
[15:09] <cachio> in this case we dont need to diable opensuse
[15:19] <mborzecki> 6644 landed
[15:19] <Chipaca> mborzecki: is that the fix-all-the-things one?
[15:23] <pedronis> zyga: there's a conflict as well in #6636
[15:24] <mborzecki> Chipaca: yeah, it should make things green again
[15:30]  * cachio lunch
[15:33]  * zyga returned home, rain + bike != fun
[15:41] <Chipaca> zyga: not with that attitude
[16:17] <zyga> pedronis: does https://github.com/snapcore/snapd/pull/6636 look good now or do you want to see some changes around the go part?
[16:19] <zyga> ups, bad push :/
[16:19] <pedronis> zyga: I need to go have a walk, will look when I'm back
[16:20] <zyga> ok
[16:27] <mvo> zyga: 6642 has conflicts now
[16:29] <Chipaca> pedronis: wrt common-id search, should I make it reject q+cid searches?
[16:29] <zyga> mvo: yes, expected
[16:29] <zyga> I just fixed the base branch
[16:29] <mvo> ta
[16:32] <zyga> I need to mend the network again
[16:32] <zyga> time to actually connect that backup modem I have
[16:32] <zyga> brb
[16:44] <zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/6597
[16:44] <zyga> mvo, mborzecki ^
[16:46] <cachio> pedronis, hey, #6625 updated
[16:47] <cachio> but it fails with ssh.disable: true
[16:47] <cachio> pedronis, is it expected, right?
[16:48] <mvo> zyga: I can check tomorrow, need to play hockey soon(ish) :)
[16:48] <zyga> sure
[17:09] <mborzecki> heh, so now spread jobs hit the travis time limits
[17:11] <cachio> mborzecki, do you have a link¡
[17:12]  * Chipaca knows cachio's keyboard layout, and hates it
[17:12] <cachio> :)
[17:12] <Chipaca> https://www.dsi-keyboards.com/wp-content/uploads/2015/03/KA-Latin-American-20867.jpg
[17:13] <Chipaca> hate hate hate
[17:13] <Chipaca> how can you program on that
[17:13] <Chipaca> :-)
[17:13] <Chipaca> having the logical not right there is cool tho
[17:13] <cachio> Chipaca, I don't know, well perhaps because I use it since long time :):)
[17:13] <Chipaca> cachio: obvs :-)
[17:14] <Chipaca> i just never could get used to it
[17:14] <cachio> Chipaca, I used to work for argentinian clients
[17:14] <cachio> Chipaca, I needed the ñ
[17:15] <cachio> Chipaca, :)
[17:15] <Chipaca> cachio: i'm still upset there never was ubuntu ñoño ñandú
[17:15] <cachio> Chipaca, and i also used to share the computer with my wife
[17:15] <Chipaca> cachio: my condolences
[17:15] <cachio> hehehe
[17:16] <Chipaca> anyhoo, back to breaking stuff
[17:16] <Chipaca> actually, no
[17:16] <Chipaca> i'm going for a walk before the sunshine goes
[17:16]  * Chipaca afk
[17:19] <pedronis> cachio: actually, not, I thought it would work with recent code changes, we'll need to dig
[17:22] <pedronis> Chipaca: I don't have a strong opinion, do we think the store will drop support for that? on our side it's easier to add things than to remove them
[17:22] <pedronis> which is an argument to not allow it unless there's a strong use case
[17:22] <Chipaca> pedronis: yeah, that's what i was thinking, particularly with rob saying they're not goingt o use it
[17:23] <Chipaca> I'll drop support for the combo
[17:23] <Chipaca> but first i'll walk
[17:23]  * Chipaca really afk now
[17:26] <cachio> pedronis, this is the output https://paste.ubuntu.com/p/KbxSxbYGZP/
[17:28] <pedronis> cachio: that is weird,  we probably need pstolowski to help debug that
[17:40] <cachio> pedronis, this ire the defaults that we use
[17:40] <cachio> https://github.com/snapcore/snapd/blob/8c8af3731b6feeb781bb477208c526755ac435a3/tests/main/ubuntu-core-gadget-config-defaults/gadget-ssh-oneline.yaml
[17:40] <cachio> pedronis, is it ok?
[17:42] <pedronis> cachio: yes, it was asked, we'll discuss tomorrow with pstolowski
[17:42] <pedronis> sorry, it is what I asked
[17:42] <cachio> pedronis, nice
[17:42] <pstolowski> Im afk, will check tomorrow morning
[17:43] <cachio> pedronis, thanks
[19:06]  * zyga EODs
[19:12] <zyga> cachio, pedronis: feels like missing path in handleServiceDisableConfiguration, specifically when output is ""
[19:13] <cachio> zyga, nice, thanks for take a look to that
[19:15] <juliank> I finally decided to start building the apt snap: https://paste.ubuntu.com/p/XvgPpKGgqQ/ :D
[19:15] <juliank> I think I had a problem with an unclean rebuild in between, as the apt snap ended up with
[19:15] <juliank> E: The method driver /apt/lib/apt/methods/mirror+file could not be found.
[19:15] <juliank> but let's see what the next revision brings
[19:17] <juliank> Hmm, so it builds the snap to install to the snap's /, but then apt looks up methods in /lib/apt, when it should be looking in /snap/apt/<id>/lib/apt
[19:21] <juliank> so I guess I can specify - -DCMAKE_INSTALL_LIBEXECDIR=/snap/apt/current but I'd like the id instead of current
[19:24]  * cachio afk
[19:34] <juliank> How do other classic snaps handle running helpers from their own libexecdir?
[20:47] <zyga> jdstrand: updated https://github.com/snapcore/snapd/pull/6642
[20:47] <zyga> jdstrand: I kept the permission as they were, I will discuss this with pedronis tomorrow
[20:48] <zyga> jdstrand: but everything else should be good now
[21:07]  * zyga really EOD now
[21:07] <zyga> juliank: that's not an ID
[21:07] <zyga> juliank: that's a revision that changes  with each build
[21:27] <jdstrand> zyga: ack, thanks
[22:32] <juliank> zyga: well, yes
[22:32] <juliank> zyga: that's where it should look for its helper programs
[22:33] <juliank> Currently I'm snapping a caldav server, but I don't feel safe having the root daemon, so I think maybe not ship a daemon, and just the command in the snap. oh well...
[23:00] <pgnd> I've installed snapd on Opensuse, per instructions here: https://forum.snapcraft.io/t/installing-snap-on-opensuse/8375
[23:00] <pgnd> There, degville mentions the need to "systemctl enable snapd.apparmor".
[23:01] <pgnd> Afaict, there's no such service installed ...  Is that^^ still current instruction, and a dep has changed?


[06:11] <mup> Bug #1912722 opened: set_boot_disk websocket method does not result in machine update notify <blocking-ui> <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1912722>
[06:53] <mup> Bug #1912727 opened: KVM Page Fails to load with error "An unexpected error has occurred, please try refreshing your browser window." <MAAS:New> <https://launchpad.net/bugs/1912727>