[00:20] <JackFrost> boosabre: And IRCCloud seems to have just reset something.
[00:21] <bluesabre> Sure enough!
[00:21] <bluesabre> Later boosabre
[00:22] <bluesabre> brainwash: please log a bug for xfwm with your findings
[00:28] <bluesabre> JackFrost: commented on that screensaver bug, thanks
[00:29] <JackFrost> You're doing all the hard work. :3
[00:48] <JackFrost> We need boosabre back.
[06:48] <astraljava> Hey folks, I was just told that on support channel that light-locker is not even in development anymore. What is the reasoning it's the default choice, still? Just no better alternative available? :D
[06:51] <astraljava> Nevermind, I have not waken up, yet, apparently. Need More Coffee™
[07:21] <JackFrost> xfce4-screensaver! ++
[07:26] <ochosi> astraljava: that's not really accurate. it's maintained by and default in elementaryOS
[07:29] <ochosi> it's true that neither me nor peter are activr anymore in the project
[07:41] <astraljava> ochosi: Ok, thanks for the clarification.
[07:42] <astraljava> JackFrost: Yes, I noticed that's what I actually use on my machine. Now to figure out why it randomly locks my session without user action.
[10:03] <brainwash> bluesabre: you still don't see the bug? have an up-to-date xubuntu 20.04 and start the session with the compositor being disabled.
[10:03] <bluesabre> brainwash: didn't check yet... I just don't use the session without the compositor which is why I would have overlooked it.
[10:04] <brainwash> if it really is a vbox driver bug... then reporting against xfwm4 won't help much I guess
[10:05] <brainwash> I will test with something like openbox too
[10:05] <bluesabre> I'll test it in qemu/kvm
[10:07] <bluesabre> Definitely doesn't seem to be the case in 19.10 on hardware after just turning the compositor off
[10:08] <brainwash> you have to restart the session
[10:08] <bluesabre> vbox has been pretty unstable for quite a while now :\
[10:09] <bluesabre> Alrighty, I can restart my session now, bbiab
[10:10] <bluesabre> brainwash: sure enough, it crashes it on hardware as well after the session is restarted
[10:10] <bluesabre> turning the compositor back on resolves it, so it's an Xfwm bug
[10:11] <brainwash> I tried with openbox, no crash
[10:11] <brainwash> will open a report then
[10:11] <bluesabre> thanks


[00:01] <tsimonq2> In case nobody saw it yet: https://lists.ubuntu.com/archives/ubuntu-release/2018-April/004438.html
[00:03] <Guest31513> I'm downloading the image now to give it a try. Would like to investigate the hyper-v enhanced session functionality
[07:05] <Laibsch> Can I still make an upload to a package with a targetted bugfix backported from upstream to a package in universe, a package I maintain in Debian where I have upload rights?  I have upload rights as PPU.  Should I target bionic or bionic-proposed?
[07:06] <Laibsch> I did read https://wiki.ubuntu.com/FinalFreeze and it is not entirely clear to me what I should do now.
[07:07] <Laibsch> I am trying to fix bug 1345605
[07:07] <Laibsch> BTW, the topic of the channel needs an update, doesn't it?
[07:10] <tsimonq2> There.
[07:19] <Laibsch> tsimonq2: Hi! In case you responded to me, I missed everything except the "There" due to internet outage.
[07:21] <tsimonq2> I didn't.
[07:21] <tsimonq2> :)
[07:24] <Laibsch> good, so I assume you just wanted to announce that you're back.
[07:24] <Laibsch> Welcome back!
[07:24] <Laibsch> I had posted a question that I will then assume that you missed and that I believe you might be able to answer.
[07:24] <tsimonq2> Ah, looking.
[07:24] <Laibsch> Can I still make an upload to a package with a targetted bugfix backported from upstream to a package in universe, a package I maintain in Debian where I have upload rights?  I have upload rights as PPU.  Should I target bionic or bionic-proposed?
[07:24] <Laibsch> I did read https://wiki.ubuntu.com/FinalFreeze and it is not entirely clear to me what I should do now. I am trying to fix bug 1345605. BTW, the topic of the channel needs an update, doesn't it?
[07:25] <tsimonq2> Is it seeded? (hint: run `seeded-in-ubuntu $package`)
[07:25] <Laibsch> Oh, I see you just did the update of the channel tagline.
[07:25] <tsimonq2> Yep. :)
[07:25] <Laibsch> I doubt it would be seeded, it is in universe
[07:25] <Laibsch> let me check
[07:27] <Laibsch> indeed, it is NOT seeded, so I can make the upload?
[07:27] <tsimonq2> Yep, if it isn't seeded, Feature Freeze applies.
[07:27] <tsimonq2> (Which is less strict.)
[07:28] <Laibsch> Yes, this only fixes a broken but current feature.
[07:28] <tsimonq2> OK.
[07:28] <tsimonq2> So, go ahead. :)
[07:28] <Laibsch> Thanks
[07:28] <Laibsch> Much appreciated
[07:29] <tsimonq2> No problem.
[07:29] <tsimonq2> And as to which you should target, target bionic.
[07:29] <Laibsch> good
[07:29] <tsimonq2> The only time you include a pocket in the changelog is for -backports or -security.
[07:30] <tsimonq2> It doesn't /hurt/ to target -proposed but it's just a tad bit weird. :)
[07:49] <Laibsch> well, the wiki says a bit otherwise.  apparently, you're supposed to target -proposed for main now
[07:49] <Laibsch> https://wiki.ubuntu.com/FinalFreeze
[07:49] <tsimonq2> That hasn't been edited since 2012.
[07:50] <Laibsch> Well, maybe it hasn't changed since then
[07:50] <tsimonq2> Notably, before we implemented https://wiki.ubuntu.com/ProposedMigration
[07:50] <Laibsch> I wouldn't know the processes well enough
[07:50] <tsimonq2> I know for a fact it has changed. ;)
[07:50] <Laibsch> good
[07:50] <Laibsch> I'm happy I can rely on your knowledge
[07:51] <tsimonq2> Believe me when I say I've had to cut it close with some uploads. :P
[07:51] <Laibsch> One more question, am I correct to assume that binaries are thrown away after upload?
[07:51] <Laibsch> I'm used to Debian where I used to upload and then sync
[07:52] <tsimonq2> You can only do source-only uploads to Ubuntu.
[07:52] <tsimonq2> So syncs throw away binaries.
[07:53] <Laibsch> But what happens if you do include debs in your changes file and upload?
[07:54] <Laibsch> things break or the binaries simply get thrown away and rebuilt?
[07:54] <tsimonq2> The upload will get rejected.
[07:54] <Laibsch> OK
[07:54] <tsimonq2> cjwatson might have more specifics; I'm only an Ubuntu developer and don't have upload access to Debian (yet). :)
[07:55] <darkxst> tsimonq2, hi
[07:56] <tsimonq2> darkxst: Hello, how are you?
[07:56] <darkxst> I am good
[07:56] <tsimonq2> Good to hear, what's up?
[07:57] <darkxst> tsimonq2, just wondering if grasp the value in archive freezes, doesnt seem you do from your reply
[07:58] <tsimonq2> I do understand the importance of them, but I disagree that they're still needed.
[07:58] <tsimonq2> If flavors can just upload whatever they want and respin, you won't ever get a release, because flavors can just keep respinning.
[07:58] <tsimonq2> Why even turn off the dailies? :)
[07:59] <tsimonq2> The archive freezes are to create a stable image, true, but the day after, the fixes people have been holding off on get uploaded.
[07:59] <tsimonq2> Thus, a stale image over that weekend.
[08:00] <darkxst> well flavours could just choose to leave the dailies on if they want
[08:00] <darkxst> but really having a semi-frozen archive where the flavours choose what to upload but universe etc is blocked out in general would allow you to make the most of your QA week
[08:00] <valorie> darkxst: can you say more about what you value in the freezes?
[08:01] <valorie> because I've not heard the release team argue for keeping them
[08:01] <tsimonq2> darkxst: So, an inverted freeze?
[08:01] <tsimonq2> That's an interesting idea.
[08:01] <darkxst> valorie, I am not release team, I was Ubuntu GNOME tech lead
[08:01] <valorie> that blocks the release team
[08:02] <valorie> yes, read your email just now
[08:02]  * valorie is the kub release manager and not so techy
[08:02] <tsimonq2> darkxst: Thinking about it though, the inverted freeze would just create a headache for non-flavor Ubuntu developers.
[08:03] <tsimonq2> The goal here is to not require any intervention from ~ubuntu-release.
[08:03] <valorie> I get why we need deadlines for new features, string freezes, etc.
[08:03] <darkxst> valorie, assuming its on a similar schedule to previous milestones is that a problem
[08:03] <valorie> that's obvious
[08:03] <valorie> right, but I fail to see the value in freezing
[08:04] <tsimonq2> Me too.
[08:04] <valorie> if you are testing and finding bugs, then the devels are fixing the bugs
[08:04] <valorie> then you can test those fixes right away
[08:04] <valorie> not wait until freeze is over
[08:05] <darkxst> valorie, if you don't freeze, other bugs may well creep in
[08:05] <valorie> but I want to hear the argument for what freezes bring
[08:05] <valorie> such as?
[08:05] <tsimonq2> Right, but that's where testing comes in.
[08:05] <darkxst> valorie, you have a moving target, who knows what will change
[08:05] <valorie> well
[08:06] <tsimonq2> darkxst: But that's the development release...
[08:06] <valorie> you are testing AN iso
[08:06] <darkxst> freezes give a point in time image, testers identify issues, the dev's can focus on fixing those issues
[08:06] <valorie> that's one moment in time
[08:06] <tsimonq2> Right.
[08:06] <valorie> for this RC somehow kub. managed to test all the test cases
[08:07] <valorie> so respinning tomorrow would be cool
[08:07] <darkxst> the point the milestones become stale is after the release, not when they are released
[08:07] <valorie> because we could at least partially re-test
[08:07] <tsimonq2> And often times, people report bugs after the release.
[08:07] <tsimonq2> With the release ISO.
[08:07] <tsimonq2> And they don't update.
[08:07] <tsimonq2> That's a problem.
[08:07] <tsimonq2> Much less so once you've entered a point where the archive is more stable.
[08:08] <darkxst> tsimonq2, even if you don't release milestone images, I think there is value in freezeing for your QA week (well days really)
[08:08] <valorie> I'm waiting to hear the advantages
[08:08] <valorie> can you give an example?
[08:09] <darkxst> valorie, I can;t give a real example, because its never been done before (unfrozen test weeks)
[08:10] <valorie> I meant a case where freezing was a benefit
[08:10] <valorie> all the people who test the dailies don't have freezes
[08:10] <valorie> although I don't have many DO that
[08:10] <valorie> I mean, I don't know how many do that
[08:10] <darkxst> and how much QA is done on the dailies?
[08:11] <alkisg> Freeze is a good signal for "everyone, please test now". I develop some packages and I want to test them 1-2 times for the new LTS Ubuntu version, but I can't test on a daily basis.
[08:11] <tsimonq2> alkisg: But is that a technical argument or a social one?
[08:11] <valorie> we do have a few people who test a daily maybe one a week
[08:11] <tsimonq2> The point of this is to not have the technical downsides while keeping the social benefits.
[08:11] <valorie> or when a devel asks
[08:12] <valorie> because they did a fix on the installer for instance
[08:12] <alkisg> I don't think it matter how I would categorize it; that's how much time I'm able to spend in helping/testing the newer Ubuntu; it's up to the release team to somehow tell me when they want me to do those tests
[08:12] <valorie> or something else easier to test on an ISO than in a ppa
[08:13] <valorie> alkisg: I think part of the point of this is to take that pressure off the release team, and have us flavors helping one another out
[08:13] <tsimonq2> alkisg: Exactly. And if the Release Team said "test at this time" but didn't actually freeze anything, would that change things?
[08:13] <valorie> all getting together to do testing weeks
[08:13] <tsimonq2> valorie: Exactly.
[08:13] <alkisg> tsimonq2: a new package upload might break other packages, making my tests useless
[08:14] <alkisg> So it would make sense for me to test at a point when the new uploads were minimal
[08:14] <alkisg> Now, minimal or frozen, no, it's not a big deal, but they should be minimal
[08:14] <valorie> I'm still not seeing your point
[08:14] <valorie> does it matter when this new package upload is made, if it is going to break your stuff?
[08:15] <valorie> I mean if you test before and everything's cool
[08:15] <valorie> and then the upload is made later, your stuff is broken.....
[08:15] <darkxst> valorie, often things break on upload, only to be fixed a few days later
[08:15] <darkxst> not you just wasted time debugging that breakage
[08:15] <darkxst> s/not/now/g
[08:15] <valorie> right, and that's why we shouldn't freeze!
[08:15] <valorie> lol
[08:16] <darkxst> which would have been fixed anyway
[08:16] <darkxst> rather than focusing on your flavours QA
[08:16] <alkisg> valorie: that's exactly my point, that that new upload that breaks stuff shouldn't be made. That's the point of the freeze, that only minor changes should be made after that, so that the big bulk of tests don't need to be done again
[08:16] <valorie> well, I think that is the point of doing the new auto-testing *first*
[08:16] <tsimonq2> alkisg: Only seeded packages for some flavors are frozen.
[08:17] <valorie> so there are *never* uploads that break stuff
[08:17] <Laibsch> valorie: that's never going to happen
[08:17] <alkisg> You can't test how your packages affects other packages with unit testing; they may not even be installed at all when you're testing
[08:17] <Laibsch> autotests are nice, but "no bugs" is utopia
[08:17] <tsimonq2> alkisg: I'm not saying we should get rid of the Final Beta freeze. I'm saying we should get rid of the freezes for just some flavors.
[08:17] <valorie> no, no
[08:17] <tsimonq2> That's the point here.
[08:17] <darkxst> valorie, what I was suggesting was more let flavours upload bug fixes as required, but otherwise freeze the archive for the few days
[08:17] <valorie> software has bugs
[08:18] <valorie> ah
[08:18] <valorie> so imo that is probably what flavors would be doing anyway that week, right?
[08:18] <valorie> testing week is fixing bugs
[08:18] <alkisg> tsimonq2: I don't mind at all if it's complete freeze or partial freeze or just "advice for fewer uploads"; but as a developer/user that wants to help make things better, I do like having a specific point in time where "my tests have additional value, because from that point on, little changes are going to be made"
[08:19] <valorie> I dunno if we need a formal freeze
[08:19] <tsimonq2> alkisg: The Alpha and Beta 1 freezes just aren't that.
[08:19] <tsimonq2> alkisg: It's putting a name on a daily, really.
[08:19] <valorie> but I do see a value on Fixing Bugs
[08:19] <valorie> for a week
[08:19] <tsimonq2> alkisg: You could grab any ISO from any point in the month and say "I'm going off of this"
[08:20] <tsimonq2> alkisg: And with those freezes, changes can and will be made in the underlying stack, but just those flavors hold off.
[08:20] <tsimonq2> alkisg: So this new procedure does just that.
[08:21] <darkxst> if there is no formal freeze, churn will continue
[08:21] <tsimonq2> Churn continues regardless.
[08:21] <valorie> personally I would rather not block the release team
[08:21] <tsimonq2> People just hold their breaths and then blast it at the archive once the freeze is done.
[08:21] <tsimonq2> So why even freeze?
[08:21] <valorie> because it is hell to have major stuff still happening the last week of the cycle
[08:22] <darkxst> tsimonq2, because it you a specific point to focus on
[08:22] <darkxst> you can fix the bugs addressed, before more are raised
[08:22] <valorie> I think we are all stating positions here
[08:22] <valorie> rather than thinking together
[08:22] <darkxst> without having to worry about what else churns
[08:22] <valorie> we all want more quality
[08:22] <valorie> we all want fewer bugs
[08:23] <valorie> and we all want the shiny new stuff too
[08:23] <valorie> so what is the best way to get there?
[08:23] <valorie> we have only 6 months to make each batch of sausage
[08:24]  * alkisg sees little value in the non-LTS releases, but that's another story :D
[08:24] <valorie> really?
[08:24] <valorie> I do not like to be on stale anything
[08:24] <tsimonq2> darkxst: The only bugs fixed during that time are release-critical ones. Not just plain old bugfixes. So I still think it's pointless.
[08:24] <alkisg> Yeah, I would much prefer having only LTS releases, and some method for package maintainers to more easily push new versions of their packages to LTS releases
[08:24] <valorie> I ran artful from the day the toolchain was uploaded
[08:25] <valorie> alkisg: that removes the value of LTS
[08:25] <valorie> imo
[08:25] <alkisg> I think it adds additional value
[08:25] <alkisg> I'm hearing a lot of users that would prefer newer versions of *some* packages in LTS releases
[08:25] <darkxst> tsimonq2, which is way I was saying to relax it a bit
[08:25] <valorie> well, there is always backports
[08:26] <valorie> that is what kub provides
[08:26] <tsimonq2> Regardless of the talk we're having right now, I've received ACKs from everyone with skin in the game. So I think it's worth trying, at least for a cycle. We can tweak it as we go, and as we see how it turns out.
[08:26] <alkisg> Indeed; but backports aren't used as much as they should...
[08:26] <valorie> I dunno if our users use them enough, but I often urge them to try them out
[08:27] <valorie> because if it doesn't work out, ppa-purge is your friend
[08:27] <alkisg> Backports aren't in ppas
[08:27] <alkisg> They're in the official archive
[08:27] <valorie> we test those too
[08:27] <darkxst> tsimonq2, valorie, I was only only offering my thoughts based on 5 years of releasing Ubuntu GNOME milestones, I have no vested interest in the outcome of these discussion, but if you are all going to be so defensive I will just get on with the others thing I need to get done
[08:27] <valorie> in Kubuntu, we have a backport PPA
[08:28] <alkisg> valorie: that's usually a bad idea, mate does that too and I hate it
[08:28] <valorie> no, I wanted to hear your reasons
[08:28] <alkisg> It would make a lot more sense to use backports there, rather than a PPA
[08:28] <valorie> I just didn't hear reasons
[08:28] <valorie> or examples
[08:28] <tsimonq2> darkxst: I'm not being defensive, I just see the idea being shot down before there's a chance to try it, that's all.
[08:29] <tsimonq2> s/being/trying to be/
[08:30] <valorie> I know that Simon didn't develop the idea alone; he discusses pros and cons with quite a few people (not me) before making the proposal
[08:31] <valorie> I spoke only after the release team said that they supported it, because to me that is the most important opinion
[08:33] <darkxst> tsimonq2, shot down by who?
[08:35] <tsimonq2> darkxst: Maybe I'm using the term liberally, but this discussion is happening as a result of making it official.
[08:35] <tsimonq2> (It seems like it, anyway.)
[08:35] <tsimonq2> I gave a good three weeks between the discussion and doing so.
[08:36] <darkxst> tsimonq2, no this has nothing to do with that, just I didnt get a chance to comment earlier
[08:36] <valorie> I'm glad to hear differing opinions
[08:36] <darkxst> again I have no vested interest in the result
[08:36] <valorie> just wish they had been stated earlier
[08:37] <valorie> groupthink can be an issue when people don't push back when they have reservations about a new idea
[08:37] <darkxst> valorie, unfortunately I have full-time job unrelated to ubuntu, which makes me kind of busy
[08:37] <valorie> yeah
[08:38] <valorie> anyway, creeping carrot will be a non-LTS
[08:39] <valorie> so if it doesn't work out well, we have time to revert to milestones and freezes, or modify slightly
[08:39] <tsimonq2> *Calculating Camel
[08:39] <tsimonq2> And, right.
[08:43] <darkxst> freezes are useful even if there is not an official milestone image to come out of it!
[08:44] <valorie> well, the lack of them might prove you right, darkxst
[09:30] <Laibsch> What do you guys use to prepare the changes file to upload?  For uploads to Debian (that requires binaries to be included) I used to use pbuilder and now cowbuilder.  But now I need a source-only changes file and haven't quite figured out yet how to do that.
[09:31] <Laibsch> I only build in a chroot like pbuilder, my main machine has very few if any dev-packages installed.
[09:40] <Laibsch> answering for myself, looks like it might be as easy as "dpkg-genchanges" even if the manpage says the source needs to have been built which outside of the chroot it hasn't been.
[09:43] <darkxst> Laibsch, sbuild
[09:44] <Laibsch> darkxst: thanks, I will look into. Never used it so far and never had to.
[09:45] <Laibsch> "debuild -S -d" or even simply "dpkg-buildpackage -S -d" (AFAIU, debuild calls dpkg-buildpackage)
[09:45] <darkxst> Laibsch, see sbuild-launchpad-chroot it produces almost identical environment to the Ubunutu archive and PPA builders
[09:46] <darkxst> Laibsch, and in chroot, so your not mutating your package sources
[09:46] <Laibsch> dpkg-buildpackage seems to do it
[09:46] <darkxst> you can also bootstrap debian into sbuild quite easily
[09:46] <Laibsch> well, same is true for pbuilder and I'm more familiar with that
[09:47] <Laibsch> but in the end, I think it seems to be necessary for Debian since you need to actually build the code and ship the binaries, the requirements for Ubuntu infrastructure apparently are already fulfilled by a lower-level tool like dpkg-buildpackage
[09:48] <darkxst> Laibsch,  are you uploading to ubuntu?
[09:48] <Laibsch> yes
[09:48] <darkxst> then use sbuild-launchpad-chroot
[09:49] <darkxst> to test
[09:49] <Laibsch> test what?
[09:49] <cjwatson> debuild -S or any near-enough equivalent is fine, indeed.  Just building a source package doesn't usually need much in the way of build-deps.
[09:49] <darkxst> package builds, before uploading
[09:49] <Laibsch> thanks for confirming, cjwatson
[09:49] <Laibsch> darkxst: I already built and started the package
[09:49] <cjwatson> And indeed, tsimonq2 is correct, if you attempt to include .debs with an upload it will be summarily rejected.
[09:49] <Laibsch> cjwatson: I tried ;-)
[09:51] <Laibsch> or actually, what I tried was to fiddle with the changes file, remove the lines for the binary files so they would not be uploaded but it was still rejected (I assume because the changes file name had "amd64" in it, indicating an arch-dependent build)
[09:51] <cjwatson> Editing .changes manually is fiddly.  Not recommended.
[09:51] <Laibsch> I know
[09:51] <cjwatson> And for Debian nowadays you should really do source-only uploads too, except in unusual circumstances.
[09:51] <Laibsch> First attempt
[09:51] <Laibsch> really?
[09:51] <Laibsch> didn't know
[09:51] <cjwatson> Really.
[09:52] <Laibsch> Well, no more uploads to debian for me anyhow.
[09:52] <tsimonq2> cjwatson: When can we have source-only NEW in Debian? :P
[09:53]  * tsimonq2 wishes for that.
[09:53] <Laibsch> looks like the upload was successful and accepted
[10:03] <cjwatson> tsimonq2: Do I look like a Debian ftpmaster?
[10:04] <acheronuk> kirkland: byobu no longer shows a ubuntu logo in bionic?
[10:06] <tsimonq2> cjwatson: I was joking there. :P
[10:06] <tsimonq2> Right, time for bed.
[10:07] <Laibsch> tsimonq2: are you in Hawaii or something?
[10:09] <tsimonq2> No, Wisconsin.
[10:30] <Laibsch> ouch
[10:30] <Laibsch> interesting time to go to sleep ;-)
[10:30] <Laibsch> happy Zzz
[16:28] <realies> the novnc package is missing its launch script, any clues why?
[16:31] <realies> https://github.com/novnc/noVNC/blob/master/utils/launch.sh
[16:31] <realies> ^
[16:46] <realies> also is very old, the newer releases have great improvements
[19:25] <ken2812221> load C:\Users\User\AppData\Roaming\HexChat\addons\google_translator.py
[19:25] <ken2812221> sorry
[19:27] <ginggs> file not found
[21:15] <valorie> the /topic is weeks out of date!
[21:16] <cjwatson> In what way?


[02:00] <ubotu> New bug: #107805 in xorg (main) "Thinkpad T60p ati 5250 video card not "completly" detected; result is powerstate not lowered when on battery power" [Undecided,Confirmed]  https://launchpad.net/bugs/107805
[04:50] <ubotu> New bug: #21416 in xserver-xorg-video-via (main) "KN400: Blank / black screen when switching to text consoles" [Medium,Needs info]  https://launchpad.net/bugs/21416
[04:50] <ubotu> New bug: #51964 in xserver-xorg-input-mouse (main) "Upgrading to <IP_ADDRESS> cause Gnome's panel and taskbar to disappear (PPC)" [Medium,Needs info]  https://launchpad.net/bugs/51964
[04:55] <ubotu> New bug: #52288 in xorg (main) "Extras buttons of Microsoft Comfort Optical Mouse 3000 doesn't work." [Low,Needs info]  https://launchpad.net/bugs/52288
[05:51] <ubotu> New bug: #55739 in xorg (main) "No more mouse events" [Medium,Needs info]  https://launchpad.net/bugs/55739
[06:00] <ubotu> New bug: #38031 in linux-source-2.6.15 (main) "ps/2 mouse not recognized on IBM X21 laptop" [Medium,Needs info]  https://launchpad.net/bugs/38031
[08:35] <ubotu> New bug: #51133 in xserver-xorg-video-sis (main) "X crash on IBM thinkcentre" [Medium,Rejected]  https://launchpad.net/bugs/51133


[01:21] <akgraner> hey all  - I'm working on updating  https://wiki.ubuntu.com/Team can someone update the artwork team listing please?
[01:21] <akgraner> https://wiki.ubuntu.com/Teams


[03:42] <AndroUser> anyone use ubuntu phone
[04:30] <jr_> Is there any news on ubuntu touch being able to be installed on tablets? I realize there are a few projects for select devices. but I mean to be installed on tablets in general
[06:00] <Lurrdock> Hello
[06:04] <lesamourai> Hello , ubuntu aquarius 5 phone  entered boot loop , any possible solution?
[06:07] <Stanley00> lesamourai: well, did you try reflash with the rom from bq?
[06:08] <lesamourai> reset to factory settings is only thing I tried and it didn't solve it
[06:10] <lesamourai> and now its constantly rebooting ..
[06:10] <Stanley00> lesamourai: ok, you can try reflash then, here's the tools http://www.bq.com/gb/support/aquaris-e5-ubuntu-edition
[06:12] <lesamourai> thanks , will go through them
[08:39]  * guest42315 they see me rollin' la la la
[09:36] <JamesTait> Good morning all; happy Thursday, and happy Punctuation Day! 😃
[10:02] <Inoki> JamesTait: woot woot! Happy Thursday to you too!
[10:12] <tathhu> Ayyy
[14:33] <kenvandine> jdstrand, i'm working on surfacing some apps installed inside libertine containers in the peer picker, how would you feel about adding a rule like this to the content_exchange policy to allow read access to the icons?
[14:33] <kenvandine> @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons/*
[14:37] <jdstrand> kenvandine: that would all untrusted apps to enumerate installed apps on the system
[14:38] <kenvandine> well, the themed icons
[14:38] <kenvandine> they might not be provided by the apps... but i see your point :/
[14:38] <kenvandine> jdstrand, they already have access to the themed icons... in /usr/share/icons/
[14:41] <jdstrand> kenvandine: yes, that's true. perhaps I don't understand what is in @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons/*
[14:42] <jdstrand> I don't care at all about access to themed icon sets
[14:42] <jdstrand> in general
[14:42] <kenvandine> that's the directory for themed icons inside the containers
[14:42] <jdstrand> however, iiuc, anything that is installed via apt-get might get themed icons
[14:43] <kenvandine> yes
[14:43] <jdstrand> which means an untrusted app could enumerate what the user installed in the container
[14:43] <kenvandine> just by finding the icons, but quite a few of those are there without matching apps
[14:43] <kenvandine> they could potentially compare what's inside the default sets of icon themes and look for extras
[14:44] <kenvandine> to deduce the delta
[14:44] <jdstrand> yes. like I said, any system supplied ones are fine because that doesn't leak anything about the user
[14:44] <jdstrand> right
[14:46] <kenvandine> jdstrand, so since they could try to compare what icons are there, i need to find another way to show the icons in the peer picker, right?
[14:47] <kenvandine> getting the image data from a themed icon requites a qguiapplication :/
[14:47] <kenvandine> and i really don't want to turn content-hub-service into that
[14:47] <jdstrand> kenvandine: that is what I'm thinking yes. I might suggest that the out of process picker either displays it, or opens it and passes the fd
[14:48] <kenvandine> it isn't an out of process picker right now
[14:48] <kenvandine> that's the issue, the picker is a qml component in process
[14:48] <jdstrand> oh
[14:48] <kenvandine> we use the service side to marshal the icons for click apps
[14:48] <jdstrand> hmm
[14:48] <kenvandine> the ones we get full paths to the icons for
[14:48] <kenvandine> but we can't get that for themed icons
[14:49] <kenvandine> it's a hard problem :/
[14:49] <kenvandine> i could get a pixmap if the service was a qguiapplication
[14:49] <kenvandine> and marshal it over dbus as well
[14:49] <kenvandine> but i really don't want to do that
[14:52] <jdstrand> kenvandine: I'm not clear on what makes qguiapplication different. in that case it will talk to some out of process other service?
[14:53] <jdstrand> is that the thumbnailer?
[14:53] <kenvandine> it would essentially be a gui app without a window
[14:54] <jdstrand> right, but why does that work?
[14:55] <kenvandine> QIcon::fromTheme will load a pixmap for the icon
[14:55] <kenvandine> nothing out of process
[14:55] <kenvandine> but maybe something like the thumbnailer could help us
[14:55] <kenvandine> i hadn't considered that
[14:55] <kenvandine> maybe we can generate thumpnails for icons in the container
[14:56] <jdstrand> why does QIcon::fromTheme not also need access to those icons? because it is guaranteed to be FromTheme?
[14:58] <jdstrand> if thumbnailing is fine, we can stop talking. I just am trying to understand why clicks get dbus marshalled data container apps don't. perhaps it all works for click because /usr/share/icons is guaranteed to not have user installed data but the container's /usr/share/icons does?
[15:00] <kenvandine> the clicks have paths to the files for the icon
[15:00] <kenvandine> so i can read those in as iconData and marshal it
[15:01] <kenvandine> so i don't use QIcon for that
[15:01] <kenvandine> jdstrand, but to get a themed icon i have to use QIcon which doesn't work as a non-gui service
[15:02] <kenvandine> i'll look into thumbnailer
[15:02] <jdstrand> oh I see. installed apps in the container don't have any sort of hooks so that you know what to marshal
[15:02] <kenvandine> right
[15:02] <kenvandine> just .desktop files with icon names
[15:02] <jdstrand> gotcha
[15:03] <jdstrand> kenvandine: keep in mind (and you probably realize this already), generating the thumbnails and giving access to all thumbnails in the directory is just pushing the problem. but seems creative use of the thumbnail service might be able to get you there
[15:03] <kenvandine> i was hoping we could provide access to that path since /usr/share/icons is accessible on the device
[15:04] <jdstrand> yeah
[15:04] <jdstrand> but those directories are managed differently unfortunately
[15:04] <kenvandine> but that just exposes the icons for what's installed on the device by default, users can't change that
[15:04] <jdstrand> oh right
[15:04] <jdstrand> you only waant the themed ones
[15:04] <kenvandine> yeah
[15:04] <jdstrand> yes, that's totally fine
[15:05] <kenvandine> same as in the container
[15:05] <jdstrand> kenvandine: perhaps add a comment somewhere strategic in the code so we don't forget why that's fine :)
[15:05] <kenvandine> so you're ok with  @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons/*
[15:05] <kenvandine> right?
[15:05] <kenvandine> since it's just the themed icons?
[15:06] <jdstrand> ok, now I'm confused again
[15:06] <kenvandine> ok... nevermind
[15:06] <kenvandine> i think i was briefly confused by what you said :)
[15:06] <kenvandine> so it's fine to allow access on the default system
[15:06] <kenvandine> but not in the container
[15:06] <kenvandine> because they could deduce the delta
[15:06] <jdstrand> when I install via apt-get an application in the container, do icons get put in /usr/share/icons? my understanding is 'yes', so that is not an ok path
[15:07] <kenvandine> they get installed in /usr/share/icons of the container
[15:07] <kenvandine> which is something like @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons
[15:07] <jdstrand> 10:06 < kenvandine> so it's fine to allow access on the default system
[15:07] <jdstrand> yes
[15:07] <jdstrand> 10:06 < kenvandine> but not in the container
[15:07] <jdstrand> 10:06 < kenvandine> because they could deduce the delta
[15:07] <jdstrand> correct
[15:07] <kenvandine> ok, so i do need to look into the thumbnailer :)
[15:07] <kenvandine> for the themed icons
[15:08] <jdstrand> so, if you can tease out the system themed icons in @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons in some manner (eg, generate thumbnails of those and put them somewhere), that is fine
[15:09] <kenvandine> and i can add a rule to allow access to where those get cached
[15:09] <jdstrand> exactly
[15:09] <kenvandine> like ~/.cache/content-hub/icons/*
[15:09] <jdstrand> or use an existing path. whatever makes most sense
[15:09] <jdstrand> sure
[15:10] <jdstrand> perhaps it would make sense to use ~/.cache/content-hub/themed-icons/*
[15:10] <jdstrand> or something so that people understand that app icons won't go in there
[15:12] <kenvandine> jdstrand, noted
[15:12] <kenvandine> i hope the thumbnailer can do theme lookups
[15:13] <kenvandine> i bet it has the same problem... not a gui app
[15:14] <kenvandine> i'd hate to have to make the thumbnailer cache all the installed icons
[15:19] <jdstrand> I bet the thumbnailer will work fine
[15:19] <jdstrand> but, the trick will be can the app ask the thumbnailer for an icon that is an app icon and get a result
[15:20] <jdstrand> ie, it can enumerate apt-get installed apps by trial and error
[15:20] <jdstrand> kenvandine: ^
[15:20] <kenvandine> no...
[15:20] <kenvandine> this would be done from the service side
[15:20] <kenvandine> which already has a list of installed apps in the container
[15:20] <kenvandine> in the peer list
[15:20] <kenvandine> for the peer picker
[15:21] <kenvandine> so the service side will need to hand a icon name for a themed icon to the thumbnailer to have it cache it
[15:21] <kenvandine> then our image provider in the qml (app) side could use that cached icon
[15:21] <kenvandine> if the thumbnailer can cache an icon with just a theme path and icon name
[15:28] <kenvandine> jdstrand, thumbnailer requires a path to the file, and if i could get that for the themed icon i could marshal the iconData like i do for the clicks :/
[15:29] <kenvandine> jdstrand, back to exposing what's installed inside the container... any app with content_exchange will be able to see what apps are installed by requesting a peer list
[15:30] <kenvandine> so i don't think allowing access to  @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons increases that exposure
[15:37] <jdstrand> kenvandine: I'm surprised by the peer list comment. that seems like maybe something that needs revisiting? either way, there is a difference though. with clicks apps opt into using content_exchange, ie, they want to be known to other apps. with apt-get in the container, there is no differentiation
[15:38] <jdstrand> that said, I thought one of the points of the content-hub was so that apps didn't know the other side
[15:38] <kenvandine> true... but it's a way to provide access to get content to those apps
[15:38] <kenvandine> they know the other side exists
[15:38] <kenvandine> but not direct access to their content
[15:38] <kenvandine> what we're doing is letting you do something like opening an image from the gallery in gimp
[15:39] <jdstrand> hrm, I thought that worked differently
[15:39] <kenvandine> so gallery shows a list of possible apps to send the content too
[15:39] <kenvandine> using the ContentPeerPicker component
[15:40] <jdstrand> like, user click share in the app, out of process helper whows user a list of choices, the user picks the choice, the out of process helper launches the choice, give the out of process helper the data which gives it to the app
[15:40] <kenvandine> the helper provides the list, but the component that shows the list is in the app's process
[15:40] <jdstrand> (so that is the reverse direction of what you are talking about, but rephrasing it for the other direction would be the same)
[15:40] <kenvandine> we've recently started talking about an out of process app for the picker that does an overlay
[15:41] <jdstrand> I think that is a problem
[15:41] <jdstrand> (not the overlay, the current display)
[15:41] <jdstrand> I thought the content picker used a tps like thing
[15:41] <kenvandine> there was plans for tps, but just to embed the other app inside the requesting app
[15:42] <kenvandine> not the peer picker itself
[15:42] <jdstrand> because, you are right-- there is no point in blocking access to /usr/share/icons in the container today if all of that is exposed in another way. but that shouldn't be exposed in any way
[15:42] <kenvandine> but we discussed that being tps too
[15:42] <kenvandine> bfiller, maybe we need to get the work for the out of process picker scheduled
[15:42]  * jdstrand doesn't care if it is tps or something else, but we are trying hard not to enumerate apps wherever possible
[15:43] <kenvandine> bfiller, that we talked about back in austin
[15:43] <kenvandine> getting that out of process solves a bunch of these issues
[15:43] <kenvandine> jdstrand, so until we get that work done, can we add access to that icons dir for container apps?
[15:44] <kenvandine> that'll be a big task, and we need the container apps for pd
[15:44] <jdstrand> kenvandine: yes, but we need to file an appropriately prioritized bug for getting the other bits fixed
[15:47] <bfiller> kenvandine: out of process as in trust session right?
[15:48] <kenvandine> yeah, the overlay thing
[15:48] <kenvandine> we had talked about something that runs and fills the same space as the keyboard rectangle
[15:54] <kenvandine> bfiller, the tough thing is going to be deprecating the existing ContentPeerPicker that apps are using
[15:55] <kenvandine> actually, maybe we can just make ContentPeerModel private... so apps can only show peers inside our UI, not programatically list them
[15:55] <bfiller> kenvandine: yup, going to have to think about planning for this in upcoming sprint
[15:56] <kenvandine> i don't know of any apps using the model directly
[15:57] <kenvandine> it'll be tricky to do that... anyway, we need to start planning it
[15:57] <kenvandine> getting that out of process solves all of these themed icons problems i have :)
[15:57] <kenvandine> but it isn't a short term fix :)
[17:20] <shd_> how do i find out what kills my "powerd-cli active" ?
[22:36] <pdanek> Does Ubuntu phone have SElinux or apparmor running by default please?
[22:36] <jjohansen> pdanek: apparmor by default, and you can configure selinux and use that if you prefer
[22:37] <pdanek> jjohansen: thx
[22:37] <jjohansen> oh hrmm, actually you can't use selinux on the phone, that is for the desktop.  Eventually you might be able to use it on the phone, but that would require work that has not been done
[22:38] <jjohansen> pdanek: ubuntu phone apps are very locked down
[22:39] <pdanek> makes sense
[22:41] <jjohansen> pdanek: https://developer.ubuntu.com/en/start/platform/guides/app-confinement/
[22:42] <popey> i doubt we'll implement selinux
[22:42] <popey> we use apparmor
[22:44] <jjohansen> popey: right, at first I missed the phone bit, you can install selinux for the desktop, its more work and community supported
[22:44] <jjohansen> for the phone however, someone would have to do a lot of work
[22:50] <pdanek> Can Ubuntu Touch run Android apps already?
[23:26] <JanC> pdanek2: no (not yet, at least)