=== ekovanci is now known as raptoid === raptoid is now known as ekovanci === ekovanci is now known as raptoid === raptoid is now known as ekovanci === Ben1 is now known as BenC === asac_ is now known as asac [03:57] hi all, I have a silly question [03:57] does anyone here know about the linker ld? [04:02] Linolium: You're better off asking your question directly. While someone might know the answer to your specific question, few are foolhardy enough to admit to complete knowledge of ld, and this may or may not be the ideal forum. [04:02] I know everything about ld [04:02] :-P [04:02] what about gold? [04:03] I lie, I have only used it a couple times [04:03] I am using ld for my generated code but it is giving jmp calls the wrong address ie. 0x80000300 instead of 0x00000300 Does anyone know what ld option can fix this? [04:03] my .map file contains .=(0x80000000+SIZEOF_HEADERS) which is the problem [04:03] the code itself is in the correct location [04:04] Linolium: That's a much better question. You might want to specify the package on which you are working, and provide a pastebin of the build log to show context. [04:05] I am working in windows aiming for taito f3 system that uses a MC68020 processecor [04:05] using gcc's windows distro [04:06] everything is fine except for the address relocation for jumps [04:06] in the code [04:06] Linolium: In that case, I suspect this isn't the best place to get the answer. Unfortunately, I don't know which would be the correct forum. [04:06] that is what I was afraid of [04:06] :: sigh [04:06] :: [04:07] there doesn't seem to be any place that knows ld well :( [04:07] surely mingw has a channel [04:07] dunno [04:07] one would hope [04:07] or a linux devices or embedded channel [04:08] i bet one of the linksys firmware channels knows the right people [04:08] ok [04:08] well thanks [04:08] it's time for me to sleep now [04:08] I'll tackle this problem more tomorrow [04:09] hi [04:09] Linolium: you are simultating the Motorola 68020 in Windows ? [04:10] mame [04:10] :) [04:10] yes, mame :) [04:10] I was gonna say MAME already does that :) [04:10] heh [04:10] doesn't it ? [04:10] yeah [04:10] it does [04:10] well, up to my function calls [04:10] hehe [04:11] ah, now I get it :) [04:11] wait, why not ask the mame people? [04:11] yeah [04:11] they're all over efnet [04:11] I was gonna say, ask the mame developers [04:11] yeah they're probably on efnet [04:11] efnet #mame? [04:11] efnet #mame probably [04:11] guessing [04:11] ok [04:11] thanks [04:11] peace guys [04:11] hi guys. i've enabled hardy-propesed in software updates, but can't see the patched kernel in the list of packages to be updated? I want the latest patched kernel that should be in -proposed... what am i doing wrong? [04:12] alex1: You are confusing linux with linux-meta and #ubuntu-devel with #ubuntu [04:13] err sorry yeah i should've asked in #ubuntu. linux-meta? [04:15] oh i see. https://launchpad.net/ubuntu/hardy/+source/linux-meta thanks :) === symptom is now known as symptom_ === symptom_ is now known as symptom === joejaxx_ is now known as joejaxx === gaurdro_ is now known as gaurdro [06:58] good morning === tkamppeter__ is now known as tkamppeter [08:20] Good morning [08:21] hi pitti [08:21] hi mvo, thekorn [08:21] * Hobbsee crash-tackles pitti in greeting! [08:21] hey dholbach [08:21] hi pitti [08:22] tkamppeter: which "custom options" patch do you have in mind? why isn't it going into 1.4? [08:22] tkamppeter: please don't upload anything into Ubuntu yet [08:22] tkamppeter: (I mean cups) [08:22] tkamppeter: I wait until the cupsys -> cups rename makes it past Debian NEW [08:23] tkamppeter: of course feel free to commit stuff to the svn [08:23] Riddell: was on VAC on Friday; doko and I wanted to attack MIR today [08:23] hey Hobbsee, hi dholbach! [08:23] *group hug* [08:23] :) === persia_ is now known as persia [08:29] * pitti hugs mvo, too [08:32] Interested in MOTU! [08:34] dave_: Come to #ubuntu-motu ! [09:04] hello dholbach === hunger_t is now known as hunger === Hewus is now known as Hew [10:18] asac: what's your feeling on bug 233922? ready for -updates? looks good from my POV so far? [10:18] Launchpad bug 233922 in yelp "[new-upstream] Firefox 3.0 RC1 is available" [High,Fix committed] https://launchpad.net/bugs/233922 [10:18] Don't we have RC2 now? [10:19] that's a different issue [10:19] the -proposed ones should go to -updates first [10:19] Is it really safer to push two large changes to -updates than one larger one? [10:20] wgrant: we know that the current set is good [10:20] if we keep piling up new uploads in -proposed, testing all the changes gets too complicated [10:20] and we don't have -rc2 packages [10:20] OK. [10:25] seb128: bonjou! [10:25] wgrant: yeah RC2 should be much quicker [10:25] bonjour, even [10:25] pitti: i'd say its good. ill go through the bug reports once more and let you know later [10:25] asac: cool, thanks [10:25] guten tag pitti [10:28] <\sh> asac: rc1 is much faster then the orig hardy one [10:29] \sh: hehe ... i referred to the time that is needed till it hits the archive ;) [10:30] but yes, there have been additional performance boosts and a few more IO bustage fixes [10:30] to which package could I reassign Bug #236961 that would remotely make sense? [10:30] Launchpad bug 236961 in upgrade-system "8.04 Install Error" [Undecided,New] https://launchpad.net/bugs/236961 [10:30] <\sh> asac: oh...damn..I'm still lacking reality ;) free beer in a pub is nice but makes life a hell [10:32] same question for Bug #236732 [10:32] Launchpad bug 236732 in upgrade-system "upgrade fails dapper to edgy" [Undecided,New] https://launchpad.net/bugs/236732 [10:32] \sh: i know what you mean :) [10:33] Q-FUNK: installer errors -> debian-installer or ubiquity, upgrade errors -> the package that failed the upgrade, or if it is a bug in the upgrader itself, 'update-manager' [10:33] <\sh> asac: but at least we won ;) [10:34] pitti: I regularly get people who presume that upgrade-system is a generic package name to report an upgrade failure. figuring out which package to reassing these 3 to is challenging. [10:34] Q-FUNK: looks like a dirty CD drive to me; a CD drive cleaning kit might well work wonders. I very much doubt it's an installer bug as such, because actual corrupt packages (as he's reporting) would happen to everyone. However, there's an outside chance that the kernel's driver for his CD is busted, in which case 'linux' would be the appropriate package [10:34] Q-FUNK: I doubt we can do anything about his problem in either debian-installer or ubiquity [10:36] cjwatson: looking at his bug, I'm thinking more of e general failure in his IDE controler, for which he is evidently blaming his upgrade. [10:36] Q-FUNK: could be; by "driver for his CD" I guess I was including everything in the relevant stack [10:36] cjwatson: replying to someone who already made up their mind thta whatever fried his hardware is our fault generally is a lost cause. [10:37] I'd probably include some advice about CD drive cleaning, and toss it over to linux in case they can make anything of it [10:37] it may be that there is at least something recoverable from dmesg [10:41] could be, indeed [10:41] mvo: thanks for doing your share of sponsoring :) [10:41] dholbach: heh :) funny that you noticed [10:41] mvo: I sure did :-) [10:42] * mvo hugs dholbach [10:42] * dholbach hugs super-soccer-mvo :) [10:43] * mvo is more super-keen-injury-mvo now :P [10:51] * ogra hrms about the kino bug dholbach just assigned to him [10:52] ogra: what's wrong? [10:53] well, its unsolvable, dv1394 is going away in the kernel and Keybuk wont make udev create /dev/raw1394 with world permissions ... [10:54] its an ancient butg (might be a duplicate of a 4 digit ubuntu bugzilla bug even [10:54] I can't do much about it [10:54] me neither [10:55] apart from changing the concept of ieee1394 completely :) [10:55] ogra: juju juju juju [10:55] if there's no other option at all to fix it, close it "won't fix" - I just wanted to get it through the sponsorship queue [10:58] ogra: would it be inappropriate to link to a wiki page explaining how a user could make their own udev rule, even if it's unsupported? [10:59] dholbach, wont fix will result in another bug agin .... [10:59] i'D like to quiten it down [10:59] highvoltage, sounds like an excellent idea, i tried to gather some info half a year ago for such a site [11:00] dholbach: bah, I never got a mail for bug 232452; #$*(#$ [11:00] Launchpad bug 232452 in latex-beamer "syntax error in colortheme beaver" [Undecided,Confirmed] https://launchpad.net/bugs/232452 [11:00] but didnt get any input (i dont own a dv cam) [11:00] pitti: AFAIK the LP bug about "subscription to a bug should send a mail rightaway" is closed now - so it should work out better in the past [11:01] right [11:01] * dholbach hugs pitti [11:01] . o O { most of the work for sponsoring is to forward these patches upstream } [11:09] pitti: seems that someone finally confirmed that my new -geode package works, in combination with the new -nsc package I had to produce to eliminate PCI ID conflicts. both are in my PPA, but might need some cleanup before they can be merged in. [11:11] Q-FUNK: ah, are you the q-funk that's been talking to (I think his nick is coolio on freenode) about these drivers? I need to assist him with it at some point. [11:12] highvoltage: my nick is q-funk everywhere, so probably not. :) [11:12] bah! :) [11:14] highvoltage: but what was the issue he had? [11:15] Q-FUNK: he has new thin clients from Via with brand new display chips, which don't work well with Edubuntu currently, he told me he talked to someone on #edubuntu who said that they're working on packages for these driverse [11:15] Q-FUNK: but I haven't had chance to catch up on it yet. === gnomefre1k is now known as gnomefreak [11:16] highvoltage: via doesn't use the -geode driver, though. IIRC they have someone making them custom X drivers that might eventually be merged. [11:17] sponsors for main, mind reviewing scons merge from bug 226783? thanks. [11:17] Launchpad bug 226783 in scons "Merge scons 0.98.4-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/226783 === ogra_ is now known as ogra [11:49] pitti, hi [11:50] Riddell, hi [11:53] hi tkamppeter [11:54] Riddell, there is a probvlem with the build server and Qt. I tried my first upload as core-dev, HPLIP 2.8.5, and I got an FTBFS with the following error: [11:54] The following packages have unmet dependencies: [11:54] python-qt4: Depends: python-elementtree but it is not installable [11:55] tkamppeter, Riddell: bug in python-qt4 [11:55] The package tried to pull python-qt4 with its build dependencies. [11:55] p-e is an intregral part of python2.5 and doesn't need to be depended on for 2.5 (and to be in main) [11:56] -> depends: python2.5 | python-elementtree [11:56] pitti, Riddell, any chance that this get fixed soon? [11:56] tkamppeter, pitti: I can fix that now === elmo_ is now known as elmo [11:58] Riddell, great, HPLIP 2.8.5 needs testing, upstream has done a lot on hp-toolbox and there are a lot of new bugs which need to get to upstream so that Intrepid gets a nice 2.8.7. [12:00] Riddell, pitti, after Riddell has fixed python-qt4, what has to be done so that the build server does a new build of the same HPLIP package? [12:00] tkamppeter: you can retry the build [12:00] tkamppeter: please tell me when the fixed pakcage is in the archive [12:00] Riddell, can you also check whether perhaps python-qt3 suffers the same problem? [12:00] tkamppeter: then I'll show you === LucidFox_ is now known as LucidFox [12:01] Riddell: I'm always amazed how many arithmetic libraries for the same purposes one can invent... [12:08] surely not exactly the same purpose [12:14] When uploading bzr source branches to LP is it ok to upload multiple sources and link them with a single product as a collection? E.g. Cell SDK would be the product, under which I'd want bzr branches for cell-gcc, cell-binutils and so on. [12:15] Rather than having separate LP products for each e.g. Cell GCC, Cell binutils etc [12:22] tkamppeter: python-qt3 does not seem to have that issue [12:23] Riddell: indi failed to upload; did you get an explanation via mail? [12:23] Riddell: ah, because it was NEWed incorrectly [12:23] * pitti fixes [12:30] Riddell: ok, I processed MIR up to what I can [12:36] morning [12:46] pitti: ok, thanks [12:48] woo, go pitti go! [12:50] munckfish: while it would work, it's not really kosher [12:51] munckfish: Launchpad projects are supposed to correspond to single atomic upstream projects [12:52] munckfish: I suppose it depends on whether you think that cell-gcc is just a branch of gcc (my view) or whether it's part of a separate Cell SDK entity that's permanently forked gcc [12:52] cjwatson: hi, yes this is the problem I have - for normal GCC I'd say keep it separate of course [12:52] however, all of these related bits from the Cell SDK page are like a forked collection [12:53] I sort of felt it important to group them together so that was obvious [12:53] I also realise they will go away eventually [12:53] but having struggled to create a cross tool chain with gcc-4.3 et al, I'm thinking of continuing to maintain these cell-* sources [12:54] So, do you still think separate or collection? [12:57] munckfish: I would still lean towards separate, but seems like a grey area. Perhaps ask #launchpad for a ruling [12:57] cjwatson: ok, I'll do so [12:57] thx for your opinion [13:05] cjwatson: btw, any chance of seeing the new vim in intrepid anytime soon? looks like there's a request for sponsorship, with your name on it :) [13:07] seb128: can you push a patch for https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/211604 so people stop complaining about invisible trash icons? the patch is upstream on gnome but it's not going anywhere. [13:07] Launchpad bug 211604 in gnome-applets "trash icon disappears in panel" [Low,Triaged] [13:07] Hobbsee: you call me a vista lover, yet you are requesting vim? vi vi vi - the sign of the devil! [13:09] nixternal: at least vim runs on ubuntu. the same cannot be said for vistsa. [13:10] alex-weej: I've read your comments, but do you care to explain what it's doing and why? [13:10] -s [13:10] seb128: it's the same fix that went into many other applets that used to break [13:10] alex-weej: that's not very useful to me to understand what it's doing and why [13:10] bonobo-activation-server is *allowed* to exist across login sessions, the fact that it does is in most cases a bug, but it still shouldn't break objects [13:11] the trash applet needs a DBus connection since the move to GIO [13:11] alex-weej: isn't that bug #49594? [13:11] Launchpad bug 49594 in libbonobo "Bonobo-activation-server sometimes is not killed after session restart, leading to many unexpected problems" [Undecided,New] https://launchpad.net/bugs/49594 [13:11] seb128: yes, but it's a separate bug that is not important [13:11] well, it leads to similar issues [13:11] if the trash applet process gets activated by bonobo, it inherits the activation server environment by default [13:12] bonobo specifically has mechanism to allow the activated object to inherit specific env variables from the *activator* [13:12] i.e. trash applet will take the dbus session bus address from gnome-panel [13:12] if the patch is applied [13:13] why is it working for me without the patch then? [13:13] because your b-a-s exits [13:13] trust me, it needs to be in and it will fix this bug. [13:14] seems to be a workaround, but it it makes things work better while the libbonobo issue is still there [13:14] no it's not [13:14] there are legitimate cases for b-a-s to exist cross-session, and fixing bug 49594 won't fix this bug in 100% of cases [13:14] we had bugs about the trash not showing an icon way before gio and dbus use [13:14] Launchpad bug 49594 in libbonobo "Bonobo-activation-server sometimes is not killed after session restart, leading to many unexpected problems" [Undecided,New] https://launchpad.net/bugs/49594 [13:14] seb128: probably because it still used dbus with gnomevfs [13:15] seb128: i wrote a patch last year to cause b-a-s to exit with the session, thus resolving 49594. it was rejected. [13:15] i learnt from the devs that it is supposed to be allowed to outlive a session [13:16] but in such cases it has a wrong environment [13:16] and that fixing dbus-using activated objects is done by telling b-a-s to pass the env vars from the activating process [13:16] ie, outdate dbus bus informations [13:16] well, it's up to you. the bug will be accepted upstream eventually because it is the right thing to do. if you want to keep triaging these bugs then suit yourself :P [13:17] and i made all of these arguments about it the first time round. turns out i just didn't understand the bonobo architecture properly. [13:17] let me find the bug. [13:17] alex-weej: as said before I don't discuss this change, I'm trying to understand what else is broken there [13:17] what practical advice would you give an open-source enthusiast who would like to get involved as a contributing developer to ubuntu? [13:18] I'm talking about coding skills to master (language, paradigms e.t.c.) [13:18] you just said what is broken. there is /nothing/ wrong with b-a-s having "outdated" DBUS_SESSION_BUS env. it shouldn't really be there in the first place, as b-a-s outlives dbus sessions [13:18] among other things [13:18] x_dimitri: check out http://wiki.ubuntu.com/MOTU/GettingStarted and the pages linked from there [13:18] assuming the ideal case that it wasn't there, the env var would have to be passed from the activating process anyway [13:18] x_dimitri, start in #ubuntu-motu, look through the different available tasks, grab oe and start working on it :) [13:18] and the way to do that is with the .server definition file XML [13:19] alex-weej: is there any case when we want to get the environment from b-a-s then? why not defaulting to use the activator one? [13:19] yes there is case for getting env from b-a-s [13:19] alex-weej: there is lot of .server around and I'm wondering if it makes sense to start change all of those rather than changing b-a-s [13:19] dholbach: thanks. I have seen those. [13:20] x_dimitri: great [13:20] for every other env var that also outlives dbus sessions [13:20] :-) [13:20] ogra:what does 'oe' mean [13:20] one [13:20] seb128: don't worry about changing b-a-s. the real fix is to move panel applets away from bonobo. it's coming! [13:20] missed a char [13:20] alex-weej: well, LC_ALL can change between sessions too, etc [13:20] it can change *within* sessions [13:21] alex-weej: should we apply the same trick to other environment variable? [13:21] ogra: oh, ok. Thank for your suggestions guys.. [13:21] it's not a trick, it's documented exactly for this case. it's the best of a bad situation. [13:21] alex-weej: right but that's not common case [13:21] lemme see what the guys in #ubuntu-motu ahve to say [13:21] i have to study [13:21] cya [13:21] alex-weej: ok, so should we use this documented case to make sure than other things, ie the locale, are correctly set too? [13:22] asac: how's the rc1 bug front? [13:24] pitti: ping [13:26] Hobbsee: I've been off for several days and am catching up; it would be best for somebody else to take it if possible === ion__ is now known as ion_ [13:29] pitti: so far it looks good. how long will you be on today? I'd like to clean the relevant bugmail folders before we push this. is there still some time? [13:33] asac: guaranteed until 18:00 CEST, then sporadic [13:39] pitti: ok thanks. Ill hurry - still need to do a quick lunch though ;) [13:45] asac: enjoy [13:59] why does archive.ubuntu.com/ubuntu/dists/dapper/Release mention "ia64" under Architectures, also mentions main/binary-ia64/Packages.bz2 with a size of 616356 bytes, but there's no such file under archive.ubuntu.com/ubuntu/dists/dapper [14:00] cr3: because the archive is split between archive.ubuntu.com and ports.ubuntu.com after Releases files are generated [14:01] elmo: hm, that makes my life complicated but nothing which can't be worked around. thanks for the explanation [14:03] cr3, note that the ports url uses ports.ubuntu.com/ubuntu-ports instead of /ubuntu [14:03] its not obvious and there is no link or anything on ports.ubuntu.com/ so you could see that [14:03] ogra: thanks for the note, but I see no "ubuntu-ports" subdir under http://ports.ubuntu.com/ [14:04] yeah [14:04] its a redirect apparently [14:04] ogra: man, the weirdness just doesn't stop :) [14:04] yeah [14:04] took me ages to figure that out [14:05] * ogra wouldnt have found out if inifinity wouldnt finally have told him [14:06] ogra: what's wrong with just using ports.ubuntu.com/, couldn't that have worked? [14:06] ogra: /ubuntu-ports is just a redirect to / though [14:06] cr3, thats not te url used in the tools (apt-setup for example) [14:06] cr3: that should work fine [14:06] yes, it should [14:06] ogra: it's not the "official" URL, but it'll work [14:06] its just inconsistent [14:06] indeed [14:06] the reason we generally use /ubuntu and /ubuntu-ports and such is to aid mirrors [14:07] i dont understand the reason for -ports though [14:07] ah [14:07] so that if somebody is mirroring a zillion different free software distributions they don't have to have a virtual host for each [14:07] right [14:07] I love asking these questions which seem just weird but have a perfectly reasonable explanation [14:07] makes sense [14:07] and /ubuntu-ports so that they don't have to figure out how to merge it back into /ubuntu [14:16] <\sh> is mono somehow uninstallable in intrepid? === njpatel_ is now known as njpatel [14:43] seb128: do you have any idea how I would go about fixing bug 236988? According to the freedesktop.org wm-spec, _NET_WM_STATE_FULLSCREEN goes above _NET_WM_STATE_ABOVE (and presumably this has to be the case so that fullscreen > panels) [14:43] Launchpad bug 236988 in openssh "HARDY: gnome-ssh-askpass does *not* grab keyboard or focus if contested with other apps" [Undecided,New] https://launchpad.net/bugs/236988 [14:45] pitti, according to LP (https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/python-qt4/4.4.2-0ubuntu2) Riddell's fix is up. How do I proceed to rebuild HPLIP? [14:46] tkamppeter: go to the build page in launchpad [14:46] click retry [14:47] https://edge.launchpad.net/ubuntu/+source/hplip/2.8.5-2ubuntu1/+build/632305 [14:47] cjwatson: not sure, gnome-keyring seems to use _NET_WM_STATE_MODAL, _NET_WM_STATE_ABOVE, but mvo might know better [14:48] that would also be a wm bug [14:48] s/would/could [14:49] you aren't supposed to use gdk_window_set_modal_hint on non-transient windows, apparently, and gnome-ssh-askpass doesn't have anything it could be transient on [14:50] tkamppeter: right, what Riddell said; you have to do that for all architectures where it failed [14:52] gdk_window_set_modal_hint doesn't obviously help, anyway [14:52] but I have to go [14:52] cjwatson: I have a look [14:52] cjwatson: gnome-keyring does that [14:53] /* [14:53] * We do this to guarantee the dialog comes up on top. Since the code that [14:53] * that prompted this dialog is many processes away, we can't figure out [14:53] * a window to be transient for. [14:53] */ [14:53] gtk_window_set_keep_above (GTK_WINDOW (dialog), TRUE); [14:53] gtk_window_set_resizable (GTK_WINDOW (dialog), FALSE); [14:53] gtk_window_set_type_hint (GTK_WINDOW (dialog), GDK_WINDOW_TYPE_HINT_NORMAL); [14:53] (and check against gksu as well) [14:54] seb128: doesn't help - must be doing something else as well [14:54] Thanks, pitti and Riddell. I see this button for the first time, is it a new LP feature or a core-dev-only feature? [14:54] tkamppeter: it has recently been made available to developers [14:54] ok, so I don't know [14:54] (or else gnome-keyring has the same problem!) [14:55] Feature request: "Retry all failed archs" button. === emgent_ is now known as emgent [14:57] pitti, with "developers" you mean core-devs or also MOTUs? Or does it depend in which repository the package resides (I only want to know it to tell the correct thing to others who ask me)? [14:58] tkamppeter: feature request> there is a script which automates this; I'll show you next time [14:58] tkamppeter: I'm not sure; I guess if you can upload a package, you can rebuild it now [15:04] pitti, HPLIP is now successfully built for 5 architectures (in the queue for the 2 missing ones). So these 5 are already on the way to the mirrors now? [15:05] tkamppeter: yes, in one or two hours (depending on whether they finished building more than 3 minutes ago) [15:06] pitti, in former times I have seen a lot of "give-back" messages here on the IRC. Was this the retrying of a build when the first build went wrong? [15:06] tkamppeter: exactly [15:06] tkamppeter: "give back" is the term for historical reasons (it's still called like that in Debian) [15:07] seb128, pedro_, bdmurray: can anyone of you play a bit with an NTFS volume to verify bug 229000? [15:07] Launchpad bug 229000 in ntfs-3g "random file corruptions in ntfs-3g < 1.2506" [High,Fix committed] https://launchpad.net/bugs/229000 [15:07] pitti, then all except amd64 will make it in one hour and amd64 perhaps only in two hours. [15:09] pitti, what means if the "successfully built" for an arch switches from ACCEPTED to DONE? [15:10] tkamppeter: "ACCEPTED" is the queue which holds built packages; the next publisher run (at :03 hourly) picks up those and puts them into the actual archive [15:10] pitti: just playing on a ntfs partition and looking if everything works correctly? [15:10] pitti: there is no TESTCASE on the bug [15:10] tkamppeter: when that happens (aronud :05 hourly) it will get to DONE [15:11] seb128: no, reproducing the actual bug is really hard [15:11] seb128: I described my own testing in the bug (test suite, some operations in nautilus, etc.) [15:11] pitti, thanks. [15:18] pitti, can I also build Debian or Ubuntu packages with a .orig.tar.bz2 instead of a .orig.tar.gz file? [15:19] tkamppeter: that feature is in hardy; so it depends on whether soyuz is running on hardy now; cprov? [15:22] pitti: we haven't backported it to edgy. Let me check it again. [15:22] pitti, can you have a look at CUPS bug 2814? [15:23] CUPS bug 2814 in Core CUPS Software "Support AllowedChars for String/Password type custom PPD options" [Priority request for enhancement,New] http://www.cups.org/str.php?L2814 [15:23] cprov: edgy! [15:23] pitti, one minute this was not the right one. [15:23] pitti, it was the right one. [15:25] pitti: confirmed, it's not there. Please file a bug so it can be done at some point in before LP 2.0. [15:25] tkamppeter: ^ [15:25] pitti: ok, I didn't try the testsuite thing you mentionned but normal usage (copies, move, renaming, deleting, mount, unmounting, browsing the drive, dnd, etc) works correctly, I've added a comment to the bug [15:26] * pitti hugs seb128, thanks [15:26] * seb128 hugs pitti [15:26] pitti, it is about some enhancements to CUPS to really support the custom options which Mike has introduced in CUPS 1.2 (string, password, numeric, ...) but they got never really used. Currently, I am on the way to get them advertized to the manufacturers and supported by the Common Printing Dialog. [15:27] pitti: ok, lets feed this to the masses :/ [15:28] asac: rumble!!! [15:28] pitti, Lars Uebernickel (developer of foomatic-rip 4.0 and now GSoC student for the CPDAPI DBUS interface for the Common Printing Dialog has written two CUPS patches for these options. [15:29] asac, food ? [15:29] One is for a special PPD keyword to restrict the allowed characters in string options, the other is about supporting the options in the CUPS web interface- [15:29] yummy [15:29] pitti: should i set to verification-done? [15:29] asac: please do, and describe the amount and quality of feedback you got [15:29] pitti, CUPS bug 2807 [15:29] CUPS bug 2807 in Core CUPS Software "Exposing custom options in the web interface" [Priority request for enhancement,Closed w/o resolution] http://www.cups.org/str.php?L2807 [15:30] pitti, and CUPS bug 1729 [15:30] CUPS bug 1729 in Core CUPS Software "CUPS web UI should support new UIOption types (int, string, password)" [Priority request for enhancement,Pending] http://www.cups.org/str.php?L1729 [15:32] Mike has rejected bug CUPS bug 2814 and he did not answer yet to the last patch for CUPS bug 1729. [15:32] CUPS bug 2814 in Core CUPS Software "Support AllowedChars for String/Password type custom PPD options" [Priority request for enhancement,New] http://www.cups.org/str.php?L2814 [15:32] CUPS bug 1729 in Core CUPS Software "CUPS web UI should support new UIOption types (int, string, password)" [Priority request for enhancement,Pending] http://www.cups.org/str.php?L1729 [15:33] tkamppeter: I don't want to permanently carry large patches which are rejected upstream; we've been through this :/ [15:35] pitti, so I leave them out as long as Mike does not accept them. If Mike turns away from the custom options I make them my baby with system-config-printer and the Common Printing Dialog. Perhaps Mike will return to them when I have made them common practise. Support from inside CUPS is a nice plus but not required. [15:35] pitti: commented. [15:35] tkamppeter: ok, thanks [15:37] tkamppeter: please file the orig.tar.bz2 thing as a bug against soyuz [15:40] In s-c-p and CPD I am upstream and I can publish specs on OpenPrinting, so no support from Mike Sweet required. [15:42] pitti, how do I report a bug on soyuz, which project? Which package? [15:42] tkamppeter: "soyuz", no package [15:42] bugs.lp.net/soyuz/+filebug [15:49] pitti, someone else reported this already as bug 225151. [15:49] Launchpad bug 225151 in soyuz "Please add support for .orig.tar.bz2" [Undecided,New] https://launchpad.net/bugs/225151 [15:57] seb128, asac: note that epiphany-browser has a newer version in intrepid, and xulrunner is already updated in intrepid, so I won't copy the lot from hardy-proposed to intrepid [15:58] asac: bug 236984 is still open in intrepid? [15:58] Launchpad bug 236984 in xulrunner-1.9 "firefox 3.0 RC1 can easily deadlock when touching any chrome file while running" [High,Fix committed] https://launchpad.net/bugs/236984 [15:59] pitti: yeah. its fix committed as our development branch is already on RC2 ... waiting for the queue to clear [15:59] ok [16:07] asac: xul and related copied, mass-copying of language packs in progress [16:10] pitti: ok ... let the fun begin. [17:30] pitti: er, I'm looking at "cron" to advise kirkland on doing a debdiff, and I'm not sure what version number to recommend. :P [17:31] 3.0pl1-104+ubuntu1? 104ubuntu2 won't work due to the +build1, iiuc [17:34] 104ubuntu2 > 104+ubuntu1, no? [17:40] kees: argh, I was so proud that we're finally back in sync :) [17:40] kees: 104+ubuntu1 will work, yes [17:40] pitti: heh. yeah, we've got a small correction that is unACKd upstream [17:41] they call /usr/bin/editor instead of /usr/bin/sensible-editor [17:41] and since kirkland is making changes to sensible-editor, this got examined at the same time. :) [17:42] kees: sorry for the weird version number in the first place; but it was the least evil-looking way to bump the number to something non-ubuntuish [17:42] yeah, I think it's the right solution; I'd just never hit this corner-case before. :) [17:43] mvo: are the changes to apt-listchanges for "dapper->hardy" still needed? [17:43] mvo: I'm going to assume "no", please let me know if I should re-add them. I'm requesting a sync for it since the other changes (security) are already upstream. [17:44] kees: no [17:44] mvo: perfect :) [17:44] kees: you assumed right :) its only needed for very old installs [17:44] kees: updated patch uploaded to https://bugs.edge.launchpad.net/ubuntu/+source/cron/+bug/222830 [17:44] Launchpad bug 222830 in cron "crontab not observing EDITOR or VISUAL" [Wishlist,In progress] [17:45] kees: btw, previous one did not update the Maintainer field ;-) [17:45] bryce: can you check on efibootmgr? if the ubuntu changes are upstream, can you do a "requestsync" for it? [17:45] kirkland: ah yes, good catch. I would have noticed when I compiled it. ;) [17:46] * kirkland is glad he cleaned that one up before getting smacked by kees ;-) [17:46] hehe [17:51] argh, libx86 [17:55] kees: is that 'argh' intended for me? [17:57] kirkland: no, just myself, I'm looking at my merges [17:58] ogra: say, can you do the powernowd merge? while I touched it last, it was just a bug fix and I'm not entirely familiar with the code-base. [17:59] me neither [17:59]