[00:43] k question, lets say ive made a program that would do nice in the ubuntu repository, what should i doe or who should i contact to get it there === pmf__ is now known as ember [00:46] warsocket: #ubuntu-motu [00:50] k [01:21] slangasek: Hi, when you have time, can you please review the merge for gnupg? bug #225005 [01:21] Launchpad bug 225005 in gnupg "Please merge gnupg 1.4.9-2 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/225005 [02:49] * Hobbsee wonders how to disable the "feature" of having no shut down button, without going to gdm first. [02:52] Hobbsee: Surely that's a lie - I've got a shutdown button. [02:52] Admittedly, it doesn't actually _shutdown_, but it's certainly a button, marked shutdown :) [02:52] Mostly it freezes gnome-panel. [02:53] RAOF: intrepid? [02:53] Hobbsee: Yah [02:53] ah. there's a separate shut down one [02:53] Right. [02:54] It's reverted to upstream GNOME's shutdown/logout thingy. [02:56] RAOF: thanks [02:56] It's broken for me, though, so it's not _really_ helpful :) [02:57] aww [02:59] RAOF: if you're in an answering mood, how do i make compiz work again? [03:00] How's it broken? [03:00] /usr/bin/compiz.real (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0" [03:00] /usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0 [03:00] Window manager warning: Workarounds for broken applications disabled. Some applications may not behave properly. [03:00] Ah. Turn off metacity's compositor. [03:00] (from a compiz --replace &) [03:00] Metacity's compositor doesn't release the CM selection in the way that compiz would like it to. [03:01] ahhh [03:01] /apps/metacity/general/compositing_manager or somesuch. It's changed name at some point in the past. [03:01] found it, thanks [03:02] That should now allow you to experience other bugs in Compiz :) [03:02] / mesa / X [03:02] like the fact taht some of my settings have been lost, and my metakeys aren't working again? [03:02] well, some of them [03:04] Dunno. I'm only just playing with compiz again now that there's an nvidia-glx to test. [03:21] and the workspaces have gone back to 2 even though i've chosen 4! [03:22] alex-weej: yeah, it seems to have wiped all the settings. [03:23] RAOF: right. got it all working, except that it still doesn't start by default. [03:23] and gnome-panel's being tempramental, again [03:25] mmm...fire :) [03:25] RAOF, how's the experience going for the nvidia-glx new way of doing things (except for jockey not being there yet)? [03:30] superm1: Basically flawless. Installing nvidia-glx-177 works fine, nvidia-xconfig worked for me. [03:32] cool, that's good === Pici` is now known as Pici [03:35] superm1: what's new? [03:36] i'm using 177 beta on intrepid now cause jockey didn't want to work [03:36] (and it's not in lrm) [03:36] alex-weej, the way that everything is packaged has changed with it not being in LRM, so i just was curious to make sure that there was no major problems coming up using the nonlrm packaging [03:37] alex-weej, you weren't using the .run file from nvidia's website right? [03:37] i was [03:37] and it worked [03:37] shouldn't it have? [03:38] Well, it should have. But the nvidia-glx-177 package would've made it easier :) [03:38] alex-weej, the nvidia-glx-177 should be able to handle the upgrades from kernel to kernel properly [03:38] so that's the important part to make sure continues to work [03:39] that's a good point... i've had loads of kernel updates but not had to rebuild === asac_ is now known as asac === jamesh_ is now known as jamesh [07:11] hello all, im trying to help someone here: http://ubuntuforums.org/showthread.php?p=5427518 . How would I go about changing the version number assigned to the package when building using the process described there? [07:15] * Hobbsee wonders why they don't just purge tracker and be done with it. [07:16] ah [07:22] yeah doesn't work unfortunately [07:25] can anyone point me in the right direction [07:33] edit debian/control [07:37] Hobbsee: You mean debian/changelog, right? [07:38] er, yes, that. [07:38] * Hobbsee wonders where her brain went. [07:42] and just add another version in there? [07:42] im not on my ubuntu machine at the moment so i can't try this myself [07:46] ryanhaigh: Correct. "dch -i" is likely to be the easiest way to get a well-formed changelog entry. [07:58] Good morning [07:58] asac: just mention it in the MIR [08:08] heya pitti [08:10] * pitti hugs Hobbsee, hey! [08:11] :D [08:12] hiya Hobbsee, pitti [08:14] * StevenK waves, jetlagged [08:14] jet lag is overrated. [08:16] Not right now, it isn't. [08:18] hey Mithrandir! [08:19] moin === mdz_ is now known as mdz [09:04] pitti: yep. did that. https://wiki.ubuntu.com/MainInclusionReportPcsc-Lite [09:05] pitti: Could you poke at why twin failed to upload to every arch it built on, bar lpia? [09:05] pitti: http://launchpadlibrarian.net/16198199/upload_673575_log.txt is the upload log [09:06] asac: MIRs are bugs ... :-) [09:08] bug 249850 is reported. Can you fix it please? :) [09:08] Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850 [09:08] StevenK: err its a bug as well [09:08] bug 250245 [09:08] Launchpad bug 250245 in pcsc-lite "[MIR] - pcsc-lite sources + partially binary promotion to main" [High,Confirmed] https://launchpad.net/bugs/250245 [09:09] asac: Heh, fair enough [09:10] ;) [09:13] StevenK: ugh, no idea; I'm afraid that's a cprov problem [09:25] asac: I'm curious... Do you specifically want to keep pcscd out of main or do you just "not care"? [09:26] soren: the latter. i just need the lib to build wpasupplicant in a way that you can install pcscd and then get smart card support [09:26] asac: Ok, cool. [09:49] StevenK: twin does hardcode the binary deb versions in debian/rules. twin 0.5.1-3ubuntu1 build packages with the versions like twin 0.5.1-3. [09:50] StevenK: don't forget to also update the versioned dependency of libtw0-dev in debian/control [09:51] What the?! [09:51] * StevenK digs [09:52] Oh, for crying out loud [09:52] There's a substvar for this! [10:05] geser: It gets worse. The version is hard coded in debian/rules. [10:06] Which is about the worst crack-cut-with-washing-powder I've ever seen [10:07] is there a better way to produce binary debs with a different version than the source? [10:08] Yes. [10:08] Don't do that. [10:08] geser: Seriously, it's complete crack [10:09] sometimes it's necessary [10:09] cf. gcc-defaults [10:10] you can fish out parts of the source version and do arithmetic if necessary [10:10] Exactly. [10:10] Wield dpkg-parsechangelog and such. === hunger_t_ is now known as hunger [10:22] pitti: Okay, that twin failure is a package bug [10:22] StevenK: yep, saw it in backscroll [10:22] I feel so dirty [10:23] * StevenK will nail the patch to the Debian BTS. [10:23] Severity: important. Maybe serious === rraphink is now known as raphink [10:47] hmm. why did rarian-compat get demoted back to universe? [10:47] * cjwatson puts it back in main [10:49] seb128: Fix for the virt-manager hypervisor selection bug just uploaded.. [10:50] soren: ah, cool, thanks [10:51] seb128: Any time :) [11:51] Anyone here an archive admin who can answer a quick question or two [11:51] NCommander: yes, some; just ask your question, please [11:52] I have codeblocks sitting in the NEW queue; it has a lintian override, which I forgot to document; should I simply wait for the package to be REJECTed (as it would be in Debian), or is it possible it can be put through, and then get a debdiff applied to it ASAP? [11:53] NCommander: you can just upload a new package if you want [11:53] NCommander: however, an underdocumented lintian warning is not generally a reason for outright rejection [11:54] unless it overrides something really bad [11:54] It overrides script-not-executable [11:54] (lintian is detecting a code parser as a script) [11:54] ah, that's usually scripts in /usr/share/ with a shebang [11:55] NCommander: I wouldn't reject a package due to that [11:55] THere is a second issue which I caught just a few hours ago [11:55] Upstream shipped a Debian folder [11:55] When I ran update-maintainer, the person who packaged it ended up in Original Maintainer [11:55] (my name is in the changelog) [11:55] I'm not sure if that's right, or not [11:58] update-maintainer is for use when making Ubuntu modifications to packages that also exist in Debian, where the prior consensus has been that Debian maintainers should not be listed in Maintainer of Ubuntu-modified packages [11:59] when making modifications to packages that originated elsewhere, you ought to find out whether that's what the original packager wants [12:00] cjwatson, it was a mistake that it went with that Original-Maintainer; I had intended to switch it to myself, but obviously that didn't quite happen [12:00] (I redid most of the Debian folder, so while I do credit the creator of the upstream folder in copyright, I'd think I should be there) [12:15] you're allowed to edit debian/control by hand rather than using update-maintainer if that's what's needed ;-) [12:16] it's a human-editable file [12:16] (BTW, in Unix we call them directories rather than folders) [12:16] in the case of what you *should* do with Original-Maintainer, I don't think it's terribly important either way, and certainly wouldn't be cause for a rejection [12:49] wrong channel [12:49] :) [13:29] moin [14:13] is there any way of tuning/inspecting gvfs? its sftp performance seems to be shockingly slow [14:13] I can scp a file at line speed (10 [14:14] err, let me try that sentence again ;) [14:14] I can scp a file at line speed (10MB/s). using nautilus's sftp claimed about 1MB/s, cp'ing to ~/.gvfs/blah/ and inspecting with iptraf suggested it was doing <200K/s [14:15] <\sh> Ng: if you do a simple sftp via sftp client...do you get the same? [14:16] \sh: yep, ~10MB/s [14:16] <\sh> Ng: strange, I always had the same issue with winscp from windows -> to sftp enabled servers (linux, sun) ... sftp was always slow for me..that's why I try to avoid sftp in general [14:16] (wired ethernet on a 100Mb fibre to the network the remote machine is on, so I'm pretty sure it's not network related or wireless nonsense) [14:18] <\sh> scp was always faster...could be me or something weired on the network those days... [14:18] this is over an internal network, effectively [14:18] <\sh> Spads: yes :) [14:19] I'm just curious if it's known that gvfs is slow at this stuff, or maybe if I can change block sizes it's sending or something [14:20] Ng: "this stuff" being? [14:21] seb128_: I'm scping stuff to one of our machines and getting pretty much full wire speed (10MB/s) with scp and sftp console clients. nautilus via gvfs sftp claims to do ~1MB/s and if I use iptraf to inspect my eth0 when I'm doing a regular cp to the ~/.gvfs/ location it's more like 200KB/s [14:21] I would expect some overhead, but that seems a bit odd [14:22] Ng: the .gvfs location is a standard fuse mount [14:24] seb128_: any suggestions for where I could be looking to figure out why it's slow? [14:25] Ng: http://bugzilla.gnome.org/show_bug.cgi?id=523015 for gvfs, dunno about fuse [14:25] Gnome bug 523015 in sftp backend "Implement sliding window based upload operation" [Normal,New] [14:25] Ng: gvfs = when you use the ssh backend to do the copy, ie what nautilus is doing [14:26] seb128_: ok. I'm entirely happy to ignore the fuse end of things, in which case we are only losing one order of magnitude ;) [14:27] Ng: also compare to command line sftp and not to scp if you want fair numbers ;-) [14:27] I did, it's also pretty much full line speed [14:27] there's a little variance which is probably because the line isn't exclusively mine, but 9-10MB/s [14:28] ok, that's probably somewhat along the line of the bug I pointed then [14:29] though your line is probably not a low latency one [14:29] seb128_: generally, sftp will be faster than scp, since scp has some ickiness in the buffering algorithms. (I think?) === seb128_ is now known as seb128 [14:30] Mithrandir: possible, anyway in this case that's clearly gvfs not doing an optimal job [14:31] seb128: the latency is pretty low from here, we have fibre to the network the other machine is on, so we're talking a millisecond or so [14:32] Ng: ok, so I don't know about other bug and it would probably require debugging from somebody knowing the code well enough [14:32] hello :) [14:33] cjwatson: which installer component puts the user into the initial groups? (audio, video, etc.)? I'd like to drop some (intrepid-device-permissions) [14:33] seb128: having 64k blocks from that patch would probably be enough in most instances, and since it was applied in march maybe we alreayd have that? [14:33] bugzilla fails at making this stuff easy to find out ;( [14:35] Ng: yes, it's already in hardy and intrepid [14:35] seb128: hmm, a quick google suggested libglib 2.17, but hardy has 2.16? [14:38] but our 2.16 does indeed have a 1024*64 buffer [14:39] Ng: http://svn.gnome.org/viewvc/glib?view=revision&revision=6736 [14:39] yeah, I just grabbed the glib hardy source and that patch is definitely in it :/ [14:42] .join #ubuntu-za [14:42] baah [14:45] pitti: user-setup [14:45] cjwatson: ah, thanks [14:46] pitti: I'd appreciate it if you kept an eye on bug 188759 and bug 205563 while doing so [14:46] Launchpad bug 188759 in user-setup "install user doesn't belong to all "administrative" groups" [Undecided,New] https://launchpad.net/bugs/188759 [14:46] Launchpad bug 205563 in user-setup "User created on installation does not belong to the scanner group" [Undecided,New] https://launchpad.net/bugs/205563 [14:46] cjwatson: right [14:46] cjwatson: btw, related to that spec, is it easily doable to not create the cdrom fstab entry for desktop installs? [14:47] no. apt-cdrom needs it [14:48] hm, too bad [14:48] attested by e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464899 [14:48] Debian bug 464899 in apt "apt-cdrom incompatible with desktop automount" [Normal,Open] [14:49] I've said this pretty much every time somebody's asked about that fstab entry in the last four years, but none of the people who want it gone seem to have fixed it yet ;-) [14:49] seems I keep forgetting about apt-cdrom then [14:50] anybody knowing about dtd registration and use there who could have a look to http://paste.ubuntu.com/28998/ and let me know if that seems correct? [14:50] that's a copy of the scrollkeeper dtd to rarian-compat and a registration similar to what scrollkeeper is doing [14:50] pitti: see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282344 [14:50] Debian bug 282344 in apt "apt-cdrom: please change default CD-ROM mountpoint" [Wishlist,Open] [14:50] (which is a more useful bug) [14:51] cjwatson: ah, however, the fstab entry doesn't require the user to be in the cdrom group [14:51] since nowadays we get ACLs on /dev/ storage devices, we can drop that [14:52] (for raw-reading CD-ROMs) [14:52] I store what I know about groups in the base-passwd documentation [14:52] but, indeed, cdrom and floppy don't seem to be used for that [14:53] pitti: the dialout comment about monetary consequences is a little odd, given that it's the first user and they could probably just pick up the phone ;-) [14:53] though I suppose there's the spyware case, if that's what you meant by dialer programs [14:53] right [14:54] it's allegedly a bit far-fetched, since I didn't see actual programs which did that under Linux yet [14:54] polkit-gnome-authorization would have a hard time dealing with minicom, wouldn't it? [14:54] but they had been a PITA under Windows [14:54] I think we should take some care with the serial port access programs we ship to avoid just pushing lots of people towards sudo [14:55] cjwatson: that just controls ACLs on /dev/ttyS, so minicom is not a problem [14:55] but yeah, I won't drop dialout until we actually have a replacement [14:55] oh, it does? it has no manual page so I couldn't tell [14:55] cjwatson: s/does/is planned to/ :-) [14:56] cjwatson: for now I plan to drop cdrom, floppy, plugdev, audio, video, dip [14:56] and keep dialout, adm, fuse [14:56] bit of a horror show of a UI though [14:57] cjwatson: how do you mean? [14:57] plugdev> awooga that's used by other bits of the installer [14:57] polkit-gnome-authorization? it's one of the most complex UIs I've ever seen :) [14:57] came up in Ubuntu reviews too [14:57] cjwatson: what's behind the "enable modem access" checkbox shouldn't matter to the user? (PolKit call or add group) [14:57] oh, if there's a cleaner wrapper around it, sure [14:58] cjwatson: ah, right; yes, that's known upstream, too, and being worked on [14:58] partman-basicfilesystems/fstab.d/basic:64: # base-passwd defines gid 46 as group plugdev [14:58] partman-basicfilesystems/fstab.d/basic:74: # base-passwd defines gid 46 as group plugdev [14:58] used for giving people the ability to see the contents of FAT/NTFS filesystems [14:58] and write to them, come to that [14:59] cjwatson: the installer cares which groups the initial user is in? [14:59] yes [14:59] s/cares/& about/ [14:59] or, rather, if they aren't in plugdev, they won't be able to read/write those filesystems [14:59] which will be a fairly serious regression [14:59] hm, how odd [14:59] pitti: not that odd - with the way FAT/NTFS permissions work, it has to just give access to a Unix group [14:59] I wasn't aware that these parts of the installer run as the target user instead of just in the installer context [14:59] they don't [15:00] but the result, post-install, will be that the user cannot read from or write to those filesystems [15:00] the alternative is to give access only to root (inconvenient) or to a specific user (doesn't allow permissions to be extended) [15:01] at the time, plugdev was a pretty reasonable choice for that [15:01] hm, I still don't understand, I'm afraid [15:01] we put this in fstab: [15:01] echo "$path" "$mountpoint" vfat $options,umask=007,gid=46 0 1 [15:01] I haven't had plugdev membership for ages, and no problem with fat/ntfs drives [15:01] if the user is not in gid 46 then they will not be able to use their Windows-formatted data partition [15:02] then you have yours set to non-default permissions [15:02] oh, that, I see [15:02] this is for ones that the user explicitly mounts in a particular place using the partitioner [15:02] cjwatson: well, I never statically add windowsish partitions to fstab [15:02] rather than filesystems that are automatically mounted [15:02] you don't, but it's not uncommon to want them on e.g. /data rather than /media/blah [15:02] right [15:02] and people do do that [15:03] it's not the absolute novice user case, but it's within what I'd consider to be relatively normal use of the desktop CD [15:03] hm, seems we cannot get rid of either (fstab/groups) without getting rid of the other, too [15:03] is plugdev doing any harm? just leave it there :) [15:04] well, seems I need to for this round then :) [15:05] I do understand the rationale, and we shouldn't use plugdev in similar ways for new purposes [15:09] group 'sambashare'? that's new to me [15:10] ah, bug 238224 [15:10] Launchpad bug 238224 in user-setup "[PATCH] Initial user should be added to sambashare group if it exist" [Medium,Confirmed] https://launchpad.net/bugs/238224 [15:14] Can any of the archive admins please process batik from 'NEW'? I would like to start looking into the packages that depend on batik and hence never built before. [15:17] seb128: hi, seen my email? [15:21] norsetto: hi, I had a quick glance on the subject but that's all, I'm still busy catching up on other things after 2 weeks travelling, is there any hurry? [15:23] seb128: well, if you could say yes or no soonish would be nice otherwise the guy will be kept hanging [15:35] to my surprise, "apt-cache search cogito" does not find any cogito package in hardy .... am i looking in the wrong place? [15:36] mkrufky: no. cogito is dead. [15:36] dead?!? [15:36] cogito always accepts my malformed git commands.... now i have to learn how to use git PROPERLY ??? [15:36] :-P [15:37] jcristau: can you recommend another tool? [15:37] git [15:37] meh [15:37] ok, thanks [15:38] mkrufky: for additional informations, see debian 436248 [15:38] Debian bug 436248 in ftp.debian.org "RM: cogito -- ROM; FTBFS, orphaned upstream, superseded by git-core" [Unknown,Closed] http://bugs.debian.org/436248 [15:38] thank you, DktrKranz [15:39] anybody else get hit with smenara ? [15:41] found this nonsense in root history http://pastebin.ubuntu.com/29004/ [15:42] tar file has a port scanner, a password list, and a replacement binary for ssh and sshd :/ [15:43] hwilde: take a look in /tmp/ for any suspicious directories [15:44] I looked around couldn't find anything [15:44] hwilde: especially directories whose name is comprised of >= 1 whitespace chars [15:44] but when I tried to ssh it gave a bunch of bogus ssh2 errors [15:44] so I removed and purged ssh, sshd, changed all passwords, reinstalled [15:44] fine now [15:44] but I couldn't find anything out on the net related [15:44] geser: yes, on my todo list [15:44] i got hit by something a few months ago.... actually, it was a server that was powered down for a few years... i think i got attacked BEFORE i took it down, and only noticed a few months after bringing it back online [15:45] so if it's not a widespread thing on the net, I am thinking it was someon internal :/ [15:45] hwilde: also look around for suspicious cron deamons [15:45] any users logged in that arent u [15:45] not without sshd :) [15:47] look anyway ... if there are false cron daemons running, it can spawn processes without using sshd [15:48] nothing in cron [15:48] no users logged in [15:48] no way they could I removed --purge sshd [15:49] i dont mean actual users [15:49] ugh [15:49] just ps aux and see if anything looks wierd [15:49] my users logged in, i means any tasks running that may or may not be malicious [15:49] ^ s/my/by [15:50] anyway, im just making suggestions... i got hit pretty badly, but it was on a very very old system runnign a 2.4 kernel that i did not keep up to date with security fixes [15:50] it was actually rather entertaining tracking it down [15:51] dbus-daemon --fork --print-address 24 --print-pid 26 --session [15:51] that looks a bit odd [15:51] /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=28 [15:51] pretty sure I don't need htat either [15:51] but they don't smell malicious [15:52] the scripts don't even look like they work [15:52] seems like a junior hack attempt [15:52] but why would it just hit me and no hits on google [15:52] must have been an inside job [15:52] keep in mind that the hacker might want you to THINK that [15:53] some rootkits change binaries or even modify kernel so that their processes do not show, so there is no easy way to be sure everything has been purged (and whoever did it does not have access anymore) short of complete re-install [15:54] “hacker” – /me cringes [15:54] rkhunter and chkrootkit might give some diagnostics. [15:58] Trewas: (FWIW boot from read-only media and verify md5sums plus a manual check of any other unwanted files would normally be sufficient, though I'd only advise it to a competent person) [15:58] james_w, seb128: our system-tools-backeds still installs /etc/dbus-1/event.d/70system-tools-backends; to me it seems entirely obsolete since /usr/share/dbus-1/system-services/org.freedesktop.SystemToolsBackends.service starts it automatically; do you see any problem with that? (works fine for me) [15:58] james_w: (currently processing your mergre) [16:00] pitti: any problem with what? having a duplicate way to start it? seems not optimal but I don't think it creates bugs either [16:04] cjwatson: right, if you have the known good md5sums available... gathering them by hand takes some effort and debsums at least does not know nearly all packages [16:04] seb128: it's rather about having the s-t-b daemon running all the time, needlessly [16:05] rkhunter seems pretty cool... but it just says Checking /dev for suspicious file types [ Warning ] [16:05] which ones are the suspcious file types :/ [16:05] [11:04:04] /dev/shm/pulse-shm-2415330484: data [16:05] hmmm [16:06] pitti: not sure what the "that" refers to in what you wrote before but if you suggest removing the event.d script I think that's a good idea [16:07] seb128: ok; will do that then, merci [16:07] cool, thanks [16:08] Trewas: debsums does know nearly all packages, although it omits a few [16:09] cjwatson, isn't there an automated way to do that from livecd [16:09] hwilde: is there? [16:09] it's news to me if there is a simple way [16:10] http://lintian.debian.org/tags/no-md5sums-control-file.html lists 221 packages, which is a rather small minority [16:11] I guess you would have to build the checksum list and put it on an external hd first [16:11] then tell the livecd to read that and compare [16:12] that would be pretty tight [16:12] I think i'm going to build it and then check my system [16:13] cjwatson: well yeah, rootkit would have to be quite carefully constructed to hide in the set of packages which debsums misses :) [16:16] someone knows who or what takes care of closing bugs, starting from changelogs like (lp:xxxx) ?? [16:16] some scripts? launchpad itself? soyuz? [16:20] gaspa, #ubuntu-bugs takes care of it [16:20] ? [16:21] hwilde: i mean "automatically"... [16:21] i mean /join #ubuntu-bugs [16:24] gaspa: soyuz does, why? [16:25] seb128: thanks. [16:25] for a discussion on debian-devel. (please a moment... searching for it) [16:27] seb128: http://lists.debian.org/debian-devel/2008/07/msg00697.html [16:27] the point is:"if a debian maintainer close a LP bug on his changelog, will be automaticaly closed in launchpad?" [16:28] the answer seems to be "yes". [16:28] i only wanted to know how... but now i'm likely satisfied. [16:28] ok [16:29] gaspa: https://wiki.ubuntu.com/ClosingBugsFromChangelog for reference === pmatulis is now known as pmatulis_afk [16:32] i see, seb128, thanks. [16:35] how can you destroy the root passwd is somebody set it [16:35] gaspa: yes, our tool that syncs packages from Debian parses the changelog for LP: entries [16:37] cjwatson: yep. [16:46] gaspa: fwiw, I've just added an explanation to https://wiki.ubuntu.com/UbuntuForDebianDevelopers about the changelog closing, in response to that thread on d-d === pmatulis_afk is now known as pmatulis === norsetto is now known as norsetto_limbo [17:32] kees: well, I haven't figured out the solution yet, but I have identified the problem with ubuntu-cve-tracker and firefox [17:33] kees: firefox (the source package) produces the firefox-2 binary, but not the firefox binary [17:33] kees: firefox-3.0 (the source package) produces the firefox-3.0 binary and the firefox binary [17:34] kees: you can see the issue with 'apt-cache madison' and 'apt-cache showsrc' [17:35] (for hardy) [17:36] kees: the trick is to get ubuntu-cve-tracker to work this out, without breaking other stuff... [17:37] (ie, it needs to pick 'firefox-3.0' as the source package in this case) [17:37] jdstrand: hurm, what's the example failure I can see with it at the moment? [17:38] kees: well, you can see what happens with ubuntu-cve-tracker by doing './scripts/cve_status CVE-2008-2785' [17:39] kees: you can see that the table shows firefox as 'needed' for all releases, though the CVE shows firefox as released for dapper-hardy [17:39] kees: however, I don't think it's ubuntu-cve-tracker's fault, but perhaps apt_pkg [17:39] (from python-apt) [17:40] or perhaps our usage of it [17:40] kees: I believe 'apt-cache madison firefox | grep hardy' demonstrates the issue [17:41] kees: we really should only get back the firefox 2 source package (which is named 'firefox'), but we get back both firefox and firefox-3.0 [17:41] * kees scratches his head [17:42] kees: at least, I only want to see the firefox 2 source package in that case [17:43] hm, we're only using apt_pkg do parse the file... [17:43] hey kees [17:43] (and compare versions) [17:43] heya pitti! [17:44] jdstrand: but yeah, there is certainly something wrong... hm [17:47] kees: re apt_pkg> well, it is precisely the parsing that is the issue :) it does seem consistent across various apt invocations, so I am not suggesting a bug there, just that we need to somehow work around it's parsing [17:52] What's the best way to contribute a small patch to language-support-writing-en (to fix bug #58308)? I'm not an experienced contributor, and looking at the naming scheme of the version, appending ubuntu1 doesn't seem appropriate. [17:52] Launchpad bug 58308 in language-support-en "No spell check in en-au locale" [Undecided,Confirmed] https://launchpad.net/bugs/58308 [17:53] Riddell: 189MB to go on the CDs? :-) [17:53] slangasek: I don't think the livefs has rebuilt yet [17:53] hmm [17:54] slangasek: it needs a recommends changed in arts but arts fails to build with a nasty compile error I don't understand [17:54] ok; shall I have a look? [17:54] http://paste.ubuntu.com/29036/ [17:54] pitti: bummer, re: rm'ing chroots [17:55] LaserJock: :) [17:55] pitti: thanks for the tip though [17:55] slangasek: don't know if that makes any sense to you [17:55] Riddell: a vague amount of sense; is this reproducible with the version in the archive? [17:56] slangasek: yes [18:00] Hew: language-support-* are all generated; it's better to make a bzr branch of langpack-o-matic and submit that for review (there are facilities in LP for that) [18:00] (oh, and mention the branch in the bug too) === norsetto_limbo is now known as norsetto [18:02] cjwatson: thanks for your help. I'm a noob at bzr, so I'll have a look at it :-) [18:08] kees: hmm-- I don't think this is as complicated as I thought-- a bug was recently introduced that appears to mark all as needed if one is needed [18:09] kees: as I think I may have introduced it, I'll fix it :) [18:09] jdstrand: okay, cool, I was just zero'ing in on it myself too [18:09] mathiaz: samba 3.2.0 wants merging :) [18:12] pitti: ArneGoetje: have you heard of any issues with the lang packs? you think we could copy them tonight so we can release the ffox/xul bits tomorrow morning? [18:13] asac: one positive (pt from slangasek), no negatives [18:14] so noone replied on the call for testing? [18:14] if so, they should have replied to Arne [18:17]