[02:45] <Unit193> ochosi: So only thing we're waiting for is knome to ack and someone to upload, right?  Everyone is fine with their email/name/etc?
[02:46] <knome> ack from my side.
[02:54] <Unit193> You don't even know if I filled it with rats or something.
[02:55] <knome> we'll find out...
[02:59] <Unit193> Did anyone save the rejected ones?
[03:00] <knome> no, they were infinitely deleted from the planet earth
[03:00] <Unit193> Bummer.
[03:01] <knome> they are still in /Accepted
[03:01] <knome> and in a secret tarball somewhere
[03:01] <knome> and my, ochosi's and probably pleia2's harddrives
[03:14] <bluesabre> mine too
[03:14]  * bluesabre is sneaky
[06:07] <ochosi> Unit193: i've sent them all an email together, let's give them until after the weekend to respond. just in case someone doesnt want their email or realname there...
[06:14] <ochosi> Unit193: so far i only collected the infos, only one of them has ack'ed it expressis verbis
[06:15] <Unit193> Sure, it'd take a while to get it up anywho.
[06:16] <Noskcaj> menulibre is now updated, mugshot is upload ready
[06:16] <Noskcaj> and i'll do parole later tonight
[06:17] <ochosi> i presume 0.6?
[06:19] <Noskcaj> yeah
[06:24] <ochosi> cool
[06:39] <Noskcaj> mugshot's uploaded, but in NEW
[07:36] <elfy> lderan: thanks - seen the pastebin
[08:54] <zequence> I'd like to add a couple of apps to be autostarted when the user logs in, by default. How does one add that for users, by default?
[09:01] <zequence> Ah, /etc/xdg/autostart/*.desktop
[09:31] <slickymaster> morning all
[10:29] <slickymaster> work meeting
[10:29] <slickymaster> bbl after lunch ->
[11:26] <Unit193> zequence: You may want to make sure it doesn't conflict with another package or settings package.  You can use /etc/xdg/ubuntustudio/autostart/ if the path already exists in another package.
[11:31] <zequence> Unit193: It's for the next version of the application ubuntustudio-controls, and the idea is that it should autostart on any DE
[11:32] <zequence> There's a way to make it only start on certain DEs though, specified in the desktop file
[11:32] <zequence> even if put in /etc/xdg/autostart
[11:33] <Unit193> Yep, and to exclude a few.
[11:33] <Unit193> OnlyShowIn, NotShownIn.
[14:08] <brainwash> bug 880533
[14:09] <brainwash> not yet fixed, delete a file and relog to reproduce it
[14:22] <knome> brainwash, where's your patch for the bug?
[14:56] <brainwash> knome: work in progress I guess
[15:25] <brainwash> does anyone here use whisker menu?
[15:27] <brainwash> if it's the left most item in the panel and you try to drag a panel window button, does the whisker menu panel item turn black?
[15:30] <brainwash> nevermind, it's a known issue
[15:31]  * pmjdebruijn uses 1.3.1 backported to saucy
[15:34] <brainwash> https://github.com/gottcode/xfce4-whiskermenu-plugin/issues/37
[15:34] <brainwash> BUT it might affect more/all external panel plugins
[15:35] <brainwash> occasionally it happens to the places plugin too
[15:35] <pmjdebruijn> sounds like a panel bug?
[15:36] <brainwash> could be, marking whisker menu as internal plugin apparently resolves the glitch
[15:36] <pmjdebruijn> btw in the next intel video driver there are going to be some nice fixes, which are relevant for xfwm
[15:36] <pmjdebruijn> brainwash: huh?
[15:37] <brainwash> "Something else that also solved the bug for me was making the plugin internal instead of external."
[15:38] <brainwash> you mean SNA related fixes?
[15:38] <pmjdebruijn> define internal vs external?
[15:38] <pmjdebruijn> brainwash: indeed
[15:38] <pmjdebruijn> I helped troubleshoot like 5+ bugs in grand total
[15:38] <pmjdebruijn> 2 were xfwm artifacts with sna
[15:38] <pmjdebruijn> and 3 were TearFree related (which defaults to off)
[15:39] <brainwash> ppor dev, he is working on SNA on a daily base, but it still causes so many glitches
[15:39] <brainwash> tearfree related? did not notice anything odd
[15:40] <pmjdebruijn> do you have tearfree enabled i nthe intel driver?
[15:40] <pmjdebruijn> (not xfwm)
[15:40] <brainwash> currently not, but I did enable it occasionally
[15:40] <pmjdebruijn> will latest git master it should finally be reliable
[15:40] <pmjdebruijn> I hit a lot of issues using chromium
[15:40] <brainwash> but didn't notice anything strange
[15:41] <pmjdebruijn> chromium :)
[15:41] <brainwash> other than the expected performance loss
[15:41] <brainwash> oh ok
[15:41] <pmjdebruijn> there were lots of cornercases :)
[15:41] <brainwash> firefox here
[15:41] <pmjdebruijn> yeah didn't have any issues there either
[15:41] <pmjdebruijn> and I had some weird issue with scummvm :)
[15:41] <pmjdebruijn> like I said, I helped troubleshoot 5 (or 6?) issues by now :)
[15:41] <pmjdebruijn> ickle did the hard work of actually fixing stuff
[15:42] <brainwash> awesome :)
[15:42] <pmjdebruijn> just trying to get the intel driver in as best shape as possible for the next LTS
[15:43] <brainwash> hopefully we get all the fixes to land in trusty
[15:44] <brainwash> and regarding internal/external -> https://github.com/gottcode/xfce4-whiskermenu-plugin/issues/37#issuecomment-29758966
[15:45] <brainwash> I assume that the internal plugins are all those which ship with xfce4-panel
[15:45] <brainwash> app menu, window buttons,..
[15:46] <brainwash> I'll file a report against xfce4-panel after some more testing
[15:51]  * slickymaster damns his work internet connection
[15:55] <knome> slickymaster, yes (re: docs meeting)
[15:55] <knome> any reason not o?
[15:55] <knome> to
[15:55] <slickymaster> knome: ok, just lost connectivity and didn't notice
[15:55] <slickymaster> if you've answer
[15:55] <slickymaster> it's ok with me
[15:55] <knome> ;)
[16:42] <brainwash> pmjdebruijn: https://bugzilla.xfce.org/show_bug.cgi?id=10656
[17:33] <slickymaster> knome: I have to go and pick up my kid at school. will be back in about 45 minutes
[17:33] <slickymaster> ->
[18:01] <ochosi> nice, fixed power-indicator already landed in trusty (with support for xfce4-powerman)
[18:59] <jjfrv8-work> if I disappear unexpectedly, it's because I've got like a triple remote connection going on here
[18:59] <pleia2> hah, sounds fun
[18:59] <jjfrv8-work> if it stays up :)
[18:59] <knome> #startmeeting Xubuntu community meeting
[18:59] <meetingology> Meeting started Thu Jan 30 18:59:47 2014 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:59] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:59] <knome> so who's here for the meeting
[18:59] <jjfrv8-work> o/
[19:00] <slickymaster> o/
[19:00] <pleia2> o/
[19:01] <elfy> yep
[19:01] <knome> ok, cool
[19:01] <knome> let me get my act together :d
[19:01] <knome> !team | meeting time
[19:02] <knome> #topic Open action items from previous meeting
[19:02] <knome> #action ali1234 follows up on gtk3 indicator status
[19:02] <meetingology> ACTION: ali1234 follows up on gtk3 indicator status
[19:02] <knome> #action elfy to poke Noskcaj if time-admin and users-admin do not exist in the next daily
[19:02] <meetingology> ACTION: elfy to poke Noskcaj if time-admin and users-admin do not exist in the next daily
[19:02] <knome> did that happen?
[19:02] <ali1234> again already?
[19:02] <ali1234> where does the time go?
[19:02] <knome> ali1234, shoo :P
[19:02] <elfy> poked and nothing happened
[19:02] <knome> keeping it carried on to make sure things happen
[19:03] <Noskcaj> o/
[19:03] <knome> #action knome to be in touch with people re Tech Lead position
[19:03] <meetingology> ACTION: knome to be in touch with people re Tech Lead position
[19:03] <knome> still TBD
[19:03] <knome> #action knome to send an email to the mailing list re: bluetooth
[19:03] <meetingology> ACTION: knome to send an email to the mailing list re: bluetooth
[19:04] <knome> TBD
[19:04] <knome> #action ochosi to follow up on xfce 4.12 release with nick and report back
[19:04] <meetingology> ACTION: ochosi to follow up on xfce 4.12 release with nick and report back
[19:04] <knome> #action ~QA to write tests for new packages, sync to tracker and call for testing
[19:04] <meetingology> ACTION: ~QA to write tests for new packages, sync to tracker and call for testing
[19:04] <knome> elfy, want to carry that on?
[19:04] <elfy> well it's ongoing
[19:05] <knome> i ask you a simple yes/no question and you start with "well..." ;)
[19:05] <elfy> well ...
[19:05] <elfy> yes
[19:05] <knome> do you need a weekly reminder?
[19:05] <elfy> no
[19:05] <knome> ok
[19:05] <knome> haha, so dropping it then :P
[19:05] <knome> #undo
[19:05] <meetingology> Removing item from minutes: <MeetBot.items.Action object at 0x1769290>
[19:05] <elfy> ok :p
[19:05] <knome> #action team members that are able to test/use bluetooth stuff, consider which software they would like to use, if it matters
[19:05] <meetingology> ACTION: team members that are able to test/use bluetooth stuff, consider which software they would like to use, if it matters
[19:05] <knome> #nick team
[19:05] <knome> that's it.
[19:05] <knome> #topic Team updates
[19:06] <knome> please use #info and #action (for new action items) as appropriate
[19:06] <knome> lderan, autopilot
[19:06] <knome> Unit193, -core email
[19:06] <knome> #info knome updated the meetings page with the new structure
[19:06] <slickymaster> #info slickymaster finished Mugshot's online documentation -> http://smdavis.us/doku/doku.php?id=mugshot-docs
[19:07] <elfy> #info Image testing for the last 7 days -> 64 bit image tests 3, no 32 bit tests reported
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 64 bit 13.10 to 14.04 5 reported for update manager upgrading, no tests from image
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 64 bit lts to lts 5 reported for update manager upgrading, 3 reported for image update
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 32 bit 13.10 to 14.04 2 reported for update manager upgrading, no tests from image
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 32 bit lts to lts 2 reported for update manager upgrading, none reported for image update
[19:07] <elfy> #info Settings Manager test call out soon - includes light-locker
[19:07] <knome> #info knome looked into the docs SRU and the new, fixed package (thanks bluesabre) should land in precise any day.
[19:07] <elfy> #info Manual testcase continues prior to calls
[19:07] <knome> ali1234, news about gtk3 indicators?
[19:08] <knome> #info knome, ochosi and pleia2 held a meeting and selected the winners for the community wallpapers
[19:08] <ali1234> some changes were pushed to the indicators but still no fix to the core library problems afaik
[19:08] <knome> #info knome did housecleaning on the blueprints
[19:08] <knome> ali1234, ok, cheers
[19:08] <Noskcaj> #info mugshot in debian NEW
[19:08] <Noskcaj> #info menulibre updated
[19:09] <Noskcaj> #info parole 0.6 in ubuntu repos
[19:09] <knome> Noskcaj, i'd appreciate "#info Noskcaj did ..." (easier for the team reports)
[19:09] <Noskcaj> ok.
[19:09] <ali1234> it's looking a lot like we'll have to wait until feature freeze and then demand it's either fixed or rolled back
[19:09] <slickymaster> #info slickymaster started to work on migrating Mugshot documentation into docbook format
[19:09] <Noskcaj> #info Noskcaj updated gthumb to 3.3
[19:09] <knome> ali1234, but new "features" are in already, just broken?
[19:10] <micahg-work> ali1234, does the current gtk3 indicator stack need to be uploaded to the archive still or is that waiting on fixes?
[19:10] <ali1234> micahg-work: there is nothing new on our side. the problems all exist in the unity stack
[19:10] <Unit193> knome: Yes?
[19:10] <ali1234> knome: the new features are in some packages and not others
[19:10] <knome> Unit193, please #info that you actually did something!
[19:10] <ali1234> that mismatch is half the problem
[19:11] <knome> ali1234, okay. then we should get the new features in before FF if at all possible (there's still time)
[19:11] <knome> ali1234, but other than that, FF shouldn't be the hard deadline for the fixes, and i'm optimistic of landing those fixes
[19:11] <ali1234> i don't know the status of stuff like xfce4-panel actually
[19:11] <micahg-work> I uploaded 2 SRUs, but I don't remember which ones
[19:12] <ali1234> we can't land any fixes in libindicator3 for example, that is what is currently broken
[19:12] <ali1234> and it is broken in unity too, still
[19:12] <Unit193> #info Unit193 sent a message to the list about the xubuntu-core meta.
[19:12] <micahg-work> ali1234, is there a summary of the issues somewhere (or list of bugs)
[19:12] <knome> #info lderan made a list of apps that can be ran simple "does it open" tests with autopilot: http://paste.ubuntu.com/6840722/
[19:13] <ali1234> micahg-work: see https://bugs.launchpad.net/indicator-network/+bug/1185565 and https://code.launchpad.net/~a-j-buxton/libindicator/remove-timeout/+merge/198070
[19:13] <knome> ali1234, micahg-work: if you don't mind, i'll add an action item for you to follow up on it and actually fix the stupid issues
[19:13] <knome> #action ali1234 and micahg to follow up on gtk3 indicator stack issues
[19:13] <meetingology> ACTION: ali1234 and micahg to follow up on gtk3 indicator stack issues
[19:13] <knome> #nick micahg
[19:13] <ali1234> i already sent a MR, there's nothing more i can do until tedg gets around to fixing it
[19:14] <micahg-work> ali1234, poke tedg and ask if he has time to review or can hand off to someone else
[19:14] <ali1234> i'm poking him once a week already
[19:14] <knome> micahg-work, any possibility you could oversee how that goes? would be good to have more people on top of the issue
[19:15] <ali1234> i've spoken to him several times about this already and it's always "yeah, i'm working on it"
[19:15] <ali1234> he knows and understands the problems we face
[19:16] <micahg-work> well, that's great, but I don't see why an MR should go 8 weeks without a review
[19:16]  * micahg-work <-- pot
[19:16] <ali1234> because it's part of a much bigger change, basically
[19:17] <micahg-work> yes, but there are ways to move these things forward, maybe it should be merged into a branch instead
[19:17] <ali1234> there are a bunch of other issues around this too, like under xubuntu it wont actually use upstart to launch indicators, because it's hardcoded to only do that in unity
[19:17] <knome> looking at the bug, not everybody agrees with what is going on
[19:17] <ali1234> knome: right
[19:17] <ali1234> that's a problem too
[19:18] <knome> i guess we're fine to do weekly reminders for a few more weeks
[19:18] <knome> if things do not progress, look at it again then
[19:18] <jjfrv8-work> sorry about that. I'm back.
[19:18] <knome> i guess another thing you could try, ali1234, is add more reviewers for the MP.
[19:18] <knome> jjfrv8-work, np :)
[19:19] <micahg-work> rewriting the indicator stack for the LTS seems so wrong...
[19:19] <ali1234> right, this is why i mentioned FF and either fix NOW or rollback
[19:19] <micahg-work> yeah
[19:20] <knome> as long as gtk3 indicators work for us, i don't mind how this falls
[19:20] <ali1234> we can always add the workaround to the environment
[19:20] <knome> ali1234, micahg-work: please obey the action item and follow up on it as much as needed :)
[19:20] <knome> and i'm of course also available, if you need something i can do to help.
[19:21] <brainwash> maybe we could already switch to gtk3 indicators and use the workaround (exporting an env var)
[19:22] <micahg-work> wait, we're still on GTK2 indicators?
[19:22] <knome> since FF is still somewhat far, i don't think it makes sense to push a workaround and then start using the new "real" fix
[19:22] <ali1234> agreed
[19:22] <ali1234> but it's always there if we need it
[19:22] <brainwash> the workaround can be reverted easily
[19:22] <knome> rather wait until the FF, and if the situation *then* looks stupid, do the workaround
[19:22] <brainwash> ok
[19:22] <knome> brainwash, it's still more work to get the workaround up than not.
[19:22] <ali1234> micahg-work: i'm not sure what is actually in the archive, because i work mainly upstream
[19:23] <micahg-work> ok
[19:23] <knome> we have to believe things are going to be fixed eventually
[19:23] <Noskcaj> micahg-work, i've got the stuff in a PPA, but i'd rather wait for a real release to upload stuff
[19:23] <brainwash> yes, Noskcaj's PPA + workaround works fine
[19:23] <Noskcaj> archive is all possible 4.11 stuff + garcon git snapshot
[19:24] <micahg-work> while I generally prefer that, we need baketime for the LTS, now if it'll just be broken in the archive, there's no point in uploading
[19:24] <ali1234> it's not as badly broken as gtk2 indicators...
[19:24] <knome> well exactly, my opinion is: hold until nearer to FF
[19:25] <knome> and see if things are fixed and then decide what to do, once, rather than uploading any workarounds now and having to poke around it later
[19:26] <Noskcaj> Is that for both panel and indicator?
[19:27] <brainwash> there is no panel 4.11 release yet
[19:28] <knome> looks like we're done with this. people involved, please keep in touch with each other.
[19:28] <knome> #topic Announcements
[19:28] <knome> i have one!
[19:28] <knome> at the end of the T cycle, jjfrv8-work will step from the doc lead position.
[19:29] <knome> while the T cycle lasts, he will keep on leading, with the assistance of slickymaster
[19:30] <knome> and if everything goes well, jjfrv8-work should be able to hand over the leader hat to slickymaster at the start of the U cycle
[19:30] <knome> of course, with the approval of the team
[19:30]  * Unit193 approves.
[19:30]  * elfy approves
[19:30]  * pleia2 approves
[19:31] <knome> we are going to have a meeting on docs issues sometime soon, where those two can update each other on the situation etc.
[19:31]  * Noskcaj approves  the approvals
[19:31] <micahg-work> sure
[19:31] <knome> (well the approval should happen later, when U cycle is starting :P)
[19:31] <knome> so, anybody interested in docs... hear hear!
[19:31] <knome> jjfrv8-work, slickymaster: you around to schedule?
[19:31] <slickymaster> yeaps
[19:31] <jjfrv8-work> yes
[19:32] <knome> whatever time works for you two is the best
[19:32] <knome> next week before/after the community meeting?
[19:33] <jjfrv8-work> next week I should be pretty flexible
[19:33] <slickymaster> next week is my ubuntu membership meeting
[19:33] <slickymaster> it depends on how much it will eventually take
[19:33] <knome> friday though, isn't that it
[19:34] <slickymaster> on the UM meeting ins on the 6th
[19:34] <slickymaster> is^^
[19:34] <knome> aha
[19:34] <knome> then i've mismarked that on my calendar ;)
[19:34] <knome> what about wednesday 19utc then?
[19:35] <jjfrv8-work> ok with me
[19:35] <slickymaster> fine with me, also
[19:35] <knome> ok, that's it
[19:35] <knome> #info Documentation checkup meeting on Wednesday, Feb 5 at 19UTC
[19:36] <knome> aaand thanks for both jjfrv8-work and slickymaster for all the work they have done this far and will do in the future!
[19:36] <knome> any other announcements?
[19:36]  * pleia2 adds to calendar
[19:36] <knome> pleia2, ta
[19:36] <knome> pleia2, you can add thu 19utc as the community meeting while you're at it
[19:37] <knome> ok, moving on
[19:37] <knome> #topic Agenda
[19:37] <knome> #subtopic Enabling more people to push to Xubuntu branches (separate branches team, or would -team do?)
[19:37] <knome> micahg-work, ping
[19:37] <micahg-work> yes?
[19:37] <knome> see the subtopic
[19:37] <knome> basically, we'd like to allow more people to be able to push to xubuntu branches
[19:37] <micahg-work> depends on the branches
[19:38] <knome> -default-settings
[19:38] <knome> mostly, i think
[19:38] <micahg-work> we can separate the branches from the uploaders team
[19:38] <knome> mhm
[19:39] <knome> do you think it would be ok to add them under ~xubuntu-team, or would you prefer a new team?
[19:39] <Noskcaj> I'd suggest we allow -team to modify branches
[19:39] <micahg-work> but I'd prefer to limit the people who can push to people who understand the package and have proven through MRs that they know what they're doing
[19:39] <Unit193> Would be best to use merges and have a couple review and approve.
[19:39] <micahg-work> yes
[19:39] <knome> ok, so something like ~xubuntu-branches
[19:39]  * Unit193 likes to have at least bluesabre take a look.
[19:40] <micahg-work> so, I'd basically move the xubuntu-dev team out of the DMB control and we would create a new team for uploaders when someone needs that
[19:40] <micahg-work> xubuntu-dev is fine
[19:40] <knome> ok,
[19:40] <knome> when you say "when someone needs that", what are you exactly referring to?
[19:40] <knome> when somebody gains packageset uploader access?
[19:40] <micahg-work> yes
[19:41] <Noskcaj> That takes for ever
[19:41] <knome> right, i would hope that happens sometime soon
[19:41] <knome> and rather create a new team for -branches
[19:41] <Noskcaj> micahg-work, Is there anything you can do to speed up my application?
[19:41] <Noskcaj> It will be a month tomorrow
[19:41] <Noskcaj> probably a new record
[19:41] <knome> but i guess i'm fine with doing what you proposed, then create ~xubuntu-dev-upload if/when we need it
[19:41] <micahg-work> Noskcaj, it's being discussed
[19:42] <Noskcaj> ok
[19:42] <micahg-work> knome, the uploader team would be managed by the DMB, so, nothing to worry about there
[19:42] <knome> micahg-work, sure
[19:43] <knome> micahg-work, can i get back to you on this in a week or so, to land the change
[19:43] <micahg-work> land what change?
[19:43] <knome> the LP teams changes, and separating -dev from upload stuff
[19:43] <knome> or would you rather just do it right away, or does it need some ack from the DMB?
[19:43] <micahg-work> oh, I just need to discuss quickly with the DMB
[19:43] <knome> ok, sure
[19:44] <knome> #action micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
[19:44] <meetingology> ACTION: micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
[19:44] <knome> #info if we need packageset uploader rights for certain people later, we shall create a new team for that purpose
[19:45] <micahg-work> nope
[19:45] <micahg-work> DMB would create that
[19:45] <knome> #undo
[19:45] <meetingology> Removing item from minutes: <MeetBot.items.Info object at 0x1632310>
[19:45] <knome> #info if we need packageset uploader rights for certain people later, we shall ask DMB to create a new team for that purpose
[19:46] <knome> nitpicking says me!
[19:46] <knome> #subtopic Status of Bluetooth in Xubuntu; what kind of testing we want to run, which software we want to use?
[19:46] <knome> micahg-work, do you have any opinion to that discussion?
[19:46] <micahg-work> ah, so, I think blueman upstream has be revived
[19:47] <Noskcaj> fyi: i updated blueman last week
[19:47] <knome> do we have a preference? do they all work with indicators, or do we need to consider that kind of issues?
[19:48] <micahg-work> is there something better out there, IIRC, blueman was the only one that worked well that didn't pull in half the GNOME stack
[19:49] <knome> then that sounds like a good one to use
[19:49] <knome> if there's no problems with using that...
[19:49] <micahg-work> if there's another alternative, I'm all ears, but with the recent resurgence of development on blueman, I think it's a good horse to be hitched to
[19:49] <Noskcaj> I think blueman has a memory leak though
[19:50] <cyphermox> there are no big alternatives really
[19:50] <cyphermox> memleaks are fixable ;)
[19:50]  * micahg-work waves to cyphermox
[19:50]  * cyphermox waves back
[19:51] <Noskcaj> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700863
[19:51] <Noskcaj> There's two other memory leaks i know of in xubuntu, so if someone could help me with them after the meeting
[19:52] <micahg-work> 1 year with no response from reporter , that bug isn't likely to be addressed
[19:52] <Noskcaj> no
[19:52] <knome> can anybody from the team even confirm that bug?
[19:53] <Noskcaj> It's just blueman uses 40mb of ram here and i've never used bluetooth
[19:53] <micahg-work> that doesn't sound like a memory leak as much as not loading on demand
[19:53] <cyphermox> Noskcaj: guess it would be worth running it through massif
[19:54] <micahg-work> if you said 400MB, that would sound like a memory leak
[19:54] <Noskcaj> I'll leave it on during the day to see if i can reproduce it
[19:54] <cyphermox> micahg-work: it really ought to be running all the time, to be able to get you anything
[19:54] <cyphermox> unless you don't have a bluetooth device of course
[19:54] <micahg-work> cyphermox, right, I have that on one machine, bluetooth is off and it's running
[19:54] <cyphermox> ah
[19:56] <knome> so i guess the gist is that we should use blueman.
[19:56] <knome> great, go file bugs!
[19:56] <knome> (:
[19:57] <knome> #subtopic Discuss documentation translations
[19:57] <knome> we should mostly do this on the docs meeting, but...
[19:57] <elfy> ummm - so what about testing blueman - forget it ?
[19:57] <knome> right... test it!  :)
[19:57] <micahg-work> hrm?
[19:58] <knome> micahg-work, hrm to what?
[19:58] <micahg-work> can launchpad not translate the docs?
[19:58] <micahg-work> hrm to test..
[19:58] <knome> it can
[19:58] <knome> we're doing that.
[19:58] <knome> we have the .po files in the branch
[19:58] <elfy> #action Someone with bluetooth to write a testcase
[19:58] <meetingology> ACTION: Someone with bluetooth to write a testcase
[19:59] <knome> but we need to tweak the packaging to build the translations and display them in a sane way
[19:59] <knome> Unit193 has been helping with that
[19:59] <slickymaster> there are already finish and portuguese versions of the docs
[19:59] <slickymaster> finnish ^^
[19:59] <knome> we also might need/want to set some kind of cut-off percentages, if that's not happening now
[19:59] <knome> micahg-work, if you happen to know about that side as well, poke Unit193 and me..
[20:00] <micahg-work> not too much, I could help on the packaging side
[20:00] <Unit193> knome: It was for me, I have that set up but not sure if any sane person would like it. :P
[20:00] <elfy> I've gtg - thanks - cya
[20:00] <knome> micahg-work, that's probably helpful as well
[20:00] <knome> but ok, let's follow up on that
[20:00] <knome> #topic Schedule next meeting
[20:01] <knome> #info Next meeting Thursday, Feb 6, 19UTC
[20:01] <knome> #endmeeting
[20:01] <meetingology> Meeting ended Thu Jan 30 20:01:21 2014 UTC.
[20:01] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-01-30-18.59.moin.txt
[20:01] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-01-30-18.59.html
[20:01] <pleia2> on the calendar :)
[20:01] <knome> Noskcaj, so what about time- and users-admin?
[20:01] <Unit193> Hah, beat me.
[20:01] <Noskcaj> knome, I have no idea
[20:02] <Noskcaj> elfy has issues with it, i just did ask pitti asked, since i don't know the package very well
[20:02] <knome> Noskcaj, you can't leave a mess behind.
[20:02] <Noskcaj> i know. I think i asked elfy to ask pitti about it
[20:03] <knome> Noskcaj, why can't you ask pitti as you were the one who made the changes?
[20:03] <knome> i can't see why elfy would need to pick it up
[20:03] <Noskcaj> good point. My reasoning was i don't understand the issue
[20:03] <Unit193> micahg-work: I changed the packaging locally to be 'dh7' or dh sequencing, and a couple others.
[20:04] <Unit193> Noskcaj: Issue is, nothing is installed except 'pixmaps', try installing the package.
[20:04] <Unit193> Look at the .install file
[20:04] <Noskcaj> That's how debian has it, strangely
[20:04] <knome> maybe the debian package is broken
[20:04] <Unit193> knome: No, it's not split up.
[20:05] <knome> okay, then maybe the ubuntu port is broken
[20:05] <knome> which leads us to... Noskcaj, please fix it. Unit193 just told you what's wrong
[20:05] <Noskcaj> ok
[20:05] <knome> thanks
[20:06] <Noskcaj> on a different topic, do we want xkb-plugin 0.7 ?
[20:06] <Unit193> https://launchpad.net/ubuntu/+source/gnome-system-tools built packages vs http://packages.qa.debian.org/g/gnome-system-tools.html binaries.
[20:06] <knome> would also think cleaning your mess would help you gaining access rights
[20:06] <knome> re: xkb-plugin; i don't know; is there a very specific reason to have it?
[20:06] <Unit193> xkb-plugin?  Is that seeded?
[20:07] <Unit193> So it is.
[20:08] <knome> i'm off.
[20:08] <Unit193> knome: You know what's proper in a Makefile? :P
[20:08] <knome> see you later :)
[20:08] <Unit193> Bah.
[20:08] <Unit193> Chau.
[20:08] <knome> Unit193, no
[20:08] <Noskcaj> debian dropped back off 0.7, it might be worth seeing if we want it. http://metadata.ftp-master.debian.org/changelogs/main/x/xfce4-xkb-plugin/unstable_changelog
[20:08] <knome> you can tell me and i'll read it when i get back ;)
[20:09] <slickymaster> dinner time for. bbl ->
[20:09] <knome> Noskcaj, that doesn't tell much
[20:09] <knome> but yeah, i'm really off
[20:09] <knome>  ->
[20:20] <Noskcaj> the new xkb plugin is for settings 4.11, and the current one might break settings
[20:21] <Noskcaj> It will also allow us to patch bug 733563
[20:24] <Unit193> slickymaster: Russian is also pretty complete, but not fully.
[20:39] <Noskcaj> Unit193, you're right, all the files are missing from the binary. I'm guessing it's the extra packages we make
[21:05] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-system-tools/regression-fix/+merge/204099
[21:27] <ochosi> hmpf, wasn't able to make the meeting...
[21:30] <Unit193> That's alright, we just assigned everything to you.
[21:33] <ochosi> cool
[21:37] <slickymaster> yeah Unit193, Russian is 84% done
[21:38] <slickymaster> and GridCube has been keeping himself busy, the Spanish translation is half way through it
[21:38] <ochosi> so gtk3-panel and indicators are on hold, eh? :/#
[22:07] <Unit193> slickymaster: Not quite >80% yet though, so not autogenerated.
[22:08] <slickymaster> ok
[22:59] <knome> ochosi, until they work, or until we are so close to FF that we will (have to) land them with a workaround
[23:01] <knome> Noskcaj, fixing that bug is nowhere near our top priority
[23:01] <ochosi> actually the only indicator that doesn't work for me is appindicator at the moment
[23:01] <ochosi> sound and power work just fine
[23:01]  * Unit193 downloaded that one from saucy repos, works fine. :P
[23:02] <ochosi> yeah, but only because there is no upstart job yet
[23:02] <ochosi> (which is why it's borked in the first place i guess)
[23:03] <knome> ochosi, the ubuntu folks do not agree on whether they should have upstart jobs or "actually fix" .. something
[23:03] <Unit193> I like how they land something that's half transitioned, thus broken. :D
[23:03] <knome> yep
[23:04] <knome> but isn't that how it always goes?
[23:04] <ochosi> yeah, but at least the panel we will need if we want gtk3 indicators
[23:04] <knome> "ok boys, this cycle, no breaking stuff"
[23:04] <knome> "oops we landed that too early"
[23:04] <ochosi> that wouldn't be affected by changes to the indicator stack, it would mostly affect xfce4-indicator-plugin
[23:04] <knome> ochosi, well you read my reasoning why we want to hold
[23:04] <knome> ochosi, or why i want to hold
[23:06] <knome> ochosi, the branches stuff is moving forward.
[23:07] <ochosi> yeah, looking forward to that
[23:08] <ochosi> we should definitely try to prepare branches for the case that indicators get fixed with upstart jobs (or even: for the case that we use them)
[23:08] <ochosi> especially a default-settings branch and a seed-branch
[23:11] <Unit193> Yes, but just swap out the indicator-*-gtk2 for indicator-foo.  That's application and sound.
[23:11] <ochosi> well, and add in -power
[23:11] <ochosi> (and set powerman to always hide the trayicon)
[23:11] <Unit193> Doesn't xfpm do whatever that does?
[23:12] <Unit193> Just because we can't doesn't mean we should.  Something about seeding "all" doesn't make sense either, since that'd be at least: indicator-application indicator-appmenu indicator-appmenu-tools indicator-bluetooth indicator-china-weather indicator-cpufreq indicator-datetime indicator-sync indicator-sound indicator-session indicator-printers indicator-power indicator-network indicator-multiload indicator-messages indicator-location ...
[23:13] <Unit193> ... indicator-keyboard
[23:20] <ochosi> yeah, seeding sound, application, power and if needed bluetooth seems good enough
[23:21] <Unit193> Bleh. :P
[23:21] <knome> printers?
[23:21] <ochosi> i think they use app-indicators atm
[23:27] <knome> bluesabre, just don't take too much on your plate :)
[23:27] <Unit193> ^ +1
[23:27] <knome> bluesabre, but i just wanted to let you know people are asking about that
[23:27] <Unit193> I'm still interested as well, I wouldn't purge that.
[23:28] <knome> same.
[23:28] <brainwash> ochosi: and messages?
[23:28] <ochosi> yeah, guess also messages
[23:29] <brainwash> what about printers?
[23:29] <ochosi> but i don't have a strong opinion on messages as i've never used it
[23:29] <ochosi> afaik printers use indicator-application atm
[23:29] <Unit193> Already have something for printers.
[23:29] <knome> my take on it is that some people like it, some people hate it
[23:30] <ochosi> like/hate what?
[23:30] <ochosi> messaging?
[23:30] <ochosi> err, -messages?
[23:30] <knome> yep
[23:31] <ochosi> well i don't have a strong opinion because i've never tried how well it works with out default messaging apps
[23:31] <knome> yep
[23:31] <ochosi> (thunderbird, pidgin..)
[23:31] <knome> well,
[23:31] <knome> it could be a make-or-break thing for *single* users, but not the distro
[23:35] <bluesabre> from my experience, it works great for pidgin and thunderbird
[23:35] <Unit193> Quassel is iffy.
[23:35] <bluesabre> (finally caught up)
[23:36] <Unit193> Click any notification bubbles and up pops quassel...
[23:36] <bluesabre> but... thats not the indicator
[23:36] <bluesabre> :
[23:37] <Unit193> Right.
[23:37] <Unit193> (Quassel works with the indicator though, sort of.)
[23:38] <bluesabre> anybody else think action buttons at the top of a window are stupid? http://worldofgnome.org/a-redesigned-file-picker-4-gnome-mockups/
[23:39] <Unit193> Very.
[23:40] <Unit193> When the Windows Metro UI is starting to look sane....
[23:40] <bluesabre> :)
[23:40] <bluesabre> btw, adding these packages could be a value-add: libappindicator1    libappindicator3-1
[23:41] <knome> value added tax?
[23:41] <bluesabre> they're not pulled by the indicator stack, or indicator-application, yet they are required for skype and dropbox indicators (with no documentation)
[23:42] <bluesabre> and probably others as well
[23:42] <Unit193> Package: nautilus-dropbox -> Recommends: libappindicator1
[23:43] <bluesabre> it might be the 3-1 that is required then
[23:43] <bluesabre> there is an askubuntu about it somewhere
[23:43] <bluesabre> anyway, :_
[23:43] <bluesabre> )
[23:43] <Unit193> indicator-application: Depends: libappindicator3-1  same with network-manager-gnome.
[23:44]  * bluesabre will do more research to figure out what the lib is later
[23:45] <Unit193> libappindicator3-1 is even pulled in onto xubuntu-core, which doesn't even have the indicators. :D
[23:45]  * bluesabre returns to programming
[23:45] <Unit193> bluesabre: Yes, and when you figure out why there is a libappindicator1, libappindicator3-1, libindicate5, libindicator3-7, and libindicator7 tell us?? :P
[23:46] <Unit193> Sure, have fun!
[23:46] <bluesabre> because ubuntu!
[23:47] <ali1234> the ones with -3 are the gtk versions
[23:47] <ali1234> gtk3 versions
[23:47] <Unit193> libappindicator3-1 and libindicator3-7 are hard deps from something because -core pulls those two (and those are the only *indicat* packages.)
[23:47] <Unit193> Ah, hrm.
[23:47] <ali1234> appindicator is how all apps make their own indicators
[23:48] <ali1234> you either use appindicator, or you integrate with an existing indicator (sound, message...)
[23:48] <ochosi> yeah, which makes it suck even more that that one is currently not working in trusty :/
[23:48] <ali1234> appindicator = indicator-application
[23:48] <ochosi> yeah
[23:48] <ali1234> libindicator5 = i have no idea what that is
[23:49] <Unit193> libappindicator1 gtk2, libappindicator3-1 gtk3 and they are for the indicator-application, OK.
[23:49] <ochosi> frankly, i've been wondering since saucy whether we should just try to avoid indicators in our default panel layout
[23:49] <Unit193> 5 is what threw me off, this all makes more sense now except for that.
[23:49] <knome> ochosi, sucks for laptop users
[23:49] <ochosi> there was once talk of an mpris2 plugin for the xfce-panel
[23:49] <ochosi> knome: why?
[23:50] <knome> battery indicator?
[23:50] <Unit193> ali1234: Thanks.
[23:50] <knome> or is there still components for the notification area?
[23:50] <ochosi> knome: we never had an indicator for that
[23:50] <ochosi> that was always a trayicon
[23:50] <knome> what about sound?
[23:50] <Unit193> !info volumeicon
[23:50] <ochosi> that is an indicator, actually the only real one we have
[23:50] <Unit193> !info volumeicon-alsa
[23:50] <brainwash> xfce4-mixer plugin
[23:50] <Unit193> Boom.
[23:50] <knome> alsa, meh
[23:50] <ochosi> Unit193: we need something for pulse though
[23:51] <ali1234> basically without indicators you are stuck using the horrible crappy and broken tray icons, or writing xfce panel plugins
[23:51] <knome> ochosi, ^ that might be your winning answer
[23:51] <Unit193> ochosi: Well, that source package now supports pulse.
[23:51] <knome> i don't think migrating to indicators *itself* is too bad...
[23:51] <ali1234> if you think indicators are bad, tray icons are 100x worse
[23:51] <bluesabre> yes
[23:51] <ochosi> yeah, i agree that trayicons suck
[23:51] <brainwash> why do they suck?
[23:52] <knome> aaand we have a winner ;)
[23:52] <knome> congrats ali1234
[23:52] <ali1234> no multimonitor support, not process separation...
[23:52] <bluesabre> thing is, everything will be significantly easier once there is an official gtk3 xfce4-panel
[23:52] <knome> bluesabre, now you're kidding ;)
[23:52] <bluesabre> no more hacky workarounds
[23:52] <bluesabre> when we get that
[23:52] <bluesabre> in 2017
[23:52] <ochosi> well in fact the current git-panel handles it okay
[23:52] <knome> besides, didn't you go back to programming?
[23:52] <bluesabre> after gtk5 is out
[23:52] <knome> ochosi, isn't that what we're going to land in T?
[23:52] <ali1234> there wont be a gtk5
[23:52] <bluesabre> there's interesting discussion here
[23:53] <ali1234> there will be nothing left to remove by gtk4
[23:53] <knome> procrastinating, i see
[23:53] <bluesabre> haha
[23:53] <ochosi> anyhow, i think i'll try to do releases for our themes now, adding in support for gtk3 indicators, in case they ever land...
[23:53] <ochosi> ali1234: hehe, good point
[23:53] <knome> ochosi, they will, one way or another
[23:53] <bluesabre> ali1234: what about all the stuff they are adding in gtk3? they can get rid of that :)
[23:53] <knome> ochosi, they aren't on infinite hold, just "for now"
[23:53] <knome> ochosi, don't worry!
[23:54] <knome> i hate to see ochosi sad
[23:54] <ochosi> knome: yeah, trying hard to start loving the bomb...
[23:55] <knome> i hate even more when ochosi is ironic, but kind of right
[23:55] <dr_strangelove> maybe that helps
[23:55] <dr_strangelove> meh, doesn't seem to help...
[23:56] <ochosi> ali1234: quick question, as that's kinda relevant for our default panel setup, are you aiming at 14.04 with panel-switch?
[23:56] <ali1234> no, not really
[23:56] <ochosi> okey
[23:56] <knome> ali1234, maybe you should ;)
[23:56] <knome> push, push, push!
[23:56] <ali1234> i noticed that debian has a tool for this already
[23:57] <ali1234> when you first log in it asks you what layout you want
[23:57] <knome> does it bring half of gnome?
[23:57] <ali1234> you only get two choices though
[23:57] <ali1234> i dunno, it's installed y default
[23:57] <ochosi> that sounds nice actually
[23:57] <ochosi> i mean only being asked once is kinda "hmmm"
[23:57] <ochosi> but still
[23:58] <knome> doesn't allow experimenting
[23:58] <knome> so it's really "meh"


[13:36] <progre55> hi guys. I've got a server, with ubuntu enterprise cloud installed, and from time to time it just freezes. No ssh connection. But I cant even connect to it using a monitor and a keyboard, so I have to force-boot it. Cant seem to find anything in the logs. Any suggestions, please? what logs to check?
[13:54] <flaccid> could be hardware
[14:33] <progre55> flaccid: what log files could I check? or any suggestions on how to check hardware parts?
[14:33] <flaccid> not sure. check /var/log/*
[14:33] <flaccid> someone else might chime in here later
[14:37] <progre55> flaccid: couldnt find anything useful in /var/log/*
[14:37] <progre55> everything seems to be normal..
[14:37] <flaccid> thats why its likely hardware imo
[14:38] <progre55> I see.. well, let me google on how I can check ram, hd and cpu for defects )
[14:38] <progre55> flaccid: thanks
[14:38] <flaccid> np
[15:59] <smoser> flaccid, jeremydei and i talked a bit, and for 11.04 we're hoping to get rightscale onto "official ubuntu ami"s
[15:59] <flaccid> that sounds awesome!
[16:00] <flaccid> i'm trying to find time to finish off my debian builder template and images
[16:00] <flaccid> hopefully within the next week
[16:00] <smoser> https://bugs.launchpad.net/bugs/668400
[16:01] <flaccid> jeremydei did mention this to me. by 'onto' do you mean including the rightlink package or still just using instance user-data to install it?
[16:02] <flaccid> ah yeah, supporting both user-data formats
[18:23] <patrickw> Is there a trick involved in running centos kernels on UEC instances?  I'm trying to update the kernel on a centos 5.3 euca certified image, but when I try to use the RH kernel (from yum update) my networking doesn't seem to start correctly.


[02:58] <Guest57746> beta testing 18.10
[02:58] <Guest57746> qt
[02:58] <Guest57746> niice
[02:58] <tsimonq2> *alpha
[02:58] <Guest57746> yas,
[02:58] <tsimonq2> We haven't hit Beta yet. :)
[02:58] <Guest57746> thats what i meant
[02:58] <tsimonq2> Guest57746: Maybe join #lubuntu-devel and lurk there? :D
[02:58] <Guest57746> fiiiiine ;)
[12:28] <Caerus> Good day everyone, maybe someone has ran into this issue.  I have a lubuntu 18.04 box with PostgreSQL 10.5 (Ubuntu 10.5-0ubuntu0.18.04) and I can´t figure out why is it that that pg doesnt listen on the eth0 ip address when the server boots, only upon restarting it I see the two: <IP_ADDRESS>:5432; <IP_ADDRESS>:5432
[12:29] <Caerus> by restarting I mean postgreSQL, as in sudo services postgresql restart
[15:52] <Ascavasaion> I did a distribution upgrade too latest LTS and now machine hangs on boot.  I left it for a while and it goes into hibernation or standby mode.  I don't know how to roll back to old version and I need access to the computer urgently.
[15:56] <leszek> Try failsafe mode
[15:58] <Ascavasaion> leszek... I tried that... got to the desktop .. but there was no launcher bar at the bottom and got do nothing.
[15:59] <Ascavasaion> need to know how to fix it.  I have urgent work I need to do on the machine tonight and not the upgrade has broken the machine.
[16:02] <leszek> Ascavasaion: all package upgrades went fine? sudo apt install -f in terminal might repair stuff. Start terminal with Ctrl+Alt+T when on desktop even without panel
[16:03] <leszek> otherwise you can also try starting lxpanel manually and see if it works
[16:04] <leszek> for future reference never do something big like an dist upgrade on the same day on a work critical machine if you don't have a bootable backup at hand
[16:10] <Ascavasaion> how would I get to command line from botched desktop with no launcher?
[16:13] <Ascavasaion> Windows key and R and then lxterminal
[16:14] <Ascavasaion> oh... never saw your ctrl alt +T... thank you


[04:52] <mup> PR snapd#8260 opened: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260>
[08:03] <pstolowski> morning
[08:46] <mup> PR snapd#8257 closed: tests: backport master test fixes <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8257>
[08:50] <mup> PR snapd#8241 closed: interfaces: work around apparmor_parser slowness affecting uio <Bug> <Reviewed> <Squash-merge> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8241>
[08:55] <mup> PR snapd#8261 opened: interfaces: work around apparmor_parser slowness affecting uio (2.44) <Created by pedronis> <https://github.com/snapcore/snapd/pull/8261>
[08:58] <pedronis> pstolowski: hi, I asked a question in #8235
[08:58] <mup> PR #8235: cmd/snap-preseed: handle --reset flag <Preseeding 🍞> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8235>
[08:59] <pstolowski> pedronis: yes, i saw it, thanks, will get to it soon
[09:13] <mup> PR snapd#8255 closed: cmd/snap: make the portal-info command search for the network-status interface <Reviewed> <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8255>
[09:20] <pedronis> pstolowski: can you look at #8248 if you have a moment, is not super urgent, OTOH is small
[09:20] <mup> PR #8248: snap: introduce Container.RandomAccessFile <Created by pedronis> <https://github.com/snapcore/snapd/pull/8248>
[09:20] <pstolowski> ok
[09:21] <pedronis> also it relates (indirectly) to UC20 needs
[09:24] <mup> PR snapd#8003 closed: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8003>
[09:26] <pedronis> pstolowski: thanks for landing that ^
[09:27] <pstolowski> i'm equally happy about landing it finnaly
[10:29] <pedronis> pstolowski: thansk for checking, we might do something also about fonts, but maybe we don't see changes because there are not fonts in the image?
[10:29] <pstolowski> pedronis: checking
[10:36] <pedronis> pstolowski: ah, no, on ubuntu the cache for those is in var  (it's in usr for some other distros)
[10:36] <pstolowski> yes, that's right
[10:36] <pedronis> pstolowski: it's /var/cache/fontconfig  but I'm not even sure we need to undo if we do something there, or whether we can
[10:37] <pedronis> it's a cache and it's not just touched by snapd
[10:39] <pstolowski> pedronis: that's right. i don't think re-running fc-cache makes any sense
[10:39] <pedronis> pstolowski: yea, agreed
[10:39] <pstolowski> / so yeah, spread test picked change to /usr.../completions
[10:40] <pedronis> yes, that we need to fix
[10:40] <pedronis> thanks for checking as I said
[10:40] <pstolowski> yep, on it
[10:45]  * zyga waves
[10:45] <zyga> everyone at home but me has a stomach bug
[10:45] <zyga> I suspect I got "lucky" because first symptoms started before I returned from Fra
[10:46] <zyga> so I may be off early next week as well, depending on how the situation develops
[10:46] <pstolowski> zyga: ironic..\
[10:46] <zyga> right?
[11:03] <alvesadrian> Hi, squashfs is read only. We are trying to make gluu snap package. As our previous experience showed that we may change any file in the snap for security or bug fixes.
[11:03] <alvesadrian> Currently we trying to figure out any file/directory that gluu services want to write.
[11:03] <alvesadrian> But this won't be enough for us. We may need to edit/replace any file inside the snap
[11:04] <alvesadrian> We are using containers and everything is writable, when we switch to snap it will be read only
[11:04] <zyga> alvesadrian: that's pretty hard to do
[11:04] <zyga> alvesadrian: can you just ship a new snap revision?
[11:04] <zyga> alvesadrian: everyone will update anyway
[11:04] <alvesadrian> snap reivsion?
[11:04] <alvesadrian> wharts that?
[11:04] <zyga> alvesadrian: if you make a snap you get a blob which is the squashfs filesystem
[11:05] <zyga> alvesadrian: instead of making changes to the files at runtime (application files, not data) you can just make another blob
[11:05] <zyga> alvesadrian: and put that to the store
[11:05] <zyga> alvesadrian: delta downloads should be fast and efficient
[11:05] <zyga> alvesadrian: so instead of shipping a snap with a self-update mechanism
[11:05] <zyga> alvesadrian: just upload subsequent revisions of the snap
[11:06] <alvesadrian> we still playing we dont have a full app ready
[11:06] <alvesadrian> we found this squashfs issue
[11:06] <alvesadrian> and we are not sure how to sort it
[11:06] <alvesadrian> for writeable files
[11:06] <zyga> alvesadrian: my advice: disable the self-update
[11:06] <alvesadrian> we dont even finish to build the app
[11:06] <zyga> alvesadrian: and let snapd handle that aspect
[11:10] <zyga> alvesadrian: how are you building the app?
[11:10] <alvesadrian> zyga snapcrft command
[11:11] <zyga> alvesadrian: when you said "we dont even finish to build the app" does that mean you still are in progress of working on the packaging?
[11:12] <alvesadrian> we are playing with parts of our big app
[11:12] <alvesadrian> is a java app
[11:12] <zyga> I see
[11:12] <alvesadrian> we are using parts to packafe it and see how it works
[11:12] <alvesadrian> just a war file
[11:12] <alvesadrian> with jetty
[11:14] <alvesadrian> @zyga one momment a coworker is comming online
[11:14] <alvesadrian> with more details
[11:14] <alvesadrian> zyga : ^^^^^
[11:14] <zyga> alvesadrian: I'm off today, just helping while I'm in the office
[11:14] <alvesadrian> one moment
[11:14] <zyga> alvesadrian: I'm afraid I won't be around much longer
[11:14] <alvesadrian> please
[11:14] <zyga> sure,
[11:15] <zyga> just saying I can respond more slowly
[11:16] <alvesadrian> slvn_ mustafa is that u?
[11:17] <alvesadrian> damn
[11:26] <alvesadrian> zyga this is mbaser my co worker
[11:26] <alvesadrian> zyga he has some concerns
[11:26] <alvesadrian> zyga can u help us?
[11:27] <alvesadrian> zyga can he ask u a few things?
[11:27] <alvesadrian> zyga are you still around?
[11:27] <alvesadrian> mbaser drop ur concern to zyga
[11:29] <zyga> just ask the questions please
[11:30] <alvesadrian> mbaser are u reding us?
[11:30] <alvesadrian> reading us?
[11:30] <zyga> perhaps forum.snapcraft.io might be easier?
[11:32] <alvesadrian> zyga no worries we can back later
[11:32] <alvesadrian> zyga he is having some connection issues
[11:32] <zyga> sure
[11:32] <alvesadrian> thanks
[11:32] <zyga> I'm online 24/7 but not always reading
[11:33] <zyga> so try asking your questions and just check for answers later
[11:33] <zyga> the forum is easier to use
[11:33] <zyga> and better for asynchronous conversations
[12:42] <pedronis> pstolowski: I made a comment in #8217
[12:42] <mup> PR #8217: o/devicestate: delay the creation of mark-seeded task until asserts are loaded <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8217>
[12:42] <pstolowski> pedronis: ty. updated #8235
[12:42] <mup> PR #8235: cmd/snap-preseed: handle --reset flag <Preseeding 🍞> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8235>
[12:55] <pedronis> pstolowski: thx, made a comment about the helper you are using there, it's actually a bit odd
[12:59] <pstolowski> pedronis: by that you mean to fix the helper to literally match on "snapd/complete.sh" right?
[12:59] <pedronis> pstolowski: to match that the end of target is like that, yes
[13:00] <pstolowski> ok, makes sense
[13:00] <pedronis> I mean /snapd/complete.sh
[13:00] <pedronis> really
[13:00] <pstolowski> right
[13:00] <pedronis> I don't know why the helper is like that
[13:00] <pedronis> is used in a couple of places
[13:00] <pedronis> but haven't closely at them
[13:00] <pstolowski> indeed, it's a bit naive
[13:00] <pedronis> but I looked at the helper in dirs that makes the targets
[13:01] <pedronis> and afaict they will always have snapd in them
[13:02] <mup> PR snapd#8248 closed: snap: introduce Container.RandomAccessFile <UC20> <Created by pedronis> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8248>
[13:07] <pedronis> cmatsuoka: thank for merging that
[13:08] <cmatsuoka> pedronis: thanks for the patch, that should help moving secboot ahead
[13:08] <pedronis> we'll need it for our own cross checking bits as well I think
[13:13] <mup> PR snapcraft#2972 opened: [rfc] catkin plugins: remove bash workaround for old catkin bug <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2972>
[13:31] <mup> PR snapcraft#2970 closed: providers: match build provider flag keys to envvar <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2970>
[15:11] <pedronis> cmatsuoka: I made a maybe annoying comment in #8159, I'm just a bit unsure why we need more passes on things
[15:11] <mup> PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
[15:13] <cmatsuoka> pedronis: thanks, I'll check that right after lunch
[15:13] <pedronis> cmatsuoka: let me know if you have questions
[15:45] <pstolowski> pedronis: search v2 is in production
[16:01] <mup> PR snapcraft#2973 opened: specifications: add core20 plugin specification <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2973>
[16:06] <mup> PR snapd#8262 opened: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks/** <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8262>
[16:43] <mup> PR snapd#8263 opened: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks2/** - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8263>
[17:31] <thresh> when I do snapcraft snap, would environment variables I set in my shell propagate to override-build: section in the snapcraft.yaml ?
[17:36] <ackk> thresh, well if you use override-build you can just export variables as part of that. otherwise you can use build-environment (see https://snapcraft.io/docs/parts-environment-variables)
[17:37] <thresh> ackk, I probably need to add some more context.  I export some variables in the CI that I would like to check when I'm doing snapcraft snap (inside the yaml, so inside the override-build).
[17:38] <thresh> I guess my question is "does snapcraft snap sanitize env(1) when doing the builds?"
[17:39] <ackk> thresh, AFAIK it does
[17:39] <thresh> there's only one way to check. (which I'm doing right now) :-)
[17:53] <thresh> ok, I think it actually works and the variable is there
[17:53] <thresh> as in I can see it in "env" output when doing the build
[18:21] <sergiusens> thresh: if you are in --destructive-mode or not using bases, the env should make it through
[19:08] <mup> PR snapcraft#2973 closed: specifications: add core20 plugin specification <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2973>
[19:26] <mup> PR snapcraft#2960 closed: specification: base plugin and plugins for core20 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2960>
[19:38] <thresh> sergiusens, I'm not using destructive mode, and my snapcraft.yaml has base: core18; env makes it through
[19:39] <thresh> so, eh.  I'm on snapcraft 2.43.1+18.04 (from .deb)
[20:12] <sergiusens> thresh: oh, so no real support for bases then, environment should just passthrough
[20:13] <thresh> sergiusens, will it change when I upgrade?
[20:13] <thresh> I'm building inside (a somewhat outdated) 18.04 non-privileged docker container.
[21:14] <mup> PR snapcraft#2974 opened: project_loader: use -isystem instead of -I for system include paths <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2974>
[21:47] <sergiusens> thresh: if you are not using a base (in snapcraft.yaml), then I would recommend 16.04 as the container
[21:48] <sergiusens> thresh: this might help with what bases are https://snapcraft.io/docs/base-snaps (but you need snapcraft 3.x)
[21:49] <sergiusens> thresh: and docs on snapcraft 3.x with docker https://snapcraft.io/docs/build-on-docker