[12:17] <mjg59> cjwatson: Yeah. I've no idea what's up.
[12:17] <mjg59> BenC: Hi - here for a second
[12:17] <BenC> mjg59: see st3's comments...seems the dscape bcm43xx is just plain broken and old
[12:19] <BenC> ogra says current kernels don't work for him either
[12:29] <mjg59> BenC: It's current as of last week.
[12:31] <mjg59> I think it's due to some miscommunicaiton on the bcm43xx mailing list
[12:34] <st3> BenC, mjg59, mb_ is the maintainer for bcm43xx-d80211, if you want any clarification about that
[12:36] <BenC> st3, mb_: So which driver is the best to use?
[12:37] <BenC> I don't want to get into a dscape vs. softmac debate, I just want to know which one will best support our users
[12:37] <mb_> kernel.org -stable tree is always best. So currently 2.6.20, as there is no -stable released, yet
[12:37] <mjg59> I've replied to the bug
[12:37] <BenC> so we should stick with bcm43xx+softmac in stock 2.6.20?
[12:37] <mb_> bcm43xx-d80211 is currently broken and doesn't work on all devices where bcm43xx-softmac des
[12:37] <mb_> does
[12:38] <mb_> Yes, please BenC
[12:38] <mjg59> Well, no
[12:38] <BenC> mb_: Thanks...that's the route we'll take then
[12:38] <mb_> Thanks
[12:38] <BenC> mjg59: Why not?
[12:38] <mb_> Saves us a lot of headache ;)
[12:38] <mjg59> stock 2.6.20 doesn't work usefully on 4611 and 4612
[12:38] <mjg59> Whereas there's code that does do that
[12:38] <st3> 4311 and 4312?
[12:39] <mjg59> Sorry,y es
[12:39] <st3> you might use patches from larry finger
[12:39] <mb_> ftp://lwfinger.dynalias.org/patches
[12:39] <mjg59> So at the very least, it's likely to be something closer to wireless-2.6 or whatever Larry's providing
[12:39] <st3> ftp://lwfinger.dynalias.org/patches
[12:39] <mb_> You might want to apply these
[12:39] <st3> oops
[12:39] <mjg59> But right now, we want to get a better understanding of what the state of d80211 is so that the transition can be made at the appropriate time
[12:40] <BenC> I'm willing to transition when stock kernel does
[12:40] <mjg59> Well, we'll be including d80211 anyway for the sake of iwlwifi
[12:40] <mb_> mjg59: ok, but please don't let your users run it with bcm43xx. It's a regression :)
[12:40] <BenC> when userspace catches up, and when more drivers are using it
[12:40] <st3> what we don't understand is, what version of -d80211 did you put in the kernel?
[12:41] <mjg59> st3: A fresh pull from wireless-dev last week, along with Michael's current tree
[12:41] <mb_> But that's d80211 only?!
[12:41] <mb_> The bcm43xx-d80211 driver is damn old
[12:41] <mb_> in your tree
[12:41] <BenC> st3: Do you have a suggested list of patches from that ftp?
[12:42] <mjg59> mb_: Right, I get confused here. I pulled from your tree on Saturday.
[12:42] <mjg59> mb_: git-log has the 4311 and 4312 fixes in it
[12:42] <st3> BenC, ftp://lwfinger.dynalias.org/patches/patch_2.6.20_for_DMA_over_1GB
[12:42] <st3> this one
[12:42] <st3> plus
[12:42] <mb_> I think 2.6.20-combined only, BenC. But best contach Larry before pulling it in.
[12:42] <mjg59> mb_: And the patches I sent you were based off that tree
[12:42] <st3> mb_, do you know if larry released that patch for 4311 and 4312?
[12:43] <mjg59> mb_: Can I just check which code you're looking at?
[12:43] <st3> yes BenC, please contact larry.
[12:43] <mb_> mjg59: patches you sent me?
[12:43] <mjg59> mb_: Oh, I may only have sent you an SSB one in the end
[12:44] <mjg59> mb_: To fix the parent field in the devices
[12:44] <BenC> it seems that radio and 1G are the only two, from the README
[12:44] <mb_> Ah, yes. That one mjg59
[12:44] <mjg59> BenC: Wait. Did you apply the patch I sent you months ago?
[12:44] <st3> "iwlist fixes, and resume fix" too
[12:44] <st3> resume fix isn't actually working, iirc
[12:44] <mjg59> BenC: If so, yes, that's very ancient and would explain a great deal
[12:45] <mjg59> BenC: You should certainly drop that - I pushed Kyle some more code last week, so I assumed that it was that stuff
[12:45] <mjg59> mb_: Sorry, I think I've figured out what's going on now - some internal miscommunication :)
[12:45] <mb_> :)
[12:45] <mjg59> mb_: You're right, that code's ancient. I'll get that fixed ASAP
[12:46] <mjg59> BenC: Did you get those last few bits?
[12:46] <BenC> sorry, I missed the last comments
[12:46] <mb_> I was damn surprised to see it being included in a distro now, as I dropped it months back :)
[12:46] <mjg59> BenC: Did you apply the dscape patch I sent you months ago?
[12:46] <BenC> that's the only one I had
[12:47] <mjg59> BenC: Ah. Yeah, drop that. It's ancient.
[12:47] <mjg59> BenC: I pushed some stuff to Kyle, so I'd assumed that that was what got in
[12:47] <kylem> still reviwing it.
[12:47] <BenC> if you have a newer dscape, I can put that in
[12:47] <mjg59> BenC: So we're definitely not getting the driver-selection stuff?
[12:47] <BenC> I think for bcm43xx, I want to revert to the stock one, and apply any needed patches to get stuff we want out of it
[12:48] <BenC> driver-selection?
[12:48] <mjg59> Supply multiple drivers, let the user choose which is used
[12:48] <BenC> you mean the driver-device-manager stuff?
[12:49] <BenC> Keybuk never got a chance to do the udev bits for it
[12:49] <BenC> so it got defered
[12:49] <BenC> so we're stuck with one-driver-per-device for feisty still :)
[12:51] <mjg59> Ok
[12:52] <mjg59> Hm. We could provide bcm43xx-d80211 without any modalias :)
[12:53] <BenC> could comment out MODULE_DEV_TABLE()
[12:53] <mjg59> Yeah
[12:54] <BenC> kylem: If you can't get the time to do dscape, can you just punt me those patches and I'll merge?
[12:54] <kylem> sure.
[12:54] <BenC> maybe they'll fix rt2x00 build with it aswell
[12:54] <kylem> eating dinner now tho. :)
[12:54] <BenC> kylem: Bear meat?
[12:54] <kylem> haha. no.
[12:54] <kylem> moose.
[12:55] <BenC> my mom gets a lot of bear meat...pretty damn good stuff
[12:55] <BenC> much better than black anus
[12:55] <kylem> i... wouldn't know...
[12:56] <BenC> mb_, st3: Thanks for your input...hopefully we'll get this sorted out soon so our users stop bugging you :)
[12:56] <mb_> :)
[01:00] <st3> =)
[01:01] <BenC> st3: And don't hesitate to send me any patches you think I might be interested in
[01:01] <st3> well, ok, i'll tell larry too
[01:02] <BenC> thanks
[01:02] <st3> np
[01:04] <st3> anyway, we work in order to get the stable software in mainline, so please watch -stable, too
[01:04] <mjg59> We generally pull from stable
[01:04] <mjg59> So yeah, that shouldn't be a problem :)
[01:05] <mjg59> Anyway, bed now.
[01:31] <Tonio_> imbrandon: ping ?
[01:32] <imbrandon> pong
[01:32] <imbrandon> Tonio_,
[02:08] <xstasi> hi
[02:10] <xiq> is it possible to get the actual scripts (etc) which are used to build the release livecd?
[02:29] <poningru_> so quick question re: the zalewski vuln, the upstream branch & trunk just got the patch in
[02:29] <poningru_> err in firefox
[02:30] <poningru_> I was wondering if anyone was working on getting the patch into our firefox
[02:31] <poningru_> https://bugzilla.mozilla.org/attachment.cgi?id=255252
[02:31] <poningru_> so...
[03:11] <xiq> is it possible to get the actual scripts (etc) which are used to build the release livecd? (not a customisation script, but whatever is used to make the real livecd in the first place)?
[03:12] <Hobbsee> xiq: the fact that you didnt get an answer the first time, and the fact that hardly anyone is talking *probably*  means that they're all asleep
[03:13] <xiq> then they won't mind me asking a second time... unless they all have tts systems running to keep the memory of wargames alive and well...
[03:19] <sistpoty> xiq: iirc this question was raised on the ubuntu-devel mailing list a few times... maybe you can find an answer there (e.g. google site:lists.ubuntu.com livecd)
[03:55] <fabbione> morning
[03:58] <xiq> sistpoty: thanks, i'll look through it..
[04:39] <alex-weej> is the "importance" field only for bug triagers on LP?
[04:39] <alex-weej> or can it be set by reporters too, somehow (i know i know)
[04:52] <Hobbsee> alex-weej: for those in ubuntu-qa.
[04:52] <Hobbsee> alex-weej: effectively the triagers
[04:52] <alex-weej> ok
[05:23] <Amaranth> alex-weej: reporters would mark all of their bugs as critical :P
[05:24] <alex-weej> irresponsible :P
[05:27] <jdong> Amaranth: people like that need a good serving of the devil's bug 666
[05:27] <Ubugtu> Malone bug 666 in malone "can't file a bug on Ubuntu" [Medium,Rejected]  https://launchpad.net/bugs/666
[08:11] <pitti> Good morning
[08:14] <LaserJock> hi pitti
[08:21] <ajmitch> morning pitti
[08:21] <pitti> hey ajmitch
[08:25] <Burgundavia> pitti: thanks for doing that cupsys dapper bug
[08:25] <Burgundavia> pitti: I need to fully test it, but I think that might be the fix
[08:25] <pitti> Burgundavia: you're welcome, sorry for the delay
[08:26] <Burgundavia> no worries
[08:26] <Burgundavia> it means the final FC4 machine in my office can now bite it
[08:37] <pitti> siretart: ping
[08:37] <siretart> pitti: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
[08:37] <pitti> heh
[08:38] <pitti> siretart: I'm just reviewing the ffmpeg MIR -- doesn't xine-lib contain a static code copy anyway?
[08:38] <Amaranth> I thought we didn't want a million copies of it
[08:38] <pitti> Amaranth: right, that's the idea
[08:39] <fabbione> siretart: ICMP_ECHO_REQUEST
[08:39] <pitti> Rationale:
[08:39] <pitti>     *
[08:39] <pitti>       Build dependency of xine-lib
[08:39] <fabbione> siretart: your script is owned
[08:41] <qiyong> is ubuntu alwasy depends on debian?
[08:42] <qiyong> and how to upgrade to the newest ubuntu?
[08:42] <pitti> qiyong: please see topic; please ask in #ubuntu
[08:42] <qiyong> pitti, no one knows there seems
[08:43] <qiyong> pitti, and i'm trying to get into the latest ubuntu for development purpose
[08:43] <Amaranth> qiyong: you waited 3 minutes
[08:43] <qiyong> Amaranth, waited hours already
[08:44] <qiyong> i think i should run a newest ubuntu in order to develop it, like debian sid
[08:44] <pitti> qiyong: sudo update-manager -d should do
[08:45] <qiyong> pitti, and that can bring me into the newest? (i'm in 6.06 LTS)
[08:46] <Chipzz> qiyong: the fact that no-one in #ubuntu knows/answers still doesn't make this the right place to ask
[08:46] <siretart> pitti: yes, xine does contain a snapshot of ffmpeg
[08:46] <pitti> siretart: I just checked; that makes it a snap :)
[08:46] <siretart> pitti: :)
[08:46] <pitti> siretart: new x-l will b-dep on ffmpeg then
[08:47] <siretart> pitti: no, I can't directly, the ffmpeg package is outdated, I need to package a new upstream version first, and get UVF approval for that
[08:47] <Chipzz> pitti: http://blogs.gnome.org/view/uraeus/2007/02/15/0
[08:47] <qiyong> Chipzz, i want to begin my ubuntu devel life
[08:47] <siretart> pitti: first I needed to have ffmpeg in main, after that, I can think about upgrading the package :)
[08:47] <pitti> siretart: that sounds fine; if it brings the code in sync with the version xine-lib has
[08:47] <pitti> siretart: oh, why not the other way round?
[08:48] <siretart> pitti: because this breaks other packages build depending on ffmpeg, which I didn't want to needlesly break. I had concerns that the ffmpeg package makes it into main at all
[08:48] <LaserJock> qiyong: in a short time Feisty Herd 4 will be released, installing and testing that would be a great way to get started
[08:49] <pitti> siretart: I see
[08:49] <qiyong> LaserJock, i don't like a fresh reinstall, i'd like some upgrade
[08:49] <Burgundavia_> pitti: basically the ffmpeg developers have no idea bout api/abi stability
[08:49] <qiyong> LaserJock, i don't like install from new CD
[08:49] <Burgundavia_> nor do they understand the word "release"
[08:50] <pitti> Burgundavia_: I know :/
[08:50] <Chipzz> qiyong: if you really want to start developing for ubuntu, a first good step would be to learn how to figure out stuff on your own; ie learn how to use google, how to read docs etc...
[08:51] <siretart> pitti: the other thing is, that even in debian there isn't a new ffmpeg version, so I have to package it myself.
[08:51] <LaserJock> qiyong: that's a pity, testing fresh installs is important
[08:51] <LaserJock> qiyong: what you do is upgrade to 6.10 and then upgrade to 7.04
[08:51] <Chipzz> qiyong: like LaserJock said; direct upgrades from LTS to feisty (7.04) are not supported
[08:52] <qiyong> LaserJock, by update-manager? or by a new CD?
[08:52] <pitti> siretart: oh, this also requires a libdts MIR
[08:52] <qiyong> Chipzz, how about 6.04 to 6.10?
[08:53] <Chipzz> you mean 6.06
[08:53] <LaserJock> qiyong: either way will work
[08:53] <qiyong> Chipzz, yeah
[08:54] <Chipzz> and yes, both 6.06 -> 6.10 and 6.10 -> 7.04 are supported; 6.06 -> 7.04 is not
[08:54] <siretart> pitti: well, ffmpeg includes an own copy of libdts and a52. I'd suggest that we promote them as well, but that's not strictly necessary
[08:54] <pitti> siretart: oh, I see; well, let's not bother now
[08:54] <ajmitch> siretart: ffmpeg sounds like a scary mess
[08:55] <Chipzz> siretart: did you read http://blogs.gnome.org/view/uraeus/2007/02/15/0 ?
[08:55] <siretart> ajmitch: it is. nevertheless, xine is pretty useless without it
[08:55] <Chipzz> siretart: that's the gstreamer developer; but I'm sure similar views are held by the xine camp
[08:55] <Chipzz> s/the/a/
[08:56] <siretart> Chipzz: I didn't read the blog entry before, but I know the problems with that
[08:57] <Chipzz> while I think having a seperate ffmpeg package is a laudable goal, I'm not really sure how practical it is while the ffmpeg api is still unstable?
[08:58] <tfheen> http://err.no/tmp/herd-4 ; critisisms welcome.
[08:59] <tfheen> cjwatson: ^^ ; I left in a reference that the new partitioner UI is not there yet, is that ok?
[08:59] <fabbione> Edubuntu:
[08:59] <fabbione>   http://cdimage.ubuntu.com/edubuntu/releases/feisty/herd-3/
[08:59] <fabbione> tfheen: ^^
[08:59] <tfheen> fabbione: the URLs need to be fixed; known; thanks.
[09:00] <fabbione> ok
[09:00] <tfheen> edubuntu fixed, I still need to add some more URLs there.
[09:00] <fabbione> tfheen: looks ok otherwise
[09:02] <pitti> siretart: I added my approval stamp
[09:03] <pitti> siretart: ok, the package will actually be promoted when something in main b-deps on it; thus, whenever you upload an updated xine-lib with the b-dep, ping me or another archive dude, and we'll promote immediately
[09:03] <pitti> siretart: does that work for you?
[09:04] <fabbione> who does approve UVF exceptions now?
[09:05] <pitti> fabbione: tfheen?
[09:05] <fabbione> pitti: ok thanks
[09:06] <Burgundavia_> is mdz stepping back to handle bigger issues now?
[09:07] <pitti> Burgundavia_: mdz doesn't scale as well as the number and size of tasks :)
[09:07] <pitti> Burgundavia_: we tried hard to clone him, but the clone just played the guitar all day long
[09:08] <pitti> (although that was really beautiful :) )
[09:08] <tfheen> fabbione: the release team, as it has always been.
[09:09] <Burgundavia_> pitti: indeed. Clearly we need human cloning :)
[09:09] <fabbione> tfheen: ok.. i just got confused with archive admin changes
[09:09] <fabbione> tfheen: there was too much overlap before :)
[09:10] <tfheen> true, those often end up overlapping quite a bit
[09:12] <fabbione> tfheen: anyway... while waiting for kernel and userland to build.. i would like a UVF exception for redhat-cluster-suite. I need to sync CVS code for gfs-kernel to build and work with 2.6.20 and a bunch of bug fixes in fence agents (like yay.. autoconf for manual fencing)
[09:12] <fabbione> tfheen: note the package has always been on CVS snapshots
[09:16] <giftnudel> good morning all (or whatever the equivalent in your timezone is)
[09:18] <tfheen> fabbione: debdiff?
[09:18] <fabbione> tfheen: sure.. it's quite big tho... removed local patches that are now upstream and stuff like that too...
[09:20] <tfheen> fabbione: as long as that's documented in the changelog, that's fine.
[09:20] <tfheen> fabbione: and it being big is a point against it, not in favour. :-P
[09:20] <fabbione> tfheen: hehe
[09:25] <fabbione> tfheen: http://people.ubuntu.com/~fabbione/rh.debdiff
[09:25] <fabbione> tfheen: i didn't document the test suite changes because we don't ship it.
[09:29] <tfheen> fabbione: ugh, it is quite big, yes.
[09:29] <fabbione> tfheen: yes i know and I know it's safe tho.. the hard part is to convice you about it :)
[09:31] <tfheen> fabbione: approved; In the future, I'd like some bug references too, but we're early in the UVF period so that's fine.
[09:31] <fabbione> tfheen: i usually reference to their bugzilla during development.. if you want i can go grab a few
[09:32] <tfheen> fabbione: no, that's fine.
[09:32] <fabbione> ok thanks
[09:32] <fabbione> like my cluster hanging in less than 4 seconds :)))
[09:32] <fabbione> it took them about.. hmmm 4 months to fix it
[09:35] <pitti> asac: do you see any reason to keep mozilla (1.7.x) and all its plugins/locale packages in universe? geser and I would like to remove it since it's obsolete, vulnerable, and unmaintained; if we don't remove it, someone needs to update those packages to SeaMonkey, do you think that's worth pursuing?
[09:38] <tepsipakki> tfheen: would you mind syncing nfs-utils from debian experimental? It's a newer upstream snapshot, also it has a patch which makes root-access work when kerberos is in use
[09:39] <tepsipakki> bug #83435
[09:39] <Ubugtu> Malone bug 83435 in nfs-utils "please sync nfs-utils (main) from Debian experimental" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83435
[09:39] <Burgundavia_> tepsipakki: how is the xorg work coming?
[09:39] <tepsipakki> Burgundavia_: all is well ;)
[09:40] <tfheen> tepsipakki: I'll take a look at it.  Sesse told me about it a couple of days ago.
[09:40] <tepsipakki> and 7.2 was officially released yesterday
[09:40] <tepsipakki> tfheen: cool
[09:41] <cjwatson> tfheen: yeah, that's ok
[10:21] <pitti> hey seb128
[10:22] <seb128> morning pitti
[10:24] <ajmitch> hi seb128
[10:24] <seb128> Hi ajmitch
[10:25] <seb128> pitti: I can do a syncs round if you want, I didn't really do admin work on wednesday due to the freeze
[10:26] <ogra> according to the topic its still in effect
[10:26] <pitti> seb128: I'll do my archive day today, but go ahead if you want to do syncs; there's enough work left :)
[10:26] <pitti> oh, no freeze any more
[10:26] <seb128> pitti: ok, doing syncs now
[10:26] <ogra> thanks :)
[10:26] <seb128> ogra: from the -changes list there is no freeze :p
[10:26] <ogra> hehe
[10:35] <giftnudel> hehe
[10:39] <cjwatson> seb128_: if you're doing syncs, could you pop into #ubuntu-x?
[10:49] <pitti> mvo, ogra, seb128: I updated https://wiki.ubuntu.com/IncreaseHardwareDatabaseParticipation according to yesterday's discussion and discussion with mvo about the u-n details; I'd appreciate a short peer review
[10:49] <pitti> seb128: NB that I dropped the 'will restore its menu item' sentence ;)
[10:49] <seb128> ;)
[10:49] <seb128> looking
[10:50] <pitti> seb128: the notification will just point out where it can be found, and offer a button to start it right away
[10:50] <pitti> so we get the 'easy to find and do' for the first time, and avoid cluttering
[10:50] <ogra> We will a post-installation update-notifier notification...
[10:50] <ogra> We will add ?
[10:50] <pitti> erm, yes, thanks
[10:51] <pitti> this sentence no verb...
[10:51] <ogra> :)
[10:51] <mvo> pitti: I would like to renamed the field to "GettextDomain"
[10:51] <pitti> ogra: that wasn't even my sencente :)
[10:51] <mvo> (details..)
[10:51] <pitti> mvo: done
[10:51] <mvo> thanks
[10:51] <pitti> fixed both and saved
[10:52] <ogra> looks fine
[10:53] <pitti> thanks for the review
[10:58] <ogra> seb128, ah, there is a proper gnome-screensaver -> gdm_socket fix :)
[10:58] <seb128> ogra: ah?
[10:59] <seb128> ogra: where?
[10:59] <ogra> http://svn.gnome.org/viewcvs/gnome-screensaver/trunk/src/cut-n-paste/gdm-queue.c?rev=1078&r1=1095&r2=1078
[11:00] <seb128> ogra: what happens if it doesn't find the socket then?
[11:03] <ogra> seb128, what does VE_IGNORE_EINTR do ?
[11:03] <seb128> dunno
[11:03] <seb128> I need to look at that
[11:04] <ogra> http://bugzilla.gnome.org/show_bug.cgi?id=407524
[11:04] <Ubugtu> Gnome bug 407524 in daemon "Freeze on unlock screen" [Normal,Resolved: fixed]
[11:06] <pitti> ogra: can you please commit/push your recent hwdb-client changes into bzr?
[11:07] <ogra> pitti, who holds the upstream branch  ?
[11:08] <ogra> mine is totally outdated
[11:08] <pitti> ogra: I used sftp://bazaar.launchpad.net/%7Eubuntu-core-dev/hwdb-client/trunk/
[11:08] <ogra> ok
[11:08] <pitti> ogra: but that has ubuntu21, but feisty has ubuntu23
[11:08] <pitti> with these two uploads from you
[11:08] <pitti> s/from/being from/
[11:08] <ogra> yep, i'll push my stuff
[11:08] <pitti> ogra: thanks
[11:09] <pitti> ogra: btw, shouldn't this get a native version number?
[11:09] <pitti> ogra: 0.6.1 perhaps?
[11:09] <ogra> pitti, yes
[11:09] <pitti> or is there an upstream branch somewhere?
[11:10] <ogra> nope
[11:11] <ogra> pitti, i forwarded you a hal patch i just got ...
[11:13] <pitti> seb128: hm, I wonder where the hal-device-manager entry is nowadays? I can't find it in c-c
[11:13] <pitti> seb128: but I need it to refer to it in the hwdb first-time notification
[11:13] <seb128> pitti: I need to fix that, it's to app, system tools atm
[11:14] <pitti> seb128: hm, not for me
[11:14] <ogra> seb128, hal device manager itself is gone
[11:14] <seb128> pitti: ups, right, I mixer with hdwb-client, it's not listed by the shell because the desktop is installed to /usr/share/control-center-2.0/capplets and not /usr/share/applications
[11:15] <pitti> seb128: just to avoid confusion: we *do* want an icon for h-d-m in control-center, and we *don't* want any icon/menu entry for hwdb-client, right?
[11:15] <seb128> pitti: correct
[11:15] <gpocentek> tfheen: hello! could you publish yesterday xubuntu isos as Herd 4? They are OK for me (I couldn't test powerpc though)
[11:15] <pitti> seb128: ah, nice, I'll fix the path
[11:15] <seb128> ok, thank you
[11:15] <pitti> seb128: I have some pending hal fixes in bzr head that I'd like to release now anyway
[11:15] <pitti> seb128: and that will drop a patch :)
[11:15] <seb128> thank you
[11:17] <pitti> seb128: ugh, could you please commit your recent hal upload to bzr or just send me a debdiff?
[11:17] <seb128> what hal upload?
[11:18] <seb128> I did one during the distro sprint
[11:18] <pitti> seb128: oh, sorry, that was ogra's
[11:18] <seb128> and pushed the changes to bzr
[11:18] <seb128> ok, np ;)
[11:18] <pitti> ogra: ^ you then :)
[11:18] <shawarma> /win/win 2
[11:18] <pitti> ogra: please merge with the 4ubuntu6 UNRELEASED changes in bzr head, shouldn't give any conflicts
[11:18] <shawarma> Doh..
[11:20] <tfheen> gpocentek: ok, thanks.  Will do.
[11:23] <pitti> ogra: nevermind, I still have hal_<IP_ADDRESS>-4ubuntu5.diff.gz on my disk, I'll do the hal merge
[11:36] <pitti> seb128: ah, moving .desktop helps, I uploaded the new hal
[11:37] <tepsipakki> so I guess it won't be a problem, if the queue isn't that long
[11:40] <ogra> pitti, why wasnt that moved ? i didnt touch anything ... wrt .desktop
[11:40] <mitsuhiko> moin
[11:41] <pitti> ogra: I meant, you forgot to commit the hal -4ubuntu6 upload to bzr; I did that now
[11:41] <mitsuhiko> is there a sane explanation why such a package exists: http://packages.ubuntu.com/edgy/libdevel/libopenexr-dev ?
[11:41] <pitti> ogra: I just need your two hwdb-client uploads in bzr, since I work on it right now
[11:41] <tfheen> mitsuhiko: what are you asking about?
[11:41] <mitsuhiko> both the edgy and feisty version is in main but not installable because the dependencies are not in the repository
[11:42] <mitsuhiko> xlibmeso-glu-dev is not part of any ubuntu repository.... but a dependency of that package
[11:42] <ogra> pitti, i'm on it ...
[11:42] <tfheen> mitsuhiko: libglu1-mesa-dev provides libglu-dev
[11:44] <cjwatson> seems to be installable just fine if you use apt rather than grovelling around in packages.ubuntu.com by hand
[11:44] <mitsuhiko> tfheen: why is apt-get/synaptic unable to install libglu1-mesa-dev in it's own then when i try to install libopenexr-dev?
[11:45] <cjwatson> ah, of course I had libglu1-mesa-dev installed in advance
[11:45] <cjwatson> somebody should update those dependencies so that the preferred ones are correct for Ubuntu
[11:45] <mitsuhiko> tfheen: anyway. thanks for the help
[11:45] <cjwatson> in fact I'll just do that now
[11:45] <tfheen> mitsuhiko: seems to be installable just fine here, and I don't have libglu1-mesa-dev installed.
[11:46] <cjwatson> mitsuhiko: if your apt cache is already inconsistent, then apt will be significantly less clever; try apt-get -f install first
[11:47] <mitsuhiko> cjwatson: i must admit that something is screwed up here. after compiling a recent p2yk (python3000) pycentral does not work any more :-/
[11:47] <ogra> pitti, done
[11:48] <mitsuhiko> that new python-support stuff in debian is a bit strange :(
[11:49] <pitti> ogra: danke
[11:53] <Chapay> hello from russia !!!
[11:54] <pitti> Chapay:  !
[11:54] <Chapay> pitti:   :)    !?
[11:55] <pitti> Chapay: I'm afraid my Russian ends there :/
[11:55] <jwendell> wow... russian class? :)
[11:55] <cjwatson> mitsuhiko: openexr fixed in feisty, once it builds
[11:56] <pitti> Chapay:   -    :-*
[11:56] <jwendell> pitti, yesterday i made my first ubuntu patch with cdbs, thanks to your class!
[11:57] <Chapay> pitti: , where are you from !?
[11:57] <pitti> Chapay: Germany
[11:57] <pitti> jwendell: great! any questions left?
[11:57] <jwendell> pitti, just one:
[11:57] <pitti> Chapay: anyway, off-topic here :)
[11:58] <Chapay> pitti: ^)
[11:58] <Chapay> :)
[11:58] <jwendell> pitti, i do an apt-get source package; cd package; cdbs-edit-patch 01_trivial.patch
[11:59] <jwendell> pitti, is there a pratical way to test my patch?
[11:59] <pitti> jwendell: sure, build the package and install the .debs :)
[11:59] <Chapay> where i can dowload ubuntu installer source !?
[11:59] <jwendell> pitti, actually i've made a copy of that directory and compiled it separately
[12:00] <pitti> jwendell: sudo apt-get build-dep <sourcepackagename>; debuild -us -uc
[12:01] <Chapay> :(
[12:02] <pitti> Chapay: apt-get source ubiquity
[12:02] <jwendell> pitti, i'm asking this because that hole process (generate and install .deb) can take many time, so, if i did something wrong in my patch, i have to do all that proccess again
[12:02] <Chapay> pitti: i`am not have inux on my work :( i need url
[12:03] <pitti> jwendell: if you can run the program from the build tree, just do 'debian/rules build' once, and then just do 'make'
[12:03] <pitti> jwendell: that *usually* works
[12:03] <jwendell> pitti, hmmm, cool
[12:03] <tfheen> or use ccache
[12:05] <jwendell> tfheen, excuse me? what is ccache?
[12:06] <seb128> jwendell: apt-cache show ccache
[12:06] <thom> jwendell: apt-cache show ccache
[12:06] <seb128> hi thom ;)
[12:06] <thom> hey ;-)
[12:06] <tfheen> the best development tool since coffee.
[12:06] <tfheen> or editors.
[12:06] <tfheen> or compilers.   Where i can get ub untu installer source !?
[12:13] <pitti> Chapay: http://archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/ubiquity_1.3.21.tar.gz
[12:13] <cjwatson> Chapay: http://wiki.ubuntu.com/InstallerDevelopment (and stop using panicked!!! punctuation!!! please)
[12:13] <Chapay> cjwatson: sorry ^)
[12:13] <Chapay> cjwatson: sorry :)
[12:13] <Chapay> pitti:  :)
[12:18] <asac> pitti: right .... actually no ... we have to remove mozilla if we don't upgrade it to seamonkey/iceape.
[12:19] <pitti> asac: yup; I meant, do you agree to just getting rid of it?
[12:19] <Keybuk> iceowanttokillwhoeverthoughtofthesesillynames
[12:20] <asac> pitti: if it just needs a word to drop it ... i would say so.
[12:21] <pitti> asac: ok, I'll do so this afternoon when I'll do archive stuff
[12:22] <asac> Keybuk: actually, i was involved :)
[12:22] <Keybuk> asac: did you do the humping weasel as well? :P
[12:23] <asac> hey ... we needed something ;)
[12:26] <pitti> Keybuk: :)
[12:27] <pitti> Keybuk: and YourSQL?
[12:28] <asac> i talked quite extensively with upstream about our options about not renaming them ... we had ZERO options ... so don't blame debian
[12:29] <pitti> Mithrandir is back!
[12:29] <Mithrandir> pitti: indeed.
[12:29] <Keybuk> asac: but no other distribution has had to rename them ...
[12:30] <ogra_> oh, incognito is over :)
[12:30] <Keybuk> what makes Debian so special?
[12:30] <Keybuk> (stop sniggering at the back, there)
[12:32] <asac> Keybuk: don't know why others ship it ... I guess they have a less tight policy on what can be shipped. For debian, firefox logos are non-free (in terms of copyright) atm.
[12:33] <Keybuk> asac: almost every graphic and font in Debian is also non-free
[12:33] <Keybuk> yet they turn a blind eye to those
[12:33] <cjwatson> is it really necessary to have this discussion YET AGAIN?
[12:33] <asac> hehe
[12:34] <asac> i don't want it :)
[01:38] <pochu> BenC: ping?
[01:42] <pochu> BenC: do you remember my wireless problem?  I had pressed the wireless button (I have an acer) so the wireless didn't work (even in edgy). But now everything is fine. Thanks anyway!!
[01:51] <Mez> keescook, ping (rar etc etc)
[01:57] <jdong> pochu: ben's probably thinking to himself 'man if all problems were this easy....'
[01:58] <Mez> jdong: BenC is probably thinking "mmmm sleep"
[01:58] <Mez> :P
[01:58] <jdong> BenC: 's probably thinking why we're pinging him so much
[01:59] <Mez> jdong: lol
[01:59] <jdong> but I love you BenC, and thanks in advance for merging reiser4 later today!
[01:59] <jdong> LOL
[02:00] <Hobbsee> mvo_: see #launchpad
[02:01] <Fujitsu> Hobbsee: DB vacuuming, another 5 or 10 minutes.
[02:01] <Fujitsu> Oops, mvo_.
[02:01] <mvo_> Hobbsee, Fujitsu: thanks
[02:02] <Hobbsee> :)
[02:02] <jdong> mvo_: not gonna set up a nice for loop hammering launchpad till it comes back up?  Hence morning.
[02:13] <Mez> jdong, it's popey and I's game of IRC tag
[02:13] <jdong> lol
[02:20] <imbrandon> jono, ping
[02:21] <jono> imbrandon: pong!
[02:21] <imbrandon> heya bro missed yall at SCALE heh, but i'll catch up soon enough somewhere along the way
[02:21] <imbrandon> but hey i got an idea i want to run by you before i blog about it, got a half sec
[02:21] <imbrandon> ?
[02:21] <jono> imbrandon: cool, but I don;t have long, about to catch a flight
[02:22] <Hobbsee> jono!!!
[02:22] <jono> hey Hobbsee :)
[02:22] <Hobbsee> :D
[02:24] <pochu> is the london office open to the public? :)
[02:25] <Keybuk> pochu: no; why?
[02:25] <Keybuk> (it's neither very large, nor interesting, since the development staff all work from home)
[02:26] <pochu> Keybuk: oh, ok. because I'm travelling to london this afternoon, till monday :)
[02:26] <seb128> Mithrandir, pitti, cjwatson: could any of you have a second look on xcb-proto (source NEW coming from Debian for xorg 7.2) before I accept it? Just to make sure I make no mistake with source new (it should be safe since the package comes from Debian)
[02:27] <pitti> re
[02:27] <pitti> seb128: will do, I'm just about to start archive stuff anyway
[02:28] <seb128> pitti: thank you
[02:28] <Keybuk> pochu: it's where the admin and business development teams work from; unless those particular departments interest you? :p
[02:28] <seb128> pitti: I'm taking a syncs lock again, I'm helping on the xorg syncs atm
[02:28] <jwendell> pitti, i'm trying to improve 'tsclient'. When i run debuild for the second time, i get an error like that:
[02:28] <pitti> seb128: that's fine; I'll do removals and NEW
[02:28] <jwendell> Trying reverse patch debian/patches/99_autogen.patch at level 1 ... 0 ... 2 ... /bin/sh: line 28: 14829 Done                    $cat $patch
[02:28] <jwendell>      14830 Aborted                 (core dumped) | patch -d . $reverse -E --dry-run -p$level > $logfile 2>&1
[02:28] <jwendell> failure.
[02:28] <jwendell> make: *** [reverse-patches]  Error 1
[02:28] <jwendell> debuild: fatal error at line 1228:
[02:29] <jwendell> fakeroot debian/rules clean failed
[02:29] <jwendell> pitti, any idea?
[02:29] <pitti> jwendell: welcome to the horrible world of autoconf
[02:29] <pitti> jwendell: patching generated files and calling autoconf/updating config.{guess,sub} don't mix well
[02:30] <pitti> jwendell: you either want to debuild with -nc, or remove/unpack the source again
[02:30] <jwendell> pitti, i'm using later option, but i have to backup the patches i've already done...
[02:30] <seb128> pitti: what email should be used for "Maintainer:" for an universe package?
[02:31] <jwendell> pitti, thanks
[02:31] <pitti> seb128: see spec<EMAIL_ADDRESS>by default
[02:31] <seb128> pitti: ok, thank you
[02:31] <seb128> pitti: could be a good idea to send an announce mail about that maybe no?
[02:31] <pitti> seb128: xcb-proto has an invalid copyright file
[02:31] <seb128> I'm not sure MOTU will read the spec or understand what they are supposed to do
[02:31] <pitti> seb128: right
[02:31] <BenC> How does one add an event to the fridge?
[02:31] <seb128> pitti: it's built from debian/rules
[02:32] <pitti> seb128: ugh
[02:32] <pitti> +debian/copyright: debian/copyright.debian COPYING
[02:32] <pitti> +       cat $+ > $@
[02:32] <pitti>
[02:32] <seb128> yeah, it's sort of ugly
[02:32] <pitti> *tsk*
[02:32] <seb128> it has been accepted to Debian though so I was not sure
[02:32] <pitti> seb128: otherwise it looks okay
[02:32] <pitti> seb128: in the source you have COPYING, and in the .debs you have a reduntant GPL copy, but *shrug*
[02:33] <pitti> seb128: the reduntant GPL copy isn't a strong enough reason for me to deviate
[02:33] <seb128> pitti: well, it has been accepted to Debian and we need it for xorg 7.2
[02:33] <seb128> let's accept it and fix later if that need to be cleaned
[02:33] <pitti> seb128: as I said, WFM
[02:33] <seb128> thank you for the review
[02:33] <pitti> seb128: oh, btw, package looks fine for main
[02:34] <seb128> pitti: can I accept it to main directly or do we need a MIR?
[02:35] <Riddell> Mithrandir: you released powerpc images as well?  I thought they were broken
[02:35] <pitti> Riddell: worked for me, segfaulted for ogra, so they are 50% broken...
[02:35] <Riddell> oh, I thought it broke for others too
[02:36] <pitti> entirely possible, I didn't follow the progress
[02:36] <ogra> Riddell, it was fine for me with video=ofonly
[02:36] <Riddell> ok, groovy
[02:36] <ogra> (which i never needed before, so i didnbt check)
[02:50] <Kano> hi, could someone test this with mc:
[02:50] <Kano> mkdir this-is_a_test-dir-which-has-1_or-0_errors_with-mc
[02:50] <Kano> then try to change to that dir with it
[02:51] <Kano> this does not work with ubuntu, with debian no problem
[02:52] <Kano> Warning: Cannot change to /home/kano/this-is_a_test-dir-which-has-1_or-0_errors_with-mc.4Edit   5Copy   6RenMov 7Mkdir  8Delete 9PullDn 10Quit
[02:52] <Kano> because of that error i really dislike ubuntu...
[02:53] <Hobbsee> Kano: i cant reproduce that.
[02:53] <Hobbsee> oh, with mc...
[02:54] <Kano> mc is my favorite toy, i use it since i use linux
[02:54] <Kano> and it always worked nice
[02:54] <pochu> Keybuk: if you have coffee and food there, I'm interested :)
[02:54] <thom> Kano: this is abjectly off topic for this channel. i recommend #ubuntu-motu or #ubuntu
[02:55] <Hobbsee> heya thom
[02:55] <thom> hey :-)
[02:55] <Kano> thom: as the mc code is the same, it must be ubuntu specifc
[02:55] <Kano> a system issue
[02:56] <thom> Kano: so report a bug. it's not on-topic here
[03:03] <zul> maybe its something with his fs
[03:04] <pochu> good bye guys!
[03:10] <seb128> libice needs a fake sync with Debian because we have an higher epoch number
[03:10] <seb128> and I change the Maintainer field with it
[03:10] <seb128> what revision should be used? ubuntu1 or build1?
[03:10] <pitti> seb128: ah, tepsipakki already did a similar change for another package
[03:11] <pitti> seb128: I'd use build1
[03:11] <pitti> seb128: since we can autosync it if Debian bumped the epoch
[03:11] <seb128> tepsipakki managed to not change the Maintainer apparently
[03:11] <pitti> just to indicate that there are no changes that we want
[03:11] <seb128> right, makes sense to me
[03:11] <pitti> seb128: right, but adding an epoch is on the edge of what can be considered modification...
[03:12] <seb128> tepsipakki is speaking to the debian x team about it
[03:14] <iwj> I think avahi and upstart have conspired to break my xen guest.
[03:14] <iwj> The script that sets the firewall properly runs before the one that sets it wrong, now.
[03:16] <doko> pitti: Are the maintainer addresses somewhere recorded, so that it's easier to get the maintainer again (-0 -> 0ubuntu1 -> -1 -> want to have the old original address)
[03:17] <pitti> doko: sure, XSBC-Original-Maintainer:
[03:17] <doko> pitti: so how does -1ubuntu1 gets the "Maintainer" fields from -0ubuntu1 ?
[03:18] <pitti> doko: I don't understand, shouldn't MoM automatically apply this change?
[03:19] <Keybuk> iwj: nothing to do with upstart
[03:19] <doko> pitti: MoM may detect that, but then you have to use MoM ...
[03:20] <pitti> doko: if you don't use MoM's patch, why not simply copy the old M/X-O-M: fields from the 0ubuntu1 package?
[03:20] <ogra_> seb128, hey, we have a cd that ships ephy now :)
[03:21] <seb128> ogra_: rock on ;)
[03:21] <iwj> Keybuk: Don't upstart and the new init scripts make it possible for the scripts to run in a different order ?
[03:21] <ogra_> only add-on, but hey :)
[03:21] <iwj> mvo: Do you have a copy of that fix to gdebi somewhere ?  Have you uploaded it to feisty ?  I suppose it was probably held by the freeze.
[03:22] <Keybuk> iwj: what new init scripts?
[03:23] <pitti> ogra_: FYI,rasmol/pulse/alsa-plugins approved for main
[03:23] <ogra_> YAY !!!!!!
[03:23] <ogra_> gst pulse and alsa was what i was waiting for :)
[03:24] <pitti> ogra_: sorry for the delay; please feel free to urge me next time if stuff is needed for herds
[03:24] <pitti> I don't process the queue that often, there's a lot of noise
[03:24] <ogra_> well, i'm fine with telling people to install it manually :)
[03:24] <seb128> pitti: should we modify Maintainers when we only change the version number or that's only when we do packaging changes?
[03:24] <seb128> like the epoch change for xorg packages
[03:24] <pitti> seb128: that's a pathetic case; my gut feeling is 'no'
[03:24] <ogra_> its not that ltsp wouldnt work at all or something ... :)
[03:25] <seb128> pitti: ok, I didn't for that libice upload ;)
[03:25] <pitti> ogra_: python-ltsp is an in-house development?
[03:25] <doko> hmm, tollef not online?
[03:25] <pitti> seb128: if someone complains, we can still change that, but it would be quite ridiculous
[03:25] <seb128> doko: Mithrandir
[03:25] <seb128> right
[03:26] <ogra_> pitti, yep
[03:26] <doko> Mithrandir: please requeue gcj-4.1 on sparc (after gcc-4.1 is in the archive)
[03:26] <ogra_> pitti, it's the backend of ltsp-manager ... and will eventually merge with python-tcm
[03:26] <ogra_> so we have *all* ltsp related functions in one module
[03:26] <ogra_> keeps dokos python lists small :)
[03:26] <pitti> ogra_: package looks good, do you still want to have that one in main?
[03:27] <pitti> anyway, approved
[03:27] <ogra_> yay
[03:27] <pitti> ogra_: do you need anything else from the current queue?
[03:27] <ogra_> pitti, indeed i want it in main :)
[03:27] <ogra_> nope, i'm happy
[03:28] <ogra_> ltsp-manager might or might not be ready for main, i'll decide that if i'm ready with the code
[03:28] <ogra_> python-ltsp was the important part :)
[03:36] <pitti> cjwatson: I just reviewed mouseemu and gave it a quick audit; souce looks good, just the init script needs LSBification
[03:36] <ogra> pitti, the ldap/pam stuff would be nice to get to main during feisty to have it in the ship seed, but i will redo the MIRs first and you can leave it to iwj it's not majorly important ...
[03:36] <pitti> cjwatson: I'll file a milestone bug for the init script and approve it, if that's ok with you?
[03:37] <pitti> ogra: I don't feel competent about pam/ldap TBH, I never used it
[03:37] <ogra> pitti, well, its the missing bit users need to make use of ldap auth at all ...
[03:38] <ogra> it's silly that we support slapd but nothing of the rest thats needed
[03:38] <seb128> cjwatson, Mithrandir, pitti: do we have some rune to sync from Debian incoming?
[03:39] <elmo> ogra: err that's not actually true
[03:39] <ogra> elmo, ?
[03:39] <pitti> seb128, cjwatson, Mithrandir: I'll show Sebastien
[03:39] <elmo> ogra: in fact it's demonstrably untrue, witness how you're authenticated to chinstrap
[03:39] <thom> no-one expects userdir-ldap
[03:39] <thom> :-)
[03:39] <cjwatson> pitti: sure, sounds good, thanks
[03:40] <elmo> ogra: now, arguably, that's not the majority or even common use case, but claiming we're missing "the bit users needs to make use of ldap auth at all" is just crazy exageration
[03:40] <doko> Mithrandir: gcc-4.1 is now in the archive for sparc, please requeue gcj-4.1 on sparc
[03:40] <ogra> elmo, we support slapd ... but i dont know any network auth for desktop that doesnt use libpam-ldap for example
[03:40] <kwwii> ogra: I've been tweaking GDM so it uses svgs for the boxes...
[03:40] <ogra> elmo, well, it would make sense to support pam-mount and libnss-pam as well
[03:40] <kwwii> ogra: http://sinecera.de/ubuntuscreen.png
[03:41] <kwwii> ignore the logo, of course :-)
[03:41] <doko> Mithrandir: please requeue gnat-4.1 for sparc as well
[03:41] <ogra> kwwii, but the entry widget is still a gtk.Entry box yes ? *g*
[03:41] <elmo> ogra: I'm not disputing that, I just hate that kind of unnecessary drama
[03:42] <kwwii> ogra: sure, but that is your job to change it ;-)
[03:42] <ogra> elmo, well, i's no drama ... id just like to see these three packages in main to help our users :)
[03:43] <ogra> kwwii, indeed :)
[03:43] <elmo> ogra: sigh, never mind
[03:56] <seb128> pitti: if I maintain a package for Debian and Ubuntu, is there a way to tell to dpkg to  not complain about the Maintainer not being changed?
[03:56] <pitti> seb128: maintaining this list in dpkg would be quite cumbersome :(
[03:57] <seb128> pitti: ok, I'll change it then, no problem
[03:57] <pitti> seb128: you could just put your @ubuntu address in Maintainer and skip O-M
[03:57] <seb128> I'll put desktop team as maintainer that's fine
[03:58] <seb128> hum, using my Ubuntu email looks fine as well ;)
[03:58] <bddebian> Heya
[04:06] <cjwatson> pitti: perhaps there could be an override switch in dpkg-buildpackage/dpkg-source to suppress that error, for seb128's case
[04:06] <pitti> cjwatson: we already have such an override system in pkgbinarymangler
[04:07] <pitti> since the debs are much more prominent, we shuold just add seb128 there IMHO
[04:08] <pitti> mvo_: is bug 85207 fixed in Feisty? Please update the feisty status task
[04:08] <Ubugtu> Malone bug 85207 in apt "SRU request for new DPKG::StopOnError config " [Undecided,Unconfirmed]  https://launchpad.net/bugs/85207
[04:08] <cjwatson> right, but given the dpkg-source change it's not possible to build a package like that any more
[04:08] <doko> pitti: is there a fixed value for the clear name of the maintainer address?
[04:08] <cjwatson> regardless of what pkgbinarymangler does
[04:08] <pitti> doko: I just updated the spec an hour ago to add some default names for consistency
[04:09] <pitti> doko: I took the pkgbinarymangler values: Ubuntu {Core,Motu} Developers
[04:09] <pitti> erm, MOTU
[04:09] <doko> so Core and MOTU.
[04:09] <pitti> cjwatson: true; I don't see a good heuristic, it'd really require a list in dpkg-dev itself
[04:12] <mvo_> pitti: it is
[04:12] <mvo_> pitti: I update the status now
[04:13] <pitti> mvo_: this gives me the creeps - 'do we want to break edgy this or that way?' :/
[04:14] <mvo_> pitti: the stoponerror? yeah, its a matter of picking the poison it seems. best is if we do not have errors during the upgrade
[04:18] <cjwatson> pitti: like I say, an override option would do, perhaps?
[04:18] <geser> doko: should gcc-4.0 be given-back to the buildds?  it looks like it never reached them
[04:19] <doko> geser: no, look at the control file
[04:24] <geser> doko: thanks for the pointer
[04:24] <jdong> Keybuk: I've lost all my vt's since upstart 0.3.5......
[04:24] <jdong> like all the consoles are just simply blank, or show the last bootup script executed
[04:24] <geser> I looked at gcc-4.0 because there are still some old debs on the archive creating some unmet deps
[04:25] <torkel> jdong: have you tried to hit enter?
[04:25] <jdong> torkel: consoles do not accept any input
[04:25] <_ion> jdong: Does /etc/event.d/tty1 contain the line "start on runlevel 2"?
[04:25] <_ion> jdong: Note the space between "runlevel" and "2".
[04:25] <jdong> _ion: nope
[04:25] <jdong> start on rcS
[04:25] <jdong> all of them are that way
[04:26] <jdong> but rcS should carry over to rc2... right?
[04:26] <iwj> Is there an easier way to say something like
[04:26] <iwj>   if [d if d not in deps_new for d in tb.deps_processed] :
[04:26] <_ion> jdong: Uh. Strange. I don't think those are the default tty* jobs from the system-services package.
[04:26] <Keybuk> jdong: you changed them yourself?
[04:26] <jdong> _ion: any way to reset that
[04:26] <jdong> Keybuk: I haven't touched a thing! :)
[04:26] <Keybuk> jdong: you must have
[04:27] <jdong> well, I will adamantly deny that :)
[04:27] <Keybuk> jdong: the ones shipped with upstart said "runlevel" not "rcS"
[04:27] <jdong> but how would I restore the defaults?
[04:27] <jdong> I have not touched upstart configs... I swear :)
[04:27] <Keybuk> jdong: is there a .dpkg-new file alongside each tty file?
[04:27] <jdong> Keybuk: no....
[04:27] <Keybuk> jdong: do you have the system-services package installed?
[04:28] <jdong> Keybuk: hehe apparently not
[04:28] <jdong> sorry about that :D
[04:28] <_ion> Where did those tty* files come from then? :-)
[04:28] <jdong> _ion: previous upstart? :)
[04:28] <keescook> Mez: pong
[04:28] <_ion> Has upstart ever shipped tty* jobs with "start on rcS"?
[04:28] <jdong> okie dokie, attempt reboot.....
[04:28] <jdong> _ion: isn't that the way it worked last release?
[04:29] <Mez> keescook, i have a poc rar but the dev wants it kept private for obv reasons
[04:29] <Keybuk> jdong: no
[04:29] <jdong> heh well anyway
[04:30] <Keybuk> make sure you have startup-tasks and upstart-compat-sysv as well
[04:31] <_ion> Better have the ubuntu-minimal metapackage installed.
[04:31] <freshmouse> Hello. I downloaded Herd 4, but I have a problem with boot. I can't boot it, it gives me a "loading error" (in text mode it's called error 10)...
[04:33] <jdong> ok all is happy
[04:33] <_ion> jdong: Better have the ubuntu-minimal metapackage installed.
[04:34] <jdong> _ion: yeah good idea; dunno how that became uninstalled
[04:34] <jdong> heh
[04:34] <_ion> Would it be evil to make ubuntu-minimal Essential: yes? :-)
[04:35] <jdong> shoudl I be using this terminus thingie?
[04:37] <freshmouse> No ideas?
[04:38] <freshmouse> I think, it needs edit the booting parametres, but I can't rememeber (and find) how.
[04:39] <pitti> BenC: is there still something to be done for bug 74004? dapper task is still open
[04:39] <Ubugtu> Malone bug 74004 in udev "Doesn't include qla2xxx firmware" [High,Confirmed]  https://launchpad.net/bugs/74004
[04:39] <BenC> pitti: I can't remember if mdz's work was on dapper or edgy
[04:39] <pitti> BenC: (both udev and initramfs-tools task); but there are no debdiffs
[04:39] <pitti> BenC: mdz worked on edgy, I finished the edgy SRU and uploaded stuff
[04:40] <BenC> pitti: Then we probably need firmware in kernel, and both udev/initramfs fixups in dapper
[04:40] <BenC> pitti: I don't even know if we have the driver in dapper's kernel
[04:40] <pitti> BenC: it's still assigned to you, is that fine?
[04:40] <BenC> kylem: ping ^^
[04:40] <BenC> Re-assign to kyle
[04:41] <BenC> If you could, please
[04:41] <pitti> sure
[04:41] <kylem> moo?
[04:42] <keescook> pitti, seb128: are you doing "NEW"s?  I think libfilter-template-perl is in this state (#85012)
[04:42] <kylem> i don't think we have that driver.
[04:42] <pitti> keescook: will do in a bit
[04:42] <pitti> keescook: still doing SRUs
[04:43] <keescook> pitti: okay, thanks!  no rush; I just wanted to make sure I understand where it was.  :)
[04:43] <pitti> kylem: if it's invalid for dapper, can you please reject the dapper tasks?
[04:43] <kylem> i'll look into it first.
[04:43] <kylem> iirc dapper already includes the firmware in the .ko.
[04:44] <pitti> cjwatson: do you have some minutes to look over bug 85934? I don't like to approve my own SRUs
[04:44] <pitti> yes Ubugtu, I suck; I mean bug 85394
[04:44] <Ubugtu> Malone bug 85394 in tzdata "New timezone data 2007b" [High,In progress]  https://launchpad.net/bugs/85394
[04:46] <kylem> pitti, the firmware is definitely built-in for dapper...
[04:50] <cjwatson> pitti: oh, yeah, I promised to, ok
[04:51] <pitti> cjwatson: thanks; we should bring it into edgy before March, so that the new rules arrive in time (that's why I'm urging)
[04:51] <kylem> pitti/mdz/BenC, this needs kernel changes since dapper doesn't include qla24xx.fw.bin
[04:51] <kylem> we can't SRU a kernel...
[04:51] <kylem> should i just add it to -security?
[04:51] <pitti> kylem: ok, that's fine; let's just reject the task then
[04:51] <pitti> kylem: IMHO not; it's not a regression from breezy, just a missing feature
[04:52] <mdz> kylem: I thought it was already in -proposed
[04:52] <mdz> oh, you're talking about dapper
[04:52] <mdz> this driver worked in dapper
[04:52] <mdz> works, even
[04:52] <kylem> no.
[04:52] <kylem> /most/ of the driver worked.
[04:52] <pitti> mdz: there's not even a debdiff for dapper
[04:52] <kylem> qla24xx is still missing firmware.
[04:52] <cjwatson> pitti: yes, those are ok, same criteria as previous tzdata updates
[04:52] <kylem> (22xx/23xx have it built in.)
[04:52] <mdz> it works well enough for the customer
[04:52] <jdong> grr how can you get a GNOME app to print to a custom command?
[04:52] <jdong> not veryone uses cups.....
[04:53] <mdz> oh, I see
[04:53] <pitti> cjwatson: thanks
[04:53] <BenC> Oh right, the driver in dapper had the firmware built-in
[04:53] <poningru> the firefox vuln in <IP_ADDRESS>
[04:53] <mdz> kylem: I don't think we should backport the initramfs/firmware changes to dapper
[04:53] <poningru> asac: ping
[04:53] <pitti> poningru: ah, that's on our radar
[04:53] <poningru> pitti: the patch is approved upstream
[04:53] <pitti> poningru: we'll update to <IP_ADDRESS> as soon as upstream releases them
[04:53] <BenC> mdz, kylem, pitti: I don't think any of this is needed for dapper, unless there's something horrible with the driver already there
[04:54] <poningru> pitti: why not just patch it ourselves and do it?
[04:54] <kylem> BenC, if you have an ISP24xx card (which is supported by the driver) it is missing firmware.
[04:54] <pitti> poningru: there are more changes in <IP_ADDRESS>, I assume; we can add the patch on top of the <IP_ADDRESS> security update, of course
[04:54] <poningru> right
[04:54] <kylem> i'm happy enough fixing that, but only if it's worth the effort...
[04:54] <poningru> pitti: they are respinning <IP_ADDRESS> for this
[04:55] <pitti> lol, ok :)
[04:55] <mdz> kylem: only if it can be built in like the other firmware
[04:55] <BenC> mdz: It shouldn't hurt to include the firmware in an update, since it wont affect any existing installs, and the lack of firmware on the CD means we wont get any new installs that need the udev/initramfs fix
[04:56] <kylem> mdz, it wouldn't be, the 24xx seems to be a special case throughout the driver. can we flag this one as a "maybe if we do a point release"?
[04:56] <mdz> BenC: sure, I'm just saying we ought not mess around with initramfs and udev in dapper
[04:56] <cjwatson> asac isn't generally around here on Fridays
[04:56] <cjwatson> pitti,poningru: ^--
[04:56] <pitti> kylem, mdz: ok, sounds like rejections of the dapper/edgy tasks are in order?
[04:57] <pitti> kylem, mdz: sorry, s_/edgy//
[04:57] <BenC> mdz: Agreed. I do think it would be safe to include the firmware though, even if it isn't in the driver
[04:57] <poningru> cjwatson: ah ok thanks
[04:57] <BenC> actually, I think it's safe if it doesn't need to be compiled in...less code changes
[04:57] <BenC> *safer
[04:59] <kylem> i'm happy with whatever we choose, one way or another.
[05:01] <geser> is it possible to have Depends: wine [i386]  in an arch all meta-package?
[05:01] <BenC> kylem: Do you know if the firmware for that device is external, and the driver already has code to load?
[05:01] <elmo> geser: no
[05:01] <kylem> BenC, for almost all of the card types supported, it's internal in 2.6.15, except the two models of qla24xx, which require the external firmware.
[05:02] <BenC> kylem: But does the driver already have code to demand load that firmware?
[05:02] <kylem> yeah.
[05:03] <BenC> kylem: I'd say drop the new firmware in the kernel for proposed, see if you can find someone with that device willing to test it, and work to move it into -stable
[05:03] <kylem> fabio may have one.
[05:03] <BenC> is that a dell type device?
[05:23] <iwj> mvo: AYT?
[05:23] <iwj> mvo: I'm having some difficulty with this local apt-ftparchive.
[05:24] <mvo> iwj: I'm here, what is the issue?
[05:25] <iwj> apt-get update says just   Ign file: . Release.gpg
[05:25] <iwj> (and similar messages)
[05:26] <iwj> I have    deb file:///root/adt-downtmp/binaries . main
[05:26] <iwj> /root/adt-downtmp/binaries contains Release{,gpg}, Packages.gz and a few other files.
[05:27] <iwj> (I knew it passing the test yesterday was too good to be true.  It turns out it wasn't installing the package I intended at all ...)
[05:29] <mvo> iwj: is there a reason not to use a flat structure? like "deb file:///root/apt-downtmp/binaries /" and lump it all into a single dir? or is that dir becoming big?
[05:30] <iwj> Err, I'm allowed `/' ?
[05:30] <mvo> think of the / as "./"
[05:30] <iwj> deb file:///root/adt-downtmp/binaries /   is an improvement.  Now it says    Failed to fetch file:///root/adt-downtmp/binaries/Release  Unable to find expected entry  Packages in Meta-index file (malformed Release file?)
[05:31] <mvo> iwj: what is in Release? can you put it into a pastebin? how was it generated (with "apt-ftparchive release ." ? after the Packages files were created?
[05:32] <iwj> http://paste.ubuntu-nl.org/6113/ is the fragment that generated it.
[05:32] <iwj> Just a mo and I'll upload the whole directory `binaries'.
[05:33] <mvo> iwj: keep a copy of the uncompressed Package file around , that should fix it
[05:33] <iwj> http://www.chiark.greenend.org.uk/~ian/d/x.tar
[05:34] <iwj> Err, that's not idea really.
[05:34] <iwj> s/idea/&l
[05:34] <iwj> Err, actually what am I talking about.
[05:34] <iwj> These Packages files are very small.
[05:34] <kuser> update-grub has changed location to /usr/sbin/. Why did ubuntu not follow yet?
[05:35] <mvo> iwj: if you haveboth Packages and Pacakges.gz in the  dir all should be good
[05:35] <iwj> mvo: How does apt decide whether the package it has installed is the right one ?  Does it record the original installation source ?
[05:36] <iwj> Do I need to worry about   Ign file:  Packages   ?
[05:36] <mvo> iwj: no, it will figure it from the available sources and usually pick the one with the biggest version number (but I'm not 100% sure if I understand the question)
[05:37] <mvo> iwj: Packages should be ok as long as it finds Packages.gz
[05:37] <iwj> OK.
[05:37] <iwj> My trickery with apt-key seems to have worked, at least.
[05:37] <iwj> That seems to work.
[05:37] <iwj> I have this new source which contains a mawk.deb with the same version number as that in the archive.
[05:37] <iwj> When I say `apt-get install mawk' I want it to install the one from my private archive.
[05:38] <iwj> It seems to do this already but I worry about how it knows.
[05:38] <mvo> iwj: and different md5sums? that is likely to confuse the system
[05:38] <iwj> Yes, different md5sums.
[05:38] <pitti> geser: gtk2hs still build-deps on mozilla-dev without alternatives
[05:38] <mvo> iwj: usually it will pick the package from the first source in sources.list, so if file:// is listed first, it will pick that
[05:39] <iwj> But how does it know that the package already installed isn't the one that it's seeing there ?
[05:39] <pitti> geser: anyway, I did a first round of removals, will check rdepends again on Monday
[05:39] <geser> pitti: I know, I'm working on it. see bug #85135
[05:39] <Ubugtu> Malone bug 85135 in gtk2hs "[UVF exception]  Sync gtk2hs (<IP_ADDRESS>-1) from Debian unstable (main)" [Undecided,Needs info]  https://launchpad.net/bugs/85135
[05:39] <pitti> geser: ah, fine; thanks
[05:40] <mvo> iwj: you mean you have 1.0-1 installed and 1.0-1 available. and it will (e.g. on upgrade) install the one from the server and think its a update?
[05:40] <mvo> iwj: IIRC it does so because the local version is different than the remote one and that makes it think its a good idea to reinstall it
[05:40] <iwj> How can it tell it's different ?
[05:41] <iwj> I have 1.3.3-11ubuntu2 from the archive installed.  My script creates this new archive (pulling a mawk 1.3.3-11ubuntu2 out of its back pocket that it built earlier), edits sources.list, runs update, and says apt-get install mawk.
[05:41] <mvo> iwj: it reads /var/lib/dpkg/status and sees e.g. a different install size than the one it has in the repository
[05:41] <iwj> Now apt somehow knows to install my mawk.
[05:41] <iwj> Urg.
[05:41] <iwj> How can I force this to happen ?
[05:41] <geser> pitti: gtk2hs is already broken (FTBFS with ghc 6.6)
[05:41] <pitti> geser: ah, I see
[05:41] <doko> Mithrandir: please requeue openoffice.org on amd64 (trying with new compiler)
[05:41] <mvo> iwj: with --reinstall. or use a new version number
[05:42] <iwj> New version number is slightly tricky because that might well break dependencies etc.
[05:42] <iwj> Eg, people write   Depends: thing (= myself)
[05:42] <iwj> And --reinstall is wrong because I only want some of the packages reinstalled.
[05:43] <mvo> iwj: heh, right. well, if it works with apt-get install --reinstall $pkg, then all should be good?
[05:43] <mvo> iwj: or is it a problem to figure in advance what package need a reinstall?
[05:43] <iwj> mvo: I know which packages I want to make sure get reinstalled _if they need to be installed at all_
[05:44] <iwj> But I don't know the latter question because only the dependency resolver knows that.
[05:44] <iwj> I suppose I could edit /var/lib/dpkg/status and set the Installed-Size of every package that I put in my local archive to some crazy value.
[05:45] <mvo> iwj: let me then re-check my memory just to be sure that you are hacking around the right assumptions :)
[05:45] <iwj> Oh!  I know!  What about if I edit Maintainer ?
[05:45] <iwj> I could write   Maintainer: Ian's crazy build thingum
[05:45] <kylem> argh. network manager. die.
[05:45] <mvo> iwj: I'm not sure if that is enough
[05:46] <iwj> Maintainer isn't enough apparently.
[05:46] <iwj> But editing Installed-Size in the dpkg status db works.
[05:46] <iwj> Yuk.
[05:48] <mvo> iwj: hrm, its evil enough to consider something custom with python-apt, no? there you have very precise control what to reinstall and what not
[05:48] <iwj> Is there a way to say `this package named X, if you want to install it, use this version, but do not install it just on my account' ?
[05:48] <cjwatson> kuser: we have
[05:48] <cjwatson> $ dpkg -c /mirror/ubuntu/pool/main/g/grub/grub_0.97-20ubuntu3_i386.deb | grep usr/sbin/update-grub
[05:49] <cjwatson> -rwxr-xr-x root/root     35831 2007-01-19 11:37:42 ./usr/sbin/update-grub
[05:49] <iwj> What fields does it compare ?  If there's one that I don't mind munging then that completely solves the problem.
[05:50] <kuser> cjwatson: Hm yes, but the lines in /etc/kernel-img.conf aren't adjusted
[05:50] <cjwatson> kuser: https://launchpad.net/ubuntu/+source/grub/+bugs and file it if it's not there already
[05:51] <Mithrandir> Riddell: ppc images worked for some people at least, so yes, I released them.
[05:51] <Mithrandir> doko: gnat-4.1, gcj-4.1 and openoffice.org all given-back.
[05:52] <iwj> mvo: Oh, no, actually that doesn't work because if I ask to satisfy dependencies it doesn't think I want to upgrade.
[05:52] <iwj> Can I upgrade only from one source ?
[05:53] <asac> poningru: any question?
[05:53] <kuser> cjwatson: Thanks, haven't found it there but will search until I'm sure I don't dupe.
[05:54] <mvo> iwj: you can use apt-get install foo=$version . for upgrade-ony-from-one source, why not comment out the others? or use a custrom sources.list?
[05:55] <mvo> iwj: apt-get upgrade -o Dir::Etc::sourcelist=/foo/bar lets you do this
[05:56] <poningru> asac: yeah was wondering if <IP_ADDRESS> with the new patch would be available for testing?
[05:57] <iwj> apt-get upgrade --reinstall doesn't seem to work.
[05:58] <iwj> I suppose I could look at the list of installed packages and explicitly apt-get upgrade <name-of-package>
[05:59] <iwj> Err,  apt-get -y --reinstall install mawk
[05:59] <asac> poningru: i have not planned to release preview packages build from rc release.
[05:59] <mvo> iwj: could you please point me to the spec or some more information? I think I miss some information what is needed :)
[05:59] <iwj> Would you mind if I phoned you ?
[05:59] <asac> but if you join #ubuntu-mozillateam channel, I will change topic if there are preview builds available
[05:59] <iwj> I think that'd be quicker.
[06:00] <geser> kuser: the change is documented in /usr/share/doc/grub/NEWS.Debian.gz
[06:00] <mvo> iwj: fine with me too
[06:01] <kuser> geser: That's how I found it. But the changes aren't performed in the ubuntu system.
[06:02] <geser> kuser: the file says you should edit it. I understand it that this doesn't happen automagically.
[06:04] <kuser> geser: Question is, who is "you". I, the user or you the developer. To me the former doesn't make sense.
[06:05] <geser> kuser: as this file it written by the Debian maintainer "you" is the user/admin
[06:06] <geser> kuser: if you have apt-listchanges installed you get this NEWS shown and/or mailed.
[06:09] <kuser> geser: And if /sbin/update-grub eventually vanishes, /etc/kernel-img.conf in the new packages get adjusted by the maintainer whereever that file comes from?
[06:19] <geser> kuser: /etc/kernel-img.conf is created by linux-image if it doesn't exist. it looks like the call to update-grub isn't created by default.
[06:20] <iwj> mvo: Thanks for that.  I'll get on and try it ...
[06:20] <mvo> iwj: :) keep me updated!
[06:22] <Adri2000> seb128, doko: why this one https://launchpad.net/ubuntu/+source/griffith/+bug/85441 doesn't need the ack from motu-sru?
[06:22] <Ubugtu> Malone bug 85441 in griffith "Please sync griffith 0.9.1-1 (universe) from unstable (main)" [Undecided,Fix released]
[06:22] <kuser> geser: Ok, so I now know which packet creates that file. But still don't know who's responsible to adjust the pathes in that package. Debian maintainers or Ubuntus.
[06:24] <lionel> Adri2000: motu-uvf you mean ?
[06:24] <geser> kuser: have you added the calls of update-grub there or were they already present?
[06:24] <kuser> geser: No, I didn't add anything.
[06:25] <Adri2000> lionel: err yes, seb128, doko: s/motu-sru/motu-uvf/
[06:25] <geser> kuser: find out who did it and you know has to updated them
[06:27] <seb128> Adri2000: pong
[06:28] <seb128> Adri2000: I thought it had been approved since it had an "ok" from doko, sorry if that was not correct
[06:28] <seb128> Adri2000: don't subscribe ubuntu-archive if that's something to decide by motu-uvf
[06:29] <Adri2000> seb128: I didn't subscribe anyone
[06:29] <doko> seb128: the subscription was done by the original submitter
[06:29] <seb128> Adri2000: the "you" was not for you especially but for whoever did that ;)
[06:30] <seb128> doko: no, you did it
[06:30] <Adri2000> according to https://launchpad.net/ubuntu/+source/griffith/+bug/85441/+activity
[06:30] <Ubugtu> Malone bug 85441 in griffith "Please sync griffith 0.9.1-1 (universe) from unstable (main)" [Undecided,Fix released]
[06:31] <doko> hmm, ok
[06:31] <seb128> Adri2000: no big deal anyway, that only a .1 new version
[06:31] <seb128> Adri2000: mistakes happen ;)
[06:32] <Adri2000> ok
[06:45] <shawarma> Is root on lvm still supported? (in Feisty)
[06:45] <doko> pitti: please approve the mysql-dfsg-5.0 upload
[06:45] <doko> pitti_: please approve the mysql-dfsg-5.0 upload
[06:45] <pitti_> ugh, yay network breakage
[06:45] <pitti_> doko: yup, got that; in feisty?
[06:46] <doko> pitti: edgy-proposed
[06:46] <pitti> doko: ah, that bug, right
[06:48] <BenC> what program detects and creates the initial xorg.conf?
[06:53] <pitti> doko: done, bug updated
[06:56] <iwj> mvo: How do I pass an apt-get -o option into gdebi, or don't I ?
[06:56] <doko> Mithrandir: please requeue libgnucrypto-java (i386/all)
[07:05] <rtg> mjg59: Hi - BenC tells me you are an ACPI/suspend expert. We are getting a bunch of complaits about suspend on Feisty and I'm attempting to determine when it stopped working. Any ideas?
[07:05] <pitti> yay, a C# reimplementation of dbus, exactly what we need *grumpf*
[07:05] <mjg59> rtg: There's a couple of patches that ought to go in
[07:05] <mjg59> rtg: There's a patch somewhere on acpi-devel about GPE configuration on wakeup
[07:05] <mjg59> I think the thread was about a T43
[07:06] <mjg59> rtg: About to head out - if you can't find it, I'll take a look later
[07:06] <rtg> mjg59: Thanks. I'll see if I can track it down.
[07:08] <shawarma> rtg: I've got a good guess..
[07:09] <shawarma> rtg: I don't remember if we ever got round to disabling vbetool for Thinkpads.
[07:09] <shawarma> rtg: If we didn't, that's a likely cause for broken resuming.
[07:10] <mjg59> (Nngh grah no it isn't)
[07:11] <shawarma> mjg59: Well, that's what the i810 driver developer guy said and removing vbetool from the resume chain fixed a *lot* of issues a while back.
[07:11] <rtg> shawarma: Suspend appears to be failing across a variety of machines. For example, I have a Dell XPS that won't return from suspend.
[07:13] <doko_> seb128: any unknown incompatibilities in libgail? (see #85609)
[07:13] <seb128> bug #85609
[07:13] <Ubugtu> Malone bug 85609 in openoffice.org "[apport]  soffice.bin crashed with SIGSEGV"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85609
[07:13] <doko_> s/unknown/known/
[07:13] <seb128> doko_: looking, that's a11y stack though, heno or dholbach would know better
[07:14] <seb128> doko_: reassign to gail
[07:14] <shawarma> rtg: Does it do anything at all or does the screen just never come back up properly?
[07:15] <rtg> shawarma: It just sits there blank after an initial flash of the disk light. Eventually the fan kicks on.
[07:16] <shawarma> rtg: Ok, that's not it then. I just seem to remember seeing the vbetool issue again recently.
[07:16] <shawarma> rtg: ...but if mjg59 says that's not it, then that's not it. :-)
[07:21] <pitti> Mithrandir: just to confirm, orig.tar.gz's need to have a COPYING file? having gpl stanzas in the source files is not enough?
[07:21] <pitti> or elmo ^
[07:30] <Burgwork> pitti: I hate to tell you this, but it appears liek that cupsys dapper update completely broke printing
[07:31] <pitti> Burgwork: hm, it seemed to have fixed stuff for other people, weird
[07:31] <pitti> Burgwork: but if it regresses for you, then let's skip it
[07:33] <pitti> Burgwork: can you please say so in the bug, so that we have a recording?
[07:33] <seb128> hum
[07:33] <seb128> binary splited to binary and binary-extra
[07:33] <seb128> -extra needs to Replaces binary, right?
[07:33] <seb128> dholbach used a Conflicts
[07:33] <pitti> seb128: and probably Conflicts: << too
[07:34] <seb128> Conflicts alone is not enough though, right?
[07:34] <pitti> seb128: that would break apt-get dist-upgrade IIRC
[07:34] <seb128> right
[07:34] <pitti> seb128: replaces/conflicts with << (changed version) are the right thing
[07:34] <seb128> I'll accept the upload and do an another one to fix it
[07:34] <seb128> pitti: well, I think some people told me that Conflicts is not required
[07:34] <seb128> that Replaces is enough
[07:35] <pitti> seb128: right, in theory Replaces: is enough
[07:35] <pitti> seb128: but that won't force the upgrade of the other package
[07:35] <NokiaA> ok so i brought vista and installed it. Whats the big deal? it's just like XP...it's not wiping my bum yet.
[07:35] <Burgwork> pitti: https://launchpad.net/bugs/55828
[07:35] <pitti> seb128: just Replaces: will just overwrite the files
[07:35] <Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Medium,Fix committed]
[07:35] <pitti> Burgwork: thanks
[07:35] <seb128> pitti: right
[07:36] <seb128> Conflicts is not right to force upgrade though ;)
[07:36] <NokiaA> wrong channel opps.
[07:37] <NokiaA> omg I just said 'i brought windows' in a ubuntu channel... I should be shot lol
[07:37] <NokiaA> my bad
[07:37] <Burgwork> pitti: I just added a comment showing what is happening
[07:37] <pitti> NokiaA: no, you should return it and reinstall :)
[07:37] <jordi> mm, no mithrandir
[07:41] <doko_> pitti: maybe we need an XS-Original-Uploaders as well ?
[07:41] <pitti> doko_: why that?
[07:42] <doko_> pitti: well, because that's invalid for ubuntu packages?
[07:42] <pitti> doko_: noone complained about that, and we don't use it anyway
[07:42] <doko_> ok, fine with me
[07:44] <keescook> anyone know why ubuntu continues to have a separate wine package from Debian?
[07:46] <seb128> keescook: no idea, ask \sh_away he's maintaining it
[07:46] <seb128> hi keescook BTW ;)
[07:46] <keescook> hiya!  :)
[07:47] <keescook> yeah, looks like the ubuntu wine doesn't have binfmt-support, but Debian's does.
[07:47] <keescook> (both have the bad desktop file, though)
[07:47] <seb128> good reason to merge with Debian then
[07:47] <keescook> agreed!  :)
[07:47] <keescook> there are some big differences between the two packages, though.
[07:49] <keescook> \sh_away: when you're back, I'd like to ask you about wine packaging; it seems Debian's package has binfmt-support and amd64 builds.  what would be needed from the Ubuntu packages to merge with Debian's package?
[07:50] <Burgwork> keescook: scott ritchie does Debian as well as teh official wine debs
[07:51] <keescook> Burgwork: yeah, the package looks good.  I'm just curious what the ubuntu-only changes are (the diff is giant...)
[08:45] <keescook> where is the log of "removed" packages?  i.e. libjpeg-mmx is not in feisty, and I want to figure out what replaced it, etc
[08:47] <keescook> (though this looks more like a failure on sbuild's part...)
[08:51] <geser> keescook: perhaps http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=158474 helps you
[08:51] <Ubugtu> Debian bug 158474 in wnpp "RFA: libjpeg-mmx" [Normal,Closed]
[08:51] <geser> it's the removal bug for libjpeg-mmx in Debian
[08:52] <keescook> geser: yeah, I tracked that down just now.  :)  So now I'm curious about gcc-4.0, which is still in debian.  :)
[08:53] <keescook> (weird, it hasn't built)
[08:53] <geser> gcc-4.0 is only architecture hppa and hurd-i386 in feisty
[08:54] <geser> it tricked me also
[08:56] <keescook> geser: what're you using to see the archs for that?  I tend to use apt-cache madison, but that doesn't give me other archs, and LP navigation takes me forever.  :)
[08:57] <geser> keescook: doko gave me the hint to look into debian/control
[08:58] <geser> I had to fetch the diff.gz
[08:58] <keescook> ah-ha! cheater.  :)
[10:56] <pochu> greetings from london :)
[11:25] <jdong> anyone else getting blurry fonts with firefox and gnome-terminal today?
[11:26] <jdong> all other apps seem fine... :-/
[11:29] <jdong> never find I magically fixed it
[11:44] <Riddell> cjwatson: in new partitioner partman_column_format_toggled() what actually tells partman the value of the format boolean?
[11:44] <Riddell> cjwatson: I can see "format='dummy'" but that's the same if the tickbox is true or false
[11:50] <Riddell> cjwatson: ooh, I got it to work
[11:50] <Riddell> although I'm not entirely sure how :)


[01:56] <haz3lnut> Aw c'mon folks, is this channel really that dead?  I been hanging here for almost a week and nary a peep out of anyone.
[01:57] <haz3lnut> So people in La don't run linux?
[02:39] <haz3lnut> Rob?  DaCeige?  What is DaCeige, some sort of ghost man?
[02:49] <haz3lnut> Leave for a year or so, and the whole channel falls apart. I thought this place would be rocking by now.
[13:09] <Robdgreat> I've been away all weekend


[04:16] <RAOF> Oh, fun. mesa FTBFS with -j5.
[04:17] <tjaalton> yeah it can have those issues.. though haven't seen it fail in quite a while
[04:17] <tjaalton> RAOF: building the unreleased git version?
[04:18] <RAOF> tjaalton: Both that and the archive version fail in the same way.
[04:18] <tjaalton> ah
[04:18] <RAOF> Trying to generate radeonsi source files.
[04:19] <tjaalton> huh, built it several times yesterday and they were all fine (-j8 though)
[04:45] <RAOF> tjaalton: Hah. And now git fails to build in the final stage because glu.h exists in debian/tmp. What?!
[04:46] <RAOF> Oh, that reminds me. Who wants to review apitrace? It's ready in git, I think we should have it in Ubuntu, and we don't need to wait for Debian. jcristau's obviously too busy to review it there.
[04:49] <tjaalton> RAOF: that's.. weird, don't see it here
[04:49] <tjaalton> I can have a look at apitrace today
[04:52] <tjaalton> hmm, wonder why cloning it drops it in a nonexistant master branch
[04:53] <tjaalton> oh right
[04:53] <tjaalton> since there's no debian-unstable branch :)
[04:53] <tjaalton> which is where HEAD is pointing at
[04:58] <RAOF> Heh.
[05:20] <tjaalton> which one should be fixed, the remote HEAD or the branch name(s)?
[05:20] <tjaalton> s/fixed/changed/
[05:22] <RAOF> tjaalton: Are you talking about apitrace or mesa here?
[05:22] <tjaalton> apitrace?
[05:23] <tjaalton> uh
[05:23] <tjaalton> -?
[05:24] <tjaalton> the convention has been to add -unstable(/-experimental) there, that's why setup-repository made apitrace.git/HEAD look like that
[05:25] <RAOF> Ah, sorry.
[05:26] <tjaalton> no worries, easy to change either way :)
[05:26] <RAOF> Ah.
[05:26] <RAOF> Right. And I didn't notice because I don't clone that!
[05:26] <tjaalton> exactly
[05:26] <tjaalton> been there, done that..
[05:26] <RAOF> I guess it should follow pkg-xorg convention and be named debian-unstable.
[05:28] <tjaalton> ok, so I renamed refs/heads/{debian,upstream}
[05:29] <tjaalton> now when you fetch you have both the old and new branches under as origin/*
[05:29] <tjaalton> -under
[05:29] <RAOF> Cool
[05:29] <tjaalton> just reset the local branch to follow the correct one
[05:31] <tjaalton> dunno what is the best way to remove the old remote branches
[05:32] <tjaalton> ah, git branch -r -d origin/foo
[05:32] <RAOF> Already done that.
[05:32] <tjaalton> cool :)
[05:32] <tjaalton> so we're set
[06:18] <RAOF> tjaalton: Mesa build confusion resolved! I was gentarball-ing with a seriously out of date upstream-experimental.
[06:19] <tjaalton> hah :)
[06:19] <tjaalton> that would explain glu.h, yes
[06:22] <RAOF> Yeah, I was wondering about that, given the damn thing has been deleted from the mesa tree!
[07:13] <dupondje> next Xorg version will support Optimus?
[07:13] <dupondje> Any roadmap available? thats for 13.04 ?
[07:16] <ml|vacation> dupondje: kernel support is missing
[07:16] <dupondje> what do we need exactly for it in kernel?
[07:17] <ml|vacation> sure you can share buffers, but for it to be actually useful you need to synchronize them to
[07:18] <ml|vacation> too*
[07:18] <dupondje> Optimus seems to be a mess to handle :(
[07:18] <dupondje> things on the roadmap for it in kernel?
[07:19] <ml|vacation> so that is what I've been working on, kernel tree is somewhere but i wont restart until next monday :p
[07:19] <tjaalton> dupondje: hm, I thought I asked if it was a hybrid setup.. noticed the bug discussion now
[07:21] <dupondje> ml|vacation: its planned for 13.04 or will it still make in 12.10 ?
[07:22] <tjaalton> 13.04
[07:23] <dupondje> or xorg-edgers ^^
[07:24] <tjaalton> well the userspace bits are nearly there
[07:24] <tjaalton> so you can just use a mainline kernel in addition to 12.10
[07:25] <dupondje> can I follow the status somewhere? So I'm up-to-date ? :)
[07:25] <tjaalton> https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-hybrid-graphics probably
[07:25] <tjaalton> it's missing some detail though
[07:30] <dupondje> subscribed :)
[07:38] <tjaalton> RAOF: apitrace doesn't have a gentarball target, shouldn't it?
[07:38] <ml|vacation> dupondje: I'll try to get the upstream pieces inside quantal, but it's less useful without the kernel parts
[07:40] <dupondje> using a daily kernel isnt an issue :)
[07:42] <RAOF> tjaalton: It's got a pristine-tar branch
[07:44] <RAOF> tjaalton: I guess it could also have a gentarball target, though.
[07:48] <tjaalton> RAOF: oh right, it does
[07:49] <RAOF> git-buildpackage. It's pretty good :)
[07:50] <tjaalton> debian/gbp.conf needs an update :)
[07:51] <tjaalton> oh you fixed it
[07:53] <tjaalton> hmm, why is the lintian warning suppressed? for backports?
[07:55] <RAOF> Hm. Does that no longer apply?
[07:55] <RAOF> It's there because when I first packaged it that warning showed up; is debhelper 9 stable now?
[07:56] <tjaalton> yeah
[07:57] <tjaalton> so you can bump it to >= 9
[07:59] <dupondje> nouveau bug followup is sweet :)
[07:59] <dupondje> in less then 24h issue is closed :)
[07:59] <dupondje> the reason we love open source!
[08:00] <tjaalton> I should probably forward some..
[08:00] <tjaalton> RAOF: policy is at 3.9.3
[08:00] <dupondje> try it out :) Ben does a great job!
[08:01] <tjaalton> I should probably try quantal on my hybrid t420s soon..
[08:02] <tjaalton> precise finally getting stable on it :)
[08:02] <dupondje> then its getting boring ;)
[08:02] <tjaalton> dang, didn't forward the compiz gpu-hungness yet
[08:04] <tjaalton> RAOF: don't know how to run the beast, but it builds and looks clean, so I'm ok with uploading it to quantal
[08:05] <RAOF> tjaalton: Install the frontend package and you can run qapitrace (it'll be in the dash), which allows you to trace stuff, or you can run “apitrace trace $app” to generate a trace.
[08:05] <RAOF> But given that I've built it in a clean chroot here, and it works, you probably don't have to do much testing :)
[08:06] <tjaalton> RAOF: yeah, I'll give it a whirl at some point
[08:07] <tjaalton> oh right, quantal laptop still gpu-hung, hehe..
[08:07] <RAOF> With the multiarch fixes in there you should even be able to trace wine apps reasonably!
[08:08] <tjaalton> hope I never need to go down that path..
[08:09] <tjaalton> but actually, would this help with the gpu hang I have? or is it more for debugging performance issues?
[08:09] <tjaalton> ah, read the description now :)
[08:10] <RAOF> Yeah.
[08:11] <RAOF> If you have some app that triggers the hang you could trace that, then the trace can be replayed on a dev box.
[08:12] <RAOF> ...which should reproduce the hang, making it easy to test :)
[08:15] <tjaalton> oh cool
[08:15] <tjaalton> I'll try it out then
[08:45] <tjaalton> hmm, should have a way to reproduce it more quickly
[19:15] <dupondje> [ 9560.052783] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[19:15] <dupondje> [ 9560.052788] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[19:16] <dupondje> outch
[19:25] <tjaalton> dupondje: so file a bug and attach it there
[19:25] <tjaalton> i915_error_state
[19:32] <dupondje> on what package?
[19:34] <tjaalton> ubuntu-bug xorg
[19:39] <dupondje> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1046505
[19:39] <dupondje> there :)
[19:50] <tjaalton> thanks
[19:59] <tjaalton> dupondje: can you reproduce it?
[20:44] <dupondje> tjaalton: nope, unable to reproduce it
[20:44] <dupondje> never had it before afaik


[19:00] <slashd> o/
[19:01] <tsimonq2> o/
[19:02] <slashd> o/ GunnarHj
[19:03] <GunnarHj> slashd: Yeah, I'm here for the case you need me.
[19:03] <slashd> GunnarHj, could we postpone your application to next DMB mtg, I'm afraid we don't meet the quorum for today mtg
[19:04] <slashd> a few folks are in vacation
[19:05] <GunnarHj> slashd: Sure, it's not exactly an emergency.. I thought that rbasak would be present, though, considering that he added that item a couple of hours ago.
[19:06] <slashd> GunnarHj, thanks for your understanding, even if rbasak show up, we will be missing one DMB member still for the quorum
[19:07] <GunnarHj> slashd: I see. Guess there is not much choice in that case.
[19:08] <slashd> GunnarHj, unfortunately not, my apologies.
[19:10] <slashd> If anyone want to bring something to the DMB, I'll stay around for the next hour or so but I won't officially start the DMB meeting.
[19:10] <slashd> tsimonq2, anything you want to add ?
[19:44] <slashd> Ok it's pretty quiet ;) let's call it a day ! see you at next DMB meeting.


[14:55] <danielthebague> networking has stopped on my ubuntu phone
[14:55] <danielthebague> is this due to the end of life of the ubuntu phone
[15:05] <danielthebague> has it been deactivated?
[15:14] <danielthebague> hi mpt has my bq aquaris e4.5 been deactivated
[15:46] <popey> danielthebague: no. we didn't remotely deactivate network on devices.
[15:47] <danielthebague> Do you think i could have been hacked?
[15:47] <popey> what's more likely is a bug, or for some reason the network has become disabled. either re-enabling the network or rebooting usually fixes it
[15:48] <danielthebague> rebooted multiple times and its not starting network manager
[16:00] <popey> might want to open a terminal and try "nmcli con" to see what connections are visible, and "nmcli con up" to bring up a connection
[16:00] <popey> i think you have to specify the connection name too


[02:05] <ChinnoDog> Hi MutantTurkey
[10:11] <teddy-dbear> Morning peoples, critters and everything else
[12:01] <icey> ahoy


[00:26] <pleia2> the team is officially verified for another 2 years, thanks nhaines for putting together the application https://wiki.ubuntu.com/CaliforniaTeam/ReVerificationApplication2015
[00:26] <darthrobot> Title: [CaliforniaTeam/ReVerificationApplication2015 - Ubuntu Wiki]
[01:52] <nhandler> Thanks nhaines :)
[01:55] <nhandler> Also, I have a box of pens/stickers sitting under my desk at work that I'll bring to the next event
[17:57] <nhaines> The next UOS session is about to start.  meetup.com for LoCo Teams.  You can view the video at http://summit.ubuntu.com/uos-1511/meeting/22618/meetupcom-for-loco-teams/ and ask questions in #ubuntu-uos-community
[17:57] <darthrobot> Title: [Meetup.com for LoCo teams - | The Summit Scheduler]


 All I know is its today.
[21:58] <belkinsa> #ubuntu-meeting and now
[21:58] <Unit193> Now, today, #ubuntu-meeting ?
[21:59] <jrgifford> OK. There now.
[22:00] <belkinsa> See ya
[22:00] <belkinsa> there
[23:03] <jrgifford> Congrats belkinsa, the states newest Ubuntu member!
[23:03] <belkinsa> Thank you!
[23:04] <jrgifford> So get your IRC cloak and then I'll figure out how to make you autovoiced here.
[23:04] <belkinsa> I will.
[23:04] <jrgifford> Because with membership comes perks of meaningless voicing.
[23:04] <jrgifford> :P
[23:05] <Unit193> jrgifford: That's for reloco leaders, actually.
[23:05] <jrgifford> Unit193 thats not what Paul told me... But ok.
[23:05] <Unit193> /msg chanserv flags #ubuntu-us-oh belkinsa +AV   if I remember correctly.
[23:06] <Unit193> jrgifford: Yeah, canth isn't a member, but is reloco.
[23:06] <belkinsa> That needs to go to skellat and see what he says.
[23:07] <Unit193> jrgifford: But, she is acting LoCo lead, so still correct technically. :P
[23:11] <Unit193> Perhaps thinking that ubuntu/member cloaks get OPs in this channel?
[23:11] <belkinsa> That might be a good idea.
[23:11] <belkinsa> Since we have no reLoCos
[23:12] <Unit193> (ubuntu/member cloaks already have +o, and have for a while.)
[23:16]  * belkinsa is working on getting cloak
[23:17] <Unit193> So I see.
[23:21] <belkinsa>  ubuntu/member/belkinsa
[23:21] <belkinsa> :)
[23:31] <belkinsa> Afterthought.  I think only true members of the LoCo that have Ubuntu Member cloaks should have voice.
[23:32] <Unit193> Eh..
[23:32] <Unit193> I'd disagree.
[23:52] <belkinsa> Nevermind.
[23:59] <Unit193> You know we can disagree, right?


[18:42] <sdeziel> nowadays, squid comes in two flavors: GnuTLS and OpenSSL. The GnuTLS one is the one in main. Since many other packages in main are using OpenSSL (apache2, nginx, postfix, dovecot, postgresql, etc) I'm wondering if it is just an historical reason to have the GnuTLS flavor of squid in main? (cross posted in #ubuntu-security)
[18:42] <sdeziel> sergiodj: any opinions ^
[18:42] <sdeziel> athos: same ^
[19:01] <Walex> sdeziel: GNU TLS and OpenSSL have different bugs and limitations, and some people think that OpenSSL has many more, so they created LibreSSL, and that's another story.
[19:07] <sdeziel> Walex: since LibreSSL isn't even in Debian, it's definitely another story


[10:43] <tsimonq2> I think I found a Launchpad bug here: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/icu/+git/icu/+merge/457194
[10:45] <tsimonq2> https://answers.launchpad.net/launchpad/+question/708709
[10:45] <tsimonq2> Happy holidays, Launchpad team :)


[11:06] <lotuspsychje> anyone wants to test a simple bug in 19.10, please add yourself affected https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1837392
[13:24] <hggdh> lotuspsychje: I see it has already been confirmed
[13:24] <EoflaOE> hi hggdh
[13:28] <hggdh> EoflaOE: hi
[14:06] <lotuspsychje> hggdh: yes & tnx ; )
[19:59] <Bashing-om> \o - Good day ! A/C restored :) .. RFO weak main house fuse !