[12:57] <TomaszD> hi, I'm working for a publishing company and we need to have access as early as possible to the final gutsy i386 image, so that we can remaster it and release it in our magazine (about 5000 copies). 18th is the release date, but I'm sure the isos are built a day earlier right? is it possible to get them somehow to avoid the inevitable queues?
[12:58] <pitti> TomaszD: no promises, but we hope to have final images in a few hours
[12:58] <slangasek> "few"
[12:58] <pitti> TomaszD: check the dailies tomorrow morning, they *should* be pretty much final
[12:58] <pitti> TomaszD: but as I said, we can never rule out emergency rebuilds for high-profile bugs
[12:59] <slangasek> TomaszD: we can make sure you have access to our candidate images, but please don't commit to pressing them until they're publically announced as final
[12:59] <TomaszD> pitti, alright. I understand. Thanks.
[01:00] <TomaszD> slangasek, sure I just need something to work on and then send to the office, it'll be pressed on the 19th, but I need time for testing my remastered copy
[01:01] <TomaszD> it would be downright insane having to do all this in one day
[01:01] <slangasek> TomaszD: sure :)
[01:01] <TomaszD> great!
[01:01] <slangasek> TomaszD: well, as pitti mentions, the candidate images are published as dailies, so they'll be available here: http://cdimage.ubuntu.com/
[01:02] <TomaszD> I know that place already, yeah :] 
[01:02] <TomaszD> so I basically need to look here http://cdimage.ubuntu.com/daily-live/current/ tomorrow right?
[01:03] <slangasek> yes
[01:03] <TomaszD> and what is tomorrow for you, because here's it's already tomorrow (01:06AM)
[01:03] <TomaszD> *here
[01:03] <TomaszD> like, in 10hrs would be fine?
[01:04] <slangasek> tomorrow for me is different than tomorrow for pitti, but he means the morning of Oct 16 European time, yes :)
[01:04] <TomaszD> alright, thanks again, will get the daily live in ten hours then and assume it's final, hope I'm not going to die a painful death because of that ;] 
[01:04] <TomaszD> bbl
[01:06] <slangasek> TomaszD: at a minimum, could you check that the md5sum of your downloaded image matches the released image once the release is announced, to make sure we didn't re-roll the image?
[01:07] <TomaszD> slangasek, I will
[01:22] <pawalls> doko, ping
[01:22] <doko> pawalls: just ask
[01:23] <pawalls> doko, Actually, this probably belongs in #ubuntu-bugs. Moving there.
[03:25] <slangasek> tepsipakki: would you be able to condense bug #132716 to a release note item for me?
[03:25] <ubotu> Launchpad bug 132716 in xserver-xorg-video-ati "ATI Driver Gets Black Screen on Radeon 7500 Mobile (Regression)" [High,Confirmed]  https://launchpad.net/bugs/132716
[03:25] <Hobbsee> morning slangasek
[03:25] <slangasek> tepsipakki: there doesn't seem to be a description in the bug of what the recurrent problem is on the 7500, so someone who knows what that issue is will have to do it
[03:25] <slangasek> Hobbsee: morning
[03:45] <bryce> slangasek: fwiw, I just got pinged by alex about 30 min ago with a potential fix for that bug.  I'm building a git snapshot for testing.
[03:50] <slangasek> bryce: it still won't land for final, so I still need a description for release-notes
[04:46] <thully> Hi - I lost suspend as of the -13 Ubuntu kernel (bug #151016), and I'm currently looking to get this debugged.  Any pointers?
[04:46] <ubotu> Launchpad bug 151016 in linux-source-2.6.22 "New in 2.6.22-13: No video after resume from suspend on MacBook" [Undecided,New]  https://launchpad.net/bugs/151016
[04:46] <thully> One thing - I noticed this:
[04:46] <thully> clockevents: remove the suspend/resume workaround^Wthinko
[04:47] <thully> in the changelog, and I'm wondering how I may test "un-removing" this patch.  This patch was applied to the tree at the same time I started having suspend issues...
[04:47] <thully> (un-applied)
[05:00] <redwoolf> is anyone else having trouble with libglib-2.0 on ubuntu? pkg-config says that it can't find glib-config.
[05:07] <Hobbsee> TomaszD: at the very least, you can grab the latest daily, then rsync it against the final - so you dont need to download hte whole lot again
[05:09] <Hobbsee> Mithrandir: we should do that for all -desktop packages (blacklist them from apport).  i've yet to find a useful one.
[05:15] <redwoolf> my error, not a bug. nevermind!
[05:20] <thully> hi - does anyone here know who I should bring kernel regressions to the attention of?  Going from -12 to -13 (and-14) killed suspend for me, and my bug on Launchpad has had no response...
[05:21] <Hobbsee> #ubuntu-kernel, probably when tehy're actually awake
[05:22] <Hobbsee> if it was going to -13, why wasnt it raised earlier?  it's likely too late for gutsy
[05:23] <thully> I reported the bug over a week ago and e-mailed several kernel-related contacts
[05:23] <Hobbsee> ok
[05:24] <thully> and they ignored me (well, one dev told me not to e-mail him)
[05:24] <Hobbsee> i'd assume that you'll have to take that up with the kernel team, as it's their domain.
[05:26] <thully> yeah, these were contacts off the kernel team page... one person mentioned reverting the one patch that seems suspicious, but I can't even find the old code/diffs to do that..
[05:27] <thully> One question - if I applied for/got QA access, would my bugs be looked at quicker?  I've had many issues which I've attached extensive information and even patches that have gone unresponded-to for months...
[05:27] <Hobbsee> possibly.  quite unlikely
[05:27] <Hobbsee> the problem is that there are so many bugs for the kernel stuff, adn so few looking at them
[05:27] <Hobbsee> it tends to be judged by severity, rather than who reported them
[05:28] <thully> yes, this is more frustrating because -12 worked fine, and then -13 messed things up
[05:28] <lifeless> Hi thully
[05:28] <lifeless> there is a dedicated channel, ubuntu-kernel
[05:28] <thully> OK
[05:29] <lifeless> the kernel folk have two problems I know of
[05:29] <lifeless> one is sheer volume as Hobbsee
[05:29] <lifeless> says
[05:29] <Hobbsee> and the other is hardware-specific bugs, and not having access to the hardware?
[05:31] <lifeless> yah
[05:31] <lifeless> and also obviously destabilising things
[05:31] <lifeless> you don't want to break peter by breaking paul
[05:31] <lifeless> erm fix
[05:31] <lifeless> anyhow
[05:31] <lifeless> I've had things sit for months too
[05:31] <lifeless> and I work with the guys
[05:32] <lifeless> I find the best way, with kernel bugs, when the fix is known, is to get someones attention in #ubuntu-kernel, and say 'there is a fix, please look, tell me what is missing to be able to apply it'
[05:32] <thully> I guess i'm curious how I could look at the diffs between kernel revs and try reverting some of the patches.  One of the -13 changes related to suspend/resume, and I'd like to try reverting that
[05:33] <lifeless> the kernel tree is maintained in git
[05:33] <lifeless> there is a wiki page doucmenting where it is and how its maintained
[05:33] <thully> I know nothing about git - particularly doing anything more than checking out the latest
[05:33] <lifeless> you could also just grab the source package
[05:33] <lifeless> yeah
[05:33] <thully> I did, but i only have the latest and not the source from the working version
[05:33] <lifeless> that is a problem, its in git because upstream is primarily
[05:34] <lifeless> oh, right, archive churn will make old source disappear when its superceded
[05:34] <mathiaz> thully: check out kernel.ubuntu.com
[05:35] <thully> mathiaz: THANKS!  that's exactly what I needed.  I figure I'll try reverting suspicious patches one at a time and see what broke it
[05:36] <mathiaz> thully: np. Good luck in your quest ;)
[05:40] <thully> I just found the commits I wanted to try reverting..
[05:43] <thully> Also, in another issue - does anyone here do gnome-power-manager?  There's an annoying bug I reported long ago that I posted a patch for and haven't heard back on...
[05:44] <Hobbsee> thully: ogra: does, and he's german.
[05:45] <thully> OK - will try tomorrow...
[07:19] <tepsipakki> slangasek: sure!
[08:03] <pitti> Good morning
[08:04] <LaserJock> morning pitti
[08:13] <StevenK> Morning pitti
[08:13] <lamont> morning pitti
[08:13] <lamont> :-_
[08:13] <pitti> hey lamont
[08:13] <pitti> good morning LaserJock, and Stevenk
[08:14] <pitti> no need to, by now I can drive the queue tool without looking at it :)
[08:15] <lamont> pitti: remind me when the publisher runs
[08:15] <StevenK> x:03 or so
[08:16] <pitti> right, it's back on auto
[08:18] <pitti> did someone say something? my IRC client beeped
[08:18] <pitti> :-P
[08:18] <TheMuso> LaserJock: I could be that one running it blindfolded if you want. :p
[08:19] <TheMuso> pitti: Load orca.
[08:19] <TheMuso> :p
[08:19] <pitti> TheMuso: I actually tried that; amazing
[08:19] <pitti> needs some getting used to, of course, but I switched off my monitor for a while to try
[08:19] <lamont> the build finished.  why doesn't launchpad want to admit it, i wonder
[08:19] <StevenK> One of the games we used to threaten to play in the office at my previous job was to take people's screens away and force them to use speakup or emacspeak.
[08:19] <TheMuso> pitti: Yeah of course.
[08:19] <TheMuso> StevenK: ROFL.
[08:20] <TheMuso> pitti: Then theres making it speak as fast as it possibly can. That again takes getting used to. :p
[08:21] <pitti> uh, yes
[08:21] <TheMuso> pitti: I'd probably struggle if I had to use GNOME/Orca in a different locale. :) like German.
[08:22] <TheMuso> Espeak would have no problem pronouncing stuff however.
[08:22] <pitti> TheMuso: Deutsch ist kein Problem :)
[08:22] <pitti> TheMuso: I tried espeak with German; it's comprehensible, just sounds funny
[08:22] <pitti> but that's equally true of the English it produces IIRC
[08:22] <lamont> pitti: if you're totally bored, once https://edge.launchpad.net/ubuntu/+source/kdesdk/4:3.5.8-0ubuntu1/+build/408426 admits to being done, a manual publisher run to kick kdewebdev in the butt will help it finish sooner... (iz 70 minute avg-pkg-build-tiem)
[08:22] <TheMuso> pitti: Yeah its getting used to synthesized speech in general.
[08:23] <lamont>  gutsy hppa   Successfully built  (ACCEPTED)
[08:23] <lamont> pitti: so if you're bored, :-)
[08:23] <pitti> lamont: can do, but the current one is still running
[08:24] <lamont> pitti: ah, ok.
[08:24] <lamont> anyway, sync of the mirror finished, heading home.
[08:24] <pitti> lamont: I'll start another one right after that, just for you :)
[08:24] <lamont> some days, sneakernet sucks
[08:24] <torkel> TheMuso: just add 'mate' at the end of every sentence? :-)
[08:24] <StevenK> Oh yes, I love jigdo.
[08:24] <lamont> pitti: damn.  what's that make it now, 20 beers?
[08:25] <pitti> lamont: not all at once, please
[08:25] <lamont> lol
[08:25] <TheMuso> Jigdo absolutely rocks for those who are quota deprived. :)
[08:25] <TheMuso> torkel: lol
[08:25] <lamont> anyway, afk for about 30-40 min, then back online for about 2 min before falling into bed.
[08:25] <StevenK> I can build an image in about 3 minutes thanks to my local mirror.
[08:25] <TheMuso> Now all we need is something similar for live CDs. :p
[08:26] <TheMuso> Stop bragging already StevenK.
[08:26] <pitti> TheMuso: rsync is not too bad for those
[08:26] <TheMuso> pitti: If quota weren't a problem, yes.
[08:26] <TheMuso> s/weren't/wasn't/
[08:26] <pitti> StevenK: did you ever try rsyncing the dvd .template against the desktop CD for jigdoing a DVD?
[08:26] <StevenK> pitti: rsync'ing a live CD still manages to take me about 45 minutes.
[08:26] <pitti> TheMuso: it is for me, too (3 GB/7 days)
[08:27] <StevenK> pitti: So it takes you two weeks to download a DVD?
[08:27] <pitti> StevenK: no, it doesn't
[08:27] <pitti> StevenK: simple solution: don't download DVDs :)
[08:27] <pitti> StevenK: well, I downloaded some at debconf, or in the London office
[08:27] <StevenK> I have to say, my plan is far better - 24Gb/month, with 12am - 12pm uncounted.
[08:28] <TheMuso> StevenK: The interndoe plan we stared on was good value, till it was changed.
[08:28] <TheMuso> s/interndoe/internode/
[08:29] <StevenK> I'm eyeing Exetel's ADSL2+ plans.
[08:33] <LaserJock> it may not be the fastest, but I can chug away as long as I like
[08:33] <Burgundavia> indeed
[08:33] <Burgundavia> this metered internet stuff is crap
[08:34] <Fujitsu> LaserJock: You mean it's actually unlimited?
[08:34] <Fujitsu> Very well named, obviousl.
[08:34] <StevenK> Look at the map of the Internet that turned up on Planet Debian and you'll see why.
[08:34] <Fujitsu> *obviously.
[08:35] <StevenK> The US has all the bandwidth, and the rest of the world has a little bit.
[08:35] <Burgundavia> most people in Canada are not de jure unlimited, but de facto are
[08:35] <pitti> stgraber: FYI, ISO tracker staffed, DVDs coming
[08:35] <Mithrandir> StevenK: heh, sure? :-P
[08:35] <Burgundavia> I had a friend who got warned at 56 GB in a single month
[08:35] <Mithrandir> I only have a 6.5MBit here, that's true.
[08:36] <Burgundavia> pitti: do you have an approx. time of day that you plan to release the final ISO?
[08:36] <pitti> Burgundavia: the ones in the tracker *are* the final ones (hopefully, *crossing fingers*)
[08:36] <Burgundavia> no, I mean send the public announcment
[08:37] <pitti> Burgundavia: oh, no idea; slangasek will do it, but traditionally it's around noon
[08:37] <Burgundavia> noon UTC?
[08:37] <pitti> yeah
[08:37] <Burgundavia> on the 18th?
[08:37] <Fujitsu> Yay, another `omg I just discovered the ISOs in .pool let's tell everybody to get them now!' coming soon.
[08:37] <liw> oh, there's new ISOs? I was waiting for the tracker's e-mails about them
[08:38] <pitti> stgraber: hm, that didn't work so well; all the flavours just say "ubuntu"; can you please have a look?
[08:38] <pitti> liw: freshly added, you shuold get them, unless there's something else broken
[08:39] <liw> ah yes, there's the e-mail
[08:39] <liw> timing is everything
[08:39] <pitti> hi dholbach
[08:40] <dholbach> good morning
[08:40] <dholbach> hey pitti
[08:40] <Fujitsu> Hi dholbach.
[08:40] <dholbach> hey Fujitsu
[08:41] <Burgundavia> LaserJock: can I get a final proof read of my story in the fridge queue?
[08:58] <LaserJock> Burgundavia: yep, one sec
[09:01] <LaserJock> Burgundavia: Day 2 right?
[09:01] <Burgundavia> LaserJock: nah, it is live already :)
[09:01] <Burgundavia> don';t worry, mdke got it
[09:01] <LaserJock> pfft
[09:02] <Burgundavia> you can look at it if you want
[09:02] <Burgundavia> top story
[09:02] <Amaranth> Burgundavia: Why the hate on packagekit? :)
[09:02] <Amaranth> Burgundavia: It seems to be explicitly designed to replace gnome-app-install and update-manager
[09:03] <Burgundavia> Amaranth: not, it is designed to fit underneath them
[09:03] <Burgundavia> and I don't hate it
[09:03] <Burgundavia> just don't think it is good for hardy
[09:03] <Amaranth> I meant the GNOME UI they have for it
[09:03] <LaserJock> I was looking at packagekit yesterday
[09:03] <Amaranth> The whole idea came out of 'making gnome-app-install work everywhere'
[09:03] <LaserJock> or rather saw what it was and put on my list of "hmm, that could be interesting"
[09:03] <Burgundavia> well, tbh their UIs suck
[09:03] <Burgundavia> g-a-i is much better
[09:04] <Burgundavia> they expose too much of the underlying package crap to the user
[09:04] <Amaranth> Burgundavia: But not much better and packagekit is only 6 week sold
[09:04] <Burgundavia> but that is something Fedora has always done
[09:04] <Amaranth> Burgundavia: So imagine what another couple months will do
[09:04] <Burgundavia> sadly, I consider that a spurious argument
[09:04] <Burgundavia> they had all the time to study every updater in existance
[09:04] <Burgundavia> and every pacakge installer
[09:04] <Burgundavia> and they still made the same mistakes
[09:05] <Amaranth> Well, the main problem is gnome-app-install uses a hack to do what it does
[09:05] <Burgundavia> I don't disagre
[09:05] <Burgundavia> but the UI is better than anything out there
[09:05] <Amaranth> it snags every .desktop from the entire archive and matches it to a package
[09:05] <Amaranth> that could be put in packagekit though
[09:05] <Burgundavia> without better package metadata, that problem is not going away
[09:05] <Burgundavia> package kit will not solve that
[09:07] <Burgundavia> having packagekit provide package metadata is pretty much the same thing as package information itself
[09:07] <Burgundavia> packagekit should understand how to get that out of the distro, but it is the distro who needs how to figure out how to feed that to packagekit
[09:09] <Amaranth> I'm not understanding your problem with that
[09:09] <Burgundavia> packagekit, if it is to be adopted, needs to be a shim over existing packaging systems
[09:10] <Burgundavia> if it starts replacing bits of the packaging system too early, adoption will fail
[09:10] <Mithrandir> I must confess as to not understanding what problem PK is trying to solve
[09:10] <Burgundavia> one of those bits is package metadata
[09:11] <highvoltage> Burgundavia: read about the AppArmour layoffs?
[09:11] <Burgundavia> one problem would be to have a third party app be able to say "install java" and it just work on Fedora, Ubuntu, etc.
[09:11] <Burgundavia> highvoltage: yep
[09:12] <Burgundavia> the other is for bigger projects like OO.o or GNOME be able to say "install this optional dep"
[09:12] <Burgundavia> you already see this with gnome-games
[09:12] <Burgundavia> try enabling 3d mode in chess and see what happens
[09:12] <Burgundavia> a 3rd major point is to move the idea of package stuff out of the distro silo
[09:15] <liw> I suspect that moving stuff out from distros will mean stuff won't be adhering to distro policies, meaning worse integration and interesting bugs during transitions, and longer transitions
[09:16] <Burgundavia> you are conflating the actual packaging with the UI bits that sit above them
[09:16] <Burgundavia> packagekit is designed to solve the latter, autopackage the former
[09:16] <mdke> liw: right. A good example is that the packagekit guys have recently been discussing questions about how easy it should be to add third party repositories which may endanger the system. Ubuntu developers have also been discussing the same thing, if they come to a different conclusion, how will the two be reconciled?
[09:16] <Amaranth> It's more or less so every distro can do what we do with 'find a package that handles this mimetype'
[09:17] <Amaranth> and cross-distro consistency with the updater UI and such
[09:17] <Burgundavia> because every distro rewriting the updater is crazy
[09:17] <Burgundavia> iven they all do 98% of the same thing
[09:18] <Amaranth> and if it gets to the level of gnome-app-install it's also so every distro has the same UI for installing applications
[09:18] <Amaranth> GUI applications, anyway
[09:18] <Amaranth> it's more or less everything we already do but with a better design and cross-distro
[09:18] <Burgundavia> means gnome-app-install can actually become a GNOME app
[09:25] <dholbach> the problem we have is that packages ask questions, that's not possible with packagekit in any way
[09:26] <Burgundavia> indeed, a serious issue
[09:26] <Burgundavia> the whole EULA thing is a bit messy as well
[09:28] <liw> Burgundavia, hmm... if PackageKit helps move things out of the "distro silo", how does this not move things out of the control of the distro?
[09:29] <Burgundavia> liw: because the packaging itself and all those bits remain with teh distro
[09:29] <Burgundavia> PackageKit is mostly for the end-user facing apps
[09:30] <Burgundavia> ie: the updater and the equiv of gnome-app-install
[09:30] <Burgundavia> both of which could easily be on any LInux system, even a source based oen such as emerge
[09:30] <Amaranth> dholbach: Is dpkg the only package system that does that?
[09:31] <liw> Burgundavia, how does the packaging remain with the distro if the packages do not come from the distro?
[09:31] <Mithrandir> Amaranth: rpm doesn't allow it, at least.
[09:31] <Burgundavia> afaik, rpm devs have rejected the whole "rpm needs EULAs" stuff
[09:31] <Burgundavia> liw: no, you misunderstand
[09:31] <Amaranth> I only have basic understanding of rpm and don't know anything about conary
[09:31] <mdke> dholbach: technical problems can often be solved though; whereas if there is a problem with the model; i.e. policy decisions which should be taken by distros being taken in the upstream project, then that's harder to fix...
[09:31] <Burgundavia> this is a layer on top of the existing packaging system
[09:31] <liw> Burgundavia, I understand the layering
[09:31] <Amaranth> liw: This is gnome-app-install
[09:32] <Burgundavia> and update-manager
[09:32] <liw> I understand all that
[09:32] <Amaranth> liw: gnome-app-install just tells apt to install stuff (through synaptic)
[09:32] <Amaranth> liw: it doesn't do any packaging stuff
[09:32] <stgraber> pitti: fixed
[09:32] <Burgundavia> packagekit doesn't really how stuff gets installed
[09:32] <liw> I am discussing specifically the point of "distro silo" and making it common to install packages from outside the distro
[09:32] <Amaranth> liw: Why would this make it 'common to install packages from outside the distro'?
[09:32] <Burgundavia> most users do that anyway
[09:33] <Amaranth> liw: Any more than synaptic and gnome-app-install do
[09:33] <pitti> stgraber: thanks
[09:35] <liw> yes, many users do that, and yes, it's possible with existing tools, but it's not a "major point" for them to make it easy for users to install packages from any random sites from the net, which is what I understood from Burgundavia's statement is one of the goals of PackageKit
[09:35] <Burgundavia> liw: umm, not really
[09:35] <mdke> well, it's been discussed anyway
[09:35] <Burgundavia> the goal is to smooth out installs of packages
[09:35] <mdke> I don't know what the conclusions have been, they might be the same as Ubuntu's and they might not
[09:35] <Burgundavia> a common place to discuss is the server stuff
[09:35] <Burgundavia> such as IBM's db2
[09:36] <Burgundavia> never going to be packaged for Ubuntu
[09:36] <Burgundavia> but what if it needs a dependency/
[09:36] <Burgundavia> ?
[09:36] <pitti> stgraber: hm, ubuntu desktop is 16.1, although I added them as 16; alternates are 16.1, but don't show up
[09:36] <Burgundavia> with PK, they could create it so that it could install those deps by writing a single script, and not dozens
[09:36] <pitti> stgraber: I just tried to re-add 16 as desktop, but that doesn't seem to work?
[09:37] <pitti> stgraber: ubuntu alternates added
[09:37] <stgraber> pitti: ok, so I just have to change Ubuntu Desktop from 16.1 to 16 ?
[09:38] <pitti> stgraber: right
[09:39] <Mithrandir> Burgundavia: this is basically just LSB modules, again
[09:39] <liw> Mithrandir, yeah
[09:40] <Mithrandir> Burgundavia: also, DB2 is certified on Ubuntu.  I would not be surprised if you could get .debs of it too
[09:40] <Burgundavia> yes, but unlike last time, this one might stick, as it is not parachuted in from above
[09:41] <fabbione> Burgundavia: db2 is packaged for dapper...
[09:41] <fabbione> Burgundavia: archive.canonical.com ?
[09:41] <Mithrandir> it seems very much so to me.  I honestly don't see what problem it's trying to solve which isn't easier solved in other ways.
[09:42] <Burgundavia> which other ways?
[09:42] <Mithrandir> ship anything you need over LSB yourself.
[09:42] <stgraber> pitti: looking at the logs, you added the 20071016 Ubuntu desktop at 08:33:32, then the 16.1 at 20071016.1. So it doesn't let you add the Desktop ones again as they already exist on the DB. I'll simply hide the Ubuntu desktop 20071016.1 and show the 20071016 so if we have a 20071016.1 for Ubuntu desktop today we won't have to add them again but simply reactivate them
[09:43] <pitti> stgraber: hm, sorry if I screwed up; thanks for fixing
[09:45] <Burgundavia> LSB is a very static solution
[09:45] <stgraber> pitti: just ping me if you have to add a new Ubuntu Desktop set today (with version number 20071016.1) so I simply reactivate the 20071016.1 ones instead of creating them again
[09:45] <pitti> stgraber: I will, thanks (let's hope it's not necessary, though :)
[09:45] <stgraber> yes :)
[10:23] <heno> *** Gutsy-final-candidates are up and ready for testing https://iso.qa.stgraber.org/ ***
[10:24] <popey> ooo
[10:30] <slangasek> Riddell, ogra1: are you guys planning separate release announcements for Edubuntu and Kubuntu?
[10:31] <ogra1> slangasek, i have to talk to RichEd about that, Riddell usually does his own
[10:34] <pitti> heno: btw, is https://wiki.ubuntu.com/Testing/Phased/Two ok for you? not sure how many bugs you want there, and some are a bit obscure, but I just added everything nontrivial
[10:38] <liw> seb128, in #147071 you say the bug has been reported already, but it's not marked as a duplicate in launchpad, and I can't the other report
[10:39] <heno> pitti: looks good. It will probably take some work to track down people who can test them, but that's fine
[10:40] <heno> *** REQUEST FOR TESTING: Firefox candidate packages for Dapper, Edgy and Feisty are posted at: https://mozilla.qa.stgraber.org/ ***
[10:44] <seb128> bug #147071
[10:44] <ubotu> Launchpad bug 147071 in nautilus "When moving files to trash in Live session, nothing appears in trash" [Low,Invalid]  https://launchpad.net/bugs/147071
[10:45] <seb128> liw: there is ten of bugs about trash applet not working correcly, maybe there is no exact duplicate of this one though
[10:45] <sladen> possibly bug #34247
[10:45] <ubotu> Launchpad bug 34247 in gnome-applets "Trash always empty." [Medium,Confirmed]  https://launchpad.net/bugs/34247
[10:46] <sladen> sorry, bug #42471
[10:46] <ubotu> Launchpad bug 42471 in casper "[Dapper LiveCD Beta2]  Deleted items are not visible in Trash" [Medium,Confirmed]  https://launchpad.net/bugs/42471
[10:46] <seb128> liw: things like bug #32466 bug #72468 bug #12494
[10:46] <ubotu> Launchpad bug 32466 in gnome-applets "External disk trash not shown by trash applet" [Medium,Confirmed]  https://launchpad.net/bugs/32466
[10:46] <ubotu> Launchpad bug 72468 in gnome-applets "Trash looks empty, isn't" [Medium,Confirmed]  https://launchpad.net/bugs/72468
[10:46] <ubotu> Launchpad bug 12494 in gnome-applets "Remote files deleted by DND to the trash applet are not refreshed" [Unknown,Confirmed]  https://launchpad.net/bugs/12494
[10:47] <liw> seb128, right, so there's lots of duplicates, good; I get it from the live cd, fwiw (the one currently being tested for release on Thursday)
[10:47] <liw> in the live session, even
[10:49] <sladen> it'll probably be something like  inotify not working with unionfs
[11:09] <rohan> what package does kubuntu use to display OSD when i control volume using volume keys on keyboard ? because atm in gutsy the OSD is not working
[11:21] <Whoopie> rohan: although using gnome, I guess, it's KMilo
[11:21] <rohan> Whoopie: ah i see.. since atm it doesn't seem to be working
[11:22] <rohan> i wonder whether it'd work for a new user though
[11:44] <asac> ogra1: currenlty live session testing - move to trash appears to auto-delete the files ... e.g. nothing in trash afterwards. is that a feature for edubuntu?
[11:45] <liw> asac, it's a bug, happens with the ubuntu live cd as well
[11:45] <ogra1> asac, bug #32466 bug #72468 bug #12494
[11:45] <ubotu> Launchpad bug 32466 in gnome-applets "External disk trash not shown by trash applet" [Medium,Confirmed]  https://launchpad.net/bugs/32466
[11:45] <ubotu> Launchpad bug 72468 in gnome-applets "Trash looks empty, isn't" [Medium,Confirmed]  https://launchpad.net/bugs/72468
[11:45] <ubotu> Launchpad bug 12494 in gnome-applets "Remote files deleted by DND to the trash applet are not refreshed" [Unknown,Confirmed]  https://launchpad.net/bugs/12494
[11:45] <ogra1> asac, see the backlog ;)
[11:45] <liw> asac, the files are in ~/.Trash, the applet and nautilus just don't show them
[11:45] <asac> liw: ogra1 thanks
[11:50] <asac> ogra1: which bug should i attach to the test case?
[11:50] <ogra1> heh, no idea, seb128 is there a master for the trash bug ?
[11:51] <seb128> why does everybody notice that the trash is not working correclty now? that's the case this warty ;)
[11:51] <ogra1> heh
[11:52] <asac> seb128: maybe it was added to the iso testplan just now?
[11:52] <seb128> ogra1: not really, pick any of the ton of gnome-applets bug about that
[11:53] <seb128> asac: no idea
[11:53] <ogra1> asac, ^^^^
[11:53] <asac> ok i use bug 12494 then
[11:53] <ubotu> Launchpad bug 12494 in gnome-applets "Remote files deleted by DND to the trash applet are not refreshed" [Unknown,Confirmed]  https://launchpad.net/bugs/12494
[11:54] <stgraber> seb128: the "move to trash" test was added to https://wiki.ubuntu.com/Testing/Cases/UbuntuDesktop in the Live session testing part :)
[11:54] <seb128> stgraber: who did that?
[11:54] <stgraber> Henrik probably
[11:54] <asac> stgraber: i filed it now ... so maybe we should remove it temporarily to not trigger dupes :)
[11:54] <seb128> stgraber: can that be reverted? there is no real sense to add things known to be b0rked there
[11:55] <stgraber> seb128: I'll add a comment next to it so people know that it's not supposed to work
[11:55] <seb128> stgraber: thanks
[12:02] <TheMuso> c
[12:02] <TheMuso> ugh
[12:03] <stgraber> asac: Why did you mark Edubuntu's Live Session as failed ? only for the Trash applet thing ?
[12:16] <soren> If anyone else used to use kees' greasemonkey script for adding karma and team emblems to lp pages, here's a patch that makes it work again after changes to edge's UI yesterday.  http://people.ubuntu.com/~soren/lp_karma_update.diff
[12:18] <tkamppeter> pitti, ping
[12:18] <pitti> hi tkamppeter
[12:19] <tkamppeter> about bug 152293, are you sure that you have the 3ubuntu10?
[12:19] <ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed]  https://launchpad.net/bugs/152293
[12:20] <pitti> tkamppeter: I have whatever is on the current CDs, but that should be 10
[12:20] <pitti> tkamppeter: I'm currently doing two more test installs (alternate this time); I'll check with those, too
[12:22] <tkamppeter> pitti, so then it seems that the CUPS startup script exits and the daemon still takes an unreasonably long time to start listening. Then the cups-pdf package would need to launch a background process to wait for CUPS in a loop to create the queue, which can happen half an hour later, if needed.
[12:23] <pitti> tkamppeter: it would be interesting to compare various installations; if it's a race condition, I might just have been unlucky
[12:23] <liw> arguably the cups startup script should wait until it's been started
[12:24] <tkamppeter> pitti, the case that it happens seems to be rare at least, otherwise the problem had been reported earlier. I always got a queue (my network has 2 computers, 5 printers, and ~10 queues).
[12:25] <pitti> tkamppeter: *nod*
[12:25] <pitti> tkamppeter: I'm doing several vmware installs in parallel, so it's slow and latent
[12:26] <tkamppeter> liw, years ago I had a similar problem and had reported an upstream bug then, which got actually fixed. Seems that now there are new discrepancies.
[12:27] <tkamppeter> pitti, and I have only native installations ...
[12:27] <asac> stgraber: i commented on it ... yes, just the trash.
[12:27] <asac> stgraber: its not marked as serious of course
[12:29] <tkamppeter> pitti, and there are two cases: "force-reload" probably does a "kill -something" on the CUPS daemon and "kill" does not wait for reactions, but "restart" actually kills CUPS and then runs "cupsd", and the command "cupsd" probably really only exits if CUPS really starts to listen.
[12:31] <asac> ok bad news ... edubuntu install leaves me with a broken X ... ending in a console session :(
[12:32] <pitti> eww
[12:32] <tkamppeter> pitti, so a proposed fix could be to not call "/etc/init.d/cupsd force-reload", but this would go directly into the higher impact restart, which kills running print jobs ...
[12:34] <asac> pitti: .. so here what i did: i did a live session and tried to enable desktop effects before install. live session downloaded nvidia driver ... now xorg.conf has nvidia driver, but nvidia glx is not installed
[12:35] <tkamppeter> pitti, but is restarting of CUPS required at all? From CUPS 1.2 on (we are at 1.3 already) adding a backend and/or a PPD does not require restarting CUPS, why does this package restart CUPS at all ...?
[12:35] <pitti> tkamppeter: don't ask me :) worth trying, I figure; if lpinfo -v picks up new backends without restart, that would be great
[12:37] <asac> cjwatson: evand: what info do you need before i reboot (read a few lines above)
[12:37] <tkamppeter> pitti, that is the case, replace the unconditional restarting by starting if it is not running and nuke the "sleep 3". Starting CUPS with "/ect/init.d/cupsys start" exits only when CUPS starts to listen (or when CUPS fails).
[12:43] <cjwatson_> asac: all the installer logs
[12:44] <tkamppeter> pitti, should we fix the cups-pdf issue before Gutsy? Or do an SRU? Or nothing?
[12:44] <cjwatson_> asac: if you've rebooted into the installed system, everything in /var/log/installer/
[12:44] <cjwatson_> sounds like a bug in the restricted-manager hook that's meant to install the packages it needs
[12:44] <popey> is there a netinst gutsy iso kicking about?
[12:45] <popey> oop, nvm, found it
[12:45] <pitti> tkamppeter: at most an SRU, fixing it in gutsy itself is too late
[12:46] <cjwatson_> asac: are you still in the live session or not?
[12:47] <ogra> asac, thats -desktop, right ?
[12:47] <cjwatson_> ogra: yes, he said "live session"
[12:47] <ogra> just wanted to be sure
[12:47] <asac> cjwatson_: no ... i have rebooted. live-sessino worked
[12:48] <asac> ogra: yes ... livecd
[12:48] <asac> cjwatson_: i can probably reproduce that if you want
[12:48] <asac> cjwatson_: but let me first file the bug ... which package?
[12:48] <cjwatson_> err
[12:48] <cjwatson_> restricted-manager I think
[12:48] <cjwatson_> though it could be ubiquity
[12:49] <asac> hmm ... i will use both then :)
[12:49] <cjwatson_> pitti: I note that the update_installed_packages function doesn't close the filehandle - relying on Python's garbage collection to do that for you in a timely fashion isn't reliable
[12:49] <cjwatson_> Python code should generally do an explicit f.close()
[12:49] <asac> cjwatson_: what info would you need from the live-session?
[12:51] <cjwatson_> asac: /var/cache/restricted-manager/installed_packages would be good (you don't have to install to do that, just do the same stuff you did in r-m)
[12:51] <pitti> cjwatson_: oh, ok; there goes another convenience...
[12:52] <cjwatson_> don't know if that's the reason for this though
[12:55] <tkamppeter> pitti, bug is now marked appropriately.
[12:55] <pitti> cjwatson_: fixed this and some other instances in trunk, thank you
[12:58] <pitti> I'm off IRC for about an hour to test-reinstall my workstation
[01:08] <asac> cjwatson_: 153254
[01:13] <pitti_live> hi jamiemcc
[01:14] <jamiemcc> hi pitti_live
[01:14] <pitti_live> seb128: hm, pidgin still has the bouncy input line by default :(
[01:15] <cjwatson_> asac: I don't see /var/cache/restricted-manager/installed_packages there
[01:16] <cjwatson_> Oct 16 10:07:12 ubuntu ubiquity: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.22/nvidia-glx_1.0.9639+2.6.22.4-14.9_i386.deb  Could not resolve 'archive.ubuntu.com'
[01:16] <tkamppeter> pitti_live, added proposed fix to bug 152293, not doing the unneeded restart of CUPS.
[01:16] <ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed]  https://launchpad.net/bugs/152293
[01:16] <cjwatson_> asac: was this a networkless install?
[01:17] <cjwatson_> hmm, apt-install perhaps needs to learn how to queue until after apt-setup
[01:18] <asac_> cjwatson_: no the network worked through network manager ... the driver was successfully downloaded and insatlled during live-session
[01:20] <cjwatson_> asac_: in addition to installed_packages, could I also have /var/lib/ubiquity/apt-installed?
[01:21] <asac_> cjwatson_: from live session?
[01:21] <cjwatson_> yes
[01:21] <cjwatson_> both
[01:21] <cjwatson_> I wonder if install_extras is just broken
[01:22] <cjwatson_> oh, nvidia-glx* isn't on the Edubuntu CD
[01:23] <cjwatson_> fixing this properly will probably have to wait for networkless-installation-fixes in hardy; any attempt to fix it now stands a good chance of breaking other things :-(
[01:23] <asac_> cjwatson_: isn|t it non-free?
[01:23] <cjwatson_> we have other restricted packages on our CDs
[01:25] <cjwatson_> it's a real bug, but that code is horribly, horribly hairy and prone to breakage. I patched it up as best we could for gutsy
[01:27] <asac> cjwatson_: well ... but ending up in a console because one tried to enable desktop effects is really a show stopper imo ... given that most nvidia cards are probably affected
[01:27] <asac> cjwatson_: maybe we can prevent nvidia drivers to be installed during live session as a hack?
[01:28] <pitti_live> asac: we could, but that would again require code changes
[01:28] <pitti_live> I don't see how to do it with just CD mangling
[01:30] <cjwatson_> I'm confused about how they got installed, given that we now don't even generate the nvidia modules in the live session
[01:30] <cjwatson_> does Edubuntu have room to add nvidia-glx-new to the CD?
[01:30] <pitti_live> cjwatson_: yes, if we kill one or two langpacks
[01:30] <asac> cjwatson_: does ubuntu have that package?
[01:30] <ogra> i think so, let me chack in detail
[01:30] <cjwatson_> asac: yes
[01:31] <cjwatson_> use rmadison
[01:31] <pitti_live> IIRC I added it to amd64, too
[01:31] <cjwatson_> rmadison -u ubuntu nvidia-glx-new
[01:31] <ogra> daily has 7M spare
[01:31] <asac> cjwatson_: ok then overall severity isnt that high most likely. i will try to reproduce it with ubuntu livecd though to be sure
[01:31] <cjwatson_> nvidia-glx-new is 5MB
[01:31] <ogra> daily-live is around 5
[01:31] <cjwatson_> for the record, Ubuntu desktop CDs don't have nvidia-glx* either
[01:31] <cjwatson_> nvidia-glx-new is in the ship seed
[01:32] <cjwatson_> ogra: only the live CD matters here
[01:32] <ogra> well, we dont have langs to drop there
[01:32] <asac> cjwatson_: /var/lib/ubiquity/apt-installed doesnt exist in live session before install ... i will now reboot to the install i previously did and attach that file
[01:32] <ogra> so it's a va banque game
[01:32] <cjwatson_> I'm not confident about this fix; I'd prefer a release note
[01:32] <cjwatson_> asac: odd, are you sure?
[01:32] <amitk> ogra: see http://people.ubuntu.com/~amitk/edubuntu*.jpg
[01:32] <asac> cjwatson_: let me reconfirm
[01:32] <cjwatson_> apt-install should create it, and nothing deletes it
[01:32] <cjwatson_> oh, no
[01:32] <amitk> congrats
[01:32] <asac> ubuntu@ubuntu:~$ ls /var/lib/ubiquity
[01:32] <asac> ls: /var/lib/ubiquity: No such file or directory
[01:33] <pitti_live> brb, booting into installed system
[01:33] <ogra> amitk, !!! WOW !!!
[01:33] <cjwatson_> asac: did you start ubiquity again?
[01:33] <cjwatson_> it deletes that file on startup
[01:34] <amitk> ogra: this is at a local (Finnish) electronic store
[01:34] <asac> cjwatson_: no ... i just opened the appearence dialog and then installed the nvidia packages through r-m
[01:34] <cjwatson_> asac: apt-installed won't exist until you've run through the installer
[01:34] <cjwatson_> installed_packages exists beforehand
[01:34] <ogra> amitk, thats extremely cool :D
[01:35] <asac> cjwatson_: ok ... i already attached the restricted-manager installed_packages to the bug ... let me get the other from the real install
[01:37] <cjwatson_> I don't need that
[01:37] <cjwatson_> oh, I do need apt-installed :-)
[01:37] <cjwatson_> ENOTENOUGHCOFFEE
[01:38] <geser> Hi pitti
[01:39] <asac> cjwatson_: unfortunately /var/lib/ubiquity doesn't exist :( ... maybe apt-get install nvidia-glx removed it?
[01:40] <stgraber> Is rhythmbox supposed to trigger the automatic codec installation thing when trying to play or import a mp3 file ?
[01:41] <stgraber> We have that in the Desktop testcase but it seems to only work with totem
[01:43] <pitti> hi geser
[01:44] <pitti> asac, cjwatson_: FWIW, in my fresh desktop installation, find /var -name ubiquity* is empty
[01:44] <asac> stgraber: seb128 would know ^^^
[01:44] <asac> pitti: ack
[01:45] <cjwatson_> pitti: it won't be there after reboot.
[01:45] <cjwatson_> asac: have you completed an installation yet?
[01:46] <cjwatson_> asac: run r-m, run through ubiquity to the end, DO NOT REBOOT, grab file
[01:46] <asac> cjwatson_: ok
[01:46] <asac> redoing install then
[01:48] <seb128> stgraber: no, easy codec installation has not been implemented for rhythmbox yet
[01:48] <stgraber> seb128: ok, so I'll update the Desktop testcase for this one too :)
[01:48] <seb128> graaa
[01:49] <seb128> who made the testcase? would be a good idea to actually made them profread by somebody from the corresponding team
[01:49] <stgraber> It probably was Henrik or Brian, I'll ping them when they show up
[01:55] <seb128> stgraber: thanks
[02:04] <ogra> hmm, why doesnt vbox like me today ?
[02:08] <asac> cjwatson_: apt-installed attached .. anything else?
[02:11] <cjwatson_> no, that's fine
[02:18] <ScottK> Is there a core-dev with a few minutes to upload a source backport from Gutsy to Feisty?
[02:19] <ScottK> The debdiff in Bug #151308 should be all that's needed to get the feisty-backports clamav up to date.
[02:19] <ubotu> Launchpad bug 151308 in feisty-backports "please backport Clamav from Gutsy to Feisty " [Undecided,Confirmed]  https://launchpad.net/bugs/151308
[02:29] <gnomefreak> ScottK: is clamav fixed in gutsy? someone yesterday got the post install script failure
[02:29] <ScottK> gnomefreak: But #?
[02:29] <ScottK> But/Bug
[02:29] <gnomefreak> we had to remove it to continue upgrades but that is last i heard.
[02:29] <gnomefreak> ScottK: i told him to file one but never got a bug number for it
[02:29] <ScottK> gnomefreak: No bug was filed, so I know nothing about it.
[02:30] <gnomefreak> ScottK: k if i see it again a bug will be reported before he gets help :)
[02:30] <ScottK> We've had a lot of testing of the upgrades during the Gutsy cycle so I doubt it was a clamav specific problem.
[02:32] <gnomefreak> using dpkg to remove it since it was never configured and wouldnt fixed it, i dont remember exacterror.
[02:43] <ogra> hmm
[02:43] <lool> Against which package would I report a bug against the menu displayed when booting a CD (the very first menu)?
[02:43] <ogra> doesn anyone else have probs with virtualbox ?
[02:43] <lool> ogra: Depends which, I saw many :)
[02:43] <ogra> i used to use the vbox version which worked fine until last week ...
[02:44] <lool> I'm using it right now on an up-to-date gutsy
[02:44] <ogra> since that crashed all the time today i thought i should switch to our packages
[02:44] <ogra> but apparetnly that crashes too during booting the -desktop iso :/
[02:44] <lool> It boots here; I'm using the i386 iso on an amd64 host
[02:45] <ogra> well, nothing boots here for me
[02:45] <liw> ogra, I had big problems with vbox yesterday, but since the machine in question also has big problems with its RAM, I don't know if the problems were due to vbox or not
[02:45] <ogra> no matter which iso i try
[02:46] <ogra> i get past the bouncing usplash ... then it hangs at some point during the initscripts ...
[02:46] <ogra> pretty random
[02:49] <sladen> ogra: I had somebody reporting that on their system, with usplash was taking 2minutes longer to boot than without;  if you leave it several minutes, does it recover
[02:49] <ogra> no
[02:50] <ogra> the vm just closes
[02:50] <ogra> and the vbox console shows "interrupted"
[02:50] <sladen> ogra: can you strace/gdb the vbox instance
[02:50] <ogra> phew
[02:50] <sladen> :)
[02:50] <ogra> oh, wait
[02:50] <ogra> i dropped the second NIC
[02:50] <ogra> seems it boots now
[02:51] <ogra> hmm
[02:51] <ogra> thats weird
[02:51] <sladen> so for 2 nics it doesn't give a dime, but nicking a nic gets you the booty?
[02:52] <ogra> i have a second NIC configured as present but without cable
[02:52] <ogra> to test -server with that
[02:52] <ogra> oh, beautiful orange text on the shutdown usplash :)
[02:54] <sladen> orange.  it's the new brown
[02:54] <ogra> doesnt it pick it from the theme ?
[02:54] <lool> Nah, it's for Halloween
[02:54] <ogra> its a bright orange here
[02:55] <ogra> very nicely corresponding with the edubuntu logo
[02:55] <ogra> ok, with second NIC it crashed again
[02:58] <ogra> yeah, its reproducable ...
[02:59] <pitti> dendrobates, soren: will you guys coordinate server testing?
[03:00] <dendrobates> pitti: sure.
[03:39] <Kmos> there isn't a milestone named feisty-updates on LP
[03:39] <Hobbsee> no, there isnt.
[03:39] <Hobbsee> there is not supposed to be.  use "nominate for release"
[03:40] <Kmos> hmm.. and for bug triage? there is dapper-updates, edgy-updates and gutsy-updates
[03:40] <Kmos> only feisty there isn't on the list
[03:40] <cjwatson_> Kmos: yep, feisty-updates never got created. don't worry about it.
[03:41] <Kmos> cjwatson_: ok :)
[03:41] <cjwatson_> we only created gutsy-updates so that we had something to punt not-for-final-release bugs to in the release crunch
[03:41] <cjwatson_> we didn't have a need for that in the feisty cycle
[03:41] <Hobbsee> cjwatson_: when were you planning to add the hardy milestones, btw?
[03:42] <Hobbsee> cjwatson_: and nominate for hardy?
[03:42] <cjwatson_> Hobbsee: can't do it until gutsy is released
[03:42] <Hobbsee> cjwatson_: why not?  soyuz limitation?
[03:42] <Hobbsee> norsetto_limbo: ^
[03:42] <cjwatson_> yep, or at least we don't want to risk it
[03:42] <cjwatson_> it's part of the hardy bringup process: NewReleaseCycleProcess
[03:42] <Hobbsee> i still think that launchpad blowing up might be fun to watch.
[03:43] <Kmos> I see some e-mail about LP remove packages of old distros.. hoary, warty, breezy.. there is a date to clean it ?
[03:44] <jdong> what is the proper procedure for helping someone with an upgrade breakage in a package?
[03:44] <norsetto_limbo> Hobbsee: yes M'am?
[03:44] <cjwatson_> Kmos: I believe the mail from Matthew Revell gives a schedule, but it doesn't matter to you unless you're a mirror admin
[03:44] <jdong> I've got one guy reporting postinst subprocess failed with error 10 in tzdata....
[03:44] <Hobbsee> norsetto_limbo: you asked about ^ before, iirc.
[03:44] <cjwatson_> in fact not even then
[03:44] <Hobbsee> jdong: see why it breaks, fix it, get it sponsored.
[03:45] <cjwatson_> it matters very much for people who care about the central archive systems
[03:45] <Hobbsee> assuming we're not frozen.
[03:45] <norsetto> Hobbsee: hmmm, no, that wasn't me
[03:45] <jdong> Hobbsee: ok, person ran off, I'll take a closer look if he pops back
[03:45] <Kmos> jdong: It doesn't give an better error message?
[03:45] <cjwatson_> jdong: error codes that are multiples of 10 from maintainer scripts usually need logs with DEBCONF_DEBUG=developer set in the environment
[03:45] <jdong> Kmos: that's the only error it shows
[03:45] <Kopfgeldjaeger> hi (amsg)
[03:46] <jdong> cjwatson_: ok, thanks for the tip
[03:46] <Hobbsee> cjwatson_: is there a list of what the dpkg error codes are, and what they all mean?  dpkg(1) doesnt show anything of interest.
[03:47] <cjwatson_> Hobbsee: they aren't dpkg error codes.
[03:47] <cjwatson_> as in, they're not things returned by dpkg itself. dpkg just passes them through. they could be anything, based on what the maintainer script does.
[03:47] <Hobbsee> cjwatson_: yeah, that.  which would explain them not being in dpkg(1)
[03:48] <cjwatson_> The debconf status codes are documented in /usr/share/doc/debian-policy/debconf_specification.html
[03:48] <tkamppeter> pitti, how important is a thing like bug 153218 for updating from Feisty to Gutsy? The -doc is not on the CDs, but for updates via the internet it can perhaps be a problem.
[03:48] <cjwatson_> but it's entirely possible for a maintainer script to return anything it likes. e.g. "exit 253"
[03:48] <ubotu> Launchpad bug 153218 in ghostscript "install ghostscript-doc error" [Medium,Triaged]  https://launchpad.net/bugs/153218
[03:57] <bddebian> Heya
[03:57] <soren> I'm a bit unclear of the policies surrounding -backports. The wiki page ( https://wiki.ubuntu.com/BackportRequestProcess ) says that "In addition to syncs, members of [WWW]  ubuntu-core-dev are allowed to upload directly to -backports", but I'm not sure if that means that we can do so without asking the backport team's permission?
[03:58] <jdong> soren: I'd trust a core-dev to make a wise decision in that regard, but it's recommended that you first talk to someone on the backports team
[03:59] <soren> jdong: mkay.
[04:00] <jazzanova> hi
[04:00] <jazzanova> can someone explain to me this bug
[04:00] <jazzanova> 732006 December B+ /home/liquidat
[04:01] <jazzanova> sorry
[04:01] <jazzanova> this one: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/74664/+activity
[04:01] <ubotu> Launchpad bug 74664 in upstart "Boot parameters not passed to init scripts" [Low,Invalid] 
[04:02] <jazzanova> what does this mean: "Rejecting the Ubuntu portion of this bug, since it's an upstream problem"
[04:03] <cjwatson_> jazzanova: it means that the bug doesn't need to be tracked both in the upstream project and in Ubuntu; since Scott is the upstream maintainer as well as the Ubuntu maintainer, he made a decision to track it in just one place
[04:03] <jazzanova> cjwatson: so it is not resolved then ?
[04:03] <cjwatson_> no, it is not
[04:04] <jazzanova> can I find this entry in the upstream log ?
[04:04] <cjwatson_> what do you mean?
[04:04] <jazzanova> can i find the place in which th ebug is tracked
[04:04] <cjwatson_> you've got it right there
[04:05] <cjwatson_> that bug has two tasks open on it; one for Ubuntu (closed), one for upstream (open)
[04:05] <jazzanova> ok
[04:05] <jazzanova> cjwatson: i need to fix this bug
[04:06] <jazzanova> do you think its hard ?
[04:06] <cjwatson_> dunno, I'll ask Scott to comment here when he gets back to his desk
[04:06] <jazzanova> should I download 'upstart' source and mess with it ?
[04:07] <jazzanova> if i install sysv-init, am I going to break everything ? i'm on feisty
[04:07] <cjwatson_> if you install sysvinit you will probably break your system
[04:07] <soren> jdong: So I'm actually allowed to do so, but I *ought* to talk to the backports team? That's sort of what I expected, too. I just wanted to get clarification.
[04:08] <jazzanova> ok
[04:08] <Vlet> Anyone know what the 'indent' args would be for Whitesmith formatting?
[04:09] <Keybuk> jazzanova: it's not especially hard
[04:09] <jazzanova> ok, im gonna give it a shot.
[04:09] <Keybuk> init/process.c - process_setup_environment()
[04:09] <jazzanova> right now
[04:09] <Keybuk> you just need to find some way of copying environment there into the child
[04:09] <Keybuk> and flagging that you want to do it
[04:10] <mdomsch> apt doesn't seem to have a method to plug in additional modules at runtime, correct?
[04:10] <pitti> tkamppeter: weird, I thought I fixed that with my last ghostscript update (build system fix to not ship doc stuff in ghostscript)
[04:15] <asac_educated> ogra: for desktop search test (https://wiki.ubuntu.com/Testing/Cases/EdubuntuDesktop) ... there is no Examples folder?
[04:15] <ogra> no space for that
[04:16] <ogra> edubuntu doesnt ship examples
[04:16] <asac_educated> stgraber: ^^
[04:24] <tkamppeter> pitti, have you checked the sizes of the packages produced by buildds?
[04:24] <pitti> tkamppeter: no, not so far
[04:24] <pitti> tkamppeter: they look fine
[04:25] <freeflying> pitti: will you upgrade language-pack before release?
[04:26] <pitti> freeflying: no, the CDs are pretty much final; we just got a fresh update over the weekend
[04:26] <tkamppeter> pitti, perhaps there are still a few files remaining duplicate in both ghostscript and ghostscript-doc.
[04:26] <pitti> tkamppeter: trying here; I have a fresh install
[04:26] <pitti> tkamppeter: right, I get it, too
[04:26] <freeflying> pitti: there have some errors in Chinese translation, also have some in other language
[04:26] <pitti> tkamppeter: seems I removed *.htm and other bits, but not *.html
[04:27] <stgraber> asac: thanks, I updated the testcase
[04:29] <iwj> cjwatson_: Do you want me to collect any particular information for bug 153310 and bug 153311, before I wipe that install ?
[04:29] <ubotu> Launchpad bug 153310 in oem-config "oem-prepare cannot cope if oem creates user (?)" [Undecided,New]  https://launchpad.net/bugs/153310
[04:29] <ubotu> Launchpad bug 153311 in oem-config "poor error handling - lack of recovery" [Undecided,New]  https://launchpad.net/bugs/153311
[04:30] <tkamppeter> pitti, can you fix that ghostscript problem then, either in Gutsy or in gutsy-updates?
[04:33] <Lure> bryce: new ati test package works ok here, could you just give a package version that will not be upgrade by current gutsy version (e.g. 6.7.196~gitXXXX instead of6.7.195~git20071015)
[04:34] <desrt> jono; fantastically true.
[04:34] <desrt> (wrt: "a musician should never /ever/ see his guitar bounce")
[04:34] <jono> desrt: :)
[04:39] <jazzanova> grep the kernel version ?
[04:45] <mdomsch> If I want an action to be run by apt or dpkg after all the packages in that transaction are installed
[04:45] <mdomsch> I could use a trigger - but what other options exist?
[04:46] <mdomsch> similar to the delayed ldconfig
[04:46] <sladen> mdomsch: you may just have answered your own question.  Perhaps if you could elaborate a bit more
[04:46] <mdomsch> sladen, sure
[04:46] <StevenK> jono: Do you have a close-up of the damage? I'm most likely missing something in that photo
[04:47] <mdomsch> I have packages A, B, C, and D being installed via apt-get install A B C D
[04:47] <mdomsch> A, C, and D all have the same command to run, such as ldconfig
[04:47] <jono> StevenK: the guitar on the right that is the same shape as the one next to it has its point missing on the end
[04:47] <mdomsch> but I only want it run once, after all of A, B, C, and D are installed
[04:47] <StevenK> jono: Ahhh
[04:47] <mdomsch> so it's not a postinst in each
[04:47] <sladen> StevenK: damage?  Jono crashed his new Ferrari /already/?
[04:47] <StevenK> mdomsch: Then it's a trigger.
[04:48] <jono> sladen: not this time :)
[04:48] <StevenK> New Ferrari? What happened to the old one? :-P
[04:48] <mdomsch> StevenK, yeah - that's what I figured.  I'm only avoiding triggers because they're pretty new
[04:48] <mdomsch> and I was hoping the same trick could be used on older releases too
[04:48] <StevenK> mdomsch: That also makes them shiny.
[04:49] <Hobbsee> ooo...shiny
[04:50] <jazzanova> i installed recompiled version of upstart, with minimal changes, ad now i can't reboot.
[04:50] <jazzanova> is there a way to tell the kernel to reboot ?
[04:52] <StevenK> jazzanova: sudo reboot -f
[04:52] <StevenK> jazzanova: Make sure you run 'sudo sync' before that
[04:52] <jazzanova> oops
[04:52] <jazzanova> already did it
[04:52] <jazzanova> thanks
[04:54] <mdomsch> phooey - no fortune-firefly package :-(
[04:55] <jazzanova> ok, i intorduced a crash to init
[05:01] <jazzanova> is there a way to force kernel reboot, some control sequence ?-
[05:01] <jazzanova> i have a crash in init.
[05:01] <mjg59> alt+sysrq+b
[05:01] <jazzanova> whats sysrq ?
[05:01] <mjg59> The key that says sysrq
[05:02] <jazzanova> thanks! wow
[05:03] <jdong> mjg59: shouldn't one try to use the reisub sequence?
[05:03] <Hobbsee> hiya mthaddon
[05:03] <sladen> preferably with a  alt+sysrq+s  to sync and a  alt+sysrq+u  to unmount first
[05:03] <jdong> well since init died, probably sub
[05:03] <mthaddon> hiya Hobbsee
[05:03] <jazzanova> sladen: great.
[05:14] <cjwatson_> iwj: no, thanks, they're problems I've seen before
[05:37] <psusi> iwj: do you see any advantage to this idea of packing a git repo directly into the source package, and if so, could you explain it to me, because it seems a colossal waste to me.
[05:38] <sladen> perfect revision control.
[05:39] <siretart> psusi: have you read the FAQ to that topic?
[05:39] <psusi> didn't know there was one... just been following the thread on dpkg-list
[05:40] <siretart> psusi: there are several very verbose and clear summaries in that particular thread in which cases it makes perfect sense to do that
[05:40] <psusi> I see no advantage to placing the entire git repo into the source package over just having a git repo that people who want to use git can use, and source packages are then automatically generated from there
[05:40] <siretart> and various pointers to the FAQ.
[05:40] <siretart> I'd suggest rereading the thread on the dpkg-list
[05:40] <psusi> ohh, that thing... yea, I read it
[05:40] <psusi> I still see zero advantage
[05:40] <psusi> it's a nice explanation of how it will work
[05:41] <psusi> but I fail to see why it's a good idea
[05:41] <psusi> I only see bad things... specifically that the size of source packages will be larger and they will be more complex to unpack
[05:42] <siretart> do you really want me to dig out Ian's perfectly clear summary for this question?
[05:42] <psusi> I'll go take another look at it, but I still see no real advantages listed...
[05:42] <psusi> maybe I just don't understand them
[05:44] <psusi> are you refering to Ian's comments starting with "This is a sensible question to ask.  Goals I would suggest:"?
[05:44] <siretart> yes
[05:45] <psusi> it seems to me that all of those goals can be done by linking the source archive to a vcs, not packing the entire vcs repository into the source package
[05:45] <iwj> psusi: Yes, I definitely see an advantage.
[05:45] <pitti> tkamppeter: gs> yes, I'll fix it in gutsy-updates
[05:45] <iwj> Although I don't like the duplication of stuff.
[05:45] <siretart> psusi: like in, say, the BSDs?
[05:46] <psusi> siretart: dunno... I know almost nothing about bsd
[05:46] <tkamppeter> pitti, OK.
[05:46] <iwj> psusi: No, you can't do those things with just a link to the repo because people without commit access to the repo can't commit.
[05:46] <siretart> psusi: see http://www.openbsd.org/cgi-bin/man.cgi?query=ports&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
[05:46] <psusi> but look at the linux kernel... they use git to manage the source, and simply git-tar out the tagged releases into tarballs that just contain the source for that release
[05:46] <tkamppeter> pitti, what about getting info into the Release Notes (see the e-mails where I CCed you
[05:46] <psusi> they can't commit anyhow without upload access to the archive
[05:47] <psusi> that's why they send in patches
[05:47] <pitti> tkamppeter: it'll be done, thanks
[05:47] <tkamppeter> ? Who is the right person for this?
[05:47] <iwj> psusi: Part of the point is to get rid of all that palaver with patches.  They're a PITA.
[05:47] <pitti> tkamppeter: slangasek
[05:47] <siretart> psusi: are you arguing there was no need for the change, or are you arguing that approach was harmful?
[05:47] <iwj> Plenty of people can upload without being able to commit.
[05:48] <pitti> tkamppeter: you mailed him already, so that's fine
[05:48] <psusi> iwj: I agree, getting rid of dpatch is a good thing... how is that not accomplished by simply throwing it out and using git, then exporting the working tree to source package?
[05:48] <psusi> siretart: I am arguing that it seems to be a lot more complicated way to achieve that set of goals
[05:49] <tkamppeter> pitti, OK, thanks. Informing the users is important in such a situation. Too bad that users start testing only after takeoff.
[05:49] <psusi> iwj: you mean to like a public write only upload directory?  then just unpack that source tarball over a git checkout of the starting version, and commit to a new branch
[05:49] <siretart> psusi: I have the impression you haven't had the chance to maintain large packages with extensive patchsets yet.
[05:49] <tkamppeter> I have the fealing that I got more and more reports of important bugs the closer it came to release.
[05:50] <psusi> iwj: can be automated and then the person who doesnt know about git doesn't have to have it or download the full repository to hack on the source
[05:50] <pitti> tkamppeter: yeah, the old chicken-egg problem with testing :/
[05:50] <psusi> if the goal is to get rid of dpatch to make it easier to extract the actual working source and tinker, why replace dpatch with git?
[05:51] <iwj> psusi: How would you know what the "original version" was ?
[05:51] <psusi> siretart: true... but I do track the kernel git tree regularly and have worked on a few packages in ubuntu that have a fair number of dpatches
[05:51] <iwj> Sorry, you said "starting version".  That.
[05:51] <psusi> iwj: because it's in the .changes
[05:52] <psusi> and debian/changelog
[05:52] <iwj> .changes is no good since the next person doesn't get it.  changelog might work.
[05:53] <psusi> why would the next person need it?
[05:53] <psusi> it's only needed by the ftpmaster to decide which version to check out and unpack this source package over
[05:54] <iwj> Oh, you want the ftp scripts to do it.
[05:54] <psusi> yea, the nmu can just get the current source tree, hack it it, upload it, and the ftp scripts can auto commit the changes to a new branch in the vcs
[05:54] <iwj> I'm not wedded to the proposal from Joey.  If you'd like to sketch out your alternative proposal more fully I'm sure people would be happy to hear it.  I don't think I can do a detailed analysis of it here though.
[05:55] <psusi> for someone with commit access to the master branch to review and merge
[05:55] <psusi> hrm.... ok
[05:55] <iwj> Note that your proposal seems to make the VCS repos much more tightly bound to the whole setup.  ATM they're kind of offstage.  That may not be a bad thing but it has political implications.  I think you should think it through and write it up.
[05:55] <psusi> yea, because the ftp scripts will still have to pull from the git repo they upload anyhow
[05:56] <psusi> ok
[05:56] <psusi> ohh, so his proprosal would throw out the sideline vcs repositories
[05:56] <psusi> and just keep a copy of the git repo in each versioned source package?
[05:56] <iwj> Well, err, in some sense, yes.
[05:57] <psusi> what a colossal duplicate of data... and of course, it also doesn't allow people to collaborte committing smaller patches between releases
[05:57] <siretart> psusi: does your proposal include having the complete archive managed in git repositories?
[05:57] <iwj> Not to say you can't have unofficial separate repos but they'd be more like unofficial separate branches.  They'd be in the same position as a current VCSless maintainer's random being-edited work-in-progress unpacked package.
[05:58] <psusi> siretart: yea, if you like git, then I say just have a git repository that auto export/imports release branches to/from the source ftp archive, rather than pack the whole git repository into each source archive
[05:58] <iwj> psusi: Also note that you shouldn't just say "git".  People get religious about this kind of thing, so if you want to talk in terms of git you should at least say "I'm going to talk about git but other VCSes should be supported" or something near the bottom to avoid getting sidetracked.
[05:59] <siretart> psusi: I'm not sold to git at all. In fact, I'm still trying to get myself used to it, but I don't think I'll ever love it. It seems to me that your proposal is going to force every uploader to the archive to use git, which is a, errrm, unrealistic assumption
[05:59] <psusi> iwj: well, not quite... if the maintainer decides to use the git repo, then maintainers of the package should be using the central git repo... that allows them to make and share incrimental patches between releases
[05:59] <psusi> then when the maintainer decides it's time for release... he tags it and it's exported to the ftp archive
[06:00] <psusi> yea, I'm talking git because 1) I'm familliar with it and 2) this patch being discussed talks about it heavily
[06:00] <iwj> psusi: Yes.  That puts the whole group of them together in the position of a single VCSless maintainer, which is obviously good.
[06:00] <psusi> siretart: it would be up to each package maintqainer which vcs they want to use
[06:00] <cjwatson_> (in particular you don't need to be sold on git because I wrote a bzr backend for Joey's code.)
[06:00] <iwj> I mean, that's why people do it :-).  But the question is how to make this more accessible to others.
[06:01] <siretart> psusi: however, on the 2nd thought, it seems to me that your proposal could be useful for a potential (small) derivative distribution, which needs to track changes in debian.
[06:01] <ringe> What's up with the missing ipw3945 drivers in newest Gutsy kernels?
[06:01] <Hobbsee> ...they...arent?
[06:02] <cjwatson_> psusi: FWIW, in Joey's proposal, source packages typically shrink, not grow.
[06:02] <Hobbsee> ringe: do you have linux-u-m installed?
[06:02] <cjwatson_> psusi: (though with bzr the result would be a little bit bigger than before, but not massively so. git's packing is a bit more efficient)
[06:02] <ringe> Hobbsee: I have just installed from the Beta CD, then kept up to date with update-manager
[06:02] <psusi> cjwatson_: I saw him claim that but I can not believe it... you can not ADD information to the package and have it come out smaller
[06:02] <cjwatson_> psusi: you apparently believe that gzip compression is perfect
[06:03] <ringe> Hobbsee: 2.6.22-12 works good, not 2.6.22-13 or -14
[06:03] <cjwatson_> psusi: it's entirely sensible to believe that different encodings will come out differently
[06:03] <psusi> cjwatson_: eh?  gzip is used either way...
[06:03] <cjwatson_> psusi: in any case you don't have to believe or disbelieve. you can try it.
[06:03] <psusi> in fact, source packages can use bzip2
[06:03] <Hobbsee> ringe: okay, so do you have l-u-m installed for the later kernels?
[06:03] <cjwatson_> or perhaps that is too much effort
[06:03] <psusi> git can only use gzip afaik
[06:04] <cjwatson_> source packages can't use bzip2 in the current format unless they use bzip2-in-tar-gz
[06:04] <psusi> so I don't see how you can save space by switching to a less effective algorithm and adding more data
[06:04] <psusi> huh?  the .deb can contain a .tar.bz2 instead of a .tar.gz
[06:04] <cjwatson_> a .deb is not a source package.
[06:05] <ringe> Hobbsee: No I didn't - why isn't that package upgraded?
[06:05] <psusi> ohh, so only the binary packages can use bz2?
[06:05] <cjwatson_> correct
[06:05] <Hobbsee> oh, headdesk.
[06:05] <psusi> ok... didn't know that... but git still also uses gzip, so same compression
[06:05] <Hobbsee> is that why people are reporting problems/
[06:05] <cjwatson_> psusi: is trying it so hard?
[06:05] <tkamppeter> pitti, can you have a look at bug 152537? It seems that "sudo aa-complain cupsd" is reset on each boot. Is that the case?
[06:05] <ubotu> Launchpad bug 152537 in cupsys "After update from Feisty to Gutsy RC, print jobs fail: "/usr/lib/cups/backend/mfp failed"" [High,Incomplete]  https://launchpad.net/bugs/152537
[06:06] <pitti> tkamppeter: no, that's permanent
[06:06] <psusi> cjwatson_: understanding is more enjoyable than accepting ;)
[06:06] <linux4me> not sure I have the right channel but here goes, apparently I'm missing glib-devel and libnet-devel, how do I install this on feisty?
[06:06] <siretart> psusi: it would help everyone if you would just try it and analyse how it works
[06:06] <psusi> and I can tell you that my linux git repo is a good deal larger than a plain tarball
[06:06] <ringe> Hobbsee: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/134193
[06:06] <ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed] 
[06:07] <ringe> ubotu: yes, that's what I' talking about
[06:07] <tkamppeter> pitti, the user tells he has to do "sudo aa-complain cupsd" after each reboot.
[06:07] <rulus> linux4me: for support #ubuntu
[06:08] <linux4me> rulus - tks
[06:08] <ringe> Hobbsee: I'll reboot to see if that fixed the bug for my part
[06:09] <Riddell> mertiki: is there a reason why the patch to bug 145709 shouldn't be a stable release update?
[06:09] <ubotu> Launchpad bug 145709 in qt-x11-free "7.10: Qt3 ~/.qt owner root and missing qtrc result result in ugly appearance" [Undecided,Fix committed]  https://launchpad.net/bugs/145709
[06:09] <mathiaz> tkamppeter: aa-complain cupsd should be persistent between reboots.
[06:09] <mertiki> Riddell : Yes
[06:09] <cjwatson_> psusi: read Joey's post a bit more closely, please
[06:09] <cjwatson_> psusi: "A sample dpkg source package built using this is temporarily here. This demo package includes only the last 200 commits to the dpkg git repo, so it's more than 1 mb smaller than dpkg's normal .tar.gz!"
[06:09] <cjwatson_> note: not all the information
[06:10] <Riddell> mertiki: what's the reson?
[06:10] <mertiki> Riddell : The /etc/qt3 folder in Gutsy has very low permissions because it's not created by the installation of the libqt3-mt package. So if Gutsy is released with the /etc/qt3 folder with very low permissions, the libqt3-mt package won't install correctly same with my patch
[06:11] <psusi> cjwatson_: yea, but how can adding the 200 commits to the current source code result in less data?
[06:11] <mertiki> /etc/qt3 folder should be created by libqt3-mt, and the previous package before my patch didn't create it in Gutsy
[06:11] <cjwatson_> psusi: again, you desperately need to read the post
[06:11] <cjwatson_> your premise is false
[06:12] <cjwatson_> http://kitenet.net/~joey/blog/entry/an_evolutionary_change_to_the_Debian_source_package_format/
[06:12] <Riddell> mertiki: ok, but why can't it can be fixed in an update?
[06:12] <mertiki> Riddell : Because each update in Gutsy would need to change the permissions of the /etc/qt3 folder in order to install correctly.
[06:13] <psusi> is he not claiming that by switching the source package from containing a .tar.gz to a .git.tar.gz he saved space somehow?
[06:13] <mertiki> Riddell : This would need additionnal works
[06:13] <cjwatson_> psusi: your question is dealt with explicitly in his post
[06:14] <cjwatson_> "Let a debian source package consist of just a .dsc and package_version.git.tar.gz, which contains only package/.git/*."
[06:14] <mertiki> Riddell : In my point of view, things would be more logical if Gutsy was released with at least a /etc/qt3 folder with good permissions, this would avoid unnecessary work
[06:14] <tkamppeter> mathiaz, thanks.
[06:15] <cjwatson_> I don't understand this point about permissions of /etc/qt3. dpkg runs as root and permissions do not impede it
[06:15] <psusi> cjwatson_: right... and he is saying that worked out smaller than the current package is he not?
[06:15] <cjwatson_> psusi: "only package/.git/*"
[06:15] <psusi> cjwatson_: aye... I am calling bs on that
[06:15] <Hobbsee> did we not seed linux-image-generic in pre-gutsy or something?  or equivalent image?
[06:15] <pitti> mertiki: since that new package needs to handle upgrades anyway, I don't see why doing it as an SRU isn't possible
[06:16] <cjwatson_> psusi: this is science, not religion. it doesn't count unless you put in the effort to reproduce it.
[06:16] <psusi> I just pulled the dmraid package into a git repo without any history... the size of just package/.git is significantly larger than the original source package
[06:16] <mertiki> cjwatson : I'm not an expert, but the package won't create config files in /etc/qt3 with the actual folder permissions, but it will if the folder has normal root permissions
[06:16] <psusi> oh wait, it idnd't pack it... hold on
[06:17] <cjwatson_> Joey's code does explicit stuff to pack the repository better
[06:17] <Hobbsee> ringe: did you upgrade from feisty, or clean install?
[06:17] <cjwatson_> which is why I'm saying you should try it, not some random other experiment
[06:17] <psusi> ok, better, but still larger, as expected
[06:17] <ringe> Hobbsee: Clean install. The 2.6.22-14 l-u-m didn't fix the problem with missing ipw3945 drivers
[06:17] <cjwatson_> and you can try the very thing he's talking about. Isn't open source great?
[06:17] <ringe> Hobbsee: in fact, the audio drivers seems to be missing too
[06:18] <Hobbsee> ringe: okay, the first half worries me.
[06:18] <mertiki> pitti : Sorry what's the exact meaning of SRU ?
[06:18] <Hobbsee> !sru | mertiki
[06:18] <ubotu> mertiki: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
[06:18] <mertiki> thanks
[06:18] <pitti> mertiki: a stable release upgrade, i. e. post-release
[06:18] <Hobbsee> ringe: is this -generic or -i386?
[06:19] <ringe> Hobbsee: generic, see also comment 10 here: http://rubyurl.com/nZq
[06:19] <pitti> Hobbsee: oh, can you teach uboty to not show MOTU/SRU any more? it's been merged
[06:19] <Hobbsee> !no sru is <reply>  Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[06:19] <ubotu> I'll remember that Hobbsee
[06:20] <Hobbsee> !sru
[06:20] <ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[06:20] <Hobbsee> good bot
[06:20] <Hobbsee> pitti: as you wish :)
[06:20] <mertiki> pitti : Ok, so if you all consider that this doesn't cause any problems, that's alright. I just wanted to explain you the problem. It's clear if the package is released as and update that further work will be required on this.
[06:20] <ringe> Hobbsee: I am concerned since this bug is not given critical priority - it's a clear blocker
[06:20] <Hobbsee> ringe: it's somewhat of a local problem
[06:20] <pitti> mertiki: right, no argument on that (the current patch doesn't handle upgrades)
[06:20] <cjwatson_> Hobbsee: linux-generic should've been seeded for some time
[06:20] <pitti> mertiki: but AFAICS that additional work would be required even for an upload into gutsy proper
[06:21] <pitti> mertiki: since a lot of people install beta or RC, or upgraded to it from Feisty
[06:21] <ringe> Hobbsee: I don't see why a whole range of wireless enabled laptops without wireless support is "local"
[06:21] <pitti> mertiki: and for an SRU we can take some time to get the upgrade right; as opposed to now, when we need to rush things and potentially make it worse
[06:21] <Hobbsee> ringe: FYI, if my ipw3945 card wasnt working, i wouldnt be talking to you now. nor would a lot of other people on irc.
[06:21] <cjwatson_> ringe: we know about the audio drivers - problem is that fixing them breaks other stuff, so instead, it'll be handled in linux-backports-modules
[06:22] <mertiki> pitti : Ok good, so should everything is already specified in the bug report, should-I do something else around that or everything is Ok?
[06:22] <Hobbsee> ringe: and that link you provided shows no mention of l-u-m being installed at all.
[06:22] <pitti> mertiki: I didn't read it entirely yet, but I don't think it has a clear strategy how to fix upgrades?
[06:22] <ringe> Hobbsee: I'm at ipw3945 myself, running 2.6.22-12 - and I just installed the l-u-m as you said without it fixing the missing files problem
[06:23] <cjwatson_> you need to install the matching l-u-m
[06:23] <pitti> mertiki: in particular, the package maintainer scripts must not touch anything in /home/
[06:23] <Hobbsee> ringe: stupid question, but you used locate to check for the new files?
[06:23] <cjwatson_> so linux-ubuntu-modules-2.6.22-12-generic
[06:23] <pitti> mertiki: so that'd boil down to some code changes
[06:23] <cjwatson_> which probably isn't in the archive any more; upgrade :-)
[06:23] <Hobbsee> cjwatson_: why do so many people seem to be on linux-image-386?
[06:24] <ringe> Hobbsee: sorry, I'm stupid - the files are there now. But why aren't they loaded with -14?
[06:24] <mertiki> pitti : the patch has just one line, and changes a single file in the debian folder of the package which allows the package to create is config files in the /etc/qt3 folder. This is a fix based on the Feisty package which was Ok.
[06:24] <cjwatson_> Hobbsee: perhaps because they have hardware that doesn't support -generic
[06:24] <pitti> mertiki: right
[06:24] <ringe> Hobbsee: and why aren't they automatically installed?
[06:24] <pitti> mertiki: I'm talking about an upgrade path for people who already have the root-owned ~/.qt
[06:24] <cjwatson_> ringe: they normally are ...
[06:24] <Hobbsee> cjwatson_: seems like a higher proportion than expected, though, looking at userland
[06:25] <Hobbsee> ringe: good question. see my last comment on the bug report
[06:25] <cjwatson_> Hobbsee: there was also a base-installer bug that treated some old Via C3s as needing -386 when actually -generic is fine
[06:25] <Hobbsee> did you have linux-image-generic installed?
[06:25] <Hobbsee> This gets installed with the gutsy cds - is this an upgrade bug only?
[06:25] <ringe> cjwatson_: I installed the BETA clean, and upgraded from there. What's not normal then?
[06:25] <cjwatson_> ringe: I'd need to see the full installer logs to tell
[06:25] <cjwatson_> ringe: /var/log/installer/*
[06:25] <Hobbsee> cjwatson_: ah right.  -i386 definetly isnt doing the ubuntu modules at all.
[06:25] <Hobbsee> cjwatson_: presumably this is intentional?
[06:25] <cjwatson_> Package: linux-image-386
[06:25] <Hobbsee> oh wait.  my bad.
[06:25] <Hobbsee> i cant read
[06:25] <cjwatson_> Depends: linux-image-2.6.22-14-386, linux-ubuntu-modules-2.6.22-14-386
[06:25] <mertiki> pitti : Oh ok right, I'm surely not the good person to fix that but if a lot of people are using Ubuntu installed from Beta and Alpha, I think that you're right :)
[06:25] <Hobbsee> cjwatson_: yeah, i suck.  i'm getting tired, i know
[06:26] <ringe> Hobbsee: nope, the linux-image-generic isn't installed
[06:26] <Hobbsee> ringe: then that's why.
[06:26] <Hobbsee> ringe: why is it not installed?
[06:26] <pitti> mertiki: thanks for pointing this out; it's on the radar now
[06:26] <cjwatson_> ringe: installer logs should help tell me why
[06:26] <ringe> Hobbsee: I agree, I was going to ask you the same.
[06:26] <mertiki> Riddell : Thanks, please tell me if I can do something else around that and thanks again for your work on this
[06:26] <ringe> cjwatson_: I'll post them to that bug
[06:27] <cjwatson_> thanks
[06:27] <mertiki> pitti : Ok right, thanks too
[06:27] <Riddell> mertiki: no need to thank me, I'm the one who somehow failed to upload it in time
[06:27] <Adri2000> release team: can I already upload to gutsy-proposed?
[06:28] <mertiki> Riddell : Haha, don't botter, I'm also the one who found the problem at the last minute
[06:28] <pitti> Adri2000: yes, it will just sit there for some days, thuogh
[06:28] <cjwatson_> Adri2000: you can upload, but nothing will be done with it until we release
[06:28] <Adri2000> ok
[06:31] <iwj> cjwatson_: Opinion on bug 153336 ?
[06:31] <ubotu> Launchpad bug 153336 in oem-config "oem-config sudden exit" [Undecided,New]  https://launchpad.net/bugs/153336
[06:32] <ringe> cjwatson_: installer logs posted to bug 134193: http://rubyurl.com/BAy
[06:32] <ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed]  https://launchpad.net/bugs/134193
[06:33] <cjwatson_> iwj: hmm, agreed but it seems cosmetic (if nasty)
[06:33] <iwj> Right.
[06:33] <iwj> I just thought I'd mention it since if you thought there was a confirmation screen it might actually be a crash.
[06:33] <cjwatson_> last week I'd have had no hesitation in fixing it
[06:33] <iwj> Sorry I didn't spot it then :-).
[06:33] <cjwatson_> no, there's no confirmation screen (perhaps unfortunately)
[06:33] <iwj> Fair enough.
[06:33] <cjwatson_> if it created the user then it's succeeded
[06:34] <cjwatson_> if it crashes, the failure mode is so unutterably horrible that you'd know :-)
[06:34] <cjwatson_> one thing oem-config doesn't do is crash quietly.
[06:35] <Hobbsee> ringe: btw - all the problems in that bug will be fixed with installing the corresponding l-u-m for the kernel that they're on..
[06:37] <ringe> Hobbsee: I installed it and tried a reboot but the network wasn't loaded. I'll try again now, though. I just installed linux-image-generic
[06:37] <Hobbsee> ringe: if everyone installed linux-image-{generic, whichever flavour they're using}, this would be solved for them, forever.
[06:40] <ringe> Hobbsee: I just filed that as bug 153345
[06:40] <ubotu> Launchpad bug 153345 in update-manager "update-manager should check for linux-image-* metapackage" [Undecided,New]  https://launchpad.net/bugs/153345
[06:41] <Hobbsee> ringe: i thought you said this was a fresh gutsy install
[06:41] <ringe> since, as I said - I did a regular install with the BETA cd
[06:41] <ringe> Hobbsee: it is
[06:42] <ringe> Hobbsee: The computer is brand new - came with Vista (which I fight Packard Bell to give me money back for)
[06:42] <Hobbsee> in which case, what's update-manager got to do with it?
[06:42] <mvo> ringe: update-manager will ensure this in release upgrade mode, but not in regular update mode (as in the regular update mode this situation can only occur if a) a devel release is used b) non-standard sources are used c) the user decided to go without -generic (or -386 etc)
[06:42] <ringe> Hobbsee: Nothing much. I just figured update-manager would do users a favor if checking for the linux-image package
[06:44] <ringe> mvo: hmm. There are two questions: why did the missing linux-image become missing in the first place, then what should update-manager do about it if it occurs?
[06:44] <ringe> I don't know the answer to the first question, since this simply is a fresh install. The answer to the second is that bug I just filed.
[06:44] <cjwatson_> ringe: not seeing anything in that log about why it wasn't installed, but I suspect it must have been a transient problem with that particular CD image
[06:44] <cjwatson_> daily builds can be like that sometimes
[06:45] <cjwatson_> ringe: no, you didn't install with the beta CD, or at least that's not what your logs say
[06:45] <cjwatson_> 'Ubuntu 7.10 _Gutsy Gibbon_ - Alpha i386 (20070823.5)'
[06:45] <cjwatson_> that's over a month before beta
[06:45] <mvo> ringe: the question why it went missing might be answered with /var/log/apt/term.log. what it should do? IMO it should do nothing because it can't tell if the user did not decided against this kernel for some reason.this is a different matter for feisty->gutsy upgrades, here it should (and will) ensure that linux-image-$flavor is installed (unless the user uses a self compiled kernel)
[06:46] <cjwatson_> it looks like you actually used Tribe 5
[06:47] <ringe> Hobbsee: I think we must be careful not to make update-manager become windows update with the trust problem
[06:47] <ringe> cjwatson_: Hmm, you're right.
[06:47] <cjwatson_> the livefs log for Tribe 5 shows that linux-ubuntu-modules was installed
[06:47] <cjwatson_> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/20070823.4/livecd-20070823.4-i386.out
[06:47] <cjwatson_> (note: livefs build numbers don't always correspond exactly to CD build numbers)
[06:48] <ringe> cjwatson_: so any update after that removed it then?
[06:48] <cjwatson_> I guess it must have done; the installer didn't
[06:48] <ringe> Well, at least that'
[06:48] <cjwatson_> it logs the packages it removes, and it didn't mention that
[06:48] <ringe> good, then
[06:49] <mvo> ringe: /var/log/dist-upgrade/apt.log may also give a clue
[06:49] <ringe> Hmm, may the problem have appeared because of mirror sync while upgrading?
[06:51] <ringe> mvo: find it attached to bug 134193
[06:51] <ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed]  https://launchpad.net/bugs/134193
[07:10] <LaserJock> grrr, /me kicks firefox
[07:11] <ringe> cjwatson_: I've added a few logs to show the difference when loading 2.6.22-12 and -14 to bug 134193
[07:11] <ubotu> Launchpad bug 134193 in linux-restricted-modules-2.6.22 "ipw3945 doesn't work after gutsy update (2.6.22-10)" [Undecided,Confirmed]  https://launchpad.net/bugs/134193
[07:11] <ogra> LaserJock, careful, it might kick back
[07:11] <LaserJock> ogra: it started it
[07:12] <LaserJock> it just keeps locking up with 100% CPU
[07:12] <ogra> evil thing
[07:15] <cjwatson_> ringe: I stopped being interested when it didn't seem to be an installer problem any more :-)
[07:15] <cjwatson_> ringe: (not to be abrupt but I'm having to be pretty focused)
[07:15] <agoliveira> Hmmm... Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) here and it's working fine with 2.6.22-14-generic
[07:15] <ringe> cjwatson_: No offense taken. :) Who'd be interested?
[07:16] <agoliveira> Not the same notebook tough...
[07:16] <ringe> agoliveira: It works perfect with 2.6.22-12-generic
[07:17] <agoliveira> ringe: I didn't have any problems that I recall for quite some time and I'm using -14
[07:17] <cjwatson_> ringe: dunno, #ubuntu-kernel maybe?
[07:18] <psusi> looks like I found my culprit... it appears that joey removed 8 mb of files from the source tree before packing it into git... that's why it's slightly smaller
[07:18] <stgraber> ringe: same here too and didn't have any problem with the driver (-12, -13, -14 and previous ones). But I know, the "work for me" isn't of any help ... :)
[07:20] <ringe> According to the latest logs I put there, the modules are there but they just don't load.
[07:39] <ringe> cjwatson_: depmod -a fixed the problems for me :)
[08:18] <Riddell> calc: could you do a SRU for 153132?
[08:18] <Riddell> bug 153132
[08:18] <ubotu> Launchpad bug 153132 in openoffice.org "Openoffice splash screen includes Ubuntu logo" [Undecided,Confirmed]  https://launchpad.net/bugs/153132
[08:26] <tkamppeter> slangasek, sorry, did not know that there is a Wiki place to collect the release note entries, I only saw one of your answeres to the bugs I am dealing with where you wrote that you will add the issue to the Release Notes. Where is this Wiki page?
[08:27] <cjwatson_> tkamppeter: http://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
[08:31] <tkamppeter> cjwatson, slangasek, thanks.
[08:36] <YokoZa1> What's the difference between fix-committed and fix-released in Launchpad?  I'm trying to figure out how to tag some bugs of mine that are solved.
[08:37] <tkamppeter> cjwatson, slangasek, is there a special order in the file? If I add something, where should I add it (the file can get very busy until Thursday)?
[08:37] <slangasek> YokoZa1: https://help.launchpad.net/BugStatuses
[08:38] <thully> ogra: ping?
[08:39] <ogra> thully, ?
[08:40] <calc> Riddell: huh? still reading the bug, i am confused as to what bug this is
[08:40] <thully> yes, I have a g-p-m bug that I've been trying to get someone to look at
[08:40] <thully> I have a patch for it - but I don't know if my patch is perfect...
[08:51] <calc> Riddell: oh i see after reading the report :)
[08:51] <ogra> thully, a bit late for the release though, whats the bug # ?
[08:51] <ScottK> YokoZa1: Generally "Fix Committed" means a fix is uploaded somewhere (could be just in a VCS, not in a release yet), but there's a fix somewhere that will eventually arrive in a development version of Ubuntu.
[08:51] <thully> bug # 137598
[08:51] <thully> #137598
[08:51] <ogra> bug #137598
[08:51] <ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,New]  https://launchpad.net/bugs/137598
[08:51] <ScottK> YokoZa1: Fix Released means it's uploaded to an Ubuntu repository (modulo time for the buildd's to build it and the mirrors to mirror it) and available.
[08:51] <calc> Riddell: would a SRU to just fix the branding bmp even be accepted, it doesn't seem clear it would from the SRU wiki page..
[08:51] <thully> to reproduce it, tune your brightness manually below maximum and wait (on AC, with default g-p-m settings)
[08:51] <thully> the "adjust brightness" function is apparently called on idle regardless of "dim on idle" setting - and with that off, it uses the default brightness (maximum) as the "dim" setting
[08:51] <thully> My patch basically stops the "adjust brightness" function from being called when dim_on_ac (or dim_on_batt if on battery) is turned off
[08:51] <Riddell> calc: I'd accept it :)
[08:51] <thully> ogra: are you seeing the issue on your end?
[08:51] <ogra> i never noticed it, no ...
[08:51] <thully> but have you tried?  granted, many may not notice if they don't change their brightness to below maximum on idle
[08:51] <thully> on AC, I mean
[08:54] <thully> ogra: hmm, don't know what's going on. I do know some others are seeng this issue (look in the bug report)
[08:55] <evand> slangasek: uh, sure.  Didn't we basically already do that for RC or are you talking about something else?
[08:55] <thully> ogra: are you on a desktop or laptop?  If you're on a desktop, that may explain why you aren't seeing it...
[08:56] <ogra> thully, i'm on a laptop
[08:56] <ogra> but it means nothing if i dont see your prob :)
[08:57] <ogra> my lappie us usually fine with all powermanagement stuff
[08:57] <thully> ogra: OK - and you were idle (i.e. there wasn't some heavy background activity going on)
[08:57] <ogra> no, DPMS kicks in at soe point
[08:58] <thully> what do you mean?  I'm a bit confused...
[08:58] <ogra> well, on idle my screen gets blanked by DPMS from g-p-m
[08:58] <ogra> my display doesnt dim or anything
[08:59] <cjwatson_> evand: it does need a final announce, even if it's mostly the same :-)
[08:59] <ogra> and returning from teh black DPMS screen gets me back to the same brightness level
[08:59] <evand> cjwatson_: gotcha
[08:59] <thully> Oh - one question - did you adjust your display to minimum while you were idle, and make sure you were on AC?  If not, you won't see the issue
[09:00] <ogra> not to minimum  ...
[09:00] <ogra> but pretty low
[09:00] <thully> OK
[09:00] <ogra> oh, its actually minimum
[09:00] <thully> brightness is handled by g-p-m for you, right - not by hardware?
[09:02] <thully> (i.e. you see a g-p-m display when you use the brightness keys, and not a hardware-specific display)
[09:02] <slangasek> evand: I'm told that Gobuntu should have a separate email announcement for ubuntu-announce, because it's separate in many respects
[09:02] <evand> ok
[09:03] <ogra> thully, no idea really (and i'm quite busy with final iso testing atm) it doesnt really matter as i said, lets see that we get a test package into -proposed and put it into an SRU for g-p-m
[09:04] <thully> OK
[09:04] <ogra> if it fixes the issue for all others in a testpackage we can pull it in ... but we need some feedback
[09:05] <thully> One question - are the daily builds out now = Gutsy final barring a catastrophe?
[09:07] <slangasek> tkamppeter: I'm not sure it's a good idea to tell folks in the release notes "if you run into any printing problems, try to deactivate AppArmor for cups", I think that leads folks to not bother reporting bugs we don't know about...
[09:07] <ogra> thully, depends on the bugs we find
[09:09] <thully> OK - I may try a fresh install to see if they changed some settings to resolve the issue - my current install if from the beta ISO (updated , of course). That is possible..
[09:31] <YokoZa1> ScottK: So what does fix committed mean then?
[09:34] <rulus> I would think Fix commited means that the fix is included in upstream's code but not packaged into Ubuntu yet
[09:34] <slangasek> not necessarily upstream.
[09:35] <ScottK> It's landed somewhere visible.  It doesn't seem to matter much where.
[09:52] <slangasek> tkamppeter: can you give me more detail on why your explanation for bug #152537 says "many third-party drivers"? the bug in question only mentions a single backend
[09:52] <ubotu> Launchpad bug 152537 in cupsys "After update from Feisty to Gutsy RC, print jobs fail: "/usr/lib/cups/backend/mfp failed"" [High,Incomplete]  https://launchpad.net/bugs/152537
[09:54] <slangasek> tkamppeter: i.e., I'd really prefer not to list a number of particular printer manufacturers here without being able to justify their inclusion
[09:56] <hunger> Will apparmor actually get used in gutsy?
[09:56] <hunger> So far I only saw some settings for cups, nothing else.
[09:59] <Seveas> hunger, so it will be used for cups :)
[10:00] <hunger> Seveas: I was hoping for a bit more coverage:-) Well, I can always roll my own stuff.
[10:00] <ajmitch> it does cover a lot more than just cups
[10:00] <hunger> The rulesset generator script seems to try to upload to opensuse. Will that get changed in time for gutsy?
[10:01] <hunger> ajmitch: Not in my *ubuntu-desktop install.
[10:01] <ajmitch> hunger: how are you measuring the coverage?
[10:01] <hunger> ajmitch: aa-status reports two installed profiles.
[10:02] <tkamppeter> slangasek, I will remove the names.
[10:03] <hunger> ajmitch: it does, but it is not installed here. Doesn't seem to be part of any -desktop.
[10:03] <Seveas> ajmitch, http://paste.ubuntu-nl.org/40859/
[10:03] <slangasek> tkamppeter: I'm fine with listing names if I can understand why these particular names are listed :)
[10:03] <Seveas> that's a default gutsy
[10:03] <ajmitch> that's probably the problem with me never running a default install :)
[10:04] <mathiaz> hunger: apparmor-profiles is in universe, so it'S not installed by default.
[10:04] <hunger> ajmitch: Plus the aa-profiles are somewhat opensuse specific. Most of the stuff I looked at won't work too well on ubuntu.
[10:04] <ajmitch> right, I should have checked that
[10:05] <ajmitch> apparmor probably wouldn't run properly on my laptop anyway since I load an selinux policy at boot
[10:06] <hunger> ajmitch: You must be pretty clever... I never managed to do that properly.
[10:06] <ajmitch> it didn't take clever, just an initramfs hook
[10:09] <tkamppeter> slangasek, pitti, all release notes from my side are added now (more can come if there are more users reporting bugs too late).
[10:10] <twb> When booting Etch, url=foo will result in an attempt to fetch the preseed file http://foo/d-i/etch/preseed.cfg.  If I just specify url=foo on Ubuntu Feisty/Gutsy, what is the full URL it uses?
[10:17] <slangasek> tkamppeter: thanks, looks pretty good
[10:19] <twb> I can't find the analog of Debian's explanation in https://help.ubuntu.com/7.04/installation-guide/amd64/appendix-preseed.html
[10:20] <evand> twb: I could be wrong, but our d-i doesn't use auto-install (yet?).
[10:20] <evand> twb: cjwatson would be the person to get a definitive answer on that from, but he's away, possibly for the evening.
[10:21] <twb> Wouldn't that mean your d-i is even older than Etch?
[10:21] <evand> no
[10:22] <twb> I'm confused as to what you mean by `auto-install', then.
[10:23] <evand> auto-install is a d-i component that does what you're describing above.
[10:23] <twb> You mean support a default path and protocol?
[10:23] <twb> Because the preseeding itself is quite plainly documented at the above URL, using url=http://foo/bar/preseed.cfg
[10:26] <evand> twb: right, and you can specify a preseed location using url=, but you cannot set url=foo and expect it to produce url=http://foo/d-i/gutsy/preseed.cfg or something similar, as I understand it.
[10:26] <twb> OK.
[10:27] <evand> twb: I'd suggest filing a bug on debian-installer in LP.
[10:28] <twb> It's not worth the effort.
[10:30] <twb> Actually what I'd really like is to be able to preseed via TFTP, rather than having to run an httpd just for the preseed file
[10:31] <oever> hi, in gutsy, libestraier-dev should depend on libqdbm-dev
[10:31] <oever> because /usr/include/estraier/estraier.h requires depot.h
[10:32] <twb> oever: bugs.debian.org/441844
[10:33] <oever> twb: ah great, thanks
[10:47] <tbf> seb128: you probably want to apply that patch to gnome-vfs: http://bugzilla.gnome.org/show_bug.cgi?id=487227
[10:47] <ubotu> Gnome bug 487227 in Async operations "Epiphany randomly crashes and freezes on startup" [Normal,New] 
[10:50] <seb128> tbf: I've subscribed to the bug and will have a look, thanks for pointing it
[10:52] <tbf> seb128: i am just selfish ;-)
[10:57] <Kopfgeldjaeger> n8
[11:19] <slangasek> tkamppeter: I've adjusted the language in the ReleaseNotes about the PDF printing issue (shorten the description, don't give users multiple options for fixing the problem); I'd appreciate your review of the change
[11:42] <slangasek> tkamppeter: um, I specifically didn't use System -> Administration -> Printing though, because AFAIK that's not present under Kubuntu?
[11:43] <tkamppeter> slangasek, I have changed your text again, selcting only one printer setup tool for describing a way to fix the problem of the missing PDF printer I selected system-config-printer due to the fact that the web interface will ask for login and password after setting up the queue.
[11:44] <slangasek> it will?
[11:44] <pitti> slangasek: (NB that system-config-printer is not for KDE and not installed by default on Kubuntu)
[11:45] <slangasek> pitti: yes, that's precisely my point
[11:45] <tkamppeter> slangasek, and even worse, if you start it with http://... and not with https://... it will autoswitch to https://... in the end of the add printer wizard forgetting all enterd data, throughing the user back to the start page.
[11:45] <pitti> ah, right, it's for cups-pdf
[11:45] <slangasek> tkamppeter: well the release notes didn't say http://, they said https://
[11:46] <tkamppeter> slanagsek, sorry, then one of the quirks I already worked around in my original text, but there is still the password issue.
[11:47] <slangasek> ok
[11:47] <tkamppeter> slangasek, pitti, is cups-pdf also installed/available in Kubuntu or any other Ubuntu flavor which does not ship system-config-printer?
[11:48] <slangasek> yes, cups-pdf is a recommends of kubuntu-desktop
[11:48] <pitti> tkamppeter: it's not enough to apt-get install --reinstall cups-pdf, or so?
[11:48] <slangasek> all the other desktop tasks use system-config-printer though
[11:49] <tkamppeter> pitti, by repeatedly doing this you can get lucky that CUPS will pick up once, but also not ...
[11:49] <pitti> tkamppeter: also, we'll fix it in an SRU very early; I don't think that this is a real frontline feature that a lot of people will immediately miss
[11:50] <slangasek> pitti: would you prefer not to release-note it?
[11:50] <tkamppeter> So this means in the release notes you cannot give workarounds to users based on GUI tools, as Kubuntu has a completely different set of GUI tools?
[11:50] <slangasek> no, it just means we should be aware of this when picking workarounds to document
[11:51] <pitti> slangasek: I'd say it depends on the number of caveats that are on the page; it shouldn't be more than a handful
[11:51] <tkamppeter> So I suggest to perhaps have to release note files, one for Kubuntu, another for the rest
[11:51] <slangasek> pitti: we already have quite a few
[11:51] <pitti> tkamppeter: no, that's fine, since Kubuntu has its own web page (including caveats)
[11:51] <pitti> slangasek: we probably have hundreds of caveats at this level :)
[11:53] <slangasek> pitti: "its own web page" including the release notes?
[11:53] <pitti> slangasek: well, I mean the "Caveats" section of the announcement page; you mean something else?
[11:54] <slangasek> pitti: this is the release notes that I'm talking about
[11:56] <pitti> ah, https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes ?
[11:56] <slangasek> yes
[11:57] <tkamppeter> Does Kubuntu have a menu entry System -> Administration -> Printing? As I did not say "system-config-printer" in my text it will perhaps fit.
[11:58] <pitti> Riddell: ^
[11:59] <Riddell> no, k-menu -> System Settings -> Printers
[11:59] <Riddell> although I don't know if you can install the CUPS pdf device from that (KDE has its own built in one of course)
[11:59] <pitti> tkamppeter: wouldn't help you much anyway, I figure, since the workflow within the printer tool is completely different
[12:02] <tkamppeter> Riddell, if the KDE Printing manager shows all entries of "lpinfo -v" it will be able to set up the PDF printer, especially because cups-pdf ships the PPD ready-made and not a PPD generator.
[12:05] <tkamppeter> Does Kubuntu exclusively ship KDE apps, all having the KDE printing dialog with built-in PDF (so no Firefox, Thunderbird, ...)? In this case one could remove cups-pdf from Kubuntu.
[12:06] <Riddell> it does (plus openoffice which won't need it), but people also install firefox and thunderbird
[12:06] <Riddell> not that I'm too fussed if the release notes don't have a KDE fix, as you say it's KDE's fault for being behind on printing
[12:06] <slangasek> "remove cups-pdf from Kubuntu" -> out of scope, we're discussing issues to be documented, not changes to the OS
[12:08] <tkamppeter> slangasek, I hope app developers (esp. Firefox/thunderbird) will allow us to do away with cups-pdf in all our flavors in Hardy or at least Hardy+1.
[12:10] <tkamppeter> Riddell, WDYT, should we describe both the GNOME and the KDE way to set up a PDF printer in the release notes, or should we have separate release notes for KDE (in that ones one can also drop the two points about users-admin).
[12:11] <pitti> well, IMHO the release notes are full enough already; it's just a race condition of a relatively minor feature which is a perfect SRU candidate, so I wouldn't worry about it too much; just my 2, of course
[12:11] <pitti> and it only happens on really slow machines
[12:12] <pitti> my 'two vmware installs and a CD burn in parallel' use case isn't really typical, I'd hope
[12:12] <pitti> tkamppeter: and I doubt that it affects desktop installs in the first place
[12:12] <pitti> (just alternate)
[12:12] <slangasek> why would that be?
[12:12] <slangasek> I mean, I tend to agree with you that we can probably do without documenting this one
[12:12] <slangasek> but I don't see why it would be specific to alternates
[12:13] <tkamppeter> pitti, so my "sleep 3" will probably help in 99% of the cases.
[12:13] <pitti> well, the PDF queue shuold be created at livefs build time, not when the user installs the system with ubiquity, or am I totally wrong here?
[12:13] <Riddell> tkamppeter: since I don't know of any GUI workaround in KDE, I would just leave it out
[12:13] <slangasek> pitti: oh, perhaps it would at that
[12:14] <tkamppeter> pitti, are print queues from livefs transferred to the ubiquity-installed system on the hard disk?
[12:15] <tkamppeter> Riddell, you mean points as users-admin points, so that the release notes are fine for you becuase there are no KDE issues worth to document?
[12:16] <pitti> so merely testing if it is present on the current live CDs ought to be sufficient?
[12:16] <pitti> s/live/desktop/
[12:16] <pitti> .. in the live systems
[12:16] <pitti> tkamppeter: not the ones you create *in* the live system
[12:16] <pitti> tkamppeter: but AFAICS the default printers.conf from livefs build time shuold be copied?
[12:16] <pitti> tkamppeter: when we do an ubiquity install, that doesn't run any postinsts
[12:16] <pitti> that's all done in the livefs build
[12:19] <tkamppeter> pitti, then you should run a certain amount of the same live CD build and check whether every build has a PDF queue, as otherwise we are either lucky and 100% of our users have a PDF queue or no one (for each flavor).
[12:19] <Riddell> tkamppeter: the users-admin release note is slightly different, there it is the gnome tool which is broken but the KDE tool is fine so no need to mention KDE, with cups-pdf I don't see a workaround for KDE so I'd just leave out any mention of KDE since there's not much a user can do
[12:19] <pitti> currently booting i386 and amd64 desktops
[12:20] <tkamppeter> Riddell, OK. GNOME is better with printer setup and KDE is better with user/group management currently ...
[12:20] <Riddell> :)
[12:22] <pitti> tkamppeter, slangasek: hm, neither i386 nor amd64 lives have the PDF queue
[12:22] <slangasek> in the images?
[12:23] <tkamppeter> pitti, can it be that the installation of the CD building progress is much slower than an alternative CD installation (or even the single-package installation which I did)?
[12:23] <pitti> Setting up cups-pdf (2.4.6-3ubuntu10) ...
[12:24] <pitti> is all the log says
[12:24] <pitti> there's no debugging info or error reporting
[12:25] <pitti> tkamppeter: very well possible that cupsd does not even start
[12:25] <slangasek> heh
[12:25] <pitti> the livefs build machinery might have a daemon-suppressing policy-rc.d, I don't know
[12:26] <elmo> it doesn't, AFAIK and FWIW but IANARBA
[12:27] <slangasek> you are not a red-bearded albatross?
[12:27] <pitti> slangasek, tkamppeter: a mere "sudo dpkg-reconfigure cups-pdf" DTRT here, thoug
[12:27] <pitti> h
[12:30] <tkamppeter_> pitti (and anyone else), can you repost your answers on my last three messages? There was a short interruption.
[12:31] <pitti> done in /query
[12:33] <tkamppeter_> Thanks pitti, seems that not all of my messages arrived, I will repeat them.
[12:33] <tkamppeter_> pitti, the postinst script of cups-pdf restarts CUPS and this should at least say something like "restarting CUPS". Can it be that in an initial installation where all packages get installed at once, cups-pdf is installed before CUPS?
[12:33] <tkamppeter_> cups-pdf depends on cupsys, does this not mean that the cupsys installation has to be completed before the cups-pdf installation starts?
[12:33] <tkamppeter_> And what does the "Pre-Depends: cupsys (>= 1.1.15)" mean?