[07:28] <tjaalton> infinity: back to work? xserver + drivers from ppa:canonical-x/x-staging can be copied to xenial now, bug 1547510 is green
[07:28] <infinity> tjaalton: Nah, it's 12:30am, not quite back to work yet. ;)
[07:28] <tjaalton> infinity: ah ok, your tomorrow then :)
[07:30] <tjaalton> hmm I'll add a pointer to the "remove these drivers" bug
[17:59] <tjaalton> infinity: so, copying the xserver bits.. ping me if you need me :)
[18:06] <tjaalton> uploading -wacom with a less silly version
[19:28] <infinity> cyphermox: Whee, another SRU?  Aren't you glad you took over multipath-tools?
[19:29] <cyphermox> thrilled.
[19:29] <cyphermox> there's likely to be another one after that too
[19:29] <cyphermox> otoh, there's SRUs because we're making it better
[19:29] <cyphermox> we're bound to hit a point where it works ;)
[19:57] <infinity> cyphermox: I'll believe it when I see it.
[19:58] <cyphermox> heh
[19:58] <cyphermox> believe me I won't mind when storage stuff will work.
[19:59] <cyphermox> after all, storage is good, and I hear some noises in my desktop pc that also sounds suspiciously like a hard drive that will fail soon.
[22:25] <flexiondotorg> infinity, It's all about the Base. No trouble?


[09:28] <henninge> Hi!
[09:28] <henninge> Welches ist der aktuellste API-Branch?
[09:29] <henninge> Ich will auf staging einen Stand bringen, der juju und API hat.
[09:29] <henninge> ups sorry, wrong window ;-)
[09:59] <dpm> hallo henninge! :-)
[11:08] <henninge> Hallo dpm! ;-)
[11:10] <dpm> henninge, long time no see, how's life?
[11:11] <henninge> dpm: very good, thanks. This is my first day of Urlaub, actually. :-D
[11:12] <dpm> henninge, nice, glad to hear all is well. I should of course remind you IRC is prohibited during holidays ;)
[11:13] <henninge> I know, Iknow. Still some loose ends to tie up but we leave tonight for Italy
[11:13] <henninge> dpm: How are you doing?
[11:13] <dpm> cool :)
[11:14] <dpm> henninge, doing well, no longer working full time on translations, I now work as App Development Liaison growing our app developer community :)
[11:14] <dpm> it's fun stuff
[11:18] <henninge> sounds cool


[07:32] <Starwind> Has anyone here used ubuntu with one of the Utilite computers?
[20:09] <sloppycode> evening people
[20:10] <sloppycode> gentleman ladies and others
[20:10] <sloppycode> anybody awake ?
[20:10] <sloppycode> thats a no then
[20:11] <ogra_> most of us jusr wait til an intresting question gets asked ...
[20:11] <ogra_> bah
[20:11] <k1l> most of us wait until someone without patience leaves before one can answer ;p
[20:12] <ogra_> heh
[22:10] <jnumm> hi, can anyone help with https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1264531
[22:10] <ubot2`> Launchpad bug 1264531 in inkscape (Ubuntu) "Segmentation fault on arm64 with command line SVG→PNG export" [Undecided,Confirmed]
[22:11] <jnumm> what can be done about it?


[00:36] <mup> PR snapcraft#4313 opened: environment: add build-on and run-on envvars for core18|20 <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/4313>
[08:39] <mup> PR snapd#12705 closed: Allow overriding the Chronical API URL <Created by Anonymous941> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/12705>
[11:45] <mup> PR snapd#12498 closed: cmd/snap: make local snap detection simpler and more permissive <Needs Samuele review> <Created by atomcult> <Closed by atomcult> <https://github.com/snapcore/snapd/pull/12498>
[11:50] <mup> PR snapd#12954 closed: gadget: relax gadget update checks <Run nested> <Run Nested -auto-> <Created by alfonsosanchezbeato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/12954>
[13:53] <mup> PR snapcraft#4286 closed: build(deps): bump pygments from 2.13.0 to 2.15.0 in /docs/.sphinx <Dependencies> <Python> <Created by dependabot[bot]> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/4286>
[13:57] <mup> Bug #2025651 changed: default Japanese font in snap apps is ugly <lunar> <mantic> <Snappy:Fix Released by gunnarhj> <language-selector (Ubuntu):Invalid> <https://launchpad.net/bugs/2025651>
[14:58] <mup> Issue snapcraft#4312 closed: failed when promote snap using option: --yes <Bug> <Created by boukendesho> <Closed by boukendesho> <https://github.com/snapcore/snapcraft/issues/4312>
[17:33] <mup> PR snapcraft#4282 closed: projects: Add support for custom data <Created by sergio-costas> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/4282>
[17:33] <mup> PR snapcraft#4308 closed: cli: use "_ALL_PROVIDERS" as for provider options <Created by rpjday> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/4308>
[17:48] <mup> Issue snapcraft#4231 closed: SNAPCRAFT_PROJECT_VERSION is empty if not explicitly set at top level <Bug> <Created by Hook25> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issues/4231>
[21:59] <mup> Issue snapcraft#4314 opened: Raise error when using `BUILD_FOR` envvars on multi-arch and unknown builds <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4314>


[00:42] <manchicken> Anybody know how to get a service using polkit to log?
[00:45] <manchicken> Actually, I guess this isn't even the polkit auth bit, it's just the dbus. I'm having a hard time figuring out how to get the dbus stuff to give me useful information. dbus-monitor doesn't give me anything when I look for the interface I'm trying to call.
[00:49] <sarnold> manchicken: have you seen d-feet? it may help
[00:50] <manchicken> sarnold: For some reason it didn't even occur to me that I could look for such a program.
[00:51] <manchicken> Here's what I used, though:  `dbus-monitor "interface=org.kubuntu.qaptworker2"`
[00:51] <manchicken> And then I have a piece of code which I know is resulting in a call to that interface, but it doesn't seem like it's making it through to dbus-monitor
[00:53] <slangasek> session or system bus? ttps://wiki.ubuntu.com/DebuggingDBus
[00:53] <slangasek> +h
[01:00] <sarnold> handy page! :) thanks slangasek
[01:06] <manchicken> I'm guessing it's session since it isn't a service which is running all the time.
[01:11] <slangasek> services on the system bus can be started on demand
[16:42] <xnox> wgrant: infinity: thanks for putting postal on manual, do you have magic powers to retry chroot problem / ppc64el things from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-4.9-trusty.html and http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
[16:43] <cjwatson> xnox: already on it
[16:43] <cjwatson> xnox: I put them on manual
[16:43] <xnox> cjwatson: thanks. ah ok =)
[16:47] <cjwatson> Turns out you can fail a lot of builds very quickly if you're just segfaulting all the time.
[16:56] <cjwatson> xnox: all done
[18:34] <Ampelbein> Is upstart supposed to take 7 hours to build? https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5731715 ;)
[18:37] <Logan_> oh dear
[18:37] <Logan_> definitely not
[18:37] <Logan_> I would kill that
[18:40] <Logan_> I just requested that in #launchpad
[19:36] <Noskcaj> Should i try and get a FFe for pavucontrol or just cherry pick the RC bug fix
[19:39] <Logan_> Noskcaj: depends on how many new features there are that could possibly cause regressions
[19:40] <Logan_> read the NEWS file or whatever
[19:43] <Noskcaj> Logan_, There's no changelog/news file, but the mailing list has http://paste.ubuntu.com/7057567/
[19:43] <Logan_> hmm
[19:44] <Logan_> at this point in the cycle, I'm sure you could get an FFe ACKed
[19:44] <Logan_> especially since it's unseeded
[19:44] <Logan_> try it, and if they deny it, cherry pick the bug fix
[19:44] <Logan_> Noskcaj: have you done a test build yet?
[19:45] <Logan_> also, see if it fixes any of the bugs at https://bugs.launchpad.net/ubuntu/+source/pavucontrol
[19:45] <Noskcaj> I was just updating my schroot now
[23:30] <Noskcaj> Laney, Mind if i package d-conf 0.19.91? It's bugfix only. http://ftp.gnome.org/pub/GNOME/sources/dconf/0.19/dconf-0.19.91.news


[13:36] <mgariepy> morning everyone
[14:33] <highvoltage> good morning
[15:03] <giorgos> someone who speaks greek??


[03:07] <bkerensa> c_smith: Might be seeing you tomorrow at the Salem Ubuntu Hour... Working out details but likely nathwill and I are taking our first road trip to evangelize Ubuntu outside of Portland tomorrow
[03:07] <bkerensa> :)
[03:07] <bkerensa> after Salem we have Eugene, Corvallis and the Coastal Towns :P
[08:55] <bkerensa> :(
[08:55] <bkerensa> sad news for a open source application coming next week :(
[16:12] <blkperl> bkerensa: whens the next event? we should have one that targets new users
[16:13] <bkerensa> blkperl: Good idea... Umm it would have to be next month... I'm stacked with events for the rest of the month
[16:13] <bkerensa> Let me discuss with nathwill tonight
[16:14] <blkperl> i have some ideas on what we should do based off some of the osbridge talks :)
[16:14] <bkerensa> blkperl: cool... Could you maybe shoot a e-mail to the mailing list with the ideas and just add subject "Ideas for New Users Event"
[16:15] <bkerensa> I'm very keen on having a new users event at FreeGeek especially
[17:27] <NTR> I might be able to head downtown Salem and attend
[17:28] <bkerensa> NTR: cool
[17:28] <bkerensa> cweber10: you coming tonight? Me and nathwill will be there
[17:29] <NTR> All depends if I can get off work in time. It is 6pm correct?
[17:29] <bkerensa> NTR: 6pm to 7pm yep
[17:55] <bkerensa> slangasek: are you down at Debconf?
[20:35] <slangasek> bkerensa: on my way to
[20:56] <c_smith> hello
[20:56] <c_smith> bkerensa, would a free host be sufficient if I wanted to have them host a znc server?
[20:57] <c_smith> there's dozens of them out there, might just be a matter of finding the right one. correct?
[21:02] <blkperl> bkerensa: yeah ill send it tonight
[21:03] <c_smith> blkperl, what area were you from? sorry, but my memory on things like this and names is shoddy at best.
[21:06] <blkperl> c_smith: portland (psu)
[21:10] <c_smith> ah, ok, thanks. like I said, my memory aint the best.
[21:23] <bkerensa> c_smith: no... you need a server with root access
[21:23] <bkerensa> blkperl: cool thanks
[21:23] <bkerensa> slangasek: have fun!
[21:26] <bkerensa> c_smith: the cheapest your going to be able to do that is for $19 a month
[21:26] <c_smith> alright. thanks for the info.
[21:26] <bkerensa> c_smith: but the Ubuntu Oregon ZNC likely wont be going anywhere it will just be moved to our physical server
[21:26] <bkerensa> c_smith: see you at 6pm
[21:26] <c_smith> hmmm. alright.
[21:26] <bkerensa> providing nathwill comes here at 4pm
[21:26] <c_smith> see you there.
[21:27] <c_smith> heh, hopefully it all works as planned. :)
[21:27]  * c_smith goes back to downloading his copies of Linux Journal
[22:03] <bkerensa> So that news I blurted about at 2am
[22:03] <bkerensa> http://techcrunch.com/2012/07/06/so-thats-it-for-thunderbird/
[22:03] <bkerensa> its now public
[22:03] <bkerensa> =/
[22:55] <cweber10> bkerensa: Yep will be there
[22:55] <c_smith> ohaithar, cweber
[23:26] <bkerensa> c_smith we are gonna run late nathwill got stuck in traffic
[23:29] <c_smith> alright. still have a bit of time before I leave myself.


[03:14] <tonyyarusso> Has anyone else noticed gecko rendering random parts of Gnome in the browser pane on Hardy lately?
[03:15] <DarkMageZ> gecko 1.8 or 1.9?
[03:16] <tonyyarusso> 1.9
[03:17] <DarkMageZ> composition running? (eg compiz, kwin with composition, metacity with composition?)
[03:17] <tonyyarusso> Fully up-to-date Hardy, happens in both Epiphany and Firefox.
[03:17] <tonyyarusso> No compositing (my card doesn't support it)
[03:17] <DarkMageZ> i'll try and replicate it ?
[03:19] <tonyyarusso> It's a bit intermittent, and I don't know what triggers it.    Hence the no compositing.  (ATI Radeon Mobility X300)
[04:01] <DarkMageZ> shouldn't you be on the fglrx driver :p
[04:03] <tonyyarusso> No - fglrx is even more broken.
[04:03] <shirish> hi guys
[04:03] <shirish> hi all has anybody tried icedtea-java7-plugin with FF3
[04:03] <tonyyarusso> I can't even boot half the time, and the other half it crashes while I'm working.
[04:04] <shirish> FF3b2+ to be more precise.
[04:04] <DarkMageZ> ouch, and it's a laptop so you've got no choice.
[04:05] <shirish> and if somebody knows how to get the plugin working with FF3
[04:07] <tonyyarusso> well, I should go to homework now, but maybe someone will have a bright idea
[04:07] <shirish> asac: you up buddy?
[04:08] <shirish> DarkMageZ: you have any idea about icedtea-java7-plugin?
[04:08] <DarkMageZ> shirish, nope. that's why i'm not helping.
[04:09] <DarkMageZ> tonyyarusso, i'll let ya know if i manage to replicate it here with fglrx on my ati 9600
[04:09] <tonyyarusso> DarkMageZ: okay, thanks
[04:10] <shirish> DarkMageZ: ok thanx
[08:50] <asac> \o/
[12:22] <asac> mono folks are just crap ... nobody answers in their channel :(
[12:24] <armin76> asac is back :D
[12:25] <asac> yeah ... at last :)
[12:26] <asac_resurrected> hehe
[12:27] <armin76> yay, now go fix bugs :P
[12:28] <armin76> btw, i know why ff doesn't work on hppa anymore
[12:28] <armin76> it fails to start with glibc-2.7
[12:28] <armin76> with 2.5 it works fine
[12:28]  * armin76 tries with ubuntu
[12:30] <asac_resurrected> mono is really my enemy no. 1 ... they are just crap. they don't allow you to write bindings in C(++) ... can you imagine that?
[12:31] <asac_resurrected> they include capability to call native functions directly ... but only if they are in in a shared lib
[13:04] <asac> Ubulette: looking at the seamonkey 2 branch it appears you figured out that you can just drop SOFTOKN ... fine
[13:04] <asac> did you revert the hacks in nss as well?
[16:39] <saivann> asac : Hi! Did you have any news from the person who makes mk locales for sunbird and lightning-extension? I did not receive a email from him yet.
[16:41] <asac> saivann: not yet. i will ping him tonight or latest tomorrow again. i think he said he wanted to work on mozilla translations on 1st feb :)
[16:41] <saivann> asac : Ho great, I'll stay ready to add this locale in this case :)
[19:26] <Ubulette> asac, yes, i've reverted nss. sm2 builds fine but is totally broken: Error: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIDocShellHistory.useGlobalHistory]"  nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)"  location: "JS frame :: chrome://global/content/bindings/browser.xml ::  :: line 647"  data: no]
[19:26] <Ubulette> Source File: chrome://global/content/bindings/browser.xml
[19:26] <Ubulette> Line: 651
[20:39] <asac> Ubulette_: yeah ... seamonkey trunk has no real stability yet i guess
[20:40] <asac> btw, i managed to bring up a gecko sharp binding using standalone glue!!!
[20:40] <asac> yeah :)
[20:40] <asac> what a mess
[20:41] <asac> uploaded to my ppa ... if that builds well, i will push it to hardy today ... then all rdepends in main should be fixed
[21:16] <Ubulette> asac, sm2 is no longer able to browser anything
[21:17] <asac> hehe
[21:19] <asac> Ubulette: most likely a packaging issue ... i have a build done as of yesterdays snapshot and it works
[21:19] <asac> http://people.ubuntu.com/~asac/sea.png
[21:20] <Ubulette> using my branch or from dist ?
[21:21] <asac> its just a build from cvs ... thats why i say "most likely a packaging issue"
[21:22] <asac> using current hardy nss/nspr ... did drop the SOFTOKN thing from ldap Makefile.client
[21:23] <asac> there are some tiny changes that i currently develop for xulrunner in the same source, but that shouldn't make any difference
[21:23]  * asac  updating trunk tree
[22:07] <asac> updated trunk works well as well :)
[22:13] <Ubulette> still no progress with bug 185178 :(
[22:13] <ubotu> Launchpad bug 185178 in libpng "Please sponsor libpng 1.2.24" [Undecided,New] https://launchpad.net/bugs/185178
[22:54] <Ubulette> asac, http://ubuntuforums.org/showthread.php?t=680865
[23:25] <Ubulette> asac, http://stompbox.typepad.com/photos/uncategorized/2008/01/27/img_0381.jpg
[23:29] <asac> Ubulette: fuck ... when did that happen :)
[23:30] <Ubulette> you were fixing nm
[23:30] <asac> yeah :)
[23:30] <Ubulette> http://stompbox.typepad.com/blog/2008/01/ahhh-dogfood.html
[23:31] <asac> hehe ... "trying to fix his networking" ... that laptop was jorge's :)
[23:32] <asac> thanks ... i would have missed that ;)
[23:32] <asac> especially since simple patchsystem just wiped 15 minutes of porting work i did to blam :(
[23:32] <asac> it didn't attempt to produce any diff at all :(
[23:34] <asac> but the pic is funn ... i mean i didn't notice that he took a photo


[08:14] <mup> Bug #1888413 changed: "Add a rack controller" instructions are wrong <MAAS:New> <https://launchpad.net/bugs/1888413>
[08:20] <mup> Bug #1888413 opened: "Add a rack controller" instructions are wrong <MAAS:New> <https://launchpad.net/bugs/1888413>
[08:26] <mup> Bug #1888413 changed: "Add a rack controller" instructions are wrong <MAAS:New> <https://launchpad.net/bugs/1888413>
[16:39] <mup> Bug #1888536 opened: named.conf.options.inside.maas reverts to default <MAAS:New> <https://launchpad.net/bugs/1888536>


[01:17] -queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.3.0-0ubuntu2 => 2:16.3.0-0ubuntu3] (openstack, ubuntu-server)
[01:18] -queuebot:#ubuntu-release- Unapproved: neutron (groovy-proposed/main) [2:17.1.0-0ubuntu2 => 2:17.1.0-0ubuntu3] (openstack)
[06:43] <cpaelzer> hi ubuntu-archive - is someone around to resolve the completed MIR https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1867198 by promoting libnginx-mod-http-geoip2 ?
[06:44] <RAOF> Hello! Let me check.
[06:55] <RAOF> Ah, yeah. component-mismatches hasn't been updated yet, but I can see update-excuses complaining.
[07:08] <RAOF> Wow, change-override takes a loooong time from here.
[07:09] <cpaelzer> is that just the distance from you to potentially slow servers or have we hit a special case?
[07:11] <cpaelzer> BTW RAOF I'D have another one to promote https://bugs.launchpad.net/ubuntu/+source/libmd/+bug/1915009
[07:11] <cpaelzer> It seems the day after the MIR meeting regularly is the morning where cases finally resolve to be promotable :-)
[07:11] <RAOF> I think it's just my latency to Launchpad, yeah.
[07:11] <RAOF> :)
[07:11] <cpaelzer> could you have a look for libmd as well to unblock libbsd ?
[07:20] <RAOF> I'm EOD now and need to go get someone, but I can look a bit later.
[07:20] <RAOF> (change-override ended up taking 11m)
[07:20] <cpaelzer> sure, enjoy your evening!
[07:21] <cpaelzer> someone else can pick it up later just as much
[09:40] <LocutusOfBorg> ubuntu-archive: can you please remove rust-argon2rs rust-png rust-tokio-current-thread on i386?
[09:40] <LocutusOfBorg> they have been probably left over the cleanup because only in proposed pocket?
[09:46] <Laney> LocutusOfBorg: what's the background?
[09:47] <LocutusOfBorg> librust-argon2rs+simd-dev/i386 has unsatisfiable dependency
[09:47] <LocutusOfBorg> librust-argon2rs-dev/i386 has unsatisfiable dependency
[09:47] <Laney> yes I can read excuses
[09:47] <LocutusOfBorg> when v_orlon removed i386 packages probably he only looked at stuff in release
[09:47] <LocutusOfBorg> not at stuff that was proposed-only pocket
[09:47] <LocutusOfBorg> the i386 binaries have been built in eoan
[09:47] <LocutusOfBorg> but the package never migrated so far
[09:48] <LocutusOfBorg> so nobody ever cared to NBS-proposed only cleanup it, and now that rust migrated this is the last blocker
[09:48] <Laney> I guess it won't come back with the next build
[09:48] <Laney> you checked the i386 list?
[09:49] <LocutusOfBorg> nope, do you want me to check into a ppa?
[09:49] <LocutusOfBorg> I usually ask v orlon to do such things, its like magic to me :)
[09:50] <Laney> nah, no need for that
[09:50] <Laney> here's the list: https://people.canonical.com/~ubuntu-archive/packagesets/hirsute/i386-whitelist
[09:51] <LocutusOfBorg> there are no rust-* packages in that list...
[09:51] <LocutusOfBorg> should we add some then?
[09:51] <LocutusOfBorg> I can say safely they should be leaf packages, because they are not even in release pocket...
[09:51] <Laney> no, not if they're not needed on i386
[09:52] <Laney> I mainly wanted (to teach you how) to check that the next build won't cause the same problem
[09:53] <LocutusOfBorg> mmm I usually do reverse-depends and rmadison to see if they are needed, looks like that link does it for me? :)
[09:54] <LocutusOfBorg> thanks a lot for sharing it, I hope somebody will eventually add all of them into a wiki
[09:54] <Laney> it's generated from germinate using update-i386-whitelist in ubuntu-archive-tools
[09:54] <Laney> wiki> please do it :>
[09:55] <Laney> now you know how it works, it's the best time
[09:55] <Laney> the removals are done
[09:56] <Laney> seb128: I was just trying to test your branch before landing it and now I wish the new question happened before asking for confirmation :p
[09:56] <seb128> Laney, you asked for that one :p
[09:57] <seb128> I added a print&exit(1) after the confirmation for testing
[09:57] <seb128> :)
[09:58] <seb128> hacky hacks :p
[09:58] <Laney> yeah I commented out the real call
[09:58] <Laney> still scary to press yes
[09:58] <seb128> thanks for the reviews btw!
[10:01] <LocutusOfBorg> thanks!
[10:34] <Laney> seb128: what do you think about https://paste.ubuntu.com/p/czcmBd7y37/ ?
[10:35] <seb128> Laney, wfm
[10:37] <Laney> cool
[10:39] <Laney> seb128: ok, pushed, you might want to mail the archive admins to ask them to re-pull their checkouts
[10:40] <seb128> Laney, ack, thanks again for the review and for the improvements!
[10:40] <seb128> & didrocks :)
[10:41] <Laney> np, cheers for the work there
[10:52] <didrocks> yw! I can update the wiki in the near future now :)
[13:59] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (focal-proposed) [3.6.13-2ubuntu1.5]
[14:15] -queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (focal-proposed) [0.10.2-0ubuntu<IP_ADDRESS>]
[14:15] -queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (groovy-proposed) [0.10.2-0ubuntu<IP_ADDRESS>]
[14:59] <Laney> good job I tested github jobs on autopkgtest staging
[14:59] <Laney> they were BROOOOOOOOOOOOOOKEN
[15:05] <doko> apw_, sforshee: are you aware that dh-systemd is NBS in hirsute? all linux packages still build-depend on that one
[15:51] <doko> rbalint: can we remove kerneloops in Ubuntu?
[15:56] <rbalint> doko, i'm ok with that, but i'd like to have kernel team's feedback LP: #1867338
[15:59] <doko> icey: please drop the dh-systemd b-d for the next nova upload
[15:59] <rbalint> ddstreet, could you please include LP: #1916485 in next systemd SRU round?
[16:00] <ddstreet> will do
[16:00] <icey> ack doko
[16:00] <doko> cpaelzer: please drop the dh-systemd b-d for the next postgresql-common upload
[16:01] <icey> doko: so I'm clear, it's just no longer needed?
[16:04] <doko> icey: yes, it's obsolete, integrated in debhelper
[16:04] <icey> ok, thanks!
[16:04] <icey> doko: it's committed to our git tree, will pick up for the next upload :)
[16:12] <cpaelzer> doko: ok I'll let myon know, any more details for me to make a case of it?
[16:13] <doko> cpaelzer: it's NBS
[16:45] <sforshee> doko: I've removed dh-systemd in our git trees, will be reflected in future uploads
[17:02] -queuebot:#ubuntu-release- New source: xwayland (hirsute-proposed/primary) [2:<IP_ADDRESS>2-0ubuntu1]
[17:49] <juliank> Laney: hooray :D
[17:50] <juliank> Laney: how are things looking for that branch?
[17:50]  * juliank is preparing massive APT srus (in number of changes, not in number of lines changed :D)
[17:50] <juliank> (ok maybe a lot of lines but mostly tests added I suppose)
[17:50] <Laney> juliank: getting nice
[17:51] <Laney> tomorrow I deploy it in prod-proposed-migration
[17:51] <Laney> and then if you hack /etc/hosts you might be able to use it "for real"
[17:51] <juliank> oh boy that's exciting
[17:51] <Laney> I feel bad about the big/long handling
[17:51] <Laney> those should be outside of the charm config I think
[17:52] <Laney> like auto deployed somehow
[20:02] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (groovy-proposed/main) [4.4.1-2.1ubuntu9 => 4.4.1-2.1ubuntu10] (core)
[23:13] -queuebot:#ubuntu-release- Unapproved: openbox (groovy-proposed/universe) [3.6.1-9 => 3.6.1-9ubuntu<IP_ADDRESS>] (no packageset)
[23:15] -queuebot:#ubuntu-release- Unapproved: openbox (focal-proposed/universe) [3.6.1-9 => 3.6.1-9ubuntu<IP_ADDRESS>] (no packageset)


[00:45] <directhex> when is a good time to break the world?
[00:45] <sebner> directhex: just before weekend!
[00:45] <directhex> i.e. when's the nearest alpha or whatevs being spun?
[00:46] <RAOF> directhex: Uploading 2.10?
[00:46] <RAOF> directhex: The next alpha's some weeks away.
[00:46] <directhex> RAOF: scheduling it, yes
[00:46] <directhex> RAOF: it means rebooting my bitcoin miner away from windows though. or i could use the work laptop
[00:46] <RAOF> 7th of July is alpha 2.
[00:47] <RAOF> If you want to break the world, now's a pretty good time.
[00:47] <directhex> agreed
[00:48] <cjwatson> yeah, it's OK
[00:48] <cjwatson> I expect Linux 3.0 will be breaking random bits of the world for a while too
[00:48] <directhex> cjwatson: the CDs will be oversize until the 2.10 transition is over, FYI
[00:48] <cjwatson> OK
[00:58] <directhex> no turning back now :o
[01:10] <directhex> cjwatson: it seems i (and i guess the mono group) lack the rights to upload cli-common. can it be added to the packageset?
[01:15] <stgraber> hmm, indeed, for some reason it's in the "core" package set
[01:16] <RAOF> directhex: If you need a sponsor for now, I'm happy to help.
[01:18] <directhex> RAOF: well, feel free to syncpackage it yourself from exp
[01:18] <RAOF> Will do.
[01:19] <directhex> s' largely your work anyway isn't it?
[01:19] <RAOF> Quite a lot of the changes will be, yeah.
[02:11] <kees> @pilot out
[02:14] <TheMuso> /c/c
[04:52] <broder> when did the patch pilots become unfriendly?
[04:59] <broder> ...huh. apparently a couple of months ago
[05:13] <lifeless> thats not the intent
[05:13] <lifeless> so perhaps raise that for discussion
[05:26] <pitti> Good morning
[05:27] <pitti> smoser: so that's the reason for it re-starting over and over? not the /dev/xconsole warning?
[05:27] <pitti> smoser: that would at least be a more appropriate behaviour of rsyslog :)
[05:27] <pitti> smoser: fine for me
[05:28] <stgraber> morning pitti
[05:34] <TheMuso> broder: How have they become unfriendly?
[05:34] <TheMuso> Hrm seems oneiric has some LVM troubles, and seems that logging out of any GNOME session is broken, at lesat for me.
[05:35] <TheMuso> broder: I'm interested because if I am appearing less friendly, I want to do something about it.
[05:35] <ajmitch> TheMuso: I think the topic used to have room for mentioning the friendly patch pilots
[05:36] <TheMuso> ah ok.
[05:36] <ajmitch> so I don't think it's any change in attitude, just in what fits in the channel topic :)
[05:40] <TheMuso> ah ok.
[06:01] <broder> TheMuso: yeah, sorry - what ajmitch said
[06:01] <broder> the people themselves are fantastic
[06:01] <TheMuso> ok then thats good.
[06:02] <broder> let's see...if i go and twiddle with...
[06:02] <broder> @pilot in
[06:02] <broder> @pilot out
[06:02] <broder> lame
[07:31] <didrocks> good morning
[07:55] <tkamppeter> pitti, hi
[07:55] <pitti> hello tkamppeter
[08:00] <tkamppeter> pitti, about CUPS, I have found out something about the problems with the USB URIs.
[08:01] <tkamppeter> pitti, the device IDs are absolutely the same when read out via usblp or via libusb.
[08:02] <pitti> tkamppeter: right, that's good (expected though); but I thought we don't have the original device IDs?
[08:02] <tkamppeter> pitti, the two usb backend versions have an inconsistency. The usblp backend removes a repetition of the manufacturer name in the MDL field of the ID, the libusb backend does not do so.
[08:03] <tkamppeter> pitti, this is a bug and can be fixed with a simple patch in the libusb backend.
[08:04] <tkamppeter> pitti, this would solve one of the three causes of differences which I showed to you yesterday.
[08:06] <tkamppeter> pitti, the other two, having no serial number with usblp and having a serial number with libusb and also having the "interface=1" in the URI are additional features of the libusb approach.
[08:07] <tkamppeter> pitti, dropping them would make the URIs absolutely equal, but we should not remove these features.
[08:10] <tkamppeter> pitti, a solution which does not require the user to have his printer turned on while updating CUPS would be to let the libusb-based backend be able to use the old URIs and this is not complicated to code, as the  code for that is in the patch which we dropped. I can create a simpler patch with only that code and the code also somewhat improved, to remove a possible cause for a segfault.
[08:11] <pitti> tkamppeter: I think making this work for printers which are turned on should cover most cases indeed
[08:11] <pitti> tkamppeter: right, I don't like dropping the interface=1 either, as it would again be an inconsistency with how upstream handles that, and also more error prone
[08:22] <tkamppeter> pitti, with the new patch the old URIs will simply be accepted by the new USB backend, allowing the user to print without URI migration. This will help all migrating users, as with using usblp before they could not have two printers of the same model connected when usblp did not reveal the serial numbers and they also could not have used all the interfaces of a multi-interface printer.
[08:22] <tkamppeter> pitti, warnings in error_log could tell that the URIs could be improved.
[08:26] <pitti> that sounds good
[08:26] <pitti> so new printers would use the full URIs, but the old ones keep working
[08:32] <didrocks> @pilot in
[08:40] <dholbach> good morning
[08:47] <tkamppeter> pitti, exactly that, new printers will use the full URIs, but the old ones keep working
[09:26] <tkamppeter> pitti, I have updated CUPS now with the new patch. Can you upload it, so that it gets more testing? Thanks.
[09:27] <pitti> tkamppeter: sure; thanks!
[09:40] <real_ate> hi all! I was hoping someone here could give me a bit of advice when it comes to shipping packages around into remote repositories
[09:40] <real_ate> our company is using ubuntu as a base for our next web application and we're building packages for the update/distribution/installation
[09:41] <real_ate> and we are using an automated build machine to build the packages... all this works... the problem is when we are trying to "ship" the packages
[09:41] <real_ate> our "repository" is located the VPS that is hosting our website
[09:42] <real_ate> but that machine is CentOS
[09:42] <real_ate> and is not likely to change. (bummer)
[09:43] <real_ate> and we can't make use of reprepro on that server so we are kinda stuck on how to get the packages up to the server and still maintain different "releases" on the server
[09:45] <real_ate> we have been building the repo every time from scratch on our build machine and then using scp to *overwrite* the repository. This works ok but because we are not using reprepro to get the packages in there and to maintain the lists and stuff it doen't clean up any unused packages
[09:45] <real_ate> and we are starting to get package sprawl, taking up too much disk space.
[09:45] <real_ate> Can anyone suggest a better way?  thanks in advance :D
[09:46] <geser> real_ate: can't you use reprepro on the build machine and rsync the "result" to your VPS?
[09:48] <real_ate> geser: no because we are dynamically provisioning the build machine on Amazon
[09:48] <seb128> if somebody wants to look at the cairo ftfbs that would be nice, I've no clue about it
[09:48] <seb128> https://launchpadlibrarian.net/73205652/buildlog_ubuntu-oneiric-i386.cairo_1.10.2-6ubuntu1_FAILEDTOBUILD.txt.gz
[09:49] <real_ate> geser: and for that to work it would have to be : Build Packages -> Copy old repo to the EC2 instance -> use reprepro -> copy back
[09:50] <real_ate> and we would be paying for transfer on both ends ;)
[09:50] <geser> real_ate: and the reason for not being able to use reprepro on the VPS are missing "debian" tools?
[09:51] <real_ate> geser: yes
[09:51] <real_ate> geser: we have found that there is debmirror in CentOS, but that has just the same problem
[09:52] <geser> real_ate: can't you create a small debian (or Ubuntu) chroot on your VPS to run reprepro?
[09:52] <seb128> hum, got sidetracked
[09:52] <seb128> so cairo fails on
[09:52] <seb128> "ccQQ5PqR.ltrans1.o:(.text+0x724): undefined reference to `pow'
[09:52] <seb128> collect2: ld returned 1 exit status"
[09:52] <seb128> but it has a -lm
[09:53] <seb128> it builds on a natty builder or in oneiric with gcc-4.5, not with gcc-4.6
[09:53] <real_ate> geser: eh...
[09:53] <real_ate> *thinks about this one*
[09:53] <seb128> changing the -lm order or adding some -L... to the libm.so directory doesn't make it build, not sure what's wrong
[09:54] <seb128> so if somebody has a clue of what is wrong I'm not saying no to know why ;-)
[09:54] <real_ate> geser: so that would mean that we would be runing the ubuntu binaries/libs under the centos 5.6 kernal right?
[09:54] <geser> yes
[09:55] <mjr> are there instructions for making alternate install disks (or more spesifically just the PXE kernel/initrd pair would suffice) for 10.04 LTS, or prebuilt ones with backported kernels from later releases?
[09:56] <real_ate> geser: ... its an interesting suggestion i have to hand it to you! :D real out of the box thinking
[09:58] <real_ate> geser: but we probably won't gain very much on space improvements
[09:59] <slangasek> seb128: I believe I have a bug report open against gcc-4.6 already for that
[09:59] <real_ate> we would have to dedicate a chunk of the disk to the ubuntu chroot, which we can't afford on this machine.
[09:59] <slangasek> seb128: bug #778292
[09:59] <seb128> slangasek, oh, thanks!
[09:59] <seb128> should -flto be turned off or something?
[10:00] <slangasek> seb128: best to ask doko; I only triaged the bug, I don't know what it means :-)
[10:01] <seb128> doko_, hey, what do you recommend for that gcc bug breaking cairo? should we wait a gcc fix or workaround it and how?
[10:02] <geser> real_ate: hmm, can you host your reprepro on one of your workstations and rsync the repository to your VPS?
[10:02] <geser> real_ate: how much disk space do you have available on the VPS?
[10:05] <real_ate> geser: we can't host the reprepro on any of our workstations. This is exactly the problem we are trying to get aroud
[10:06] <real_ate> :D
[10:06] <real_ate> geser: we have quite a large amount of stuff that needs to be built and uploaded
[10:07] <real_ate> and have a terrible (i mean really terrible) upload speed from the office
[10:08] <real_ate> we're talking about 1GB for a full upload of packages, which was taking about 6-12 Hours a pop, depending on the reliability of our connection
[10:09] <real_ate> geser: and its not a matter of not having enough disk space on the VPS, the problem is that we always deal with large files like this and if the repo can't be cleaned things will get out of control very quickly
[10:12] <doko_> seb128: either disable lto, or don't use --as-needed
[10:13] <seb128> doko_, ok, I will turn off --as-needed for now I think, it's the easier to do, thanks
[10:13] <cjwatson> directhex: I've added cli-common to the cli-mono set
[10:14] <cjwatson> broder: topic space is very limited, perhaps not the ideal place to express friendliness
[10:15] <directhex> cjwatson, ta
[10:16] <directhex> cjwatson, need to isolate the armel build failure now. sigh
[10:20] <didrocks> Amaranth: your 07_* patch didn't apply in c-p-m (no -p1 for your patch)
[10:29] <tkamppeter> "sudo lsusb -vvv" hangs on a built-in USB hub on my laptop, can one fix this without rebooting?
[10:33] <micahg> hi doko, I was wondering if you ever saw my question about a libreadline transition
[10:39] <cjwatson> doko_: I'd appreciate a quick look at http://bugs.debian.org/630006, if you have a moment; it's blocking d-i builds
[10:48] <pitti> tseliot: want me to look at bug 756163 ?
[10:48] <tseliot> pitti: yes, please, I really don't know what's going on there
[10:49] <pitti> ok
[10:56] <chrisccoulson> directhex, how familiar are you with the moonlight plugin? and do you know what the mozilla-specific parts of that plugin are used for? (ie, everything in plugin/firefox in the source tree)
[10:57] <directhex> chrisccoulson, i believe that stuff is largely obsolete nowadays, given the steady abandonment of the xpcom apis used by that code, in modern firefox
[10:57] <directhex> chrisccoulson, best bet is to speak to shana on gimpnet for a sane explanation
[10:58] <chrisccoulson> directhex, ok, thanks. i'm not sure if you saw https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033229.html , but i'm trying to figure out whether we can keep moonlight but just drop the mozilla-specific parts
[10:59] <chrisccoulson> as it's not really much code at all
[10:59] <chrisccoulson> i'll find shana and ask though. thanks!
[10:59] <directhex> chrisccoulson, i didn't see that. i'd definitely talk to andreia though. let me know what she says
[11:00] <chrisccoulson> thanks
[11:01] <directhex> chrisccoulson, relatedly, i know she did some work on gluezilla which is also affected by xulrunner removal. worth bringing that up too.
[11:02] <chrisccoulson> directhex, ok, will do. thanks
[11:04] <directhex> i think gluezilla was updated to work okay with ff4, but segfaults on garbage disposal due to some threading problem. personally i wanted a move to use webkit-sharp for the system.windows.forms.webbrowser control emulation (which is what gluezilla does) since it tends to break less frequently for embedding circumstances than moz
[11:05] <chrisccoulson> directhex, yeah. and mozilla embedding is going to be break quite frequently in the future. do you know if gluezilla uses gtkmozembed?
[11:06] <tkamppeter> pitti, thanks for the upload.
[11:06] <directhex> chrisccoulson, historically? probably. hence the desire to dump it for webkit-sharp.
[11:06] <chrisccoulson> directhex, ah, ok. the reason i asked is that gtkmozembed has actually been removed entirely now - https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion
[11:09] <tkamppeter> I have a problem with USB, seems that my Lenovo laptop is not compatible with the Oneiric kernel. Even directly after reboot "sudo lsusb -vvv" hangs and on the system console I get several message "usb 7-1: device descriptor read/64, error -110" and after some minutes I get "hup 7-0:1.0: unable to enumerate USB device on port 1". Anyone has an idea what happens?
[11:13] <real_ate> geser: turns out we can use reprepro over a mounted ssh, and moves happen server side! rockin! ;)
[11:14] <real_ate> we're currently investigating/testing
[11:17] <didrocks> dholbach: hey, seems I'm marked as "community" in most of merges and not in bold in http://reports.qa.ubuntu.com/reports/sponsoring/. However, I'm in the sponsor team, any idea what's missing?
[11:18] <dholbach> didrocks, the sponsoring overview does not know anything about "Community" AFAIK
[11:19] <dholbach> didrocks, ah
[11:19] <didrocks> hum, not sure why I'm not an Ubuntu Developer (neither in italic) :p
[11:19] <dholbach> it's "gedit (upstream)"
[11:19] <dholbach> at least that's the sponsoring overview understands it
[11:19] <didrocks> dholbach: oh ok :)
[11:20] <didrocks> weird: Merge into:lp:~ubuntu-desktop/gedit/ubuntu
[11:20] <dholbach> yes, that's an upstream branch
[11:20] <dholbach> it's not a source package branch
[11:20] <didrocks> not really :)
[11:20] <dholbach> well, in launchpad terms it is
[11:20] <didrocks> it's our desktop team branch :)
[11:20] <didrocks> right
[11:20] <didrocks> I'll add that as well in my report
[11:20] <dholbach> it's not ~<person>/ubuntu/<release>/<pkg>/<title>
[11:20] <seb128> the sponsoring queue only really understand udd merge requests
[11:20] <dholbach> I would prefer not to have to teach the sponsoring overview how the desktop team handles things in a special way
[11:21] <seb128> it doesn't even list other ones if you don't subscribe the sponsors
[11:21] <seb128> dholbach, that's fine, our version page lists our desktop merge requests ;-)
[11:21] <dholbach> great, thanks :)
[11:21] <seb128> it's better than your sponsoring page :p
[11:21]  * seb128 hugs dholbach
[11:21]  * dholbach hugs seb128 back
[11:23] <doko_> cjwatson: ok, looking at it today
[11:32] <mjr> was there instructions somewhere on building a 10.04 alternate installer kernel/pxe-initrd pair with a newer kernel (or prebuilt install images with later backported kernels)?
[11:37] <cjwatson> doko_: thanks
[11:37] <cjwatson> mjr: is this an Ubuntu kernel from -proposed or -updates or something, or a custom one?
[11:41] <mjr> an lts-backport kernel would be fine
[11:43] <mjr> just need a bit of extra hardware support at install-time
[11:44] <mjr> (extra as in supported in newer kernels out of the box)
[11:48] <cjwatson> mjr: basically you need to get the debian-installer source package, change build/config/<architecture>.cfg to have the kernel version + ABI number you want to use, and debuild -b
[11:49] <mjr> okay, sounds like a proper starting point, thanks
[11:49] <cjwatson> if it's not in one of the sources d-i looks in by default, you might need to run 'util/gen-sources.list.udeb' in build/, then copy sources.list.udeb to sources.list.udeb.local and edit it
[11:52] <cjwatson> is somebody other than me processing syncs?  I was in the middle of some
[11:54] <cjwatson> didrocks: ^-
[11:54] <didrocks> cjwatson: yeah, I was as well, sorry
[11:54] <cjwatson> I flushed the ones I was doing individually, so you can go ahead now
[11:55] <didrocks> cjwatson: ok thanks, finishing those I was heading to :)
[11:55] <cjwatson> (I did agda-bin and nautilus-dropbox)
[11:55] <didrocks> oh ok, removing agda-bin then
[12:09] <didrocks> @pilot out
[12:23] <TLE> pitti: Hallo. Thanks for the email. I was wondering.
[12:26] <siretart> chrisccoulson: yes?
[12:34] <TLE> pitti: Is there any special kind of testing that should be done, now that there has been this infrastructure change for firefox?
[12:34]  * dholbach hugs didrocks
[12:34] <TLE> testing l10n-wise I mean
[12:34]  * didrocks hugs dholbach back :)
[12:34] <dholbach> :)
[12:56] <pitti> TLE: just that translations still work; the new langpacks should pull in firefox-locale-*
[12:57] <TLE> pitti: ok thanks
[13:44] <doko_> cjwatson: libffi udeb in NEW
[13:48] <kenvandine> @pilot in
[14:18]  * dholbach hugs kenvandine
[14:19]  * kenvandine hugs dholbach
[14:19] <dholbach> :)
[14:26] <cjwatson> doko_: thanks, will look
[14:28] <cjwatson> doko_: I'm afraid that's wrong - Pre-Depends: multiarch-support is unsatisfiable in d-i
[14:28] <cjwatson> doko_: installing to /usr/lib/$(DEB_HOST_MULTIARCH)/ is fine, but you need to drop the Pre-Depends
[14:29] <cjwatson> (for the udeb)
[14:50] <brendand> mvo - i just put this branch for review https://code.launchpad.net/~brendan-donegan/update-manager/bug791548_networkmanager0.9/+merge/64185
[14:50] <brendand> ignore ubottu
[14:50] <mvo> brendand: its reviewed and merged already, many thanks!
[14:51] <brendand> mvo - perhaps you're thinking of a different one?
[14:51] <brendand> mvo - this one is for the NM problem in O
[14:53] <seb128> hum, kvm sit on the plymouth logo eating cpu when trying to boot isos in oneiric and usb-creator keeps spinning on disk erase and doesn't offer the create a disk on start
[14:53] <seb128> that's going to be interesting to try an iso :p
[14:53] <brendand> mvo - thanks. lp just took a bit :)
[14:54] <mvo> brendand: great!
[14:54] <doko_> cjwatson: hmm, lintian complains about it
[14:55] <doko_> and this is a check, which is enforced by ftp-master
[14:57] <dholbach> if somebody has a bit of time to review pad.lv/mps/ubuntu-sponsoring that'd be nice :)
[15:04] <cjwatson> doko_: totally a lintian bug.  it's overridable, so override it for now and I'll get it fixed in lintian
[15:05] <doko_> ok
[15:06] <doko_> cjwatson: hmm, how is the override file called for an udeb?
[15:07] <cjwatson> oh, that's annoying
[15:08] <cjwatson> same as usual, but it's cruft that shouldn't be in a udeb :-/
[15:08] <cjwatson> /usr/share/lintian/overrides/libffi6-udeb
[15:08] <cjwatson> doko_: alternatively, just don't make the udeb multiarch
[15:08] <cjwatson> there's no particular need for it
[15:09] <cjwatson> that might be better for the momeent
[15:09] <cjwatson> *moment
[15:14] <cjwatson> doko_: fixed in lintian.git, anyway, but it'll take a while for that to be deployed on ftp-master so I think just not making the udeb multiarch is the most straightforward answer
[15:16] <DktrKranz> cjwatson: if that turns to be a blocker, we could see to speed things up. It requires a lintian upload, though.
[15:17] <abhinav-> dholbach: your blog is timing out while loading. cannot open the links posted on fb and twitter
[15:18] <cjwatson> DktrKranz: shouldn't be a blocker, I hope; no udeb ever actually needs to be multiarch
[15:18] <cjwatson> (at least at the moment)
[15:18] <cjwatson> (but thanks)
[15:24] <dholbach> abhinav-, it works for me
[15:25] <dholbach> abhinav-, nigelb had a similar problem yesterday - can you traceroute it and see how far you get?
[15:25] <abhinav-> dholbach: sure
[15:30] <abhinav-> dholbach: it times out after 10 hops. would you like to see the output of traceroute ?
[15:30] <dholbach> abhinav-, what's the last hop?
[15:31] <abhinav-> dholbach: so-1-3-0.0.pjr01.ldn001.flagtel.com (<IP_ADDRESS>)  340.677 ms  341.246 ms  342.055 ms
[15:31] <dholbach> for nigelb yesterday it was "so-1-3-0.0.pjr01.ldn001.flagtel.com (<IP_ADDRESS>)"
[15:31] <dholbach> aha, interesting - seems you have a similar route and something goes wrong there :-/
[15:31] <nigelb> abhinav-: airtel?
[15:32] <abhinav-> yes
[15:32] <nigelb> dholbach: Our ISPs are the same.
[15:33] <dholbach> I'm sorry, there's not a lot I can do about it
[15:34] <stgraber> well, I guess that blog post will appear on Planet Ubuntu if it's not already there
[15:34] <stgraber> so you can probably read from there instead
[15:35] <stgraber> though you'll be missing the comments
[15:36] <nigelb> stgraber: I just socks proxy through my VPS :-)
[15:36] <stgraber> that works too :)
[15:36]  * stgraber wonders how many people know of ssh's "-D" parameter ;)
[15:39]  * nigelb uses is every so often :D
[15:49] <doko_> cjwatson: re-uploaded, now afk
[15:51] <cjwatson> doko_: thanks
[16:10] <cjohnston> !regression-alert  bug 795520  <-- I was told to do that ;-)
[16:13] <jdstrand> cjohnston: fyi, that bug is private, which is why ubottu can't deal
[16:14] <jdstrand> cjohnston: afaict, there is nothing in the bug that should be kept private...
[16:14] <cjohnston> jdstrand: I wasn't sure, so when I started attaching things, I marked it private
[16:15] <cjohnston> its not private anymore
[16:15] <jdstrand> cjohnston: feel free to use regression-alert again
[16:15] <cjohnston> !regression-alert  bug 795520
[16:15] <cjohnston> now what did i do wrong
[16:16] <cjohnston> no pioe?
[16:16] <cjohnston> pipe
[16:16] <cjwatson> cjohnston: there's no such version of bcmwl published in any Ubuntu release
[16:16] <cjwatson> <IP_ADDRESS>+bdcom-0ubuntu3, but not <IP_ADDRESS>+bdcom-0ubuntu3.1
[16:16] <cjwatson> ah, it was already deleted from natty-proposed
[16:16] <charlie-tca> maybe without the bug? or since it is a bot command, with the | between the command and bug
[16:16] <cjwatson> "bad SRU"
[16:19] <jdstrand> charlie-tca, cjohnston: I think !regression-alert should be on it's own. then describe it after.
[16:19]  * jdstrand updates wiki
[16:19] <cjohnston> I was just given the first part in a PM, so I was trying to make it work.. I guess I got attention anyway.. heh
[16:22] <seb128> cjwatson, pitti, hum, the new lsb version built with python3 witll had an almost 6mb to the cd tomorrow :-(
[16:23] <pitti> ah, it's hte first package to pull in python 3?
[16:23] <cjohnston> cjwatson: is there anything I can do to fix my system with it being deleted?
[16:23] <seb128> pitti, yes
[16:24] <cjwatson> cjohnston: 'sudo apt-get install bcmwl-kernel-source/natty' ought to do it
[16:25] <cjwatson> seb128: hmm, I wonder if this is doko committing to python3 for oneiric.  Let's not worry too much about it immediately
[16:25] <seb128> cjwatson, ok
[16:25] <cjohnston> no errors...
[16:29] <cjohnston> That worked.. I have wireless again.. Thanks cjwatson
[16:41] <jelmer> cjwatson, hi, still there?
[16:42] <cjwatson> jelmer: hi
[16:43] <jelmer> cjwatson: I proposed an SRU for bzr, with ~ubuntu-sru subscribed to the merge proposal
[16:43] <jelmer> cjwatson: Is that sufficient, or should I find a related but and subscribe ~ubuntu-sru to that as well?
[16:44] <cjwatson> I have no idea how the tracker will cope with that
[16:44] <cjwatson> you want pitti for that
[16:44] <jelmer> cjwatson: ah, thanks
[16:44] <jelmer> pitti: hi
[16:51] <seb128> jelmer, they work the reverse way
[16:52] <seb128> jelmer, ubuntu-sru doesn't do sponsoring, they review things in the queue and go back to the bug to read it and accept the upload
[16:52] <seb128> jelmer, so if you need your work to be uploaded you should subscribe ubuntu-sponsors
[16:53] <seb128> jelmer, ideally you would need a bug with the merge proposal also, the sru tracking list bugs and you need a place where testers can comment on whether the update works or not
[16:53] <cjwatson> apw: so, notwithstanding your comments in -meeting, I think at least fixing eglibc would be a pretty good plan.  how about http://paste.ubuntu.com/623518/?  tested out of context ...
[16:54] <cjwatson> (in particular I think we should resolve eglibc problems before accepting the kernel through NEW)
[16:54] <apw> cjwatson, absolutly on the NEW thing
[16:54] <apw> cjwatson, i am not sure that $(( works with 0NN as i think that switches it into octal
[16:55] <jelmer> seb128: bzr has a microrelease exception; there will usually be zero or more bug reports related
[16:55] <apw> i t
[16:55] <cjwatson> apw: I'm not relying on that
[16:55] <apw> s/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/;
[16:56] <cjwatson> the effect of the added first sed statement is to transform 3.0-0.1 into 3.0.0-0.1
[16:56] <apw> does that not take 2.6.39 -> 2.6.039 ?
[16:56] <cjwatson> no, because [^.0-9] doesn't match in the relevant place there
[16:56] <seb128> jelmer, ok, well pitti left for the w.e already he will be back on tuesday, but from what I can say usually they need at least one bug to list on the tracker, so if your update close no launchpad bug you should open one about the new version
[16:56] <apw> ahh misses the ^, re's suck for reading
[16:56] <cjwatson> I did test that bit :)
[16:56] <seb128> jelmer, so you have at least one bug reference in the changelog for the tracker
[16:56] <cjwatson> <cjwatson@sarantium ~>$ echo $(($(echo "2.6.39-1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\?.*/\1 \* 10000 + \2 \* 100 + \3/')))
[16:56] <cjwatson> 20639
[16:56] <cjwatson> <cjwatson@sarantium ~>$ echo $(($(echo "3.0-1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\?.*/\1 \* 10000 + \2 \* 100 + \3/')))
[16:57] <cjwatson> 30000
[16:57] <apw> cjwatson, that look sane then yes, though there is another place it errors due to format
[16:57] <cjwatson> ok, where's that?
[16:58] <cjwatson> oh yes, I see
[16:58] <apw> cjwatson, about line 286 of the preinst
[16:58] <seb128> cjwatson, "  * desktop-o-gtk3-gnome3: ubiquity mostly converted to PyGI, though blocked on porting a custom widget (timezone map)"
[16:58] <jelmer> seb128: I have that, but do I subscribe ubuntu-sru to all the related bugs, to just the MP?
[16:58] <cjwatson> I wonder where the built-in assumptions in glibc it's referring to are
[16:59] <seb128> ev, cjwatson: dunno who is working on that but did you talk to mterry about it? he wanted to do a C library for that widget and has been discussing that upstream with the GNOME guys
[16:59] <cjwatson> seb128: I was just reporting what ev said
[16:59] <seb128> ev, cjwatson: if that's done the lib could probably just build a gir to use
[16:59] <apw> cjwatson, i was trying to find them, but ... not found as yet
[16:59] <cjwatson> apw: sysdeps/unix/sysv/linux/dl-sysdep.c
[16:59] <seb128> cjwatson, ok, I will check with ev, thanks
[16:59] <ev> ah yes, I hadn't considered that
[16:59] <ev> stupidly
[16:59] <ev> will go down that road instead
[17:00] <ev> thanks seb128
[17:00] <mterry> ev, cjwatson, seb128: upstream is going to do some sort of map library, but it likely won't have our geonames timezone completion logic.  So we can patch it in when they have something
[17:00] <cjwatson> so that looks to me as though glibc will treat 3.0 as 3.0.0
[17:00] <apw> cjwatson, that would be appropriate
[17:01] <apw> cjwatson, yeah concur that it does assume all and any part is 8 bits max, but the build only checks that 3rd
[17:01] <apw> cjwatson, so are you going to fix those two in the package ?  so i don't need to look any more ?
[17:01] <cjwatson> right.  I think it's reasonable enough for it to only check the last one, which is the only one people typically fiddle with
[17:02] <cjwatson> yeah, I think I can deal if that's OK with you, but review is good
[17:02] <apw> cjwatson, yep let me have the changes and i can review np
[17:02] <cjwatson> can't easily test it here but don't want to have to fix it twice
[17:02] <apw> i can cirtainly test it if i can figure out how to un-half install the broken version on my machine here
[17:03] <cjwatson> er, you might need to fiddle the new preinst into place in your .deb using ar and tar
[17:03] <apw> i upgraded with a 3,0-0.1 kernel installed on my oeniric and its half installed and refusing due to that change
[17:03] <apw> cjwatson, ouch ... ok
[17:03] <cjwatson> I can provide instructions once I'm finished
[17:03] <apw> where is the .deb its using in archive ? ... ok will await those :)
[17:04] <cjwatson> http://paste.ubuntu.com/623531/
[17:06] <cjwatson> make a temporary directory, cd to it, 'cp /var/cache/apt/archives/libc6_* .'
[17:06] <debfx> how do we deal with ppa packages that cause issues likes file overwrite conflicts? e.g. bug #748715
[17:07] <james_w> charlie-tca, hi, I hear that you get blank pages on status.ubuntu.com. Is that correct?
[17:09] <ogra_> james_w, do you own that ?
[17:09] <cjwatson> ar x libc6_*; gunzip control.tar.gz; tar xf control.tar; apply patch to preinst; tar rf control.tar ./preinst; ar r libc6_* control.tar.gz
[17:09] <james_w> ogra_, I'm involved
[17:09] <cjwatson> then dpkg --unpack libc6_*; dpkg --configure -a
[17:09] <cjwatson> I think that should work
[17:09] <cjwatson> WARNING NOT GENERALLY SANE
[17:09] <ogra_> james_w, do you know if there is a particular reason the arm team isnt on there ?
[17:10] <james_w> ogra_, nope
[17:10] <james_w> ogra_, in the teams list?
[17:10] <ogra_> yeah, how do i get ubuntu-armel added ?
[17:11] <james_w> ogra_, ask cjohnston for now
[17:11] <apw> cjwatson, ok on it
[17:11] <ogra_> k
[17:13] <cjwatson> apw: (this results in a control.tar.gz with two preinst files, but dpkg uses the second which is what we need here)
[17:14] <apw> cjwatson, well its progressing
[17:15] <apw> here goes nothing
[17:18] <apw> cjwatson, ok those fixes look fine to me, test fine in isolation and worked to allow me to finish the package installation
[17:18] <cjwatson> excellent, forwarding to Debian and will upload
[17:19] <apw> cjwatson, i will go look at PS which is producing much vile whining
[17:19] <cjwatson> PS?
[17:19] <cjwatson> ah, procps
[17:21] <apw> yeah, ps and top are both whining same message
[17:21] <apw> any idea where the lightdm/gdm choice is made ?
[17:23] <apw> ahh found it /etc/X11/default-display-manager
[17:40] <apw> anyone got working networking on oneiric ?
[17:41] <tumbleweed> yes
[17:46] <apw> cjwatson, procps seems to be easy to fix, simple one line change.  I've pushed a bzr branch with it on, but as its a 3,.0 (quilt) we're back to the question as to whether one should have the .pc etc in there; perhaps you could review: lp:~apw/procps/kernel-version-fix
[17:47] <cjwatson> apw: there's no question, you match whatever the branch currently does
[17:47] <apw> cjwatson, well its the importer, so it does what it wants
[17:47] <cjwatson> yes.  so match it.
[17:48] <cjwatson> I think your commit matches its behaviour except that it doesn't normally add the .timestamp file, IIRC
[17:48] <cjwatson> (for better or worse)
[17:48] <cjwatson> and actually it doesn't add .pc/.quilt_patches or .pc/.quilt_series either
[17:48] <apw> ahh ok, i'll delete those
[17:49] <cjwatson> I think that's a discrepancy between what happens when you apply patches with quilt and what happens when dpkg-source unpacks the package on a system without quilt installed
[17:49] <montaj> hey guys
[17:49] <montaj> i have a question regarding bug #791467
[17:49] <montaj> it appears that gcdmaster is needed to build cdrdao
[17:49] <cjwatson> apw: otherwise looks fine
[17:49] <montaj> what is the way to procees in this case, attach a patch of the control file to the bug or build a new package and ask somebody to sponsor it?
[17:52] <montaj> I would very grateful if somebody could point me on how to proceed to fix the regression
[17:53] <apw> cjwatson, ok updated with those removed, perhaps you could do the honours if it looks ok
[18:10] <ScottK> montaj: If you know how to fix it, attach a patch and then subscribe the ubuntu-sponsors team to the bug and someone will review it.
[18:31] <kenvandine> @pilot out
[18:47] <cjwatson> apw: merged, thanks, uploading (eglibc also uploaded a while back)
[18:47] <cjwatson> binaries will take a bit
[18:49] <cjwatson> apw: heh, you forgot to add debian/patches/ubuntu-handle-short-kernel-versions.patch - I'll fix it up
[18:49] <cjwatson> and the change to debian/patches/series too
[18:52] <cjwatson> apw: fixed up and uploaded now
[18:59] <apw> cjwatson, i am hopless sometimes, thanks
[20:17] <chrisccoulson> directhex, i just tried building moonlight here, and it fails right at the end. not sure if you can provide any insight for this error:
[20:17] <chrisccoulson> dh_clideps: Could not resolve moduleref: moon for: mscorlib.dll!
[20:17] <chrisccoulson> or anyone else for that matter :)
[20:18] <directhex> chrisccoulson: hm. probably a use-case we didn't consider for cli-common 0.8
[23:36] <ohsix> hm is something else being done with firefox this (natty) cycle? ff5 beta just showed up
[23:38] <micahg> ohsix: that's in -proposed and natty will follow the new mozilla release cycle immediately
[23:38] <ohsix> ok cool
[23:39] <cjwatson> ohsix: http://askubuntu.com/questions/48035/why-is-natty-proposed-suggesting-an-upgrade-to-a-beta-version-of-firefox
[23:39] <ohsix> will it leave proposed after the release or is it just going to soak a bit like most things in -proposed
[23:40] <micahg> ohsix: yes, it will actually be replaced with the release build next week sometime and migrate to -updates/-security on release day (hopefully)
[23:40] <ohsix> ok cool ya that's what the post said; thanks guys


[00:20] <hatch> sorry it was kind of a lot of rewrite
[00:20] <hatch> and lacking inline docmentation
[00:35] <hatch> this is correct
[00:35] <hatch> good catch
[00:35] <hatch> :)
[00:35] <hatch> so in your oppinion am I doing this right? Nothing else I've done has the python.js augmenting the data
[00:35] <hatch> so it kind of breaks the flow
[00:39] <hatch> ok glad you think so
[00:39] <hatch> because I was unsure it was the right approach


[06:23] <tjaalton> LocutusOfBorg: hi, ideas how to fix 1829034?
[06:23] <tjaalton> bug 1829034
[06:26] <tjaalton> looks like conflicts/replaces aren't properly set on the backport..
[06:45] <seb128> sbeattie: hey, pointing that bug in case you didn't see it/it's interesting, bug #1829245 claims to be a regression from the recent security upload
[06:51] <cpaelzer> seb128: he's off now - but I subscribed him and others
[06:53] <seb128> cpaelzer: thx
[10:01] <rbasak> ddstreet: thank you for raising the sudo/HOME question on ubuntu-devel-discuss@
[10:01] <rbasak> ddstreet: FWIW, ubuntu-devel@ would have been fine. https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel says "Discussions seeking consensus among Ubuntu developers" is on-topic.
[10:32] <ddstreet> rbasak i think user input is fairly important for this change as much as developer input, which is why i chose -discuss
[11:02] <rbasak> ddstreet: fair enough
[11:20] <xnox> bdmurray:  please purge resolvconf from your system. and use resolved only.
[11:58] <LocutusOfBorg> tjaalton, https://salsa.debian.org/pkg-llvm-team/llvm-defaults/commit/a1287b19315f64f15fba7126cb98c314f1a5ebc2
[11:58] <LocutusOfBorg> unfortunately that meta-package seems to be non-existing in bionic...
[12:00] <LocutusOfBorg>  libomp-dev | 5.0.1-1               | bionic/universe          | amd64, arm64, armhf, i386, ppc64el
[12:00] <LocutusOfBorg> it is provided by another libomp package, not by llvm
[12:52] <tjaalton> LocutusOfBorg: no, the breaks/replaces are built wrong on bionic for llvm7 & 8
[12:53] <tjaalton> Conflicts: libomp5
[12:53] <tjaalton> vs
[12:53] <tjaalton> Conflicts: libomp-x.y
[12:53] <tjaalton> er, C/R
[12:54] <tjaalton> LocutusOfBorg: unless you mean llvm-defaults would fix this
[13:08] <tjaalton> LocutusOfBorg: uhm, no.. I'm just confused. it's llvm7 where libomp5-7 doesn't provide libomp-x.y
[13:11] <seb128> cyphermox, hey, bug #1828996 ... wouldn't be that an hostnamed issue? I think g-c-c only calls into that
[13:11] <seb128> sorry wrong bug number
[13:11] <tjaalton> LocutusOfBorg: so we'd need d9b6d3fd40bc107 in bionic
[13:13] <seb128> bug #1162475 I meant
[13:45] <cyphermox> it is a systemd issue, as currently assigned to it. there are *control-center tasks too because of .pkla issues in the past, and I don't know whether they all go call on whatever the dbus method is to set-transient-hostname
[13:45] <cyphermox> err
[13:45] <cyphermox> set-static-hostname
[14:09] <seb128> cyphermox, k, thx
[14:09] <seb128> cyphermox, hey btw :)
[14:10] <cyphermox> seb128: good morning :)
[14:10] <seb128> cyphermox, oh, while I'm talking to you. Do you plan to look at the plymouthd patches/update early in the cycle? I'm mostly curious and I a bit interested in helping with upstreaming some of our distro changes if that helps
[14:39] <bdmurray> xnox: that only helps me, not other users of Ubuntu 18.04
[14:43] <vorlon> bdmurray: refresh my memory, what actually introduced the behavior regression originally?
[14:44] <bdmurray> vorlon: upgrading to 18.04 iirc
[14:44] <vorlon> bdmurray: right, I mean, what component of the system changed its resolver behavior
[14:44] <cyphermox> seb128: I'll see when I can get to that
[14:44] <vorlon> is it newer glibc doing more aggressive pipelining?
[14:45] <seb128> cyphermox, sounds like "not now/help welcome"? :)
[14:45] <bdmurray> vorlon: I haven't had a clear understanding of the issue. ddstreet might
[14:45] <LocutusOfBorg> yes tjaalton probably that one
[14:46] <LocutusOfBorg> sbeattie, I syncd intel-microcode from Debian, because their version looks better than the Ubuntu one... https://launchpad.net/ubuntu/+source/intel-microcode/3.20190514.1
[14:46] <ddstreet> bdmurray dns lookups with responses > 512 bytes cause getaddrinfo to fallback to TCP dns lookups, unless 'options edns0' is enabled
[14:47] <ddstreet> the systemd stub resolver doesn't (correctly) support that until disco
[14:47] <LocutusOfBorg> looks like they are picking stuff from github repo now, and the "releasenotes" are more up-to-date
[14:47] <ddstreet> with only systemd installed, this was worked around by adding 'options edns0' to systemd stub resolver
[14:48] <ddstreet> but with resolvconf installed, it might throw upstraem nameservers into /etc/resolv.conf, depending on the specific system config, so xnox told me to strip 'edns0' out of resolv.conf when resolvconf is installed to avoid that (since we can't guarantee upstream nameservers support edns0)
[14:49] <ddstreet> hence, bionic/cosmic without resolvconf installed can lookup e.g. toomany.ddstreet.org
[14:49] <vorlon> ddstreet: bdmurray's configuration isn't using the stub resolver, he has resolvconf and therefore upstream nameservers in /etc/resolv.conf
[14:49] <ddstreet> while bionic/cosmic with resolvconf installed cannot lookup e.g. toomany.ddstreet.org
[14:49] <ddstreet> vorlon resolvconf throws the stub resolver in there too
[14:49] <ddstreet> and strips out edns0
[14:49] <vorlon> and the configuration of the stub resolver itself is independent of /etc/resolv.conf, so if he WAS using the stub resolver it should work, since the configuration of options on the stub resolver (edns0) should be independent of the configuration of /etc/resolv.conf via resolvconf
[14:50] <ddstreet> so gai won't fallback to edns0, it'll fallback to tcp
[14:50] <ddstreet> edns0 is a resolv.conf conf, not systemd conf
[14:50] <vorlon> bdmurray: what's your /etc/resolv.conf?
[14:50] <ddstreet> it tells glibc's gai what to fall back to
[14:51] <bdmurray> vorlon: https://pastebin.ubuntu.com/p/X6zdcSSdS2/
[14:51] <vorlon> ok so the problem is falling back to tcp and then trying to talk to the stub resolver which doesn't listen
[14:52] <vorlon> right
[14:52] <vorlon> so in fact if you have resolvconf and ONLY systemd-resolved as a DNS server, we should in fact set options edns0
[14:52] <vorlon> or else "fix" the stub resolver by backporting a huge new feature what could go wrong
[14:53] <vorlon> or alternatively, after we finish nuking resolvconf from eoan and make systemd conflict with it (calling dr xnox), we could SRU that to bionic
[14:53] <vorlon> except that's a package removal which won't be applied by update-manager
[14:54] <ddstreet> yeah we really need to fix the cases where upstream nameservers are handed to resolvconf, then we can apply edns0 safely
[14:54] <ddstreet> e.g. ifupdown static ip's
[14:54] <ddstreet> maybe ibft
[14:54] <ddstreet> no idea about network-manager or openvpn
[14:54] <vorlon> maybe we should update resolvconf itself to magically re-add options edns0 if it sees only the resolved ip
[14:55] <ddstreet> what if it does have an upstream nameserver?
[14:55] <vorlon> I don't see a sane way to solve that case
[14:55] <ddstreet> does it rip out the stub resolver?
[14:55] <vorlon> hmmm there's an idea
[14:55] <vorlon> why not?
[14:55] <ddstreet> because the  upstream namesever might not resolve all addresses
[14:55] <ddstreet> e.g. local stuff, per-interface stuff, etc
[14:56] <ddstreet> we had this discussion already when you reverted my patch to make resolvconf use upstream nameservers :)
[14:56] <ddstreet> pretty sure either we corral and kill all things that might put an upstream nameserver into resolvconf, or we backport resolved tcp pipelining
[14:57] <ddstreet> i think tcp pipeline backport is probably the less dangerous option, but it's certainly not trivial
[14:57] <vorlon> I thought the reason we reverted it was because we were winding up with /etc/resolv.conf containing *both* resolved which requires options edns0, *and* upstream nameservers that were not guaranteed to work with them
[14:58] <vorlon> if we always select one or the other, and choose whether to emit options edns0 selectively according to which we choose, I don't think that has the regressions we had before
[14:59] <ddstreet> that only works if you don't actually need the stub resolver to resolve anything
[14:59] <ddstreet> and that's hardly going to be the case all the time
[14:59] <vorlon> right, we do also need to make sure in such a case that there are no DNS servers being poked into resolved that aren't also poked into resolvconf
[14:59] <ddstreet> besides backporting tcp piplining, the only sane thing to do is make all your dns belong to resolved
[15:00] <ddstreet> well resolved has per-interface dns
[15:00] <ddstreet> you can't do that with resolv.conf
[15:00] <ddstreet> there is no way to fit resolved into resolv.conf
[15:00] <ddstreet> that covers all situations
[15:00] <vorlon> yes, which means you would not have BOTH per-interface dns AND upstream nameservers in resolvconf
[15:01] <vorlon> changing the resolvconf package in the presence of resolved to emit only <IP_ADDRESS> into /etc/resolv.conf, and redirect all other servers to resolved?
[15:01] <vorlon> (did we already rule that option out?)
[15:02] <ddstreet> yes, that is the only sane solution - all your dns belong to resolved
[15:02] <vorlon> ok
[15:02] <ddstreet> but, you have to either fix the soures (ifupdown, open-iscsi, etc) to send stuff to resolved, or oyu have to hack resolvconf to send stuff to resolved
[15:03] <vorlon> in that case we don't need to backport tcp support at all as long as we're telling gai to use edns0
[15:03] <ddstreet> yes
[15:03] <vorlon> I think hacking resolvconf centrally is better
[15:07] <vorlon> xnox: ^^
[15:18] <seb128> juliank, bug #1829401 looks like a recent regression/bug from your changes
[15:19] <xnox> bdmurray:  it helps everyone who did clean install of bionic, as none of those use resolvconf
[15:20] <xnox> vorlon:  ok
[15:38] <sbeattie> LocutusOfBorg: that's fine, thanks
[16:23] <coreycb> sil2100: hi, any chance you could take a look at accepting nova into disco-proposed and cosmic-proposed? (the latest upload, the one before that can be rejected) - note this version will replace the current versions in -proposed
[16:26] <sil2100> coreycb: sure, let me try getting to that
[16:27] <coreycb> sil2100: thank you
[16:52] <sil2100> coreycb: hm, actually, I think the .changes file for at least the disco one seems to be missing one version
[16:52] <sil2100> coreycb: the current nova in disco-proposed has 2 versions pending SRU verification, 2:19.0.0-0ubuntu2.1 and 2:19.0.0-0ubuntu2.2
[16:53] <sil2100> coreycb: you included 2:19.0.0-0ubuntu2.2 in it, but 2:19.0.0-0ubuntu2.1 got dropped
[16:53] <sil2100> coreycb: could you re-upload with -v2:19.0.0-0ubuntu2 ?
[16:53] <sil2100> Then we should have all the bugs in the .changes file
[16:53] <coreycb> sil2100: i thought the 2nd version i uploaded included it
[16:54] <sil2100> coreycb: it includes 2, while it should include 3 ;)
[16:54] <sil2100> https://launchpadlibrarian.net/424039899/nova_19.0.0-0ubuntu2.3_source.changes
[16:54] <sil2100> The current one in -proposed already has 2 versions scheduled, so puttin the new one on top means it should have 3 entries in the .changes file
[16:55] <coreycb> sil2100: gotcha! fixing.
[16:59] <coreycb> sil2100: ok uploaded a new one to disco
[17:01] <sil2100> coreycb: thanks o/
[17:07] <sil2100> coreycb: for the future, could we get a bit more info regarding regression potential? I'd say normally it's not enough giving context where the patches come from - every cherry-pick can cause regressions (as it was visible multiple times in the past)
[17:07] <sil2100> coreycb: this section should outline where one should expect issues to pop up if anything after looking at which parts of the code have been touched
[17:09] <sil2100> coreycb: it should be more of a thought exercise, identifying what areas can regress potentially due to the code changes, which other pieces can be affected by this
[17:09] <sil2100> (that's for the two new bugs)
[17:10] <sil2100> Anyway, accepted that for now
[17:11] <coreycb> sil2100: yes i'll do my best to improve on that. there's a lot of throughput as you can tell with openstack.
[17:11] <coreycb> sil2100: thank you
[17:13] <coreycb> sil2100: the point i usually try to make with with cherry-picked changes is that they've gone through a whole lot of gate testing, unit and functional, and upstream reviews.
[17:14] <sil2100> coreycb: that's always useful info, but we always feel safer after we know someone did look through some of the regression-potential scenarios ;)
[17:15] <sil2100> Also, it really depends on the fix, since sometimes there can really be not much to write in the regression potential field indeed
[17:15] <coreycb> sil2100: ack on both points