[07:16] <lordievader> Good morning
[08:58] <xrandr_mac> Can I install ubuntu server from. The network install cd?
[10:04] <RoyK> xrandr_mac: so long that you have network access during the installation, yes - I've used that a lot
[10:38] <RoyK> any idea what to do when I try to make a package and I get this error? http://paste.debian.net/1074553/
[11:22] <supaman> RoyK: is there a debian directory and it contains a changelog file?
[11:28] <RoyK> supaman: there's a debian dir, but no changelog file, so I forged one and with a little trouble, it worked
[11:28] <supaman> great :-)
[13:48] <coreycb> jamespage: sahid: i'm going to sweep up the remaining rc's for stein. i don't think there are many.
[13:53] <PaulePanter> Hi. Installing ubuntu-server (bionic), I am only asked to configure the DNS server by the installer and not the rest of the network configuration (DHCP/static).
[13:53] <sahid> coreycb: ack, do you need some help? I can do some
[13:53] <PaulePanter> I then have to edit the netplan configuration manually in the live system.
[13:54] <coreycb> sahid: i think we're good, thanks. we can split up the final release when that comes around.
[13:54] <sahid> coreycb: ok sure we will do that :)
[13:55] <coreycb> sahid: james has smoke tests passing on the current proposed packages so we'll re-run that and we'll need to manually test dashboards
[14:01] <jamespage> coreycb: ta - just a few I think
[23:24] <sveinse> Trying to install latest ubuntu 18.04 LTS server on a VM and the installer crashes when I'm trying to set manual ipv4 address, starting the installer all over again :(
[23:25] <sarnold> that sounds vaguely familiar
[23:32] <tomreyn> sveinse: probably bug 1816954
[23:46] <Maxel> hi, I ran into a problem I thought I solved but apparently did not. My boot partition is only 500mb and it has 0 bytes free. I was trying to do an upgrade and now I'm stuck
[23:46] <Maxel> I see some guides saying I can boot from a different disc of linux and try to repartition the disk, but wanted to see if anyone thinks that's a terrible idea on here before I accidentally break something
[23:47] <mwhudson> Maxel: are you booted?
[23:47] <sveinse> Maxel: It happened to me all the time on my old server. You probably have older kenels taking up all the space. uninstall them first, and then you can install the upgrade
[23:47] <sarnold> I wouldn't go down that route, no..
[23:47] <Maxel> yeah, it's a vm I have
[23:47] <mwhudson> you should be able to remove some kernels
[23:47] <Maxel> running on esxi
[23:47] <sarnold> I'd just truncate some kernels with "> /boot/vmlinuz-...." -- pick old ones
[23:47] <sarnold> then dpkg --purge that old version
[23:47] <Maxel> I would like to solve the tiny boot partition eventually, but I need to free up some space first
[23:48] <mwhudson> what does dpkg -l linux-image-*-generic | grep ^ii show?
[23:48] <Maxel> remind me what the util to pipe output to pastebin is?
[23:48] <mwhudson> pastebinit
[23:49] <Maxel> http://paste.ubuntu.com/p/VWc835NQ4F/
[23:49] <mwhudson> yes ok you probably don't need all of those :)
[23:50] <sarnold> try to keep the newest one or two, and whatever kernel you're running now
[23:50] <Maxel> I think I messed this up once though, what's the safe way to remove these? I just deleted the files and got myself in trouble
[23:50] <mwhudson> apt remove linux-image-4.4.0-134-generic
[23:50] <mwhudson> (for example)
[23:51] <mwhudson> like sarnold says probably best not to remove the kernel you are actually running
[23:51] <sarnold> truncate one file with > /boot/vmlinuz-whatever ... to free up storage; then you can dpkg --purge the package that owned the file
[23:51] <Maxel> just fill the file with 0 bytes you mean?
[23:51] <mwhudson> then upgrade to bionic where this kind of stuff doesn't pile up in the same way :)
[23:52] <mwhudson> (not necessarily helpful advice i realize)
[23:52] <mwhudson> Maxel: yes
[23:52] <mwhudson> well not fill the file
[23:52] <Maxel> is that 18.04? cause that's what I was trying to actually do here
[23:52] <mwhudson> replace the file with a 0 byte file
[23:52] <mwhudson> Maxel: yes
[23:52] <Maxel> ls -l
[23:52] <Maxel> whoopsies
[23:53] <Maxel> just cause I'm extra worried, so can I just do: echo "" > vmlinuz-4.4.0-128-generic
[23:55] <sarnold> maybe; I've always used > filename to truncate files
[23:55] <sarnold> using echo in that fashion may try to make a new directory entry and thus fail to allocate memory
[23:55] <Maxel> no need to echo anything, just lead with the >
[23:55] <sarnold> right
[23:58] <Maxel> trying to purge the package now: dpkg: warning: ignoring request to remove vmlinuz-4.4.0-128-generic which isn't installed


[00:00] <rickspencer3> RAOF, robert_ancell, tremolux, TheMuso, shall we go ahead?
[00:00] <TheMuso> sure
[00:00] <tremolux> ready
[00:00] <RAOF_> Yes.
[00:00] <rickspencer3> RAOF, we'll start with you, since you are first on the list
[00:01] <rickspencer3> RAOF did you get any kind of projection for WI through put?
[00:01] <RAOF_> I only had 4 WI in Lucid, and they took ~1.5 weeks.  That's not really enough data to project from, I think.
[00:02] <rickspencer3> so, like 3 per week
[00:02] <rickspencer3> RAOF_ didrocks came up with 5 for himself, so shall we estimate 4 for you to start, maybe?
[00:02] <RAOF_> That seems reasonable.
[00:03] <rickspencer3> so that's 24 total for A2
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-video-bugs-in-the-kms-world
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-easy-wayland-testing
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-gpu-freeze-reports
[00:04] <rickspencer3> RAOF are those all of your blueprints for maverick?
[00:04] <robert_ancell> rickspencer3, how are you getting that list?
[00:04] <rickspencer3> they seem to have work items, and to be less than 24
[00:04] <rickspencer3> robert_ancell, go here:
[00:04] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/maverick?searchtext=desktop-maverick
[00:04] <rickspencer3> and sort by assignee
[00:04] <robert_ancell> and manually count work items?
[00:04] <rickspencer3> pretty much, yeah
[00:05] <RAOF_> Yep, those are all of them.
[00:05] <rickspencer3> RAOF, do you see any reason not to target them all for A2?
[00:05] <RAOF_> Oh, no, missed one.
[00:05] <rickspencer3> basically get them all done by June 24th?
[00:05] <rickspencer3> can you paste me a link to the one I missed?
[00:06] <RAOF_> Yeah, grabbing it.
[00:06] <rickspencer3> oops, there are only 5 weeks now
[00:06] <rickspencer3> so 20 work items total
[00:06] <RAOF_> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-rootless-x
[00:06] <rickspencer3> so the first 4 brings you to 17
[00:07] <RAOF_> This bumps it to 23
[00:07] <rickspencer3> RAOF lots of work items there, so maybe target rootless x to A3?
[00:07] <rickspencer3> https://wiki.ubuntu.com/MaverickReleaseSchedule
[00:07] <rickspencer3> or do you feel that it *must* be done for maverick?
[00:08] <RAOF_> No.  It's a nice-to-have.
[00:08] <rickspencer3> ok
[00:08] <rickspencer3> I'm targeting the first 4 to A2, the rootless x one to A3
[00:08] <rickspencer3> sound ok?
[00:08] <RAOF_> The other work items are mostly about getting good bugs and being able to deal with them - that's more imporltant.
[00:08] <RAOF_> I'm fine with that.
[00:09] <rickspencer3> sweet
[00:09] <rickspencer3> next is tremolux
[00:09] <tremolux> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-software-center-front-end
[00:09] <rickspencer3> tremolux, were you able to calculate a WI throughput?
[00:10] <tremolux> it's going to be a little complicated for my case
[00:10] <tremolux> because we have community folks who are likely to grab some things
[00:10] <rickspencer3> how does 4 per week sound as an estimate?
[00:10] <tremolux> yes, that seems fine, 4-5 or so
[00:10] <rickspencer3> yeah, that can increase productivity
[00:11] <tremolux> so I have 17 here for alpha-2
[00:11] <rickspencer3> tremolux, I think you'll have a tad less maintainer work than other folks, at least to start
[00:11] <tremolux> yep
[00:11] <rickspencer3> so maybe 5 is a good number
[00:11] <rickspencer3> so 17 is just right
[00:11] <rickspencer3> I only see one blueprint currently targeted for you:
[00:11] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-software-center-front-end
[00:11] <tremolux> yep, but I will likely have some work items on other blueprints
[00:12] <tremolux> https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-opportunistic-apps-stable-release
[00:12] <tremolux> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-software-center-dynamic-appview
[00:12] <tremolux> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-software-center-dynamic-testing-improvements
[00:12] <tremolux> https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-oneconf
[00:12] <rickspencer3> does this have all the buy something and cool apps work items?
[00:12] <tremolux> these bad boys
[00:12] <rickspencer3> aha
[00:12] <tremolux> no, this doesn't
[00:12] <rickspencer3> so across those 5 blueprints, you have a total of 17 work items right now?
[00:13] <tremolux> I think about 20, not counting the ones that I have past a-2
[00:13] <rickspencer3> ok
[00:14] <rickspencer3> we need to pick for A2
[00:14] <tremolux> oh, do we have the buy apps blueprint? not yet, right?
[00:14] <rickspencer3> tremolux, correct, not yet, you are blocking on me to work out how to track LP work items
[00:14] <rickspencer3> so those need to be, for sure, in A2
[00:14] <tremolux> right, definitely
[00:14] <rickspencer3> how many did you have from that one?
[00:15] <rickspencer3> I see the work items, but I don't see which are for you
[00:15] <tremolux> yes, I think I have "any UI work"
[00:15] <rickspencer3> heh
[00:16] <rickspencer3> ok, so I see there is a lot of work here, and the work items have been identified
[00:16] <rickspencer3> but the 20 that you will sign up for in A2 haven't been called out yet
[00:16] <rickspencer3> we'll have to take care of that tomorrow
[00:17] <rickspencer3> tremolux, can you look through all of these specs, and see which ones you think you need to pick off for A2, including the "ghost spec" for buy something?
[00:17] <tremolux> yes, it's a little tricky because mvo and I dynamically divide up work historically
[00:17] <rickspencer3> ah
[00:17] <rickspencer3> hmmm
[00:17] <tremolux> we grab from a bucket  :)
[00:17] <tremolux> but we don't have to do that
[00:17] <rickspencer3> I see
[00:17] <rickspencer3> well ... we shouldn't bust a functional work flow
[00:17] <tremolux> it's fine to sign up, much better for tracking
[00:17] <rickspencer3> let's do both
[00:17] <tremolux> ok
[00:17] <rickspencer3> sign up for say 15
[00:18] <tremolux> that sounds good
[00:18] <rickspencer3> maybe not 15, but the number that 1. should be done in A2 and 2. are very UIish, so most likely you will do
[00:18] <rickspencer3> however, I do need to know between you, what you are committed to delivering in A2
[00:19] <rickspencer3> even if many of the work items are unassigned
[00:19] <tremolux> yep
[00:19] <rickspencer3> tremolux, do you think you have enough information to identify the A2 work items tomorrow?
[00:19] <tremolux> yes, I already made a cut for my spec
[00:20] <rickspencer3> I'm concerned I'm not being clear
[00:20] <rickspencer3> ok, it sounds good, then
[00:20] <rickspencer3> the blueprint certainly have a lot of analysis in them
[00:20] <tremolux> and tomorrow I'll work with mvo to 1. pare my list if necessary and 2. add items for me in the other specs
[00:20] <rickspencer3> sounds great
[00:20] <rickspencer3> rock
[00:20] <tremolux> cool
[00:20] <rickspencer3> any other concerns, etc...?
[00:21] <tremolux> nope!  sorry everyone for the diversion from the noob
[00:21] <tremolux> :)
[00:21] <rickspencer3> software center is a bfd for Maverick!
[00:21] <rickspencer3> welcome to the team :)
[00:21] <rickspencer3> tremolux, tbh, we're all noobs at this ;)
[00:21] <tremolux> haha, thanks!  \o/
[00:21] <rickspencer3> next on the list is TheMuso
[00:22] <rickspencer3> TheMuso, have you calculated a WI throughput?
[00:22] <TheMuso> rickspencer3: No, I haven't. You know me and graphs, and given the fact I didn't really have much in the way or work items last cycle, and that I don't have many this cycle, its not exactly that easy to do so.
[00:22] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-gnome3-accessibility-readiness
[00:23] <rickspencer3> TheMuso, that's fine
[00:23] <rickspencer3> we all have different jobs
[00:23] <TheMuso> rickspencer3: That spec has turned out to be more informational
[00:23] <rickspencer3> that's why the system is flexible
[00:23] <rickspencer3> TheMuso, I see some things there that could be turned in WIs
[00:24]  * TheMuso looks again...
[00:24] <rickspencer3> TheMuso, let's talk more next week
[00:24] <TheMuso> ...and doesn't see things that could be WIs.
[00:24] <rickspencer3> let me think
[00:25] <rickspencer3> I'd like to see some commitments to technical progress in both accessibility and sound
[00:25] <rickspencer3> but I think we need to discuss more
[00:25] <rickspencer3> sound ok?
[00:25] <TheMuso> Well other than getting the bits from upstream, there is not much else that could be a work item.
[00:26] <TheMuso> and since we are starting to be more conservative with things...
[00:26] <rickspencer3> that sounds like you are planning just to integrate upstream bits this cycle
[00:26] <TheMuso> but ok sounds reasonable
[00:26] <rickspencer3> which is good and important
[00:26] <rickspencer3> but I'd like to see us go beyond that
[00:27] <rickspencer3> robert_ancell, were you able to calculate a WI throughput estimate?
[00:28] <robert_ancell> I don't think I have enough data from the last cycle, I'm thinking the 20-25 team estimate sounds about right
[00:29] <rickspencer3> cool
[00:29] <rickspencer3> robert_ancell, I only see this one blueprint for you:
[00:29] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-shotwell
[00:29] <rickspencer3> are there others that haven't been accepted yet?
[00:29] <robert_ancell> I'll be doing a large chunk of work on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-gnome
[00:29] <rickspencer3> I seem to recall some change mail from your blueprints
[00:29] <rickspencer3> aha
[00:29] <rickspencer3> of course
[00:30] <rickspencer3> erk
[00:30] <robert_ancell> all the new things I planned seb removed from the maverick schedule
[00:30] <rickspencer3> looks like lots of tough ones
[00:30] <rickspencer3> robert_ancell, right ... that didn't mean you were banned from doing those
[00:30] <robert_ancell> I was also signed up to getting PyGI working (foundations blueprint) but it doesn't seem to be on the Maverick schedule
[00:30] <rickspencer3> just, not to commit to them
[00:30] <robert_ancell> Also https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-shotwell
[00:30] <rickspencer3> PyGI is not on the schedule!!
[00:31] <rickspencer3> robert_ancell, I think shotwell maybe end up more maintainer work than expected
[00:31] <rickspencer3> how many work items do you have in A2 total?
[00:31] <robert_ancell> I don't have a lot of work items for these, as not sure how to divide, e.g. for GNOME should I make "Package 2.31.1", "Package 2.31.2" to break it up?
[00:31] <rickspencer3> I'm wondering if you are feeling like you could do more?
[00:32] <robert_ancell> based on comitted work, yes
[00:32] <rickspencer3> robert_ancell, do you feel like the current plan has you under-utilized?
[00:32] <rickspencer3> if so, we should consider bringing back one of your other blueprints
[00:33] <robert_ancell> sure, we should discuss priorities
[00:33] <rickspencer3> for this stuff:  for GNOME should I make "Package 2.31.1
[00:33] <rickspencer3> I think I wouldn't make work items, per se
[00:33] <rickspencer3> that sounds more like regular maintainer work
[00:34] <robert_ancell> they do represent chunks of work, so not sure if that's worth tracking or not
[00:34] <rickspencer3> well ... if it's recurring and rote, it's probably worth accounting for, as in it will take up time, but not work tracking
[00:34] <rickspencer3> if that makes sense
[00:35] <robert_ancell> acounting != work tracking?
[00:35] <rickspencer3> no
[00:35] <rickspencer3> like I could assume you are going to do 20 hours per week of maintainer work on gnome, for example (made up number)
[00:36] <rickspencer3> so I would account for that by knowing that you only have 20 more hours a week to work
[00:36] <rickspencer3> but I would track the flow of maintainer work
[00:36] <rickspencer3> it will just get done
[00:36] <robert_ancell> ok
[00:37] <rickspencer3> robert_ancell, I hate to think of  you not having awesome projects that you are motivated to work on
[00:37] <robert_ancell> just to run back, "PyGI is not on the schedule", was that a statement of suprise or "it's not supposed to be on the schedule"
[00:37] <rickspencer3> well, it was a statement of surprise
[00:38] <rickspencer3> I would have thought it was a bit tricky to land and make it work
[00:38] <rickspencer3> but maybe not
[00:38] <rickspencer3> I know this is totally vague, btw
[00:38] <robert_ancell> ok, shall we discuss after the meeting which project to put on schedule
[00:38] <rickspencer3> well first, what do you think?
[00:39] <rickspencer3> does it need to be tracked, etc...?
[00:39] <robert_ancell> Color management is the interesting one I'd like to try
[00:39] <rickspencer3> hmmm
[00:39] <robert_ancell> which I know you want to talk about anyway :)
[00:39] <rickspencer3> ok
[00:40] <rickspencer3> robert_ancell, are doing the PyGI work specifically yourself, or are there other people involved?
[00:40] <rickspencer3> I ask, because I care about this a lot for certain developer experience stuff we are workign on
[00:40] <rickspencer3> like the easy and fun telepathy API
[00:40] <robert_ancell> rickspencer3, I'm doing the packaging (I've done some work this week, but it's not working)
[00:41] <rickspencer3> ah
[00:41] <robert_ancell> so it should be working by default in Maverick asap
[00:41] <robert_ancell> (but expected to still have all the usual bugs)
[00:41] <rickspencer3> who is responsible for getting it working?
[00:41] <rickspencer3> are you the maintainer?
[00:41] <robert_ancell> no
[00:41] <rickspencer3> foundations?
[00:42] <robert_ancell> not sure, I think that's upstream.  The meeting was more about making it available so people are prepared for when the old bindings start to stop being maintiained
[00:42] <rickspencer3> hmmm
[00:42] <rickspencer3> I would like someone in Ubuntu to be on point for making sure this goes smoothly
[00:42] <tremolux> robert_ancell: do you know, is Barry working on this?
[00:43] <robert_ancell> tremolux, I don't know, I'm looking for blueprint now
[00:43] <rickspencer3> I am so happy to have robert_ancell back on the team!
[00:43] <tremolux> robert_ancell rocked OEM!
[00:43] <robert_ancell> I think it is, https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-python-versions but it doesn't seem to have the items yet.  Maybe no-one copied them from the gobby doc
[00:44] <rickspencer3> robert_ancell, I suggest that you work on color management (or what you prefer) but don't target it to the release
[00:44] <robert_ancell> rickspencer3, ok, can do
[00:44] <rickspencer3> so we don't appear committed to delivering it
[00:44] <rickspencer3> then you can pull a Simple Scan
[00:44] <robert_ancell> hehe :)
[00:44] <desrt> robert_ancell: hey
[00:44] <rickspencer3> deliver such awesome software that everyone wants to ship it!
[00:44] <robert_ancell> desrt, hey
[00:44] <desrt> robert_ancell: seb was wondering if you had some free time to make some packages
[00:45] <robert_ancell> desrt, ok, talk after meeting
[00:45] <RAOF_> robert_ancell: Feel free to pour some colour-management work this way if you need to :)
[00:45] <desrt> ah.  didn't realise.  sorry. :)
[00:46] <rickspencer3> desrt is always welcome to our meetings! :)
[00:46] <rickspencer3> robert_ancell, I think we are done, actually
[00:46] <robert_ancell> ok, I feel like I'm hogging the meeting, anything I should do to track things?
[00:46] <robert_ancell> oh ok
[00:46] <rickspencer3> well ... just get your work items cleaned up on your blueprints
[00:47] <rickspencer3> I'll look at the burndown chart on Monday and make sure nothing seems amiss
[00:47] <robert_ancell> rickspencer3, ok, I just don't have any really, let me know if there's a good way to break up the items
[00:48] <rickspencer3> hmmm, you ended up with no spec work?
[00:48] <rickspencer3> just maintenance?
[00:48] <robert_ancell> rickspencer3, just no items, so I have two I put on Shotwell "Package 0.6" and "Package 0.7" but I just put them to have some items on this
[00:48] <rickspencer3> basically, you are the new seb128 ;)
[00:49] <robert_ancell> GNOME I have two that seb retro added (update GLIB, GTK+)
[00:49] <rickspencer3> yeah, like you ended up with a large maintenance surface area
[00:49] <robert_ancell> PyGI should have one
[00:49] <rickspencer3> which makes sense
[00:49] <rickspencer3> but I don't want you to be bored
[00:49] <robert_ancell> I always have side projects :)
[00:49] <rickspencer3> so I guess having a blueprint on the side makes sense
[00:50] <rickspencer3> looking at your areas, you have a lot of responsibility for maverick!
[00:50] <rickspencer3> alright, so let's finish up here
[00:50] <rickspencer3> RAOF, TheMuso, tremolux, robert_ancell - thanks for your time and effort planning out maverick!
[00:50] <rickspencer3> please note that we have HR review stuff due by Tuesday!
[00:51] <tremolux> fun times  :)
[00:51] <TheMuso> np
[00:51] <rickspencer3> don't forget to invite peer reviews and such
[00:52] <rickspencer3> any questions, comments, etc...?
[00:52] <TheMuso> rickspencer3: no questinos, but if you have a minute, I'd like to talk about your thoughts re technical progress for sound/a11y that you mentioned earlier.
[00:52] <tremolux> not me
[00:52] <TheMuso> questions
[00:52] <rickspencer3> TheMuso, sure
[00:53] <tremolux> ok, thanks all, I enjoyed my first desktop meeting, Eastern Edition (tm)
[00:53]  * tremolux goes to make sure the kids didn't eat all the dinner
[00:53] <robert_ancell> desrt, ok, so anything special to note about glib/dconf?
[00:55] <desrt> ya.  you should add a small vendor patch to dconf
[00:55] <desrt> also: you'll need a post-install hook
[00:56] <desrt> the patch you should add is the one at the head of the 'master' upstream
[00:56] <rickspencer3> tremolux, they are not usually this organized ;)
[00:56] <desrt> totally silly mistake on my part
[00:56] <desrt> the post-install hook is the one that runs gio-querymodules
[00:57] <robert_ancell> desrt, any dconf/gconf interactions to worry about? (guessing no)
[00:57] <desrt> nope
[00:57] <robert_ancell> did seb128 give any hints on packaging naming?  I'm guessing gnome-dconf from the last discussion
[00:58] <desrt> that's a dreadful name
[00:58] <desrt> like, really really bad
[00:58] <robert_ancell> and you would recommend...
[00:59] <desrt> hmm.
[00:59] <desrt> well, i like 'dconf'
[00:59] <robert_ancell> because libdconf doesn't sound right.
[00:59] <robert_ancell> Sorry, dconf is taken
[00:59] <desrt> it's difficult
[00:59] <robert_ancell> but it's also not really gnome specific
[00:59] <desrt> really, the various binary packages will all have different names anyway
[00:59] <desrt> unlikely to have one called 'dconf'
[00:59] <desrt> the source package name is the trouble
[01:00] <desrt> yes.  indeed.
[01:00] <desrt> would it be very strange to call the source package 'dconf-source'?
[01:00] <robert_ancell> TheMuso, ^ ?
[01:00] <desrt> with binary package names like 'dconf-gsettings' 'dconf-tools' etc
[01:00] <desrt> 'libdconf'
[01:01] <robert_ancell> dconf-config? or something like that, i.e. "name"-"class"
[01:01] <robert_ancell> dconf-settings?
[01:01] <robert_ancell> dconf-registry?
[01:01] <desrt> d-conf?
[01:01] <robert_ancell> aha
[01:01] <desrt> you're going to have to repackage 'dconf' in universe i guess
[01:02] <desrt> because it tries to install /usr/bin/dconf.  i'll be using that.
[01:02] <robert_ancell> why couldn't you have done a debian package name check before choosing the name!! :)
[01:02] <TheMuso> gnome-dconf?
[01:02] <desrt> no.
[01:02] <TheMuso> orca is gnome-orca after all.
[01:03] <desrt> it's not gnome-specific
[01:03] <TheMuso> ah ok
[01:03] <robert_ancell> we can't change the binary name
[01:03] <robert_ancell> (of the existing dconf)
[01:03] <desrt> epiphany got renamed to epiphany-game
[01:04] <desrt> let the record show what happens when i run 'dconf'
[01:04] <desrt> /usr/bin/dconf:3: DeprecationWarning: The popen2 module is deprecated.  Use the subprocess module.
[01:04] <desrt>   import os, sys, glob, re, shutil, getopt, popen2, time, fnmatch
[01:04] <desrt> /usr/bin/dconf:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead
[01:04] <desrt>   import difflib, smtplib, gzip, md5, sha
[01:05] <desrt> /usr/bin/dconf:5: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[01:05] <desrt>   import difflib, smtplib, gzip, md5, sha
[01:05] <desrt> Traceback (most recent call last):
[01:05] <desrt>   File "/usr/bin/dconf", line 481, in <module>
[01:05] <desrt>     main()
[01:05] <TheMuso> lovely
[01:05] <robert_ancell> who would I talk to about renaming it?
[01:05] <desrt> popcon says 150 people are using it
[01:06] <desrt> i'm not sure?
[01:06] <desrt> i don't know what happened for epiphany
[01:06] <TheMuso> I guess in Debian is the best place to do this properly right, or is this a package that is only in Ubuntu?
[01:06] <desrt> it's from debian
[01:06] <desrt> http://qa.debian.org/popcon.php?package=dconf
[01:06] <TheMuso> right
[01:07] <desrt> about 400 times as many people are using gconf
[01:08] <robert_ancell> so I don't know what the process here is, what are the chances of filing a bug in debian and anything being done?  Guess I need to ask the Debian GNOME guys what their dconf plans are
[01:08] <desrt> ah.  only 7 people are marked as having dconf installed/used recently
[01:08] <TheMuso> wow
[01:08] <desrt> how much do you want to bet that they all thought that they were getting my software? :p
[01:10] <desrt> huh.  according to popcon, 99.79% of all debian users are using popcon
[01:10]  * desrt suspicious
[01:10] <Amaranth> epiphany didn't get their name
[01:10] <Amaranth> They got epiphany-browser instead
[01:10] <Amaranth> Heck, did git get their name yet?
[01:10] <desrt> alternatives?
[01:10] <desrt> yes.  git is git.
[01:11] <desrt> er.
[01:11] <desrt> Amaranth: we're talking about /usr/bin/ binary names, not packagers
[01:11] <Amaranth> ah
[01:11] <desrt> the epiphany-browser package installs /usr/bin/epiphany
[01:12] <chrisccoulson> the existing dconf in the archive really should just be removed, it hasn't been updated for over 2 years now
[01:12] <desrt> chrisccoulson: that's what i was getting at with my 'spews about deprecations then crashes'
[01:12] <chrisccoulson> desrt - i agree, and i hate cruft anyway ;)
[01:12] <desrt> robert_ancell: maybe you should wait
[01:13] <chrisccoulson> ok, i will check to make sure nothing is build-depending on it and ask an archive admin to remove and blacklist it
[01:13] <desrt> are you a DD?
[01:13] <robert_ancell> no
[01:13] <chrisccoulson> i'm not either
[01:13] <robert_ancell> I'll get the packaging working and get seb to check this out, he's more on the pulse of Debian
[01:13] <desrt> you should fairly familiar with the ways of debian :p
[01:13] <desrt> *sound
[01:14] <desrt> it's too hot in here.  my brain is melting.
[01:14] <chrisccoulson> heh
[01:35] <rickspencer3> good night all!
[01:36] <rickspencer3> I'll be back on Monday (will check in tomorrow prolly)
[04:40] <nigelb> Isn't assinging to desktop team out?
[04:40] <nigelb> I believe we dont do that anymore
[05:01] <lifeless> RAOF_: ping
[05:01] <RAOF_> lifeless: Pong.
[05:02] <lifeless> RAOF_: whats a good pci express video card to buy [good == linux love] these days
[05:02] <lifeless> poolie is stranded at a computer shop
[05:02] <lifeless> and has a fried card
[05:02] <RAOF_> What's he need it for?
[05:02] <lifeless> bzr dev
[05:02] <lifeless> explicitly not games
[05:02] <RAOF_> Buy the cheapest ATI card money can buy.
[05:02] <lifeless> thanks
[05:02] <RAOF_> That should be ~$50
[05:03] <lifeless> and the free driver will likely run it ?
[05:03] <lifeless> or the binary blob is tolerable ?
[05:03] <RAOF_> Free driver works fine on the box next to me; that has a video card chosen by this algorithm.  The blob also works.
[05:04] <lifeless> RAOF_: hd4350 ring any bells ?
[05:04] <RAOF_> That's possibly what I've got in the box next to me.
[05:04] <RAOF_> I'll check.
[05:05] <lifeless> now thats service; poolie says 'thanks very much'
[05:07] <lifeless> RAOF_: so what did lspci say ?
[05:07] <RAOF_> Yup.  Radeon DH 4350 is what I've got.
[05:07] <lifeless> awesome
[05:07] <lifeless> poolie reckons its a typo :)
[05:08] <lifeless> DH<->HD
[05:08] <RAOF_> It is :)
[05:11] <lifeless> poolie is very grateful
[05:12] <RAOF_> No problem!
[06:20] <RAOF> Yay sbuild-on-tmpfs-overlay!
[06:48] <fagan> good morning desktoppers
[07:46] <pitti> Good morning
[08:03] <didrocks> good morning pitti, fagan
[08:04] <fagan> morning didrocks
[08:05] <pitti> hey didrocks, fagan
[08:05] <fagan> hey pitti
[09:00] <seb128> hey there
[09:01] <didrocks> salut seb128, bien dormi?
[09:01] <seb128> lut didrocks
[09:01] <seb128> nickel, et toi?
[09:03] <pitti> bonjour seb128
[09:03] <seb128> hey pitti
[09:03] <seb128> how are you?
[09:03] <pitti> c'est bien, merci! et toi?
[09:04] <didrocks> seb128: très bien, merci ;)
[09:06] <seb128> pitti, gut danke
[09:07] <nigelb> so many languages :)
[09:29] <dpm> heya pitti, good morning, I'm moving all helper scripts related to Ubuntu Translations to a central location. We've got one to retrieve the URLs from translation imports. ArneGoetje told me it was you who wrote it, so I've added a license header and added you as the original author before publishing it. Before I push it, does that look ok to you (well, the license header, copyright assignment and such)? -> http://pastebin.ubuntu.com/437184/
[09:39] <pitti> dpm: no, I don't think I wrote this :) just leave you as the author then, it doesn't matter much; The copyright should be (C) 2010 Canonical Ltd., if you wrote it during paid hours
[09:40] <pitti> dpm: btw, if you are looking for a home for it, langpack-o-matic might not be the worst one
[09:53] <didrocks> james_w: hey, who should we ping when an debian branch is out of date? (are they still target testing?)
[09:57] <didrocks> james_w: the sid branch is uptodate, just lp:debian/package points to testing
[10:00] <james_w> didrocks: that's launchpad's decision, I'm not entirely sure what the consequences of changing it would be
[10:02] <didrocks> james_w: no pb, since we can branch from sid. I was just surprized at first :)
[10:02] <james_w> yeah
[10:02] <james_w> I would prefer it was the other way, but as I said, I'm not sure what would rely on it pointing to testing
[10:04] <didrocks> ok, thanks james_w :)
[10:05] <james_w> didrocks: perhaps you could file a bug against launchpad?
[10:05] <james_w> we can discuss it there
[10:05] <james_w> otherwise we will just never know
[10:05] <didrocks> james_w: "launchpad" itself is the right target task?
[10:06] <james_w> launchpad-registry I think
[10:06] <james_w> but launchpad is always fine
[10:06] <didrocks> ok, filling it and subscribing you, ok?
[10:11] <dpm> pitti, ah, ok, I'll credit ArneGoetje as the author then. I'm going to put it in the ubuntu-translations project, where we've got a home for such tools
[10:13] <pitti> nice
[10:18] <seb128> what is the standard way to run autotools at build time?
[10:26] <pitti> seb128: I'd call autoreconf -vi
[10:26] <seb128> pitti, in which changelog target?
[10:26] <pitti> oh, and then rm -rf autom4te.cache/ please
[10:27] <seb128> robert-ancell did that
[10:27] <seb128> common-configure-arch common-configure-indep::
[10:27] <seb128> 	autoreconf -f -i -s
[10:27] <pitti> hmm; I think "build" should depend on configure
[10:27] <pitti> or configure, yes
[10:27] <pitti> and configure should depend on configure.ac
[10:27] <pitti> that won't yet catch Makefile.am modifications, though
[10:27] <seb128> I'm wondering if we should try to use the cdbs autotools-vars.mk
[10:28] <pitti> seb128: cdbs has builtin support foor that
[10:28] <pitti> "for"
[10:28] <seb128> I know we had discussion in the past about the cdbs way to do it though
[10:28] <seb128> they don't use autoreconf
[10:28] <seb128> but run autoconf, automake, etc
[10:28] <pitti> DEB_AUTO_UPDATE_AUTOCONF, DEB_AUTO_UPDATE_AUTOHEADER, and so on
[10:28] <seb128> which is less smart than autoreconf
[10:30] <asac> i had a patch for AUTORECONF at some point ... guess that was list in battle though
[10:30] <asac> lost
[10:36] <seb128> asac, if you find it somewhere let me know ;-)
[10:40] <didrocks> seb128: I just had a look at the evolution-exchange and the only real diff we have is: http://paste.ubuntu.com/437209/ you described as "don't use a Debian specific directory". Do we keep that? I'm not sure to understand the reason?
[10:40] <didrocks> (well, the diff is ubuntu - debian, should be the contrary no -xxx for us)
[10:40] <seb128> didrocks, it's about matching the directory used by evolution I think
[10:41] <seb128> you would need to drop the evolution change too
[10:41] <didrocks> seb128: I remember to do the same in evolution (we also remove -xxx), but I have no clue why :)
[10:41] <seb128> and make sure you rebuild everything using this dir
[10:41] <DASPRiD> didrocks, no pr0ns for us? :/
[10:41] <seb128> because I don't see the reason to have a distro change there
[10:42] <didrocks> seb128: ok, I was thinking you made the change in first place, but didn't have the time to have a look at it. I can try to sync and rebuild evolution without it
[10:42] <seb128> it's another case of debian maintainer doing changes for the sake of doing changes and not being compatible with upstream
[10:42] <seb128> didrocks, no, I mean what debian is doing is wrong
[10:42] <seb128> why that directory needs to be changed?
[10:42] <didrocks> seb128: oh ok, understood now
[10:42] <didrocks> seb128: so, let's keep that
[10:43] <seb128> but feel free to open a bug on the bts, maybe the new debian maintainers for it can sort that
[10:43] <didrocks> made sense to not change upstream, especially for side effects because of hard-coded path :)
[10:43] <seb128> either it has a sense and should be taken upstream or has none and should be dropped from debian
[10:43] <didrocks> sure, I'll do that in the same round
[10:43] <seb128> thanks
[10:43] <didrocks> thanks for the explanation :)
[10:43] <seb128> yw ;-)
[10:43] <seb128> hey chrisccoulson
[10:43] <didrocks> good morning chrisccoulson
[10:44] <pitti> hey chrisccoulson
[10:44] <chrisccoulson> hi seb128 didrocks pitti
[10:44] <chrisccoulson> how are you all?
[10:45] <pitti> good, thanks!
[10:45] <seb128> good, thanks, what about you?
[10:45] <DASPRiD> very good, thanks
[10:46] <zyga> hello, anyone seen mvo today?
[10:46] <chrisccoulson> yeah, i'm good too thanks. a little bit tired though
[10:47] <seb128> zyga, not yet
[10:48] <seb128> he might be on swap day or something
[10:48] <seb128> chrisccoulson, working too much?
[10:48] <chrisccoulson> seb128 - i've had a couple of late nights this week ;)
[10:49] <seb128> don't overwork yourself too much ;-)
[11:30] <Bacta> So which of you knuckle heads violated my laptops UI?
[11:30] <pitti> !coc | Bacta
[11:30] <ubot2> Bacta: The Ubuntu Code of Conduct is a community etiquette document to which we ask all Ubuntu users to adhere, and can be found at http://www.ubuntu.com/community/conduct/ .  For information on how to electronically sign the CoC, see https://help.ubuntu.com/community/SigningCodeofConduct .
[11:31] <Bacta> coc?
[11:31] <Bacta> No I don't care about that, I'm just curious about why my window controls were moved to the left
[11:31] <Bacta> It took an hour to fix
[12:00] <dpm> hi seb128, I've got two WI on the desktop-translations roundtable we had (https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-desktop-translations-roundtable). I'm not sure that's the best place to put them and make them appear in the burn-down chart. Do you have any existing blueprint for Desktop where I could move them to?
[12:00] <seb128> dpm, they should show up on our list if they are assigned to people in our team
[12:01] <dpm> seb128, even if it's a community-m-desktop-* blueprint?
[12:01] <seb128> yes
[12:02] <seb128> dpm, I've set the maverick serie goal for it
[12:02] <seb128> let's see how next WIs refresh goes
[12:02] <dpm> seb128, ok, thanks, I'll keep an eye on it, then
[12:35] <pitti> seb128: btw, let me know when I should flush the desktop ones, so that we have a clean start
[12:45] <seb128> pitti, we shouldn't be far from it now, is it easy to do for you?
[12:46] <seb128> pitti, ie if you can do it now that would be nice, I might ask you again on tuesday after the meeting though
[12:49] <geser> pitti (or any other core-dev): https://code.edge.launchpad.net/~geser/ubuntu/maverick/gir-repository/dont_build_gtk_gir/+merge/25762 is ready for sponsoring. It re-adds a drop Ubuntu delta to gir-repository (don't build gtk gir) which is needed as else the build fails to upload.
[12:49] <seb128> geser, hi
[12:49] <seb128> geser, the build didn't fail due to that though
[12:50] <seb128> I've it on my list of things to look at
[12:50] <geser> seb128: Hi, the give-back a few minutes ago did
[12:50] <seb128> weird
[12:50] <seb128> do you know why the previous one failed earlier?
[12:50] <geser> https://edge.launchpad.net/ubuntu/+source/gir-repository/0.6.5-6/+build/1736972
[12:51] <geser> seb128: the first one failed because it didn't detect libsoup (the log didn't tell why) and as a building it in my pbuilder (to check why) succeed I asked in #ubuntu-devel for a give-back (which pitti did)
[12:52] <seb128> ok, weird
[12:52] <seb128> I would like to know why the detection failed where the packages got installed
[12:53] <seb128> geser, I will sponsor your change for now, I had something similar but wanted to debug the other issue before upload, but since this one seems to have went away now...
[12:58] <geser> seb128: the problem might have been due to zlib1g-dev as the old one didn't have a .pc file and I've seen some builds checking for gnutls failing due to this (and libsoup2.4-dev depends on libgnutls-dev)
[12:58] <seb128> geser, hum, that makes sense, thanks
[12:59] <seb128> geser, I'm uploaded your change
[12:59] <geser> thanks
[12:59] <seb128> not sure if I should push the diff or let the autoimport deal with it though
[12:59] <seb128> thank you for fixing the issue
[13:06] <james_w> push!
[13:06] <seb128> james_w, I've bad experience with that
[13:06] <james_w> really?
[13:06] <seb128> I managed to make autoimport stop for some sources
[13:06] <seb128> which means you get outdated imports if the next person just upload
[13:07] <james_w> ah, well that's a bug
[13:07] <james_w> we should fix it, not work around it
[13:07] <seb128> and I've no clue how to fix those
[13:07] <chrisccoulson> seb128 - i should probably be disabling csd in firefox at some point shouldn't i? (i think it had issues last cycle)
[13:07] <seb128> ie to make autoimport work again
[13:07] <james_w> seb128: report a bug and I will look at it
[13:08] <seb128> chrisccoulson, right, I will upload csd to maverick today
[13:08] <didrocks> oh Friday cracky day so? :)
[13:08] <chrisccoulson> seb128 - ok, i will get that disabled in firefox too
[13:09] <seb128> didrocks, it's maverick, whoever is crazy enough to run it deserve the crack breakage ;-)
[13:09] <chrisccoulson> lol
[13:09] <didrocks> seb128: heh :-)
[13:10] <seb128> I'm doing my merges on lucid without installing
[13:10] <seb128> it should tell you a bit about maverick state ;-)
[13:10] <chrisccoulson> i see tracker no longer builds on maverick
[13:11] <seb128> james_w, bug against what?
[13:11] <seb128> james_w, I'm not even sure if that's not my who acted dump there
[13:11] <seb128> i.e is the autoimport supposed to update things when the bzr and archive are different?
[13:12] <james_w> seb128: bug against 'udd', or anything I'm subscribed to really :-)
[13:12] <james_w> seb128: I don't understand your other statements
[13:13] <seb128> james_w, I've commited things manually to the bzr
[13:13] <seb128> then did uploads without commiting
[13:13] <seb128> is the autoimport supposed to work on those cases?
[13:13] <james_w> yes
[13:13] <seb128> or the fact to manually commit put you in manual mode?
[13:13] <seb128> james_w, lp:ubuntu/libgnome-desktop
[13:13] <seb128> ups
[13:13] <pitti> seb128: yes, I can do it now (sorry, was off for lunch)
[13:13] <james_w> when you commit and push as well as upload it will check that what you uploaded is the same as what is committed
[13:14] <james_w> however, that's the most fragile part of the code
[13:14] <seb128> james_w, I mean lp:ubuntu/libgnome-keyring
[13:14] <james_w> but I need to know when it happens so that I can make it more robust
[13:14] <seb128> is the one I screwed
[13:14] <pitti> seb128: thanks for sponsoring gir
[13:14] <seb128> pitti, you're welcome, thank you for dealing with the workitems tracker ;-)
[13:14] <james_w> seb128: that's odd, I'll have a look thanks
[13:15] <seb128> james_w, do you want a bug? against udd? thanks for looking to it!
[13:15] <seb128> james_w, I'm sure I did something stupid but I don't know what and how to fix it
[13:17] <james_w> seb128: no, I think you just triggered a bug, so thanks!
[13:18] <seb128> james_w, thank you ;-)
[13:20] <pitti> seb128: flushed, copied back, reports regenerating now
[13:20] <seb128> pitti, you rock, thanks
[13:21] <james_w> seb128: ah, do you happen to remember how you did http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/libgnome-keyring/maverick/revision/5 ?
[13:21] <james_w> do you just drop the new .orig.tar.gz in to the parent dir, and then dch -v whatever?
[13:23] <seb128> james_w, bug #583770
[13:23] <ubot2> Launchpad bug 583770 in udd "lp:ubuntu/libgnome-keyring ubuntu auto-import is broken (affects: 1)" [Undecided,New] https://launchpad.net/bugs/583770
[13:23] <james_w> thanks
[13:24] <seb128> james_w, I'm not sure what I did exactly there, I think I mixed workflow for debian dir only in the vcs against source import
[13:24] <james_w> ok
[13:24] <seb128> ie I worked once in the directory as it was a debian dir only
[13:24] <james_w> do you know about "bzr merge-upstream"?
[13:24] <seb128> I managed to revert upstream changes in the diff.gz
[13:24] <seb128> yes, I use it for dx update
[13:25] <james_w> great
[13:25] <seb128> I just think I got confused between this one and screwed an update
[13:25] <pitti> seb128: http://people.canonical.com/~pitti/workitems/maverick/canonical-desktop-team.html
[13:25] <james_w> it's a shame it doesn't currently work for debian-only, then you could use it for everything and avoid that
[13:25] <seb128> ie I did checkout the import and worked on it later as it was another desktop debian only dir
[13:25] <seb128> then I realized I reverted changes in the diff.gz
[13:25] <seb128> and did another upload
[13:25] <james_w> ah, ok
[13:25] <seb128> but the auto-import didn't cope with it
[13:26] <james_w> I need to think for a minute to see if we can handle this, but I may have to cause it to re-import those uploads so that they contain the pristine-tar data
[13:26] <seb128> feel free to overwrite the whole thing with auto imports
[13:26] <seb128> the few commits I did were broken anyway
[13:27] <seb128> I will do better with the next upload :-)
[13:27] <james_w> seb128: thanks, I'll think over lunch anyway
[13:27] <james_w> thanks for helping to improve the system :-)
[13:28] <seb128> ;-)
[13:30] <seb128> pitti, https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa?field.series_filter=karmic
[13:30] <seb128> should that one be cleaned?
[13:30] <seb128> what about the gdm one on https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa
[13:30] <pitti> seb128: atasmart is in proposed now, so it can go
[13:30] <pitti> seb128: gdm> same
[13:31] <seb128> pitti, ok, cleaning those
[13:31] <seb128> thanks
[13:36] <desrt> good morning everyone
[13:36] <seb128> hello desrt
[13:36] <desrt> pitti: i see you just can't bring yourself to leave this place :)
[13:36] <pitti> desrt: I just love this place too much :)
[13:37] <desrt> seb128: i was talking yesterday with robert and chris.  chris, particularly, thinks that dconf should drop from universe/debian
[13:37] <seb128> pitti, the trendline seems to need an update for the new schedule
[13:37] <seb128> ie 10.10.10
[13:37] <seb128> ups no
[13:37] <pitti> seb128: that requires fixing the milestones in LP
[13:37] <didrocks> good morning desrt
[13:37] <desrt> seb128: based on the fact that it hasn't been packaged in 2 years, has approximately 7 active users on popcon and when you start it up it spews a tonne of deprecation warnings then crashes
[13:37] <desrt> didrocks: hey
[13:37] <seb128> pitti, seems I mistead the legend
[13:37] <desrt> seb128: they wanted to defer to you to talk to the debian guys, though
[13:38] <seb128> desrt, chrisccoulson?
[13:38] <desrt> seb128: yes
[13:38] <seb128> I'm not interested by talking to the debian guys
[13:38] <seb128> I think we should not hijack an existing namepsace
[13:38] <desrt> 00:12 < chrisccoulson> the existing dconf in the archive really should just be  removed, it hasn't been updated for over 2 years now
[13:38] <seb128> namespace
[13:38] <desrt> 00:13 < chrisccoulson> ok, i will check to make sure nothing is build-depending  on it and ask an archive admin to remove and blacklist it
[13:39] <desrt> 00:13 < robert_ancell> I'll get the packaging working and get seb to check this  out, he's more on the pulse of Debian
[13:39] <chrisccoulson> yeah, i haven't done that yet. seb128 - what do you think?
[13:39] <seb128> you can try
[13:39] <seb128> I'm not interested to try
[13:39] <seb128> I think it's wrong
[13:39] <seb128> it will lead to issues
[13:39] <james_w> you can remove dconf, but for Debian at least, you have to wait a release cycle until you can take the name
[13:39] <pitti> will the binary packages really conflict?
[13:39] <desrt> if you think it's wrong then probably we should just not do it, then
[13:39] <seb128> having 2 differents things using the same namespace leads to issues
[13:40] <pitti> isn't it all just libraries?
[13:40] <desrt> pitti: the binary packages will not
[13:40] <desrt> pitti: it's more about the source package name
[13:40] <desrt> i suggested we just call the new source package 'dconf-source' or something
[13:40] <seb128> I would be fine renaming both
[13:40] <pitti> desrtconf?
[13:40] <seb128> to avoid apt-get source dconf giving the wrong one
[13:40] <desrt> pitti: sure :p
[13:40] <chrisccoulson> is the name an issue? i thought the main issue is that the current dconf ships conflicting binaries
[13:40] <desrt> seb128: ya.  that's the other issue.
[13:40] <seb128> I'm a bit reluctant to reuse a name for something different
[13:41] <desrt> seb128: i have a sneaking suspicion that the 7 people on popcon who installed dconf recently thought that they were getting my dconf :p
[13:41] <desrt> chrisccoulson: oh right.  that too.
[13:41] <desrt> seb128: dconf will have /usr/bin/dconf
[13:41] <seb128> it does?
[13:42] <desrt> same story as epiphany here, i guess?
[13:42] <seb128> sucks
[13:42] <chrisccoulson> so, we could work around the name (wasn't "d-conf" suggested yesterday?), but the conflicting binaries is more difficult
[13:42] <pitti> desrt: oh, is that a gconftool-like thing?
[13:42] <desrt> pitti: ya
[13:42] <desrt> pitti: with interface like the current 'gsettings' and 'gdbus' tools (ie: git-inspired)
[13:42] <desrt> dconf get ...
[13:42] <desrt> dconf set ...
[13:44] <desrt> rumour has it that 'gdbus' will be installed as '/usr/bin/dbus' soon
[13:44] <desrt> looks like there's no problem there, fortunately
[13:45] <pitti> /usr/bin/gdbus I hope?
[13:45] <desrt> nah.  just 'dbus'
[13:45] <desrt> by request of dbus maintainers
[13:45] <seb128> we should maybe drop current dconf and use the namespace for the new one
[13:45] <chrisccoulson> that's what i thought. the current dconf hasn't been touched since august 2007
[13:45] <desrt> seb128: is it possible that we drop the current package and use a different name for the packages at least for now?
[13:46] <desrt> like 'desrtconf' or whatever
[13:46] <chrisccoulson> i'm not sure anybody would miss it ;)
[13:46] <desrt> then in a year or two, we rename the source package?
[13:46] <desrt> just to avoid the trouble you were concerned about...
[13:46] <seb128> I think it's not so much of an issue for sources
[13:46] <pitti> I'm all for dropping dconf, the only downside that I see that this would prevent us from being able to keep the new dconf in sync with debian
[13:46] <seb128> would be an issue for binaries
[13:47] <seb128> i.e like epiphany
[13:47] <Laney> sounds like something to coordinate with debian
[13:47] <seb128> you use the game
[13:47] <seb128> and then get the browser and no game after updaging
[13:47] <seb128> upgrading
[13:47] <desrt> heh
[13:47] <seb128> Laney, right, cf backlog
[13:47] <desrt> this presupposes that you use the game
[13:47] <desrt> nobody does that :p
[13:47] <seb128> lol
[13:47] <chrisccoulson> that's why firefox has all the transitional packages, to handle upgrades where binary package names change ;)
[13:47] <desrt> (except people who were trying to install the browser...)
[13:47] <pitti> would it be so bad to call it d-conf in both D and U for now?
[13:47] <seb128> chrisccoulson, well it stays firefox for those
[13:48] <desrt> pitti: aww.  i liked the desrtconf name :)
[13:48] <chrisccoulson> seb128 - it does now
[13:48] <seb128> chrisccoulson, I mean all the variants are still the firefox browser
[13:48] <seb128> you didn't hijack a game names firefox
[13:48] <chrisccoulson> ah, yeah, true
[13:48] <pitti> desrt: you could also call it d#conf or d♭conf :)
[13:50] <chrisccoulson> or ɟuoɔp
[13:50] <desrt> chrisccoulson: WIN
[13:51] <ccheney> hi
[13:53] <mclasen> desrt: talking about names...is ca.desrt.dconf the final busname ?
[13:53] <desrt> mclasen: this is difficult.
[13:53] <desrt> obvious alternatives being org.gnome org.freedesktop and org.gtk
[13:53] <desrt> all of them having politics attached
[13:54] <desrt> totally doesn't matter as far as i'm concerned
[13:54] <desrt> and it's very easy to change in the future
[13:54] <desrt> the dbus API is private
[13:55] <seb128> chrisccoulson, could you open a debian bug on dconf?
[13:55] <seb128> asking for a rename or get it cleaned
[13:55] <chrisccoulson> seb128 - ok, will do
[13:56] <seb128> chrisccoulson, thanks
[13:59] <desrt> thanks, guys
[13:59] <desrt> probably much less confusing this way, in the long run
[14:35] <didrocks> seb128: do you know if this is still valid (http://paste.ubuntu.com/437340/)? Debian doesn't have it
[14:36] <seb128> didrocks, do we still build out of the srcdit?
[14:36] <seb128> srcdir
[14:36] <seb128> didrocks, or said differently, do we have a po/*.pot after build
[14:37] <seb128> didrocks, debian doesn't need it, it's for rosetta import
[14:37] <didrocks> seb128: I see nothing in that regard in debian/rules, I guess there is no other file when you can change srcdir?
[14:37] <didrocks> seb128: I'll have a testbuild without it and see
[14:37] <seb128> didrocks, ok, thanks
[14:37] <seb128> didrocks, I think it used to build 2 variants
[14:38] <seb128> one hildon one and a normal one
[14:38] <seb128> or something
[14:38] <seb128> so it was building out of the srcdir
[14:38] <seb128> it might not apply now
[14:38] <didrocks> seb128: you're welcome, I'll have a look at debian/rules for the version you added that to see how it was described in debian/rules
[14:38] <seb128> try without it and see if the pot is there
[14:40] <didrocks> ok, I see how it was on debian/rules, with two binary packages and two builds. No we don't have that. I'll confirm by a build
[14:40] <seb128> cool
[14:53] <momelod> Greetings channel
[14:53] <momelod> Im trying to setup a wireless internet stick I got from my cellular provider.
[14:54] <momelod> I have defined a connections in NetworkManager->edit connections->mobile broadband
[14:54] <momelod> but how do i launch it? when i click on network manager I dont see it listed as an available connection..
[15:02] <didrocks> momelod: this is a developer channel, for support, please see on #ubuntu
[15:11] <momelod> thanks
[15:28] <Amaranth> seb128: So I was thinking of taking advantage of the multiple tarball support of 3.0 source packages and putting compiz, compiz-plugins-main, and compiz-plugins-extra in one source package
[15:29] <Amaranth> seb128: Then we can more easily make sure they are updated at the same time and partition groups of plugins however we want (used vs unused, for example)
[15:53] <ccheney> grr, BOA called claiming i hadn't paid my mortgage, they screwed up their records and can see it themselves when i called in :-(
[15:55]  * kenvandine imports 22728 photos into shotwell
[15:55] <kenvandine> lets see how long this takes
[15:56] <ccheney> heh my iphone is giving itself gsm interference noise
[15:57] <LaserJock> didrocks (whenever you get a chance): was there any work done on porting netbook-launcher to liblauncher 0.3?
[15:57] <LaserJock> kenvandine: are you using Lucid's shotwell?
[15:57] <kenvandine> yes
[15:59] <kenvandine> looks like it will take a while, it appears to preview every photo on import
[15:59] <kenvandine> using a ton of CPU, but it is remarkable how low the memory usage is
[16:00] <kenvandine> 34m RSS and 236% cpu usage
[16:10] <dobey> kenvandine: 236% cpu?
[16:10] <kenvandine> hehe... yeah
[16:10] <dobey> kenvandine: have you like, perfected quantum computing?
[16:10] <kenvandine> impressive huh?
[16:11] <dobey> your cpu is actually in 3 different dimensions, and it's using 100% in 2 of them, and 36% in the third? :)
[16:11] <kenvandine> apparently
[16:12] <kenvandine> this is going to take a while...
[16:12] <dobey> heh
[16:13] <didrocks> LaserJock: not from what I know. I'll upload it next week to maverick, maybe the right time to port that?
[16:20] <seb128> Amaranth, hum, not sure, the plan was to get in sync with debian
[16:20] <seb128> didrocks, hum, alacarte, why did you drop the properties change?
[16:20] <didrocks> seb128: ooppss, miss it so, will reupload
[16:21] <seb128> didrocks, thanks
[16:21] <didrocks> seb128: I tried the review with bzr merge-package maybe I miss something in the workflow
[16:21] <didrocks> sorry about that
[16:21] <seb128> no worry
[16:21] <Amaranth> seb128: The guy I'm pretty sure handles compiz in Debian had the same idea but wanted to wait to figure out git submodules first
[16:21] <Amaranth> Which I assuming means rolling his own orig.tar.gz
[16:21] <Amaranth> s/I/I'm/
[16:27] <Amaranth> seb128: Debian still ships compiz-gtk, I don't think getting in sync is a good idea unless it involves them making changes to get more in line with our packaging of compiz
[16:28] <LaserJock> didrocks: you're doing a new netbook-launcher or liblauncher upload next week?
[16:28] <seb128> Amaranth, well if it works for them it should work for us?
[16:28] <LaserJock> didrocks: the porting might take me a while to do, at least it wasn't trivial when I looked during lucid
[16:28] <seb128> Amaranth, really is that we have nobody maintaining compiz and we do a poor job at it
[16:28] <didrocks> LaserJock: not sure about next week, I have already tons of things on my plate right now. If you want to do it, I'll happily sponsors you
[16:28] <seb128> Amaranth, we would win to share work with debian
[16:28] <Amaranth> The packaging side is almost no work
[16:29] <Amaranth> The bug triage is the work and unless we drop all of our patches that isn't going to change
[16:29] <seb128> dealing with bugs is the work
[16:29] <LaserJock> didrocks: well, do you have anything already planned for non-unity maverick uploads? I don't know what the current status is
[16:29] <seb128> they seem to do a better job that us to it recently
[16:30] <LaserJock> didrocks: I'm happy to start hacking away on porting it
[16:30] <didrocks> LaserJock: not right now, uploading unity to maverick will take me a long time already
[16:30] <LaserJock> didrocks: ok, I just didn't want to duplicate or miss work you're planning on
[16:33] <Amaranth> seb128: So you want to drop our patches and just sync from Debian?
[16:33] <didrocks> LaserJock: no pb, just keep me in touch :)
[16:33] <LaserJock> didrocks: k, will do
[16:33] <seb128> Amaranth, I want to investigate whether it would be doable and a good idea
[16:33] <seb128> Amaranth, or at least be back in sync for all the side packages, ccsm, -gconf, etc
[16:42] <Amaranth> seb128: I'm fine with getting back in sync with Debian for the side packages, we don't patch them or anything
[16:43] <Amaranth> seb128: But we modify compiz quite a bit
[16:43] <seb128> ok
[16:43] <seb128> thanks for the feedback
[16:43] <Amaranth> Although since development seems to be moving to mutter I suppose we don't need to modify it to start faster, it's already 10x faster than mutter for that
[16:45] <seb128> Amaranth, not my experience there
[17:16] <seb128> chrisccoulson, I uploaded gtk csd in maverick
[17:17] <seb128> chrisccoulson, you might want to upload firefox to get decoration back for it
[17:19]  * kenvandine heads out to lunch, bbiab
[17:56] <chrisccoulson> seb128 - thanks, i will disable that in firefox later then
[18:02] <pitti> good night everyone, have a nice weekend!
[18:02] <didrocks> enjoy your weekend pitti!
[18:45] <didrocks> kenvandine: do you know of any documentation about the batch_update() method in desktopcouch?
[18:46] <kenvandine> i don't
[18:47] <didrocks> ok, worth a try :)
[18:52] <kenvandine> didrocks, my ultimate source is #ubuntuone :)
[18:53] <didrocks> kenvandine: sure, I'll delegate that for next week though :)
[19:00] <cjohnston> kenvandine: any further thoughts on bug 580067?
[19:00] <ubot2> Launchpad bug 580067 in gwibber "twitter fails to download messages, sometimes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/580067
[19:01] <kenvandine> cjohnston, ryan was going to look at it... he was very interested in it
[19:01] <kenvandine> he is at google I/O though...
[19:01] <cjohnston> ahh
[19:02] <kenvandine> he has some suspicions, and has been looking for someone that could repro it
[19:02] <kenvandine> so glad you found it :)
[19:03] <cjohnston> I am able to reproduce it daily.. heh   without any effort on my part
[19:03] <cjohnston> I'm glad I don't live by twitter
[19:18] <kenvandine> cjohnston, ryan thinks it might be something related to the way we compute the last message we downloaded
[19:18] <cjohnston> hmm//
[19:18] <kenvandine> so it fails to fetch more messages because it is trying to get messages that doesn't exist
[19:18] <cjohnston> gotcha
[19:19] <kenvandine> which he had suspected was a bug before you found this, but could never prove it
[19:19] <cjohnston> well.. then i guess we should hope that is what it is
[19:19] <kenvandine> yeah :)
[19:19] <kenvandine> i'll bug him about it
[19:19] <cjohnston> lol
[19:20] <cjohnston> you know where to find me
[19:53] <jcastro> kenvandine: http://sjoerd.luon.net/posts/2010/05/telepathy_and_vp8/
[19:53] <jcastro> YEAH!
[20:04] <kenvandine> jcastro, woot!
[20:55] <ccheney> Riddell, ping
[20:56] <ccheney> Riddell, i just saw that kubuntu-desktop doesn't pull in ttf-liberation, which is not so good
[20:56] <ccheney> Riddell, openoffice.org defaults to 'Times New Roman' which is not metric compatible with that, but due to not having any metric compatible fonts on the disk it ends up using it anyway
[20:57] <ccheney> er sorry
[20:58] <ccheney> Riddell, i meant the above to say since ttf-liberation is not installed which is metric compatible with 'Times New Roman' then it falls back to 'Times' which then falls back to 'Nimbus Roman No9 L' which is the font not metric compatible with 'Times New Roman'
[20:58] <ccheney> Riddell, it appears ubuntu, xubuntu, lubuntu all pull ttf-liberation in directly probably due to the metric issue
[21:00] <ccheney> Riddell, it might be a good idea to pull it in for 10.04.1 as well due to problems working with documents on kubuntu due to that (if allowable)
[21:01] <ccheney> Riddell, i haven't gotten any bugs reports about this issue afaik but saw it when testing another bug under kubuntu
[21:02] <ccheney> Riddell, if you would like i can file a bug about kubuntu-meta
[21:02] <ccheney> s/about/against
[22:51] <ccheney> hmm example-content is also missing from kubuntu


[01:53] <wxl> infinity, vorlon: any reason why lubuntu can't have usb-creator(-kde) in our packageset?
[02:02] <vorlon> wxl: implying that lubuntu devs would be able to upload usb-creator, a package for which the Lubuntu team are definitely not the current maintainers?
[02:03] <vorlon> LocutusOfBorg: reprotest/i386> yeah I was trying to figure out if that wasn't the result of a progression rather than a regression, but I see now that it isn't - hinting
[02:17] <teward> vorlon: can you hand-wave a no-change rebuild in the SRU queue?  Or should I wait for the rest of the SRU team to address it?
[04:08] <wxl> vorlon: we do use usb-creator-kde in our flavor. perhaps that's insufficient?
[04:55] <vorlon> wxl: and usb-creator-gtk is seeded in ubuntu-desktop, ubuntukylin-desktop, and ubuntu-mate-desktop.  So ubuntu-desktop looks like the correct packageset to me
[04:56] <vorlon> teward: I'm not in a position to do SRU reviews this evening, sorry
[04:56] -queuebot:#ubuntu-release- New: accepted pdal [arm64] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [armhf] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [amd64] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [armhf] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [ppc64el] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [amd64] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [ppc64el] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [arm64] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [s390x] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [s390x] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [i386] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [i386] (eoan-proposed) [1.9.1+ds-1]
[06:14] -queuebot:#ubuntu-release- New binary: python-pdal [amd64] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: python-pdal [i386] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: python-pdal [s390x] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: python-pdal [ppc64el] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:16] -queuebot:#ubuntu-release- New binary: python-pdal [arm64] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:16] -queuebot:#ubuntu-release- New binary: python-pdal [armhf] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[07:45] -queuebot:#ubuntu-release- Unapproved: lasso (bionic-proposed/main) [2.5.1-0ubuntu1 => 2.5.1-0ubuntu1.1] (ubuntu-server)
[07:45] -queuebot:#ubuntu-release- Unapproved: lasso (disco-proposed/main) [2.6.0-2build1 => 2.6.0-2ubuntu0.1] (ubuntu-server)
[07:48] <sil2100> grrr, pending-sru page again is outdated, I'm running sru-report locally to determine if it's crashing or maybe it's just something with the runs on snakefruit
[07:49] <sil2100> Ok, it doesn't crash
[07:50] <sil2100> Laney, cjwatson: could one of you log into snakefruit and check what's up? The current report is "Generated: 2019-07-12 15:54:18 UTC"
[07:50] <sil2100> I was able to successfully run sru-report and get some meaningful output
[07:52] <RikMills> sil2100: morning. I need to do some more verification on the list of bugfixes, which I doubt I can finish today, but I assume it would be possible to get the Plasma SRU out later in the week?
[07:53] <RikMills> I would like it to have some time in release pocket before we cook the 18.04.3 isos!
[07:58] <sil2100> RikMills: sure, +1 on that - just give me a poke once you feel we're good to go
[07:59] <RikMills> thanks :)
[08:05] <Laney> sil2100: ok, done - that's the third time this has happened lately
[08:06] <Laney> dunno if you want to add some logging and find out where it's hanging, then make that part more resillient
[08:06] <sil2100> Laney: actually I saw compontent-mismatches outdated as well
[08:06] <sil2100> Like, the current component-mismatches is from 2019-07-12 20:30
[08:06] <sil2100> There's a .html.new from today, but it's like half-way generated?
[08:07] <sil2100> Weird things are happening lately
[08:08] <sil2100> Laney: anyway, thanks for running that, guess +1 on adding some logging - we never had frequent issues like that, so no one really needed any debugging
[08:09] <Laney> actually I found this from component-mismatches
[08:09] <Laney> https://paste.ubuntu.com/p/nhkGXGfcjk/
[08:24] <sil2100> huh
[08:39] <Laney> thanks freenode™
[08:40] <Laney> this person's display name is breaking it https://launchpad.net/~paelzer 😈
[08:42] <cjwatson> haha
[08:42] <cjwatson> hopefully not too hard to fix
[08:43] <apw> oh the circle of friends; heh
[08:48] <sil2100> cpaelzer: ^ hah, it's you who broke the component-mismatches report!
[08:48] <ogra> probably time to switch it to utf8 then ;(
[08:48] <ogra> err
[08:48] <ogra> ;)
[08:50] <cpaelzer> sil2100: yes apw found that
[08:50] <cpaelzer> but I have the UTF char so long that I wonder it broke now
[08:50] <cpaelzer> anyway thanks apw for fixing
[08:51]  * apw hands the bottle of thanks to Laney
[08:58] <Laney> sil2100: something like lp:~laney/ubuntu-archive-tools/cm-utf8
[08:58] <Laney> there's probably a strictly more complete / correct way to do that
[08:59] <Laney> I can't commit to lp:ubuntu-archive-tools so please review and do it if you like it :-)
[09:00] <cjwatson> I have horrible things at the start of various scripts I've written that force stdout to be UTF-8
[09:01] <cjwatson> That sort of thing may do the job but note that I'm pretty certain it will break in Python 3
[09:02]  * cjwatson hunts
[09:02] <cjwatson> Laney: https://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/view/head:/build/util/help-to-gfxboot.py#L14 maybe?
[09:03] <Laney> cjwatson: yeah OK, this is probably better than leaving a time-bomb behind
[09:03] <Laney> thanks
[09:04] <cjwatson> (The Python 3 hack there shouldn't be necessary in practice as of 3.7, since it was really just to deal with LC_CTYPE=C and 3.7 coerces that to UTF-8, but it should also still be harmless on 3.7)
[09:07] <LocutusOfBorg> vorlon, hello, how do you feel about merging iptables from unstable=?
[09:15] <LocutusOfBorg> and please don't look at my squid upload, thanks (I'm deeply sorry for the quality of the upload, but I couldn't fix it)
[09:17] <LocutusOfBorg> (I can say, such bugs are already there, gcc-9 is just showing them)
[09:52]  * Laney pokes sil2100
[09:56]  * LocutusOfBorg pockes somebody to accept python-pdal
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [amd64] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [armhf] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [ppc64el] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [arm64] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [s390x] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [i386] (eoan-proposed) [2.1.8+ds-2]
[10:22] <sil2100> Laney: ugh! Looking ;)
[10:23] <sil2100> Ah, I see apw already merged it o/
[10:24] <Laney> yeah
[10:26] <LocutusOfBorg> thanks nftables for not failing locally, on pbuilder, on sbuild on debomatic and failing on ubuntu archive with no reason :(
[10:29] <sil2100> Laney: btw. do you know if sru-report is hung again on snakefruit?
[10:30] <Laney> sil2100: no, should run soon
[10:31] <sil2100> Ah, ok, I see the .new there indeed, thanks
[10:32] <Laney> yeah seems to be moving
[11:36] -queuebot:#ubuntu-release- Unapproved: wslu (bionic-proposed/main) [2.0.0-0ubuntu2~18.04.0 => 2.0.0-0ubuntu2~18.04.1] (no packageset)
[11:36] -queuebot:#ubuntu-release- Unapproved: wslu (xenial-proposed/main) [2.0.0-0ubuntu2~16.04.0 => 2.0.0-0ubuntu2~16.04.1] (no packageset)
[11:36] -queuebot:#ubuntu-release- Unapproved: wslu (disco-proposed/main) [2.0.0-0ubuntu2 => 2.0.0-0ubuntu<IP_ADDRESS>] (core)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [amd64] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [ppc64el] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [i386] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [s390x] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: nftables [arm64] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: nftables [armhf] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[12:48] <LocutusOfBorg> hello, please accept nftables, I plan to transition it...
[12:50] <teward> anyone on SRU today to handle the no change rebuild SRU for NGINX in the Bionic unapproved queue?  Just asking since theres TLS1.3 isms for managing TLS 1.3 proto and ciphers hat are ignored unless we build against 1.1.1 now in the repos there
[12:51] <apw> teward, can do
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [amd64] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [armhf] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [ppc64el] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [arm64] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] <teward> apw thank you kindly.
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [s390x] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [i386] (eoan-proposed) [0.9.1-2ubuntu2]
[12:55] <apw> teward, and those are correctly in -security ?  the openssl updates
[12:57] <apw> teward, or are we actually trying to have nginx in -security with different support to those in -updates
[12:57] <teward> apw: ask mdeslaur.  they never brought 1.1.1 into -security
[12:57] <teward> so the repos are TECHNICALLY in a diverged state
[12:57] <teward> and that was apparently Security's decision
[12:58] <mdeslaur> nono, we're still waiting for the last openssl SRU to go through before all the packages get copied to -security
[12:58] <teward> so that is out of my hands to answer
[12:58] <teward> so it sounds like the SRU queue needs more love and attention then?
[12:59] <apw> mdeslaur, so it is appropriate to have an nginx in -proposed built against 1.1.1 then, right ?
[12:59] <mdeslaur> not sure why 1832919 isn't being released for bionic
[12:59] <mdeslaur> apw: yes
[12:59] <mdeslaur> apw: we can rebuild it in -security if/when we want
[13:00] <apw> mdeslaur, i can see no reason it is not released and some time ago
[13:01] <apw> mdeslaur, oh because its not released in disco
[13:01] <mdeslaur> :(
[13:02] <apw> xnox, your openssl upload is all lagging in disco ... for lack of validation on some of the 'other' bugs
[13:05] -queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.14.0-0ubuntu1.3]
[13:05] <apw> teward, anyhow ^ seems appropriate in the new world order, even if we cannot release it
[13:05] <apw> (though i believe we can to -updates only)
[13:08] <teward> apw: ack.
[13:11] -queuebot:#ubuntu-release- Unapproved: accepted creduce [source] (disco-proposed) [2.10.0-1~19.04]
[13:11] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1014.15] (no packageset)
[13:21] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2.2]
[13:36] -queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (disco-proposed) [4.18.0-1ubuntu2.1]
[13:41] -queuebot:#ubuntu-release- Unapproved: accepted creduce [source] (bionic-proposed) [2.10.0-1~18.04]
[13:47] -queuebot:#ubuntu-release- Unapproved: secureboot-db (bionic-proposed/main) [1.4~ubuntu<IP_ADDRESS> => 1.5~ubuntu<IP_ADDRESS>] (core)
[13:47] -queuebot:#ubuntu-release- Unapproved: secureboot-db (xenial-proposed/main) [1.4~ubuntu<IP_ADDRESS> => 1.5~ubuntu<IP_ADDRESS>] (core)
[13:47] -queuebot:#ubuntu-release- Unapproved: secureboot-db (disco-proposed/main) [1.4 => 1.5~ubuntu<IP_ADDRESS>] (core)
[13:49] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (disco-proposed) [2.0.0-0ubuntu<IP_ADDRESS>]
[13:53] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (bionic-proposed) [2.0.0-0ubuntu2~18.04.1]
[14:06] <xnox> apw:  right, let me verify all the things then.
[14:18] <coreycb> sil2100: hello, if you have any cycles for your SRU rota today we have cinder and designate in the bionic unapproved queue that fix ftbfs in bionic-proposed. i've also synced with folks since to make sure we're on the same page with ensuring packages build successfully before hand.
[14:22] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (xenial-proposed) [2.0.0-0ubuntu2~16.04.1]
[14:56] <sil2100> coreycb: ok o/
[15:10] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.7-0ubuntu2]
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted designate [source] (bionic-proposed) [1:6.0.1-0ubuntu1.2]
[15:24] -queuebot:#ubuntu-release- Unapproved: cargo (disco-proposed/universe) [0.35.0-0ubuntu1~19.04.1 => 0.36.0-0ubuntu1~19.04.1] (no packageset) (sync)
[15:25] -queuebot:#ubuntu-release- Unapproved: rustc (disco-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~19.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~19.04.1] (no packageset) (sync)
[15:26] -queuebot:#ubuntu-release- Unapproved: cargo (bionic-proposed/universe) [0.35.0-0ubuntu1~18.04.1 => 0.36.0-0ubuntu1~18.04.1] (no packageset) (sync)
[15:26] -queuebot:#ubuntu-release- Unapproved: rustc (bionic-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~18.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~18.04.1] (no packageset) (sync)
[15:26] -queuebot:#ubuntu-release- Unapproved: cargo (xenial-proposed/universe) [0.35.0-0ubuntu1~16.04.1 => 0.36.0-0ubuntu1~16.04.1] (no packageset) (sync)
[15:27] -queuebot:#ubuntu-release- Unapproved: rustc (xenial-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~16.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~16.04.1] (no packageset) (sync)
[15:29] -queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (bionic-proposed) [0.36.0-0ubuntu1~18.04.1]
[15:29] -queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (bionic-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~18.04.1]
[15:32] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1014.15]
[15:37] <coreycb> sil2100: thanks!
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (disco-proposed) [0.36.0-0ubuntu1~19.04.1]
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (xenial-proposed) [0.36.0-0ubuntu1~16.04.1]
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (disco-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~19.04.1]
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (xenial-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~16.04.1]
[15:47] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (disco-proposed) [13.2.6-0ubuntu<IP_ADDRESS>]
[15:56] <xnox> apw:  about eoan - 5.2.0-8.9 looks all green on autopkgtests (retried a few things in the morning) is it good to unblock, or not yet?
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.12-0ubuntu<IP_ADDRESS>]
[16:04] <apw> xnox, do i have it blocked ?
[16:04] <apw> xnox, i thought sforshee had a couple of test failures; perhaps not
[16:04] <apw> xnox, or is it blocked on the bug ...
[16:10] <sforshee> apw, xnox: yes blocked on the bug
[16:11] <sforshee> trying to confirm that a network-manager test regression is not a kernel regression
[16:13] -queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (disco-proposed) [1.5~ubuntu<IP_ADDRESS>]
[16:13] -queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (bionic-proposed) [1.5~ubuntu<IP_ADDRESS>]
[16:14] <Laney> the network-manager tests are in a fairly bad state atm unfortunately
[16:14] -queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (xenial-proposed) [1.5~ubuntu<IP_ADDRESS>]
[16:14] <Laney> Till's been working on them
[16:15] <Laney> rcj: could you review https://code.launchpad.net/~mvo/livecd-rootfs/+git/livecd-rootfs/+merge/370065 again pls?
[16:16] <vorlon> Laney: do you also intend to cherry-pick https://code.launchpad.net/~tobijk/livecd-rootfs/+git/livecd-rootfs/+merge/370096 to bionic or do you need tobikoch to submit a second MP?
[16:16] <sforshee> Laney: I assume part of that is because it tries to build modules and the -fcf-protection thing is breaking that
[16:17] <vorlon> if that were so, the tests should be passing w/ linux 5.2 in -proposed
[16:17] <sforshee> right, there are some IPv6 address assignment tests failing with 5.2 that look to be new failures
[16:17] <Laney> sforshee: They're broken independent of that
[16:18] <sforshee> although my laptop is getting an IPv6 address just fine
[16:18] <Laney> I suppose you could run what you've seen past Till and he might be able to tell you if it's new or not
[16:18] <vorlon> anyway, 'AssertionError: 0 not greater than or equal to 2 : []' doesn't point to a kernel module issue ;)
[16:19] <Laney> vorlon: I can do, once these changes are validated in eoan
[16:19] <Laney> would be helpful if the bug(s) were proactively SRUified if they aren't already
[16:20] <vorlon> Laney: validated in eoan> since there seems to be a fair bit of urgency around this, I'd suggest not waiting for such verification before SRUing but doing it in parallel
[16:20] <vorlon> tobikoch: ^^ could you fix up the bug report to add the appropriate SRU template?
[16:20] <Laney> vorlon: well I'm not going to be able to get to it before finishing today, was planning to see tomorrow's ISOs and then backport
[16:20] <vorlon> ok :)
[16:21] <Laney> feel free to take over though if you'd like
[16:21] <vorlon> probably ENOTIME for that, just trying to make sure no one is blocked :)
[16:21] <Laney> nod
[16:25] <sforshee> tkamppeter: so Laney says you've been working on broken network-manager tests, I'm seeing a couple of failures with the kernel in eoan-proposed and it would be helpful to know if those are known to be broken or racy
[16:25] <sforshee> the ones that are failing are:
[16:25] <sforshee> ethernet: manual connection, IPv6 with only RA, preferring public address
[16:25] <sforshee> ethernet: manual connection, IPv6 with only RA, preferring temp address
[16:28] <sforshee> oh and this one shows up in one of the logs too, but only once - ethernet: auto-connection, IPv6 with DHCP
[16:28] <sforshee> the others have appeared in multiple runs
[16:32] <tkamppeter> I was only aware of that some tests do not work.
[16:33] <tkamppeter> sforshee, for further development on the test script (better debuggability) I have repeatedly run some of the tests. There I have also observed that the  ethernet: manual connection, IPv6 with only RA, preferring public address sometimes fails.
[16:34] <tkamppeter> sforshee, the test system has kernel 5.0.0-20.
[16:34] <sforshee> tkamppeter: ok so that's something, though it has seemed to fail fairly consistently in adt with 5.2
[16:34] <sforshee> but maybe I'm just having bad luck
[16:35] <sforshee> it's only happened on amd64 and i386 though which is also odd
[16:36] <tkamppeter> sforshee, what is "adt"?
[16:37] <sforshee> tkamppeter: autopkgtest, I can't remember what that acronym was for (auto device test?) but I guess it is outdated
[16:38] <cjwatson> In the very early days it was autodebtest and the initialism persisted in command names for a while (partly because apt- wasn't a good prefix to use)
[16:38] <cjwatson> Now the commands are just autopkgtest or autopkgtest-* though)
[16:39] <sforshee> our kernel tooling still calls it adt, so that's what I tend to call it
[16:40] <Laney> rcj: (I think that it's not the place you indicated it should be put in)
[16:51] <tkamppeter> Is there any known bug in network support in kernel 5.2? Or a known change of how some of its networking functionality works?
[16:51] <Laney> (commented)
[16:52] <Laney> (re: livecd-rootfs; going to upload without mvo's change now)
[16:53] <teward> sil2100: autopkgtest fail due to internal test env networking issues is unrelated to NGINX SRU; retry queued
[16:53] <sforshee> tkamppeter: I'm not aware of any relevant networking bugs/changes from 5.2 right now, but every release has a lot of networking changes
[16:53] <teward> internal "unable to connect to ftpmaster" tends to be env related :P
[16:55] <sforshee> tkamppeter: I'm looking through the logs, it seems like the connection is getting activated so maybe it just isn't happening quickly enough
[16:56] <sforshee> the inconsistency of which tests fail in a given run also support that as a possibility
[16:57] <tkamppeter> sforshee, this is possible. for me it fails in the ethernet case (still with 5.0.x kernel) in the .add_and_activate_connection() step, this is also a reason why I continued improving the debuggability of the main loops.
[17:03] <tkamppeter> sforshee, generally, the failures I observe happens rather rarely, perhaps once in 10 runs, so a timout or race issue is possible, probably not a general incompatibility, but note that I am still on 5.0.0-20.
[17:04] <sforshee> tkamppeter: yeah the thing that worries me is that I can't get any run with no failures at all
[17:06] <tkamppeter> sforshee, does it fail always at the same place in the same way (=incompatibility of new kernel with current NM -> Need to contact NM upstream) or is the density of sporadic failures so high that the probability of all the tests passing is near zero?
[17:15] <sforshee> tkamppeter: it's that one or more of a small subset of tests fail every time, but which test varies from run to run
[17:20] <tkamppeter> sforshee, if each test passes at least sometimes we have most probably no incompatibility but more some slowing factor.
[17:20] <sforshee> yeah that's what I'm thinking
[17:32] <teward> sil2100: autopkgtest regression for bug #1836366 cleared - the regression was entirely local to the test env with networking, no actual regression observed.
[19:20] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
[19:21] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
[19:23] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
[19:24] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
[21:16] -queuebot:#ubuntu-release- New binary: plymouth [amd64] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:16] -queuebot:#ubuntu-release- New binary: plymouth [s390x] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:17] -queuebot:#ubuntu-release- New binary: plymouth [i386] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:17] -queuebot:#ubuntu-release- New binary: plymouth [ppc64el] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:21] -queuebot:#ubuntu-release- New binary: plymouth [armhf] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:26] -queuebot:#ubuntu-release- New binary: plymouth [arm64] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)


 Hello everyone, just now I have shifted from Kubuntu to Ubuntu OS on my main laptop, but after finishing the installation, post Reboot the CPU usage is 100% due to the systemd_journal process...
 When earlier I was using Kubuntu, I found this solution to get out of this systemd_journal issue and it did work but when I applied the same on Ubuntu OS nothing happened. Still, CPU usage is 100%.
 I know this group is made for Kubuntu support only but still if i can get some help from anyone, it would be really appreciated..thanks (re @Student: The systemd-journald is service in Linux OS that collects and stores the logging data.
 On some Linux distributions it is often found that systemd-journald service is consuming more than 90% or some times nearly 100% of CPU resources.
 So here's a fix for this problem...
 Open your terminal and type following command.(You can use text editor of your choice.)
[03:04] <tomreyn> Student: systemd-journald is the systemd system logging / journalling daemon. it stores system log files which you can inspect using the journalctl command. if the daemon is keeping the cpu busy, this might be because it is logging a LOT. and that may be because something is malfunctioning,spewing out lines that are to be logged all the time.
[03:05] <tomreyn> journalctl -f    will show the logs lines as they are being added. if running this command writes a lot of repeating lines to screen then find out what it is that logs this, and stop / fix it.
[03:06] <tomreyn> https://linuxtechos.blogspot.com/2018/11/solvedhigh-cpu-usage-by-systemd.html (which you seem to have quoted above) is old, i also don't see how the supposed fix (workaround rather) is (directly) related to the symptom - it may just have helped this one persons' computer, but i would not expect it to be a universal solution to this problem.
[05:16] <KevlarNoir> HELLO
[05:17] <KevlarNoir> good morning
[05:45] <alkisg> o/
[12:22] <BluesKaj> Hi all
 Can you please suggest some YouTube video or article that will guide me to understand and help to resolve this issue step by step.. thanks (re @IrcsomeBot: <tomreyn> journalctl -f    will show the logs lines as they are being added. if running this command writes a lot of repeating lines to screen then find out what it is that logs this, and stop / fix it.)
[13:15] <tomreyn> Student: I was looking for some web page describing the symptom and providing a general approach to identifying the root cause yesterday, but could not really. this one (from a debian user) describes the symptoms well enough: https://unix.stackexchange.com/questions/606291/systemd-journald-and-rsyslogd-high-cpu-usage
[13:16] <tomreyn> it also discusses some commands you can use to get a better idea of what the root cause may be, just as i suggested running   journalctl -f   yesterday
[13:16] <tomreyn> have you done so, yet?
[13:31] <omegatron> hm, my KMail crashes at startup (Kubuntu 21.0.4); in the crash report window, following the "How to create useful crash reports" link (because of some lines with '??'), it tells me to instal -dbgsym packages.. well how would I do that?  apt-cache doesn't find them and the Muon Package Manager is not helpful at all ...
 I think the issue got resolved itself😂. When first I installed Ubuntu on my laptop, the CPU usage was 100%, so I changed "quiet splash" to "pci=nomsi" in the grub file, but the issue did not resolve by changing it. So I texted here to get some help.
 Today, after seeing your message,
  I reverted the same settings by replacing "pci=nomsi" with "quiet splash" to get the output of this command (journalctl -f) but before running this command, I checked my CPU usage and now I am not getting any high CPU usage...😁 it's normal... (re @IrcsomeBot: <tomreyn> have you done so, yet?)
 How do i play .ts file on Ubuntu? Default player doesn't support .ts file and VLC player does support it but the problem with VLC player is that,  it's very lagging when i tried to forward/backward the video and there is some delay in video and audio on vlc(same issue was with windows earlier and now with linux)
 On windows, pot Player was perfect to play .ts file without any lagging and it was very smooth but on Linux OS the pot player is still not available.
 So is there any other video players, which works smooth?
[15:08] <BluesKaj> VLC and Smplayer do very well on Linux
[15:08] <mybalzitch> tried mplayerc ?
[15:08] <mybalzitch> that might be old software now
[15:09] <BluesKaj> it's not old it's up to date
[15:20] <BluesKaj> I use both VLC and Smplayer on Kubuntu dev release 21.10 which I'm testing atm, and both players work very well, nice and smooth
[15:54] <BluesKaj> later all, take care
[16:24] <tomreyn> Student: i still doubt that botting with "pci=nomsi" is a magical fix to solve whatever yet unknown root cause that drives up cpu load on systemd-journald. what may happen is that adding "pci=nomsi" removes functionality which now prevents the root cause from occurring. maybe. we don't really know for lack of details.
[16:26] <tomreyn> !dvdcss | Student
[16:27] <tomreyn> !dvd | Student
 Ok, will try this later and let you know, my daily Internet data got exhausted now. (re @IrcsomeBot: <BluesKaj> VLC and Smplayer do very well on Linux)
 Thanks for the suggestions, will try and let you know. (re @IrcsomeBot: <mybalzitch> tried mplayerc ?)
 Don't know about smplayer, but did you tried to play .ts format file on VLC? I am sure you will face lagging issue on VLC.. (re @IrcsomeBot: <BluesKaj> I use both VLC and Smplayer on Kubuntu dev release 21.10 which I'm testing atm, and both players work very well, nice and smooth)
 Rightly said, without knowing the root causes we can't say anything... But in the future, if I face a similar issue, then first I'll run the "journalctl -f" command & will take a screenshot and I'll share it with you to find the root causes.. thanks for the help buddy😇.  Appreciated. (re @IrcsomeBot: <tomreyn> Student: i still doubt that botting with "pci=nomsi" is a magical fix to solve whatever yet unknown root cause that drives up cpu
[17:48] <tomreyn> you're welcome
 I Will try it later, thanks 😇 (re @IrcsomeBot: <ubottu> Student: Ubuntu's default installation and repositories do not include packages needed to play commercial DVDs for legal reasons. For information on adding them, see https://help.ubuntu.com/community/RestrictedFormats/PlayingDVDs | For information on the legalities involved, see the "DVD" section of https://help.ubuntu.com/community/FreeFormats)
 Need some suggestion, my friend wants to buy a VPN so he asked me. But you all are more experienced then me so which one you suggest?
 His primary requirements are :-
 1) no log privacy
 2) unblock sites
 3) faster speed
 Checked on the internet,  most people are saying to go for Nord and Express VPN.
[18:11] <oerheks> VPN choice is not a Kubuntu support issue
 Ok, i was just asking for suggestion, but no problem..thanks
[19:15] <user|62> What changed in USB between Kubuntu 18.x or 19.x and 20.04 that requires a firmware upgrade to the Brother scanner/printers?
[19:33] <user|57> hola
[19:34] <user|57> help
[19:34] <user|57> alguien habla español
[19:47] <Guest71> Hi, my Windows Key suddenly stopped working. Im on KDE Plasma 5.22.5
[19:52] <valorie> by "not working" what do you mean?
[19:52] <valorie> my keyboard has no "windows" key, so....
[19:54] <Guest71> I cant open the start menu with it
[20:14] <valorie> ah
[20:18] <Guest1> hi i got disconnected i just asked about my windows key
[21:00] <user|2> Uploaded file: https://uploads.kiwiirc.com/files/fd691f211246fe7bd45e8f1e6cf93810/E821E2AD-1C85-4620-9C47-B95DEE093B4C.pdf
 Ubuntu:- How do i get Timeshift Restore option on Grub Menu? I am using BTRFS file system...
[22:38] <Mekaneck> @Student keep in mind that this IRC channel and Telegram group is tailored at support for Kubuntu not Ubuntu
[22:39] <Mekaneck> And afaik you can't get a restore option for timeshift in grub
 Ok, good bye