[00:02] <anduril> anyways night all :)
[00:52] <InHisName> I think my problems are burning a CD slow enough to not have installation problems.  Brasero seems to want to burn 28x - 37x  even when I specify 8.0x  !!!
[00:55] <MobileTurkey> can't you set a option to go slower and also to do a md5 or sha1 sum of it?
[00:56] <InHisName> Set setting to: 8.0x    ---> avg drive speed: 4338KiB/s(25.2x)   about 3 TIMES faster than my cieling !
[02:01] <InHisName> OK, Brasero - out, GnomeBaker - out (no speed limit),  Now trying K3B - will limit down to 8x.  As it writes it seems to limited to 6.64x & 7.07x  both below 8x.  Also verifying CD after write.
[02:01] <InHisName> All done, not hung, eject works.  On to testing the install, now.
[02:03] <InHisName> Hmmm, the last disk seems to be still writing the install, maybe it's ok too.  Waiting some more......
[02:11] <MobileTurkey> InHisName: dude get some better software.
[02:11] <MobileTurkey> or just do a usb install....
[02:25] <InHisName> needs a motherboard that supports usb install to do that.
[02:26] <MobileTurkey> dang
[02:26] <MobileTurkey> how old is that box?
[02:26] <MobileTurkey> I mean most of my old boxes even support that
[02:28] <InHisName> Gettin' older every year.   I stumbled onto a Quad core cheap and bought a MB that was being clearanced. And that was several years ago.  2.4Ghz quad.  No reason to upgrade when I have NO income.
[02:39] <MobileTurkey> me neither
[02:39] <MobileTurkey> lack of income is pretty crappy
[09:22] <JonathanD> Morning.
[09:37] <jedijf> wet
[09:40] <JonathanD> yes
[09:57] <rmg51> wet morning all;-)
[10:10] <JonathanD> SOunded like sometihng just blew up
[10:19] <rmg51> I didn't hear a thing
[11:39] <InHisName> me neither
[11:39] <InHisName> only rain drop noises here
[12:04] <teddy-dbear> morning
[12:05] <anduril> I can haz ice scream sammawich?
[12:10] <teddy-dbear> only if you share with me :-D
[12:11]  * InHisName jumps into the sharing circle too
[12:56] <JonathanD> It was in bridgeport
[13:04] <InHisName> too far away for me to hear something from there.
[13:53] <InHisName> any pidgin experts around ?    I see:  history plugin requires logging      when I start Pidgin.  That is due to a setting that may be incomplete.  Not sure where to find it.
[13:58] <rmg51> InHisName: look under preferences logging
[13:59] <rmg51> you can also find it in the top left corner   Options
[14:03]  * JonathanD looks around.
[14:07] <InHisName> options>enable logging-checked    not finding preferences nor buddy lists    unity sure hides stuff from old methods.
[14:12] <rmg51> try alt-tab
[14:12] <rmg51> see if it's there
[14:14] <rmg51> I have to ask, how did you get to plugins?
[14:28] <InHisName> Pidgin is all the chat rooms,  the buddy list is separate but is not running in alt-tab.  I used to click on envelope in upper left and see options - one was to start buddy list.  Not there now (in envelope)
[14:33] <rmg51> since I'm hot using Unity, not sure I can be of anymore help
[14:34] <teddy-dbear> silly Unity :P
[17:54] <fosburg> can MAC postscirpt fonts be installed Ubuntu OS?
[21:16] <InHisName> My  NetGear WNDR3700 arrived.  Now to fit it into my other routers/switches and to work well together.
[22:46] <beta0x64> what's up?
[22:46] <rmg51> me
[22:46] <beta0x64> ew...
[22:46] <InHisName> I'm sittin' down
[22:47] <beta0x64> just kidding
[22:47] <InHisName> I'm sittin' down
[22:47] <beta0x64> Interesting!
[22:47] <beta0x64> not really.
[22:49] <InHisName> Can a wireless router be configured to act more like a wireless switch ?
[22:49] <anduril> you mean as a repeater or range extender?
[22:50] <jedijf> access point
[22:51] <InHisName> No so same network in wan and out the ports.    i.e.  192.168.101.x   same as my main router assignments to other devices.
[22:51] <anduril> yes the netgears can be configured that way
[22:52] <InHisName> Is there a buzz word to search the pdf for ?
[22:53] <beta0x64> InHisName, what type of router is it?
[22:53] <anduril> are you hard wiring this router to your other router or you want it to grab wirelessly and broadcast that way?
[22:53] <InHisName> a, b, g, n    is that the answer you are seeking ?
[22:53] <beta0x64> InHisName, what exactly do you want to do? Describe your desired response. You may just want to mess with routing tables
[22:54] <jedijf> http://www.smallnetbuilder.com/lanwan/lanwan-basics/30740-how-to-use-a-router-to-add-network-ports
[22:54] <jedijf> InHisName: ^^^
[22:54] <anduril> If you're hardwiring your new router to your old one and using the old one as the DHCP server then disable the DHCP server on the Netgear unit and hardware it in. Otherwise if you're wanting to connect the netgear to your other router wirelessly then you need to go into Wireless Repeating Function and set it up there
[22:55] <InHisName> I have a linux box router -- then -- 16 port 100/10 switch   it want to attach wan to one of these ports and have IPs assigned by dhcp from same network (like a switch could do)
[22:56] <InHisName> I have read thru 70% of user manual so far.   Down into security stuff now.   Maybe it is after security and before index.
[22:57] <anduril> Ok I have the WNDR3400...go into LAN Setup, turn off "Use Router as DHCP server," change the Netgear 3700's IP address to something high in the range so it doesn't conflict with something else. Make sure its on the same subnet as your linux router
[22:58] <InHisName> Ok, starting to make sense with turning off.   I have a wndr3700.  Should be similar.
[22:59] <anduril> should be netgear changed the interface only on their new top halo model
[22:59] <anduril> they've get it the same otherwise since like ver 3 of the POS 614 brick model
[23:00] <jedijf> hey, i think i have that brick
[23:00] <anduril> :-p it wasnt until their last Linux model (dont remember exacty version but its the same as what I have now just without dual band) that I started recommending netgear again
[23:01] <anduril> I just hate how their admin page resets the router with the most triviol of changes. ticks the gf off to no end when Im messing around and boom goes the interwebs
[23:02] <InHisName> Lotta folks like the 3700, many like it better with ddwrt     I thought I'd try with supplied sw first then think about changing.
[23:02] <jedijf> s/changing/bricking
[23:03] <anduril> just a word of warning if you're planning on using the USB port for sharing out a drive? Its SLOOOOOOOOW
[23:03] <InHisName> no, not really
[23:07] <anduril> hmm Im way down on firmware rev
[23:11] <InHisName> I was reading the setup manual,   I see the user manual has more useful info in it.
[23:12] <anduril> who reads the manual? :)
[23:13] <InHisName> I usually  read / skim to get the gist and get all running.   I'll probably FULLY read the security setup section.  I know too little and can't wing security.
[23:14] <anduril> there isnt too much to the security section really. Run WPA2 (you have to for decent N performance anyways) and thats that for the most part
[23:14] <anduril> unless you're planning on doing DMZ (which you wont if you're using it as an access point) or guest networks or port forwarding or the like
[23:14] <InHisName> do I need to use WPS at all ?  What does it stand for ?
[23:14] <anduril> thats the quick setup thing if I remember correctly
[23:15] <anduril> hit a button on the router and a button on the wireless card and it auto sets up or something. never used it
[23:15] <InHisName> I can skip it for manual setup ?
[23:15] <anduril> yup
[23:15] <InHisName> 'k
[23:15] <InHisName> dinner, l8tr
[23:16] <anduril> you'll probably also want to turn off NAT Filtering under WAN Setup but Im not 100% on that
[23:24] <rmg51> InHisName: did you ever figure out Pidgin?
[23:28] <rmg51> if you didn't here is the way to find preferences
[23:30] <rmg51> you need the buddy list to be visible
[23:30] <rmg51> if it's not there click on the envelope on the top panel
[23:31] <rmg51> Pidgin will show up there
[23:31] <rmg51> click on it and the buddy list will appear
[23:32] <rmg51> with it visible mouse over to the left top corner of the menu bar
[23:33] <rmg51> it will show Pidgin Internet Messenger
[23:34] <rmg51> when you mouse over it, it will change and show you four options
[23:34] <rmg51> Buddies, Accounts, Tools and Help
[23:35] <rmg51> click Tools-Preferences
[23:35] <rmg51> done
[23:36] <rmg51> and stop asking questions about Unity
[23:37] <rmg51> I don't want to boot into Unity unless I don't have any other choice :P
[23:50] <InHisName> ok I got buddy list to appear.     Looking for what set off the Tools-prefs    not seeing those choices, yet.
[23:52] <InHisName> Top left of WHOLE screen.   Uggh, keep forgetting it so way far away from the app.
[23:54] <rmg51> menu bar
[23:54] <InHisName> I'm in prefs now.  looking thru it.
[23:56] <rmg51> it's under logging
[23:57] <InHisName> I clicked it to see how it will do.
[23:59] <rmg51> your on your own from this point on
[23:59] <InHisName> Thanks     rmg51


[06:51] <kreign> hi, I'm trying to figure out what the upstart tool does on shutdown - eg. where the commands are defined that are run on shutdown
[06:52] <kreign> there's /etc/init for startup but I'm not seeing where eg. filesystems get umounted on shutdown
[11:15] <mbiebl> what distro?
[11:40] <djszapi> JanC there ?
[11:40] <djszapi> you tried last time to get the messages we discussed, can you remember ?
[11:41] <djszapi> KeyBuk told me it is because upstart cannot log to the kmsg and the proper daemons are not running during the boot-session to get those messages into the syslog.
[11:41] <djszapi> so I am trying to write a patch for upstart in order to be able to write into the kmsg for need.
[11:54] <djszapi> JanC: so it should fex. work after the startup.
[13:11] <SpamapS> kreign: shutdown happens on runlevel 0
[13:12] <SpamapS> kreign: most of it ist still handled in /etc/rc0.d
[13:12] <SpamapS> kreign: at least, in Ubuntu
[16:19] <gp5st> i'm here (http://upstart.ubuntu.com/index.html) where can i find a list of all directives for an upstart script? the wiki seems more technical and doesn't help:(
[16:20] <gp5st> but to the point, what i want to know is if there is respawn keyword, i've seen hints on other sites but i can't find one in the upstart page or man page
[16:29] <JanC> gp5st: read the init(5) manpage
[16:30] <gp5st> ah
[16:30] <gp5st> the (5) is what must have got me
[16:30] <gp5st> thanks:)
[16:30] <JanC> http://manpages.ubuntu.com/manpages/maverick/en/man5/init.5.html
[16:31] <gp5st> i found it, i was just doing man init before not man 5 init
[16:31] <gp5st> :)
[16:32] <JanC> there is a reference to init(5) at the bottom of init(8)  ;)
[16:33] <gp5st> i'm sure:)
[17:41] <kreignf> hi, I asked a question in here last night... does anyone know where the 'shutdown' time events are defined for upstart? eg. umount -a
[20:20] <JanC> kreignf: depends on how you or your distro configures it
[20:21] <kreignf> JanC, :| ok, so where would I look? this is on ubuntu.
[20:21] <kreignf> JanC, I've dug around a bit but can not find anything suggestive (eg. grep umount /etc/init/*)
[20:22] <JanC> somebody answered that earlier today:
 kreign: shutdown happens on runlevel 0
 kreign: most of it ist still handled in /etc/rc0.d
 kreign: at least, in Ubuntu
[20:24] <kreignf> SpamapS, ah, thank you mate. ;P
[20:24] <kreignf> JanC, didn't see it, passed out before I got a response. thanks.
[20:25] <kreignf> not sure how i missed that on looking myself
[20:29] <SpamapS> kreignf: its not very obvious honestly
[20:29] <SpamapS> /etc/init/rc.conf covers it tho
[20:29] <kreignf> SpamapS, I'm not so sure I like the... complexity... of upstart, vs. classic init, at this point. at least for a server.
[20:30] <kreignf> SpamapS, seriously hope the intent is to have an all-in-one start/stop mechanism.
[20:30] <SpamapS> kreignf: its the complexity of the hybrid implementation that makes most uneasy. As it gets more purely upstart.. it will seem more elegant. :)
[20:30] <kreignf> SpamapS, "sometimes it's set here and sometimes it's here" is not a good way to do it. :|
[20:30] <kreignf> SpamapS, right.
[20:30] <kreignf> SpamapS, I'm sure.
[20:31] <kreignf> still, I'd think startup and shutdown would be handled by upstart, at the least. you know, 'system' tasks.. not relegating umount to rc
[20:32] <SpamapS> I think that was the plan.. but the push in lucid was to get the bootup fast, not the shutdown. :)
[20:32] <kreignf> heh
[20:32] <SpamapS> and it actually works ok
[20:33] <kreignf> well I know where to stick my command then
[20:33] <kreignf> was kinda fading last night when I was looking into it
[20:33] <SpamapS> there is a need for some more synchronization .. there are races right now that can lead to the fs's not unmounting I'm afriad.
[20:33] <kreignf> not all cylinders were firing
[20:33] <kreignf> SpamapS, oh joy. :|
[20:33] <kreignf> SpamapS, where are the races?
[20:33] <kreignf> in upstart?
[20:33] <SpamapS> basically things that stop on runlevel [!2345] are not guaranteed to be stopped when fs's are unmounted
[20:34] <kreignf> ah
[20:34] <kreignf> eg. a long-terminating database process
[20:35]  * kreignf considers a lengthy sleep
[20:35] <kreignf> SpamapS, do the desktop guys push the ubuntu server direction quite a bit?
[20:35] <kreignf> ubuntu server is a nice thing
[20:35] <kreignf> (due to the newer kernel)
[20:36] <kreignf> just not sure i like the... process refinement?
[20:36] <kreignf> the resulting refinement is damn nice
[20:37] <SpamapS> kreignf: ubuntu is ubuntu .. server and desktop are just different "seeds"
[20:37] <SpamapS> kreignf: which affects the CD creation, and the length of security fixes.
[20:38] <kreignf> SpamapS, I don't recall sources.list having a definite "server" tag ; what determines the seed, to the mirror?
[20:38] <kreignf> or is it just a package selection that gets said support?
[20:38] <SpamapS> I would say.. realistically.. lucid is just now stabilized and tested enough that I'd want to roll something out on it.. 10.04.2 is out in a week or two.. it has a lot of little weird things fixed.
[20:39] <kreignf> SpamapS, yeah.
[20:39] <kreignf> SpamapS, been a bit long in the uptake IMO
[21:14] <kreignf> SpamapS, anything I can tell the kernel/upstart on boot to "tell me what you're doing!" ? I get "Starting /scripts/init-bottom... ; Done. Done. Finishing /scripts/init-bottom; Done - and then nothing
[21:14] <kreignf> just hangs there
[21:14] <kreignf> c-a-d reboots it
[21:14] <kreignf> but other 'n that I can't do much
[21:15] <SpamapS> kreignf: pass --verbose to the kernel
[21:16] <kreignf> SpamapS, hmm
[21:19] <kreignf> SpamapS, would that be akin to "ro verbose" or do you mean --verbose?
[21:19] <SpamapS> kreignf: at the end of the line in grub, add --verbose
[21:19] <kreignf> SpamapS, the line starting linux, I presume
[21:20] <kreignf> just not familiar with --verbose as an ammendum to kernel boot opts
[21:20] <SpamapS> its unknown to the kernel, so the kernel passes it along to upstart
[21:20] <kreignf> ah ok.
[21:20] <kreignf> cool.
[21:50] <kreignf> SpamapS, I'm getting some cryptic "init: hostname goal/state is start/stopping post-stop->waiting/etc." info here, and then it just hangs up /goes no further after "init: handling stopped event"
[21:52] <kreignf> SpamapS, going to paste the image up
[21:54] <kreignf> SpamapS, mind if I email you the image?
[23:33] <SpamapS> kreignf: the lines before 'handling stopped event' are probably more interesting :)
[23:33] <SpamapS> kreignf: what OS is this?
[23:35] <kreignf> SpamapS, ubuntu
[23:35] <kreignf> 10.04
[23:35] <kreignf> LTS
[23:36] <kreignf> SpamapS, that was a couple hours ago; I got by it. now I'm trying to figure out why the freaking modules I need aren't loading on boot (they're in /etc/modules) but load just fiiine on manual modprobe
[23:37] <kreignf> heh
[23:37] <kreignf> and it works on another system :P
[23:40] <SpamapS> kreignf: /etc/init/module-init-tools.conf
[23:42] <kreignf> SpamapS, so this is going to sound a bit cheap but I see something scroll by on intial boot 'failed' - but I'm not finding it in logs. it's directly before login starts.
[23:42] <kreignf> any idea where that'd be logged?
[23:42] <SpamapS> alt-f7
[23:42] <SpamapS> aka "the console"
[23:43] <kreignf> yey
[23:43] <kreignf> heh
[23:46] <kreignf> unfortunately it does not appear to scroll. meh.
[23:49] <SpamapS> kreignf: those should also end up in /var/log/boot.log
[23:49] <kreignf> yeah
[23:49] <kreignf> virtual console is slooow in vbox


[00:32] -queuebot:#ubuntu-release- New: accepted domdf-python-tools [amd64] (mantic-proposed) [3.4.0-1]
[00:32] -queuebot:#ubuntu-release- New: accepted node-clipanion [amd64] (mantic-proposed) [3.1.0+dfsg-1]
[04:37] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (focal-proposed) [0.193ubuntu4~20.04.1]
[04:40] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (jammy-proposed) [0.193ubuntu4~22.04.1]
[04:45] <vorlon> RAOF: thanks for the ubuntu-dev-tools accepts; also, hmph apparently I need to do some work to make it build on focal
[04:46] <RAOF> Heh. It didn't look like it would FTBFS ?
[04:51] <vorlon> yeah it's a python compat issue apparently
[05:05] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (focal-proposed/universe) [0.187~bpo20.04.1 => 0.193ubuntu4~20.04.2] (no packageset)
[05:08] <vorlon> RAOF: ^^ ftbfs fixed
[05:20] <RAOF> vorlon: You forgot `-v`?
[05:21] -queuebot:#ubuntu-release- New binary: sch-rnd [amd64] (mantic-proposed/none) [1.0.0-1] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: sch-rnd [s390x] (mantic-proposed/none) [1.0.0-1] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: sch-rnd [ppc64el] (mantic-proposed/none) [1.0.0-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-dev-tools [source] (focal-proposed) [0.193ubuntu4~20.04.2]
[05:24] -queuebot:#ubuntu-release- New binary: sch-rnd [arm64] (mantic-proposed/universe) [1.0.0-1] (no packageset)
[05:26] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (kinetic-proposed) [0.193ubuntu4~22.10.1]
[05:29] <vorlon> RAOF: is that actually required? I'm unclear on this
[05:30] <RAOF> Yeah, without the full changelog there won't be any SRU bugs to track.
[05:30] <vorlon> mmk
[05:30] <vorlon> RAOF: reuploaded
[05:32] -queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (focal-proposed/universe) [0.193ubuntu4~20.04.1 => 0.193ubuntu4~20.04.2] (no packageset)
[05:33] <LocutusOfBorg> vorlon, hello I tracked down https://launchpad.net/ubuntu/+source/llvm-toolchain-16/1:16.0.5-1~exp1 failure on ppc64el (regression)
[05:33] <LocutusOfBorg> I started on qemu/ppc64el/lunar, and it was fine.
[05:33] <LocutusOfBorg> then I updated binutils to mantic, and it is throwing:
[05:34] <LocutusOfBorg> root@Unimatrix08-Jammy:/llvm-toolchain-16-16.0.5# ./build-llvm/bin/clang
[05:34] <LocutusOfBorg> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[05:34] <LocutusOfBorg> Segmentation fault (core dumped)
[05:36] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (focal-proposed) [0.193ubuntu4~20.04.2]
[05:47] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (lunar-proposed) [0.193ubuntu4~23.04.1]
[05:55] -queuebot:#ubuntu-release- New binary: sch-rnd [riscv64] (mantic-proposed/universe) [1.0.0-1] (no packageset)
[06:00] -queuebot:#ubuntu-release- New: accepted sch-rnd [amd64] (mantic-proposed) [1.0.0-1]
[06:00] -queuebot:#ubuntu-release- New: accepted sch-rnd [ppc64el] (mantic-proposed) [1.0.0-1]
[06:00] -queuebot:#ubuntu-release- New: accepted sch-rnd [s390x] (mantic-proposed) [1.0.0-1]
[06:00] -queuebot:#ubuntu-release- New: accepted sch-rnd [arm64] (mantic-proposed) [1.0.0-1]
[06:00] -queuebot:#ubuntu-release- New: accepted sch-rnd [riscv64] (mantic-proposed) [1.0.0-1]
[06:01] <LocutusOfBorg> its gold, with bfd it works
[06:23] <juliank> Please reject  oem-stella.cmit-cooexy-meta/focal from NEW, there was some process issues and this should not have been uploaded
[06:33] <RAOF> vorlon: If you're still here - why did you upload debootstrap to lunar adding a Breaks on a version of ubuntu-dev-tools that doesn't apply to any version that's ever been in lunar?
[06:36] -queuebot:#ubuntu-release- Unapproved: rejected debootstrap [source] (lunar-proposed) [1.0.128+nmu2ubuntu1.2]
[08:03] -queuebot:#ubuntu-release- Packageset: Added linux-apfs-rw to kernel-dkms in jammy
[08:03] -queuebot:#ubuntu-release- Packageset: Added linux-apfs-rw to kernel-dkms in kinetic
[08:03] -queuebot:#ubuntu-release- Packageset: Added linux-apfs-rw to kernel-dkms in lunar
[08:03] -queuebot:#ubuntu-release- Packageset: Added linux-apfs-rw to kernel-dkms in mantic
[10:27] <RikMills> ubuntu-archive: if anyone has a chance to review ktextaddons in NEW that would be appreciated. needed to be able to update the KDE PIM stack in mantic to the latest current release
[10:28] <RikMills> LP: #2021510
[10:28] -ubottu:#ubuntu-release- Launchpad bug 2021510 in Ubuntu "[needs packaging] ktextaddons" [Wishlist, New] https://launchpad.net/bugs/2021510
[10:57] <rbasak> vorlon: I mean that git-ubuntu is good for handling packaging derived from eg. Debian syncs with which we maintain a delta, but the workflows aren't good when the packaging isn't derived from elsewhere. If an Ubuntu team maintains packaging that isn't derived, then gbp without git-ubuntu is probably easier.
[10:57] <rbasak> Which means that Vcs-Git would point elsewhere than git-ubuntu.
[10:57] <rbasak> I'd still like the team to accept MPs against the git-ubuntu branches eg. by rebasing as needed.
[10:58] <rbasak> But I think that best practice packaging for such packages would still use gbp or dpm or whatever, just the same as best practice in Debian.
[11:01] <schopin> rbasak: while I understand the reasoning, that sounds convoluted. If the package exists in Debian then use this Ubuntu-specific workflow, but if it's not in Debian then use the Debian workflow?
[11:09] <rbasak> schopin: sorry about that. git-ubuntu is intended to fill a gap - Debian's workflows (understandably) don't accomodate workflows for distributions that derive from them. The biggest issue being that Debian's workflow is determined per-package whereas Ubuntu does things per-team, so it's a pain to onboard Ubuntu developers who would need to understand a dozen different workflows and git-ubuntu
[11:09] <rbasak> unifies those derived packages' workflows nicely.
[11:10] <rbasak> So git-ubuntu focused on what was poor, and what wasn't poor was when you _aren't_ a derivative package, because Debian workflows already work well for thsoe.
[11:11] <rbasak> I'm sorry I can't solve all problems at once :-)
[11:13] <zhsj> ubuntu developers need to know the dozens of workflows in debian to submit a merge request (yeah we could just send debdiff, but hmm...)
[11:15] <schopin> I personally would be fine with using git-ubuntu for everything, even if it would be for some cases a regression vs a gbp/dpm/etc approach (and yes I'm aware of the contradiction of that statement vs my complaining about the lack of staging in the past ;) )
[11:18] <rbasak> schopin: staging is coming FWIW.
[11:19] <schopin> I know. BTW feel free to ping me if you need a tester for it.
[11:19] <rbasak> schopin: the first git-ubuntu commit can't be rich - that's an edge case bug that isn't a priority to fix. But after that, you can use git-ubuntu only if you really want. But there's no equivalent to uupdate or gbp import-orig for example.
[11:19] <schopin> Oh right, I actually encountered the issue of new upstream versions before.
[11:21] <rbasak> It's "just work" to implement all these missing things. But developers use so many different workflows it's difficult to reimplement equivalents of everything. I have to prioritise :-/
[11:21] <rbasak> Given that gbp and dpm exist, it seems appropriate to reimplement those workflows last.
[11:21] <schopin> ACK
[11:33] -queuebot:#ubuntu-release- Unapproved: linux-apfs-rw (jammy-proposed/universe) [0+git20220214+ds-2ubuntu2~22.04.1 => 0+git20220214+ds-2ubuntu2~22.04.2] (kernel-dkms)
[13:47] -queuebot:#ubuntu-release- Unapproved: ocsinventory-agent (jammy-proposed/universe) [2:2.8-2 => 2:2.8-2ubuntu1] (no packageset)
[14:05] -queuebot:#ubuntu-release- Unapproved: accepted carla [source] (jammy-backports) [2.5.5-0ubuntu1~bpo22.04.1]
[14:06] -queuebot:#ubuntu-release- Unapproved: accepted gallery-dl [source] (jammy-backports) [1.25.5-1~bpo22.04.1]
[14:36] <vorlon> RAOF: the breaks: would be relevant during upgrade from jammy if the user doesn't have -updates enabled
[14:37] <vorlon> LocutusOfBorg: are you filing a bug on binutils for the llvm-toolchain-16 regression?
[14:40] -queuebot:#ubuntu-release- New: rejected oem-stella.cmit-cooexy-meta [source] (focal-proposed) [20.04~ubuntu1]
[14:58] <LocutusOfBorg> vorlon, switching to bfd worked :D
[14:58] <LocutusOfBorg> so mayyyyyyyybe
[14:59] <LocutusOfBorg> WDYT?
[14:59] -queuebot:#ubuntu-release- Unapproved: mutter (lunar-proposed/main) [44.1-0ubuntu1 => 44.2-0ubuntu1] (desktop-core, desktop-extra)
[15:00] <vorlon> LocutusOfBorg: it's always good to have toolchain bugs documented :)
[15:05] -queuebot:#ubuntu-release- Unapproved: gnome-shell (lunar-proposed/main) [44.1-0ubuntu1 => 44.2-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
[15:22] -queuebot:#ubuntu-release- Unapproved: rejected glibc [source] (focal-proposed) [2.31-0ubuntu9.10]
[15:25] <tjaalton> why is ubuntu-drivers-common available on ppc64el.. test failing due to no pci devices around and blocking mesa migration on mantic
[15:26] <vorlon> xnox: your mk-sbuild test case in LP: #2020530 fails for me, I get mk-sbuild usage outut
[15:26] -ubottu:#ubuntu-release- Launchpad bug 2020530 in ubuntu-dev-tools (Ubuntu Bionic) "The debootstrap SRU to end all debootstrap SRUs" [Undecided, In Progress] https://launchpad.net/bugs/2020530
[15:26] <vorlon> xnox: ah, missing quotes around sbuild -c argument
[15:27] <vorlon> xnox: oh sorry that's not your test case that's the original bug description! lala
[16:52] <bdmurray> tkamppeter: the autopkgtest regression for libppd looks legitimate to me<EMAIL_ADDRESS>[17:23] <vorlon> RAOF: also the SRU bug was LP: #2020530
[17:23] -ubottu:#ubuntu-release- Launchpad bug 2020530 in ubuntu-dev-tools (Ubuntu Bionic) "The debootstrap SRU to end all debootstrap SRUs" [Undecided, In Progress] https://launchpad.net/bugs/2020530
[19:39] -queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [23.1.2-0ubuntu0~18.04.1 => 23.2-0ubuntu0~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[19:40] -queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [23.1.2-0ubuntu0~20.04.2 => 23.2-0ubuntu0~20.04.1] (core, edubuntu, ubuntu-cloud)
[19:40] -queuebot:#ubuntu-release- Unapproved: cloud-init (jammy-proposed/main) [23.1.2-0ubuntu0~22.04.1 => 23.2-0ubuntu0~22.04.1] (core, ubuntu-cloud)
[19:40] -queuebot:#ubuntu-release- Unapproved: cloud-init (lunar-proposed/main) [23.1.2-0ubuntu0~23.04.1 => 23.2-0ubuntu0~23.04.1] (core, ubuntu-cloud)
[19:40] -queuebot:#ubuntu-release- Unapproved: cloud-init (kinetic-proposed/main) [23.1.2-0ubuntu0~22.10.1 => 23.2-0ubuntu0~22.10.1] (core, ubuntu-cloud)
[19:42] <blackboxsw> rbasak: it's probably a bit late on your SRU day but I wanted to queue a review of unapproved queue for -proposed for cloud-init's ~quarterly SRU of cloud-init for 23.2 to B, F, J,K and L. This should be our last 5-series SRU review as we will drop SRUs direct to bionic in 23.3. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2023110
[19:42] -ubottu:#ubuntu-release- Launchpad bug 2023110 in cloud-init (Ubuntu) "sru cloudinit (23.1.2 to 23.2)" [Undecided, In Progress]
[19:43] <blackboxsw> if too late, I'll probably fall-forward to mr a-hasenack tomorrow on his SRU review day.
[20:20] <rbasak> blackboxsw: sorry, it is indeed way past my EOD
[20:20] <blackboxsw> no worries at all rbasak. take care have a good evenin'
[20:35] -queuebot:#ubuntu-release- Unapproved: mokutil (bionic-proposed/main) [0.3.0+1538710437.fb6250f-0ubuntu2~18.04.1 => 0.6.0-2~18.04.1] (core)
[20:41] -queuebot:#ubuntu-release- New binary: crowdsec [amd64] (mantic-proposed/universe) [1.4.6-4] (no packageset)
[20:52] -queuebot:#ubuntu-release- New binary: crowdsec [ppc64el] (mantic-proposed/universe) [1.4.6-4] (no packageset)
[20:53] -queuebot:#ubuntu-release- New binary: crowdsec [s390x] (mantic-proposed/universe) [1.4.6-4] (no packageset)
[20:53] -queuebot:#ubuntu-release- New binary: crowdsec [armhf] (mantic-proposed/universe) [1.4.6-4] (no packageset)
[20:55] -queuebot:#ubuntu-release- New binary: crowdsec [arm64] (mantic-proposed/universe) [1.4.6-4] (no packageset)
[21:04] -queuebot:#ubuntu-release- New: accepted crowdsec [amd64] (mantic-proposed) [1.4.6-4]
[21:04] -queuebot:#ubuntu-release- New: accepted crowdsec [armhf] (mantic-proposed) [1.4.6-4]
[21:04] -queuebot:#ubuntu-release- New: accepted crowdsec [s390x] (mantic-proposed) [1.4.6-4]
[21:04] -queuebot:#ubuntu-release- New: accepted crowdsec [arm64] (mantic-proposed) [1.4.6-4]
[21:04] -queuebot:#ubuntu-release- New: accepted crowdsec [ppc64el] (mantic-proposed) [1.4.6-4]
[21:59] -queuebot:#ubuntu-release- Unapproved: glibc (jammy-proposed/main) [2.35-0ubuntu3.2 => 2.35-0ubuntu3.2] (core, i386-whitelist) (sync)
[22:04] -queuebot:#ubuntu-release- Unapproved: accepted glibc [sync] (jammy-proposed) [2.35-0ubuntu3.2]
[23:27] <RAOF> vorlon: Ah, yeah, sorry I missed the bug in the .changes. But I'm still conufsed.
[23:28] <RAOF> I thought that we supported LTS->LTS upgrades, but intermediate releases needed to upgrade through the full chain (so you couldn't go jammy->lunar without going through kinetic, so the debootstrap update wouldn't be necessary)
[23:28] <RAOF> And also, if someone is upgrading from jammy -updates disabled, won't the upgrade also have -updates disabled, and so publishing debootstrap into lunar-updates doesn't help??
[23:40] -queuebot:#ubuntu-release- New binary: golang-github-crowdsecurity-go-cs-bouncer [amd64] (mantic-proposed/universe) [0.0.2-2] (no packageset)