[01:28]  * calc hopes he didn't damage his car tonight, had to drive through water :\
[01:33] <ebroder> Hmm...I didn't realize I wasn't joined. Sorry
[04:14] <jtholmes> popey, are you still around
[04:28] <jtholmes> popey i have a question about screencasts
[04:39] <nhandler> jtholmes: popey is probably sleeping right now. I would suggest either sending him an email or /msg, or trying to contact him tomorrow
=== racarr_ is now known as racarr
[04:56] <jtholmes> nhandler, ok thx not important tonight
=== pace_t_zulu_ is now known as pace_t_zulu
[06:04] <LaserJock> does anybody happen to know if it'd be possible to promote packages in Jaunty?
[06:06] <slangasek> it's not, no
[06:06] <LaserJock> figured, just thought I'd ask
[06:07] <slangasek> once the release is done, no changes are made to the release pocket; and promoting a package in the -updates pocket would just be confusing
[06:07] <LaserJock> I've got a regression and I don't know how to fix it otherwise
[06:07] <LaserJock> I wouldn't think "we're SRU'ing a copy of a lib into Main" would fly
[06:10] <slangasek> generally not
[06:10] <slangasek> what's the regression?
[06:11] <LaserJock> bug #359517
[06:11] <ubottu> Launchpad bug 359517 in kdeedu "kstars does not support indi" [Critical,Triaged] https://launchpad.net/bugs/359517
[06:12] <LaserJock> the new upstream release of indi got new package names, but kstars wasn't transitioned
[06:12] <LaserJock> but apparently building with the old indi doesn't give the desired result
[06:13] <LaserJock> so I guess the task would be to figure out how to get kstars to work properly with the older version
[06:13] <ScottK> LaserJock: That or 'fix' it in -backports where nothing cares about Main/Universe
[06:14] <ScottK> That'll cause other problems though
[06:17] <ScottK> Good night.
[06:17]  * ScottK heads to bed.
[06:17] <LaserJock> night
[06:20] <ScottK> LaserJock: Would you please ping me?
[06:20] <LaserJock> ScottK: ping
[06:20] <ScottK> LaserJock: Thanks.
[06:21]  * calc gone to bed too
[06:23] <LaserJock> what is the general opinion of using PPAs for this sort of thing?
[06:23] <LaserJock> i.e. either temporary fixes of fixes that can't make it into -updates for whatever reason?
[06:25] <LaserJock> s/of/or/
[06:28] <wgrant> LaserJock: PPAs aren't such pure evil now that they're signed, and there are quite a few semi-official ones.
[06:29] <LaserJock> I wonder if I could put a easy fix kstars in ~edubuntu-dev PPA and put it on edubuntu.org as a workaround
[06:29] <LaserJock> *an
[07:09] <pitti> Good morning
[07:20] <dholbach> good morning
[08:48] <geser> good morning
[08:52] <Keybuk> mvo: interesting, update-manager popped up this morning and its lists were out of date
=== tkamppeter_ is now known as tkamppeter
[09:17] <dholbach> ArneGoetje: how does bug 241904 look to you?
[09:17] <ubottu> Launchpad bug 241904 in language-selector "[Hardy] Single quote prevents synaptic from running in language-selector" [Undecided,Confirmed] https://launchpad.net/bugs/241904
[09:18] <mvo> Keybuk: oh? how much out of date? what do the timestamps in /var/lib/apt/periodic/update-success-stamp look like?
[09:22] <pitti> oh, is karmic now open for development?
[09:22] <Keybuk> mvo: I installed updates yesterday
[09:22] <Keybuk> today update-manager shows the same updates until I click Check
[09:22] <dholbach> pitti: https://launchpad.net/ubuntu/karmic says "Active Development" and not "Pre-Release Freeze" anymore
[09:23] <pitti> \o/
[09:23] <dholbach> I didn't see an announce either though
[09:24] <pitti> I flush the karmic unapproved queue then
[09:24] <pitti> I saw people doing uploads, so that should be okay
[09:24] <pitti> slangasek, cjwatson: ^ FYI
[09:24] <pitti> time to upload crack!
[09:24]  * pitti uploads new hal
[09:25] <slangasek> pitti: yah, I got to step 22, hadn't gotten any farther yet :)
[09:28] <slangasek> pitti: perhaps you could write a quick mail to u-d-a?
[09:28] <pitti> slangasek: will do
[09:29] <Keybuk> pitti: does new hal use libvolume-id or libblkid?
[09:31] <pitti> Keybuk: volume-id
[09:31] <pitti> it hasn't really changed a lot in ages
[09:31] <pitti> I'm going to package DK-disks soon
[09:32] <Keybuk> *nods*
[09:32]  * Keybuk peeks at the incoming crazy crack
[09:32] <Keybuk> +config DEVTMPFS
[09:32] <Keybuk> +       string "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
[09:32] <Keybuk> +       depends on HOTPLUG
[09:34] <pitti> slangasek: done (shamelessly stolen from jaunty announcement)
[09:34] <Keybuk> udev and devfs had a lovechild!
[09:34] <slangasek> \o/
=== slangasek changed the topic of #ubuntu-devel to: Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[09:35] <slangasek> Keybuk: isn't devfs udev's uncle? :P
[09:35] <Keybuk> slangasek: devfs was a very bad uncle
[09:35] <Keybuk> it liked udev to play special games in the bath
[09:36] <slangasek> I have high hopes for their offspring
=== virtuald_ is now known as virtuald
[09:40] <Keybuk> slangasek: the basic idea being that the kernel has a tmpfs internally, and it mknods in there as it makes entries in sysfs
[09:40] <Keybuk> you mount that tmpfs as /dev
[09:40] <Keybuk> then udev simply adjusts it, e.g. renames or permissions
[09:41] <slangasek> oh, we're having an actual technical conversation now
[09:41] <slangasek> :)
[09:42] <ogra_> Keybuk, how does that work with /dev/console and the other few devices the kernel needs in advance
[09:43] <Keybuk> ogra_: the kernel doesn't need it?
[09:43] <ogra_> console ?
[09:43] <Keybuk> right
[09:43] <ogra_> hmm, why does it panic then if it has none :P
[09:43] <slangasek> because init needs it and dies miserably if it's not there
[09:43] <slangasek> that's not the kernel's fault
[09:43] <Keybuk> I think you're confusing the lack of a console and the lack of /dev/console
[09:44] <ogra_> oh, yeah, i do
[09:44] <Keybuk> the devtmpfs idea is intended to solve the "device nodes before udev is started" problem
[09:45] <ogra_> right
[09:45] <ogra_> i understood that but was wondering about /.dev
[09:45] <Keybuk> what's /.dev ?
[09:46] <ogra_> wasnt there a /.dev in initramfs ?
[09:46]  * ogra_ is probably a bit behind
[09:46] <Keybuk> I don't think so
[09:46] <Keybuk> there's a /dev/.initramfs
[09:46] <Keybuk> (which can probably be moved to /var/run)
[09:46] <ogra_> yeah, thats what i mean
[09:47] <ogra_> hmm, no, looking at it its not what i mean ... whats the pre-populated dir called that has console and a few ttys etc ?
[09:48]  * ogra_ thought that was /.dev once
[09:54] <tkamppeter> pitti, hi
[09:55] <mdz> ogra_: you're thinking of /dev/.static
[09:55] <mdz> which is the /dev on disk over which the tmpfs is mounted, which has persistent (but potentially wrong) device nodes
[09:57] <pitti> hey tkamppeter
[09:57] <tkamppeter> pitti, it is about the SRU bug 357732.
[09:57] <ubottu> Launchpad bug 357732 in cups "cups always prints with the default page size" [High,Fix committed] https://launchpad.net/bugs/357732
=== thekorn_ is now known as thekorn
[10:00] <tkamppeter> I have done a second fix in pstopdf, which fixes the problem of Shaun Crampton, his PPD has the default values directly after the colon of "*Default<option>:", without space, and the current pstopdf does not support this. So I have fixed this upstream now and also in the Debian BZR of CUPS.
[10:00] <tkamppeter> I wouls like to SRU this, too to make the paper size handling safely work in all situations.
[10:02] <tkamppeter> pitti, but as the first fix is very urgent, I suggest that you put it into -updates immediately, as it renders printing non-functional for most users, and after that we put the second into -p[roposed.
[10:02] <pitti> tkamppeter: I agree, since the current patch doesn't cause regressions, it just doesn't fix it for everyone
[10:03] <pitti> tkamppeter: did you see that the second patch didn't fix it yet for Michael Gefen?
[10:03] <tkamppeter> pitti, it fixes the problem for 90 %of the users (everyone who does not use the crazy printerr tool which Shaun has used).
[10:03] <pitti> tkamppeter: right, I mean your followup patch
[10:05] <tkamppeter> Michael Gefen has another problem. He is once taking a PDF which reaches up to all borders and expects it to appear completely on the printout. With acroread he succeeds as it scales by default but evince does not scale. evince has also a bug that it defaults its paper size to Letter even with an A4 document and an A4 printer (it does so at least for me). So he is running into several evince or GTK Print bugs.
[10:06] <pitti> okay
[10:06] <apw> pitti, hey ... bugs tagged regression-potential are presumably now regression-released.  will someone/something do that or do we need to do it manually??
[10:06] <tkamppeter> pitti, so put the current SRU through ASAP and then we do another SRU for my second fix.
[10:07] <pitti> apw: hm, I don't know; bdmurray?
[10:07] <pitti> tkamppeter: copied
[10:11] <pitti> tkamppeter: sorry, X froze; if you replied to my "cups copied", I lost it
[10:14] <tkamppeter> pitti, I did not reply to it.
[10:14] <pitti> tkamppeter: hm, I get a merge conflict when I cherrypick your trunk patch to the jaunty branch; seems that the jaunty sru and the trunk one had slightly different fixes?
[10:15] <tkamppeter> pitti, I have uploaded my newest version into the trunk.
[10:15] <pitti> anyway, I take the version from trunk
[10:15] <pitti> which I believe is what we need
[10:16] <tkamppeter> You can check by downloading my last pstopdf from the bug and compare.
[10:16] <ogra> slangasek, do you still take release note entries ?
[10:16] <pitti> tkamppeter: oh, I see; the jaunty branch had an additional line: if test -n "$pagesize" && test -e "$PPD"; then
[10:16] <ogra> slangasek, bug 368079 looks like a very good candidate if so ...
[10:16] <ubottu> Launchpad bug 368079 in ltsp "ltsp-client chroot is missing the python-serial package" [Undecided,New] https://launchpad.net/bugs/368079
[10:16] <pitti> tkamppeter: ok, got it
[10:17] <pitti> tkamppeter: there's still al large diff between the jaunty and trunk version of pstopdf, but I got the cherrypicking now
[10:18] <tkamppeter> pitti, are you comparing with the original Jaunty or with the SRUed Jaunty (my first fix).
[10:19] <pitti> SRUed, current jaunty branch head
[10:19] <tkamppeter> What we should have is exactly my current pstopdf, the second one which I have uploaded to the bug (be careful, one of the users has also uploaded the intrepid pstopdf to the bug).
[10:20] <pitti> tkamppeter: http://paste.ubuntu.com/159895/
[10:21] <pitti> tkamppeter: anyway, I cherrypicked your latest fix, this is it: http://bazaar.launchpad.net/%7Eubuntu-core-dev/cups/jaunty/revision/652
[10:22] <tkamppeter> pitti, I see the difference, between the two fixes I added support for custom paper sizes, but this is also important, as we got already user complaints with custom paper sizes. So include it with the custom paper size bits.
[10:23] <pitti> tkamppeter: needs another SRU bug, though, as it's quite an intrusive change
[10:23] <pitti> or is it related to this bug?
[10:25] <tkamppeter> pitti, there is another bug where we could offer this as an SRU, one moment.
[10:30] <tkamppeter> pitti, if you are in the situation of bug 338999. Only this user has printed only PDF files and so not exercised pstopdf. Seems that I have to do a test to see whether the pstopdf change is required.
[10:30] <ubottu> Launchpad bug 338999 in foomatic-filters "Custom PageSize has broken with lp/foo2zjs after upgrade to 8.10" [Medium,Fix released] https://launchpad.net/bugs/338999
[10:37] <tkamppeter> pitti, I have done a quick test now, if the input file is PostScript, custom page sizes only work with my fix.
[10:38] <pitti> tkamppeter: as I said, if you think it's a major regression, please prepare the bug for SRU and point to the bzr commit
[10:38] <pitti> for cherrypicking
[10:39] <tkamppeter> pitti, this means to report a bug and suggest it for an SRU?
[10:39] <pitti> tkamppeter: if there isn't an existing bug report for it, it's hardly important enough for an SRU
[10:41] <tkamppeter> pitti, AFAIR there is no bug on Custom PageSize, seems that because no printing dialog supports Custom PageSize it rarely happens. Seems it is more relevant for the Common Printing Dialog as then we will enter with a feature-complete dialog for the first time ever.
[10:41] <pitti> tkamppeter: let's not worry about it for SRU then
[10:42] <tkamppeter> Yes, I keep it as upstream fix and if someone complains about custom page size not working before the CPD arrives I simply attach the current upstream state of pstopdf to his bug report and mark it fixed in Karmic.
[10:43] <tkamppeter> Otherwise custom page size is really only a subject for the CPD generation.
[10:45] <pitti> tkamppeter: ok, so I'll upload the space fix to -proposed then
[10:45] <tkamppeter> pitti, and for Karmic all my changes and fixes are already in. So if you upload CUPS to Debian the sync bot will get it to LKarmic.
[10:45] <pitti> right
=== Johnm_ is now known as johnm_work
=== azeem_ is now known as azeem
=== cjwatson_ is now known as cjwatson
=== savvas_ is now known as savvas
[12:13] <siretart`> most spectacular bug ever: (IMO) https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28
[12:13] <ubottu> Ubuntu bug 255161 in cupsys "I am unable to print from open office, I tried reinstalling open office but it did not work. I use a brother mfc240c printer and I am running Hardy. Printing from other apps has not been an issue." [Undecided,Invalid]
=== nhandler is now known as Guest21024
[12:27] <cjwatson> siretart`: that's a fabulous bug
[12:28] <siretart`> :-)
[12:28]  * cjwatson targets bug 248619 for a bunch of releases
[12:28] <ubottu> Launchpad bug 248619 in file "file incorrectly labeled as Erlang JAM file" [High,Confirmed] https://launchpad.net/bugs/248619
[12:29] <infinity> That's... An incredibly awesome bug.
[12:29] <siretart`> yes. Having to ask bug submitters for the day of the week they tried the package is, uhm, funny?
[12:30] <infinity> Is it wrong that I want to leave it unfixed, just due to the sheer awesome that it embodies?
[12:30] <siretart`> most funnily, the bug can only be validated tuesdays :-)
[12:37] <cjwatson> is somebody already taking care of forwarding that bug to Debian? the Debian file maintainer is rather picky, IIRC
=== keffie_jayx is now known as effie_jayx
[12:45] <ogra> infinity, dont abuse LP, just put it on t-shirts :)
[12:47] <infinity> ogra: I didn't mean "unfixed in LP", I literally meant "unfixed"... Which would qualify more as "abusing users" than "abusing LP".
[12:48] <ogra> lol, oh, then i misunderstood *g*
[12:48] <infinity> ogra: But it could become a part of Ubuntu certification training.  People would phone up help desks and say "I can't print, HALP!"... And they'd respond with "well, yeah, duh, it's Tuesday."
[12:49] <ogra> lol
[12:51] <olmari> X-)
[12:52] <highvoltage> poor techie who is called out to fix the problem, he struggles all day just to have the client phone him and say "hey don't worry, it's working again!"
[12:53] <highvoltage> just to have the same thing happen the next week, and again, and again
[12:57] <directhex> i don't like tuuuuuuuueeeeesdays! tell me why!
[12:59] <chrisccoulson> directhex - you just spoiled my day - i honestly thought it was wednesday today :(
[13:00] <ogra> seb128, so i just tried to use my ekiga for the first time since i use jaunty, where is my setup gone ?
[13:00] <directhex> chrisccoulson, it can't be wednesday, the printers aren't working!
[13:00] <seb128> ogra: why you don't ask somebody who has touched ekiga once?
[13:00] <ogra> seb128, oh, who has it ?
[13:00] <seb128> ogra: I don't use it and never worked on the package so no clue
[13:00] <seb128> ogra: nobody I think
[13:01] <seb128> kenvandine_wk did the upgrade
[13:01] <ogra> ouch
[13:01] <seb128> and pitti tested with him
[13:01] <seb128> but there is no official maintainer for it in ubuntu
[13:01] <ogra> well, ekiga wiping the whole former setup is surely worth a release note
[13:01] <seb128> it's not the case for everybody
[13:01] <ogra> pitti, ^^^ did you test with an existing VOIP setup ?
[13:01] <cjwatson> traditionally we write release notes after understanding the problem :)
[13:02] <seb128> pitti has been testing upgrades with working accounts
[13:02] <ogra> weird
[13:02] <seb128> since he spoted some config not migrated issues and got those fixes
[13:02] <seb128> got those fixed
[13:02] <ogra> well, my config wasnt migrated for sure ... and i got autoconnected to ekiga.net
[13:03] <seb128> that's a bug
[13:03] <seb128> but that doesn't mean it happens to everybody
[13:03] <ogra> i havent used ekiga since intrepid though ...
[13:03] <ogra> which is quite a while ago ... not sure how to track that down now that i started it once
[13:04] <james_w> Our house used to lose Internet connection when it got warm, it took months for the technicians they sent out to believe me.
[13:05] <james_w> "yes, it's working fine today because it is cloudy, please come back when it is sunny"
[13:07] <directhex> james_w, sounds like BT to me ^_^
[13:07] <james_w> Virgin
[13:07] <directhex> ew, even worse
[13:07] <james_w> they are generally pretty good IME, but they just couldn't quite believe it
[13:08] <kenvandine_wk> seb128: i migrated my old setup
[13:08] <kenvandine_wk> it just worked
[13:08] <kenvandine_wk> ogra: what version did you upgrade from?
[13:09] <ogra> kenvandine_wk, whatever we used in intrepid
[13:09] <pitti> ogra, seb128: yes, settings migration was something I particularly looked at, since it failed badly for 2.x->3.0 (and thus 3.0 didn't go into intrepid)
[13:09] <kenvandine_wk> the previous version we had included some patches that handled migration, but 3.2 supposedly didn't need the migration patches, it was built in
[13:09] <pitti> same here, it worked fine, and I can also create/change existing accounts
[13:10] <ogra> i cant even do the echo test atm
[13:10] <pitti> ogra: @ekiga.net service is broken more often than not, though
[13:11] <pitti> ogra: does it work with the canonical account or any other?
[13:11] <ogra> no
[13:11] <kenvandine_wk> ogra: yeah, i can't use ekiga.net most of the time it seems
[13:11] <ogra> thats what i meant
[13:11]  * pitti has a diamondcard account which has never failed so far
[13:11] <ogra> not using ekiga.net here
[13:11] <pitti> confirmed, @ekiga echo test doesn't work ATM
[13:11] <pitti> Canonical account works fine
[13:13] <ogra> hmm
[13:14] <ogra> seems i'm properly connected to my canonaicl account ... looks more like an issue with the audio settings
[13:14] <kenvandine_wk> errors i get connecting to ekiga are always server side, i have tried debugging it
[13:14] <kenvandine_wk> the error is server hungup
[13:14] <kenvandine_wk> ekiga.net that is
[13:15] <ogra> yes, as i said before i'm not using ekiga.net
[13:17]  * ogra wonders where to disable STUN and NAT ... seems the options arent there anymore
=== JayFo is now known as JFo
[14:26] <tkamppeter> pitti, are you maintaining the hal package?
[14:46] <cjwatson> doko: do you have any thoughts on what should be done with the glibc sparc test failure?
[14:47] <ogra> .oO(throw it at NCommander until it stops failing)
[14:47] <ogra> he is eager to fix such stuff and has the HW at home
[14:48] <cjwatson> I care because the last version that built is immediately before we turned off the annoying fwrite warn_unused_result attribute, so anything that stops bothering to take account of that FTBFS on sparc
[14:48] <cjwatson> NCommander: ^- feel free :-)
[14:51] <rtg> cjwatson: whats the story on debootstrap and karmic?
[14:53] <cjwatson> rtg: it works
[14:53] <cjwatson> as long as you have karmic's debootstrap, anyway
[14:53] <rtg> cjwatson: ok, maybe I'm just too stupid to find the right version.
[14:53] <cjwatson> you need 1.0.13
[14:53] <rtg> jaunty backports, right?
[14:53] <cjwatson> not yet, but I'll shove it in there now
[14:53] <ogra> just pull it directly from karmic
[14:53] <cjwatson> as ogra says
[14:54] <rtg> doh! ko.
[14:54] <rtg> ok, even
[14:55] <cjwatson> it'll be in jaunty-backports in a couple of hours if you prefer
[14:56] <rtg> cjwatson: thanks
[14:56] <cjwatson> of course that's not to say that the base system will actually all manage to install correctly, at least once we start syncing the world
[14:56] <cjwatson> if you're desperate you can debootstrap jaunty and then upgrade the chroot
[14:56] <doko> cjwatson: hmm, debian does ignore the test on kfreebsd-*, have to turn on the sparc to check.
=== jorge_ is now known as jcastro
[15:05] <rtg> cjwatson: not desperate, but I would like to get the Karmic kernel building using the new toolchain soon. I'll figure it out.
[15:33] <pitti> tkamppeter: yes, I do
[15:34] <tkamppeter> pitti, I have moved bug 368553 to you now.
[15:34] <ubottu> Launchpad bug 368553 in hal "[jaunty] [TYPO in script - missing quote] line 81: unexpected EOF while looking for matching `"' /usr/lib/hal/scripts/linux/hal-system-killswitch-get-power-linux: line 84: syntax error: unexpected end of file. " [Medium,Triaged] https://launchpad.net/bugs/368553
[15:35] <pitti> tkamppeter: I saw that one
[15:35] <pitti> I'll get to it
[15:47] <doko> pitti, cjwatson: please could you demote java-gcj-compat (source & binaries)?
[15:51] <cr3> what's the wiki page explaining how versions should be named?
[15:58] <cjwatson> cr3: versions of what?
[15:59] <cr3> cjwatson: packages, like 1.0-ubuntu1~ppa2 for example
[15:59] <cjwatson> doko: it's not in component-mismatches, and a bunch of stuff still depends/build-depends on it - you sure?
[15:59] <cjwatson> cr3: policy manual
[15:59] <cjwatson> you construct versions by understanding the rules by which they are compared
[16:00] <doko> cjwatson: gcj-* does provide it
[16:00]  * cjwatson tries to work out why it hasn't fallen out of c-m then
[16:02] <cjwatson> doko: should it perhaps just be removed?
[16:02] <cjwatson> I suspect that as long as it's in the archive it will sometimes end up being chosen in preference to some other package providing it
[16:02] <cjwatson> mixed real/virtual dependencies are tricky
[16:02] <doko> cjwatson: ok, removal is fine as well
[16:03] <doko> maybe block it syncing from debian
[16:03] <cjwatson> doko: oh, the Provides will have no effect on versioned dependencies
[16:04] <cjwatson> I think there are a few of those
[16:04] <doko> cjwatson: yes, known, there are just a few (openjdk, OOo in main)
[16:04] <cjwatson> the only downside of removal is that it will not be possible to go back to gcj-4.3 if 4.4 fails to build some things
[16:06] <doko> well, we default to openjdk anyway, so we have another alternative
[16:06] <cjwatson> mm, right
[16:07] <doko> and I'm wondering why OOo still uses java-gcj-compat ...
[16:08] <cjwatson> doko: ok, removed and sync-blacklisted
[16:08] <cjwatson> we may be able to resurrect it if you find out you need it back
[16:09] <doko> hope I don't need it ...
=== thekorn_ is now known as thekorn
[16:39] <fbond> Hi.  I have an 8.04 machine that locks up after hours or days with an X app running.  I'm trying to pin point the problem so I can file an appropriate bug.  I don't see anything telling in kern.log, the X log, etc.  What can I do to get the system to give me more useful information?
[16:41] <d1b> hi is ubuntu aware of the sctp poc attack code out ?
[16:41] <d1b> or should i ask on ubuntu harded ?
[16:41] <d1b> http://kernelbof.blogspot.com/2009/04/kernel-memory-corruptions-are-not-just.html#comments
[16:48] <jdong> d1b: cool exploit, but any time kernel memory corruption is present it is not surprising that it is game over.
[16:48] <pitti> a friend of mine upgraded to jaunty and applauds us for the boot speed; passing on the credit
[16:49] <jdong> the only crime here seems to be that most vendors (including ourselves) did not accurately portray the extent of the exploit.
[16:51] <d1b> jdong: i think sctp is not used by the majority of people and shouldn't be compiled by default on desktop systems.
[16:52] <d1b> the issue is that some one else is going to mod this and post it on another site / just use it so it exploits all platforms no matter the arch /kernel....
[16:53] <amitk> d1b: sctp is a module
[16:53] <d1b> where possible...
[16:53] <jdong> d1b: I don't see sctp enabled on any of my stock Ubuntu systems
[16:53] <NCommander> Anyone in the mood to sponsor seed changes in karmic?
[16:53] <NCommander> https://bugs.edge.launchpad.net/ubuntu-seeds/+bug/368677
[16:53] <d1b> amitk: good, i didn't check the ubuntu config.
[16:53] <ubottu> Ubuntu bug 368677 in ubuntu-meta "Please change the seeds to make usplash only seeded on arches that support it." [Undecided,New]
[16:53] <jdong> the user has to enable it himself
[16:53] <d1b> jdong: so you would need to load a sctp application. i take it
[16:54] <jdong> d1b: run a SCTP server on the host to be attacked, correct.
[16:54] <jdong> d1b: of course, my deepest condolences to those who do run SCTP servers on unpatched servers :)
[17:02]  * jdong is still a bit disappointed there isn't a GUI configurable option for update-notifier behavior
[17:06] <ogra> jdong, pgtk and glade ;) provide one in a ppa should be less than 10 lines of code
[17:06] <ogra> *pygtk
[17:15] <cjwatson> NCommander: why is usplash present on hppa and ia64 in the first place if it doesn't work?
[17:15] <cjwatson> NCommander: if the package weren't present, then it wouldn't be included in ubuntu-desktop
[17:15] <cjwatson> germinate-update-metapackage is smart like that
=== calc_ is now known as calc
[17:16] <NCommander> cjwatson, it used to be built on those architectures, but no longer. ubuntu-desktop tries to pull it in via the artwork package (which is installable and has a hard depends)
[17:17] <ogra> should be a recommends
[17:17] <infinity> cjwatson: It's not still around...
[17:17] <infinity> cjwatson: It hasn't been in the archive on those arches since intrepid...
[17:17] <cjwatson> in that case I don't get why ubuntu-meta's ./update is pulling it in, and want to investigate that, not band-aid around it with seed fixes
[17:18] <ogra> and actually its not even a recommends on jauntys ubuntu-artwork
[17:18] <cjwatson> that said, usplash-theme-ubuntu needs to be removed from the archive on those architectures
[17:18] <ogra> Depends: human-theme (>= 0.14), ubuntu-gdm-themes, ubuntu-wallpapers
[17:18] <ogra> no usplash at all, i would suspect the artwork package is outdated on these arches
[17:18] <cjwatson> ogra: I don't think this is remotely relevant here
[17:19] <NCommander> cjwatson, ogra: heres the output of apt-get install ubuntu-desktop on HPPA http://paste.ubuntu.com/160087/
[17:19] <NCommander> (it looks similar on ia64)
[17:19] <cjwatson> NCommander: yes, I know the ubuntu-desktop dependencies are wrong. What I want to know is *why*.
[17:19] <cjwatson> because germinate-update-metapackage is supposed to filter out nonexistent packages from the dependencies
[17:19] <ogra> NCommander, right, and no artwork package in there ...
[17:20] <infinity> cjwatson: If the theme is kicking around, that would explain the why.
[17:20] <cjwatson> infinity: that would explain it for the theme
[17:20] <infinity> cjwatson: Since usplash is a direct dependency of the theme, no?
[17:20] <cjwatson> it doesn't explain why there's a direct Depends: usplash from ubuntu-desktop on ia64, too
[17:20] <infinity> cjwatson: germinate won't filter out required deps, will it?
[17:21] <ogra> right, usplash is a direct dep
[17:21] <cjwatson> sure should
[17:21] <cjwatson> that's why it bothers to fetch package lists
[17:21] <cjwatson> packages listed in seeds are only "required" if they actually exist on the architecture being germinated
[17:21] <NCommander> Is it possible usplash never got removed from disk on those archs?
[17:22] <cjwatson> it's not on disk now
[17:22] <NCommander> Oh ...
[17:22] <cjwatson> it could be that it was only removed after ubuntu-meta was last updated
[17:25] <MrSunshine_> hmm, befs driver, why isnt that shipped with ubuntu ? ... atleast as a module it hink it should be in there :/
[17:25] <infinity> cjwatson: Unlikely.  It hasn't been built on hppa/ia64 since 0.5.21, I believe.
[17:26] <cjwatson> it hasn't been *built*, but we often take a while to get round to ports-architecture NBS removals
[17:26] <infinity> cjwatson: Yeah.  0.5.21 added the arch restriction.  And that was way back in intrepid.
[17:26] <infinity> cjwatson: Oh, fair point on the NBS...
[17:26] <cjwatson> for example intrepid still has the 0.5.20 binaries
[17:27] <cjwatson> and I'm only just removing all the usplash theme binaries now, even though they can't have built for ages
[17:27] <infinity> #  Removal requested  on 2009-04-09.
[17:27] <infinity> # Deleted on 2009-04-09 by Steve Langasek
[17:27]  * NCommander tests ubuntu-meta
[17:28] <NCommander> cjwatson, I didn't know that about seeds ignoring packages that didn't exist. Sorry about the noise :-/
[17:28] <infinity> cjwatson: Last meta was in March, so your guess is probably spot on there.
[17:28] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/testing-ports/karmic_outdate_all.txt is a pretty good demonstration of how bad the arch-specific NBS problem has got
[17:28] <infinity> cjwatson: Didn't realise the binaries were so recently removed.
[17:28] <cjwatson> NCommander: it'll be worth giving it a try in about 1.5 hours, when the removal takes effect
[17:28] <cjwatson> (of usplash-theme-ubuntu)
[17:29] <cjwatson> infinity: where do you see the removal comment? I had trouble finding it
[17:29] <NCommander> cjwatson, I'll close the bug and delete the branches, thank you for looking into this; ubuntu-desktop on HPPA is now installable :-)
[17:29] <infinity> cjwatson: https://edge.launchpad.net/ubuntu/jaunty/hppa/usplash
[17:29] <cjwatson> NCommander: the ubuntu-meta task is still valid
[17:29] <cjwatson> I closed the seeds task
[17:29] <cjwatson> infinity: ah, thanks
[17:36] <cjwatson> apw: so, bug 251242; do you care if I upload it first to karmic as 20090000-2.0.0ubuntu4, and then SRU to jaunty-proposed as 20090000-2.0.0ubuntu3.1?
[17:36] <ubottu> Launchpad bug 251242 in kexec-tools "Always kexecs on shutdown/reboot" [Medium,In progress] https://launchpad.net/bugs/251242
[17:37] <apw> cjwatson, that seems most appropriate
[17:38] <apw> thanks for looking at that for me
[17:40] <pitti> cjwatson: why not copy jaunty-proposed to karmic after it built and verified?
[17:40] <pitti> (that's how I treat the majority of SRUs right now)
[17:40] <pitti> I mean, toolchain wise it's of course better to upload
[17:41] <apw> this is a diificult time i guess while we are waiting for the toolchain in karmic to settle down
[17:43] <cjwatson> apw: err, hang on, I just noticed that debian/kexec-tools.postinst sets an initial value for this
[17:43] <cjwatson> pitti: *shrug* it's done now :)
[17:44] <pitti> cjwatson: I just wondered if you generally consider it bad to copy -proposed to karmic
[17:44] <apw> cjwatson, yeah though it only does that if the file is not present and the file is present as its included in our package
[17:44] <cjwatson> apw: that said, I don't think that /etc/default/kexec will ever not exist while the postinst is running
[17:44] <cjwatson> right
[17:44] <cjwatson> pitti: not especially, but now that the archive is open I'd rather we do separate uploads so that things are built with the new toolchain
[17:44] <apw> i was assuming that that was coming from debian and not changing it would minimise a merge
[17:44] <apw> i am happy to correct that one too if its better that way
[17:44] <cjwatson> apw: I think it's OK as is, as long as people make sure to test both fresh installations and upgrades
=== rbelem is now known as rbelem-lunch
=== beuno_ is now known as beuno
[17:45] <apw> from my reading the upgrade path is to install the default file if its missing, and update the value in whatever file is there based on the odl format file
[17:46] <apw> so i believe it will do the right thing in those cases, but yes it should be tested
[17:46] <cjwatson> the whole postinst stuff is rubbish and to be ignored AFAICS
[17:46] <cjwatson> oh, hmm
[17:46] <apw> the only bit that looked like it might do something was the copy over of the old value at the end
[17:46] <apw> but that is independannt of the ensure there is a file part
[17:46] <cjwatson> no, the postinst does need to be fixed - it's an explicit policy violation and will clobber whatever's in the file with the value stored in debconf
[17:46] <apw> and that part should be a noop
[17:47] <cjwatson> I don't think it will be a no-op
[17:47] <apw> is that was already wrong or will be wrong now
[17:47] <cjwatson> in fact, its behaviour will depend on whether the package is installed with dpkg -i or with apt-get
[17:47]  * apw looks at cjwatson in horror
[17:48] <cjwatson> if dpkg -i is being used, the config script will run at postinst time, and will grab whatever value was set by dpkg's conffile handling
[17:48] <cjwatson> if apt-get is being used, the config script will run at preconfiguration, before unpacking the new package, and will thus have the effect of resetting the value that was in place beforehand
[17:48] <cjwatson> at least that's my reading, I haven't tested it
[17:49] <cjwatson> this is why policy says you MUST NOT mix dpkg conffile handling and maintainer script configuration file handling
[17:49] <apw> ok so it sounds like its plain wrong before hand.  i think you are saying we should not have a conf file at all here
[17:49] <apw> and just use the postinst script
[17:50] <cjwatson> there are two options: support configuration using debconf, or don't ship the file in the .deb
[17:50] <cjwatson> sorry, that's a misstatement
[17:50] <cjwatson> the two options are: support configuration using debconf and don't ship the file in the .deb; or ship the file in the .deb and don't support configuration using debconf
[17:51] <cjwatson> I wouldn't advocate debconf configuration for this if you were starting from scratch since it's so simple, but since it's already there that changes things a bit
=== emgent_ is now known as emgent
[17:51] <apw> so would i right in saying removing the static file totally and fixing the postinfst would achieve that?
[17:51] <cjwatson> I believe so, but test that
[17:52] <apw> cjwatson, thanks for the input... will go do that
[17:52] <cjwatson> what would you like to happen on upgrades?
[17:52] <apw> my fealing is you shouldn't change things people have selected already
[17:52] <cjwatson> my suggestion would be that on upgrade *to this version* we should override user configuration, since we can't tell whether they explicitly chose it or not and we think most people want it off
[17:52] <apw> so if they have a value we should honour it on upgrade.
[17:52] <cjwatson> but that future upgrades should not override user configuration
[17:53] <apw> and how does one tell the difference
[17:53] <cjwatson> i.e. 'if dpkg --compare-version "$2" lt 20090000-2.0.0ubuntu3.1; then db_set kexec-tools/load_kexec false; fi', probably in the config script
[17:54] <cjwatson> properly indented of course
[17:54] <apw> ok thanks ... will go play ...
[17:54] <cjwatson> sorry, --compare-versions not --compare-version
[17:54] <cjwatson> debconf-devel(7) describes the arguments passed to the .config script
[17:55] <cjwatson> the policy manual describes the arguments passed to the .postinst script
[17:55] <apw> excellent thanks
[18:01] <andre_pl> where can I find documentation on the notification system?
[18:16] <mdz> andre_pl: what kind of documentation?
[18:16] <mdz> andre_pl: https://wiki.ubuntu.com/NotifyOSD https://wiki.ubuntu.com/NotificationDevelopmentGuidelines and https://wiki.ubuntu.com/NotificationDesignGuidelines are all potentially good starting points
[18:17] <andre_pl> mdz: i'm trying to figure out why the volume controls are able to appear over top of an mplayer window, but a custom notification that I create wont appear at all
[18:19] <mdz> andre_pl: if the answer isn't there, try MacSlow
[18:19] <mdz> though he may be offline for the evening
[18:22] <andre_pl> mdz: I found it actually, set_urgency(2) does the trick, thanks
[18:27] <davidbarth> andre_pl: ping? mdz mentioned you had a notification dev. question
[18:27] <mdz> davidbarth: <andre_pl> mdz: I found it actually, set_urgency(2) does the trick, thanks
=== jdong__ is now known as jdong
[18:27] <Adri2000> mvo: got time to take a look at my bug?
[18:27] <davidbarth> andre_pl: ah, too late then; however, be sure to check the guidelines at:
[18:28] <davidbarth> andre_pl: https://wiki.ubuntu.com/NotificationDevelopmentGuidelines
[18:28] <davidbarth> andre_pl: also, you may want to join #ayatana where the team is discussing n-osd/indicators development
[18:29] <davidbarth> andre_pl: or join the ayatana mailing list at: https://launchpad.net/~ayatana
[18:29] <davidbarth> andre_pl: see you there
[18:35] <andre_pl> davidbarth: thanks!
=== jdong__ is now known as j-dizzle
=== jdong is now known as j-dizzle
[18:48] <james_w> anybody know a command to print all the users in a group?
[18:49] <elmo> getent group foo
[18:49] <elmo> ?
[18:50] <james_w> thanks elmo
[18:57] <NCommander> We're not doing a mass give-back for karmic like we did for jaunty?
[19:01] <james_w> NCommander: probably will, but the initial Debian sync is enough of a flood for now I would expect
[19:09] <devfil> cjwatson: do you know when packages will be "autosynced" from Debian?
[19:09] <NCommander> so gdb seems to be hosed on HPPA
[19:09] <NCommander> figures
[19:52] <cjwatson> devfil: seb128 was going to start that shortly
[19:52] <seb128> I'm still ;-)
[19:53] <devfil> ok, thanks :)
[19:53] <seb128> I'm just waiting in gcj-4.4 as requested by doko
[19:54] <seb128> it's built on everywhere but armel where it's building
=== fabbione is now known as fabbione-vac
[20:15] <mvo> Adri2000: what was the bugnumer again?
[20:23] <Adri2000> mvo: bug #338419
[20:23] <ubottu> Launchpad bug 338419 in filezilla "Filezilla fails to install " [Undecided,Invalid] https://launchpad.net/bugs/338419
[20:24] <mvo> Adri2000: thanks, that is indeed a app-install-data bug it seems, let me have a look where that problem comes from
[20:25] <jdong> jdstrand: wrt bug 331534, hardy is actually affected. /etc/apparmor.d/force-complain's presence will bork out apparmor-utils helpers
[20:25] <ubottu> Launchpad bug 331534 in apparmor ""force-complain" and "disable" directories breaks aa-genprof" [Undecided,Confirmed] https://launchpad.net/bugs/331534
[20:25] <jdong> I think that's worth SRU'ing; I'll prep a debdiff
[20:31] <mvo> Adri2000: thanks, I updated the bug
[20:31] <jdstrand> jdong: that is cool. what I was trying to say in the bug was that 'disable' didn't cause a problem in hardy, not that 'force-complain' did not. in other words, hardy is affected by the presence of 'force-complain' and intrepid is by both 'force-complain' and 'disable'
[20:32] <jdong> jdstrand: ah, understood. I thought you might have overlooked that Hardy was affected by force-complain
[20:32] <jdong> I stuck a quick debdiff against the latest hardy package if that helps quicken the SRU process
[20:33] <jdong> oddly within the past week I had two different people whine about this one, so either the apparmor moons are aligning or I'm hanging out with hypochondriacs ;-)
[20:34] <jdstrand> somehow that slipped by... :/
[20:34] <jdstrand> I'll get the SRUs going for them
[20:34] <jdong> thanks, no worries :)
[20:35] <Adri2000> mvo: ok
[20:35] <Snova> What is an SRU?
[20:36] <jdong> !sru
[20:36] <ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[20:36] <Snova> Ah.
[20:37] <Snova> So, basically any updates I get from a stable release (I think backports don't count).
[20:37] <jdong> Snova: correct, for the -updates repository
=== yofel__ is now known as yofel
=== savvas_ is now known as savvas
=== jorge_ is now known as jcastro
=== seb128_ is now known as seb128
=== beuno_ is now known as beuno
[22:16] <EtienneG> hey guys
[22:17] <EtienneG> I am troubleshooting a bug in the netboot installer, and wants to get the syslog and partman log for a bug report
[22:17] <EtienneG> any suggestion as to how to get them *out* of the system I am installing?
[22:17] <EtienneG> there must be a way, but I am baffled
[22:58] <mathiaz> EtienneG: you can try to scp the files
[22:58] <EtienneG> mathiaz, yes,, but there is no scp executable in the d-i shell
[22:58] <mathiaz> EtienneG: from a console, anna-install openssh-client-udeb (IIRC) and then you can scp them
[22:58] <EtienneG> mathiaz, ha HA!
[22:58] <EtienneG> thanks a lot
=== rbelem-lunch is now known as rbelem
[23:03] <bigon> mmm I've just seen that in pbuilder python install modules inside site-package by default now
[23:03] <bigon> right?
[23:05] <geser> bigon: how were the modules installed during the build?
[23:18] <cjwatson> EtienneG: or you could go back to the installer main menu and select "save debug logs"
[23:19] <EtienneG> cjwatson, interesting, I did not knew about that option
[23:19] <EtienneG> cjwatson, as you are around, I have a quick one
[23:20] <EtienneG> in a partman-auto/expert_recipe, can you flag more than one partition with $primary{ } ?
[23:21] <cjwatson> EtienneG: yes
[23:21] <EtienneG> cjwatson, somehow, it does not work for me
[23:21] <EtienneG> cjwatson, I will do a bit more test and report a bug if I cannot get it to work
[23:22] <cjwatson> please do
[23:22] <cjwatson> I can probably diagnose it easily given the logs
[23:22] <cjwatson> there are of course the usual constraints on primary partitions
[23:23] <EtienneG> cjwatson, which log would you need?  partman and syslog?
[23:23] <cjwatson> error handling might not be very good if you inadvertently violate them
[23:23] <cjwatson> EtienneG: yes. installer bugs almost never need anything else
[23:23] <EtienneG> cjwatson, by constraints, you mean the limit of four?
[23:23] <bigon> geser: the module was installed in site-package directory (so the pkg doesn't FTBFS) but python doesn't find the module at runtime
[23:24] <cjwatson> and the fact that you can't put logical partitions between primary partitions
[23:24] <cjwatson> and the fact that if you have any logical partitions the limit is three not four
[23:24] <EtienneG> cjwatson, yes, of course
[23:24] <EtienneG> got that
[23:24] <cjwatson> and quite possibly others I've forgotten :)
[23:24] <EtienneG> actually, I am trying with only two partition, both primary
[23:24]  * cjwatson is not the DOS partition table format's biggest fan
[23:25] <EtienneG> ha, legacy!
[23:26] <EtienneG> although we are not really bound to it
[23:26] <cjwatson> I might have screwed up the code in partman-auto for $primary{ }, obviously. I only really implemented it in order to cope with BIOSes that throw their toys out of the pram if there isn't at least one primary partition
[23:28] <cjwatson> though nowadays partman-auto is smart enough to ensure that there's at least one primary partition without the help of $primary{ }
[23:38] <Pollywog> I cannot find sane-backends-extras
[23:38] <Pollywog> anyone know where I can get it?
[23:40] <dtchen> Pollywog: the source package (which you've named) is in universe. did you install libsane-extras?
[23:49] <Kangarooo> Hello! I have noticed one thing.. I put ubuntu on one pc and xubuntu on laptop and when really overloaded and start to slow down.. looks strange.. sometimes window looses some graphic.. but I thought why windows has been looking ok even thou programms not so good and more buggy.. and I think that windows before shows anything it loads it completely programms graphic and when loaded grapfic things.. then it show all. .. ubuntu is not doing that.. 
[23:50] <Kangarooo> if programm is showing only when all graphic is laoded then it gives feeling that programm is running great and smooth :)