[00:00] Does that get burned onto the disk? [00:00] yes, or it can be read from other media (e.g. network) [00:01] Oh, Ok, I just want to read it from the CD [00:01] Is there a howto for this? [00:01] use the kernel parameter preseed/file=/path/to/preseed - usually you'd modify isolinux.cfg to make that change the default [00:02] start off on http://wiki.debian.org/DebianCustomCD - everything should apply equally to ubuntu [00:02] Oh, Ok, thanks [00:14] But the preceed file? [00:16] will be linked from somewhere on there [00:16] Oh, thanks for all your help [00:16] Good day. Shaw bash [00:16] http://letmegooglethatforyou.com/?q=preseed%20file :) [00:16] Oh, too late, I guess [02:47] ScottK, care to take a look at https://bugs.edge.launchpad.net/hardy-backports/+bug/309568? [02:47] Ubuntu bug 309568 in intrepid-backports "Please backport Swfdec 0.8.2 from Jaunty to Intrepid & Hardy" [Undecided,New] [02:55] No. [02:56] Heading out to buy packing tape for Christmas shipments that must go out tomorrow. [02:57] ah [03:17] ScottK: stay away from UPS overnight, $$$$$...I shipped out today from UPS on the Santa Express...will get to your neck of the woods on xmas eve, and it only cost $30 total [03:17] overnight morning delivery they wanted $100 [04:18] Yoohoo [04:18] I'm trying to help with https://wiki.ubuntu.com/SavingTheWorld [04:19] Can anyone tell me which version of gdm is likely to be in jaunty? [04:19] Here I see 2.20: http://packages.ubuntu.com/jaunty/gdm but there seems to be 2.25 in GNOME [05:07] RAOF: is nouveau in a workable state in jaunty, or is there some magic i need to invoke? [05:08] according to the alpha2 notes, the kernel support isn't in place yet? [05:08] psh [05:08] who reads alpha notes [05:08] real men install before the notes were written ;) [05:08] pwnguin: You need to review nouveau-kernel-source on revu, then upload it :P [05:18] RAOF: so it's sitting on a copyright review? [05:40] pwnguin: Yeah, and general packaging. [05:42] pwnguin: Feel free to review, if you'd like some nouveau action :) [07:01] lool: the djvulibre build failure looks like a linker problem. I know about it ... [07:09] good morning [07:09] what's good about mornings? :P [07:09] ;) [07:11] If mornings really exist, why are there only 12 hours on a clock [07:11] Keybuk: reping in case you missed my ping this weekend :) [07:11] StevenK: I always deny mornings exist ;) [07:12] they're a big conspiracy! :)P [07:33] seamonkey composer is probably the best WYSIWYG html editing solution under linux. [07:33] after "sudo apt-get install seamonkey", [07:33] ubuntu only installs a "SeaMonkey" launcher in the Internet category. [07:33] that's not enough. [07:33] i hope it also install a "SeaMonkey Composer" launcher whose command line is: seamonkey -edit. [07:34] yay, more drive bys. [07:35] * Hobbsee wonders about a bug report for that [07:39] Chipzz: morning [08:35] soren: qemu/kvm USB passthrough seems broken on hardy for me; it says 'usb_linux_update_endp_table: Connection timed out' immediately after I do usb_add host:1.2 in the qemu/kvm console. Is this known? Is there a workaround? [09:17] Hello. [09:19] I want to ask is ubuntu support graphic/video card ( 3dlab's WildCat III 6210) ? if yes , then it donot installed the drivers of it m the screen i can see right now is 3/4 of my computer , and the resolution is 800x600 , unfortunately there is no relevent thread available of forums on on google search as well , BUT , www.3dlabs.com do offer my video/graphic card driver for redhat/novel/suse distributions , Can any one help me [09:22] shani^work: try #ubuntu === PecisDarbs_ is now known as PecisDarbs [10:20] Keybuk: goodmorning :) [10:43] infinity: Hmm are you aware of http://launchpadlibrarian.net/20629978/buildlog_ubuntu-jaunty-armel.debian-installer_20081029ubuntu5_CHROOTWAIT.txt.gz ? [10:43] Unpacking chroot for build 815466-1906338 [10:43] tar: This does not look like a tar archive [10:43] armel chroot is buggered, i've had two reoprts today [11:06] directhex: ah [11:06] lool, i don't know who's in charge of debuggerification though [11:07] infinity. But he's on leave. [11:07] and what's the contingency plan? [11:08] directhex: I poked Canonical IS (buildd sysadmins) [11:16] cjwatson, i am wondering if it is possible to see if a package was uploaded [11:19] apw: not sure what you mean [11:19] apw: or, er, can you be more precise please? [11:19] specificially the module-init-tools in jaunty, rtg says he has uploaded an ubuntu18 but its not visible [11:19] (sorry got distracted, offered some coffee) [11:20] now when he did it before it wasn't there 'for some time' so i am interested in understanding where the limbo is before it appears, and whether its visible anywhere [11:20] it'd show up at https://launchpad.net/ubuntu/+source/module-init-tools if the upload was successful [11:21] modulo a delay of up to five minutes until a cron job runs [11:21] it will take "some time" to show up in the archive proper, but it will be visible in LP before that [11:21] and its not there, and its been a couple of days, but thinking about it he may have uploaded it agaist intrepid-proposed [11:22] the "some time" delay is because the archive proper is managed by a script that runs hourly and takes nearly an hour to run [11:22] presumably that needs to be approved before it appears? [11:22] where was the upload to? [11:22] jaunty? [11:22] if so they're auto-approved [11:22] thinking about it intrepid-proposed is most likely [11:23] as the last one was pocket copied to jaunty after the fact [11:23] is there a queue of unapproved things somewhere? [11:23] https://launchpad.net/ubuntu/intrepid/+queue lets you inspect unapproved stuff in intrepid [11:23] * apw adds that info to the juju list [11:24] elect unapproved from the drop-down [11:24] +s [11:24] ahhh there it is, thanks, so it was uploaded but its in there [11:24] also StableReleaseUpdates is quite clear that most things should go to the development release *first* [11:25] unapproved i assume means 'waiting for approval' not rejected [11:25] that is correct [11:25] cjwatson, yeah, i am not quite sure why rtg has been doing this package that way [11:25] it got copied to jaunty by someone else last time [11:25] I realise that the kernel itself is not done this way but that's a special case [11:26] the main reason is i now want to fix it again and can't get the source back through apt-get source [11:26] there was a period when jaunty wasn't open so things had to be done that way, but that's no longer the case. rtg should stop doing this [11:26] so was looking to see where it was gone [11:26] cjwatson, ahh, ok, it is hard for us sometimes as we work outside normal process so much [11:27] so in the normal process it would be uploaded to jaunty, fine [11:27] (that said I haven't looked at this change) [11:27] I think you can download the files from +queue [11:27] then when its proposed for intrepid, is that a new upload or is that a copy back? [11:27] new upload [11:27] * apw attempts to learn [11:27] ok ... [11:28] cool. i think i can get what _i_ need out of this queue [11:28] it's slightly more work (although only trivially so), but the reason for this is that it's usually much easier to shake out problems in the development release, and the strictures on doing work there are much weaker [11:28] and i will get rtg to sort out uploading it to jaunty, its too easy to get out of sync [11:28] besides as soon as intrepid and jaunty's versions differ you have to do this anyway [11:29] well, if this is to go into intrepid-proposed then we might as well copy it to jaunty as before. I'm just saying that rtg shouldn't do this in future [11:30] though as a counterpoint, encouraging him to upload it to jaunty will help cement that as the right approach === jscinoz__ is now known as jscinoz [11:33] cjwatson, thanks for the info [11:35] directhex: builder was taken out of the pool for now, until someone can check what's wrong [11:38] lool, will failed builds happen again automatically, or is a no-change reupload needed? [11:46] directhex: You can hit retry to give them back, and eventually they'll be given back when we give back all failed packages (this happens from time to time) [11:46] s/and/or [11:46] No need for a sourceful upload I think [11:47] directhex: Perhaps we can give back all "Chroot problem" failed builds right now [11:47] cjwatson, if one makes a change to a package like m-i-t for jaunty and the change is not required for intrepid its not going to get uploaded there, if later a change which is needed makes an upload to intrepid then the inbetween change is likely to get carried too. in this case it is a benign and safe change, is there somewhere one normally documents that sort of information for 'later' when the change is being considered? [11:50] lool: the djvulibre build failure is due to a very old libtool (2001) [11:50] lool: the shared library is linked with -nostdlib, but without -lgcc [11:51] doko_: No, I tried with the current one and it fails as well [11:51] doko_: With the new one, -nostdlib isn't on the command line and -lgcc_s is [11:51] doko_: However the shared gcc_s.so doesn't have these symbols, and the .a as them as .hidden [11:52] lool: linking the *shared lib* with -lgcc resolves this issue [11:52] but then I get: [11:53] g++ -o .libs/bzz -DHAVE_CONFIG_H -I.. -I.. -I../libdjvu -I. -DNDEBUG -Wall -O3 -Wno-non-virtual-dtor -pthread -DTHREADMODEL=POSIXTHREADS bzz.o -Wl,-Bsymbolic-functions ../libdjvu/.libs/libdjvulibre.so -lm [11:53] ../libdjvu/.libs/libdjvulibre.so: undefined reference to `__aeabi_atexit@CXXABI_ARM_1.3.3' [11:53] collect2: ld returned 1 exit status [11:53] make[1]: *** [bzz] Error 1 [11:53] doko_: I tried a cvs checkout of djvulibre with jaunty's libtool, and it didn't work; it could be a libtool issue though [11:53] doko_: I don't get that far [11:53] lool: try to add -lgcc to libdjvu/Makefile.in (LIBS) [11:54] doko_: Ok, I suspect your undefined reference is due to -undefined [11:54] -no-undefined rather [11:55] __aeabi_atexit is defined in libstdc++ [11:55] doko_: Aha, then there's a missing link to that perhaps? [11:55] Would be surprizing that this is needed [11:56] ahh, no in libsupc++ [11:58] Ok, so missing -l [11:58] doko_: Now is it a libtool issue to include -lgcc, or is it the job of upstream using atomic extensions? [11:59] ok, this works for now [12:00] Hmm this is some internal gcc lib [12:00] directhex: The chrootwait failed builds were requeued [12:00] lool: not sure why I do see this on armel only [12:01] apw: there's no such thing as a benign and safe change for stable releases; updates to stable releases must be necessary changes only [12:01] doko_: I suspect the i386 implementation doesn't need kernel side help [12:01] apw: StableReleaseUpdates has some stuff near the top about why [12:01] doko_: So no special library, but simply i386 instructions [12:01] Says cmpxchg or something [12:01] s/Says/say [12:02] cjwatson, it would be normal practice to build a branched version with out the intermediate change [12:02] apw: that's right [12:02] ok ta [12:15] with bzr build-deb, is there a way to specify a custom -i ? [12:17] --builder='dpkg-buildpackage -rfakeroot -uc -us -S -i...'? [12:17] or set source-builder in the configuration file, probably better [12:18] lool: libdjvu/atomic.* is hard coded per architecture [12:19] cjwatson: can it have per-package source-builder ? [12:20] you can have a per-package configuration file [12:20] .bzr-builddeb/local.conf [12:20] see /usr/share/doc/bzr-builddeb/README.gz [12:20] thx [12:20] or perhaps .bzr-builddeb/default.conf depending on whether you want it to be overridden by user configuration [12:21] hmm, didn't wokr [12:21] Building the package in ../build-area/udev-135, using dpkg-buildpackage -rfakeroot -uc -us -S [12:21] quest ubuntu% cat .bzr-builddeb/default.conf [12:21] [BUILDDEB] [12:21] source-builder = dpkg-buildpackage -rfakeroot -uc -us -i'(?:/|^)test(?:/|$)' [12:21] ... at this point you need james_w :) [12:22] try local.conf instead, it's higher-priority [12:22] and surely source-builder needs -S [12:22] err, right [12:23] local.conf worked [12:24] * Keybuk is still said you can't put -i in debian/control somewhere :p [12:25] mm, yeah [12:26] since if anyone checks out this udev branch, and tries to build it [12:26] dpkg-source will simply spazz out [12:26] doko_: So apart of relibtoolizing, do we need to change djvulibre or the toolchain or both? [12:27] lool: I uploaded a patch just adding the two libs in djvulibre [12:27] doko_: No relibtoolizing? [12:27] I don't think it's needed [12:29] Keybuk: I think the idea of .bzr-builddeb/local.conf is that you can commit it to the branch so that stuff works as long as the other person is using bzr bd [12:30] I thought that was what default.conf was for? [12:31] the local in local.conf just means that it overrides ~/.bazaar/builddeb.conf [12:31] i.e. package-local - I don't think it means that it's supposed to be local to your system [12:31] although I might be corrected by somebody who knows bzr-builddeb better :) [12:41] where might i find the sync status page, for packages synced from debian during jaunty [12:42] we don't really have such a thing? [12:42] when we 'sank' would have that been against experimental? [12:42] no, from unstable generally [12:43] thats probabally what i meant [12:43] is there an easy way to find out which version of something is in debian unstable [12:44] packages.debian.org [12:44] thanks [12:44] (or https://launchpad.net/debian) [12:44] reliant on the LP import continuing to work of course :) [12:44] cjwatson: it's a shame the /ubuntu/ doesn't link to that ;) [12:45] though this all reminds me [12:45] I think it'll be able to once we're doing "native" syncs from Debian [12:45] * Keybuk does an autosync [12:45] i.e. just copying the publishing records across from /debian to /ubuntu [12:45] there are a couple of bugs left to fix first though [12:46] ooh, firefox-3.1's location bar shows you the expansion of keyword bookmarks as you type [12:46] that's actually quite cool [12:57] cjwatson: Heh I requested this feature pre 3.0, the patch had been proposed by someone way before 3.0 but it took so long to reach a release! [12:57] https://bugzilla.mozilla.org/show_bug.cgi?id=392143 [12:57] Mozilla bug 392143 in Location Bar and Autocomplete "show keywords as url bar autocomplete choices" [Enhancement,Verified: fixed] [12:58] cjwatson: does it make sense for me to get rid of the seed files that kubuntu doesn't need? *-server and virt-host? [13:05] Riddell: probably, yes [13:05] Riddell: as long as you don't try to merge from ubuntu [13:06] Riddell: (if you do, you'll get conflicts; you shouldn't really need to merge from ubuntu any more anyway) [13:11] cjwatson: does the installer do anything with the fuse group? [13:14] Keybuk: it used to, but not as of intrepid [13:14] see user-setup 1.20ubuntu7 changelog [13:15] why did we stop? [13:16] dynamic ACL stuff? [13:16] hmm [13:16] upstream udev just sets fuse to 0666 :p [13:18] dynamic ACL apparently, yes [13:26] lool: djvulibre built on armel [13:32] Cool === Arby_ is now known as Arby === thekorn_ is now known as thekorn [13:48] hello [13:49] I want to make a patch for a source package (with cdbs-edit-patch); and was wondering: should the patch include the changes to the changelog file? [13:49] or should a patch only contain the actual code changes? [13:50] the patch should nopt include changelog stuff [13:51] basically, use a patch for anything outside appname-1.0/debian/ [13:51] changelog is in debian/, so no patch [13:51] I think he means upstream changelog [13:51] (no, don't bother) [13:51] oh, that too [13:51] ok, thanks [13:51] morning' iain [13:51] oliver_g_, The patch created with cdbs-edit-patch should change things only outside the debian/ directory. Including the changelog entries in a submitted patch is welcome. You'd likely find #ubuntu-motu a better channel for these questions. [13:51] 'ow do? [13:52] work is pointless today. i'm just playing civ4 [13:52] not started your hols yet? [13:52] nah [13:53] persia: ok, thanks for the #ubuntu-motu hint [14:09] Will a buildd admin please rescore python-qt4 on armel (I'm not sure if my previous message went through) === pgraner_ is now known as pgraner_lt [14:41] why is boost1.37 not yet built, or is not yet processed? NEW package in Debian [14:47] doko_: syncing of new packages is manual and sporadic. I've synced it now [14:53] cjwatson: thanks, will other packages be processed as well before our merge window closes? [14:54] doko_: yes - there are only 55. In any case the merge window does not "close" on 25 December; that's just when every package should have been merged at least once. You can quite happily merge stuff after that === azeem_ is now known as azeem [15:16] doko_: all processed now [15:23] cjwatson, in re the system-cleaner upload: my usual suspects (mvo, james_w) are on holiday, could you upload the new package and if so, do you prefer to do it from bzr (I've pushed the changelog change), or shall I upload a .dsc to my ppa? [15:24] bzr is fine [15:24] url? [15:24] cjwatson, bzr+ssh://bazaar.launchpad.net/~systemcleaner-hackers/systemcleaner/trunk.deb-packaging/ [15:24] I need to tweak things in LP to make lp:system-cleaner work, I guess [15:27] liw, hi! You need to tell LP that you're using code, in the "Change Details" link. Then, under the code tab, it will prompt you to specify a development focus. [15:27] that's when the lp:projectname magic works :) [15:28] beuno, there's a separate packaging branch; can I make lp:foo/trunk and lp:foo/trunk.deb-packaging both work? (I think I've seen other projects do tha) [15:28] liw: there's already a 1.10.4-0ubuntu2 in intrepid-proposed - you can't reuse that version number [15:29] cjwatson, er, oops. [15:29] liw: looks like maybe you forgot to merge that into trunk.deb-packaging? [15:29] liw, I *think* that only works if it's linked to a series. [15:29] cjwatson, yeah, I'll need to fix that, hang on === hyperair1 is now known as hyperair [15:52] cjwatson, ok, that took a while, I had to hunt down the right branch and do a phone call, but I've pushed the branch again, if you want to try again [15:53] cjwatson, in other words, I merged the SRU changes [15:53] cjwatson: what do you know about /dev/net/tun ? [15:54] liw: thanks, uploaded [15:54] cjwatson, thank you [15:55] Keybuk: at what level? I remember it showing up hardcoded in a number of places (wasn't it in links.conf?) and I know approximately what it's used for [15:55] can you see any reason it shouldn't be world-writable? [15:58] Keybuk: Documentation/networking/tuntap.txt says it's ok [15:58] Set permissions: [15:58] e.g. chmod 0666 /dev/net/tun [15:58] There's no harm in allowing the device to be accessible by non-root users, [15:58] since CAP_NET_ADMIN is required for creating network devices or for [15:58] connecting to network devices which aren't owned by the user in question. [15:58] If you want to create persistent devices and give ownership of them to [15:58] unprivileged users, then you need the /dev/net/tun device to be usable by [15:58] those users. [16:00] sounds fair [16:31] liw: oh BTW the changelog entry for system-cleaner wasn't quite accurate - Soyuz didn't remove all Architecture: all packages, only those where an upload was copied from a post-release pocket in an earlier release (e.g. intrepid-proposed -> jaunty) [16:35] cjwatson, oh, ok, then I misunderstood [16:36] robbiew, about the https://blueprints.launchpad.net/ubuntu/+spec/package-license-tracking blueprint: should it be assigned to someone? [16:37] it should indeed [16:38] liw: are you volunteering? :P [16:41] trying to find a bug i commented on friday... i didn't subscribe. anyway to view my own history of comments? [16:41] robbiew, well, no :) most of the effort is going to be in the discussions with Debian to finish the spec for the format, and Steve was going to do that [16:41] oh there we are. commented bugs. [16:42] robbiew, but if I'm writing the library, I'll happily co-author the Ubuntu spec with Steve [16:42] Okay. I have run into #295859. Does anybody think my two comments near the end accurately describe the problem? [16:42] bug #295859 [16:42] Launchpad bug 295859 in update-manager "Upgrade Manager crashes during upgrade from Kubuntu Hardy to Intrepid" [Undecided,New] https://launchpad.net/bugs/295859 [16:43] benc: According to the last comment in bug #278188, irda has been fixed in 2.6.28 rc9. Would it be possible to get the fix backported into intrepid? [16:43] liw: ok, thnx [16:43] Launchpad bug 278188 in linux "irda broken on Thinkpad T23 with 2.6.27-4-generic, works with 2.6.24-16-generic" [Undecided,New] https://launchpad.net/bugs/278188 [16:43] * robbiew assigns to Steve [16:43] liw: ^ [16:44] ion_: file a bug report with a patch and let smb know [16:44] robbiew, ack [16:45] benc: smb? [16:46] ion_: stefan bader, he handles the stable releases [16:46] benc: Alright, thanks [16:59] I swear that the Mini 9 keyboard was made especially to punish me [17:02] Keybuk: too small? [17:02] robbiew: too big! [17:03] heh [17:03] robbiew: also it kept coming up without a / key so he needed to run KEYBUK.EXE [17:05] how do I tell network mangler to leave the ethernet connection _UP_ and _ALONE_, while still letting it mangle the wireless? [17:06] lamont: in intrepid? doesn't it do that by default? [17:06] By using the RF kill switch when you don't want it to switch to wireless. [17:06] robbiew: small, cheap, crappy [17:06] Keybuk: intrepid. something keeps downing the interface [17:06] Spads: keybuk.com! get it right! :p [17:06] dude, you got a dell [17:06] lol [17:06] lamont: probably postfix [17:06] Keybuk: yeah I figrued it was a COM after I hit enter [17:07] ScottK: no no. I have the wireless up and running for upstream bandwdith, and am using the ethernet for some local downstream hackery (configuring a couple of devices over the wire) - and I want it to leave my downstream intreface the hell alone [17:08] Ah. Dunno about that. [17:08] afk [17:09] persia: Can I do the lash merge? [17:09] persia: Oh wait, you did [17:26] cjwatson: so should you be the assignee for the archive reorganisation? [17:30] 7W 31 [17:30] sorry [17:30] cjwatson: For reference: http://blueprints.launchpad.net/ubuntu/+spec/archive-reorganization [17:52] robbiew: I guess so [17:53] cjwatson: such enthusiasm! :P [17:54] :-) just haven't seen the output of the UDS session yet [17:54] but yes, I think it ought to be me at least for coordination purposes (even though the implementation work needs to be in several places) [17:55] right [17:56] well...the videos are there for your enjoyment [17:56] heh [18:00] cjwatson: hmm...I guess having the same person as assignee and approver is problematic from a checks-and-balances point of view [18:12] robbiew: I agree [18:13] * robbiew assigns himself as approver [19:40] directhex: Broken armel chroot was repaired and this buildd is back in the pool === RainCT_ is now known as RainCT [20:16] tseliot: I'm reading your specs right now :) === asac_ is now known as asac === krusaf|bnc is now known as krusaf [20:51] rickspencer3: thanks === fta_ is now known as fta [22:34] Template #1 in /var/lib/dpkg/tmp.ci/templates has a duplicate field "template" with newvalue "dexrex/ToS-accepted". Probably two templates are not properly separated by a lone newline. [22:34] i don't get this? [22:34] i have it set up like the parallels templates [22:34] from the partner pool [22:35] bbs: can you put the full dexrex templates file somewhere I can see it? [22:36] cjwatson: sure [22:36] thx [22:36] second [22:37] http://dpaste.com/101758/ [22:39] http://dpaste.com/101759/ [22:39] ^^ preinst file [22:39] don't care about preinst [22:40] bbs: I suspect that the line just before "Template: dexrex/ToS-accepted" is not really empty. Maybe it has one space in it? [22:40] it's hard to tell for sure from a pastebin, as the process of pasting into a pastebin sometimes hides this kind of thing [22:40] you might be able to turn on special characters or something in your editor to see for sure [22:40] lol [22:40] :) [22:40] thats funny [22:40] i'll take a peek [22:40] i mean it just keeps yelling atm [22:41] cjwatson: whats the easiest way to do a single binary install [22:41] using an "install" [22:41] file [22:41] with CDBS [22:41] or what? [22:41] please don't use the Enter key as punctuation [22:42] perhaps try reading something like https://wiki.ubuntu.com/PackagingGuide ? [22:42] i did [22:42] debian/*.install (or debian/install) files are a feature of debhelper rather than of CDBS as such, although CDBS does use debhelper [22:42] read 'man dh_install' [22:42] that Guide is not sufficient and does not contain barely anything about binary files [22:42] why is it important what the files contain? [22:43] ok i will take a look [22:43] all that debian/rules and the things it calls needs to worry about is putting the files in the right place, basically! [22:43] yes, exactly :) [22:43] whether they're text files or binary files normally doesn't matter [22:44] anyway, for mentoring on packaging creation, please use #ubuntu-motu [22:44] cjwatson: i've tried there -- its a wasteland in there for a few hours now [22:44] thanks for your time.. [22:47] Riddell: I thought I'd recommended that you stop merging the Kubuntu seeds from Ubuntu - isn't it just creating confusion? (such as the recent CD build failure) [22:47] Riddell: (if it's really useful, then I guess ...) === Seeker`_ is now known as Seeker` [22:49] Riddell: (I've fixed the seed bug causing that CD build failure) === jussio1 is now known as jussi01 [22:55] Would people prefer the default host for dput to be local or something bogus to help prevent accidentally uploads to Ubuntu or would people prefer that it remain Ubuntu? [22:56] Having to specify Ubuntu when uploading to it shouldn’t be too hard. [22:56] * cody-somerville nods. [22:56] hi [22:56] cody-somerville: I always change it to something bogus [22:56] ion_, thats my thinking as well [22:56] whats the deal about kenrel -11 [22:56] pochu, me too [22:57] it broke laptop stuff for me [22:57] okay, sounds good. [22:57] suspend does not work anymore [22:57] and it starts with the lowest screen brightness Oo [23:02] Dec 22 23:47:23 burning-studio kernel: [ 19.049472] asus-laptop: Brightness ignored, must be controlled by ACPI video driver [23:09] cody-somerville: it's not like you can accidentally *successfully* upload to Ubuntu unless you're an Ubuntu developer and the top line in debian/changelog lists an Ubuntu suite. I don't see the dput default as a problem [23:10] cody-somerville: I'm not sure I ever recall an "argh, I accidentally uploaded this to Ubuntu" incident [23:10] cjwatson, I hear it from MOTUs all the time ;] [23:10] Sounds like that could be pretty easy if you use dch [23:10] * directhex uploads cody-somerville to experimental [23:11] : O [23:12] take THAT! [23:12] If any core-devs would like to sponsor, see bug #310754 :) [23:12] Launchpad bug 310754 in dput "Merge dput 0.9.2.36 from debian unstable (main)" [Low,Triaged] https://launchpad.net/bugs/310754 [23:12] cody-somerville: none of them seem to come to the archive admins saying "could you please reject this?" [23:12] cjwatson, Sure [23:13] cjwatson, If you'd like, you're welcome to sponsor my upload and revert that change if you'd like. I don't feel strongly about it. [23:13] I just know for myself, I do set it to something bogus because I *would* be coming to ask [23:13] at this time of night I think somebody else can do it :) [23:13] ;] [23:13] Alrighty. I'm going to go enjoy some dinner. bbiab [23:13] cjwatson, btw, do you know anything about valgrind? [23:13] * directhex wonders if an archive admin can find time in between eating mince pies & rockin' around the christmas tree to do a couple of syncs [23:14] cjwatson, it won't compile on Jaunty due to depending on glibc version no higher than 2.7 (and we have 2.8) [23:14] cjwatson, although the NEWS file seems to suggest that support for 2.8 was added [23:15] cjwatson, so I'm wondering if its safe to modify the configure.in file to allow it to compile with 2.8 [23:17] cody-somerville: not at that level - if you're wondering if it's safe, I'd suggest mailing upstream [23:17] * cody-somerville nods. [23:17] cjwatson, Thanks. Will do. [23:17] * cody-somerville is off for now. bbiab (for real now) :) [23:50]