[01:45] <OvenWerks> Eickmeyer: um, ok, so long as it runs after the ondemand one on ubuntu.
[03:00] <Eickmeyer[m]> OvenWerks: It won't even run unless it's enabled, which it's not by default.
[15:59] <OvenWerks> Eickmeyer: ok, Im confused. I am not sure "what" won't run unless its enabled"
[16:01] <Eickmeyer[m]> OvenWerks: So, a systemd service file does nothing unless called upon. By sitting in /lib/systemd/system it does nothing unless someone calls "systemctl start *.service". Additionally, it does nothing at boot unless it's enabled by "systemctl enable *.service".
[16:01] <OvenWerks> not true
[16:02] <OvenWerks> at least that has not been my experience
[16:02] <Eickmeyer[m]> Any systemd document I have ever read says what I wrote.
[16:02] <OvenWerks> enable *.service just drops a link in the right place
[16:03] <Eickmeyer[m]> The file simply "exists" until called upon.
[16:03] <OvenWerks> if the link is pre installed it runs
[16:03] <Eickmeyer[m]> Exactly, enabling it to be called-upon at boot.
[16:03] <Eickmeyer[m]> In this case, I'm not doing that.
[16:04] <Eickmeyer[m]> (not creating the link)
[16:04] <OvenWerks> all of the scripts in /lib/systemd/ do nothing unless there is service that calls them.
[16:05] <OvenWerks> From a package?
[16:05] <Eickmeyer[m]> Correct, and that service must be in /lib/systemd/system and either A) linked in /etc/systemd/system or B) manually run.
[16:05] <OvenWerks> a package should create all needed links
[16:05] <OvenWerks> Are we still talking about -controls/ondemand?
[16:05] <Eickmeyer[m]> That's correct, but if it's a systemd link it needs to be created the systemd way.
[16:06] <OvenWerks> no that is not true.
[16:06] <Eickmeyer[m]> Yes, but controls/ondemand is diferent.
[16:06] <OvenWerks> the package can create the link just fine.
[16:06] <Eickmeyer[m]> Ok, I'll rephrase that. A systemd link should be created the systemd way.
[16:06] <OvenWerks> not for a package install
[16:07] <Eickmeyer[m]> Which isn't hard (postinst: systemd enable foo.system)
[16:07] <Eickmeyer[m]> *systemctl enable foo.system
[16:07] <OvenWerks> I still disagree... but whatever.
[16:08] <OvenWerks> the enable tends to put the links in /etc not in /lib/systemd/system/
[16:08] <Eickmeyer[m]> As it should.
[16:08] <Eickmeyer[m]> Enable simply makes it run at boot.
[16:08] <OvenWerks>  the /etc/ should only be used for local config not package config
[16:09] <Eickmeyer[m]> There are exceptions to that, in this case, systemd services.
[16:09] <OvenWerks> that is so the system admin can modify the operation of the system without making package upgrade fail
[16:09] <Eickmeyer[m]> Systemd throws that old rule out the window.
[16:09] <OvenWerks> not very smart
[16:10] <OvenWerks> not old rule but correct rule
[16:10] <Eickmeyer[m]> But it is the way that it is. systemd is smarter at handling that situation than you think.
[16:10] <OvenWerks> systemd also runs correctly puts in links in the correct places too.
[16:11] <Eickmeyer[m]> Yes, but not unless it's told.
[16:11] <OvenWerks> putting a link in the right place "tells" systemd what to do with it
[16:12] <Eickmeyer[m]> That's correct. Such as when systemd is told to enable a .system file, it makes a link in /etc/systemd/system/{target.wants}.
[16:13] <Eickmeyer[m]> It bases that link on the systemd file saying "WantedBy = *.target".
[16:13] <OvenWerks> or even if the link is in /lib/systemd/system or a sub directory
[16:13] <OvenWerks> I have tested this rather a lot
[16:14] <OvenWerks> it does work even without use the "enable" command even with no link in /etc
[16:14] <Eickmeyer[m]> Yes, but it doesn't automatically run in anything in /lib/systemd/system unless it's enabled. ondemand.service is an exception because it's enabled on Ubuntu systems already (there's a symlink in /etc/systemd/system/multi-user.target/) and it looks for anything in its directory called .conf.
[16:15] <OvenWerks> There are rather a lot of commands/files in /lib/systemd/system and /lib/systemd/user that just run with no link what so ever in /etc
[16:15] <Eickmeyer[m]> Yes, but the systemd file I made does not. It cannot unless it's "enabled".
[16:15] <OvenWerks> wrong totallly wrong I have seen things run with out any enabling done
[16:16] <OvenWerks> Then you have not put the link in the right place
[16:16] <Eickmeyer[m]> Then those things have a link somewhere in /etc/systemd.
[16:16] <OvenWerks> no they don't
[16:16] <Eickmeyer[m]> No, I don't want the systemd file I made to run on Ubuntu. I only want it to run on Fedora.
[16:17] <Eickmeyer[m]> Hence, I don't have Ubuntu enable it.
[16:17] <Eickmeyer[m]> If it makes you feel better, I can have .postinst delete it during install.
[16:17] <OvenWerks> unless systemd is totally different on fedora it likely works much the same way
[16:18] <OvenWerks> so how many files are in /etc/systemd/system/*/ ?
[16:18] <Eickmeyer[m]> Fine, I'll have postinst delete it, but it needs to be there for non-Ubuntu systems otherwise you can't even launch -controls.
[16:19] <OvenWerks> wierd
[16:19] <OvenWerks> it sounds like a really really bad design]
[16:20] <OvenWerks> just like hard linking /lib/systemd to /usr/lib/systemd
[16:20] <Eickmeyer[m]> Non-Ubuntu systems don't have ondemand.service. That's an ubuntu-only thing made to replace init.d/ondemand. So, nothing creates the cpufreq files that -controls reads when it starts. In order to fix that, I needed something to run a systemd service on boot.
[16:21] <OvenWerks> That much I can see
[16:23] <Eickmeyer[m]> And that is why I did what I did. I wouldn't want it to run at boot on Ubuntu since that conflicts with the operation of ondemand.service (not so much conflicts as runs the /systemd/ubuntustudio service twice). So, I made it "WantedBy=multi-user.target" so that it only gets called if it is seen in /etc/systemd/system/multi-user.target" as a symlink.
[16:24] <OvenWerks> so create another *.service file in /lib/systemd/system/ called whatever.service. It should have in it:
[16:24] <OvenWerks> [Unit]
[16:24] <Eickmeyer[m]> Yes, that's exactly what this has.
[16:24] <OvenWerks> Description=Set the CPU Frequency Scaling governor
[16:24] <OvenWerks> ConditionVirtualization=no
[16:24] <OvenWerks> ConditionPathExists=/sys/devices/system/cpu/online
[16:25] <OvenWerks> [Service]
[16:25] <OvenWerks> Type=idle
[16:25] <OvenWerks> ExecStart=/lib/systemd/studio
[16:25] <Eickmeyer[m]> It's much simpler than that: https://git.launchpad.net/ubuntustudio-controls/tree/lib/systemd/system/studio-system.service
[16:25] <OvenWerks> That one does have an install segment
[16:26] <Eickmeyer[m]> Yes, but that is for "systemctl enable" reference to make the symlink. The packaging file for rpms calls that as a postinst.
[16:27] <Eickmeyer[m]> Otherwise it sits there and does nothing. I verified it already.
[16:27] <OvenWerks> you can remove the Install section and just put a link in /lib/systemd/system/multi-user.target.wants/ too
[16:28] <OvenWerks> but yes it could just be enabled
[16:29] <Eickmeyer[m]> Exactly. Fedora (and openSUSE) like to do things the "systemd way" as opposed to Debian and Ubuntu that make a lot of compromises for people who objected to using systemd in the first place.
[16:29] <OvenWerks> but looking at the system folder it looks like even ubuntu has put everyth8ing in /etc
[16:30] <Eickmeyer[m]> Yep. That's done during the postinst scripts by way of "systemctl enable".
[16:31] <OvenWerks> so, I guess we couold change all of the systemd stuff to do that. Its fine if not very "Linuxy" (or Unixy"
[16:31] <OvenWerks> next question is does it work?
[16:32] <Eickmeyer[m]> Yes, it works.
[16:32] <OvenWerks> it may need ConditionPathExists=/sys/devices/system/cpu/online
[16:33] <Eickmeyer[m]> It doesn't.
[16:33] <Eickmeyer[m]> It just works the way it is. I have tested it.
[16:33] <OvenWerks> maybe it is fixed then
[16:34] <Eickmeyer[m]> Must be, but I do know I had to have kernel-tools installed since we change the cpu governor.
[16:34] <Eickmeyer[m]> brb, kid to school.
[16:35] <OvenWerks> when ubuntu first switched to systemd, and they were still using ondemand in /etc/init.d/ there were problems with it running too soon
[16:35] <OvenWerks> in fact, so far as I know cpufreq still had that problem last I looked
[16:36] <OvenWerks> (we don't use it anymore)
[16:43] <OvenWerks> Eickmeyer[m]: it is probably ok to have both ways of running that installed.
[16:43] <OvenWerks> it should not matter if it gets run twice (in ubuntu/debian)
[16:45] <OvenWerks> or we could set up ubuntu so that ondemand is merely turned off and use the second method to actually do the work.
[16:45] <OvenWerks> It sounds like in debian/buntu land, system is done one way and user another way.
[16:46] <OvenWerks>  it is also quite possible that debian/buntu basically ignores systemd in user land except for packages like pulse that come from and upstream that does systemd by default
[16:48] <OvenWerks> (except for gnome which kind of messes things up)
[16:52] <OvenWerks> I think that perhaps the debian packaging setup requires a multilevel config system for better stability when updating software...
[16:53] <Eickmeyer[m]> And that's very possible. I think, for consistency sake, I'll have postinst remove the systemd service I created, but the packaging for Fedora keep it.
[16:54] <Eickmeyer[m]> OvenWerks: For reference, here's the .spec file used to build the .rpm package: https://pagure.io/studio-controls/raw/master/f/studio-controls.spec
[16:54] <OvenWerks> Eickmeyer[m]: The main thing in ubuntu is that ondemand has a delay in it (60 sec)
[16:54] <OvenWerks> so it has to be "repaced"
[16:54] <Eickmeyer[m]> In that, I remove the ondemand-service stuff.
[16:55] <OvenWerks> *replaced
[16:55] <Eickmeyer[m]> So, there's no reason why in Ubuntu I couldn't remove studio-system.service.
[16:55] <Eickmeyer[m]> Just different ways of doing things. ¯\_(ツ)_/¯
[16:56] <Eickmeyer[m]> And, no, systemd isn't very unix-like. That was, and is, the biggest objection people have with it.
[16:58] <OvenWerks> It would be nice to have one set of files that just works... but then it would not work with a system that still uses /etc/init.d for everything :P
[16:59] <OvenWerks> There are somethings I like about systemd...
[17:00] <Eickmeyer[m]> I think, at this point, we have a run-time dependency on systemd for -controls, tbh.
[17:02] <OvenWerks> yup I don't think we nee to worry about making it work for slackware :)
[17:03] <Eickmeyer[m]> Hahaha
[17:03] <Eickmeyer[m]> Or Gentoo.
[17:05] <Eickmeyer[m]> So, do we start working on unbranding it next cycle?
[17:05] <OvenWerks> yes
[17:05] <Eickmeyer[m]> Cool.
[17:06] <Eickmeyer[m]> Either way, it runs and works on Fedora, haven't tried openSUSE yet.
[17:08] <Eickmeyer[m]> Though, for Fedora, I did have to package python-jack and zita-ajbridge.
[17:08] <OvenWerks> :)
[17:08] <OvenWerks> they are both worth having anyway
[17:09] <Eickmeyer[m]> Exactly. I was surprised they weren't there already. python-jack is undergoing review as we speak, and zita-ajbridge has been approved for release.
[17:10] <Eickmeyer[m]> I'm waiting for those both to hit RawHide. Once those hit, submitting studio-controls will be the next step.
[17:13] <Eickmeyer[m]> BTW, Fedora's default kernel (the only one they have, really) is very nicely optimized for lowlatency.


[05:21] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/hide-related-blueprints/+merge/181198
[05:23] <wgrant> StevenK: k
[05:40] <StevenK> wgrant: Re bug 1128655 ; http://pastebin.ubuntu.com/6009086/
[05:40] <_mup_> Bug #1128655: Creating a recipe and then requesting a build has an incorrect PPA selected by default in the build request dialog <confusing-ui> <easy> <ppa> <recipe> <ui> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1128655>
[05:44] <wgrant> StevenK: What will happen if the user can't write to either the last build PPA or the daily build PPA?
[05:46] <StevenK> wgrant: The list is populated with PPAs the user has upload permission for, so if the initial value is not in that list, I'd hope its ignored.
[05:49] <wgrant> StevenK: Right, which means you have the same problem.
[05:49] <wgrant> It ends up selecting the first PPA in the list.
[05:50] <StevenK> In the case of the daily build PPA or last build PPA being unappendable, I think that's okay
[05:50] <wgrant> I don't think so.
[05:50] <wgrant> It's too easy an accident to make, and lots of people make it.
[05:51] <wgrant> I think it should default to the daily build archive or nothing.
[05:51] <wgrant> Probably.
[05:51] <StevenK> Only probably?
[05:53] <StevenK> wgrant: Like http://pastebin.ubuntu.com/6009118/ , then?
[05:54] <wgrant> StevenK: Right, but you'll also need to change something so the <select> has an option for no value, and ensure that the form rejects that.
[05:55] <StevenK> Oh, so the default is empty string or something
[05:55] <StevenK> (With no daily build archive)
[06:12] <StevenK> wgrant: http://pastebin.ubuntu.com/6009155/
[06:21] <wgrant> StevenK: Does ensuring that the archive field is required not work?
[06:21] <wgrant> The form infrastructure has some built-in functionality to add a "(no value)" option.
[06:21] <wgrant> Or some text like that.
[06:27] <StevenK> wgrant: The only thing I can see like that is missing_value for Field
[06:27] <StevenK> But that doesn't add it to the vocab
[06:28] <wgrant> StevenK: It doesn't need to be in the vocab, just the form field.
[06:28] <wgrant> eg. +copy-packages overrides it to say "The same series"
[06:30] <StevenK> wgrant: Which requires a new class that subs from LaunchpadDropDownWidget -- all the existing code has a Choice()
[06:31] <wgrant> StevenK: Have you looked at the internals to see how you can make the option appear?
[06:32] <StevenK> I've tried. zope.schema eats babies.
[06:47] <StevenK> wgrant: http://pastebin.ubuntu.com/6009237/
[06:50] <wgrant> StevenK: Can you possibly just override the field used by the *widget* to have required=False, so the validation can see required=True as normal, obviating the need for the extra code in validate()?
[06:58] <StevenK> wgrant: I could, if I could figure out how to do that
[06:59] <wgrant> StevenK: You can do it using a custom_widgets attribute on the form, I think.
[07:00] <StevenK> Really?
[07:00] <StevenK> I thought I would have reach into setUpWidgets and such
[07:02] <wgrant> You might have to.
[07:02] <wgrant> custom_widgets might just let you specify custom classes.
[07:02] <wgrant> Not sure.
[07:02] <StevenK> I think it's just custom classes, yeah.
[07:09]  * wgrant mocks tests down from 3s to 0.008s.
[07:12] <StevenK> wgrant: I recall self.fields.omit() -- but it seems widgets don't work like that
[13:29] <GuidoPallemans> Hi everyone, I'm planning on building a launchpad app for the Ubuntu touch project, but I don't personally use launchpad actively. Can anybody help me what this app needs? it's going to be pretty basic
[23:48] <StevenK> wgrant: So yes, I can add a widget with required=False, but TBH, it's easier to change the field in the schema and eat the check in validate


[00:00] <xnox> vorlon:  yes.
[00:00] <xnox> vorlon:  bionic daily; eoan is fine.
[00:00] <vorlon> so we just need to sru back the snap base handling
[01:11] <xnox> vorlon:  well.... bionic snap seeding in desktop is kind of by-hand; whilst eoan uses ./snap-tool and is nicer.
[01:11] <xnox> vorlon:  i don't know what is the plan with backporting ./snap-tool to bionic.....
[08:19] <akik> what's ubuntu's policy on using NOPASSWD in sudoers? i'm asking because cloud-init is still doing it for the default user and cloud-init is originally a ubuntu project
[08:30] <cjwatson> I'm not sure there's a policy on it.  cloud-init probably does so because there's no point in requiring a password in environments where users typically don't have a password set at all.
[08:30] <cjwatson> (For cloud guests the default user usually only authenticates using an SSH key)
[08:32] <akik> i mean it lessens security if there's a user account on the system that can get root access without password
[08:32] <akik> and there's not warning about it
[08:32] <cjwatson> You should ask the cloud-init people specifically
[08:32] <akik> they didn't see any problem with it
[08:33] <cjwatson> You aren't going to get anywhere looking for a policy stick to hit them with
[08:33] <cjwatson> IMO anyway
[08:33] <akik> i don't want to hit anybody, just want to make systems safer
[08:33] <akik> :)
[08:36] <cjwatson> ("policy isn't a stick to hit people with" is an old catchphrase in the Debian policy-authorship community)
[08:43] <cjwatson> You could also discuss it with the Ubuntu security team I suppose.  No guarantee they'll agree with you of course
[10:08] <odc> akik: that's pretty much how it works on all "cloud" distros. It's a sane default. You can modify it if you want, but using passwords is very impractical on a large scale.
[10:19] <akik> odc: no it's not a sane default
[10:19] <maswan> I think it is a sane default
[10:19] <akik> cloud-init creates a default sudo NOPASSWD: user with no warning
[10:22] <maswan> yes, which is exactly what I'd expect, managing passwords is hardly something you want to deal with by default
[10:23] <odc> akik: in typical cloud deployments, we do not make a distinction between users and administrators. If someone has the ssh key to connect on a machine, then they can do anything they want. It has been like that for many years now.
[10:24] <akik> that's no excuse for keeping it that way
[10:24] <odc> well what would you do?
[10:24] <akik> security > convenience
[10:24] <akik> remove the NOPASSWD: from the sudo config
[10:25] <odc> and? what would be the password?
[10:26] <akik> whatever you set it as
[10:26] <akik> i'm not concerned about that
[10:27] <odc> and where was the password defined? in cloud-init? in clear-text?
[10:27] <akik> i'm not talking about getting rid of the ssh pki setup
[10:27] <maswan> just hardcode the password to "ubuntu"?
[10:27] <akik> just removing the default NOPASSWD: sudo config
[10:27] <akik> well now you're just being silly
[10:31] <odc> akik: you're just used to the old model. If you don't want someone to be root, just don't let him login to the machine at all. If you want to make sure an application cannot have root rights, run it in a container. That's pretty much ho it works now.
[10:32] <akik> it's not about "the old model". it's about obeying the normal system security practices
[10:33] <akik> ubuntu desktop doesn't do that, why should cloud-init do it?
[10:33] <akik> i'm sure if i suggested adding it to ubuntu desktop, it would be rejected
[10:36] <odc> because that's what people expect. Servers and desktop are managed in a different way. You don't do passwords when you manage hundreds or thousands of machines
[10:36] <odc> unless your server will be used by people you don't trust
[10:37] <akik> i'm sure you don't login to the shell with ssh if you "manage hundreds or thousands of machines"
[10:37] <akik> or you're doing it wrong then
[10:37] <odc> no, but ansible does
[10:37] <odc> also for debugging :(
[10:39] <odc> but i agree that immutable deployments are usually the best ^^
[12:24] <sladen> xnox: was there some intermediate discussion that was missed?
[12:25] <xnox> sladen:  no. it's been discussed for a while on-and-off for 1 year plus.
[12:25] <xnox> sladen:  do you have some concerns? literarly all of our installer are dog slow to boot, compared with installed systems and it's bad.
[12:26] <xnox> sladen:  i guess some flavours may be concerned about size. but we are talking about 11M difference in the age of booting of USB sticks, as nobody has floppies anymore.
[12:27] <xnox> sladen:  and it pisses me off that a faster create & boot exists, and we are not using it =)
[12:27] <sladen> xnox: if I understand correctly, there's only a single metric (1:+1.14 space gzip:LZ4) LZ4 14% larger than gzip?
[12:28] <sladen> xnox: decompression should be +/- the same.
[12:29] <sladen> xnox: if not, there's something sub-optimal in the I/O stage.  Like flushing/read size/blocking
[12:29] <sladen> xnox: ie. using a different, but near identical hammer, doesn't help if it's a screw, not a nail
[12:49] <TJ-> who's responsible for  manpages.ubuntu.com ?
[13:02] <xnox> sladen:  lz4 decompression with lz4 is 4x faster than gzip
[13:02] <xnox> sladen:  lz4 compression is 20% faster than gzip
[13:03] <xnox> sladen:  so update-initramfs -u speed inprovement is noticable, and speed boot is blazing fast.
[13:03] <xnox> sladen:  decompression speed is not +/- the same.
[13:03] <xnox> it's like 1.6s vs 0.1s
[13:04] <xnox> sladen:  the larger than gzip, is the only downside, with upsides in compression/decompression time
[13:16] <juliank> heh, launchpad lost another upload yesterday
[13:17] <juliank> I uploaded lvm2 for xenial and newer, and the bionic upload was never accepted into unapproved; but re-uploading it worked fine
[13:17] <juliank> :)
[13:17] <sladen> xnox: don't think the +/-20% is much to care about.   gzip/zlib and LZ4 use the same tech which is string matching.  Only real difference is that gzip has a Huffman coder on the front to squeeze the bits) ... which is where the extra 15% size reduction comes from, at the cost of doing bit shuffling to unpack those variable length symbols
[13:18] <sladen> xnox: however, the difference between 1.6s and 0.1s is *so* dramatic (for the same tech) that something /else/ is likely broken
[13:19] <sladen> xnox: (it should be the case that a 14% I/O saving is easily wiped out by the processing)
[13:19] <sladen> xnox: so, by all means go ahead; but the solution still appears to be trying alternative hammer, rather than understanding the problem
[13:26] <ogra> xnox, please take also into account that on Core the initrd is created off-device (being readonly at runtime), there the smallest size (uboot loading and moving the file in ram can be very slow with bigger initrd's) and decompression time are indeed more essential ...
[13:27] <sladen> xnox: with chunking + parallelisation (decoding while streaming), the overall time *should* trend to the time for the pure read() from the block-device.  Which *should* mean that a 15% I/O saving results in a 14% start->finish timing
[13:30] <sladen> xnox: with further optimisations to order the CPIO, and returns files/chunks as soon-as-ready, it should be possible to get a boot time /faster/ than the pure decompression speed (because unused data is never even uncompressed!)
[13:45] <xnox> sladen:  re:cpio ordering => i was pondering about that. But i'm not sure what the right order is, or if it matters. How do we get the file-listing of the full initrd? and stream things? or is it just a matter of putting init first?
[13:45] <xnox> sladen:  i don't believe kernel can do chunking and parallelisation for decoding while streaming for the initrd. but i might be wrong.
[13:46] <xnox> sladen:  ie. for lz4 we must use '-l' legacy format.
[13:49] <xnox> sladen:  also, for the public cloud workloads we do want to trade size & IO for cpu time. Typically clouds have fast ssd/nvme storage, but overcommitted cpu. Thus 14% larger size, and 400% faster decompress is a win there, unlike bare metal.
[13:50] <sladen> xnox: yeah, latter is complete opposite of ogra's boot-off-serial-EEPROM example :-)
[13:52] <ogra> well, more SD/eMMC ... :)
[13:52] <sladen> xnox: chunking/parallelisation code would likely need writing.  It might be possible to do that as a pure userspace ... minimum initramfs.cpio that unpacks an initramfs2.cpio
[13:53] <ogra> actual flash got rare nowadays ... to expensive
[13:54] <sladen> xnox: think the conclusion is that for /many/ use cases (perhaps even quite a lot), it's a cheap win (time taken to change a flag)
[13:55] <sladen> xnox: and that with specific, clearly defined use-cases; and spending 3 months testing+writing code where required, pretty much anything is optimisable/betterable.  Probably by quite large percentages
[13:56] <rbasak> TJ-: the best general answer is to use the Vcs-* fields from debian/control. That tells you what the maintainer considers to be the normative VCS source.
[13:57] <rbasak> TJ-: however that field isn't currently maintained well in the case of Ubuntu packages that have deltas against Debian, unfortunately.
[13:58] <xnox> sladen:  looking forward, we may be booting initrd-less in many cases. But then the question will come down to as to what i/o speed we get at the boot-protocol vs bootloader support - ie can grub/uboot/aboot/etc. boot lz4 compressed kernel image. and that is actually probably more interesting than initrd.
[13:58] <rbasak> Usually though if an Ubuntu delta exists and Vcs-* seems to point to Debian, that means that Ubuntu developers aren't maintaining the delta in a VCS.
[14:00] <xnox> sladen:  i hope you do agree that using lzma makes no sense at all in the cloud or bare-metal installers.
[14:00] <TJ-> rbasak: what's that in relation to? I'm confused?
[14:00] <xnox> sladen:  and it is a massive step up to use either gzip or lz4 for those.
[14:01] <sladen> xnox: LZMA is nuts for all use cases except one-time compress and TFTP/serial/EEPROM booting were I/O is the bottleneck
[14:03] <rbasak> 17:35 <TJ-> is there some voodoo to understanding where to find the actual, meaningful, git commit logs for package git repos?
[14:03] <rbasak> From above
[14:04] <TJ-> rbasak: oh! blimey, wasn't that yesterday? I thought you were on about manpages.ubuntu.com :D
[14:04] <rbasak> Essentially what I'm saying is that the git-ubuntu imports are guaranteed to reflect publication history in apt, and not necessarily what the developers of those packages actually use (Vcs-* is for that)
[14:04] <TJ-> rbasak: right; now I've got the context it makes sense :)
[14:05] <TJ-> rbasak: fortunately I didn't need to deep-dive the source after-all, turned out to be a simple LUKSv2 instead of LUKSv1 confused poor GRUB :)
[14:07] <sladen> xnox: gah.  Forgot the actual reason for LZMA.  It was CD-ROM booting
[14:08] <sladen> xnox: it was deployed for the Live-CD were CD-ROM I/O to boot was the overriding bottleneck
[14:08] <xnox> sladen:  also size, we had to fit on 700MB and lzma gave us half the size than gzip
[15:32] <Laney> xnox: can you recommend a python binding to systemd that's in the archive and lets me list / enable / disable / start / stop units?
[15:32] <Laney> python3-systemd looks quite limited
[15:32] <Laney> or should I talk dbus?
[15:36] <xnox> Laney:  and you want it for the user or system units?
[15:36] <gamester> Is ubuntu dev not receiving regular gnome updates? Is it just sitting on gnome 3.32?
[15:37] <Laney> xnox: system
[15:37] <Laney> gamester: it will do, we usually pick it up a bit later on
[15:37] <xnox> Laney:  so list / start / stop / restart is doable over dbus.
[15:37] <Laney> xnox: yeah I know, just wondering if there are some handy bindings
[15:39] <Laney> I found 'psystemd' which looks nice but doesn't seem to be packaged
[15:39] <xnox> Laney:  oh, and on the manager there is now EnableUnitFiles DisableUnitFiles MaskUnitFiles UnmaskUnitFiles nice. it wasn't used to be there.
[15:39] <xnox> Laney:  maybe check what snapd uses...
[15:40] <ogra> dh_systemd ?
[15:40] <xnox> Laney:  but also curious what you doing .
[15:40] <Laney> xnox: autopkgtest-cloud charm in python
[15:40]  * Laney eyes ogra with suspicion
[15:40]  * ogra grins
[15:40]  * xnox will start using snapd out of context, to get out of context responses from ogra from now
[15:40] <xnox> on
[15:40] <xnox> =))))))
[15:40] <Laney> xnox: need to enable the right number of template instances per the config
[15:40] <ogra> \o/
[15:40] <xnox> Laney:  arghuhghh
[15:41] <Laney> I'm trying to move all of the things that admins do by SSHing into the machine out into the charm
[15:43] <Laney> probably will end up at 'most' rather than 'all' though
[16:36] <Laney> https://paste.ubuntu.com/p/6RWj9j8wdT/
[16:36] <Laney> not too hard
[17:09] <ahasenack> question, when I override dh_gencontrol, for the purpose of using a substvars file, when I call dh_gencontrol at the end, do I need to pass $@ or something like to it, preserving whatever command line arguments debhelper was going to give it?
[17:10] <ahasenack> ilike https://pastebin.ubuntu.com/p/TKC5t9CnRh/
[17:10] <ahasenack> or just dh_gencontrol?
[17:50] <vorlon> ahasenack: just dh_gencontrol is sufficient, dh puts all the relevant information in environment vars so you don't have to repeat
[17:50] <ahasenack> vorlon: thanks
[17:53] <infinity> ahasenack: Also, $@ probably isn't what you think it is.  It would call "dh_gencontrol override_dh_gencontrol".
[17:53] <ahasenack> heh, quite the loop
[17:53] <ahasenack> but somehow it avoided it, when I tested
[17:54] <infinity> Not a loop.  Just a nonsensical argument to dh_gencontrol
[17:54] <infinity> $@ being a variable that substitutes in the current target.
[17:55] <ahasenack> I see
[18:00] <ahasenack> snapd's d/rules is sourcing /etc/os-release to check the ubuntu release the package is being build on, is that ok/stable?
[18:00] <ahasenack> specifically
[18:01] <ahasenack> "include /etc/os-release"
[18:01] <ahasenack> and then it decides on VERSION_ID
[18:01] <ahasenack> which seems to not change with point releases, i.e., trusty is 14.04.6, and VERSION_ID is 14.04 still
[18:01] <infinity> It's no worse than people build-depending on lsb-release and calling that, which is pretty common.
[18:01] <infinity> It's not meant to change with point release.
[18:02] <ahasenack> yeah, that is what I was reviewing, and I recently saw a debian package changing to os-release to avoid the build-dep on lsb-release
[18:02] <infinity> And why would knowing which point release you're building on be useful?
[18:02] <ahasenack> we need a certain libapt-pkg<abi> minimum version, and the automatic dependency via shlibs doesn't catch the specific version that has a bugfix we need
[18:02] <infinity> Point releases aren't a real thing anyway.  It's just a snapshot in time of the parent release.
[18:02] <infinity> Uhh, wat?
[18:03] <infinity> If you need a minimum version of a build-dep, you have a versioned build-dep.
[18:03] <infinity> Not a hack in rules.
[18:03] <ahasenack> I'm using substvars in rules to construct the depends (not build-dep)
[18:04] <ahasenack> https://github.com/CanonicalLtd/ubuntu-advantage-client/issues/520#issuecomment-498417459
[18:05] <infinity> Okay.  Still not following how you'd need to care about the point release version.
[18:05] <ahasenack> I don't, I wanted to be sure VERSION_ID wouldn't incorporate the point release number, and break my series if ifeq
[18:05] <ahasenack> of* ifeq
[18:05] <infinity> Versioned build-dep on the version you want, versioned dep on the version you want.  Don't really even need substvars there, unless you're trying really hard to build the same source on all releases.
[18:05] <ahasenack> I would check for 14.04, for example, not 14.04.N
[18:06] <ahasenack> the latter
[18:06] <ahasenack> same source on all releases
[18:06] <infinity> A fun goal, but don't be married to it either.  Things get messy in a hurry sometimes. :)
[18:06] <ahasenack> and this is the first time we have such a variable dependency
[18:06]  * infinity glances at all the m4 in gcc's rules.
[18:06] <ahasenack> yeah, keeping an eye on it, very carefully
[18:06] <ahasenack> python differences are annoying enough already between trusty and something more modern
[18:07] <infinity> And okay, if you wanted to make sure it WON'T incorporate the point release, as the man who updates that, I can assure you that it won't. ;)
[18:07] <infinity> It did once when someone else did it for me, and I fixed it in a hurry. :P
[18:09] <ahasenack> heh
[18:10] <ahasenack> infinity: and is /etc/os-release ok to source, or does it have to be parsed like /etc/lsb-release?
[18:10] <ahasenack> specifically, use "include /etc/os-release" in d/rules, like I've seen snapd do
[18:10] <infinity> https://www.freedesktop.org/software/systemd/man/os-release.html
[18:10] <ahasenack> aha, even better
[18:10] <infinity> ahasenack: The "spec" claims it should be okay to source.
[18:11] <infinity> ahasenack: And since I don't see any reason why we'd deviate from said spec, I think you're good to go.
[18:11] <ahasenack> thx
[18:12] <infinity> Hrm.
[18:13]  * infinity notes the addition of VARIANT and VARIANT_ID to the spec.
[18:13] <infinity> Which are completely useless without a .d mechanism.
[18:13] <infinity> Cause I'm not letting every flavour overwrite os-release.
[18:13] <infinity> Oh well.
[18:13] <infinity> It was almost useful.  Well job, systemd people.


[00:00] <KGB-0> gnome-control-center ubuntu/fprintd-async 039362a Marco Trevisan * pushed 1123 commits (first 5 follow) * https://deb.li/8BFe
[00:00] <KGB-0> gnome-control-center ubuntu/fprintd-async 6e16cd8 Robert Ancell debian/ (25 files in 2 dirs) * https://deb.li/3NON0
[00:00] <KGB-0> * debian/patches/0003-info-overview-Use-the-Ubuntu-logo-prominently.patch:
[00:00] <KGB-0>   - Fix Ubuntu logo not showing in about panel (LP: #1864577)
[00:01] <KGB-0> gnome-control-center ubuntu/fprintd-async 34443ac Sebastien Bacher (31 files in 10 dirs) * https://deb.li/R27z
[00:01] <KGB-0> Merge branch 'upstream/latest' of salsa.debian.org:gnome-team/gnome-control-center into upstream/latest
[00:01] <KGB-0> gnome-control-center ubuntu/fprintd-async 7eb491e Sebastien Bacher (40 files in 12 dirs) * Merge remote-tracking branch 'salsa/debian/master' into ubuntu/master * https://deb.li/3zcVs
[00:01] <KGB-0> gnome-control-center ubuntu/fprintd-async aadd4c4 Sebastien Bacher debian/changelog * upload to focal * https://deb.li/33Fdv
[00:01] <KGB-0> gnome-control-center ubuntu/fprintd-async 0182db4 Robert Ancell (19 files in 2 dirs) * New upstream version 3.36.0 * https://deb.li/iOBgn
[00:02] <KGB-0> gnome-control-center ubuntu/fprintd-async 039362a Marco Trevisan . * branch deleted
[00:04] <KGB-0> gnome-control-center ubuntu/master Marco Trevisan * [open] merge request !15: debian/patches: user-panel: Don't wait for fprintd on initialization and don't limit enroll stages * https://deb.li/U2Dg
[00:31] <sa-ghosts> Wimpress, can we get an easy way to switch between 24h time and 12 am/pm time in ubuntu-mate?
[00:31] <sa-ghosts> for 20.10 ofc
[00:31] <sa-ghosts> or even 21.04
[00:43] <sa-ghosts> sorry, I didn't know about the #ubuntu-mate channel
[01:06] <KGB-2> gnome-shell signed tags 28584b3 Marco Trevisan ubuntu/3.36.1-5ubuntu1 * gnome-shell Debian release 3.36.1-5ubuntu1 * https://deb.li/3eXJF
[01:06] <KGB-2> gnome-shell ubuntu/master a0d1ea0 Marco Trevisan * pushed 46 commits (first 5 follow) * https://deb.li/3kBK7
[01:06] <KGB-2> gnome-shell ubuntu/master ec852ab Dušan Kazik po/sk.po * Update Slovak translation * https://deb.li/rKI4
[01:06] <KGB-2> gnome-shell ubuntu/master f21a0ff Florian Müllner NEWS meson.build * Bump version to 3.34.4 * https://deb.li/3fGiD
[01:06] <KGB-2> gnome-shell ubuntu/master 6b784e0 Simon McVittie (465 files in 41 dirs) * Merge tag 'debian/3.34.3-1' into debian/unstable * https://deb.li/i7Oad
[01:07] <KGB-2> gnome-shell ubuntu/master 1cdc9cb Simon McVittie debian/ changelog gbp.conf * d/gbp.conf: Switch to debian/unstable branch * https://deb.li/pXuV
[01:07] <KGB-2> gnome-shell ubuntu/master 8d74b71 Simon McVittie (5 files in 3 dirs) * New upstream version 3.34.4 * https://deb.li/MLAj
[05:23] <jibel> morning all
[05:25] <duflu> Hi jibel
[05:28] <jibel> hi duflu
[06:18] <seb128> goood morning desktopers
[06:20] <jibel> salut seb128
[06:22] <seb128> lut jibel, comment ça va aujourd'hui ?
[06:23] <jibel> seb128, ça va bien et toi? beau temps pour aller à la plage :)
[06:24] <seb128> ça va, le manque d'exercice commence à devenir un peu pénible
[06:24] <didrocks> good morning
[06:24] <seb128> lut didrocks, comment ça va chez toi ? ;-)
[06:25] <didrocks> seb128: ça va ? Et toi ?
[06:25] <seb128> ça va, juste un peu en manque de mouvement !
[06:26] <jibel> c'est vrai qu'on commence à faire un peu de gras
[06:26] <jibel> salut didrocks
[06:27] <oSoMoN> good morning desktoppers
[06:28] <oSoMoN> salut jibel, didrocks
[06:29] <jibel> bonjour oSoMoN
[06:29] <didrocks> hello jibel, oSoMoN
[06:34] <jibel> didrocks, I verified that snapshots are taken only once per u-u run and the check on the pid works fine. I don't know why you had 2 at the same time.
[06:34] <didrocks> this is annoying, maybe uu crashed and relaunched? weird
[06:36] <jibel> didrocks, you'd see that in unattended-upgrades-dpkg.log
[06:39] <didrocks> ah, interesting, boot the vm
[06:40] <didrocks> I don’t have those logs
[06:41] <didrocks> just /var/log/unattended-upgrades/unattended-upgrades-shutdown.log which is empty
[06:41] <seb128> lut oSoMoN, en forme aujourd'hui ?
[06:42] <seb128> didrocks, jibel, I think u-u does split the upgrade in smaller sets instead of applying the stack of updates in one go, but I don't know if it does exit and start again when doing that
[06:43] <didrocks> seb128: it doesn’t from what we were told, and there is no hook. This is why we had the 20 minutes grace period that we narrowed down to checking the pid file, still taking into account if u-u doesn’t remove it, to check if it still exists
[06:44] <jibel> seb128, right, and we want to avoid taking a snapshot for each slice of updates. The process is the same apparently but didrocks had a case where he had 2 snapshots at the same time
[06:44] <seb128> k
[06:44] <didrocks> (spoiler alert: u-u doesn’t remove all temporary files and when asking the answer was "you are not supposed to look at them"
[06:44] <didrocks> when I got 2 snapshots at the same second, there was only one transaction (from dpkg log)
[06:44] <didrocks> this is why this is puzzling
[06:45] <didrocks> I think let’s keep a look
[06:48] <jibel> didrocks, https://paste.ubuntu.com/p/fCmj3hn63S/ is the log for this morning. There are many updates but only 1 snapshot
[06:48] <duflu> Morning seb128, didrocks, oSoMoN
[06:48] <seb128> duflu, hey, how are you today?
[06:48] <jibel> this morning and previous days
[06:48] <didrocks> hey duflu
[06:49] <duflu> seb128, busy but feeling good. I just separated that Xorg crash into a new bug for focal. And populated Trello with everything on the horizon (now more stressed)
[06:49] <didrocks> jibel: ack, so worked as expected
[06:49] <duflu> How are you seb128 ?
[06:49] <jibel> yup
[06:49] <seb128> duflu, I'm good thanks, I will have a look to trello in a bit, we didn't keep up with updating it as much as we should have recently
[06:50] <duflu> Yeah I noticed that when I was the only person touching cards some days
[06:50] <duflu> And other days I was one of the people not updating cards
[06:50] <seb128> duflu, I assigned some of the gnome-shell issues previous week and this week while we were reviewing the rls-ff-incoming bugs, Marco took his share but he needs some help ... do assignement on launchpad reach you correctly or do you prefer also cards to be created for those?
[06:50] <duflu> seb128, I put those in Trello today :)
[06:50] <duflu> Yes I do get the Launchpad emails too
[06:51] <seb128> k
[06:52] <seb128> duflu, bug #1869571 might be a good one to start with
[06:52] <seb128> it got oem tagged now
[06:52] <duflu> seb128, yes but I will avoid putting it in progress till more cards already started are off the list
[06:55] <seb128> duflu, I would say this one is more important than plymouth not showing on nvidia (which is only cosmetics for some seconds at boot) if you could trade those (unless you started enough work on the plymouth/nvidia one that you prefer to finish rather go back to it later)
[06:55] <duflu> Yeah they are started
[06:55] <duflu> I would waste time if I stopped and had to relearn where I was
[06:55] <seb128> k, fair enough, I let you work in order then :)
[07:14] <oSoMoN> salut seb128, la forme, et toi?
[07:14] <oSoMoN> hey duflu
[07:15] <marcustomlinson> morning desktoppers
[07:23] <didrocks999> hey marcustomlinson
[07:23] <oSoMoN> good morning marcustomlinson
[07:24] <marcustomlinson> hey didrocks999 .999999999999 and oSoMoN
[07:25] <didrocks999> :p
[07:27] <seb128> oSoMoN, ça va, j'ai bien dormi, par contre je manque d'exercice et j'aime pas ça :-/
[07:27] <seb128> hey marcustomlinson
[07:36] <duflu> Hi marcustomlinson
[07:44] <marcustomlinson> hi seb128 and duflu
[08:01] <Laney> morning
[08:02] <didrocks> hey Laney
[08:03] <Laney> moin didrocks
[08:03] <Laney> you good?
[08:04] <Laney> immediate agenda: look at xnox's stuff, figure out the BREAK_ARCHES thing in proposed-migration to unblock various things, do queue reviews
[08:04] <didrocks> I’m good, thanks! you?
[08:04] <marcustomlinson> hey Laney
[08:05] <seb128> hey Laney, how are you today?
[08:05] <Laney> hey marcustomlinson seb128
[08:05] <Laney> yeah good, back in shorts today!
[08:05] <Laney> I think I'll be happier at work once this release is done
[08:05] <Laney> might need another 4 day weekend after that, that was good
[08:06] <Laney> how's it going there?
[08:06] <seb128> bah, one day I will unmap ctrl-R for reconnecting to the server
[08:07] <Laney> didn't see anything, quits/joins are off :p
[08:07] <Laney> that sounds like a weird thing to have on an easy shortcut
[08:17] <Laney> seb128: Wimpress: whoever else cares: btw I got vorlon to make a 20.04.1 milestone
[08:17] <Laney> might want to go through the rls bugs at some point and target those
[08:18] <seb128> Laney, ah, nice one
[08:18] <seb128> yes
[10:58] <jibel> Laney, thanks for noticing the s, fixed
[10:59] <Laney> jibel: was hoping it wasn't a typo in code somewhere :O
[11:01] <jibel> it was unfortunately
[11:02] <Laney> suspected it might have been, as that stuff was c+ped
[11:02] <Laney> oh well, bug found bug squashed
[11:10] <didrocks> fortunately, people who have installed it beforehand and who won’t switch to a server-style type won’t notice, but meh :p
[11:10] <didrocks> thanks Laney
[11:18] <marcustomlinson> Laney: hey man, sorry to bug you with this again. the fun hasn't ended: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1872958
[11:18] <marcustomlinson> Could you have a look at the MPs for u-m and u-r-u when you have a chance? It's relatively straightforward
[11:44] <Laney> marcustomlinson: hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
[11:46] <Laney> I feel like we could be more general here
[11:47] <marcustomlinson> ok
[11:49] <Laney> let me think
[11:49]  * Laney swooshes wise beard
[11:55] <Laney> marcustomlinson: something like https://gist.github.com/iainlane/10465ca8f5ddb1c90950ed836f9cf778 - would that work or am I missing something? (quite possible)
[11:56] <marcustomlinson> Laney: ah
[11:56] <marcustomlinson> though art smart
[11:57] <marcustomlinson> let me try that
[11:57]  * marcustomlinson can't spell thou
[11:59] <Laney> yeah I sort of feel like we'll end up chasing down a rabbit hole if we start trying to list relationships that already exist in the archive and we should be able to use apt to figure it out
[11:59] <Laney> hopefully that's right
[12:40] <marcustomlinson> Laney: yeah your code looks good. just wanted to make absolutely sure. manual testing and autopkgtests are good. pushed
[12:41]  * marcustomlinson is still amazed at how fast Laney wrote that code...
[13:39] <seb128> kenvandine, hey, any idea why I can't push to https://code.launchpad.net/snap-store ?
[13:40] <seb128> the project maintainer is ~ubuntu-desktop
[13:40] <seb128> so anyone from the team should be able to push no?
[13:40] <seb128> shrug
[13:40] <kenvandine> seb128: code isn't hosted on LP
[13:40] <seb128> I forgot again that it's maintain in gitlab
[13:40] <seb128> maintained
[13:40] <kenvandine> i thought i added a link to that
[13:40] <seb128> I just read the note I made you add last time :p
[13:40] <seb128> yeah, I just read it :p
[13:40] <seb128> ignore me
[13:40] <kenvandine> lol
[13:41] <kenvandine> there is a mirror on LP
[13:41] <kenvandine> for builds
[13:41] <seb128> kenvandine, is it fine it I commit a translation template in po/?
[13:41] <kenvandine> yes!
[13:41] <seb128> thx
[13:52] <Laney> marcustomlinson: 10x engineer innit
[13:53] <marcustomlinson> Software Engineer X
[13:53] <Laney> might ask Brian to review this branch now though
[13:54] <Laney> "why yes, that code I wrote looks great, ship it"
[14:21] <seb128> kenvandine, do you know how often it usually takes for the git mirror on launchpad to catch up new commits?
[14:39] <kenvandine> seb128: i think 5 hours
[14:40] <seb128> kenvandine, bah, patience! thanks
[14:40] <kenvandine> i can trigger it manually :)
[14:40] <seb128> please
[14:40] <seb128> how do you do that? maybe I can do myself?
[14:40] <didrocks> yeah, it’s between 5 to 6 hours
[14:41] <kenvandine> https://code.launchpad.net/~ubuntu-desktop/snap-store/+git/snap-store
[14:41] <kenvandine> i clicked it
[14:41] <kenvandine> but it was actually going to run in 12 minutes :)
[14:51] <seb128> thx
[14:59] <seb128> didrocks, Wimpress, what was the plan for the pop-icon/gtk-theme packages, should we regularly update with what is in their ppa?
[14:59] <seb128> like now before focal release?
[15:13] <oSoMoN> chrisccoulson, ricotz: FYI https://bazaar.launchpad.net/~mozillateam/firefox/firefox.focal/revision/1373
[15:14] <oSoMoN> I'll apply this change to the thunderbird packaging branches, too
[15:30] <Laney> Wimpress: Confirm that having "Ubuntu" booting to maybe-ubiquity and not "Try" / "Install" on grub (EFI) boot is the desired behaviour of the ISO please
[15:30] <Laney> xnox has a MP doing that and I'm ready to merge it
[15:30] <Laney> maybe confirm by voting approve on https://code.launchpad.net/~xnox/debian-cd/no-try-only-do-in-grub/+merge/381967
[15:47] <kenvandine> seb128: bug 1870777
[15:47] <kenvandine> seb128: that made me realize we have strings provided by snapd-glib
[15:47] <kenvandine> so we need the same sort of translation export for snapd-glib
[15:48] <kenvandine> seb128: but maybe that's what you were working on?
[15:48] <seb128> kenvandine, I'm working on fixing the snap-store translations state
[15:48] <seb128> the template on https://translations.launchpad.net/snap-store was outdated
[15:49] <seb128> snapd-glib you build from source?
[15:49] <kenvandine> yes
[15:49] <seb128> I need to check the status of the upstream project translations
[15:49] <kenvandine> but we should be able to do the same sort of thing for those translations
[15:49] <seb128> well, no need
[15:50] <seb128> if upstream has the translations they should be installed by the part build?
[15:50] <kenvandine> oh
[15:50] <kenvandine> true
[15:50] <seb128> I will check that though
[15:50] <kenvandine> maybe they aren't translated yet
[15:50] <kenvandine> thanks!
[15:50] <seb128> speaking of
[15:50] <seb128> did you talk to Robert about fixing the build?
[15:50] <seb128> armhf build
[15:50] <kenvandine> ugh, sorry i forgot
[15:51] <kenvandine> i got distracted with the appstream issue :)
[15:51] <seb128> we really need that build to be fixed
[15:51] <kenvandine> which had me super stressed and up half the night :)
[15:51] <kenvandine> ok
[15:51] <kenvandine> i'll will email him now :)
[15:51] <seb128> it's annoying that he didn't track that by himself :/
[15:51] <seb128> thx
[15:52] <kenvandine> i've been pushing him really hard on snap-store related stuff
[15:52] <kenvandine> but yeah
[15:53] <seb128> also do you know if he's likely to have slots for the g-c-c bugs assigned to him tomorrow? freeze is coming
[15:55] <kenvandine> i'll talk to him about that too
[15:55] <seb128> thx, can you drop me an email or ask him to drop me one
[15:55] <kenvandine> so looking at update_excuses, snapd-glib seems to be only missing riscv64
[15:55] <seb128> I will try to pick the g-c-c changes tomorrow if he doesn't
[15:56] <seb128> oh, armhf built
[15:56] <seb128> I guess something else got fixed
[15:56] <seb128> https://launchpad.net/ubuntu/+source/snapd-glib/1.57-0ubuntu1/+build/19128842
[15:56] <seb128> it built on the 10th
[15:56] <seb128> when other archs built on the 6th
[16:48] <Wimpress> Laney: Yes, EFI booting should always boot to maybe-ubquity.
[16:48] <Wimpress> Agreed with design and foundations last week.
[16:49] <Wimpress> Laney, I've added to the merge-proposal.
[16:49] <Laney> ta
[19:54] <diddledan> kenvandine, any chance we can get gtk2-common-themes snap released into i386?
[20:58] <robert_ancell> kenvandine, is https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-software/commit/?id=925d7d794e4d4ada393d070c5fa4560cd22d62a9 what you mean regarding the ubuntu-software package?
[20:58] <robert_ancell> i.e. that binary package is dead, and should now be empty?
[21:15] <kenvandine> robert_ancell: oh great
[21:16] <kenvandine> diddledan: not super excited about that.  As Ubuntu isn't supporting i386 anymore
[21:16] <kenvandine> diddledan: if we did, what happens when we really can't support it anymore?
[21:16] <kenvandine> i'd rather never turn it on than take it away from someone in 6 months or a year
[21:17] <kenvandine> robert_ancell: btw... the missing icons thing i think might be caused by Yaru app icons aren't in gtk-common-themes
[21:17] <kenvandine> robert_ancell: it's possible it isn't as bad as it looks... just need a rebuild of gtk-common-themes
[21:18] <kenvandine> which i'm doing now
[21:19] <robert_ancell> kenvandine, oh great = that is what we should do? I noticed that the snap-store deb only has the new branding on the beta channel. So I wasn't seeing the double icons here until I switched to that.
[21:20] <diddledan> well 18.04 supports i386 and we've got at least another 3 years of that release being active. then there's other distributions than ubuntu to consider
[21:20] <kenvandine> true
[21:21] <robert_ancell> seb128, do you know about the riscv64 build-failure for snapd-glib. Is that a required architecture?
[21:21] <diddledan> .. wait, riscv, robert_ancell?! :-o
[21:21] <diddledan> that's .. omg.
[21:22] <seb128> robert_ancell, don't worry about it, it shouldn't be a blocker and ubuntu-release is working on fixing the migration tools
[21:22] <sarnold> robert_ancell: probably best to treat it as supported, xnox said the other day when I added it to the security team faq that it ought to be lisetd as fully supported
[21:22] <robert_ancell> seb128, ok, cool.
[21:22] <robert_ancell> sarnold, in this case it seems the tests are timing out after 30s, which is not long enough. Is there a way to increase that?
[21:23] <robert_ancell> hmm, or is this meson doing this?
[21:23] <robert_ancell> aha, it is meson.
[21:25] <kenvandine> diddledan: i'll think about it
[21:26] <ogra> hrm ... snap-store segfaults for me on 16.04 Unity when clicking the updates button (it shows three updates in the tab)
[21:26] <ogra> https://paste.ubuntu.com/p/BfP52NJ399/
[21:27] <ogra> (trying the new beta here)
[21:43] <seb128> robert_ancell, did you see my snapd-glib email? would have been nice to add the dh-translations/--with translations change to the upload you just did, otherwise the lib is basically untranslated
[21:44] <robert_ancell> seb128, yeah, I thought I'd add those to a second release. The first fix is a no-brainer.
[21:45] <seb128> robert_ancell, k, the translation one is probably trivial as well but another upload is cheap enough
[21:45] <seb128> on that note calling it a day!
[21:45] <robert_ancell> seb128, night!
[21:45] <seb128> thx :-)
[22:32] <kenvandine> robert_ancell: confirmed, my fix in gtk-common-themes fixes snap-store :)
[22:32] <robert_ancell> kenvandine, nice!
[22:32] <kenvandine> looks much better now
[22:33] <kenvandine> gtk-common-themes had been stripping out icons in the apps dir to save space
[22:33] <kenvandine> most apps don't need app icons within the snap... but snap-store does :)


[12:41] <kandarpk> dfarning: good morning
[12:49] <dfarning> kandarpk, good morning. how are you?
[12:49] <kandarpk> dfarning: I am doing good
[12:50] <kandarpk> dfarning: thanks
[12:50] <kandarpk> dfarning: how are you doing ?
[12:50] <dfarning> kandarpk, it looks like you guys are making good progress.
[12:50] <dfarning> i am doing well,  tired after meeting all of the new people....
[12:51] <kandarpk> dfarning: hmmm
[12:53] <kandarpk> dfarning: thats not good to know early morning.
[12:54] <kandarpk> dfarning: you want to take some rest or should I start firing my questions ?
[12:55] <dfarning> kandarpk, :) it is a good tired.... like after a hard run.
[12:55] <dfarning> go ahead.
[12:55] <kandarpk> dfarning: nice
[12:55] <kandarpk> dfarning: the jhbuild problem didn't get solved
[12:56] <dfarning> i'll try to help.  but you already know more technically about most systems than I do.
[12:57] <kandarpk> after running the sugar-jhbuild script, only a jhbuild folder got created
[12:58]  * dfarning looks
[12:59] <kandarpk> dfarning: shall I paste the contents of the script ?
[13:02] <dfarning> kandarpk, I am setting up sugar-jhbuild on my local computer to see what happens.
[13:02] <kandarpk> dfarning: Great.
[13:04] <dfarning> kandarpk, I am on a very slow internet connection.
[13:05] <dfarning> hmmm... I am on a low power netbook... that can't run jhbuild.
[13:06] <dfarning> kandarpk, what was the output from ./sugar-jhbuild build ?
[13:07] <kandarpk> dfarning: it downloaded some 2MB content and created a jhbuild folder
[13:09] <dfarning> kandarpk, hmm I thought 'build' created the source/ and install/ dirs.
[13:09] <dfarning> kandarpk, did depscheck run succefully?
[13:10] <kandarpk> dfarning: depscheck ?
[13:10] <kandarpk> dfarning: I used git clone only
[13:10] <dfarning> kandarpk, please see http://wiki.sugarlabs.org/go/Development_Team/Jhbuild#Build_sugar_base_system_and_its_dependencies
[13:12] <dfarning> kandarpk, sorry if the process seems clunky.... I wrote sugar-jhbuild a couple of years ago as a quick hack.... and no one ever rewrote it:(
[13:12] <kandarpk> dfarning: :)
[13:14] <kandarpk> dfarning: how much data will it download ?
[13:15] <dfarning> depscheck is verysmall.... it just makes sure that all of the necessary build dependancies are installed'
[13:16] <kandarpk> dfarning: update ?
[13:16] <dfarning> kandarpk, it then prompts you to install them if they are not available.
[13:19] <dfarning> kandarpk, update will grab many MB of source code:(
[13:19] <kandarpk> dfarning: so, I need to run that as well ?
[13:20] <dfarning> kandarpk, +1
[13:23] <kandarpk> dfarning: by the way, how is your work at PY progressing ?
[13:25] <dfarning> kandarpk, I think it is going well.... Creating a long term partnership with PY and UY so we have some sustainability.
[13:25] <kandarpk> dfarning: Nice.
[13:27] <kandarpk> dfarning: to run sugar via jhbuild, should I uninstall sugar first ?
[13:31] <dfarning> kandarpk, jhbuild can coexist with the installed packages.
[13:31] <kandarpk> dfarning: ok. switching to USR.
[13:38] <kandarpk> dfarning: Error during phase build of python-xklavier
[13:39] <dfarning> kandarpk, just hit continue.... or whatever the command is.... that will not affect the docstrings you are working with.
[13:40] <kandarpk> dfarning: why do I need to install ? the source should still be available
[13:42] <dfarning> sphynix grabs the docstrings from the install/ dir rather than the source/ it does this to insure that everything can find the other modules if they need to be 'imported'
[13:43] <kandarpk> dfarning: does that mean .py files inside install are created during build ?
[13:46] <dfarning> kandarpk, the .py files are also in the source code.....  ^^ just means that the directory structure is correct and every thing is in the correct place relatative to one another.
[13:46] <kandarpk> dfarning: ok
[13:55] <kandarpk> dfarning: will lfaraone be available today ?
[13:56] <dfarning> kandarpk, he is not scheudaled for today.... but he might be available anyway
[13:57] <kandarpk> dfarning: Ok.
[14:06]  * dipankar is away: Be Right Back
[14:06] <kandarpk> *I'll be back in an hour.
[14:41]  * dipankar is back (gone 00:32:14)
[14:41]  * dipankar is away: Be Right Back
[15:00] <ankur> kandarpk, around?
[15:00] <kandarpk> ankur: hi
[15:01] <ankur> hey , i completed my activities , can you see if there are any changes required in them ?
[15:01] <ankur> i will sending you mail
[15:01] <dfarning> ankur, +1
[15:02] <dfarning> ankur, what do you have planned next?
[15:02] <ankur> hi dfarning
[15:02] <dfarning> ankur, hello
[15:03] <ankur> dfarning, well i was just hoping that this time i send my activities for review , they wont require changes . Well , i haven't planned much as of now
[15:04] <ankur> will be gogin with the flow what is required :)
[15:04] <ankur> gogin/going
[15:05] <dfarning> ankur, good, have you read producing oss? watched ponious people?
[15:06] <ankur> well did not complete the book :(
[15:06] <ankur> but will do that tonight :)
[15:07] <dfarning> ankur, good there is a lot of good stuff in there that will help explain why people in opensource communities act like they do?
[15:08] <ankur> but it was quite depressing to know the amount of OSS projects do not meet their aim
[15:10] <dfarning> ankur, yes,  many companies also fail....
[15:10] <dfarning> ankur, we have to get a lot of things right, find good people to work with, and have some luck.
[15:11] <ankur> dfarning,  +1
[15:13] <dfarning> ankur, since you are caught up... do you want to hack or study today?
[15:14] <ankur> one min dfarning  , i was on phone
[15:20] <dfarning> ankur, np an interesting hacking project will be to try to run sugar in ubuntu 10.10 and see what bug we fixed in the ppa still exist.  Then we can go back and correctly apply the patches to the 10.10 branch.
[15:23] <ankur> dfarning, as far as i remember i uploaded most of the packages for maverick in ppa
[15:23] <ankur> :)
[15:23] <ankur> well it will be good to see if that worked or not
[15:24] <ankur> but one thing i remember was that uploading of two packages failed at that time , there build failed
[15:24] <ankur> we will have to work on that too
[15:25] <dfarning> ankur, _nope_:) no more ppa.... now you are ready to work directly in ubuntu universe the same way neeraj was doing last week.
[15:25] <dfarning> ankur, the ppa was just pratice:)
[15:25] <ankur> dfarning,  :)
[15:25] <ankur> also i wanted to ask , i was some what missing from action last week , i missed that if slider puzzle and jigsaw puzzle starting bugs were fixed or not
[15:26] <ankur> becasue when i saw bugs , they were dependecy related problem , AFAIR
[15:26] <dfarning> ankur, not sure... will have to ask lfaraone or kandarpk
[15:26] <ankur> python-abiword was not added
[15:30] <ankur> dfarning,  i am up for testing , but i wanted to test my packages once more and mark them up in wiki page.
[15:30] <ankur> once i do that , i will get back to you :)
[15:31] <dfarning> ankur, you understand the situation better than I do
[15:32] <kandarpk> dfarning: do you have anything for me ?
[15:33]  * dipankar is back (gone 00:51:46)
[15:34] <dfarning> kandarpk, hacking or learning today?
[15:34] <kandarpk> dfarning: do not have 10.10 installed
[15:37] <dfarning> kandarpk, installing and testing that would be usefull.
[15:37] <kandarpk> dfarning: Ok.
[15:41] <ankur> dfarning,  will luke be coming today ?
[15:42] <dfarning> kandarpk, I would suggest the same task as I suggested to ankur.  Think about how to scync the packages between debian and ubuntu while maintaining the patches in a sane manner.
[15:43] <kandarpk> dfarning: I worked on syncing connect and poll
[15:46] <dfarning> kandarpk, cool.
[15:46] <dfarning> I must runn
[17:02] <lfaraone> I'll not be here for more than a minute.
[17:03] <lfaraone> Just letting everyone know that the changes specified on http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2010-July/002708.html need to be made to all packages.
[17:03] <lfaraone> I've also marked it as such on the wiki page.
[17:04] <lfaraone> Please hilight or mail me and I'll get back to your questions when I have a chance. Today'll be a beach day :)
[19:08] <kandarpk> alsroot: Hi.
[19:08] <alsroot> kandarpk: hi
[19:08] <kandarpk> alsroot: I faced some problem in cloning speak activity
[19:09] <kandarpk> alsroot: upstream branch wasn't present in my local git repo on cloning
[19:09] <kandarpk> any idea ?
[19:09]  * alsroot tries clean clone
[19:11] <alsroot> kandarpk: I just did "git clone git://git.sugarlabs.org/speak/mainline.git" and it is ok for me, did git log errors?
[19:11] <kandarpk> alsroot: I used gbp-clone git+ssh://git.debian.org/git/collab-maint/sugar-speak-activity.git
[19:12] <kandarpk> alsroot: let me run the command again
[19:13] <alsroot> kandarpk: btw, better to use fully-bundled branch instead of master, toolkit dependency live there
[19:16] <kandarpk> alsroot: git clone git://git.sugarlabs.org/speak/mainline.git
[19:17] <kandarpk> is creating mainline folder, whch has only master branch
[19:17] <kandarpk> am I missing something ?
[19:17] <alsroot> kandarpk: thats right, only mast branch is created by default
[19:18] <kandarpk> alsroot: what about upstream branch ?
[19:18] <kandarpk> how do I get that ?
[19:18] <alsroot> kandarpk: but there is no "upstream" branches, http://git.sugarlabs.org/projects/speak/repos/mainline/logs/master
[19:19] <alsroot> btw, to get particular branch on clone, add "-b <branch>" to clone command
[19:20] <kandarpk> alsroot: ok. thanks.
[19:25] <kandarpk> *need to study a bit more...
[19:29] <alsroot> kandarpk: there are several external git tutorials on http://wiki.sugarlabs.org/go/Activity_Team/Git
[19:30] <kandarpk> alsroot: thanks :)
[19:34] <kandarpk> alsroot: one more thing, running 'DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean'
[19:34] <kandarpk> doesn't regenerate control from control.in
[19:34] <kandarpk> in speak activity
[19:35] <alsroot> kandarpk: sorry, I used deb packaging only in pretty simple cases, not sure what it could be
[19:35] <kandarpk> alsroot: np.


[01:31] <itsdavidagain> greetings! just learning irq, pastebin etc... found this channel, and badly need some help untangling a mess :D
[01:32] <itsdavidagain> think I forgot to say please :)


[19:31] <ibeardslee> morning
[19:42] <chilts> morning
[19:56] <ajmitch> morning
[20:01] <mwhudson> morning
[22:17] <kcj> Morning.
[23:40] <ojwb> morning