[00:26] are there any mirrors for the alpha 5 x64 alternate ISO? cdimage is still giving me trouble [00:30] lukehasnoname: https://launchpad.net/ubuntu/+cdmirrors is mostly releases.u.c mirrors, but I'm sure there are some in there with cdimage mirrors too [00:32] damn, they must all be synced to the same server which does NOT have any alphas, apparently [00:34] * TheMuso remembers his ISP mirroring alphas, but can't remember if they still do, and thinks that an Australian mirror may not be the closest geographically. === vorian is now known as mad-mule === mad-mule is now known as vorian [02:17] ubuntu-fr [02:18] oops [02:39] Is cdimage.ubuntu.com down intentionally? [02:41] MattJ: http://91.189.88.34/ should get you there [02:41] james_w: thank you so much :) [02:41] only some of the servers behind cdimage are down, so going directly to one that isn't works [03:01] RAOF: If you thought your issue with attempting to switch a stream from hda to your USB speakers was bad, try mine. Pulseaudio completely dies when I either start pulseaudio with my USB sound card connected, or connect my USB sound card while pulseaudio is running. [03:02] TheMuso: Ba baw! [03:02] RAOF: Damn right. [03:05] I guess that answers the "will 0.9.12 be in Intrepid" question. [03:13] Yay! Go assertions! This is a log I'll need to send upstream. [03:13] But I think I need to try alsa 1.0.18rc3 first. [03:15] I'd send you my alsa-source package, but the lappy don't have internets. And it'll be trivial for you to build one yourself :) [03:20] RAOF: Yeah. [03:21] gah! Alsa-project.org is down. [03:22] I _could_ throw it up on my webspace; it's not too hard to hunt down internet for my lappy. [03:23] But the ftp is still up. [03:23] RAOF: nvm, the ftp part of alsa-project still appears to fucntion. [03:24] Yay! === asac_ is now known as asac [05:52] RAOF: BTW if you are using alsa-driver 1.0.18rc3, and attempt to change the volume of your hda device, you will get an oops. If you want to be really sure about having this resolved, I've just pulled this patch from one of the alsa dev's git trees, and can make an updated package available if you want it. [05:53] RAOF: patch to fix it that is. [06:01] TheMuso: Hm.. Let me try that. [06:02] It doesn't seem to oops here? [06:02] hrm [06:02] it may not be for all hda cards. [06:02] but it did for mine, which sent me hunting for the patch I remember seeing on the alsa dev list. :p [06:04] :) [06:04] Yeah, I don't think mine does; I'm fairly sure I'm using 1.0.18rc3, and it doesn't oops for me. [06:05] Yay crazy hda! [06:05] Totally agree. [06:10] RAOF: Ah thats right, the oops only occurs when changing S/PDIF settings. [06:11] Heh. I'm not so much with the digital out. [06:11] RAOF: yeah well I was just playing with elements in the mixer when it happened for me. The patch fixes it for me though. and luckily this patch is only for 1.0.18rc3, as in it doesn't affect ubuntu as it stands./ [06:12] :) [06:13] ok even the latest alsa lib and driver doesn't stop pulse from dying. [06:13] Upstream goes my log. [06:14] You've upstreamed my underrun logs, right? === tkamppeter_ is now known as tkamppeter [06:35] RAOF: Will be doing so as well. [08:14] I always seem to forget this: Is it necessary to specify a dependency on packages with priority: required? [08:16] no [08:16] lets go with iceweasel [08:16] :D [08:19] laptopnenolod: [citation needed] [08:19] bryce, When you're around, could you give me a hand with an x.org issue in Intrepid? :] [08:20] soren, priority: required packages are provided by the base system, and are not necessary [08:20] laptopnenolod: [citation needed] :) [08:20] soren, the debian policy manual [08:20] * cody-somerville notes that laptopnenolod is incorrect. [08:21] * soren sighs [08:21] * laptopnenolod notes that he is correct, and maintains several critical debian packages (have you enjoyed lilo recently?) [08:21] http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5 [08:22] cody-somerville, priority: required is effectively equivilant to essential: yes [08:23] infact, i do not know of any packages in priority: required that are not essential: yes [08:23] laptopnenolod: Look... I know that debian policy is the source for this source of information, so just referring to that is not very helpful. [08:23] laptopnenolod: er... [08:23] s/this source/this kind/ [08:23] I'm looking for a specific reference to support your claim. [08:24]

http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5 [08:24] laptopnenolod: ...which doesn't mention "priority: required" at all. [08:24] assuming that your packages are essential: yes (which they should be if they are in priority: required) [08:24] Er... No. [08:24] er, yes [08:25] * soren rolls eyes [08:25] laptopnenolod, In which cases would priority be set to required and essential not be set to yes? [08:25] forget it. [08:25] Package: bash [08:25] Essential: yes [08:25] Priority: required [08:25] laptopnenolod: procps [08:25] cody-somerville, exactly! as i said, they are equivilant [08:25] soren, that is odd. [08:25] No. [08:25] It's common. [08:26] laptopnenolod, It isn't a rhetorical question. I'm honestly interested since you seem to be knowledgeable about the essential field. [08:26] cody-somerville, apparently procps, and some others. enough to make them "common" [08:27] cody-somerville, but AFAIK debootstrap and cdebootstrap install all packages Essential: yes, and Priority: required .. so they are functionally equivilant. [08:27] I think the reason we don't depend on Essential is to prevent an unresolvable dependency loop. [08:27] Except you can probably remove a priority: required package without dpkg having a screaming hissy fit? [08:27] RAOF, yes. [08:28] so if for whatever reason, Essential: yes is not set, then you should depend on it. [08:28] but if it's priority: required, then it is most likely also Essential: yes [08:28] Well, regardless, I think we've established a distinction. [08:29] * StevenK can't think of a package this is Priority: required that isn't part of the essential set [08:29] scanning main, i only see less than 10 packages that are not Essential: yes, but Priority: required [08:29] There are 67 packages that are required, but only 25 that are essential... [08:30] So no, they're not "most likely also essential: yes". [08:30] Regardless, there is a distinction and so although laptopnenolod your answer pragmatically might be correct, it isn't technically correct - and I think soren was looking for the more technical answer. [08:30] i'm not scanning ubuntu. i should clarify that. [08:31] cody-somerville: Quite so. Thank you. [08:31] Btw, is there a pdf version of the Debian Policy Manual anywhere? [08:31] not that i know of [08:37] cody-somerville: the ubuntu-policy package appears to have a pdf in it [08:37] \o/ === dholbach_ is now known as dholbach [09:02] laptopnenolod: you're definitely incorrect, sorry. adduser and procps are the usual exceptions [09:02] i believe we settled this already. [09:02] it wasn't clear, and I wanted to give soren a clear answer [09:03] FWIW the main purpose of required these days is to be the first stage of debootstrap, i.e. stuff that's unpacked with ar and tar the first time round [09:04] for example I wanted there to be an answer from somebody else who maintains key Debian packages - I trust you use your password file ;-) [09:06] cjwatson, i mentioned [c]debootstrap already :P [09:06] (oh and of course libraries must never be Essential: yes even if they're required - Essential is *not* closed under dependency - but they're sort of an edge case since you typically versioned-dep on them) [09:06] cjwatson: Thanks very much. [09:06] in other news, can you guys replace abrowser with iceweasel. thanks [09:06] I think that would be very confusing since our firefox package is not based on Debian's iceweasel package [09:07] it would imply some kind of commonality that simply isn't there [09:07] yes :P you should work with Debian wrt packaging and tell mozcorp to go away [09:07] (right now, at least) [09:10] i haven't even seen the EULA nagbox yet. my intrepid box is at home :( [09:11] the unfortunate part about telling mozcorp to go away is that history demonstrates that that means our upstream bugs will suddenly get a lot less attention :-/ [09:11] which is one reason it isn't a slam-dunk [09:15] i need to upgrade my laptop to either debian lenny proper or intrepid; right now it is running a derivitive which is more of a personal sandbox... but the concepts i am playing with are definitely a lenny+1 if not lenny+2 thing. decisions, decisions :P === asac_ is now known as asac [09:17] also working on a shadowed source package format that says "take package from X and apply these changes to it"... definitely lenny+2 imo there [09:39] so, no one wants to comment on my email about vsftpd? or is it still too early monday morning? :p [09:39] err, that was for -server sorry === cjwatson changed the topic of #ubuntu-devel to: buildds down for maintenance for some hours | alpha-5 released | archive: open, feature freeze in place | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBu === cjwatson changed the topic of #ubuntu-devel to: buildds down for maintenance for some hours | alpha-5 released | archive: open, feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [09:42] (actually not all buildds are down; we should still have one per architecture, but the rest are being moved around) [09:50] I have the following command "apt-get -b source linux-image-2.6.27-3-generic" which fetches and build the kernel, the issue I'm having is that I need it to build a diffferent version of the source which is modified, any ideas on how to achieve this? [09:50] apt-get source (no -b), cd directory-it-gives-you, hack hack hack, debuild -b [09:52] apt-get source linux-2.6.26 [09:52] Intrepid uses 2.6.27 [09:52] results in "E: Unable to find a source package for linux-2.6.26" [09:52] the source package is just 'linux' [09:53] I need to use the source I have. [09:53] why not just build it in the usual upstream way, then? [09:53] because if I have to answer one question then I'm foo-bared. [09:54] you could copy in the debian directory from the current source, but configs will be out of sync and you will likely have to answer questions [09:54] I can't be prompted for any information, it has to build without any user interaction. [09:54] I think we need to understand exactly what you're actually trying to achieve here [09:54] I want to build a modified source and creaet the .deb pacakges. [09:55] but apparently noninteractively; why? [09:55] because I want the build to work on all hardware and I don't have time to learn the ububtu way. [09:55] dalew: you could use make-kpkg from the package 'kernel-package', if you just need to build debs [09:55] you will still need to provide usable configs, though [09:56] with the command used to build intrpid I was asked no questions, exactly how i need it to be. [09:56] dalew: do you only need to build one specific piece of modified source, or arbitrary modified source? [09:56] the who thing. [09:56] whole [09:56] what does that mean? [09:56] build it all. [09:56] I mean, do you want to be able to build anything from 2.6.ancient through to 2.6.future, or what? [09:57] or do you only care about just one version? [09:57] because you really do have to provide useful configs, which need a certain amount of human attention [09:57] I have a modified linux-2.6.26 source based on the rc5 [09:57] it would be much easier if you only had to care about one version [09:58] really, the following command asked for nothing form me "apt-get -b source linux-image-2.6.27-3-generic" [09:58] yes, you said. [09:58] that fetched the source, I already have the source I want to use. [09:58] that doesn't mean we have magic integration to build arbitrary source. [09:59] dalew: how about you grab the source package from here: https://launchpad.net/ubuntu/+source/linux/2.6.26-5.17 - that's the last 2.6.26 we released [09:59] dalew: unpack it with 'dpkg-source -x linux_2.6.26-5.17.dsc', and copy the debian directory into your modified source [09:59] because it will not contain my changes. [09:59] dalew: then debuild -b [09:59] dalew: because you're not listening to me! [10:00] ah but I see what your getting at. [10:00] dalew: copy the *debian directory*. not the whole thing. [10:00] sec. [10:00] that will include configs [10:02] darn, many sources to pick, the first generic is acceptable? [10:02] no no, those are binaries [10:03] the three links at the top of that page - .orig.tar.gz, .diff.gz, and .dsc [10:03] downloading all 3 [10:03] (you can actually do this with just the .diff.gz, which is less of a download, but the process is more involved because you then have to filter out changes to the kernel source itself) [10:06] ok got all 3 files. [10:08] extracting. [10:09] pitti, hi [10:10] ditto'd the debian dir. [10:14] next step in this process? [10:14] 09:59 dalew: then debuild -b [10:15] gotcha. [10:15] in the directory just above debian/ [10:16] http://acm.pastebin.com/d48ce1516 [10:16] which is the root source directory. [10:16] you're going to have to sync up debian/config/ with your source [10:16] how do I do that? [10:17] the reason our source package builds noninteractively is that that's already been done by the maintainer [10:18] you could try 'debian/rules updateconfigs' to see if it can be done automatically. Make sure that you have a backup of the source though [10:21] when I run it it keeps deleting the debian directory. === michiel_e is now known as Eghie [10:22] *blink* [10:23] I don't see anything that would do that and it's hard to believe. debian/ is important to source packages and our code doesn't typically run around deleting it ;-) [10:28] after the update debuild -b ran debian/rules clean and it was gone. [10:29] started fresh extract, copy and updateconfig seems to be building now. [10:29] there's no way that 'debian/rules clean' should remove debian/ [10:30] but try just 'debian/rules build && fakeroot debian/rules binary', then [10:30] well I don't know which command did it but I do know it vanished. [10:30] debuild -b seems to be working ATM [10:32] http://acm.pastebin.com/db013864 [10:34] here's the whole session, shwoing thta it starts out there but then fails with it missing. http://acm.pastebin.com/d3c8d1485 [10:35] cjwatson: what package setups up autologin on the liveCD? [10:35] NCommander: casper [10:35] cjwatson: ok, since autologin broke on the xubuntu livecd [10:35] (not a good thing for the CD to prompt for a username and password) [10:36] query, what are .udeb files? [10:37] dalew: that session looks like you had previously used make-kpkg or 'make deb' or something on that source tree, and it thought it was cleaning up after that [10:37] dalew: udebs are micro-debs used by the installer [10:38] NCommander: what display manager do you use? has this ever worked for Xubuntu? [10:38] cjwatson: Xubuntu uses GDM. It worked in Hardy since I used an Xubuntu liveCD to install [10:38] ok, it's from another attempt to follow instructions that didn't give a working install, your instructions seem to be going significantly further [10:39] NCommander: check /var/log/casper.log to see if there's anything interesting in there [10:39] Yeah, I will [10:40] cjwatsom: thanks [10:40] THere is a Critical bug against this on xubuntu-meta, and a New/Unclassified one on casper [10:41] dalew: no problem [10:41] cjwatson: any good ideas what might be causing this to go boom [10:42] NCommander: nothing comes to mind; if it's just gdm then it should be the same as Ubuntu, unless your configuration file location is different or something [10:43] cjwatson: well, I *think* I found the problem [10:43] cjwatson: it looks like someone removed casper from the live seed [10:44] cjwatson: it should be in that seed, right? [10:44] yes [10:45] oh, no, it doesn't need to be [10:45] NCommander: livecd-rootfs already deals with adding it [10:46] cjwatson: that seems to be missing too [10:46] yes, of course. livecd-rootfs isn't installed on the live CD, it's what builds the live filesystem [10:47] http://cdimage.ubuntu.com/xubuntu/daily-live/current/intrepid-desktop-i386.manifest says casper is on your live filesystem [10:49] oh [10:49] Thanks [10:49] jelmer: ping [10:52] cjwatson: just "dpkg -i" the image and header files is all that I need to do or should I do all of the .deb files?? [10:52] image and header should be fine [10:53] it made a lot of .deb files, normal? [10:55] ok, bootable, thank you for your time. [10:55] yep, it's normal that it made lots [10:56] I can imagine how longh it takes to build on fast machine, the dual 3ghz quad core Xeon does it in no time but the screen scrolls so quickly that it's hard to read anything. [10:56] what is the average build time? [10:57] or is under 5 minutes considered normal? [11:08] doko: the libnss-mdns recommend in openjdk-6 was reintroduced in 6b12~pre1-0ubuntu2, I reopened bug 261847 [11:08] Launchpad bug 261847 in openjdk-6 "Installing openjdk-6-jre-headless pulls in dbus/avahi" [Critical,New] https://launchpad.net/bugs/261847 [11:09] cjwatson, those would be generic installations meaning any CPU or are they going to be specific to my Xeon's? [11:09] dalew: they ought to be generic back to i686 (supposed to be i586 but that was a bug in our 2.6.26 configs) [11:10] oldest I got is Pentium-D so I should be safe then. [11:10] mistake, Celeron-D on a D915G [11:11] still pentium 4 class [11:11] supposrting SSE3 [11:14] lamont: are you around? [11:19] hm, are the lpia buildd's really i386's?, or can I use DEB_HOST_ARCH to determine that a package is being built on lpia? [11:20] mvo__: could you fix please bug 270035? it' only one line, but prevents the generation of the pot file [11:20] Launchpad bug 270035 in app-install-data-ubuntu "desktopize.sh doesn't work" [Undecided,New] https://launchpad.net/bugs/270035 [11:21] kelemengabor: sure === mvo__ is now known as mvo [11:21] thanks :) [11:27] tjaalton: they're i386 under the covers, but DEB_HOST_ARCH should work anyway [11:28] cjwatson: thanks [11:28] Mithrandir: could you change https://code.launchpad.net/casper/trunk to point to ~ubuntu-core-dev/casper/trunk, please? (I moved the old branch out of the way due to brokenness.) [11:34] hello ... i read about the plan integrating vmware-player into hardy partner sources ... does anybody know something about the plan when this will be done? [11:42] cjwatson, you seem very knowledgeable about ubuntu and the builds, is it possible to have a binary with multiple arches, say i386 and ppc that would work in their associated environments? [11:43] dalew: we don't have any real "fat binary" support that I know of, no [11:44] shame, it would be nice to have a single installation that works on PPC or Intel based machines. [11:46] oh oh, cleaned up everything, thought I'd make a fresh build in a build location and it generated the header and doc packages but then failed, use the same commands verbatim. [11:50] cjwatson: I thought ELF supported fat binaries [11:51] dalew: it would be in theory possible to create a universe installation disc for PowerPC and i386/amd64 since OpenFirmware doesn't use El Torro booting [11:52] NCommander: in theory I think so, but there's no distro-level support for it [11:52] you would almost certainly run into issues with per-architecture files that aren't ELF objects [11:53] IIRC one of the Debian multi-arch install images is i386/amd64/powerpc (but that's essentially just 3 netinst images glued together I believe). [11:53] cjwatson: multilib would help resolve that if Debian ever got around to supporting it [11:53] NCommander: I think that's very optimistic, even given the basic ground level of optimism involved in assuming that multiarch will happen any time soon [11:54] cjwatson: Solaris has multiarch (or something similar), so its at least possible [11:54] Debian's multiarch proposals is not intended to resolve any more than providing multiple trees of libraries; it doesn't even contemplate addressing multiple-architecture binaries [11:54] Of course, that multiarch has made it rather difficult to make a nexenta solaris-amd64 port [11:54] s/ is / are / [11:55] and it doesn't even start to address things like providing the completely different sets of hardware support that would be required for i386+powerpc [11:56] * NCommander nods [11:56] broonie: right, that just exploits CD layout tricks to make them all boot and then has a giant composite apt archive [11:56] I was just saying that multiarch would be a step in the right direction [11:56] cjwatson: how much do you know about the acceptance of new ports, I wanted to ask about the possibility of an offical (community supported) Solaris Ubuntu Server port [11:56] we haven't done it often enough for there to be a real process [11:56] by default, it would be a decision for the technical board [11:57] cjwatson: I guess the next question is how is the easiest way I can ask (the port already semi-exists in the form of nexenta, although it needs some clean up before it would meet Ubuntu standards w.r.t to source cleaniness) [11:58] the main problem with new ports is that there *has* to be a really solid more-than-one-person commitment to keeping it going. hppa has been a problem because it lags behind and developers occasionally end up so annoyed by e-mail about it that they invest time to clean it up [11:58] I don't think we should be accepting one-man-band ports [11:58] It already has a community [11:58] nexenta is based off ubuntu dapper and hardy [11:58] six developers, and 50+ users [11:58] and they must not involve source changes that would be unacceptable in Ubuntu; that seems obvious but is perhaps worth saying [11:59] cjwatson: of course [11:59] sure, but that only helps if they would actually be interested in developing for Ubuntu itself and qualified to do so [11:59] also, 50+ users is not worth the immense investment in terms of archive space [11:59] cjwatson: 50+ is the debian minimin for an offical port. Just saying. [11:59] small user bases like that should be done separately, IMO [11:59] NCommander: that doesn't change my opinion [12:00] I understand. [12:00] every new port adds a significant fraction to the time that the hourly archive run takes, for instance [12:00] Right now, I'd just ask the technical board if such a port would be acceptable (since its non-Linux), and then proceed from there on moving towards matching up with Ubuntu and then slowly working towards becoming an offical port [12:00] that time is already unacceptably long [12:01] cjwatson: its 40 minutes * arch last time I checked [12:01] no it's not [12:01] never has been [12:01] apt-ftparchive was in that ballpark for me on a clean run ont the archive with no database files [12:02] currently it takes about an hour for all architectures. But when you consider that the cron job is hourly, that's not to be sneezed at [12:02] we need it to take significantly less than an hour [12:02] clean run is not the normal case [12:02] * NCommander nods [12:02] What takes an hour in the script to run? [12:03] so at the moment I would be inclined to say that the performance problems MUST be fixed before we can add new ports. [12:03] err, all sorts of things. The Soyuz developers are aware of a number of problems and several of them are high-priority [12:03] * NCommander had no intention of instantly creating this port out of nowhere, just if Nexenta should be making moves to match Ubuntu so if/when they can be offically accepted its a fairly streamlined process [12:03] apt-ftparchive itself takes about 20 minutes [12:04] anyone familiare with mtools ? "mcopy -i imagefile.img ::file ." would copy file out of imagefile.img into $(pwd) ... is there a way to defne a secont imagefile as target ? [12:04] *second [12:04] ogra, I don't know if mtools can do it (it might), but would it not be simpler to loop mount the image? [12:05] liw, that would require root/sudo :) [12:05] i'm looking for a userspace way [12:05] sadly defining a second -i option doesnt do what i expected [12:05] cjwatson: Do you know how much faster NMAFA is that apt-ftparchive? [12:06] ogra: mmount two images on separate drive letters? [12:06] * ogra reads about mmount [12:06] wgrant: not in terms of hard numbers, no [12:06] cjwatson: done [12:06] Mithrandir: thanks [12:07] cjwatson, hmm, seems not to work without having a mtoolsrc [12:08] ogra: you could just copy out and then copy in ... [12:09] everyone, thanx for your time, time to head out to work so enjoy. [12:09] cjwatson, yeah, thats an option [12:09] * dalew shakes cjwatson's hand. [12:11] ogra: you can set MTOOLSRC to a local mtoolsrc file [12:11] yeah, thats what i thought about first [12:11] but i want a single script ... [12:11] sadly there are no global vars i could just set [12:12] export MTOOLSRC="$(tempfile)"; trap 'rm -f $MTOOLSRC' EXIT HUP INT QUIT TERM; ... [12:12] can still be in a single script :) [12:12] lol [12:12] wow [12:12] indeed [12:13] actually possibly "rm -f ..." rather than 'rm -f ...' there. but you get the idea. [12:13] yeah [12:13] * ogra hugs cjwatson ... genious [12:15] liw, the idea is that most .img files we use are vfat anyway ... i want to have a script set for any user to create and modify images without needing root [12:15] cjwatson: was just making notes on what I've done tonight, you gave me some alternate build commands which partial was "debian/rules build" but I only copied half the line, was going to try them later and see if it gave a better build., "Konversation" doesn't seem to keep logs. [12:15] ogra, ack, for that loop mounting isn't useful, unless you only run the script on systems where you are willing to set up /etc/fstab to have the loop mount with user option [12:16] nevermind, I found the log file. [12:53] NCommander, pong [12:54] jelmer: I was going to ask what patch system you perfer for samba4, but I found that quilt was already enabled in the build-deps so I used that to fix the build on Ubuntu [13:02] NCommander: back home now, generally not online at 4AM. [13:02] 6AM, OTOH [13:02] lamont: I was going by your /away status ;-) [13:03] heh. away means I either remembered to set it, or I killed the client [13:03] or I'm back and forgot to clear it. === pedro__ is now known as pedro_ [13:03] lamont: :-P [13:04] lamont: my question was what's the easiest way to talk to the TB about the possibility of having a community-supported solaris-* port (essentially merging nexenta's efforts into our own), since an Ubuntu Solaris server would sport powerful features like ZFS [13:05] * lamont generally finds email to be a good way to talk to the TB [13:05] point me to your leaders email address ;-) [13:07] "The Ubuntu Technical Board can be reached by email at technical-board@lists.ubuntu.com" [13:07] soren: do you happen to know what it means when I get "virtio-net header not in first element" ? === azeem_ is now known as azem === azem is now known as azeem === Seeker`_ is now known as Seeker` [14:05] mvo: Not off the top of my head, no. I have sort of a guess, but it doesn't make much sense, I think. Where are you seeing it? [14:07] soren: bug 270495 [14:07] Launchpad bug 270495 in kvm "-net user -net nic,model=virtio stoped working" [Undecided,New] https://launchpad.net/bugs/270495 [14:10] Is there a reason for the ula in FF3? [14:10] mvo: When did this happen? What changed? [14:12] davmor2: there's an extensive bug log on the subject [14:13] cjwatson: ah okay ta just noticed it and thought I'd check if there was a reason [14:13] soren: it happens shortly after I boot (can't give you details, it exists when the message appears) [14:13] mvo: I mean when did it stop working? [14:13] Extensive doesn't quite cover it any more. [14:13] mvo: 2.6.27-3, perhaps? [14:14] soren: I think it was not working with 2.6.27-2 too, I'm currently trying to figure out if it depends on the guest or not [14:15] soren: I will post more information into the bugreport, I was just curious if it is something known :) [14:15] mvo: I've not stumbled upon it before, no. [14:15] thanks! [14:22] siretart: you around? [14:35] NCommander: at work. [14:35] siretart: when you get home, there is a bug I'd like you to review (needs to be run by -release and ScottK wanted me to ask you) cause it required a dependency change [14:36] NCommander: what's the number? [14:37] siretart: https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/270200 [14:37] Launchpad bug 270200 in gnucash "Change libgoffice dependency from 0.4 to 0.6" [Low,In progress] [14:38] NCommander: did you already talk to thomas about this? How about filing this as a bug in debian and add a remote bugwatch on it? [14:38] siretart: bug is in debian, no response [14:39] The original bug had the watch [14:39] Hold on, I'll readd it [14:39] NCommander: but I don't see why it needs a confirmation from -release? [14:40] siretart: I was told that since it required a change in dependencies, it required approval [14:40] siretart: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498775 - debian bug [14:40] Debian bug 498775 in gnucash "Please change the dependencies from goffice0.4 to 0.6" [Wishlist,Open] [14:40] cjwatson: hi. Just to let you know I'm sort of back on the PS3 trail again. I have a stable kernel build (awaiting a git pull) so hopefully I can start to follow up some of the other issues on LP soon. [14:41] munckfish: cool, that's good to know [14:41] Launchpad won't let me add a remote bug watch [14:42] NCommander: I don't have any objections to that if you say you tested it and can confirm that it works okay for you [14:42] siretart: works for me [14:42] siretart: would you mind commenting that, and I'll subscribe u-u-s [14:46] NCommander: sure, go ahead [15:19] companies that serve 2MB pdf's for disaster recovery information to potentially 2mil affected customers are pretty dumb [15:19] i guess they never heard of plain text [15:20] if all customers downloaded this data which is updated twice a day they would be doing ~ 7.25TB/day transfer [15:20] needless to say their site is constantly falling over === Tonik_ is now known as Tonik [15:27] lovely now all i'm getting is IIS error messages :\ === superm1 is now known as superm1|away [15:39] asac: what are the chances of getting this patch applied to firefox for intrepid? https://bugzilla.mozilla.org/attachment.cgi?id=332569 [15:41] seb128: I have adapted my patches so as to make it easier for upstream to adopt them. If they are accepted we will only need a really small patch to make the xrandr capplet work automagically as planned. Here's the link to the bug which you filed: http://bugzilla.gnome.org/show_bug.cgi?id=545118 [15:41] Gnome bug 545118 in Screen resolution "should give a clue about why the settings can't be applied sometimes" [Normal,New] [15:42] tseliot: thanks [15:43] kwwii: what bug id is that? [15:44] seb128: of course, if they are not accepted, I will write other patches with the non-upstream functions marked with an "ubuntu" prefix. I guess it won't take long to have a reply from upstream since feature freeze is near, right? [15:44] tseliot: they are already feature and api frozen, code freeze is today for GNOME [15:45] tseliot: let's wait some days for commnents and then distro patch that for intrepid [15:45] seb128: ok, thanks [15:46] asac: https://bugzilla.mozilla.org/show_bug.cgi?id=405421 [15:46] Mozilla bug 405421 in Widget: Gtk "Ensure our widget painting is transparent for themes that support it" [Normal,Resolved: fixed] [15:47] seb128: so uh, first time I ever uploaded an FTBFS on i386 :-/ [15:47] NCommander: soyuz bug [15:47] \o/! [15:47] yay for bugs [15:48] seb128: hi - I've ran into bug 121341 for the python-gobject package. [15:48] Launchpad bug 121341 in python-support "python modules need to work during dist-upgrades" [High,Confirmed] https://launchpad.net/bugs/121341 [15:49] hey mathiaz [15:49] seb128: one solution could be to switch to python-central [15:49] seb128: what do you think about it ? [15:49] mathiaz: I would prefer avoid having to do this [15:50] kwwii: do we have a ubuntu bug for this too? if so, lets milestone that for beta [15:50] seb128: the other option is to fix python-support then [15:50] the word "non-trivial" comes to mind [15:51] mathiaz: the situation just sucks, pygobject is almost on sync on debian but changing debian to python-central will not be possible [15:51] one of the active pkg-gnome member is the python-support guy and he's against python-central [15:51] seb128: hm.. [15:52] and I already discussed the issue with him and he says there is no clean way to have things still working during an upgrade and he doesn't want to do that in python-support [15:52]