[06:33] <jose> marcoceppi: hey, just as a heads up, you may want to close this bug when/if the charm is on the store: https://bugs.launchpad.net/charms/+bug/1294232
[06:33] <_mup_> Bug #1294232: Charm Needed: Magento <Juju Charms Collection:New> <https://launchpad.net/bugs/1294232>
[09:12] <themonk> marcoceppi: hi
[09:17] <themonk> if provider charm has only relation joined and requirer charm only relation changed will it be wrong? here provider relation joined sets variable and requirer charm gets those variables
[11:32] <Tug> hi, I tried manual providing yesterday and it was working like a charm
[11:33] <Tug> now if I try to connect to the agent machine agent (just doing juju status in fact)
[11:33] <Tug> ERROR state/api: websocket.Dial wss://my.domain.com:17070/: dial tcp XXX.XXX.XXX.XXX:17070: connection refused
[11:34] <Tug> s/manual providing/manual provisioning/
[12:55] <marcoceppi> Tug: you're using 1.16?
[12:55] <Tug> nop I switch to devel :s
[12:56] <marcoceppi> devel should work with manual provider. what version Ubuntu is the machine?
[12:58] <Tug> the machine with the client or the agent ?
[12:58] <marcoceppi> agent
[12:58] <Tug> ubuntu server 12.04
[12:58] <marcoceppi> :/
[12:59] <Tug> yeah it was an experiment...
[12:59] <marcoceppi> ssh in to the machine, run sudo initctl list | grep juju
[12:59] <marcoceppi> so far you are doing all the right things
[13:00] <Tug> I have "juju-db stop/waiting" that's no good right ?
[13:00] <marcoceppi> you should have two juju jobs
[13:00] <marcoceppi> so the provisioning seems incomplete
[13:01] <Tug> jujud-unit-redis-master-0 start/running, process 10004
[13:01] <Tug> jujud-unit-nirror-front-0 start/running, process 10006
[13:01] <Tug> jujud-unit-nirror-proxy-0 start/running, process 10005
[13:01] <Tug> juju-db stop/waiting
[13:01] <Tug> jujud-machine-0 start/running, process 10003
[13:01] <marcoceppi> but yes, that should be running
[13:01] <marcoceppi> oh, start the juju-db job then
[13:01] <Tug> I may have reconfigured mongodb for my needs
[13:01] <Tug> is it using mongodb ?
[13:01] <marcoceppi> sudo start juju-db
[13:01] <marcoceppi> yes
[13:01] <Tug> :s
[13:01] <marcoceppi> juju-db is mongodb
[13:02] <Tug> yeah I wiped out the db to connec to a replicaset
[13:02] <marcoceppi> which explains why now. if you want to run a charm on node 0 which uses mongodb, try --to lxc:0 instead
[13:03] <Tug> ok but I would have to start over because the configuration is lost right ?
[13:05] <marcoceppi> Tug: you might be able to save it but odds are it's best to start over
[13:05] <Tug> ok, thanks for helping me again marcoceppi :)
[13:06] <marcoceppi> Tug: np!
[13:07] <Tug> next time I try the real thing in AWS ;)
[13:23] <zchander> ping marcoceppi
[13:25] <Tug> I wonder how I will update my application once deployed though. Is there an API or something to execute commands on all the units of a service ?
[13:25] <Tug> I like the way deployment is done with capistrano
[13:47] <Tug> I'm not a fan of polling a deployment repository
[21:16] <marcoceppi> Tug: typically, you can make a version configuration option to decouple charm from application version
[21:17] <marcoceppi> Tug: some charms even do something like repo, branch where repo can be a git, bzr, or hg repository and branch can be a git tag, git branch, bzr tag, etc
[21:19] <Tug> ok, but if I change the config option of the service all units are updated ?
[21:19] <Tug> what if I want to update half of it to keep the system online for instance ?
[21:59] <lazyPower> Tug: I may be wrong, but i don't think juju supports that ootb. You woudl want ot deploy 2 clusters of the application, and update them independently behind a load balancer
[21:59] <lazyPower> eg: wordpress1, wordpress2, behind haproxy
[21:59] <lazyPower> set wordpress1 to perform the update, haproxy will route to wordpress2 while wordpress1 is "down" for the update.
[22:48] <marcoceppi> Tug: lazyPower is correct. You're managing service groups not units. If you want to matinain diffferent service groups and do cascading upgrades, deploy your service twice with different alias (juju deploy wordpress wp1; as an example)
[22:48] <Tug> ok makes sens :)
[22:48] <Tug> *sense
[22:49] <Tug> have to go, thx for tthe tips


[03:54] <average_guy> lynx is awesome cyberanger
[03:54] <average_guy> bitlbee is to wrst
[03:54] <average_guy> thx for the tips
[03:56] <wrst> cool average_guy!
[04:20] <average_guy> how about a "screen" multiplexer?  I have been reading about them.  Does anyone use one?
[04:20] <Unit193> YOu mean, screen or tmux?  I like screen better.
[04:20] <Unit193> Used both.
[04:21] <average_guy> I use screen for everything
[04:22] <average_guy> I want to look at 4 at a time instead of flipping
[04:23] <average_guy> ever use i3 desktop Unit193?
[04:24] <Unit193> No.
[04:24] <Unit193> AwesomeWM, for testing.
[04:25] <average_guy> I have no windowing currently
[04:25] <average_guy> reminds me of the DOS days
[04:44] <average_guy> account<EMAIL_ADDRESS>Love2love talk.goole.com:5223:ssl
[04:45] <average_guy> oops
[04:46] <average_guy> now i gotta change that password again
[04:47] <average_guy> one thing about console vs GUI is it is a lot easier to F#@K up on the console..
[04:57] <Unit193> ComputerChic: May as well greet you in double!
[04:57] <Unit193> jfenn2199: Howdy.
[05:15] <Juzzy> http://www.theregister.co.uk/2013/01/10/fcc_wi_fi_speactrum_increase/
[06:51] <cyberanger> average_guy: screen session "Ctrl + a, S" and "Ctrl + a, |"
[06:59] <average_guy> yeah thx cyberanger, just copying stuff from one to another, and pasted on the wrong one :(
[07:00] <average_guy> publicly logged channel wrong... :(
[12:20] <jfenn2199> tttttttttttttttttttttttttttttttttttttttttttttt
[12:34] <wrst> hello jfenn2199
[14:12] <wrst> xTEMPLARx:
[14:24] <xTEMPLARx> they who what what
[14:25] <xTEMPLARx> ain't nothin' wrst than a feller who'll call yer name and then not talk at ye
[14:25] <wrst> ha ha xTEMPLARx
[14:25] <wrst> just being aggervatin' today
[14:25] <xTEMPLARx> ;)
[14:29] <wrst>  how you doign?
[14:29] <xTEMPLARx> coughing and choking from sinus fun, otherwise relatively healthy.  Still bummed out from the FB convo, though.
[15:52] <wrst> xTEMPLARx: one with netritious seemed very good?
[16:05] <xTEMPLARx> yeah not that one
[16:05] <xTEMPLARx> the one I deleted from my timeline that he's referring to
[16:05] <wrst> well i missed all the action!
[16:05] <xTEMPLARx> I have a friend that I've known for years and years who now works for a democratic illinois state senator
[16:06] <xTEMPLARx> so since that sort of thing is his bread and butter, as you can imagine he's very vocal and slanted.
[16:06] <wrst> many times the more vocal and slanted someone is their arguments are equally vocal and slanted but doesn't mean they are good arguments
[16:07] <xTEMPLARx> what WAS a great friendship that could talk about anything without anger or belittling judgements is now a very biased and slanted one
[16:07] <xTEMPLARx> and he's taking the familiar tack of "if you don't see and agree with what I"m saying you're a complete idiot and your opinions are crap"
[16:07] <wrst> yeah that's just not cool
[16:07] <xTEMPLARx> which breaks my heart
[16:07] <xTEMPLARx> for real
[16:11] <wrst> yeah it should never get to that, peopel can be passionate about opposing things and still like each other
[16:29] <xTEMPLARx> and we were pretty m uch at that point but it musta stewed in him because he came back with more fuel for the fire
[16:29] <xTEMPLARx> and then his wife jumped in
[16:30] <xTEMPLARx> so I deleted the thread
[16:30] <xTEMPLARx> it was causing me to dread facebook
[16:31] <wrst> why do people do that?
[16:32] <wrst> i mean really
[16:34] <xTEMPLARx> because they're so focused on being "right" and "winning" the argument, that they're willing to sacrifice a friendship in order to do so
[16:45] <wrst> many times when people are that focused on winning an argument they don't let the facts get in the way either ;)
[21:27]  * xTEMPLARx is ready to go home...
[22:01] <xTEMPLARx> in fact...
[22:01]  * xTEMPLARx is out.
[22:07] <wrst> later xTEMPLARx!


[05:59] <hikenboot> greetings all just installed ubuntu 7.04 getting cant access tty job control turned off on first boot after install...any ideas..I see hundres of posts for this issue with no solutions
[06:00] <crdlb> hikenboot: this channel is for gutsy now
[06:00] <crdlb> you want #ubuntu
[11:12] <Edulix> hi!
[11:12] <Edulix> I want to install madwifi drivers (ath_pci etc) from source
[11:12] <Edulix> what packages should I need?
[11:13] <Edulix> linux-source-2.6.22 should suffice or do I need linux-headers too? where can I get thoe from?
[11:14] <Edulix> well I'll test it..
[11:22] <crimsun> you should use the matching linux-headers-$(uname -r)
[11:22] <crimsun> otherwise, if you want the snazoo from the actual source, then apt-get source linux-headers-$(uname -r)
[11:24] <Edulix> crimsun: can you tell me where is the linux-headers-2.6.22* package? I'm installing the gutsy kernel in feisty
[11:24] <Edulix> (I want tickless kernel ;-)
[11:26] <crimsun> I advise you to hold off from trying that.
[11:26] <Edulix> crimsun: well.. I've tested and it works fine
[11:26] <crimsun> but you can use launchpad.net to find it.
[11:26] <Edulix> the only thing left is to compile madwifi for it so my atheros wifi card works too
[11:26] <crimsun> Edulix: no, you really mean "Works for Me".
[11:27] <Edulix> crimsun: yes, that's what I meant
[11:27] <Edulix> crimsun: actually it works better than feisty release kernel for me
[11:27] <crimsun> it doesn't boot three of my machines.
[11:28] <Edulix> I'm using a pre-release kernel (2.6.20-12  instead of 2.6.20-15) because in following versions sound didn't work
[11:28] <Edulix> crimsun: hehe that's life =)
[11:28] <crimsun> what sound card?
[11:28] <Edulix> snd_hda_intel
[11:29] <Edulix> integrated in my samsung r40 laptop
[11:29] <Edulix> actually it seems that it was fixed after fesity was released
[11:31] <Edulix> but because of ubuntu politics, this will not be fixed for feisty kernel. there'll be only security updates because "fixing a bug can lead to another one". but I still think that bugs should also be fixed in stable version..
 :P
[11:31] <crimsun> can you be more specific?
[11:31] <Edulix> crimsun: about the sound card?
[11:31] <crimsun> I've triaged about six thousand different ALSA bugs
[11:31] <Edulix> hehe
[11:32] <crimsun> no, about your bug
[11:32] <Edulix> ah
[11:32] <crimsun> is it the AD1986A one?  the SB450 one?  the Realtek 88x jack sense one?  the "inaudible audio from resume" one?
[11:33] <Edulix> well, as far as i can remember: sound modules load fine, but then alsa mixer shows only one bar or two (front and mic perhaps?) and there's none form PCM
[11:33] <Edulix> apps like amarok freeze at start
[11:33] <crimsun> that's not a bug, that's a symptom.  Big difference.
[11:33] <crimsun> What's the actual bug?
[11:35] <Edulix> uhm well the bug? sounds doesn't play, I don't know why. and this was in the change from 2.6.20-12 to 2.6.20-13. if you want me to be more specific I can reboot with 2.6.20-15 (which has the same bug) and tell you better
[11:35] <crimsun> yes, reboot, and please read http://www.linux-sound.info/alsa/index.php?task=support and tell me the URL of the paste generated by the script linked from that page.
[11:35] <Edulix> but I recall that it was related to some changes in a define for alsa
[11:35] <Edulix> (#define)
[11:35] <crimsun> that sounds like the SB450 one
[11:36] <crimsun> the fix that I've committed is a gruesome hack at best, and it's definitely not the right one at all, but it fixes the symptom.  It does not, however, actually fix the bug.
[11:37] <crimsun> there are several critical pieces that are missing to actually fix the bug, and they're all far too invasive to go into a released kernel without introducing further regressions.
[11:37] <crimsun> I know - I wrote that code.
[11:40] <Toma-> hey crimsun, i got that old dell d300 with the cs4232 to work! i had to disable apci, get lspnp, then set the right addresses! thanks for the point in the right direction :)
[11:44] <Edulix> crimsun: sorry, I was at the tlf
[11:45] <Edulix> I'll reboot now
[11:47] <crimsun> Toma-: np
[11:49] <Toma-> crimsun: strange thing tho, the pnp ports have changed over the years from 0x530 to 0x0530. So all the previous docs were totally wrong :O
[11:50] <crimsun> err, that's a consequence of the underlying subsystem being wonky.
[11:50] <crimsun> I knew isapnp should have died.
[11:50] <Toma-> mmm. ill update the wiki/forum help on it
[11:57] <Edulix> hi back!
[11:58] <Edulix> crimsun: http://pastebin.ca/485908 there you are
[11:59] <Edulix> crimsun: ping?
[11:59] <crimsun> http://adhd.irule.net/~crimsun/feisty-azx-sb450/
[11:59] <crimsun> use those.
[12:02] <Edulix> ok
[12:03] <Edulix> anyway I still want tickless kernel and I want to toy with PowerTOP so I'm trying to build madwifi  in 2.6.22 =)
[12:09] <ScarFreewill> is gutsy going to use kde4?
[12:10] <crdlb> it won't be released in time
[12:10] <crdlb> even if it's completely on schedule
[12:10] <Edulix> oh I thought it would use it
[12:10] <crdlb> they're going to release an update or something when it does come out though iirc
[12:11] <ScarFreewill> kde4 is for nov 2007 right?
[12:12] <crdlb> October 23, 2007: Targeted Release Date
[12:12] <crdlb> from wikipedia
[12:12] <ScarFreewill> ok thx
[12:12] <crdlb> and gutsy is planned for october 18
[12:14] <ScarFreewill> i don't mind to just download a few new debs for kde4 when it gets out, though it would have been nice to have it natively ;)
[01:15] <Edulix> hi
[01:16] <Edulix> why is it that I have no /lib/modules/2.6.22-1-generic/build directory?
[01:19] <Edulix> ok found it
[01:32] <Edulix> wow
[01:32] <Edulix> it worked! I have 2.6.22 with madwifi (and sound ;-)
[01:32] <Edulix> where? in feisty hehe
[01:33] <fuoco> Edulix: how did you achieve that? i'm just in the process of trying the same
[01:34] <Edulix> fuoco: download linux-headers-2.6.22-1_2.6.22-1.5_all.deb, linux-headers-2.6.22-1-generic_2.6.22-1.5_i386.deb, linux-image-2.6.22-1-generic_2.6.22-1.5_i386.deb and install them
[01:34] <Edulix> (from gutsy)
[01:34] <Edulix> then download madwifi from svn
[01:35] <Edulix> and then reboot to use the new kernel, and compile ("make && make install") madwifi
[01:35] <Edulix> and there you go ;)
[01:35] <fuoco> ok, cool thx
[01:36] <Edulix> your are welcome =)
[01:36] <Edulix> now time to test powertop (do you know about it?)
[01:36] <fuoco> what's that?
[01:36] <Edulix> well the web page is down now :( but:
[01:37] <Edulix> read this http://www.kdedevelopers.org/node/2801
[01:37] <Edulix> fuoco: it's basically an utility to exploit the tickless kernel feature we've got in 2.6.21+ so that bateries last longer
[01:38] <Edulix> (laptops)
[01:38] <fuoco> yeah ok
[01:39] <Edulix> btw take into accound that 64bits kernels are not tickless yet
[01:39] <fuoco> i'm on ppc actually
[01:39] <Edulix> oh =)
[02:50] <fgh> hi............. i am girl 22.is any one for chat??????
[02:50] <zaggynl> wait, what?
[02:51] <Girl___22> what what?
[02:51] <someothernick> lol
[02:52] <Girl___22> i am from serbia :) jebem mu mater
[02:52] <zaggynl> IRC's pretty dead today
[02:58] <Edulix> hi!
[03:02] <Edulix>  how can I see a list of flavours for AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-debs flavours=<?>  ?
[09:25] <fuoco> anyone runs a 2.6.21 or 2.6.22 kernel ?
[09:32] <stouset> Anyone upgrade to Gutsy and experience large fonts in GNOME?
[09:33] <stouset> Preferences->Fonts shows everything at 10pt.
[09:34] <stouset> Although I'm reasonably certain that 10pt fonts aren't the size of my finger.
[09:38] <stouset> For the record, a font size of about 7 as configured through font preferences corresponds to exactly what 10 was pre-gutsy.
[09:39] <kalpik> stouset, check your DPI
[09:39] <stouset> kalpik: Easiest way?
[09:39] <kalpik> xdpyinfo | grep resolution
[09:40] <stouset> 129x126
[09:40] <kalpik> that's the problem.. you have to set it to 96x96
[09:40] <stouset> Indeed.
[09:41] <stouset> That would do it. Didn't even notice the DPI setting in the font prefs was way off at 127.
[09:41] <stouset> Interesting that it changed itself.
[09:42] <kalpik> hmm
[09:42] <kalpik> i told you its not the right time to switch to gutsy :P
[09:43] <stouset> I know. Which is precisely why I'm doing it.
[09:43] <kalpik> hehe
[09:43] <stouset> Might as well file the bug reports.
[09:43] <kalpik> love breakage, dont you? ;)
[09:44] <stouset> Like helping out. Always ran unstable on Debian and filed reports aplenty.
[09:44] <kalpik> so while we're at it, even i was planning to switch to gutsy :P
[09:44] <kalpik> just not daring enough
[09:44] <stouset> That was the only hitch as far as I can tell, so far.
[09:44] <kalpik> hmm
[09:44] <stouset> For some...1,250 packages installed. So not a barebones system.
[09:46] <stouset> Of course, I did end up tossing Debian and switching to Ubuntu when they broke fglrx in unstable for about two months.
[09:46] <stouset> Couldn't use the free driver, since it doesn't support my card yet.
[09:46] <kalpik> yeah.. ubuntu is known for very stable dist-upgrades
[09:47] <stouset> Thanks for the assist.
[09:48] <kalpik> sure :)
[09:48] <stouset> brb
[09:56] <stouset> kalpik: I've never really understood how GNOME handles DPI vs. Xorg. Best I can tell, is it that my DPI is set in xorg to 129x126, which would be the default DPI for my fonts, but GTK overrides it to 96 with the font properties?
[09:56] <stouset> i.e., if I were to open up a window that used some other font rendering toolkit, it would use the 129x126 DPI?
[09:56] <kalpik> gtk font properties are messed up
[09:56] <kalpik> neevr report the cotrrect DPI
[09:57] <kalpik> *correct
[09:57] <stouset> Ah.
[09:57] <stouset> Anywhere I can read up about it?
[09:57] <kalpik> hmm.. wait
[09:58] <kalpik> this thread mentions about DPI: http://ubuntuforums.org/showthread.php?t=20976
[10:00] <stouset> Thanks.
[10:01] <fuoco> anyone who uses 2.6.22 kernel or otherwise gutsy: can you check if 'top' shows your cpu ever goes idle or just wastes cycles? ('%wa' in top)
[10:02] <stouset> Ah, DisplaySize is a godsend.
[10:02] <kalpik> hehe
[10:51] <KiloHertz> anyone in here ever done xinerma  with a agp card and a pci card?
[10:51] <KiloHertz> anyone in here ever done xinerma  with a agp card and a pci card?
[10:51] <KiloHertz> sorry it pasted twice


[00:12] -queuebot:#ubuntu-release- New binary: rocksdb [ppc64el] (bionic-proposed/universe) [5.8-2] (no packageset)
[00:29] -queuebot:#ubuntu-release- New binary: biomaj3 [amd64] (bionic-proposed/universe) [3.1.3-1] (no packageset)
[00:31] -queuebot:#ubuntu-release- New: accepted biomaj3 [amd64] (bionic-proposed) [3.1.3-1]
[01:20] -queuebot:#ubuntu-release- New binary: rocksdb [amd64] (bionic-proposed/universe) [5.8-2] (no packageset)
[02:49] -queuebot:#ubuntu-release- New binary: rocksdb [arm64] (bionic-proposed/universe) [5.8-2] (no packageset)
[03:28] -queuebot:#ubuntu-release- New binary: biomaj3-daemon [amd64] (bionic-proposed/universe) [3.0.12-1] (no packageset)
[04:43] <slangasek> infinity, Laney: do you have any idea why courier 0.78.0-2 migrated into bionic when it caused courier-filter-perl's autopkgtests to regress (because courier-mta is broken)?
[04:44] <slangasek> infinity, Laney: ah, worse than that, it made it into artful broken
[04:45] <slangasek> and doesn't seem to have ever been hinted
[05:02] <infinity> slangasek: A very good question that I don't know the answer to.
[05:09] <infinity> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/artful/2017-09-18/12:23:56.html.gz
[05:09] <infinity> slangasek: courier-filter-perl wasn't in the release pocket when courier migrated.
[05:10] -queuebot:#ubuntu-release- New binary: avro-c [ppc64el] (bionic-proposed/none) [1.8.2-1] (no packageset)
[05:10] -queuebot:#ubuntu-release- New binary: avro-c [s390x] (bionic-proposed/none) [1.8.2-1] (no packageset)
[05:10] <infinity> slangasek: https://launchpad.net/ubuntu/+source/courier-filter-perl/+publishinghistory
[05:10] <infinity> slangasek: doko demoted to proposed but didn't make any effort to block it, so it migrated right back.
[05:11] -queuebot:#ubuntu-release- New binary: avro-c [arm64] (bionic-proposed/none) [1.8.2-1] (no packageset)
[05:11] -queuebot:#ubuntu-release- New binary: benchmark [ppc64el] (bionic-proposed/none) [1.3.0-1] (no packageset)
[05:11] -queuebot:#ubuntu-release- New binary: avro-c [armhf] (bionic-proposed/none) [1.8.2-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: benchmark [arm64] (bionic-proposed/none) [1.3.0-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: dtkwm [arm64] (bionic-proposed/none) [2.0.0-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: benchmark [armhf] (bionic-proposed/none) [1.3.0-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: dtkwm [s390x] (bionic-proposed/none) [2.0.0-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: dtkwm [armhf] (bionic-proposed/none) [2.0.0-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: avro-c [amd64] (bionic-proposed/none) [1.8.2-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: benchmark [amd64] (bionic-proposed/none) [1.3.0-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: dtkwm [amd64] (bionic-proposed/none) [2.0.0-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: pystaticconfiguration [amd64] (bionic-proposed/none) [0.10.3-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: avro-c [i386] (bionic-proposed/none) [1.8.2-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: dtkwm [i386] (bionic-proposed/none) [2.0.0-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: benchmark [i386] (bionic-proposed/none) [1.3.0-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: python-aws-requests-auth [amd64] (bionic-proposed/none) [0.4.1-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: python-stomp [amd64] (bionic-proposed/none) [4.1.19-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: python-jira [amd64] (bionic-proposed/none) [1.0.10-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: aioprocessing [amd64] (bionic-proposed/none) [1.0.0-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: python-exotel [amd64] (bionic-proposed/none) [0.1.5-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: pybitcointools [amd64] (bionic-proposed/none) [1.1.42-1] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: python-twilio [amd64] (bionic-proposed/none) [6.8.2-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: sasmodels [amd64] (bionic-proposed/none) [0.97~git20171104-1] (no packageset)
[05:46] <slangasek> infinity: right, I was wondering if that might've been the case but didn't make it there yet. ok.
[05:46] <slangasek> doko: do you remember demoting courier-filter-perl to -proposed in September to unblock courier, and do you remember why you did it?  Because LP: #1732071
[06:23] <slangasek> why are the automatic autopkgtests so terrible? :P  Testsuite: autopkgtest-pkg-perl, implemented by Package: pkg-perl-autopkgtest.  Brilliant.
[07:02] <slangasek> LocutusOfBorg: libpoe-component-client-dns-perl autopkgtest failures suggest a regression in perl 5.26.1-2ubuntu1 related to SIGUNUSED
[07:10] <slangasek> likewise, libtest-valgrind-perl/1.19-1/ppc64el looks like a real regression
[07:43] <LocutusOfBorg> slangasek, yes, confirmed, but I can't understand why it fails, I checked and SIGUNUSED seems to be still there
[07:43] <LocutusOfBorg> do you have any clue?
[08:27] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-101.124]
[08:28] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-101.124~14.04.1]
[08:29] -queuebot:#ubuntu-release- New: accepted haskell-tasty-golden [i386] (trusty-proposed) [<IP_ADDRESS>-1]
[08:29] -queuebot:#ubuntu-release- New: accepted ppc64-diag [ppc64el] (trusty-proposed) [2.7.4-1~14.04]
[08:29] -queuebot:#ubuntu-release- New: accepted ppc64-diag [powerpc] (trusty-proposed) [2.7.4-1~14.04]
[08:30] -queuebot:#ubuntu-release- New: accepted aioprocessing [amd64] (bionic-proposed) [1.0.0-1]
[08:30] -queuebot:#ubuntu-release- New: accepted avro-c [i386] (bionic-proposed) [1.8.2-1]
[08:30] -queuebot:#ubuntu-release- New: accepted benchmark [i386] (bionic-proposed) [1.3.0-1]
[08:30] -queuebot:#ubuntu-release- New: accepted dtkwm [i386] (bionic-proposed) [2.0.0-1]
[08:30] -queuebot:#ubuntu-release- New: accepted pystaticconfiguration [amd64] (bionic-proposed) [0.10.3-1]
[08:30] -queuebot:#ubuntu-release- New: accepted python-exotel [amd64] (bionic-proposed) [0.1.5-1]
[08:30] -queuebot:#ubuntu-release- New: accepted python-stomp [amd64] (bionic-proposed) [4.1.19-1]
[08:30] -queuebot:#ubuntu-release- New: accepted sasmodels [amd64] (bionic-proposed) [0.97~git20171104-1]
[08:30] -queuebot:#ubuntu-release- New: accepted avro-c [amd64] (bionic-proposed) [1.8.2-1]
[08:30] -queuebot:#ubuntu-release- New: accepted dtkwm [amd64] (bionic-proposed) [2.0.0-1]
[08:30] -queuebot:#ubuntu-release- New: accepted python-aws-requests-auth [amd64] (bionic-proposed) [0.4.1-1]
[08:30] -queuebot:#ubuntu-release- New: accepted python-twilio [amd64] (bionic-proposed) [6.8.2-1]
[08:30] -queuebot:#ubuntu-release- New: accepted benchmark [amd64] (bionic-proposed) [1.3.0-1]
[08:30] -queuebot:#ubuntu-release- New: accepted python-jira [amd64] (bionic-proposed) [1.0.10-1]
[08:30] -queuebot:#ubuntu-release- New: accepted pybitcointools [amd64] (bionic-proposed) [1.1.42-1]
[08:30] -queuebot:#ubuntu-release- New: accepted avro-c [arm64] (bionic-proposed) [1.8.2-1]
[08:30] -queuebot:#ubuntu-release- New: accepted avro-c [ppc64el] (bionic-proposed) [1.8.2-1]
[08:31] -queuebot:#ubuntu-release- New: accepted benchmark [arm64] (bionic-proposed) [1.3.0-1]
[08:31] -queuebot:#ubuntu-release- New: accepted benchmark [ppc64el] (bionic-proposed) [1.3.0-1]
[08:31] -queuebot:#ubuntu-release- New: accepted dtkwm [arm64] (bionic-proposed) [2.0.0-1]
[08:31] -queuebot:#ubuntu-release- New: accepted dtkwm [s390x] (bionic-proposed) [2.0.0-1]
[08:31] -queuebot:#ubuntu-release- New: accepted pythonqt [amd64] (bionic-proposed) [3.2-4]
[08:31] -queuebot:#ubuntu-release- New: accepted pythonqt [i386] (bionic-proposed) [3.2-4]
[08:31] -queuebot:#ubuntu-release- New: accepted pythonqt [s390x] (bionic-proposed) [3.2-4]
[08:31] -queuebot:#ubuntu-release- New: accepted rocksdb [arm64] (bionic-proposed) [5.8-2]
[08:31] -queuebot:#ubuntu-release- New: accepted avro-c [armhf] (bionic-proposed) [1.8.2-1]
[08:31] -queuebot:#ubuntu-release- New: accepted benchmark [armhf] (bionic-proposed) [1.3.0-1]
[08:31] -queuebot:#ubuntu-release- New: accepted dtkwm [armhf] (bionic-proposed) [2.0.0-1]
[08:31] -queuebot:#ubuntu-release- New: accepted pythonqt [arm64] (bionic-proposed) [3.2-4]
[08:31] -queuebot:#ubuntu-release- New: accepted rocksdb [amd64] (bionic-proposed) [5.8-2]
[08:31] -queuebot:#ubuntu-release- New: accepted avro-c [s390x] (bionic-proposed) [1.8.2-1]
[08:31] -queuebot:#ubuntu-release- New: accepted mpgrafic [s390x] (bionic-proposed) [0.3.15-1]
[08:31] -queuebot:#ubuntu-release- New: accepted rocksdb [ppc64el] (bionic-proposed) [5.8-2]
[08:31] -queuebot:#ubuntu-release- New: accepted biomaj3-daemon [amd64] (bionic-proposed) [3.0.12-1]
[08:31] -queuebot:#ubuntu-release- New: accepted pythonqt [ppc64el] (bionic-proposed) [3.2-4]
[09:47] -queuebot:#ubuntu-release- New sync: rdma-core (bionic-proposed/primary) [15-1]
[09:56] -queuebot:#ubuntu-release- New binary: python-subunit2sql [amd64] (bionic-proposed/universe) [1.8.0-3ubuntu1] (no packageset)
[10:05] <jamespage> any AA's around who could accept python-subunit2sql NEW binaries? unblocks some dep-waits I need for OpenSTack queens milestone 1 updates
[10:08] <apw> jamespage, looking
[10:08] <jamespage> apw: its a fix for the build failure ontop of the debian sync
[10:10] <ginggs> would someone please remove bagel-data on armhf and i386? it's an obsolete arch:all package
[10:11] -queuebot:#ubuntu-release- New: accepted python-subunit2sql [amd64] (bionic-proposed) [1.8.0-3ubuntu1]
[10:12] <LocutusOfBorg> jamespage, is murano include in some openstack packages? can you please look at fixing its autopkgtestsuite? such openstack packages are holding a lot of packages
[10:12] <jamespage> LocutusOfBorg: it is - I thought coreycb did some fixes for that directly yesterday
[10:12]  * jamespage looks
[10:13] <jamespage> yeah 1:4.0.0-0ubuntu2
[10:14]  * LocutusOfBorg retries them
[10:14] <jamespage> that sounds sensible
[10:14] <LocutusOfBorg> thanks!
[10:16] <Laney> I'm reducing the parallelism on the armhf workers
[10:16] <Laney> hopefully this will alleviate the ENOSPC failures
[10:18] <LocutusOfBorg> will you also retry failures? I can't find a good way to do it
[10:18] <Laney> sure
[10:18] <LocutusOfBorg> :)
[10:20] <LocutusOfBorg> folks, sphinx is not migrating because of mailman-core failing its test on amd64
[10:21] <LocutusOfBorg> since the new mailman3-core is even worse in its autopkgtestsuite, and obviously broken... can we please ignore the results for some while, until Debian makes at least it installable again?
[10:21] <doko> ugh, who accepted the incomplete binary builds ...
[10:21] <apw> doko, which ones ?
[10:22] <LocutusOfBorg> Creating config file /etc/dbconfig-common/mailman3-core.conf with new version
[10:22] <LocutusOfBorg> chown: invalid user: ‘postgres’
[10:22] <LocutusOfBorg> unable to connect to postgresql server.
[10:22] <LocutusOfBorg> error encountered creating user:
[10:22] <LocutusOfBorg> No passwd entry for user 'postgres'
[10:22] <LocutusOfBorg> apw, I think pythonqt
[10:22] <doko> pythonqt, mpgrafic
[10:22] -queuebot:#ubuntu-release- New: accepted rdma-core [sync] (bionic-proposed) [15-1]
[10:22] <LocutusOfBorg> pythonqt is some misalignment on armhf?
[10:23] <apw> doko, likely that was me, when i was processing debian new
[10:24] -queuebot:#ubuntu-release- New binary: rdma-core [s390x] (bionic-proposed/none) [15-1] (no packageset)
[10:25] -queuebot:#ubuntu-release- New binary: rdma-core [i386] (bionic-proposed/none) [15-1] (no packageset)
[10:25] -queuebot:#ubuntu-release- New binary: rdma-core [ppc64el] (bionic-proposed/none) [15-1] (no packageset)
[10:27] <doko> apw: please fix the pythonqt build on armhf then ... ;p it's blocking our big transition now ...
[10:27] -queuebot:#ubuntu-release- New binary: rdma-core [amd64] (bionic-proposed/none) [15-1] (no packageset)
[10:27] -queuebot:#ubuntu-release- New binary: rdma-core [arm64] (bionic-proposed/none) [15-1] (no packageset)
[10:28] <LocutusOfBorg> doko, what is missing, only pythonqt?
[10:31] <doko> "only", except for some hundred failing autopkg tests
[10:31] <LocutusOfBorg> ack
[10:34] <oSoMoN> sil2100, hey, you mentioned the other day you would review the libreoffice 5.4.2 SRU for artful?
[10:55] <sil2100> oSoMoN: yeah, I can do that, last time I think the problem was that it was FTBFS for bionic or something (IIRC)
[10:56] <sil2100> oSoMoN: is it ok now?
[10:58] <oSoMoN> sil2100, I have a patch for bionic that temporarily disables the failing unit test, but I'm not entirely satisfied with that temporary solution so I'm waiting on upstream for now
[10:58] <oSoMoN> sil2100, but seb128 mentioned to me that the bionic upload shouldn't block the artful SRU
[11:01] -queuebot:#ubuntu-release- New binary: biomaj3-cli [amd64] (bionic-proposed/universe) [3.1.7-1] (no packageset)
[11:10] -queuebot:#ubuntu-release- New: accepted biomaj3-cli [amd64] (bionic-proposed) [3.1.7-1]
[11:10] <sil2100> oSoMoN: let me take a look at it in a moment - so the bionic FTBFS is specific only to bionic? e.g. it's failing due to toolchain changes?
[11:11] <doko> sil2100: yes, the bionic is due to the new ICU
[11:12] <doko> oSoMoN: please upload. we don't want to wait on upstream to unblock all of our entangled transitions
[11:12] <sil2100> Ok, so I guess I can re-review, but I need to have a declaration that the openoffice in bionic gets fixed ASAP
[11:12] <sil2100> (by fixed I mean migrating)
[11:13] <oSoMoN> sil2100, yes, it's due to the transition from ICU 59 to 60
[11:13] <doko> bdrung: rdma-core ftbfs on armhf
[11:13] <oSoMoN> sil2100, so that failure is not affecting artful
[11:28] -queuebot:#ubuntu-release- New binary: elastalert [amd64] (bionic-proposed/universe) [0.1.21-1] (no packageset)
[11:56] <xnox> Laney, it seems that newly added amd64 items in the adt queue, starve old i386 queue items. E.g. in huge amd64 was zero, but now amd64 huge is processed ahead of old i386 huge. I wonder if something clever needs doing like half of the i386/amd64 workers need to take things off i386 queue first. I guess i need to poke the code for this thing, to really figure out what is going on.
[11:56]  * xnox still is waiting for systemd adt test results, but it's only been two days so far, so it's ok.
[11:56] <Laney> xnox: known, tried to fix, didn't work, feel free to look
[11:57] <xnox> Laney, ack. yeah, it smells hard.
[11:57] <xnox> / obscure
[11:57] <Laney> we connect to the queues in a random order
[11:57] <Laney> but it apparently doesn't work like that
[11:57] <apw> i thought we did ... that
[11:57] <Laney> so dunno
[11:58] <xnox> Laney, random.... 4.... chosen by a random dice roll, right? =)
[11:58] <Laney> you can probably set up a rabbitmq locally with multiple queues and replicate this
[11:58] <Laney> heh
[12:13] -queuebot:#ubuntu-release- New binary: python-stestr [amd64] (bionic-proposed/universe) [1.0.0-2] (no packageset)
[12:46] <jamespage> apw: could you do the NEW's for python-stestr as well please?
[12:48] -queuebot:#ubuntu-release- New: accepted python-stestr [amd64] (bionic-proposed) [1.0.0-2]
[12:53] <jamespage> apw: ta
[12:53] <jamespage> (if that was you)
[12:53] <apw> t'was
[13:24] -queuebot:#ubuntu-release- New binary: repmgr [amd64] (bionic-proposed/universe) [4.0~beta1-1] (no packageset)
[13:24] -queuebot:#ubuntu-release- New binary: repmgr [ppc64el] (bionic-proposed/universe) [4.0~beta1-1] (no packageset)
[13:24] -queuebot:#ubuntu-release- New binary: repmgr [i386] (bionic-proposed/universe) [4.0~beta1-1] (no packageset)
[13:24] -queuebot:#ubuntu-release- New binary: repmgr [s390x] (bionic-proposed/universe) [4.0~beta1-1] (no packageset)
[13:25] -queuebot:#ubuntu-release- New binary: repmgr [arm64] (bionic-proposed/universe) [4.0~beta1-1] (no packageset)
[13:26] -queuebot:#ubuntu-release- New binary: repmgr [armhf] (bionic-proposed/universe) [4.0~beta1-1] (no packageset)
[13:26] -queuebot:#ubuntu-release- New binary: ubuntu-mate-artwork [amd64] (bionic-proposed/universe) [18.04.0] (ubuntu-mate)
[13:30] -queuebot:#ubuntu-release- New: accepted elastalert [amd64] (bionic-proposed) [0.1.21-1]
[13:30] -queuebot:#ubuntu-release- New: accepted repmgr [arm64] (bionic-proposed) [4.0~beta1-1]
[13:30] -queuebot:#ubuntu-release- New: accepted repmgr [i386] (bionic-proposed) [4.0~beta1-1]
[13:30] -queuebot:#ubuntu-release- New: accepted repmgr [s390x] (bionic-proposed) [4.0~beta1-1]
[13:30] -queuebot:#ubuntu-release- New: accepted repmgr [amd64] (bionic-proposed) [4.0~beta1-1]
[13:30] -queuebot:#ubuntu-release- New: accepted repmgr [ppc64el] (bionic-proposed) [4.0~beta1-1]
[13:30] -queuebot:#ubuntu-release- New: accepted repmgr [armhf] (bionic-proposed) [4.0~beta1-1]
[13:30] -queuebot:#ubuntu-release- New: accepted ubuntu-mate-artwork [amd64] (bionic-proposed) [18.04.0]
[13:32] <doko> ahh, abi-compliance-checker loaded the queues with kde insanity tests ... I assume the kde guys didn't make any progress with these tests?
[13:32] <doko> tsimonq2: ^^^
[13:33] <LocutusOfBorg> doko, abi-compliance-checker should fix the tests
[13:33] <LocutusOfBorg> I'm triggering them right now
[13:34] <doko> ? no, the kde package still rebuild during the autopkg test
[13:40] <LocutusOfBorg> ok, I got your question now
[13:41] <LocutusOfBorg> anyway, now with abi-compliance-checker fixed the failed testsuites for qtbase transition should become green
[13:44] <tsimonq2> doko: Right, that was our blocker, that fixes things (or should at least)
[13:45] <doko> tsimonq2: so you wil now stop rebuilding the kde packages in the autopkg tests?
[13:45] <LocutusOfBorg> it *fixes* according to at least two of us :)
[13:46] <LocutusOfBorg> doko, "fixes" in mean of "it was regressed", not with mean of "the testsuite now sucks less"
[13:47] <tsimonq2> Right
[13:53] <tsimonq2> doko: This cycle unless Santa decides to come around again (Kubuntu Santa :P) I'll look at seeing wtaf is going on with the KDE autopkgtests
[13:54] <balloons> sil2100, you about?
[13:54] <doko> tsimonq2: ta
[13:56] <sil2100> balloons: hey! Yes
[13:59] <balloons> sil2100, so I was hoping juju 2.2.6-0ubuntu<IP_ADDRESS> could be approved. It has the noproxy update to fix the ADT failure I believe. That's the only change
[14:00] <sil2100> balloons: I'll get to it in a minute then, after I look at OpenOffice
[14:00] <sil2100> s/OpenOffice/LibreOffice
[14:01]  * juliank was already confused for a second :)
[14:02] <balloons> Thanks!
[14:02] <sil2100> There's something wrong with my head today, but that's ok
[14:02] <sil2100> I'll be fine
[14:17] <sil2100> oSoMoN: hey! I looked at the libreoffice SRU and it's good content-wise, but needs to be re-uploaded with the version number changed
[14:18] <sil2100> oSoMoN: for artful you need to either release it as 1:5.4.2-0ubuntu<IP_ADDRESS> or 1:5.4.2-0ubuntu1~17.10.1 or anything similar
[14:19] <sil2100> oSoMoN: it cannot have the same version number as what's in bionic
[14:21] -queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (zesty-proposed) [0.31~17.04.1]
[14:21] -queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.31~16.04.1]
[14:22] <sil2100> oSoMoN: I'll reject them for now, you can still fetch them from the Rejected queue if anything
[14:22] <oSoMoN> sil2100, ack, I have my weekly team meeting now, will prepare a new upload right afterwards
[14:22] <oSoMoN> thanks for the review
[14:24] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice-l10n [source] (artful-proposed) [1:5.4.2-0ubuntu1]
[14:24] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (artful-proposed) [1:5.4.2-0ubuntu1]
[14:24] <xnox> i wish we could steal launchpad's 90 builders for the 3,000 autopkgtest queue
[14:33] <Laney> don't get worked up about it
[14:38] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (zesty-proposed) [2.2.6-0ubuntu<IP_ADDRESS>]
[14:39] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (xenial-proposed) [2.2.6-0ubuntu<IP_ADDRESS>]
[14:41] <sil2100> balloons: ^
[14:43] <balloons> sil2100,ty. I'll wait for the runs now to confirm
[14:50] <elopio> hey Laney, I enabled the daily execution of autopkgtest on our PPA, based on http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/retry-autopkgtest-regressions
[14:50] <elopio> but I'm wondering, why does it use the cookie instead of oauth?
[14:51] <Laney> elopio: not sure, maybe ask pitti as he wrote that script
[14:51] <Laney> does it work fro you?
[14:55] <LocutusOfBorg> elopio, how to use oauth from bash?
[14:56] <LocutusOfBorg> same way probably, but finding a cookie from the browser and copy-paste it seems faster to do?
[14:57] <Laney> yeah but it would be better if it actually did the requests
[14:58] <elopio> Laney: it works for me.
[14:59] <elopio> LocutusOfBorg: I am doing it on python, but failing to do the oauth. I might be doing something stupid, so doing the same thing with the cookie for now.
[14:59] <Laney> I'm actually not sure how to do the oauth stuff
[15:00] <Laney> if you work it out it'd be cool to port r-a-r to using it imo
[15:02] <elopio> Laney: afaik, it should be as simple as using the ssoclient to login with user and password, and then use the keys and secretos to send a requests_oauth get. But last time I did this was like 4 years ago, and it's obviously not working.
[15:09] <Laney> elopio: ah, sorry it's not trivial for you :-(
[15:26] <LocutusOfBorg> elopio, there is a python-oauth2 library in Ubuntu...
[15:27] <LocutusOfBorg> called python-oauth TBH
[15:28] -queuebot:#ubuntu-release- Unapproved: qemu (zesty-proposed/main) [1:2.8+dfsg-3ubuntu2.7 => 1:2.8+dfsg-3ubuntu2.8] (ubuntu-server, virt)
[15:28] <elopio> Laney: well, with the cookie it's trivial, and working. It just seems I will have to refresh it every month.
[15:29] <elopio> LocutusOfBorg: I'm asking the SSO team, will let you know how that goes
[15:29] <Laney> elopio: indeed
[15:39] -queuebot:#ubuntu-release- Packageset: Added linux-firmware-snapdragon to kernel in artful
[15:39] -queuebot:#ubuntu-release- Packageset: Added linux-firmware-snapdragon to kernel in bionic
[15:39] -queuebot:#ubuntu-release- Packageset: Added linux-firmware-snapdragon to kernel in xenial
[15:39] -queuebot:#ubuntu-release- Packageset: Added linux-firmware-snapdragon to kernel in zesty
[15:40] <elopio> LocutusOfBorg: Laney: so, nessita says it's probably not possible, because SSO supports only OpenID, which needs the cookie.
[15:59] <cjwatson> autopkgtest could be refactored to use macaroons and then it would be possible
[15:59] <cjwatson> but it would take some work on the autopkgtest end, and you'd probably have to support it in parallel with the web flow
[16:17] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (artful-proposed/partner) [1:20171025.1-0ubuntu1 => 1:20171114.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:17] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20171025.1-0ubuntu<IP_ADDRESS> => 1:20171114.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:18] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20171025.1-0ubuntu<IP_ADDRESS> => 1:20171114.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:18] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20171025.1-0ubuntu<IP_ADDRESS> => 1:20171114.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:40] <slangasek> tsimonq2: helping to sort through autopkgtest failures and unblock migrations, instead of merging new versions of e.g. nodejs, would be appreciated
[17:09] -queuebot:#ubuntu-release- New sync: ruby2.5 (bionic-proposed/primary) [2.5.0~preview1-1]
[17:10] -queuebot:#ubuntu-release- New: rejected ruby2.5 [sync] (bionic-proposed) [2.5.0~preview1-1]
[17:12] -queuebot:#ubuntu-release- New binary: earlyoom [ppc64el] (bionic-proposed/none) [0.12-1] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: atinject-jsr330 [amd64] (bionic-proposed/universe) [1.0+ds1-4] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: erlang-p1-eimp [ppc64el] (bionic-proposed/none) [1.0.0-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: libesedb [ppc64el] (bionic-proposed/universe) [20170121-3] (no packageset)
[17:15] -queuebot:#ubuntu-release- New: accepted atinject-jsr330 [amd64] (bionic-proposed) [1.0+ds1-4]
[17:15] -queuebot:#ubuntu-release- New binary: lmdbxx [ppc64el] (bionic-proposed/none) [<IP_ADDRESS>+git20160228.0b43ca8-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: libesedb [i386] (bionic-proposed/universe) [20170121-3] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: stenc [ppc64el] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: cc65 [ppc64el] (bionic-proposed/none) [2.16-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: libesedb [amd64] (bionic-proposed/universe) [20170121-3] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: ocaml-migrate-parsetree [ppc64el] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: jose [ppc64el] (bionic-proposed/none) [10-2] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: luksmeta [ppc64el] (bionic-proposed/none) [8-2] (no packageset)
[17:16] <tsimonq2> slangasek: Sure, but are there other transitions besides Qt that was waiting on the abi-compliance-checker uploaded this morning that could use some help?
[17:16]  * tsimonq2 didn't see any
[17:17] -queuebot:#ubuntu-release- New binary: ddgr [amd64] (bionic-proposed/none) [1.0-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: earlyoom [i386] (bionic-proposed/none) [0.12-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: earlyoom [amd64] (bionic-proposed/none) [0.12-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: flycheck-package [amd64] (bionic-proposed/none) [0.12-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: erlang-p1-eimp [amd64] (bionic-proposed/none) [1.0.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: libesedb [s390x] (bionic-proposed/universe) [20170121-3] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: erlang-p1-eimp [i386] (bionic-proposed/none) [1.0.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: pulsemixer [amd64] (bionic-proposed/none) [1.3.0-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: dlmodelbox [amd64] (bionic-proposed/none) [0.1.2-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: patroni [amd64] (bionic-proposed/none) [1.3.4-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ruby-gitlab [amd64] (bionic-proposed/none) [4.2.0-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ruby-rubocop-rspec [amd64] (bionic-proposed/none) [1.19.0-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: stenc [amd64] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: luksmeta [i386] (bionic-proposed/none) [8-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ruby-rsec [amd64] (bionic-proposed/none) [0.4.2-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: stenc [i386] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: php-db-dataobject [amd64] (bionic-proposed/none) [1.11.5-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: simplemde-markdown-editor [amd64] (bionic-proposed/none) [1.11.2+dfsg2-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: libthumbor [amd64] (bionic-proposed/none) [1.3.2-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: cc65 [amd64] (bionic-proposed/none) [2.16-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: lmdbxx [amd64] (bionic-proposed/none) [<IP_ADDRESS>+git20160228.0b43ca8-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: luksmeta [amd64] (bionic-proposed/none) [8-2] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: python-periodictable [amd64] (bionic-proposed/none) [1.5.0-2] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: cc65 [i386] (bionic-proposed/none) [2.16-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: ocaml-migrate-parsetree [i386] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: lmdbxx [i386] (bionic-proposed/none) [<IP_ADDRESS>+git20160228.0b43ca8-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: vspline [amd64] (bionic-proposed/none) [0.2.0-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: ocaml-migrate-parsetree [amd64] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: python-bumps [amd64] (bionic-proposed/none) [0.7.6-2] (no packageset)
[17:22] <slangasek> tsimonq2: there are piles of autopkgtest regressions listed on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html that need investigation
[17:22] -queuebot:#ubuntu-release- New binary: jose [amd64] (bionic-proposed/none) [10-2] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: pynmea2 [amd64] (bionic-proposed/none) [1.9.0-1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: php-enum [amd64] (bionic-proposed/none) [2.3.1-1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: spyder-reports [amd64] (bionic-proposed/none) [0.1.1-1] (no packageset)
[17:23] <tsimonq2> slangasek: Sure, I can take a look when I get home
[17:23] -queuebot:#ubuntu-release- New binary: earlyoom [s390x] (bionic-proposed/none) [0.12-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: erlang-p1-eimp [s390x] (bionic-proposed/none) [1.0.0-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: lmdbxx [s390x] (bionic-proposed/none) [<IP_ADDRESS>+git20160228.0b43ca8-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: stenc [s390x] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: jose [i386] (bionic-proposed/none) [10-2] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: luksmeta [s390x] (bionic-proposed/none) [8-2] (no packageset)
[17:27] <slangasek> Laney: er... bos02 is live?  Yes, I was not in the loop that this is the case, the last I heard was that the network needed redone
[17:28] -queuebot:#ubuntu-release- New binary: cc65 [s390x] (bionic-proposed/none) [2.16-1] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: libesedb [arm64] (bionic-proposed/universe) [20170121-3] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: jose [s390x] (bionic-proposed/none) [10-2] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: libesedb [armhf] (bionic-proposed/universe) [20170121-3] (no packageset)
[17:30] <Laney> oops
[17:31] <Laney> well, that's why the arm64 queues drained this millenium
[17:31] <slangasek> makes sense ;)
[17:31] <slangasek> zesty did seem to go faster than xenial had ;)
[17:31] -queuebot:#ubuntu-release- New binary: ocaml-migrate-parsetree [s390x] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:32] <slangasek> Laney: anyway, in that case does it make sense to let artful finish, do a baseline run for bionic, and then turn it on for all series?
[17:33] -queuebot:#ubuntu-release- New binary: earlyoom [arm64] (bionic-proposed/none) [0.12-1] (no packageset)
[17:33] -queuebot:#ubuntu-release- New binary: erlang-p1-eimp [arm64] (bionic-proposed/none) [1.0.0-1] (no packageset)
[17:33] <slangasek> xnox: ^^ so it seems we're less idle now after all
[17:33] <slangasek> Laney: ah... and does that mean s390x is no longer lxc?
[17:33] -queuebot:#ubuntu-release- New binary: lmdbxx [arm64] (bionic-proposed/none) [<IP_ADDRESS>+git20160228.0b43ca8-1] (no packageset)
[17:34] -queuebot:#ubuntu-release- New binary: erlang-p1-eimp [armhf] (bionic-proposed/none) [1.0.0-1] (no packageset)
[17:34] <xnox> slangasek, just because instances work for autopkgtest, it doesn't mean it works for launchpad vbuilders, no? and maybe the network issues wgrant saw, do not affect autopkgtest?
[17:34] -queuebot:#ubuntu-release- New binary: earlyoom [armhf] (bionic-proposed/none) [0.12-1] (no packageset)
[17:34] -queuebot:#ubuntu-release- New binary: lmdbxx [armhf] (bionic-proposed/none) [<IP_ADDRESS>+git20160228.0b43ca8-1] (no packageset)
[17:34] <xnox> Laney, do you recall any bos02 networking issues; that got fixed; and then you were able to use the instances?
[17:35] <Laney> xnox: umm
[17:35] <slangasek> Laney: it sure looks like the worker config points to s390x in scalingstack, which is awesome - that means we should get the lxc host torn down and put back in the hardware pool, have you started that?
[17:35] <Laney> are you remembering something I told you or something you saw?
[17:36] <Laney> slangasek: not yet, that's on the list
[17:36] -queuebot:#ubuntu-release- New binary: luksmeta [arm64] (bionic-proposed/none) [8-2] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: luksmeta [armhf] (bionic-proposed/none) [8-2] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: stenc [arm64] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:36] <xnox> slangasek, it would be nice to release this sru https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1730647 and release s390x cloud images with this change.
[17:36] <slangasek> xnox: it was a network performance issue; it is likely that it would have affected autopkgtest instances also
[17:36] -queuebot:#ubuntu-release- New binary: stenc [armhf] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:37] <slangasek> Laney: where does that list live? ;)
[17:37] <xnox> slangasek, as otherwise none of the cloud images can upgrade and reboot into the new kernel.
[17:37] <slangasek> xnox: did you poke the sru vanguard?
[17:37] <xnox> slangasek, nope =)
[17:38] <slangasek> xnox: please start there ;) and I can take a look if they're not available
[17:38] <sil2100> o/
[17:38] <sil2100> I can look at that
[17:38] <xnox> sil2100, thanks! \o/
[17:40] <Laney> slangasek: just my todo list
[17:40] -queuebot:#ubuntu-release- New binary: cc65 [armhf] (bionic-proposed/none) [2.16-1] (no packageset)
[17:40] <Laney> I know dok_o has been asking about lcy01 performance, not aware of anything bos02 specific
[17:40] -queuebot:#ubuntu-release- New binary: ocaml-migrate-parsetree [arm64] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:40] <sil2100> xnox: uh oh! One day remaining to the 7-day aging period - what's the priority of this one?
[17:40] -queuebot:#ubuntu-release- New binary: jose [armhf] (bionic-proposed/none) [10-2] (no packageset)
[17:40]  * sil2100 reads the bug
[17:40] <slangasek> Laney: ok, that seems like something we could put on a shared todo list for s390x or such - are there any blockers from your side for me to go ahead and start that reclamation process?
[17:40] -queuebot:#ubuntu-release- New binary: cc65 [arm64] (bionic-proposed/none) [2.16-1] (no packageset)
[17:40] -queuebot:#ubuntu-release- New binary: jose [arm64] (bionic-proposed/none) [10-2] (no packageset)
[17:41] <Laney> slangasek: it might be nice to have a non huge arm64 queue as they're shared arm64/s390x
[17:41] <sil2100> xnox: ok, seeing that it's just a seed change, let me take care of it
[17:41] <xnox> Laney, huh?! arm64/s390x cannot be shared....
[17:42] <xnox> Laney, or you mean quota wise?
[17:42] <Laney> right
[17:42] <slangasek> ah
[17:42] <Laney> the *workers* are shared
[17:42] <Laney> but if it's important to give those machines back to the pool we can live with that
[17:43] <slangasek> a shared quota for disjoint hardware is clearly crazypants
[17:43] <slangasek> is this fundamental to openstack?
[17:43] <Laney> I guess we could have two tenants or something
[17:43] -queuebot:#ubuntu-release- New binary: ocaml-migrate-parsetree [armhf] (bionic-proposed/none) [1.0.7-1] (no packageset)
[17:44] <slangasek> it's not like we can actually have the s390x scale out when the s390x queue is larger, at the expense of arm64
[17:44] <slangasek> because the underlying hardware pools are not actually that elastic
[17:44]  * xnox ponders how fast can s390x emulated arm64
[17:44] <slangasek> Laney: or what about having two worker pools, each taking half the nova quota?
[17:44] <Laney> we're currently handling our full quota of arm64
[17:45] <Laney> so maybe we could double it and do that?
[17:45] <xnox> since there is more arches; with more hardware; our quota needs bumping, no?
[17:45] <slangasek> this is basically the split I did to point at the arm64 bos01 node - split at the worker unit level
[17:46] <slangasek> Laney: yeah, ISTM that operationally the right thing for scalingstack to do is to give us two tenants
[17:46] <slangasek> is nova currently letting us use our full quota with arm64 because we're the only tenant using it yet?
[17:47] <slangasek> anyway, these use cases are all clearly different from amd64+i386, where you do use a single hardware pool to service both archs
[17:48] <slangasek> so: scalingstack should give us an arm64 and an s390x tenant, with separate quotas, rather than a single tenant with a quota large enough to encompass both archs that we would be abusing if we applied it all to one arch
[17:49] <Laney> I'd ask w_grant what he thinks is best
[17:49] <Laney> I think there's a decent amount of configuration to set up a new tenant
[17:49] <cjwatson> try next week though; he's on holiday
[17:50] <slangasek> (otoh, nova would then need to be able to restrict each tenant by hardware class... if giving us two tenants just means we could still point both tenants at s390x, that's not an improvement)
[17:51] <xnox> we can promise to be nice....
[17:51] <slangasek> well, I'll open an RT in the meantime to start the discussion w/ IS to understand what's feasible
[17:51] <Laney> even with the shared pool arm64+s390x ripped through the backlog much faster than x86
[17:51] <slangasek> sure, for the common case it should be fine
[17:52] <slangasek> but the first time we have an outage taking out some of one class or the other of hardware, the queues will get wonky and take longer than is sane to recover
[17:52] <Laney> cc William on the ticket and he can give input when he's back
[17:53] <slangasek> indeed
[17:53]  * tsimonq2 wonders if a smart autopkgtest queue would be possible so when we have large queues like at the beginning of the cycle, leaf packages can have lower priority *shrug*
[17:54] <slangasek> tsimonq2: it's not as simple as sorting the queue by whether the package is a leaf package, you also want to look at the triggers; and at the moment the queue is entirely fifo so there would be significant work to change that
[17:55] <Laney> right, and by definition the packages that trigger other tests aren't leaf packages
[17:56] <Laney> and those are the ones that back up the queue really
[17:56] <tsimonq2> Right
[17:56] -queuebot:#ubuntu-release- New: accepted cc65 [amd64] (bionic-proposed) [2.16-1]
[17:56] -queuebot:#ubuntu-release- New: accepted cc65 [armhf] (bionic-proposed) [2.16-1]
[17:56] -queuebot:#ubuntu-release- New: accepted cc65 [ppc64el] (bionic-proposed) [2.16-1]
[17:56] -queuebot:#ubuntu-release- New: accepted ddgr [amd64] (bionic-proposed) [1.0-1]
[17:56] -queuebot:#ubuntu-release- New: accepted earlyoom [amd64] (bionic-proposed) [0.12-1]
[17:56] -queuebot:#ubuntu-release- New: accepted earlyoom [armhf] (bionic-proposed) [0.12-1]
[17:56] -queuebot:#ubuntu-release- New: accepted earlyoom [ppc64el] (bionic-proposed) [0.12-1]
[17:56] -queuebot:#ubuntu-release- New: accepted erlang-p1-eimp [arm64] (bionic-proposed) [1.0.0-1]
[17:56] -queuebot:#ubuntu-release- New: accepted erlang-p1-eimp [s390x] (bionic-proposed) [1.0.0-1]
[17:56] -queuebot:#ubuntu-release- New source: nototools (bionic-proposed/primary) [0~20170925-0ubuntu1]
[17:56] -queuebot:#ubuntu-release- New: accepted cc65 [arm64] (bionic-proposed) [2.16-1]
[17:56] -queuebot:#ubuntu-release- New: accepted cc65 [s390x] (bionic-proposed) [2.16-1]
[17:56] -queuebot:#ubuntu-release- New: accepted earlyoom [arm64] (bionic-proposed) [0.12-1]
[17:56] -queuebot:#ubuntu-release- New: accepted earlyoom [s390x] (bionic-proposed) [0.12-1]
[17:56] -queuebot:#ubuntu-release- New source: fonts-noto-color-emoji (bionic-proposed/primary) [0~20170913-0ubuntu1]
[17:56] -queuebot:#ubuntu-release- New: accepted cc65 [i386] (bionic-proposed) [2.16-1]
[17:56] -queuebot:#ubuntu-release- New: accepted earlyoom [i386] (bionic-proposed) [0.12-1]
[17:56] -queuebot:#ubuntu-release- New binary: rdma-core [s390x] (bionic-proposed/universe) [15-1] (no packageset)
[17:56] -queuebot:#ubuntu-release- New: accepted dlmodelbox [amd64] (bionic-proposed) [0.1.2-2]
[17:56] -queuebot:#ubuntu-release- New: accepted erlang-p1-eimp [armhf] (bionic-proposed) [1.0.0-1]
[17:56] -queuebot:#ubuntu-release- New: accepted erlang-p1-eimp [amd64] (bionic-proposed) [1.0.0-1]
[17:56] -queuebot:#ubuntu-release- New: accepted erlang-p1-eimp [ppc64el] (bionic-proposed) [1.0.0-1]
[17:56] -queuebot:#ubuntu-release- New: accepted jose [amd64] (bionic-proposed) [10-2]
[17:56] -queuebot:#ubuntu-release- New: accepted jose [armhf] (bionic-proposed) [10-2]
[17:57] -queuebot:#ubuntu-release- New: accepted jose [ppc64el] (bionic-proposed) [10-2]
[17:57] -queuebot:#ubuntu-release- New: accepted libesedb [amd64] (bionic-proposed) [20170121-3]
[17:57] -queuebot:#ubuntu-release- New: accepted libesedb [armhf] (bionic-proposed) [20170121-3]
[17:57] -queuebot:#ubuntu-release- New: accepted libesedb [ppc64el] (bionic-proposed) [20170121-3]
[17:57] -queuebot:#ubuntu-release- New: accepted libthumbor [amd64] (bionic-proposed) [1.3.2-1]
[17:57] -queuebot:#ubuntu-release- New: accepted lmdbxx [arm64] (bionic-proposed) [<IP_ADDRESS>+git20160228.0b43ca8-1]
[17:57] <tsimonq2> But other things could be factored in too such as if the trigger is in main or universe, seeded or not, etc.
[17:57] -queuebot:#ubuntu-release- New: accepted erlang-p1-eimp [i386] (bionic-proposed) [1.0.0-1]
[17:57] -queuebot:#ubuntu-release- New: accepted jose [arm64] (bionic-proposed) [10-2]
[17:57] -queuebot:#ubuntu-release- New: accepted jose [s390x] (bionic-proposed) [10-2]
[17:57] -queuebot:#ubuntu-release- New: accepted libesedb [i386] (bionic-proposed) [20170121-3]
[17:57] -queuebot:#ubuntu-release- New: accepted lmdbxx [amd64] (bionic-proposed) [<IP_ADDRESS>+git20160228.0b43ca8-1]
[17:57] -queuebot:#ubuntu-release- New: accepted lmdbxx [i386] (bionic-proposed) [<IP_ADDRESS>+git20160228.0b43ca8-1]
[17:57] -queuebot:#ubuntu-release- New: accepted lmdbxx [s390x] (bionic-proposed) [<IP_ADDRESS>+git20160228.0b43ca8-1]
[17:57] <tsimonq2> *shrug*
[17:57] -queuebot:#ubuntu-release- New: accepted flycheck-package [amd64] (bionic-proposed) [0.12-1]
[17:57] -queuebot:#ubuntu-release- New: accepted libesedb [arm64] (bionic-proposed) [20170121-3]
[17:57] -queuebot:#ubuntu-release- New: accepted lmdbxx [armhf] (bionic-proposed) [<IP_ADDRESS>+git20160228.0b43ca8-1]
[17:57] -queuebot:#ubuntu-release- New: accepted luksmeta [armhf] (bionic-proposed) [8-2]
[17:57] -queuebot:#ubuntu-release- New: accepted jose [i386] (bionic-proposed) [10-2]
[17:57] -queuebot:#ubuntu-release- New: accepted lmdbxx [ppc64el] (bionic-proposed) [<IP_ADDRESS>+git20160228.0b43ca8-1]
[17:57] -queuebot:#ubuntu-release- New: accepted libesedb [s390x] (bionic-proposed) [20170121-3]
[17:57] -queuebot:#ubuntu-release- New: accepted luksmeta [amd64] (bionic-proposed) [8-2]
[17:57] -queuebot:#ubuntu-release- New: accepted luksmeta [i386] (bionic-proposed) [8-2]
[17:57] -queuebot:#ubuntu-release- New: accepted luksmeta [s390x] (bionic-proposed) [8-2]
[17:57] -queuebot:#ubuntu-release- New: accepted ocaml-migrate-parsetree [arm64] (bionic-proposed) [1.0.7-1]
[17:57] -queuebot:#ubuntu-release- New: accepted ocaml-migrate-parsetree [i386] (bionic-proposed) [1.0.7-1]
[17:57] -queuebot:#ubuntu-release- New: accepted ocaml-migrate-parsetree [s390x] (bionic-proposed) [1.0.7-1]
[17:57] -queuebot:#ubuntu-release- New: accepted php-db-dataobject [amd64] (bionic-proposed) [1.11.5-1]
[17:57] -queuebot:#ubuntu-release- New: accepted pulsemixer [amd64] (bionic-proposed) [1.3.0-1]
[17:57] -queuebot:#ubuntu-release- New: accepted luksmeta [arm64] (bionic-proposed) [8-2]
[17:57] -queuebot:#ubuntu-release- New: accepted ocaml-migrate-parsetree [amd64] (bionic-proposed) [1.0.7-1]
[17:57] -queuebot:#ubuntu-release- New: accepted ocaml-migrate-parsetree [ppc64el] (bionic-proposed) [1.0.7-1]
[17:57] -queuebot:#ubuntu-release- New: accepted php-enum [amd64] (bionic-proposed) [2.3.1-1]
[17:57] -queuebot:#ubuntu-release- New: accepted luksmeta [ppc64el] (bionic-proposed) [8-2]
[17:57] -queuebot:#ubuntu-release- New: accepted patroni [amd64] (bionic-proposed) [1.3.4-1]
[17:57] -queuebot:#ubuntu-release- New: accepted ocaml-migrate-parsetree [armhf] (bionic-proposed) [1.0.7-1]
[17:57] -queuebot:#ubuntu-release- New: accepted pynmea2 [amd64] (bionic-proposed) [1.9.0-1]
[17:57] -queuebot:#ubuntu-release- New: accepted python-bumps [amd64] (bionic-proposed) [0.7.6-2]
[17:57] -queuebot:#ubuntu-release- New: accepted ruby-gitlab [amd64] (bionic-proposed) [4.2.0-1]
[17:57] -queuebot:#ubuntu-release- New: accepted ruby-rubocop-rspec [amd64] (bionic-proposed) [1.19.0-1]
[17:57] -queuebot:#ubuntu-release- New: accepted spyder-reports [amd64] (bionic-proposed) [0.1.1-1]
[17:58] -queuebot:#ubuntu-release- New: accepted stenc [arm64] (bionic-proposed) [1.0.7-1]
[17:58] -queuebot:#ubuntu-release- New: accepted stenc [i386] (bionic-proposed) [1.0.7-1]
[17:58] -queuebot:#ubuntu-release- New: accepted stenc [s390x] (bionic-proposed) [1.0.7-1]
[17:58] -queuebot:#ubuntu-release- New: accepted python-periodictable [amd64] (bionic-proposed) [1.5.0-2]
[17:58] -queuebot:#ubuntu-release- New: accepted simplemde-markdown-editor [amd64] (bionic-proposed) [1.11.2+dfsg2-1]
[17:58] -queuebot:#ubuntu-release- New: accepted stenc [armhf] (bionic-proposed) [1.0.7-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-rsec [amd64] (bionic-proposed) [0.4.2-1]
[17:58] -queuebot:#ubuntu-release- New: accepted stenc [ppc64el] (bionic-proposed) [1.0.7-1]
[17:58] -queuebot:#ubuntu-release- New: accepted stenc [amd64] (bionic-proposed) [1.0.7-1]
[17:58] <slangasek> tsimonq2: and then the first time you have an entangled transition involving both libraries in main and libraries in universe, people will be complaining that the autopkgtests for the universe package aren't getting priority :)
[17:58] <Laney> rescoring would be nice, but even that is not possible with the current architecture
[17:58] -queuebot:#ubuntu-release- New: accepted vspline [amd64] (bionic-proposed) [0.2.0-1]
[17:58] <tsimonq2> Oh right
[17:58] <tsimonq2> Laney: That's sort of what I was thinking, something resembling the current Launchpad build queu.
[17:59] <tsimonq2> But slangasek raises a good point
[17:59] <Laney> although
[17:59] <Laney> https://www.rabbitmq.com/priority.html
[18:00] <Laney> it's all pie in the sky as with most feature work on autopkgtest though right now
[18:01] <Laney> it actually *is* possible to set this up at home though if somebody wanted to work on the infrastructure :-)
[18:02] <slangasek> to one standard deviation, any time the queues are not empty, the developers are going to be unhappy.  Which is why I don't consider it a high priority to work on support for smarter juggling of the queue
[18:03] <Laney> I think rescoring would be valuable as a human can look at the queue and identify jobs which would help to progress things out of -proposed
[18:03] <Laney> other than that, probably diminishing returns
[18:03] <slangasek> yeah
[18:04] <slangasek> but automated scoring, less useful than it might seem initially
[18:04] <Laney> on that note, goodnight
[18:10] <slangasek> night!
[19:03] -queuebot:#ubuntu-release- Unapproved: accepted indicator-printers [sync] (artful-proposed) [0.1.7+17.10.20171021-0ubuntu1]
[19:16] <ginggs> would someone please remove bagel-data on armhf and i386? it's an arch:all package no longer built from source
[19:22] <slangasek> Laney: so you mentioned that there were 40 workers for bos02, and I see that's the case, but the branch says 20?
[19:22] <slangasek> ginggs: looking
[19:24] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.23]
[19:24] <slangasek> ginggs: removed
[19:24] <ginggs> slangasek: ta!
[19:25] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.22 => 2.408.23] (desktop-core)
[19:25] <slangasek> ginggs: (removed on all archs, which briefly increases the uninstallable count but will fix itself in the next britney run <shrug>)
[19:27] <slangasek> Laney: starting the baseline run for arm64/bionic as well, now; there's no reason not to throw these all at the wall in parallel AFAICS
[19:28] <Ukikie> Why was ruby2.5 rejected anywho
[19:28] <Ukikie> ?
[19:30] <slangasek> good question; unfortunately only the AA who rejected it, and the uploader, can say
[19:30] <slangasek> in this case they might be the same person (doko?)
[19:32] <slangasek> not sure why that was a manual sync, either, when it should get autosynced
[19:34] <Ukikie> He was very interested in it, even asked #debian-ruby when it'd make it through NEW.
[19:34] <slangasek> sure.  he's an AA himself, and with the timing I assume he self-rejected
[19:41] -queuebot:#ubuntu-release- Unapproved: accepted klibc [source] (zesty-proposed) [2.0.4-8ubuntu4.1]
[19:48] -queuebot:#ubuntu-release- Unapproved: accepted klibc [source] (xenial-proposed) [2.0.4-8ubuntu<IP_ADDRESS>]
[20:00] <LocutusOfBorg> I still think that trying to remove duplicates on autopkgtestsuite infra would already improve it significantly.
[20:01] <LocutusOfBorg> when three people work on the same transition, it is easy to rescore the same retry many times, and with k* tests this becomes a pain easily
[20:01] <LocutusOfBorg> in my opinion this can avoid a lot of useless work on the infra
[20:03] <slangasek> well in the meantime, people should be looking at the queue before retrying.
[20:06] <LocutusOfBorg> this is what we do, but it doesn't scale easily this approach :)
[20:06] <LocutusOfBorg> we sync on telegram before retrying them
[20:06] <LocutusOfBorg> but again, somebody else might want to do it
[20:14] <slangasek> "we sync on telegram" er, wut
[20:19] <slangasek> the place for coordinating around proposed-migration is this irc channel
[20:25] -queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20171012.1-0ubuntu1 => 16.10+17.10.20171113-0ubuntu1] (core) (sync)
[20:48] <elbrus> slangasek: I assume you didn't dive deep in the failing cacti autopkgtest before accepting it today as force-badtest, right?
[20:49] <elbrus> I fixed the autopkgtest, and the latest failure in Debian pointed at a claimed, but not really, fixed CVE
[20:51] <elbrus> not that it matters much, but delta with the version in Ubuntu was less than it appeared and the autopkgtest was showing that
[20:51] <slangasek> elbrus: certainly not a /deep/ dive; I was updating a large number of out-of-date hints for packages that had newer versions in -proposed.  looking at my hint line, it's possible I missed a '/armhf' on cacti however
[20:52] <elbrus> slangasek: ok, ginggs figured that as well
[20:52] <elbrus> good to know
[20:52] <elbrus> well, anyways, the autopkgtest should be fixed again with my latest upload (although I expect /armhf to be currently too slow to test reliably
[20:52] <elbrus> )
[20:53] <elbrus> upload to Debian that is
[20:55] <slangasek> elbrus: this supports my thesis that autopkgtest should always reset the baseline to what's currently in the release pocket, because it eliminates tedious and error-prone hinting
[20:58] <elbrus> slangasek: I am not sure that I follow what you mean
[20:58] <slangasek> elbrus: https://bugs.launchpad.net/britney/+bug/1700668
[21:33] -queuebot:#ubuntu-release- Unapproved: network-manager (xenial-proposed/main) [1.2.6-0ubuntu<IP_ADDRESS> => 1.2.6-0ubuntu<IP_ADDRESS>] (kubuntu, ubuntu-desktop)
[22:44] <doko> slangasek, Ukikie: no, I didn't reject it. it failed to build (test failure), same as for ruby2.3
[22:46] <Ukikie> https://ci.debian.net/packages/r/ruby2.3/unstable/amd64/
[22:47] <slangasek> doko: ah; I have no idea who rejected then, though it all works out since the second auto-sync landed fine in the archive
[22:59] -queuebot:#ubuntu-release- Unapproved: snapd-glib (artful-proposed/main) [1.23-0ubuntu1 => 1.24-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[23:00] -queuebot:#ubuntu-release- Unapproved: gnome-software (artful-proposed/main) [3.26.1-0ubuntu2 => 3.26.1-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[23:48]  * tsimonq2 tries to fix mailman3-core autopkgtests to make sphinx migrate


[22:52] <jose> cjohnston: what's the qa dashboard link? (for the deployed prod instance)
[22:52] <cjohnston> reports.qa.ubuntu.com
[22:53] <jose> ok, thanks
[22:55] <cjohnston> np
[22:58] <jose> submitted MP for qa-dashboard
[22:59] <cjohnston> I see tht
[23:00] <cjohnston> I tagged the qa-dashboard bugs..
[23:01] <cjohnston> some of them may be bitesize but require some investigation to determine the cause
[23:01] <cjohnston> so I didn't mark them as such
[23:01] <jose> ok, and I see some new bugs in summit
[23:02] <cjohnston> :-)


[02:11] <MauroGaspari[m]> <Eickmeyer[m] "OvenWerks, Mauro Gaspari: Sorry "> No worries, busy with work is a very good problem to have in 2020
[14:53] <OvenWerks> Eickmeyer[m]: no worries, I am generally aware that anything I post may not be read for a while :)


[08:12] <persia> ogra: Thanks for chasing the hardware support buttons.  I'm not sure if it's related, but all the extra buttons on my Kohjinsha work with today's MID image.
[08:13] <persia> (this represents an improvement from the last time I tried them)
[08:33] <ian_brasil> persia: wow you have a Kohjinsha ..is it a C3?
[11:16] <lool> ogra: You're getting a BB? :)
[11:17] <ogra> lool, nah, just looking at their website
[11:17] <ogra> i get a n800 tomorrow for 80€ from ebay to play with arm stuff
[11:17] <lool> It's nifty to start hacking on OMAP3, but I don't find it very rich after that
[11:19] <ogra> well, i'm ltsp upstream dev ... that board makes the perfect thn client ... i'm so waiting for being able to support arm thin clients ... with the mythv ltsp modules you can have the perfect VCR with a powerful server in the basement and the beagelboard as client in your living room
[11:20] <lool> Good point
[11:21] <ogra> its the perfect peripherial ...
[11:22]  * ogra would love if we would start working on home automation some day ... thats a real intresting field
[11:30] <ogra> the 128M are somewhat a showstopper for real usage
[11:35] <ogra> though compcache might help a bit :)
[11:48] <ogra> yay
[11:48]  * ogra has the evtouch calibration tool not segfaulting anymore :)
[11:57] <ogra> so lets see ...
[14:28] <persia> ian_brasil_: No: it's the SR series.
[15:27] <lool> ogra: BTW, saw your blog post this morning and: thanks!
[15:27] <lool> We need more bloggers
[15:27] <lool> I should get a blog too
[15:28] <ogra> i'll try to take that role from time to time
[15:28] <ogra> if we want a community we need to be more wordy :)
[15:30]  * ogra takes a break before implementing the rest of the evtouch stuff ... my brain melts
[15:43] <Glasswalker> Hey, I have an old Hitachi Visionplate (or a pile of them to be exact). I am trying to get a newer linux distro to work on them, and ubuntu-mobile sounds perfect. The visionplate is a Crusoe based internet tablet, using pcmcia wifi, and a compactflash card (recognized as an IDE hdd by linux). It uses the MK712 touchscreen driver.
[15:44] <Glasswalker> Any idea if I will be able to get ubuntu-mobile running on it? or any suggestions what I might need to do to get it to work?
[15:46] <persia> Glasswalker: You ought be able to get Ubuntu Mobile to run on them if you have enough extra RAM, but they are larger screens (but similar resolution) than those for which either of the flavours is designed.
[15:46] <Glasswalker> Yeah they use 800x600 res
[15:46] <Glasswalker> I think it has 256MB ram
[15:46] <Glasswalker> might be 128MB
[15:46] <Glasswalker> I am using a 4GB CF card in them
[15:47] <Glasswalker> Will ubuntu mobile play nice with the flash storage?
[15:47] <Glasswalker> (as in it won't thrash it with constant rewrites)
[15:47] <persia> The default base specs look like the low end for Xubuntu: you might try that.  If you have vertical resolution issues, try Ubuntu Mobile (but I think that expects 3D).  You could try Ubuntu MID, but it's not optimised for a screen with that low a DPI, and may not be as pretty.
[15:48] <Glasswalker> Meh looking pretty is the least of my worries
[15:48] <Glasswalker> my main problem right now is I have tried Kubuntu, and DSL linux, Kubuntu I had problems installing, DSL Linux I got to install and boot on it beautifully, but I can't get the touchscreen to work in that one
[15:48] <Glasswalker> Nothing I install seems to support the MK712 touchscreen driver
[15:49] <Glasswalker> (even though it has been officially supported in the kernel since early 2.4 kernel apparently)
[15:49] <Glasswalker> And the lack of any useful information on the visionplate slows progress a bit :) lol
[15:50] <Glasswalker> I mean I could just run them with Midori, but that project got abandoned years ago, and all the software on the latest image for the thing is ancient...
[15:50] <Glasswalker> Do you know if there is a way to cross-compile an optimized kernel for the crusoe? so I can take advantage of it's native performance (Rather than it's rather shoddy x86 pseudo-emulation crap) lol
[15:51] <ogra> persia, ubuntu-mobile expects as much 3D as ubuntu desktop ... i.e. it wil fall back automaticaly to metacity if no GL support for compiz is there
[15:51] <persia> You don't need to cross-compile, you just need to recompile.  Supposedly that was fixed in 7.10, but I've not read any reports about 8.04.
[15:52] <persia> Glasswalker: Specifically, the crusoe *can't* run native code.
[15:52] <persia> ogra: Ah, cool.  Thanks for the correction.
[15:52] <Glasswalker> lmao
[15:52] <Glasswalker> ok fair enough
[15:53] <Glasswalker> ok
[15:53] <Glasswalker> so a recompile on-device will do the trick?
[15:53] <Glasswalker> The only reason I ask is midori is lightning fast on it
[15:53] <persia> Glasswalker: Well, you could replace the code parsing engine with something different, but given the performance of the 256-bit core, it likely emulates x86 faster than it runs native code.
[15:54] <persia> midori feels fast because it's stripped down to the bare essentials, rather than because of the kernel (although compiling with the right options helps)
[15:57] <persia> Glasswalker: But you probably want Xubuntu anyway.  The mobile flavours are more about form factor than performance.  As much as I'd like more users, I'm just not sure it's the best install for your hardware.
[15:58] <Glasswalker> ok fair enough
[15:58] <Glasswalker> The reason I gravitated to it was that it was designed for internet devices...
[15:58] <Glasswalker> But if you think Xubuntu is better for my purpose I will give it a shot.
[15:58] <Glasswalker> (I have to admit the nice touchy feely interface would be nice though lol)
[15:59] <Glasswalker> Although my application will handle 90% of the interface anyway
[15:59] <ogra> the current ubuntu-mobile image i announced yesterday will definately have probs with less than 256M (its just a modified gnome desktop)
[15:59] <Glasswalker> Ahh, so memory is a concern.
[15:59] <Glasswalker> yeah I think these max out at 512MB (if I can find ram for them lol)
[16:00] <ogra> 256 or 512 should be ok
[16:00] <ogra> but 128 is definately not enough for that image
[16:00] <Glasswalker> In the end all I want to use them for is a dedicated orbiter for LinuxMCE, so it basically needs a decent browser, and the ability to compile the orbiter client.
[16:03] <persia> Glasswalker: You may want to create a custom install: start with Ubuntu Minimal, add your favorite browser, an X server, and your client.  If you prepare a package for the client, you only need to compile it once, and can distribute that to all of the machines.
[17:09] <vadi2> where can I find a list of MID models that are known to support Ubuntu MID?
[18:08]  * ogra dances
[18:08]  * ogra has the evtouch calibration working from a running X server ...
[18:11] <venome> ogra: nice, what calibration tool did you use? for me the parameter calibrate "1" seems not working
[18:12] <ogra> venome, i'm currently fixing up the evtouch driver to use hal-input with xorg 1.5
[18:12] <ogra> http://paste.ubuntu.com/50200/ see the hal-set-property cal at the bottom ;)
[18:13] <ogra> i should be dont tonight ... so tomorrow these fixes should hit intrepid
[18:19] <venome> well, it seems pretty straightforward ... but i can't find the ev_calibrate tool ... do you know where to get the source / binary ?
[18:19] <venome> ogra: see my previous question please :)
[18:22] <ogra> ev_calibrate is shipped in the xserver-xorg-input-evtouch package ... but it was very buggy until today, i fixed much of it this morning, wait for my next upload of that package it should basically work then ... what i stil lack on are .fdi files for all supported evtouch devices, currently i only have one for ideaco and one for egalax
[18:24] <ogra> i made a call on planet.ubuntu.com and the ubuntu-devel mailing list about a month ago that people send me their lshal output for systems with known evtouch devices but the feedback was zero :/
[18:24] <ogra> fact is that without .fdi the device wont work in intrepid since xorg 1.5 expects all input devices to be handled by hal
[18:29] <venome> orga: that's quite a lot of work you've done ... i'm looking forward to seeing the results. didn't know there are these changes happeing in intrepid ... Btw. i've got the eGalax too so if you need anything ... but i'm running gutsy where the ev_calibrate seems not yet present ...
[18:34] <ogra> it is in /usr/lib/xf86-input-evtouch/
[18:34] <ogra> even in gutsy
[18:34] <ogra> but it was broken forever in debian and ubuntu
[18:35] <ogra> if you have an egalax, yu could probably even use my .fdi from bug 261873
[18:36] <ogra> (in intreid indeed)
[18:36] <ogra> *intrepid
[18:44] <ian_brasil_> ogra: http://paste.ubuntu.com/50200/ is a generic standalone script for calibrating evtouch..i mean like if your touchscreen is not working you could use this script to make it work?
[18:44] <ogra> ian_brasil_, only if ev_calibate works (which it onyl does since my last upload) and sits in $PATH
[18:45] <ian_brasil_> ok
[18:45] <ogra> and indeed it requires the new hal-input layer
[18:45] <ogra> patiency :) i'll be done tonight with my work ...
[18:46] <ogra> within the next 24h evtouch should work and have a proper calibration mechanism in intrepid
[18:46] <ian_brasil_> ogra: i wasn't trying to rush you at all..just trying to work out in my mind what the script was
[18:47] <ogra> its a ripoff of the calibrate.sh script shipped in the evtouch driver
[18:47] <ogra> with added hal support
[18:48] <ogra> together with the fixes and fdi files from bug 261873 it will make evtouch work flawless and enable you to calibrate from a running X server
[18:49] <ogra> all i need are additional .fdi files or lshal output for devices i dont own
[18:50] <ian_brasil_> the script will be integrated into xserver-xorg-input-evtouch package ?
[18:51] <ogra> yes
[18:51] <ogra> together with a gui tool if i make it in time
[18:52] <ogra> so you will have a "calibrate touchscreen" entry in your gnome control center (or in the moblin control thingie)
[18:52]  * ian_brasil_ wishes he had a touchscreen device to send ogra an .fdi file
[18:52] <ogra> beta freeze is tomorrow ... so i cant promise the gui will be there
[20:14] <RwL> trying to install the new gnome-based ubuntu mobile on a samsung Q1, and I'm getting grub Error 15: File Not Found after install & restart. I'd selected Guided --> Use Entire Disk for partitioning. Help?
[20:20] <RwL> Thinking I ought to manually partition it, but can't find a spec to use
[20:25] <lool> "GLX and DRI passthrough support for Xephyr" woohoo
[20:25] <lool> RwL: We miss the kernel meta-packages at the moment, so the images are still known broken :-/
[20:25] <lool> RwL: Install a kernel manually after installation?
[20:26] <RwL> thanks for the info, lool, but that's probably more work than interests me right now :)
[20:27] <lool> RwL: Wait a little more then ;)
[20:29] <RwL> lool: sure. likely hours, days, weeks? no big deal, just curious to play with this platform
[20:37] <lool> RwL: The image is built daily; you can rsync it to avoid redownloading if you like
[20:37] <lool> It's a matter of days
[20:41] <ian_brasil> ogra: http://paste.ubuntu.com/50238/ its pygtk and very simple but it is a start at least
[20:41]  * lool &


[02:21] <ysf>  I'm trying to install (a fresh, vom alternate cd) koala - but everytime he configures the upstart service he reboots. when i launched the recovery mode i could dpkg --configure the remaining packages but it always reboots after upstart. do you have a hint what i can do to continue the install?  my current iso is: http://mirror.switch.ch/ftp/mirror/ubuntu-cdimage/9.10/ubuntu-9.10-beta-alternate-i386.iso
[06:46] <ara> good morning all!
[09:02] <davmor2> Morning All
[09:08] <davmor2> sbeattie: did you get cjwatson's email about the server re-org,  will that effect our script (I'm assuming it will).
[10:11]  * ara reboots
[10:29] <maxstirner> having a bit of a nitemarish experieence on karmic
[10:29] <maxstirner> i do like going +1 early..
[10:30] <maxstirner> I get x hardware freezes I'm having a hard time finding the relevant bug for
[10:30] <maxstirner> could be due to the usb system also, luks containers arent opened automatically any longer
[10:31] <maxstirner> nautilus seems tohave a hard time opening a windowupon first launch after booting, i have to kill it usually
[11:20] <thekorn> hi,
[11:21] <thekorn> I've a question about a possible bug in gnome's file selector dialog,
[11:21] <thekorn> under which conditions should the icon of an image file show a thumbnail?
[11:23] <thekorn> in the past a thumbnail was shown for 'small' jpg files,
[11:23] <ara> and now?
[11:23] <thekorn> ara: just a black default icon
[11:24] <davmor2> thekorn: might be best asking on #ubuntu-devel or #ubuntu-desktop
[11:24] <thekorn> which looks like this icon which is shonw in cases where an icon was not found
[11:24] <thekorn> okidoki, aking there
[11:24] <ara> thekorn, maybe you have wrong permissions in .thumbnails?
[11:24] <ara> thekorn, or you deleted?
[11:25] <thekorn> hmm, I see this in UNR and desktop live session
[11:25] <ara> thekorn, for every file?
[11:28] <thekorn> ara: no just for every image file
[11:28] <ara> thekorn, what are the contents of the .thumbnails folder? are those under fail?
[11:30] <thekorn> ara: hmm, I don't have a ~/.thumbnails in the live sessions at all
[11:30] <ara> thekorn, maybe then is wrong permissions in the live session
[11:31] <ara> .thumbnails is supposed to be created to hold those thumbnails
[13:52] <fader_> Hi, everybody!
[13:52]  * fader_ waits for "Hi, Dr. Nick!"
[13:54] <davmor2> You'll wait a while you're no doctor nick :P
[13:54] <davmor2> Morning fader_ :)
[13:54] <fader_> davmor2: How was your weekend?
[13:54] <davmor2> normal thanks racing around like a flaming mad man
[13:55] <fader_> Hopefully not testing ISOs though :)
[13:55] <davmor2> I would of been if I could of got to the global jam
[14:26] <smb> Is the oem install option on Kubuntu Karmic amd64 supposed to be working or known to be broken?
[14:27] <davmor2> smb: should be working it did for me for beta
[14:29] <smb> davmor2, Bah, it repeatably hangs for me on the last step (user configuration) at 37% with the process madly trying to read some apparently busy socket...
[14:29] <smb> OK, bug write time then :/
[14:30] <davmor2> smb: I'll have a look after.  It might be something that got introduced post beta
[14:31] <smb> davmor2, That might be. Part of my test is a dist-upgrade before preparing for shipping
[14:35] <smb> davmor2, I'do another round without upgrading. And then one without installing the nvidia binary driver.
[14:35] <davmor2> smb: was there a kernel update in there or installer updates that would break it
[14:36] <smb> davmor2, There was a kernel update too, I believe
[14:36] <smb> davmor2, Installer I am not sure, but I get that ingo
[14:36] <smb> info even
[16:50] <OberonKing> sorry folks, i'm have a issue with the last 2 livecd, alpha 6 and beta don't boot, make the boot process but freeze... can't even enter to a console (ctrl+f1). i try noapic, nolapic, ....etc and nothing.....
[16:50] <OberonKing> ohh, i forget, in virtualBox work without problems
[16:58] <davmor2> OberonKing: sound like a hardware issue.  If you've written a bug then do the following please.  sudo lspci -vvnn > lspci.txt   then add the text file to the bug.  if you haven't written a bug then please do and add as much info as possible.  Try extracting the syslog so people can see where your machine is having issues
[17:03] <OberonKing> davmor2, thanks... the lspci thing done, but... the exit of liveCD it's imposible... if boot without splash option there isn't no error.. and after that, can't responds nothing
[17:03] <davmor2> OberonKing: do you have an intel 915 gfx card in the machine?
[17:05] <OberonKing> nope, Nvidia GF 8600GT, mother asus m2npv-vm, micro athlon64 x2 +4600
[17:09] <sbeattie> davmor2: re the access announcement from colin, I'm pretty certain that only affects releases.ubuntu.com and not cdimage.ubuntu.com, so no change to our scripts.
[17:10] <davmor2> sbeattie: Cool just thought I'd double check :)
[17:10] <sbeattie> davmor2: but speaking of, is there a chance I could get you to test the zsync SRU I pushed out for Bug 420931?
[17:10] <ubot4> Launchpad bug 420931 in zsync "zsync crashes with SIGSEGV when updating dvds" [Medium,Fix committed] https://launchpad.net/bugs/420931
[17:25] <davmor2> sbeattie: right is it just zsync that needs updating?
[17:25] <sbeattie> davmor2: yeah
[17:26] <sbeattie> davmor2: you shouldn't see "Segmentation fault" post update in your cron logs anymore.
[17:26] <sbeattie> (if it's actually fixed it)
[17:26] <davmor2> sbeattie: done
[17:26] <davmor2> I'll let you know tomorrow
[17:28] <sbeattie> davmor2: please do. It should also reduce/eliminate the rcksum-* files left behind in your isodir.
[17:28] <davmor2> Yay
[17:33] <OberonKing> davmor2, fill a bug report, thanks.... it's a pity, I use ubuntu since hoary and never have troubles to run a liveCD
[17:34] <davmor2> OberonKing: the syslog will most likely hold the key which is the problem.