[07:03] <satoris> Hi, how could I make sure this UIFe won't cause any problems for documentation screenshots (as described in the bug): https://bugs.launchpad.net/unity-lens-music/+bug/1049651
[07:03] <ubot2> Launchpad bug 1049651 in unity-lens-music "[UIFe] Do not list Internet radio stations in the dash" [Undecided,Incomplete]
[07:11] <mdke_> satoris: you'll need to subscribe ~ubuntu-core-doc to the bug and ask them. Or contact jbicha who has done all the work on the screenshots this cycle
[07:12] <mdke_> knome: sure. I am rarely on irc so email is probably the simplest way. I can be around on irc at about 9pm London time today though, in case that fits your time zone
[07:13] <mdke_> sladen: I'm very rarely on irc nowadays so the best way to deal with freeze exceptions is to subscribe the docteam to the bug report or send an email to the mailing list
[07:17] <mdke_> knome: I will take a look at the branch later on. My initial reaction just to the layout is to put all the xml in one directory under "desktop-guide/C/", it will be simpler to manage that way, as it is all one document
[07:18] <mdke_> knome: I'll be out for the day now but catch up with you later
[07:20] <satoris> mdke_: done, thanks.
[08:29] <sladen> mdke_: okaydokey.  ta.  jb replied
[09:01] <knome> mdke_, yeah, i'll make sure i'm around 9pm UTC.
[09:15] <xnox> isHello =)
[09:15] <xnox> phhhh... can't type =)
[09:16] <knome> ;)
[09:16] <xnox> Is this a place to check about User Interface Freeze Exception w.r.t. documentation screenshots?
[09:16] <xnox> in particular bug 1052040
[09:16] <ubot2> Launchpad bug 1052040 in ubiquity "[regression] ubiquity greeter does not have overlay scrollbars in quantal, but it did in precise" [Medium,Fix committed] https://launchpad.net/bugs/1052040
[09:16] <xnox> it has screenshots attached.
[09:16] <xnox> I was not sure who e.g. does http://www.ubuntu.com/download/help/install-ubuntu-desktop
[09:17] <xnox> and if there is other documentation with quantal screenshots already
[10:19] <popey> anyone around to review https://bugs.launchpad.net/unity-lens-music/+bug/1049651 ?
[10:19] <ubot2> Launchpad bug 1049651 in unity-lens-music "[UIFe] Do not list Internet radio stations in the dash" [Undecided,New]
[10:43] <eagles0513875> hey guys I have a question what is the difference between the server guide documentation and help.ubuntu.com documentation
[10:43] <eagles0513875> as I am noticing a big discrepancy on how to setup postfix and dovecot between the two documents
[10:48] <eagles0513875> anyone alive in here :(
[15:08] <cortman> Who is able to change community wiki page names?
[15:08] <cortman> Is this a Canonical-only ability?
[15:23] <popey> cortman, which page?
[15:24] <cortman> popey, https://help.ubuntu.com/community/GnomeClassicTweaks
[15:25] <popey> cortman, https://help.ubuntu.com/community/UserDocumentation?action=edit&editor=text
[15:25] <popey> cortman, does that work? (you need to login to edit)
[15:25] <popey> oh, hang on, wrong page
[15:25] <popey> duh
[15:26] <popey> https://help.ubuntu.com/community/GnomeClassicTweaks?action=edit&editor=text
[15:26] <cortman> No popey
[15:26] <cortman> I meant rename the page
[15:26] <cortman> sorry
[15:30] <popey> interesting, cortman the rename option is greyed out for me too
[15:30] <popey> i guess there's a team I am not in
[15:30] <cortman> Yeah- it'd be the administrators team I believe.
[17:36] <bkerensa> jbicha: reviewing a bug for desktop team to ensure it wont conflict with out screenshots
[17:46] <jbicha> bkerensa: thanks, removing features is easier for docs than adding them :)
[17:47] <bkerensa> jbicha: I also didn't see any screenshot including the internet radio in the branch
[17:47] <bkerensa> so it should be fine
[17:50] <jbicha> yes
[20:48] <knome> mdke_, i'm ready. :)
[20:56]  * pleia2 waves
[20:56] <knome> hallo pleia2
[20:56] <knome> i actually hope we aren't late...
[20:56] <pleia2> it's not 21 yet :)
[20:56] <knome> "9pm london time"
[20:57] <knome> that sounds like 1 hour ago
[20:57] <knome> (yeah, i just noticed)
[20:57] <knome> duh. i'll just handle it over email if he's not around :)
[20:57] <pleia2> doh
[20:57] <knome> hehe. that's life...
[21:15] <bkerensa> knome: what did you need?
[21:15] <bkerensa> jbicha: are we squared away mostly or do you have any work items we need finishing?
[21:15] <knome> bkerensa, looking at the xubuntu docs, i don't know what mdke had in mind
[21:15] <knome> bkerensa, i saw you looked at the docs - thanks - and i've now fixed the build errors
[21:15] <bkerensa> ok
[21:16] <bkerensa> which branch was this again? remind me?
[21:16] <bkerensa> so I can pull it and have a look
[21:16] <knome> let me check, rocket2dmn pushed it to a new location
[21:16] <knome> bkerensa, what's your email, i could fw you a mail
[21:17] <bkerensa><EMAIL_ADDRESS>[21:17] <knome> sent
[21:18] <knome> bkerensa, obviously trying to get this done and uploaded by thursday
[21:18] <bkerensa> oh
[21:18] <bkerensa> yeah before freeze
[21:18] <knome> yep
[21:19] <bkerensa> jbicha: can you create a new quantal branch for them?
[21:19] <bkerensa> So they dont hit the freeze wall
[21:20] <bkerensa> knome: What time was mdke supposed to meet with you guys on IRC?
[21:20] <jbicha> knome: hopefully rocket2dman will be able to review the new docs for you
[21:20] <knome> bkerensa, 9pm london time, so over hour ago
[21:20] <jbicha> if it becomes a blocker on Thursday, I might be able to push it for you but I don't have much experience with docbook
[21:21] <knome> jbicha, can you elaborate what you are referring to "reviewing" here? i'm totally new to docs stuff
[21:21] <knome> the docbook stuff should be ok, there's no errors etc.
[21:21] <knome> the only thing i don't know about is the translations and how the package creating magic happens
[21:21] <jbicha> knome: no one from xubuntu has commit access to those branches, right? someone from Docs needs to merge them? that's what I mean
[21:21] <knome> jbicha, i believe that's true
[21:22] <bkerensa> jbicha: at some point it might be helpful to  add me for reviews so I can merge stuff since we are understaffed
[21:22] <knome> jbicha, for R, i'm totally willing to take the workload for xubuntu if you wish
[21:23] <bkerensa> knome: we just review your MP's to ensure they are sane and if they are then they get merged and eventually you guys should have a commiter
[21:23] <knome> bkerensa, sounds fair
[21:24] <knome> this one is a complete rewrite, so i don't know how much it makes sense to look at diffs at least
[21:24] <jbicha> bkerensa: how much experience do you have with either docbook or Mallard?
[21:24] <knome> i truly believe i've well enough familiar with docbook, but the translations/building is hebrew for me
[21:25] <bkerensa> jbicha: I am familiar with docbook not so much with mallard
[21:27] <bkerensa> jbicha: I am looking over their MP right now
[21:27] <jbicha> bkerensa: so for commit access, we're looking for multiple, good merge patches or MPs from you to the Ubuntu documentation
[21:28] <jbicha> if you have that, you're welcome to apply for commit access on the mailing list
[21:28] <bkerensa> jbicha: are there even any candidates work items to submit patches for atm?
[21:28] <bkerensa> candidate* work items
[21:29] <jbicha> my list from precise is mostly still undone
[21:29] <jbicha> Unity documentation in general is very lacking in ubuntu-docs
[21:30] <jbicha> even proofreading the docs (whether for ubuntu, ubuntu server, kubuntu, etc) and submitting fixes to readability or updates to reflect current features are very welcome
[21:31] <knome> just a note that there's no sense to proofread xubuntu on precise... we will have to look for a possible update for a later point release
[21:33] <jbicha> precise in general is not a good candidate as documentation SRUs are rather painful
[21:33] <bkerensa> jbicha: can you remind me the precise list
[21:33] <jbicha> I need to update this, but this was my precise todo list: http://pad.ubuntu.com/ubuntu-docs-todo
[21:54]  * knome is drumming the table anxiously
[22:02] <bkerensa> knome: so basically jbicha will review if he has time before Thursday
[22:02] <knome> if not?
[22:03] <knome> is there anything i can make to speed up this process?
[22:04] <jbicha> if not, then we let the Release Team we're going to need a Documentation Freeze Exception
[22:05] <bkerensa> knome: likely not there is really only one or two people who review things and jbicha is one of them but they have a lot of other projects and have to complete ubuntu-doc itself
[22:05] <knome> ok. if mdke has time, can he do the review too?
[22:05] <bkerensa> jbicha: fyi I just submitted a MP for ubuntu-doc
[22:05] <bkerensa> ttyl
[22:05] <bkerensa> knome: ^ He could but the liklihood is slim
[22:05] <knome> bkerensa, i know, and i'm sorry we're this late, but we literally rewrote the whole docs from scratch this cycle
[22:06] <bkerensa> knome: no worries
[22:06] <knome> thanks
[22:06] <mdke_> knome: really sorry about earlier
[22:06] <knome> mdke_, oh, no problem.
[22:06] <knome> :)
[22:06] <mdke_> thanks to jbicha for emailing me
[22:07]  * mdke_ reading scrollback
[22:07] <jbicha> I figured you might not be on IRC at the moment but maybe you were still checking email :)
[22:07] <mdke_> email makes a noise on my phone yeah. Man I suck
[22:07] <knome> lol
[22:08] <knome> i'd never let that happen :)
[22:08] <mdke_> ok, so what's the issue
[22:08] <knome> well, you got the mail
[22:08] <knome> we want our docs reviewed and uploaded
[22:08] <knome> i have personally two main concerns:
[22:08] <knome> how are the translations going to work?
[22:08] <bkerensa> knome: there you go ^
[22:08] <bkerensa> see busy people :)
[22:08] <knome> and; how is the packaging going to work?
[22:09] <mdke_> ok
[22:09] <knome> bkerensa, heh, yeah, thanks ;)
[22:09] <knome> i think we're ok with docbook; it all validates now without errors
[22:09] <mdke_> knome: your first objective must be the packaging side, as that will allow the package to be uploaded in time for the freeze
[22:10] <mdke_> the translation will be pretty easy and I can take care of it
[22:10] <knome> ok, i have no idea about packaging in general, and i have no permissions to push anywhere.
[22:10] <mdke_> ubuntu-docs uses the gnome build system, but I would imagine that for xubuntu-docs that will not be appropriate to have gnome dependencies.
[22:11] <mdke_> so we should use the packaging system from the historical xubuntu-docs for simplicity
[22:11] <mdke_> have you figured out how users will view the documentation?
[22:11] <knome> yeah, that sounds good (we're also tight on space, so...)
[22:11] <knome> they'll view the docs in a browser, as html files
[22:12] <mdke_> ok, good
[22:12] <mdke_> I'll take a look at the packaging tomorrow and see what I can do
[22:12] <knome> thanks
[22:12] <knome> can i do something before that?
[22:12] <jbicha> knome: doesn't xubuntu also already have yelp installed?
[22:13] <knome> jbicha, probably, but this is actually all built to work with a browser
[22:13] <knome> s/probably/yes/
[22:13] <jbicha> oh ok, it's an option in the future then
[22:13] <mdke_> jbicha: if we try to use yelp there could be an issue about how to point it at the right document which could be complex I guess
[22:13] <knome> yeah, for Q i just want to get it in
[22:13] <jbicha> and if you're using yelp, you could even switch to Mallard
[22:13] <jbicha> I get a commission for every new Mallard user I sign up :)
[22:13] <knome> i've heard not all of our stuff even works in yelp
[22:14] <knome> (some inline icons missing)
[22:14] <knome> really don't want to hassle with that...
[22:14] <jbicha> yeah, too late to be fighting with new shiny
[22:14] <mdke_> I'm not sure there is anything that you can do in the meantime
[22:14] <knome> and honestly i don't know how much sense it would make to convert the docs AGAIN
[22:14] <knome> mdke_, ok, i'll just anxiously wait :)
[22:15] <mdke_> hopefully not too many changes will be required to the package system
[22:15] <knome> mdke_, do you have any idea what time would you get into it? i can try to be on irc at that time
[22:15] <mdke_> one thing I did notice was that you have a lot of files in different directories
[22:15] <mdke_> I think we should simplify that by putting them in one directory, as they are all part of one document
[22:15] <knome> yeah, that's what we had before, so i didn't mess up with that
[22:15] <mdke_> ah, I see
[22:15] <mdke_> perhaps leaving that will minimise the packaging changes required then, so I'll dig a little deeper
[22:16] <knome> mm-hmm
[22:16] <mdke_> I'll be working on it in the evening London time
[22:16] <mdke_> but this time I won't forget
[22:16] <knome> ok, we have a community meeting at 15UTC, and before or after that is great
[22:17] <knome> (during is ok too, but a bit distressing)
[22:17] <mdke_> if we need a little flexibility in relation to the freeze, I imagine that won't be too problematic, since it is important to get this in, and I don't believe that xubuntu-docs has had any translations in the last few releases, so anything we can do is basically an improvement
[22:18] <mdke_> knome: it will definitely be after your meeting
[22:18] <knome> hah, you say translations? it hasn't had much love after natty anyway
[22:18] <mdke_> in terms of getting it uploaded, I don't know if I have upload rights for that
[22:18] <knome> (mostly just updating the version numbers)
[22:18] <mdke_> right
[22:19] <mdke_> anyhow we will find someone to do the upload if needs be
[22:19] <knome> sounds good :)
[22:19] <mdke_> sorry again for the hassle this evening
[22:20] <knome> np really
[22:20] <knome> thanks for taking care of it
[22:20] <mdke_> that's ok, I haven't done anything this cycle so it may be a way to get me back into a little Ubuntu work
[22:20] <knome> heh, that's good too then
[22:21] <mdke_> ok, I'll see you tomorrow, thanks for all the huge work on xubuntu-docs
[22:21] <knome> np, see you :)
[22:21] <jbicha> knome: do you have upload rights for the xubuntu-docs package?
[22:21] <knome> jbicha, i'm most certain i don't
[22:21] <mdke_> I might, but can't remember
[22:21] <knome> jbicha, unless being on ~xubuntu-doc warrants that :P
[22:21] <jbicha> knome: I'm a MOTU so I could upload it if mdke can't
[22:21] <mdke_> oh awesome
[22:21] <knome> jbicha, <3
[22:22] <jbicha> mdke_: I'm going to poke you Thursday night or Friday for an ubuntu-docs upload since I don't have rights for that
[22:23] <mdke_> ok, I've found the email - i don't have xubuntu-docs upload rights. Only ubuntu-docs and gnome-user-docs
[22:23] <knome> mdke_, do you know who gives those permissions?
[22:23] <mdke_> jbicha: fine by me. Thanks also to you for working on everything single handedly
[22:23] <mdke_> knome: I'm a little out of date on procedures, in my day it was the TB. Now I suspect there is a different board that does it
[22:24] <mdke_> it's tough to keep up with all these boards
[22:24] <jbicha> knome: yeah, it's still the Tech Board
[22:24] <jbicha> oh, no wait, it's https://wiki.ubuntu.com/DeveloperMembershipBoard
[22:24] <knome> heh.
[22:24] <mdke_> hah!
[22:25] <mdke_> ok, I don't feel so bad now
[22:25] <mdke_> ok, night all
[22:25] <knome> night mdke_ and thanks!
[22:25] <jbicha> knome: you already have rights to upload xubuntu stuff?
[22:25] <knome> jbicha, i don't, i'm not a developer
[22:25] <knome> i mean, in the "traditional" meaning
[22:27] <jbicha> oh, well I guess you could apply either for xubuntu-dev or for PPU (per-package-uploader) for the stuff you do upload
[22:28] <knome> well, we seem to have people in the DMB and people who have upload rights to xubuntu-doc too :P
[22:38] <shaunm> jbicha: come on, work for that commission!
[22:41] <jbicha> shaunm: I actually did some local docs mentoring yesterday, maybe she'll be a future Docs Team member
[22:42] <jbicha> I've also tried teaching my wife but she runs away whenever she sees something that looks anything like code
[23:01] <shaunm> jbicha: then you want my visual mallard editor
[23:02] <jbicha> my wife was asking for that yesterday, I said it was mythical
[23:03] <jbicha> is it alpha yet?
[23:03] <shaunm> http://i.imgur.com/Xa30C.png
[23:03] <shaunm> you can't argue with screenshots. screenshots are *never* fake. ;-)
[23:04] <shaunm> no, it's in the crappy prototype stage. not even useful for a simple page
[23:04] <jbicha> it'll be a webapp?
[23:04] <shaunm> yes-ish
[23:06] <shaunm> the editor component ought to be sufficiently reusable that we could stick it in a webkit web view and wrap it up with some gtk widgets
[23:09] <jbicha> I guess my question was whether it would be exclusively web


[07:05] <darkxst> ricotz, have you looked at g-s-d update?
[07:06] <darkxst> particularly the OSD removal
[07:19] <ricotz> darkxst, hi, no, i haven't
[07:20] <darkxst> wondering should I just revert the patches, or make it fallback to g-s-d OSD's for the non shell case
[07:21] <darkxst> https://bugzilla.gnome.org/show_bug.cgi?id=695021
[07:21] <darkxst> another post-freeze annoyance
[07:25] <ricotz> darkxst, i see, give jbicha some time
[07:29] <ricotz> darkxst, btw, make sure you are sorting new entries in *.install files alphabetically or adapt to the current style instead just adding thing at the end
[07:35] <darkxst> ricotz, from what I can see they are usually just a mess
[07:35] <darkxst> hmm, no that is the control files I mean
[07:40] <darkxst> so finally spidermonkey release should happen tomorrow
[07:43] <darkxst> probably a bit too late for raring I guess
[08:15] <ricotz> might be still possible while it will be in universe without rdepends
[08:15] <ricotz> g2g
[13:45] <drehdz> anyone else having a problem with pidgin and empathy?


[13:08] <sudip> can anyone please mark LP: #1875642 as affecting Focal, Jammy, Lunar and Mantic
[13:08] -ubottu:#ubuntu-bugs- Launchpad bug 1875642 in fsvs (Ubuntu) "FSVS - not able to commit changes to remote HTTP SVN repo" [Undecided, Fix Committed] https://launchpad.net/bugs/1875642
[16:22] <sudip> thanks bdmurray
[16:26] <bdmurray> no problem


[01:31] <nathan__> hello?
[01:31] <nathan__> DBA around
[01:31] <nathan__> or DBO?
[03:11] <LjL> ubotwo part


[00:49] <Popo> Hi! Can someone give me a hand with a clean install?
[00:50] <Unit193> Don't know, what's the problem?
[00:51] <Popo> I'm seem stuck getting this message: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP
[00:52] <Popo> With gui install, it's been at "detecting file systems" for 15-ish minutes
[06:24] <xu-help49w> hi
[06:24] <xu-help49w> my password locks me out i dont nop it
[06:25] <xu-help49w> i dont no my password for softwere what do i do
[13:25] <hansh> did `apt update;apt full-upgrade; reboot;` today
[13:25] <hansh> in a VMWare VM
[13:25] <hansh> when it booted up again, the screen could no longer resize, and the mouse pointer from the host doesn't align with the mouse pointer in the VM
[13:26] <hansh> any idea how to fix it?
[13:26] <hansh> Xubuntu 18.04
[13:28] <hansh> well.. whatever the problem was, seems it just magically fixed itself on reboot #3 (after 2 reboots of it being borked)
[13:28] <hansh> (on last reboot i ran `sudo shutdown now` instead of telling it to shutdown via the xubuntu shutdown button, maybe that fixed something, idk)
[16:03] <xu-help19w> I have installed ubuntu 20.04 + xubuntu on raspberry pi4, but xwindows when inactive for a while stop responding any command, only wiht ctrl+alt+f2 I can get a terminal and restart lightdm.
[19:19] <xu-help59w> how do you find the release for a processor you dont know the specs?
[22:54] <Gunstick> Hi. Upgrading 18.04 to 19.10, got error in initramfs-tools "lz4: symbol lookup error: lz4: undefined symbol: LZ4F_createCDict"
[22:55] <Gunstick> "E: mkinitramfs failure cpio 141 lz4 -9 -l 127"
[22:57] <Gunstick> https://paste.ubuntu.com/p/ncj4W39yvC/
[23:07] <Gunstick> seems to be a new thing, one of the 3 google results, with no answer https://mlog.club/article/5168525
[23:10] <Unit193> 18.04 to 19.10?  That's...not really an upgrade path. :3
[23:10] <Gunstick> it got proposed by ubuntu update. so I took it. and I did the same on another xubuntu and that one worked without issues
[23:11] <Gunstick> but tha'ts not the question. question is how do I debug this. i.e. where is cpio used in update-initramfs so I can trace it and get why it's using lz4 instead of i.e. plain gzip
[23:13] <Unit193> Compression is configured in /etc/initramfs-tools/initramfs.conf
[23:14] <Gunstick> yeah. "COMPRESS=lz4", making that into a gzip
[23:15] <Gunstick> it works
[23:16] <Gunstick> question is where does this lz4 come from. Note: I do some AtariST retrocomputing on this machine, which uses a specific lz4. Maybe it was detected and the installer assumed that it's my preferred packer?
[23:16] <Gunstick> thanks for the help.
[23:17] <Gunstick> can I document this somewhere so in case others stumble on the issue?
[23:35] <Unit193> Not sure where one would be documenting it.


[14:49] <ahasenack> vorlon: hi, do you have a TL;DR for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221618 ? I just got this error in adsys' dep8 test with the new samba 4.16.1 from debian (which I'm merging): https://pastebin.ubuntu.com/p/xss2Tpd7q2/
[14:52] <ahasenack> adsys needs to set _FILE_OFFSET_BITS?
[14:58] <ahasenack> importantly, that only happened in a 32bit arch (armhf in this case)
[15:12] <ahasenack> hm, that patch was changed
[15:13] <ahasenack> now it's https://salsa.debian.org/samba-team/samba/-/blob/master/debian/patches/libsmbclient-ensure-lfs-221618.patch
[15:18] <ahasenack> when it changed: https://salsa.debian.org/samba-team/samba/-/commit/da576616f3c2156e7103eeab0a951ca459c4953e
[15:18] <ahasenack> so that smbclient header was doing the #define before
[15:18] <ahasenack> (via the original patch)
[18:01] <ahasenack> getconf LFS_CFLAGS it is
[18:01] <ahasenack> I wonder how many packages will have to be patched with that
[19:10] <lousiF> sudo apt update
[19:10] <lousiF> all day
[19:10] <lousiF> lol
[19:11] <lousiF> weird Jellyfish operating system..


[03:32] <ehoover> wgrant: we're still having 503 trouble with our recipe builds ( https://code.launchpad.net/~pipelight/+recipe/wine-compholio-daily ), but if we only build one or two at a time things seem to be ok
[03:33] <ehoover> has something changed in the past week or so?
[06:25] <CarlFK> $ dput CarlFK-ppa dvswitch_0.9.1-ubuntu6_source.changes
[06:25] <CarlFK> No host CarlFK-ppa found in config
[06:26] <CarlFK> I think I lost the config migrating to a new box.. where is this config spozed to be?
[06:26] <wgrant> You shouldn't need manual config
[06:26] <wgrant> Unless you're uploading from !Ubuntu
[06:26] <wgrant> dput ppa:USERNAME/PPANAME foo.changes
[06:30] <CarlFK> Successfully uploaded packages.
[06:30] <CarlFK> yay.  thanks wgrant
[07:10] <CarlFK> er... https://launchpad.net/~carlfk/+archive/ppa  Latest updates:            dvsmon                        111 weeks             ago
[07:10] <CarlFK> shouldn't I see what I just uploaded ?
[07:10] <CarlFK> + dput ppa:CarlFK/CarlFK-ppa dvswitch_0.9.1-ubuntu7_source.changes
[07:11] <wgrant> You have mail
[07:11] <wgrant> Specifically:
[07:11] <wgrant> 2014-01-20 06:31:14 DEBUG   Rejected:
[07:11] <wgrant> 2014-01-20 06:31:14 DEBUG   Launchpad failed to process the upload path '~CarlFK/CarlFK-ppa/ubuntu':
[07:12] <wgrant> 2014-01-20 06:31:14 DEBUG
[07:12] <wgrant> 2014-01-20 06:31:14 DEBUG   Could not find person or team named 'CarlFK'.
[07:12] <wgrant> You probably wanted ppa:carlfk/ppa
[07:12] <CarlFK> ah, thanks
[07:12] <CarlFK> Package has already been uploaded to ppa on ppa.launchpad.net
[07:12] <CarlFK> rawr.
[07:12] <wgrant> dput -f
[07:15] <CarlFK> oh look.. the page says "You can upload packages to this PPA using: dput ppa:carlfk/ppa ..."
[07:15] <CarlFK> I should do that ;)
[07:15] <CarlFK> yay.  Build started                   12 seconds ago                   on                   wani04 (amd64+qemu)
[18:47] <CarlFK> a year ago or so there was talk of being able to target multiple ubuntu releases for PPA.    has that happened yet?
[22:01] <teward> is there a way to duplicate the functionality the PPAs have, where you upload a source package, it builds in sbuild or whatever, and then uploads to its own Debian repository, WITHOUT Launchpad?  (Or, do I need to ask this in #ubuntu-server or somewhere else?)
[22:06] <teward> (i.e. duplicate this on a private system/server)
[23:26] <dobey> teward: you'd have to implement something that did all the same work. you could run an instance of launchpad on a private server, but it'd probably be easier to just implement something that only copied the PPA functionality if you don't want all the other stuff too
[23:27] <teward> dobey: that's kinda what I meant, any ideas on how to replicate that?
[23:27] <teward> (just the PPA functions)
[23:29] <dobey> aside from a web page to dhow the contents as LP does, it should be fairly easy
[23:29] <dobey> you just have to take the bits and glue them together, and make sure you do it securely
[23:30] <dobey> but probably a bit off topic for #launchpad. maybe slightly more on topic in #launchpad-dev
[23:42] <wgrant> dobey, teward: Some Ubuntu channel is probably more relevant.
[23:43] <wgrant> #launchpad-dev is for Launchpad development, not so much for replicating Launchpad functionality without Launchpad involvement.
[23:49] <teward> i'll poke #ubuntu-server, they'll probably have an idea
[23:49] <teward> and if not, well... then maybe poke the people who develop LP who know the pure basics.


[02:38] <rberger> Ist there any accurate stanza documentation for the version of upstart that is shipping with Ubuntu Karmic? The Wiki http://upstart.ubuntu.com/wiki/ does not seem to reflect what is being shipped in that release?
[03:20] <raphael___> rberger: you want to look at http://packages.ubuntu.com/upstart
[03:23] <rberger> raphael: That just seems to have the package info, but no usage documentation. I'm looking at info for writing my own init scripts
[03:33] <JanC> rberger: man 5 init
[03:45] <rberger> JanC: Thanks, that is what I'm looking for. I had tried man initctl and man upstart but cause of history had a historical blindspot for man init. Might be good to note this on the wiki/launchpad site...
[03:45] <rberger> s/historical/mental/
[03:46] <JanC> you should always look at the SEE ALSO section of manpages  ;)
[03:47] <rberger> I did but "assumed" that init was the old init stuff and not the configuration info for the new stuff. I'm still realing from it going from /etc/event.d to /etc/init
[03:48] <rberger> Looks like the console stuff no longer is there. I spent an hour or so trying the various example from the wiki that use the console output and console owner assuming I should see the output on my terminal...


[12:04] <ahasenack> morning
[12:04] <athos> ahasenack: morning :)
[12:08] <ahasenack> hi athos
[14:15] <lotuspsychje> flaf: did you get answered yet on your issue?
[14:18] <flaf> Hi lotuspsychje. Not yet unfortunately. According to this comment https://bugs.launchpad.net/subiquity/+bug/1946609/comments/2 , I think the feature exists but I have not found.
[14:21] <lotuspsychje> you filed the bug flaf ?
[14:26] <flaf> lotuspsychje: in fact it's a old bug I had filed and during the discussion I have said "to avoid my problem, it was cool if an option could allow a minimal install". And someone tells me "the option exists now since Ubuntu 21.10".
[14:27] <flaf> lotuspsychje: I would to deploy Ubuntu 22.04 now and I would like to use this feature (a minimal install) by I have found no info concerning this feature in the documentation of Subiquity.
[14:28] <lotuspsychje> i see flaf maybe the volunteers here might guide you to the best road
[14:31] <ahasenack> flaf: can you try 22.04 in a vm and see if the option is there, and if it does what you need?
[14:31] <flaf> lotuspsychje: yes. I had some private messages with dbungert, which is a dev of Subiquity. He helped me very well and, in return, I have filed some bugs. ;) But he doesn't seem to be present on this chan anymore.
[14:34] <flaf> ahasenack: This feature ("minmal" install) is present via a non interactive install (tested, I put the CD and answer to the questions...). But, in my case, I try a full automatic install via a user-data file (Subiquity/cloud-init/curtin etc). By this way, I have not found the option in user-data file to select a minimal install.
[14:35] <flaf> ahasenack: I hope I'm clear...
[14:36] <flaf> oups... this feature is present via an *interactive* install... But not found via user-data file (ie full automatic install).
[14:37] <ahasenack> ok
[16:08] <jrwren> e2fsck says a fs is in use. it doesn't show as mounted. I can mount it and unmount it. I cannot lvchange -a n it. reboot will probably fix it, but I'm trying to skip that.  What to do?
[17:01] <ahasenack> what about /proc/mounts?
[17:16] <ygk_12345> HI all
[17:16] <ygk_12345> i am trying to set systemd service overrides by issuing the command systemctl edit <service-name>
[17:17] <ygk_12345> but the the value for LimitNOFILESoft is not changing even after systemstl daemon-reload.
[17:17] <ygk_12345> its ubuntu 20.04. how to modify limits only for a specific process ?
[17:17] <ygk_12345> i dont want global change
[17:18] <ygk_12345> I mean for systemd specific service only
[17:20] <daum> i'm on 20.04 on a server and recently started getting packet loss.  Looking at the output of ifconfig i see the dropped count slowly increasing.  Any ideas what i could look at to try to resolve this?
[17:21] <sdeziel> ygk_12345: could you share the `systemctl cat <service-name>` output via pastebin?
[17:22] <ygk_12345> sdeziel i dont have it handy right now.  But the LimitNOFILESOft is set to 1024. i want to change it to 2048 for that service only
[17:25] <sdeziel> ygk_12345: then having the following in the override snippet should work: https://termbin.com/ejo5
[17:26] <ygk_12345> @sd
[17:26] <ygk_12345> sdeziel bu it is not working even after a reload and a restart
[17:27] <ygk_12345> sdeziel still systemctl show service  is reporting old values only
[17:31] <sdeziel> ygk_12345: LimitNOFILESoft is not a valid name (there is no Soft suffix) so maybe that's the problem? Without seeing the cat output, it's hard to be sure
[17:31] <ygk_12345> sdeziel its exactly this "{LimitNOFILESoft"
[17:32] <ygk_12345> "LimitNOFILESoft"
[17:38] <sdeziel> ygk_12345: my bad, "LimitNOFILESoft" is valid, but it doesn't show in `man systemd.exec` which is weird. I think it's still worth trying with "LimitNOFILE"
[17:39] <ygk_12345> sdeziel "LimitNOFILE" is hard limit
[17:39] <ygk_12345> sdeziel i want to increase only the soft limit
[17:40] <sdeziel> ygk_12345: `man systemd.exec` says: > Set soft and hard limits on various resources for executed processes.
[17:42] <ygk_12345> sdeziel maybe I can try this "colon-separated pair soft:hard"
[17:43] <sdeziel> ygk_12345: I just tested and using `LimitNOFILE=2048:524288`, gives me LimitNOFILE=524288 and LimitNOFILESoft=2048
[17:43] <ygk_12345> sdeziel ok i will try it. thanks so much for your time and help. Have a nice day ahead :)
[17:44] <sdeziel> ygk_12345: you are welcome, you too
[17:56] <sdeziel> apt-get crashes one of my server no matter what I do with it https://termbin.com/gt0o. It started crashing after a power outage but a fresh `btrfs strub` says it's all clean, any ideas?
[17:56] <sdeziel> and dmesg had this: traps: apt-get[1783701] general protection fault ip:7e3cf64bef7b sp:7ffd15913248 error:0 in libc-2.31.so[7e3cf649e000+178000]
[17:57] <ahasenack> jammy or kinetic?
[17:57] <sdeziel> ahasenack: sorry, 20.04
[17:58] <sdeziel> libc6 was upgraded on May 11th: Upgrade: libc6:amd64 (2.31-0ubuntu9.7, 2.31-0ubuntu9.9)
[17:59] <ahasenack> haven't seen that before
[17:59] <sdeziel> yeah, me neither and it only affects one of 3 machines I keep almost identical
[18:01] <sdeziel> I will try to downgrade using dpkg on old .deb
[18:04] <sdeziel> downgrading libc6:amd64 from 2.31-0ubuntu9.9 to 2.31-0ubuntu9.7 => didn't help :/
[18:10] <sdeziel> oh well, a reboot made it work and I can go back to 9.9 and it still works, sorry for the noiswe
[19:06]  * ahasenack is scared of the samba merge this cycle
[19:07] <sergiodj> how's it looking?
[19:09] <ahasenack> I'm just watching the traffic, and there were many many changes
[19:10] <ahasenack> I was waiting for it to calm down a bit, before tackling the merge
[19:10] <sergiodj> any news from the Debian side, or will we stay ahead of them?
[19:10] <ahasenack> at least the new maintainer is very active, and has no qualms with asking upstream when he sees something that feels wrong
[19:10] <ahasenack> debian moved on, they are on 4.16.x already (the new maintainer did it)
[19:10] <sergiodj> ah, great
[19:11] <ahasenack> he is making many changes to the build system
[19:11] <ahasenack> the package build, that is
[19:11] <sergiodj> right
[19:11] <ahasenack> which is where the delta hurts
[19:11] <ahasenack> we still have i386 delta
[19:11] <ahasenack> I wonder when we will get rid of i386 for goot
[19:11] <ahasenack> good*
[19:11] <sergiodj> interesting.  I will try to check what happened during these last few months
[19:11] <sergiodj> ah, i386...  never ending story
[19:12] <patdk-lap> holdoff till I can kill frontpage? :)
[19:13] <sergiodj> FWIW openldap 2.6 also changed libldap's soname, which will require a new binary package
[19:13] <ahasenack> I actually had to think for one or two seconds for that one
[19:13] <ahasenack> frontpage
[19:13] <ahasenack> sergiodj: that's fine
[19:13] <patdk-lap> :)
[19:13] <sergiodj> yeah
[19:13] <ahasenack> first thing I remembered were frontpage exploits, access.log full of some fp? links
[19:13] <sergiodj> I'm double check everything because I don't want to mess up this rename
[19:14] <patdk-lap> ya, it is suppose to have root on the server, in each clients web space :(
[19:14] <sergiodj> s/check/checking/
[19:14] <patdk-lap> mine is hacked to run as a normal cgi under normal user permissions
[19:14] <patdk-lap> should see how many customers are logging into it still
[20:35] <ahasenack> sergiodj: I think openldap is failing to do sasl digest-md5 authentication (yes, quite obscure)
[20:35] <ahasenack> I was just trying with postfix (another server I know uses cyrus-sasl2), and it works there, so I'm about to rule out a cyrus-sasl2 bug
[20:35] <ahasenack> but will test openldap with previous cyrus-sasl2 now
[20:36] <sergiodj> ahasenack: OK, thanks for the heads up
[20:36] <ahasenack> getting postfix to work with sasl auth was "interesting", since it defaults to a chroot
[20:36] <ahasenack> and I think I found a bug in the way it prepares that chroot
[20:37] <ahasenack> it copies files into it without preserving the permission
[20:37] <ahasenack> so my secrets file was copied over and made 0644 (!)
[20:38] <sergiodj> ahasenack: kinetic, right?
[20:38] <ahasenack> yes
[20:38] <sergiodj> let me see if I can find a bug in the upstream bugzilla
[20:38] <sergiodj> although, as you said, it's very obscure
[20:39] <ahasenack> and openldap is deeming digest-md5 obsolete/insecure, so I'm unsure if they will even want to check it
[20:39] <ahasenack> but hey, got a dep8 failure about it
[20:39] <ahasenack> tests/test_ldapconnection.py::test_bind_digest Fatal Python error: Segmentation fault
[20:43] <sergiodj> found two bugs with "digetst-md5" in their comment sections, but they don't seem related to the error you're mentioning
[20:47] <sarnold> if that's on a github-hosted repo, https://github.com/check-spelling/check-spelling  might be a nice suggestion :)
[20:49] <ahasenack> your highlight rules are a mistery to me :)
[20:51] <sarnold> alas, it's much less sophisticated than that, it's just if the most recent few lines in a channel look interesting..
[20:51] <sarnold> and 'md5' surely stands out as 'interesting' :)
[20:54] <ahasenack> no typo there either :)
[20:57] <sarnold> alas they got that part right! :D
[21:00] <ahasenack> hm, found other bugs
[21:00] <ahasenack> the openldap cli utilities no longer take -h for hostname
[21:01] <ahasenack> that explains this I"m seeing in tests: "ldapwhoami: unrecognized option -�"
[21:01] <ahasenack> alas, it's not failing the tests
[21:01] <ahasenack> script is not run with set -e
[21:02] <sergiodj> I don't remember seeing this in the release notes
[21:02] <sergiodj> huh
[21:04] <ahasenack> ok, got digest-md5 working with previous cyrus
[21:06] <ahasenack> and with the new one, the client core dumps
[21:06] <ahasenack> grumbl
[21:09] <ahasenack> https://pastebin.ubuntu.com/p/qxygkxddjJ/
[21:10] <ahasenack> before I EOD, let me check if I can at least see if the crash is inside openldap or cyrus
[21:11] <ahasenack> oh, plot twist
[21:11] <ahasenack> it's in libssl3
[21:11] <sergiodj> hahah
[21:12] <sergiodj> oh, man
[21:12] <ahasenack> I mean, libcrypto.so.3
[21:12] <ahasenack> I meant to say openssl3
[21:12] <sergiodj> right
[21:12] <ahasenack> #0  0x00007ffff740854b in EVP_EncryptUpdate () from /lib/x86_64-linux-gnu/libcrypto.so.3
[21:12] <ahasenack> #1  0x00007ffff70a07a9 in ?? () from /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so
[21:12] <ahasenack> will install debug symbols tomorrow
[21:12] <sergiodj> where's debuginfod again?!
[21:12] <ahasenack> slacking
[21:13] <ahasenack> tsc, tsc
[21:13] <ahasenack> I keep reading it as debug info fod
[21:13] <ahasenack> or debugin fod
[21:13] <sergiodj> yeah, some people say "debug infod"
[21:13] <sergiodj> heh
[21:13] <sergiodj> bad naming
[21:13] <ahasenack> correct is debuginfo d, right?
[21:13] <ahasenack> as in debuginfo daemon?
[21:13] <sergiodj> yes
[21:13] <ahasenack> k
[21:16] <ahasenack> postfix digest-md5 worked, but it didn't setup a security layer (ssf was zero)
[21:16] <ahasenack> ldap sets a security layer, ssf=128
[21:16] <ahasenack> and something goes wrong
[21:16] <ahasenack> postfix digest-md5, showing it worked, but ssf=0: https://pastebin.ubuntu.com/p/R5xNQnYKJ2/
[21:17] <ahasenack> and if I try to force it, it doesn't auth
[21:17] <ahasenack> "too weak": https://pastebin.ubuntu.com/p/f9HG3MH2Nm/
[21:20] <sergiodj> sorry, I'm pulling my hair out a little bit with Breaks/Conflicts/Replaces and the new openldap library name
[21:21] <ahasenack> ah, no, I'm just thinking out loud
[21:21] <sergiodj> yeah, please keep going
[21:21] <sergiodj> it's fun watching a live debug session
[21:21] <sergiodj> :)
[21:22] <ahasenack> if I disable the security factor (i.e., ssf=0), then digest-md5 works with ldap just like it did for postfix (where it was zero)
[21:22] <ahasenack> ubuntu@k1-sasl-digest-ldap:~$ ldapwhoami  -U ubuntu@lxd -w ubuntusecret -O maxssf=0
[21:22] <ahasenack> SASL/DIGEST-MD5 authentication started
[21:22] <ahasenack> SASL username: ubuntu@lxd
[21:22] <ahasenack> SASL SSF: 0
[21:22] <ahasenack> dn:uid=ubuntu@lxd,cn=vms,cn=digest-md5,cn=auth
[21:22] <ahasenack> ubuntu@k1-sasl-digest-ldap:~$
[21:22] <ahasenack> no core dump
[21:23] <ahasenack> ok, probably have enough for tomorrow
[22:08] <octav1a> I have a raid1 mdadm with two disks. I don't see any I/O errors in dmesg. For some reason, when rebooting the machine safely with sudo reboot, when it comes back up I still get a "recovery" process every time in /proc/mdstat
[22:08] <octav1a> Does anyone know why this happens?
[22:09] <octav1a> they are SSD so I feel this is putting undue wear on them
[23:17] <patdk-lap> must not be rebooting correctly? never seen a recovery thing in mdstat due to a reboot
[23:18] <patdk-lap> how did you configure md?
[23:19] <sdeziel> I remember some (old) bug where something was not properly umounted causing this behavior


[03:08] <sweb> wxl: sddm not start , just lightdm work
[03:18] <wxl> sweb do over but install lubuntu-desktp and sddm at the same time
[03:18] <wxl> you shouldn't have lightdm at all
[03:19] <sweb> wxl: it's install, dpkg-reconfigure sddm , reboot not apply no error nither in syslog
[03:20] <wxl> ^ did you end up testing on amd64 guiverc
[03:20] <wxl> ?
[03:21] <sweb> guiverc ? ppa ? add repo ?
[03:22] <wxl> he was going to see if he could confirm your experience; previously we had confirmed it works fine if you `sudo apt install lubuntu-desktop` or `sudo apt install ^lubuntu-desktop sddm`
[03:22] <guiverc> no issues on amd64  daily
[03:23] <wxl> so that means you've somehow done something different, sweb
[03:23] <guiverc> my prior confirmation daily boots to LXQt, general 'live' play & everything was as expected
[03:24] <wxl> was it clear we meant mini/netboot -> install metapackage?
[03:24] <sweb> it's arm64 raspberry pi 4 4G
[03:24] <sweb> also on 2G
[03:24] <sweb> not amd64
[03:24] <wxl> OH
[03:24] <wxl> one difference
[03:24] <wxl> you installed server
[03:25] <sweb> yeah i install servers
[03:25] <sweb> server version as i mention before
[03:25] <wxl> nevermind, that is what we tested
[03:26] <sweb> one important i need mini version of preinstall not server i could not find image for that
[03:27] <wxl> right, no nevermind that you were right with server
[03:29] <sweb> so i thinks that's but, also huge list of dependecy for lubuntu ... why ever need to install gdm during installation
[03:29] <sweb> ?
[03:30] <kc2bez> unless there is something has changed from 19.10 to 20.04 it shouldn't install gdm
[03:31] <sweb> try it ... it's will
[03:32] <wxl> you shouldn't
[03:32] <wxl> it in fact explicitly requests sddm instead
[03:32] <sweb> 19.10 also install gdm3
[03:33] <wxl> install aptitute and run `aptitude why gdm3`
[03:33] <wxl> pastebin the results
[03:36] <sweb> https://paste.ubuntu.com/p/hqFMMztrMt/
[03:38] <sweb> it's already there https://packages.ubuntu.com/focal/lubuntu-desktop
[03:39] <sweb> how could possible ? 0_o
[03:41] <sweb> lubuntu depend entire gnome, right ? so gdm3 install and the default display manager so maybe sddm not configure well and so on...
[03:41] <wxl> no
[03:41] <kc2bez> Lubuntu does not depend on Gnome
[03:42] <wxl> tight
[03:42] <wxl> right i mean
[03:42] <wxl> but network-manager-gnome requires gnome-shell??????
[03:43] <sweb> seems be
[03:43] <wxl> it didn't used to
[03:43] <sweb> https://packages.ubuntu.com/focal/network-manager-gnome
[03:44] <sweb> could i expect to solve this problem solved soon ?
[03:45] <wxl> maybe
[03:45] <wxl> i don't understand because we tested this before
[03:45] <wxl> @kc2bez: something is very weird here. how did it work for you?
[03:45] <wxl> and how do we not have gnome-shell installed???
[03:45] <kc2bez> I will test it again tomorrow.
[03:46] <kc2bez> I didn't have gnome-shell
[03:46] <wxl> i'm on a daily 20.10 and there's network-manager-gnome, but no gnome-shell
[03:46] <kc2bez> it worked well for me.
[03:47] <kc2bez> I only tested 19.10 though
[03:48] <sweb> thanks guys for telling me ... i install about 5 time different image on my raspberry tonight and i'm going to die to what's my mistake
[03:49] <wxl> https://launchpadlibrarian.net/410773007/network-manager-applet_1.8.18-2ubuntu3_1.8.18-2ubuntu4.diff.gz
[03:49] <sweb> kc2bez: https://packages.ubuntu.com/eoan/lubuntu-desktop it's also as recommends on  https://packages.ubuntu.com/eoan/network-manager-gnome so withount no remocend install it's will install
[03:49] <wxl> upstream screwed us :/
[03:49] <sweb> accourding this page : https://ubuntu.com/download/raspberry-pi
[03:50] <sweb> sudo apt-get install lubuntu-desktop will install entire gnome-shell
[03:51] <sweb> i thinks that's dependecy bug for eoen and focal
[03:51] <kc2bez> I still have my pi with Lubuntu on it. I will report back tomorrow.
[03:52] <sweb> thanks i have to go, thanks btw
[03:53] <wxl> i'm still confused by this
[03:54] <kc2bez> I am a little too
[03:54] <kc2bez> I am not on front of my pi right now though.
[03:55] <wxl> maybe a timing thing
[03:55] <wxl> seems it's gnome-shell | policykit-1-gnome | polkit-1-auth-agent
[03:55] <wxl> the latter is a virtual package including lxqt-policykit
[03:56] <wxl> and, curiously, policykit-1-gnome
[03:59] <wxl> jbicha's patches 1.8.10-2ubuntu{3,4} seem to be the problems; we released 1.20.4-2ubuntu2
[04:01] <kc2bez> We have Gnome-shell blacklisted in rSeed https://phab.lubuntu.me/source/seed/browse/focal/blacklist$10
[04:01] <kc2bez> might be why it doesn't show in our daily.
[04:02] <wxl> ahhhhh
[04:02] <wxl> i wonder if doing the task DOES make a difference
[04:03] <kc2bez> I will test both.
[04:03] <wxl> i'd first try installing `lubuntu-desktop` to confirm the activity, then `^lubuntu-desktop` and if both of those fail, `lubuntu-desktop sddm` and `^lubuntu-desktop sddm` in focal and eoan
[04:04] <kc2bez> will do. I will report back to you.
[04:05] <wxl> thanks
[05:06] <guiverc> if of value; these are the gnome packages in daily (2020-01-12) https://paste.ubuntu.com/p/XTjsdyRB3z/  gnome-accessibility-themes  gnome-icon-theme  gnome-keyring  gnome-keyring-pkcs11:amd64   gnome-themes-extra:amd64  gnome-themes-extra-data  libpam-gnome-keyring:amd64   libsoup-gnome2.4-1:amd64  network-manager-gnome  pinentry-gnome3


[00:20] <vorlon> schopin: hydra FTBFS with openssl 3 might be an openssl bug; openssl/err.h references INT_MAX without including limits.h?
[00:20] <vorlon> hmm except it does include limits.h
[00:21] <vorlon> suspicious
[01:00] -queuebot:#ubuntu-release- New binary: libixion [amd64] (jammy-proposed/main) [0.17.0-3] (ubuntu-desktop)
[01:01] -queuebot:#ubuntu-release- New binary: libixion [ppc64el] (jammy-proposed/main) [0.17.0-3] (ubuntu-desktop)
[01:01] -queuebot:#ubuntu-release- New binary: libixion [s390x] (jammy-proposed/main) [0.17.0-3] (ubuntu-desktop)
[01:06] -queuebot:#ubuntu-release- New binary: libixion [armhf] (jammy-proposed/main) [0.17.0-3] (ubuntu-desktop)
[01:07] -queuebot:#ubuntu-release- New binary: libixion [arm64] (jammy-proposed/main) [0.17.0-3] (ubuntu-desktop)
[01:21] -queuebot:#ubuntu-release- New: accepted libixion [amd64] (jammy-proposed) [0.17.0-3]
[01:21] -queuebot:#ubuntu-release- New: accepted libixion [armhf] (jammy-proposed) [0.17.0-3]
[01:21] -queuebot:#ubuntu-release- New: accepted libixion [s390x] (jammy-proposed) [0.17.0-3]
[01:21] -queuebot:#ubuntu-release- New: accepted libixion [arm64] (jammy-proposed) [0.17.0-3]
[01:21] -queuebot:#ubuntu-release- New: accepted libixion [ppc64el] (jammy-proposed) [0.17.0-3]
[02:50] -queuebot:#ubuntu-release- New binary: insighttoolkit5 [amd64] (jammy-proposed/universe) [5.2.1-1] (no packageset)
[04:06] -queuebot:#ubuntu-release- New binary: liborcus [amd64] (jammy-proposed/main) [0.17.0-2] (ubuntu-desktop)
[04:06] -queuebot:#ubuntu-release- New binary: liborcus [s390x] (jammy-proposed/main) [0.17.0-2] (ubuntu-desktop)
[04:06] -queuebot:#ubuntu-release- New binary: liborcus [ppc64el] (jammy-proposed/main) [0.17.0-2] (ubuntu-desktop)
[04:14] -queuebot:#ubuntu-release- New binary: liborcus [arm64] (jammy-proposed/main) [0.17.0-2] (ubuntu-desktop)
[04:16] -queuebot:#ubuntu-release- New binary: liborcus [armhf] (jammy-proposed/main) [0.17.0-2] (ubuntu-desktop)
[05:22] -queuebot:#ubuntu-release- New binary: cgif [amd64] (jammy-proposed/universe) [0.0.2-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: hcxkeys [amd64] (jammy-proposed/universe) [6.2.0-1] (no packageset)
[05:22] <RikMills> vorlon: why did you rebuild qtbase-opensource-src?
[05:24] -queuebot:#ubuntu-release- New binary: cgif [ppc64el] (jammy-proposed/universe) [0.0.2-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: pg-auto-failover [amd64] (jammy-proposed/universe) [1.6.3-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: hcxkeys [ppc64el] (jammy-proposed/universe) [6.2.0-1] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: libmobi [amd64] (jammy-proposed/universe) [0.9+dfsg1-1] (no packageset)
[05:27] -queuebot:#ubuntu-release- New binary: libmobi [ppc64el] (jammy-proposed/universe) [0.9+dfsg1-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: liborcus [riscv64] (jammy-proposed/main) [0.17.0-2] (ubuntu-desktop)
[05:29] -queuebot:#ubuntu-release- New binary: pg-auto-failover [ppc64el] (jammy-proposed/universe) [1.6.3-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: cgif [s390x] (jammy-proposed/universe) [0.0.2-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: cgif [arm64] (jammy-proposed/universe) [0.0.2-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: hcxkeys [arm64] (jammy-proposed/universe) [6.2.0-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: hcxkeys [s390x] (jammy-proposed/universe) [6.2.0-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libmobi [s390x] (jammy-proposed/universe) [0.9+dfsg1-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: cgif [armhf] (jammy-proposed/universe) [0.0.2-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libmobi [arm64] (jammy-proposed/universe) [0.9+dfsg1-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: hcxkeys [armhf] (jammy-proposed/universe) [6.2.0-1] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: pg-auto-failover [s390x] (jammy-proposed/universe) [1.6.3-1] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: libmobi [armhf] (jammy-proposed/universe) [0.9+dfsg1-1] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: howardhinnant-date [ppc64el] (jammy-proposed/universe) [3.0.1-1] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: pg-auto-failover [arm64] (jammy-proposed/universe) [1.6.3-1] (no packageset)
[05:35] -queuebot:#ubuntu-release- New binary: howardhinnant-date [amd64] (jammy-proposed/universe) [3.0.1-1] (no packageset)
[05:38] -queuebot:#ubuntu-release- New binary: howardhinnant-date [s390x] (jammy-proposed/universe) [3.0.1-1] (no packageset)
[05:46] -queuebot:#ubuntu-release- New binary: howardhinnant-date [armhf] (jammy-proposed/universe) [3.0.1-1] (no packageset)
[05:50] -queuebot:#ubuntu-release- New binary: howardhinnant-date [arm64] (jammy-proposed/universe) [3.0.1-1] (no packageset)
[06:10] <RikMills> vorlon: can you remove qtbase 5.15.2+dfsg-14ubuntu2 please?
[06:10] <RikMills> LP: #1953712
[06:31] <cpaelzer> Hi ubuntu-archive, there is a "Binary only movements to universe" in component mismatches that would help me - it is about the demotion of postgresql-server-dev-14
[06:35] <RAOF> cpaelzer: Enjoy.
[06:35] <cpaelzer> \o/
[06:35] <cpaelzer> thanks RAOF
[06:37] <RikMills> archive-admin: please remove qtbase 5.15.2+dfsg-14ubuntu2 from proposed
[06:38] <RikMills> qtbase-opensource-src
[07:56] -queuebot:#ubuntu-release- New binary: hcxkeys [riscv64] (jammy-proposed/universe) [6.2.0-1] (no packageset)
[08:06] -queuebot:#ubuntu-release- New binary: libmobi [riscv64] (jammy-proposed/universe) [0.9+dfsg1-1] (no packageset)
[08:30] -queuebot:#ubuntu-release- New binary: howardhinnant-date [riscv64] (jammy-proposed/universe) [3.0.1-1] (no packageset)
[08:42] -queuebot:#ubuntu-release- New binary: pg-auto-failover [riscv64] (jammy-proposed/universe) [1.6.3-1] (no packageset)
[09:31] -queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [arm64] (jammy-proposed/multiverse) [11.5.1-1] (no packageset)
[09:37] <RikMills> sil2100: hi, would you be kind enough to remove qtbase-opensource-src 5.15.2+dfsg-14ubuntu2 from proposed?
[09:37] <RikMills> LP: #1953712
[09:38] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (impish-proposed) [2.742.2]
[09:38] <sil2100> RikMills: hey! Looking
[09:39] <RikMills> discussed with Steve last night, where agreed not to rebuild it. Then I guess it slipped in in his mass script all the same
[09:40] <sil2100> Yeah, makes sense, removing it then
[09:40] <RikMills> Thanks. debian-qt people are working on an openssl 3 patch at the moment
[09:45] <paride> bdmurray, that arm64 image you prepared really helped a lot!
[09:47] <sil2100> paride: hey! Sorry, missed your ping yesterday, were you able to get things resolved? :)
[10:01] <ricotz> hello, will jammy get the icu 70 update?
[10:23] -queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (jammy-proposed/multiverse) [11.5.1-1] (no packageset)
[10:31] -queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (jammy-proposed/multiverse) [11.5.1-1] (no packageset)
[11:07] <paride> sil2100, yes, bdmurray helped me out
[11:08] <paride> actually I still don't know how to produce a custom ISO by myself, I guess I'd have to setup the entire build process with a custom +livefs on LP
[11:08] <paride> one day I'll try
[11:46] <sil2100> paride: hah, yeah, it's a bit annoying to set that up locally, I can try writing up some docs one day for that, since you need both cdimage and debian-cd
[11:53] -queuebot:#ubuntu-release- New binary: ceres-solver [s390x] (jammy-proposed/universe) [2.0.0+dfsg1-1] (no packageset)
[12:38] <ricotz> hello, please accept liborcus NEW - https://launchpad.net/ubuntu/+source/liborcus/0.17.0-2
[12:45] <ricotz> sil2100, hi :) ^
[13:00] -queuebot:#ubuntu-release- New binary: ceres-solver [amd64] (jammy-proposed/universe) [2.0.0+dfsg1-1] (no packageset)
[13:24] <slyon> hey ubuntu-sru! If I have a fix that only affects the LTS (i.e. Ubuntu Core images), do I still need to SRU it to all the series in between (Focal -> Hirsute -> Impish -> Jammy) or is it enough to have it fixed in the upgrade path (Focal -> Jammy)?
[13:27] -queuebot:#ubuntu-release- New binary: ceres-solver [armhf] (jammy-proposed/universe) [2.0.0+dfsg1-1] (no packageset)
[15:29] -queuebot:#ubuntu-release- Unapproved: debhelper (focal-backports/main) [12.10ubuntu1 => 13.5.2ubuntu1~bpo20.04.1] (core, i386-whitelist)
[15:33] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (focal-backports/universe) [0.185~bpo20.04.1 => 0.187~bpo11+1] (no packageset)
[15:41] <bdmurray> slyon: I think its enough to only fix it in the LTSes then but be explicit in the bug i.e. add Won't Fix tasks for the other releases and explain why in the bug description
[15:42] <slyon> bdmurray: thanks! will do
[15:52] <sil2100> ricotz: o/
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (jammy-proposed) [2.06-2ubuntu2]
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [arm64] (jammy-proposed) [2.06-2ubuntu2]
[15:54] -queuebot:#ubuntu-release- New: accepted insighttoolkit5 [amd64] (jammy-proposed) [5.2.1-1]
[15:54] -queuebot:#ubuntu-release- New: accepted liborcus [arm64] (jammy-proposed) [0.17.0-2]
[15:54] -queuebot:#ubuntu-release- New: accepted liborcus [ppc64el] (jammy-proposed) [0.17.0-2]
[15:54] -queuebot:#ubuntu-release- New: accepted liborcus [amd64] (jammy-proposed) [0.17.0-2]
[15:54] -queuebot:#ubuntu-release- New: accepted liborcus [s390x] (jammy-proposed) [0.17.0-2]
[15:54] -queuebot:#ubuntu-release- New: accepted liborcus [armhf] (jammy-proposed) [0.17.0-2]
[16:08] -queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (jammy-proposed) [11.5.1-1]
[16:08] -queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (jammy-proposed) [11.5.1-1]
[16:08] -queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [arm64] (jammy-proposed) [11.5.1-1]
[16:08] -queuebot:#ubuntu-release- New: accepted cgif [amd64] (jammy-proposed) [0.0.2-1]
[16:08] -queuebot:#ubuntu-release- New: accepted cgif [s390x] (jammy-proposed) [0.0.2-1]
[16:08] -queuebot:#ubuntu-release- New: accepted libmobi [arm64] (jammy-proposed) [0.9+dfsg1-1]
[16:08] -queuebot:#ubuntu-release- New: accepted libmobi [ppc64el] (jammy-proposed) [0.9+dfsg1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted libmobi [s390x] (jammy-proposed) [0.9+dfsg1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted cgif [ppc64el] (jammy-proposed) [0.0.2-1]
[16:09] -queuebot:#ubuntu-release- New: accepted libmobi [armhf] (jammy-proposed) [0.9+dfsg1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted libmobi [amd64] (jammy-proposed) [0.9+dfsg1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted libmobi [riscv64] (jammy-proposed) [0.9+dfsg1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted hcxkeys [amd64] (jammy-proposed) [6.2.0-1]
[16:09] -queuebot:#ubuntu-release- New: accepted hcxkeys [armhf] (jammy-proposed) [6.2.0-1]
[16:09] -queuebot:#ubuntu-release- New: accepted hcxkeys [riscv64] (jammy-proposed) [6.2.0-1]
[16:09] -queuebot:#ubuntu-release- New: accepted hcxkeys [arm64] (jammy-proposed) [6.2.0-1]
[16:09] -queuebot:#ubuntu-release- New: accepted hcxkeys [s390x] (jammy-proposed) [6.2.0-1]
[16:09] -queuebot:#ubuntu-release- New: accepted hcxkeys [ppc64el] (jammy-proposed) [6.2.0-1]
[16:09] -queuebot:#ubuntu-release- New: accepted howardhinnant-date [amd64] (jammy-proposed) [3.0.1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted howardhinnant-date [armhf] (jammy-proposed) [3.0.1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted howardhinnant-date [riscv64] (jammy-proposed) [3.0.1-1]
[16:09] -queuebot:#ubuntu-release- New: accepted liborcus [riscv64] (jammy-proposed) [0.17.0-2]
[16:10] -queuebot:#ubuntu-release- New: accepted howardhinnant-date [arm64] (jammy-proposed) [3.0.1-1]
[16:10] -queuebot:#ubuntu-release- New: accepted howardhinnant-date [s390x] (jammy-proposed) [3.0.1-1]
[16:10] -queuebot:#ubuntu-release- New: accepted howardhinnant-date [ppc64el] (jammy-proposed) [3.0.1-1]
[16:12] -queuebot:#ubuntu-release- New: accepted cgif [arm64] (jammy-proposed) [0.0.2-1]
[16:13] -queuebot:#ubuntu-release- New: accepted cgif [armhf] (jammy-proposed) [0.0.2-1]
[16:13] -queuebot:#ubuntu-release- New: accepted pg-auto-failover [amd64] (jammy-proposed) [1.6.3-1]
[16:13] -queuebot:#ubuntu-release- New: accepted pg-auto-failover [ppc64el] (jammy-proposed) [1.6.3-1]
[16:13] -queuebot:#ubuntu-release- New: accepted pg-auto-failover [s390x] (jammy-proposed) [1.6.3-1]
[16:13] -queuebot:#ubuntu-release- New: accepted pg-auto-failover [arm64] (jammy-proposed) [1.6.3-1]
[16:13] -queuebot:#ubuntu-release- New: accepted pg-auto-failover [riscv64] (jammy-proposed) [1.6.3-1]
[16:28] -queuebot:#ubuntu-release- New binary: ceres-solver [riscv64] (jammy-proposed/universe) [2.0.0+dfsg1-1] (no packageset)
[16:52] -queuebot:#ubuntu-release- New: accepted ceres-solver [amd64] (jammy-proposed) [2.0.0+dfsg1-1]
[16:52] -queuebot:#ubuntu-release- New: accepted ceres-solver [riscv64] (jammy-proposed) [2.0.0+dfsg1-1]
[16:52] -queuebot:#ubuntu-release- New: accepted ceres-solver [armhf] (jammy-proposed) [2.0.0+dfsg1-1]
[16:52] -queuebot:#ubuntu-release- New: accepted ceres-solver [s390x] (jammy-proposed) [2.0.0+dfsg1-1]
[17:02] <juliank> vorlon: you're better at reading update_output.txt than I am, so what does this all mean:
[17:02] <juliank> skipped: lxml (228, 0, 12)
[17:02] <juliank>     got: 14+0: a-1:a-0:a-0:i-1:p-0:r-12:s-0
[17:02] <juliank>     * riscv64: gcc-python3-dbg-plugin, python3-lxml-dbg
[17:02] <juliank> why does that not pop up on update_excuses in a human-readable version?
[17:04] <juliank> That just means "migrating lxml would render gcc-python3-dbg-plugin uninstallable as it depends on python3-lxml-dbg"
[17:04] <juliank> ?
[17:05] <juliank> presumably this should be smoothed because we have SMOOTH_UPDATES=all rather than just libs oldlibs like Debian has
[17:05] -queuebot:#ubuntu-release- Unapproved: debhelper (bionic-backports/main) [12.1.1ubuntu1~ubuntu18.04.1 => 13.5.2ubuntu1~bpo18.04.1] (core)
[17:05] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-backports/universe) [0.175~18.04.2 => 0.187~bpo18.04.1] (no packageset)
[17:05] -queuebot:#ubuntu-release- Unapproved: dwz (bionic-backports/universe) [0.12-2 => 0.13-5~bpo18.04.1] (no packageset)
[17:06] <juliank> so I guess it would have printed that line without smoothing enabled?
[17:24] <bdmurray> paride: so will there be an upload of finalrd?
[17:25] <vorlon> juliank: yes, it means those are the packages rendered uninstallable - gcc-python3-dbg-plugin and python3-lxml-dbg; python3-lxml-dbg is NBS and britney tries to keep the old binary around, but because of strict versioned build-dep the old binary isn't installable with new lxml, and so gcc-python3-dbg-plugin is also uninstallable
[17:25] <vorlon> if only python3-lxml-dbg was broken by the update I believe britney would allow it
[17:26] -queuebot:#ubuntu-release- New binary: mkcert [ppc64el] (jammy-proposed/none) [1.4.3-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: mkcert [arm64] (jammy-proposed/none) [1.4.3-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: mkcert [s390x] (jammy-proposed/none) [1.4.3-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: mkcert [armhf] (jammy-proposed/none) [1.4.3-1] (no packageset)
[17:27] <paride> bdmurray, yes, the test iso worked perfectly. The upload I prepared doesn't implement a slightly different change, imho better
[17:28] <paride> which makes sense to have anyway, in case it shouldn't actually fix the issue I'm working at
[17:28] <paride> bdmurray, this is my proposal: https://code.launchpad.net/~paride/ubuntu/+source/finalrd/+git/finalrd/+merge/412931
[17:29] -queuebot:#ubuntu-release- New binary: mkcert [amd64] (jammy-proposed/none) [1.4.3-1] (no packageset)
[17:40] <ahasenack> :q
[18:00] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (hirsute-backports/universe) [0.180 => 0.187~bpo21.04.1] (no packageset)
[18:04] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (impish-backports/universe) [0.185 => 0.187~bpo21.10.1] (no packageset)
[18:33] <RikMills> vorlon: a qtbase-opensource-src that should work with openssl 3 is building in a landing PPA. I'll land that when it won't collide with the KDE apps release stack currently building
[18:42] -queuebot:#ubuntu-release- New binary: mkcert [riscv64] (jammy-proposed/universe) [1.4.3-1] (no packageset)
[19:33] <vorlon> RikMills: ok - sorry, I don't know how this wound up in the upload list when it wasn't there on a dry run
[19:36] <RikMills> vorlon: it happens. I certainly can't 'cast stones'. all is well, and a prooper fix got done perhaps sooner that it would have done as a result
[19:36]  * RikMills thanks mitya57 for that
[19:37] <RikMills> now I just need to fix my typing. sigh..... :D
[19:37] <seb128> vorlon, hey, did you see that you had a reply from poppler upstream on your merge request?
[19:39] <vorlon> seb128: yep, thanks
[19:42] <seb128> np!
[20:09] <ricotz> sil2100, o/ ty
[21:05] -queuebot:#ubuntu-release- New source: fwupd-efi (jammy-proposed/primary) [1:1.1-1~ubuntu1]
[22:03] -queuebot:#ubuntu-release- New binary: rustc [i386] (jammy-proposed/universe) [1.54.0+dfsg2+llvm-3ubuntu1] (i386-whitelist)
[22:15] <vorlon> cjwatson: hi, will you have time this week to look at the archive EFI key question?
[22:17] -queuebot:#ubuntu-release- New binary: rustc [amd64] (jammy-proposed/universe) [1.54.0+dfsg2+llvm-3ubuntu1] (i386-whitelist)
[22:28]  * vorlon ughs at LP: #1954338 - the kind of package that keeps limping along because it's less effort to continue fixing it than it is to open launchpad tasks for all the individual tiny revdeps
[22:47] -queuebot:#ubuntu-release- New binary: rustc [s390x] (jammy-proposed/universe) [1.54.0+dfsg2+llvm-3ubuntu1] (i386-whitelist)
[22:54] <bryceh> ubuntu-archive: lp: #1954343
[22:59] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (jammy-proposed/universe) [1.54.0+dfsg2+llvm-3ubuntu1] (i386-whitelist)
[23:24] -queuebot:#ubuntu-release- New binary: fnt [amd64] (jammy-proposed/none) [1.3-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: pyodc [amd64] (jammy-proposed/none) [1.1.2-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New: accepted fnt [amd64] (jammy-proposed) [1.3-1]
[23:25] -queuebot:#ubuntu-release- New: accepted mkcert [armhf] (jammy-proposed) [1.4.3-1]
[23:26] -queuebot:#ubuntu-release- New: accepted mkcert [s390x] (jammy-proposed) [1.4.3-1]
[23:26] -queuebot:#ubuntu-release- New: accepted mkcert [amd64] (jammy-proposed) [1.4.3-1]
[23:26] -queuebot:#ubuntu-release- New: accepted pyodc [amd64] (jammy-proposed) [1.1.2-1]
[23:26] -queuebot:#ubuntu-release- New: accepted mkcert [riscv64] (jammy-proposed) [1.4.3-1]
[23:26] -queuebot:#ubuntu-release- New: accepted mkcert [arm64] (jammy-proposed) [1.4.3-1]
[23:26] -queuebot:#ubuntu-release- New: accepted mkcert [ppc64el] (jammy-proposed) [1.4.3-1]
[23:27] -queuebot:#ubuntu-release- New: accepted rustc [amd64] (jammy-proposed) [1.54.0+dfsg2+llvm-3ubuntu1]
[23:27] -queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (jammy-proposed) [1.54.0+dfsg2+llvm-3ubuntu1]
[23:27] -queuebot:#ubuntu-release- New: accepted rustc [i386] (jammy-proposed) [1.54.0+dfsg2+llvm-3ubuntu1]
[23:27] -queuebot:#ubuntu-release- New: accepted rustc [s390x] (jammy-proposed) [1.54.0+dfsg2+llvm-3ubuntu1]
[23:28] -queuebot:#ubuntu-release- New binary: neutron-ha-tool [amd64] (jammy-proposed/none) [0.0.5-1] (no packageset)
[23:30] -queuebot:#ubuntu-release- New: accepted neutron-ha-tool [amd64] (jammy-proposed) [0.0.5-1]