=== gQuigs is now known as bryanquigley
=== BenderRodriguez is now known as RobertMuellerIsG
=== RobertMuellerIsG is now known as RobertMuellerIII
=== RobertMuellerIII is now known as BenderRodriguez
[04:21] <JackFrost> doko: Hi!  FWIW, apt-offline seems to no longer be seeded, re: LP 1848755.  Looks like it got removed from Debian testing.
[04:21] <ubottu> Launchpad bug 1848755 in apt-offline (Debian) "xubuntu and ubuntustudio should not depend on apt-offline (or fix it)" [Unknown,Confirmed] https://launchpad.net/bugs/1848755
[05:04] <valorie> interesting
[05:04] <JackFrost> Hmm?
[05:06] <valorie> that it was removed, yet still is depended upon
[05:06] <JackFrost> As noted, Xubuntu and Ubuntu Studio removed it from their seeds a while ago.  In Debian it was dropped from testing due to it..not working at all! :P
[05:07] <JackFrost> Interestingly, a couple of the bugs are fixed in git.
[05:08] <valorie> I should have read the bug report before responding
[05:08] <Eickmeyer> valorie: bluesabre and I took care of it a couple months ago.
[05:08] <valorie> :-)
[08:52] <doko> systemd stopped building libudev-dev,however libpci-dev still depends on it. what is the replacement?
[08:52] <doko> xnox: ^^^
[08:56] <seb128> doko, do you know if that's something that needs fixing or to be badtested?
[08:56] <seb128> Depends: python3-all:i386 but it is not going to be installed
[08:56] <seb128> (http://autopkgtest.ubuntu.com/packages/b/brotli/focal/i386)
[08:56] <seb128> vorlon, ^
[08:59] <doko> I don't know, that's python3
[08:59] <doko> there are currently a lot of unistallable packages because python got dropped, but that's python2
[09:01] <doko> looks like systemd 244.1-0ubuntu1 was removed in proposed
[09:32] <cpaelzer> kanashiro: you merged smartmontools last and the only delta we had left was one to let the service run even on diskless systems
[09:32] <cpaelzer> kanashiro: this came up in Debian as well later in the form of bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862908
[09:32] <ubottu> Debian bug 862908 in smartmontools "smartd fails to start when no disks are present" [Normal,Fixed]
[09:33] <cpaelzer> Their solution is to change the default to an option of the daemon that won't quit without disks
[09:33] <cpaelzer> See https://salsa.debian.org/debian/smartmontools/blob/master/debian/patches/default_never-quit.patch
[09:33] <cpaelzer> that seems even better than the systemd change we carry
[09:33] <cpaelzer> kanashiro: I came to look at it for https://salsa.debian.org/debian/smartmontools/blob/master/debian/patches/default_never-quit.patch
[09:33] <cpaelzer> kanashiro: I'd ask you to check as well if you agree that this could be a sync
[09:33] <cpaelzer> kanashiro: if so let me know and state so on the bug
=== cking_ is now known as cking
[10:23] <santa_> ddstreet: hi, since some time ago I have been suffering a bug in network-manager and I have a patch for it, so I'm wondering if you would sponsor the upload (because you did the last n-m upload)
[10:24] <santa_> https://launchpad.net/~panfaust/+archive/ubuntu/vpn-pass/+packages
[10:25] <santa_> ↑ as you can see I have a modified package for focal, but I believe this bug also affects eoan (at least)
[10:26] <santa_> so maybe we could get the patch into focal ann then SRU it for affected stable versions? what do you think?
[10:26] <santa_> s/ann/and/
[10:50] <ddstreet> santa_ is there a lp bug for that?  if it needs to go into eoan too, it'll need a bug to track that
[11:15] <santa_> ddstreet: I haven't checked yet, if there isn't we can always open one, let me check...
[11:18] <santa_> ddstreet: yep: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1858092
[11:18] <ubottu> Launchpad bug 1858092 in network-manager (Ubuntu) "Network Manager not saving OpenVPN password" [Undecided,New]
[11:21] <doko> mitya57: please could you have a look at https://launchpad.net/ubuntu/+source/python-docutils/0.15.2+dfsg-1build1 ?
[11:24] <ddstreet> santa_ great!  can you attach your debdiff to that bug, i'll review/upload from that
[11:25] <santa_> ddstreet: ack, thank you for your time
[12:09] <xnox> doko:  que?! libudev-dev            | 244-3ubuntu1       | focal                                 | amd64, arm64, armhf, i386, ppc64el, s390x
[12:10] <xnox> doko:  and yes, 244.1 was removed due to bugs. You upgraded with proposed, and now must downgrade?
[12:11] <xnox> doko:  i wish my chroots would have -proposed enabled; but when i refresh the chroots they'd only use -release/-updates/-security to "dist-upgrade"
[12:20] <cpaelzer> doko: your fix to texlive-latex-extra worked for the package itself
[12:20] <cpaelzer> but it still depends on texlive-pictures
[12:21] <cpaelzer> which then has the python dependency
[12:21] <cpaelzer> so one down, one (many) more to go
[12:23] <cpaelzer> src:texlive-base that would be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938655 then I guess
[12:23] <ubottu> Debian bug 938655 in src:texlive-base "texlive-base: Python2 removal in sid/bullseye" [Normal,Open]
[12:23] <cpaelzer> on that one there was no reply
[12:23] <cpaelzer> And the old depends line is not py2/py3 as on the -extra package - it is "Depends: tex-common (>= 6), python, texlive-base (>= 2017.20170628), texlive-binaries (>= 2017.20170524.44437), texlive-latex-recommended (>= 2017.20170628)"
[12:23] <cpaelzer> ahasenack: ^^ FYI
[12:23] <cpaelzer> since you asked about texlive
[12:24] <kanashiro> cpaelzer, re smartmontools: I tried the Debian's patch here and it worked fine, agreed that we can sync it now on
[12:24] <cpaelzer> thank you kanashiro
[12:24] <cpaelzer> just say the same on the bug
[12:25] <cpaelzer> I'll do trigger the sync
[12:25] <cpaelzer> thanks for the second pair of eyes on this
[12:25] <kanashiro> cpaelzer, do you mean the Debian bug?
[12:25] <cpaelzer> kanashiro: no on https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1858121
[12:25] <ubottu> Launchpad bug 1858121 in smartmontools (Ubuntu) "Please re-add update-smart-drivedb" [Undecided,Confirmed]
[12:26] <kanashiro> ah ok :)
[12:26] <cpaelzer> sorry, I still need to fully surface from my big endian debugging - I might appear more confused than usual
[12:26] <cpaelzer> "even more" :-)
=== ricab is now known as ricab|lunch
[13:17] <gpiccoli> o/ xnox, sorry to annoy. Can you help getting a force-badtest merged , in order to get a pkg released?
[13:17] <gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu/+merge/377160
[13:17] <gpiccoli> lukasz helped me last time, but seems he's out. Or if you can point another person to help, also pretty useful. Tnx in advance!
[13:50] <kanashiro> cpaelzer, re nut: do you think we should try to forward this to Debian? https://git.launchpad.net/ubuntu/+source/nut/commit/?id=eae756c108e276023be2c714c630ea27854f51da
[13:51]  * cpaelzer reading
[13:55] <cpaelzer> kanashiro: Debian doesn't use -O3 so they won't need it
[13:55] <cpaelzer> kanashiro: this is one of the cases that can't hurt to forward, but not have too much expectations on
[13:55] <cpaelzer> as it depends lot on the mood of the receiving maintainer
[13:57] <kanashiro> cpaelzer, hum, good catch. Since this is just part of our delta I'll keep it as is for now
[13:58] <cpaelzer> kanashiro: if you think it was unclear up to now maybe modify the commit message to avoid the same thoughts next time?
[13:58] <cpaelzer> jamespage: thanks to doko dpdk 19.11 would now build fine in Focal (even with docs) - how is openvswitch doing?
[13:59] <cpaelzer> jamespage: have you decided if you want DPDK 19.11 in focal first - since you wanted it in the PPA first I'd assume so
[13:59] <jamespage> cpaelzer: getting there - just working on the new ovn package as the openvswitch update drops all of the ovn binaries
[13:59] <jamespage> cpaelzer: DPDK can go to focal first please
[13:59] <cpaelzer> ok, I'll have a call with Debian DPDK on Thu to check if we need anything else before - then I'll most likely upload to f-proposed
[14:00] <cpaelzer> jamespage: let me know if you need any other timing
[14:00] <kanashiro> cpaelzer, good idea, I'll just add this clarification regarding the build flag and Debian
[14:00] <seb128> doko, do you plan to forward those python diffs you are uploading to Debian?
[14:03] <doko> once the testing frameworks work again
[14:04] <seb128> testing frameworks? what is that?
[14:05] <doko> pytest & co
[14:06] <seb128> well, that's not in the path of sending those ' Depend on python2-dbg instead of python-dbg.' changes back, is it?
=== ricab|lunch is now known as ricab
[14:08] <doko> seb128: please could you stop harassing me? If I don't fix the testing frameworks, I get complaints from you about that instead. just stop.
[14:09] <seb128> doko, sorry you feel harassed, I was just asking a question but I will stop there
[14:09] <seb128> doko, those deltas you are adding have a maintainance cost and I'm trying to avoid that, which was why I asked the question
[14:10] <seb128> doko, who would you recommend I ask those questions to instead of you?
[14:11] <doko> seb128: I said I will forward them. why do you continue?
[14:11] <seb128> continue?
[14:11] <doko> <seb128> well, that's not in the path of sending those ' Depend on python2-dbg instead of python-dbg.' changes back, is it?
[14:12] <seb128> I failed to understand how pytest block the dbg depends forwarding
[14:12] <doko> it's on my list. you don't define the priority on that list. if you want, please escalate
[14:12] <doko> time, just time
[14:12] <seb128> but maybe I just overlook something
[14:12] <seb128> k, fair
[14:12] <seb128> thx
[14:47] <Laney> LocutusOfBorg: did you look into pcsc-lite stuck in proposed yet?
[14:57] <xnox> gpiccoli:  i'm not release-team / sru-team so cannot help you with merging hints. Sorry.
[14:57] <xnox> gpiccoli:  lukasz is still on holidays at the moment
[14:57] <gpiccoli> no problem xnox, thanks for the information! Anybody else that can help me besides Lukasz?
[15:00] <cpaelzer> james_page: my argus-eyes have spotted OVN building - hehe
[15:01] <cousin_luigi> Greetings.
[15:02] <cousin_luigi> What's the ubuntu equivalent of https://sources.debian.org ?
[15:11] <mitya57> doko: I will fix it.
[15:16] <rbasak> cousin_luigi: launchpad.net has the sources available. The ability to browse the source tree without downloading is limited to a subset of packages via code.launchpad.net. That's a work in progress.
[15:19] <cousin_luigi> rbasak: I see. Is this perchance a consequence of importing packages from debian?
[15:21] <rbasak> cousin_luigi: I'm not sure what you mean. Is what a consequence of importing packages from Debian?
[15:22] <cousin_luigi> rbasak: I understand that some (many?) packages come from debian. Are the two things related somehow?
[15:23] <cousin_luigi> But then, I'm no longer up to date with these matters.
[15:23] <rbasak> I still don't follow, sorry.
[15:23] <cousin_luigi> nm, it's not important.
[15:23] <cousin_luigi> Anyway I have my answer. Thanks & bbl.
[15:23] <rbasak> I mean Ubuntu being a derivative of Debian, almost everything in Ubuntu is related to Debian somehow :)
[15:24] <rbasak> sources.debian.net is a separate service that derives from the Debian source package publication machinery
[15:24] <rbasak> Ubuntu has its own machinery (Launchpad) so an equivalent of sources.debian.net would need to be separately implemented, and nobody has ever done this.
[15:42] <vorlon> seb128, doko: brotli's autopkgtest tests a python3 module, which means it won't be cross-installable or cross-testable; I'll add it to the permanent blacklist
[15:43] <seb128> vorlon, thx
[15:51] <LocutusOfBorg> Laney, fixing
[15:56] <Laney> ♥
[15:56] <seb128> vorlon, what do you do exactly to trigger those emails without content on focal-changes@lists? is that package copies to rescure i386 binaries in some way?
[16:02] <LocutusOfBorg> fixed btw
[16:09] <seb128> santa_, hey, I updated n-m to 2.20.8 in focal, I think that includes the fix you mentioned earlier, still could be good to SRU to 19.10 if someone is interested in that and want to do the SRU paperwork and prepare an upload
[16:12] <santa_> seb128: that's great, thanks! I think that should have the fix, I will re-test once the package reaches the mirrors. I could prepare a package for eoan SRU as soon as I have time
[16:12] <seb128> santa_, thx
[16:12] <vorlon> seb128: yes, when I do a copy with binaries to the same archive (to resuscitate i386 binaries where needed), that's how it shows on focal-changes
[16:16] <seb128> vorlon, ok, I guessed so but wanted to make sure, thanks :-)
[16:36] <Bluefoxicy> I see the Blueprints feature is no longer active on launchpad
[16:37] <Bluefoxicy> I had wanted to suggest an Ubuntu VDI blueprint, as mentioned in bug #1654864 concerning the Weston RDP compositor backend
[16:37] <ubottu> bug 1654864 in weston (Debian) "weston build with rdp backend" [Unknown,New] https://launchpad.net/bugs/1654864
[16:39] <Bluefoxicy> Current display managers will recognize a user logging in and switch to their session on the console
[16:40] <Bluefoxicy> as Weston can switch back-ends and keep the same session open (e.g. display -> compositor -> session -> client application), it's possible for a server on port 3339 to expose a display manager over RDP, which then when logged into switches the compositor to connect to the user's existing session
[16:41] <Bluefoxicy> thus remote access
[16:43] <Bluefoxicy> Likewise, rather than 250 desktops drawing 100 watts (65-200 watts when idle, 200W or more when in use), i.e. 25kW, a single 1,000 watt server can support 250 user sessions.
[16:44] <Bluefoxicy> That means cutting costs, but also the environmental footprint
[16:45] <Bluefoxicy> Thin clients are often built from Raspberry Pi boards, idling at under 5 watts, and reaching 15W in use.
[16:46] <Bluefoxicy> That does add 3.75kW, so this hypothetically converts 25kW to around 5kW, a 5:1 energy savings; and those small board thin-clients are less manufacturing, shipping, and eventual waste.
[17:01] <JanC> why not just use the RPi as desktops instead?  :P
[17:01] <JanC> (or similar)
[17:45] <ahasenack> rafaeldtinoco: testsuite-python passed on an unprivileged lxd
[17:45] <ahasenack> rafaeldtinoco: https://pastebin.ubuntu.com/p/tbsWWZdbMg/
[17:51]  * ahasenack comments on the mp
[18:02] <rafaeldtinoco> tks ahasenack
[18:02] <ahasenack> rafaeldtinoco: that being said, I had a few odd (random?) errors that I can't explain, like a missing dep when running the test once, which now resolved. Maybe related to the python churn going on
[18:04] <rafaeldtinoco> weird.. I had with the python tests
[18:04] <rafaeldtinoco> but not during build time
[18:08] <ahasenack> it was during the tests
[18:08] <ahasenack> I didn't rebuild it (I used autopkgtest with -B)
[18:32] <Bluefoxicy> @JanC:  Slower storage, less RAM, more management (a default, minimal installation image can be wiped at any time), lower access (you can access your VDI desktop from anywhere)
[18:32] <udevbot> Error: "JanC:" is not a valid command.
[18:35] <Bluefoxicy> JanC: I tried running an Ubuntu VM from LiveCD in 1GB RAM.  It kept giving me a black screen as the OOM kicked in. <_<
[18:35] <Bluefoxicy> New RPI is $40 1GB, $86 4GB.
[18:40] <JanC> Live-CD needs lots of RAM for decompressing the image
[18:40] <JanC> I'm running an older version of Ubuntu (still with Compiz/Unity) on an actual system with 1GiB RAM...
[18:40]  * ogra points to #ltsp .. 
[18:40] <JanC> and it could be some other hardware than RPi
[18:41] <ogra> https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi
[18:44] <JanC> LTSP & similar tin client solutions are sometimes useful for central management & such, but I really doubt you do 5:1 energy savings if you take all the hardware used into account
[18:56] <ogra> well, he was talking about thin clients aboe ... but yeah, i agree that you just move the power usage into the server room with it
[18:57] <ogra> (and into the various high speed switches that you need if having a bigger setup)
[19:01] <JanC> not to mention most systems used as thin clients could be used as a low-end desktop on their own
[19:01] <rafaeldtinoco> ahasenack: replied to your review with a comment, will act based on your reply (fyio)
[19:01] <JanC> so you actually increase the energy usage
[19:22] <mitya57> doko: https://tracker.debian.org/news/1092153/accepted-python-docutils-0152dfsg-2-source-into-unstable/
[19:48] <gpiccoli> vorlon, sorry to annoy, but given Lukasz is out, can you help getting a force-badtest merged? https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu/+merge/377160
[19:55] <vorlon> gpiccoli: looks like the mp has the wrong target
[19:55] <gpiccoli> vorlon, or I messed up...it shows a giant diff, but what we need is a single line, a force-badtest to makedumpfile
[19:56] <gpiccoli> basically this thing vorlon : https://bazaar.launchpad.net/~gpiccoli/britney/hints-ubuntu/revision/4319
[19:57] <vorlon> gpiccoli: merged (with adjustment - we shouldn't drop the hint for the version currently in the release pocket)
[19:58] <gpiccoli> oh, I wasn't aware of that, thanks a lot vorlon! I'll follow this procedure in the future
[19:58] <gpiccoli> now vorlon, abusing your kindness, what's the next step getting this released to -updates?
[19:58] <gpiccoli> *for getting
[19:59] <gpiccoli> we have another set of relevant fixes to makedumpfile, so I'd like to move this to submit another package version to -proposed the sooner I can
[20:54] <doko> mitya57: thanks, but the rules file still calls python, not python2
[20:56] <mitya57> doko: Oh. Can you fix this with Ubuntu delta for now?
[20:56] <doko> sure, merging
[20:56] <mitya57> I can't do another Debian upload right now but I will apply this in git for the next one.
[21:25] <doko> mitya57: https://launchpadlibrarian.net/459588980/buildlog_ubuntu-focal-amd64.python-docutils_0.15.2+dfsg-2ubuntu1_BUILDING.txt.gz
[21:26] <Bluefoxicy> ogra: a thousand watt server can handle around 250 moderate-use users at once. PCs idle at 65W-200W and generally consume 200W during use.
[21:28] <Bluefoxicy> JanC:  the savings is about 10kg/hr of CO2 if you assume the RPI is running at 15W consumption the whole way.
[21:29] <Bluefoxicy> ogra: as to high-speed switches, running fairly-intensive use over RDP at 32 bits is 120kbit/s peak, under 100kbit/s typical, 250 = 25 Mbit/s
[21:29] <Bluefoxicy> and modern, low-power switches with 10 microsecond switching can run on 48V PoE at a few dozen watts at most.
[21:30] <Bluefoxicy> Those switches can carry 10GbE
[21:32] <Bluefoxicy> JanC:  BTW I can put about 800MB into a tmpfs and the livecd can run just fine. With no tmpfs it still crashed.
[21:32] <JanC> Bluefoxicy: 250 RPis will always use less than 250 RPis + 1 (or more) servers
[21:33] <JanC> (or whatever else you use as a low-power desktop instead)
[21:33] <Bluefoxicy> JanC: that's true.  The problem is 250 desktops on 1 server will have more resources and burst processing power than 1 RPi
[21:34] <JanC> in reality, I've never seen a system like that being usable for anything but basic use
[21:35] <Bluefoxicy> At my job, I spend all day with powerpoint, word, chrome, Microsoft Teams, outlook, a file explorer, and ssh clients.
[21:35] <Bluefoxicy> Few office workers are actually compiling code and rendering 3D video all day.
[21:37] <JanC> sure, which is why they could just run a browser on any low-power machine
[21:38] <Bluefoxicy> JanC: you're basically discounting that burst resource usage is high (e.g. RPi can drag on for 30-40 seconds trying to open Chrome, then take a long time to render a Web page) while ongoing resource usage is low
[21:38] <Bluefoxicy> yet the hardware to handle high burst usage consumes 10-20 times as much power AT IDLE than a thin client
[21:38] <Odd_Bloke> Bluefoxicy: JanC: This could probably migrate to #ubuntu-offtopic at this point. :)
[21:47] <mitya57> doko: weird. I will look tomorrow.
[21:49] <doko> ta