[00:00] alpha 3 out? [00:01] billisnice: see /topic [00:01] lol, seeing the topic would be good [00:01] does ext4 install auto this time? [00:02] is ext4 upgradable live, the way 2->3 is? [00:03] I think so, but you don't get some feature or other [00:03] * Laney knows not much about this [00:03] I still do not know how to switch to ext4? Where are the instructions [00:04] billisnice: Probably best for #ubuntu+1 [00:04] directhex: Yes it is, but some features only apply to new files. [00:04] RAOF, and backward compatible e.g. using the ext2 driver for windows? [00:04] directhex: Not new files; they'll be using extents, which aren't backwardly compatible. [00:05] hm. i hope someone cobbles together a driver, then [00:22] persia, you around? === emma_ is now known as emma [01:17] NCommander, ? [01:17] persia, do you know how to modify a COPYING file to include two licenses (do I just stick the second one in there or do I need to list what files are licensed what (everything has the right header) [01:22] NCommander, Context? You're working upstream, and merging in code with a different license? [01:22] persia, no, upstream has code under two licenses, the copying file only has one, but they're willing to change the copying file provided I give them a diff :-) [01:22] (and thus also let me get the compontent into Ubuntu once I repack) [01:24] Well, I don't know best practice for that. My personal preference when reviewing copyright for a package is that COPYING contains information about who holds copyright over which files, and under which licenses, with pointers to external files (also in ./) for specific licenses when multilicensed, or an inline license when there is only one. [01:26] I suspect that's against the intent, and that best practice would be for COPYING to contain something like "foo is released under the the GNU Public License version 3, and includes components bar and baz previously released under the GNU Lesser Public License version 2.1, ..." [01:36] Ok, that works for me. [02:51] cjwatson, maxb: I'm trying to build a bootable chroot. binfmt stuff isn't working (trying to execute perl scripts with [ba]sh); e1000.ko module isn't loading automatically (am I missing a modprobe package or something?). [02:53] cjwatson, maxb: there's a lot of things I could hard-code for my purposes, but I'm trying to get it to work automatically. I'm building a vnfs capsule generator script for perceus and want it work on other hardware. [02:55] If anyone has suggestions as to where to go to ask for this sort of thing, let me know. From what I know about #ubuntu, this question is probably not well suited to that channel :p [02:55] jharr, regarding binfmt, is binfmt-support installed in your chroot? [02:55] jharr, It's mildly offtopic for this channel, but no, there's probably not a better place (to my knowledge). [02:56] persia: thx :) [02:56] You know, I'm an idiot for not checking this... /usr/bin/perl is there, but it's 0 bytes [02:59] Turns out /dev/pts wasn't being mounted by debootstrap, which borks perl's install. [03:01] Let me see what version of debootstrap I have (I'm doing this from a CentOS 5.2 box and an rpmforge.net verison of debootstrap, don't hit me). [03:01] I'll go poke around with that, thanks for the tips. [04:35] WARNING: The following packages cannot be authenticated! [04:35] libavdevice52 libimlib2 ffmpeg [04:35] ^^^ is this supposed to happen after apt-get update fails ENONETCONNECTION? [05:06] Installing binfmt-support in a chroot and it's borking at the "setting up" phase. Apparently because it's getting the wrong info from uname (b/c of the chroot) [05:06] FATAL: Could not load /lib/modules/2.6.26.5-2.nsa1/modules.dep: No such file or directory [05:07] good morning [05:08] dholbach: good morning [05:08] hey jharr [05:14] maybe this is in the init script for it [05:22] Is there any way to prevent a package from calling an /etc/init script? [05:22] when it's installed [05:23] how do the three different repos work (regular, -updates, & -security)?? if an update is made to -security... the code in the other 2 are also updated? or if an update's made to -updates... the code in -security isn't updated, right? [05:24] nothing goes into the regular repo after release [05:24] stuff goes into -security for security updates or -updates for critical non-security updates [05:25] but often times the stuff in -security get's copied over to -updates to take some of the load off the servers [05:25] hey help me where can i get info on how to create a workspace [05:25] grndslm: does that sort of answer the question? [05:27] LaserJock: kinda [05:27] mostly yes [05:27] karthik: what do you mean by a workspace? I'm guessing this isn't the right channel [05:28] LaserJock: we can some define it as a virtual desktop.. [05:30] karthik: you should probably ask #ubuntu [05:31] LaserJock: i'm trying to implement using a c program [06:08] jharr, --no-start as an argument to dh_installinit. there's a variety of other ones too for other situations. look at dh_installinit's man page for more [06:11] superm1: thx [06:13] hey any one help abt how to create a virtual desktop [06:13] using a c prog [06:28] Good morning everyone! [06:37] hey there pitti! [06:38] pitti!! [06:42] I'm back from skiing, and still in one piece :) [08:14] pitti, hi === evan_ is now known as evand [09:39] pitti, thanks for applying mdz's patch saves me a job [09:40] apw: you're welcome :) [09:40] * apw throws away his debdiff [09:40] apw: I just ran the script, and it works fine here on a Dell Latitude D430 after I fixed "pmi suspend" -> "pm-suspend" [09:41] yeah i seem to have something installed on my test boxes which isn't standard and i don't know why [09:42] is powermanagement-interface non-standard and if so how have i gotten it [09:42] i was under the impression that was the official interface to these operations [09:44] * apw wonders how he would find out such a thing [09:45] hm. pitti, you're the oracle for such things. can you tell me why the "ndoc" source package is in main? are there any clues in the vast swathes of files which decide which section to put things in? [09:46] apw: pmi was installed by default until intrepid [09:46] hmmm, thats unhelpful [09:47] jharr: you don't actually need binfmt-support unless you're trying to get things like Windows executables to execute automatically; #! lines are interpreted by the kernel and the only userspace support they need is for the relevant interpreter to work [09:47] i guess i need to go get the launcher and find out what the heck it calls [09:47] directhex: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/rdepends/ndoc/ [09:48] apw: "launcher"? [09:48] apw: if you mean the gnome-power-manager applet [09:48] apw: it does a hal call, which in turn calls pm-suspend [09:48] i mean the thing that adds the suspend things to the menuything [09:48] pitti, "* Extra seed"? [09:49] directhex: yes, because the library is pulled in via dependencies, we keep the util in main, too [09:49] jharr: dh_installinit --no-start is useful if you're building a package but I suspect that superm1 didn't realise you were building a chroot. Usually people just want to stop daemons being started. There are a couple of ways to do that kind of thing which hook in at different levels: to stop just the daemon being started, you can dpkg-divert the start-stop-daemon program; to stop the init script being called at all ... [09:49] ... (usually), write a policy-rc.d script (see the invoke-rc.d(8) manual page). [09:50] pitti, hm, i wonder why antlr uses it - it's a java thing! [09:51] the antlr source package builds a libantlr2.7-cil binary package [09:51] note that the antlr->nant arc is a build-dependency not a dependency [10:00] bah, circular build dep between nant & ndoc [10:07] apw: powermanagement-interface is something which is installed by default, but it's old and should probably be superseded by more recent development [10:07] apw: this part of the stack needs the same sort of analysis and cleanup that slangasek is doing for hotkeys [10:08] yeah we are doing some stuff on this on the obsolete acpi duplicate suspend machinary [10:13] TheMuso: I'm noticing that on both systems I've upgraded to Jaunty, my mixer levels are now muted by default, when they used to be set to sensible values [10:14] mdz: powermanagement-interface was installed by default, but is no longer in jaunty [10:14] that should be read "is no longer installed by default in jaunty" rather than "no longer exists in jaunty" [10:14] it's still installed by xubuntu-desktop for some reason [10:14] cjwatson: oh, good. I didn't notice as it wasn't removed during the upgrade [10:15] * mdz purges it [10:15] a piece of history though === thekorn_ is now known as thekorn [10:24] cjwatson: I guess I should add a config entry that remove it for ubuntu-desktop users then on upgrade? [10:24] mvo: hopefully it can drop to universe by jaunty release; but in the absence of that, I guess so, yes [10:26] apw: as I wrote in the thread, pmi is actually doing something pretty close to what you'd want (talking to hal via dbus), it's just that it's probably no longer used by much of anything except your script ;-) [10:26] apw: a copy/paste of the dbus-send logic might be the appropriate thing if there's no better tool for this case [10:27] apw: I assume we'll want a very similar script for hibernate testing which will have the same issues [10:27] mdz, apw: "gnome-power-cmd.sh suspend" would replicate it, but it needs to run as user, not roo [10:27] t [10:28] but you need root for programming the automatic wakeup (once that actually works) [10:28] and its gnome specifc i guess [10:28] pitti: running as the user sounds like a feature [10:28] yes, it is [10:28] mdz: it would be, yes [10:28] though there are a couple of things in the script which require root at the moment [10:28] enable_trace and disable_trace [10:28] yeah the wakeup needs root right now, but that doesn't mean we can't dip in and out [10:28] set_wakeup_timer [10:29] writing the log too [10:29] its not impossible to split it into two cooperating halves [10:29] pitti: hi, when you have a minute, can you please look at bug 314212, I'm wondering if we should work around this in py-lp-bugs by trying to reupload if lp.net/+storeblob timeouts [10:29] apw: you could use $SUDO_USER and such hacks, but I really think that using dbus-send to hal is the right thing to do [10:29] Launchpad bug 314212 in apport "Apport unable to report crash - urlopen error timed out" [Undecided,Confirmed] https://launchpad.net/bugs/314212 [10:29] thekorn: hm, I thought that would have been fixed in LP last week? [10:29] apw: we'll need to do it anyway to make it fit nicely into a desktop-oriented test framework [10:30] pitti, i tend to agree that next step is probabally to use dbus. tehn we can work on splitting it so that it can run as user at least in part [10:30] I think checkbox insists on running as root at the moment, but I'm inclined to consider that a bug (->cr3,heno) [10:30] which would fit with what mdz is suggesting there whcih i assume would include a pretty interface [10:31] pitti: me too, but there were some new reports about it over the weekend and some people complaining in #u-bugs [10:32] pitti: maybe this needs a launchpad task [10:32] thekorn,pitti: I've had some cloakroom problems this morning as well [10:32] I've seen both a) apport opening file://ubuntu rather than http://launchpad.net in firefox, and b) NotFound on the +filebug URL with the cloakroom ID [10:33] mdz, thekorn: I wonder whether we are really talking about the same thing [10:33] the former was intermittent, the latter persistent === asac_ is now known as asac [10:33] one was that the upload suceeded, but the +filebug/DEADBEEF page said "no such page" [10:33] the other is that the upload itself times out/fails [10:34] pitti: I agree that using dbus-send is the right thing to do, but it would be nice to abstract it away in a nice function which knows which dbus method to call and which argument to pass, etc...and we are back to pmi :-) [10:34] pitti: is a) either of those, or are there three different problems? [10:34] pitti: right the "no such page" one was supposed to be fixed in lp last week [10:34] mdz: a) sounds like you are using some test backend again? [10:35] pitti: I literally retried with the same configuration and it worked [10:35] mdz: b) is bug 311690, I believe [10:35] Launchpad bug 311690 in launchpad-foundations "Delay between blob submission and blob availability causes Launchpad to OOPS." [Critical,Fix released] https://launchpad.net/bugs/311690 [10:35] well, a different crash report actually, but otherwise the same [10:35] mdz: if you have a reproducer for file://ubuntu, can you please mail me/create a bug report? [10:36] pitti: 311690 was workaroundable before by waiting a few seconds and reloading; this time it's persistent [10:36] so this needs to be reopened then? [10:37] hey pitti [10:37] hey tseliot [10:38] pitti: I can reproduce every time on this crash file, I'll send it to you [10:40] pitti: while we're on the subject, I was thinking about whether it's still a good idea to defer collecting the hook information etc. until the user is notified about the report. don't we have a beter chance of getting accurate and relevant data if we run the hooks and collect package info immediately when the crash happens? [10:41] mdz: two reasons for this: (1) hooks often collect user data (gconf keys), but kernel-triggered apport runs as root, and (2) hooks can potentially take a lot of time, which doesn't have a progress bar when the crash happens [10:41] mdz: however, for quick hooks which depend on timely information, we could have another class of hooks which run right away [10:42] pitti: (1) is a legitimate concern, and perhaps there should be two types of hooks. we already have both hooks which break because they require root, and hooks which expect user context (e.g. an X display) [10:42] pitti: regarding (2), I think it's OK to run them in the background with high nice+ionice and not worry about how long it takes [10:43] pitti: sometimes I've already installed updates before I report the bug, and the package info will be wrong [10:43] mdz: oh, and a third reason is that at the time when the crash happens, we don't even know which package it belongs to [10:43] pitti: it also makes it harder for things like X, which wants to get the log file before it's rotated away [10:44] pitti: we can look that up, the only reason we don't do it is (2) right? [10:44] mdz: right, because dpkg -S takes so awfully long [10:44] not only because it takes so long, but because it bogs down the system (I think ionice -c3 would address that) [10:45] mdz: ionice/nice would take care for the "bog down system" only partially [10:45] since you still need to wait for that long until the app actually disappears and you can restartit [10:46] but in a dev release that's certainly bearable [10:46] pitti: why? it should be possible to collect the info after the process has ended [10:47] hmm [10:47] apport could fork()/setsid() itself after collecting core dump and /proc, probably [10:47] what is the discussion about? running apport on stable versions? [10:48] seb128: no, running hooks when the crash happens, as opposed to when the UI runs [10:48] ah ok [10:48] running it on stables is not just a performance issue (that's actually the least important reason) [10:54] seb128: I have fixed this bug and provided upstream with patches (which are no longer workarounds): https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/307306 [10:54] Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] [10:54] tseliot: that was not a gnome-settings-daemon bug then? [10:55] seb128: it was a bug in both gnome-settings-daemon and gnome-power-manager. They use an expensive RandR call every time an event is triggered [10:55] * pitti hugs tseliot [10:56] tseliot: ok [10:56] pitti: the patches are in the upstream reports, if you want to try them [10:58] doko_: have you noticed that there are comments in bug 235070 indicating that it isn't fixed in hardy? [10:58] Launchpad bug 235070 in gcc-4.2 "Please apply libgomp patch to GCC for Hardy Heron" [Undecided,Fix committed] https://launchpad.net/bugs/235070 [10:59] (despite the presence of that patch in hardy-updates) [11:07] cjwatson, is it reasonable to rely on the fact that a dpkg-buildpackage will 'clean' your source tree before packaging it| [11:07] apw: yes [11:08] (there's an -nc flag in case you don't want that) [11:08] and would it be reasonable to fix permissions in your source tree while cleaning it [11:08] you can't say -nc with -S its not legal [11:08] yes, but it might be better to fix permissions just before using the scripts in question [11:09] actually, I think I may have misunderstood you [11:09] you cannot rely on clean being run after extraction [11:09] and adding executable bits before building the source package will do you no good - they need to be applied after extraction [11:09] so there is no hook for makeing sure the tree is ready [11:09] do it in the build target instead [11:09] sure there is, 'build' :-) [11:10] build can depend on whatever it needs [11:10] (or just do it inline) [11:10] and thats safe in the face of parallel builds [11:10] if debian/rules is written correctly, yes [11:11] got any info on what 'correctly' is in this cas [11:11] case [11:11] info make [11:11] I believe it has information on ordering [11:11] for example, 'build: dep1 dep2' means that dep1 and dep2 may be run in parallel, while 'build: dep2' and 'dep2: dep1' means that dep1 must be completed before dep2 starts [11:12] that would make sense to my expectationh of make behavior [11:12] ok will try it that way. i do not want to fix every build target for the kernel, its toooo likely to go wrong [11:13] you already have prepare- targets in debian/rules.d/2-binary-arch.mk [11:14] yeah but they are for the binary components, and i need to ensure i beat the headers too [11:15] you can also call debian/rules recursively if it makes things easily [11:15] easier [11:16] so 'rulename:\n\tchmod blah;\n\tdebian/rules prereq1 prereq2' [11:16] policy and the dpkg-dev toolset just specify a minimal interface - it's for maintainers to build richer things on top of that [11:16] i think i can use the same prepare concept in here for everything, have a general prepare [11:17] its just a lot of complexity to paper over the loss of information in the packaging system. sigh [11:36] is it a holliday today in the USA? [11:37] MLK today [11:37] i think that's an optional holiday [11:37] directhex, ok cool thanks [11:37] optional? [11:37] :) [11:37] pitti, please do not yet upload CUPS or pass through my upload into-proposed (bug 310575). I have still to add a fix. [11:37] Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Medium,Fix committed] https://launchpad.net/bugs/310575 [11:39] tkamppeter: ok; I rejected it from the intrepid queue [11:41] urgh, hall in C++ ? [11:41] *hal [11:41] * ogra is scared [11:44] ogra: are you talking about libhal++ or what? [11:45] tseliot, about the recent annoucement on the hal ML [11:45] yes, seems to be libhal++ [11:45] a fork/reimplementation [11:46] "HAL/C++ is a _reimplementation_ of libhal and libhal-storage in pure C++, using dbus-C++." [11:46] aah, this one: http://projects.backtrace.info/pmwiki.php?n=Main.Halmm [11:46] ok [11:46] right [11:47] sooner or later we'll use DeviceKit [11:47] "It is modeled after the original libhal and libhal-storage, but does not aim at complete adherance to the original API." [11:47] thats scary [11:47] it depends on what you plan on doing with it [11:47] well, apps will still use libhal for quite a while ... it takes its time until linked apps will switch [11:48] ogra: It does make some sense to have an API that makes sense in the language you're working with rather than another language that happens to link with it. [11:48] broonie, right, but it doesnt make sense to reimplement it in a fresh fork ... [11:48] instead of just adding to the existing code and thus keep API/ABI compatibility [11:51] Uh, doing something sensible in $OTHER_LANGUAGE rather implies breaking those; one of the wins with DBusing stuff is to keep a cross language ABI at the DBus level rather than lib level. [11:56] well, still new implementation requires new documentaion etc etc ... while as tseliot says a completely new system is in the work [12:01] mvo: do you know of anything that would call udev{adm ,}trigger on an upgrade? === azeem_ is now known as azeem [12:15] is it fine for any old package to use lzma compression and Pre-Depend on the relevant dpkg version? [12:17] james_w: for most, anyway; it should probably be avoided for base packages, to avoid breaking debootstrap [12:17] it's easystroke in universe [12:17] the contributor, and upstream maintainer, added it in the latest upstream version, I just wanted to make sure it wasn't against policy [12:31] pitti, I have released Foomatic 4.0 last week. Intrepid ships only a BZR snapshot. The BZR snapshot has some bugs, once Intrepid does not pass the LSB 3.2 compliance tests (http://bugs.linuxbase.org/show_bug.cgi?id=2423) and second, there are two bugs reported to Ubuntu: bug 299918 and bug 303691 [12:31] Launchpad bug 299918 in foomatic-filters "Cannot print duplex in intrepid with Ricoh Aficio 2060, Ricoh Aficio MPC3000 or Brother HL-4050cdn using the openprinting drivers" [Medium,Fix released] https://launchpad.net/bugs/299918 [12:31] bugs.linuxbase.org bug 2423 in lsb-test-printing "foomatic-rip tests fail against foomatic-filters-4.0" [Normal,Resolved: notourbug] [12:31] Launchpad bug 303691 in foomatic-filters "Intrepid, print broken with Minolta PagePro 8L printer" [High,Fix released] https://launchpad.net/bugs/303691 [12:32] So I am thinking about an SRU for Intrepid updating foomatic-filters to 4.0.0 final. [12:32] tkamppeter: are any of those regressions from hardy? [12:33] Yes, as Hardy still shipped the Perl version (3.0.x) of foomatic-filters. All three bugs did noty occur with that version. [12:35] tkamppeter: remember that if you upgrade to the final 4.0, *all* of the changes have to pass SRU criteria, otherwise we should just backport the specific changes (if they are serious) [12:45] pitti, concerning bug 310575 now everything is ready, new fix committed to the BZR and uploaded to -proposed. [12:45] Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Medium,Fix committed] https://launchpad.net/bugs/310575 [12:49] what's the right format of version number for an upload to hardy-propsed? [12:49] oldver.1 [12:49] and make sure to not clash with security :) [12:51] do you have to upload with hardy-proposed in changelog or hardy? [12:51] Keybuk: udev-triggered-on-upgrade> no, but I can try to find out more about it - does it seem to happen on a standard upgrade? [12:51] mvo: I guess - mdz is the only person to have reported it so far [12:52] mvo: any idea what to do with bug 241431? [12:52] Launchpad bug 241431 in update-manager "edgy to feisty upgrades fail due to use of old-releases" [Medium,Fix released] https://launchpad.net/bugs/241431 [12:52] pitti: uf, the proper fix is to backport the code from the jaunty version so that it auto-detect if it needs to use archive.u.c or old-releases.u.c [12:53] Keybuk: I'm on the machine now; is there anything I can look at for clues? [12:54] mdz: I'm surprised there's nothing in /var/log :-/ [12:54] Keybuk: ok, is this for bug #317944 ? I have a look on my auto-upgrade testing image if it shows a similar behavior [12:54] Launchpad bug 317944 in udev "Wrong permissions in /dev after Intrepid->Jaunty upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/317944 [12:54] mvo: right [12:55] Keybuk: syslog shows that syslogd was restarted a few minutes after the ctime on /dev/null, which explains why its socket is unmangled [12:55] mdz: no messages from udevd? [12:55] mvo: I don't feel we should do that for feisty, but for gutsy/hardy/intrepid it might be worthwhile? [12:55] Keybuk: hardy-proposed [12:55] pitti: ok [12:56] Keybuk: none (ever, so far as I see) [12:56] the only occurrence of 'udevd' is in dmesg [12:56] right, it'll be in your dmesg history [12:56] kern.log has timestamps [12:57] Keybuk: it's not in kern.log at all [12:57] dmesg.0:[ 20.478679] udevd version 124 started [12:57] dmesg.1.gz:[ 22.546635] udevd version 124 started [12:57] dmesg.2.gz:[ 19.596002] udevd version 124 started [12:57] dmesg.3.gz:[ 18.636002] udevd version 124 started [12:57] dmesg.4.gz:[ 19.456003] udevd version 124 started [12:57] those are the only occurrences [12:57] (notably, it isn't in my current dmesg) [12:58] bug #223324 has 32 dups and seems to be a dup of bug #221781; is there a way to mass fix the dups of 223324? [12:58] Launchpad bug 223324 in scrollkeeper "Parser error in ///usr/share/gnome/help/blackjack/el/blackjack.xml : Entity 'Βοήθεια' not defined" [High,Triaged] https://launchpad.net/bugs/223324 [12:58] Launchpad bug 221781 in scrollkeeper "scrollkeeper crashes during upgrade and causes maintainer script failures for various packages" [Undecided,Confirmed] https://launchpad.net/bugs/221781 [12:59] If not, I think I'll just close 223324 and point at the other bug in a comment [13:00] lool: not that I know of from Launchpad, but maybe bdmurray has a script to do it with python-launchpad-bugs [13:01] I think I heard about such a script in the past [13:02] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-March/000800.htm [13:02] https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-March/000800.html I mean [13:04] james_w: Thanks [13:05] It looks like I should spend some time to clean it up and integrate with u-d-t [13:06] is there anybody working on freetype in ubuntu or talking to upstream sometimes? [13:07] bug #277294 has quite some duplicate [13:07] Launchpad bug 277294 in freetype "evince crashed with SIGFPE, trying to seek in KXTGA930.PDF" [High,Confirmed] https://launchpad.net/bugs/277294 [13:07] doko_: http://lists.gnu.org/archive/html/freetype-devel/2008-08/msg00023.html indicates that could be a gcc issue, could you perhaps investigate this one? [13:27] mdz: just to confirm something [13:27] mdz: /etc/udev/rules.d is basically empty on your box, right? [13:31] Keybuk: upgrade is running, it will be finished in ~30min [13:36] I'm working on a new package. It's somewhat lacking in the clear licensing area. Only a select few source files specify the license, there's no "top level" license file or anything (the few source files with licensing information correctly state the copyright holder and references the Apache license). [13:37] I'm curious what the minimum to ask them to add would be for it to be acceptable for us. [13:37] I suspect this is not uncommon, so perhaps someone has already written up a template bug text for this sort of thing? [13:43] generally a top-level licence is enough [13:43] but that licence will likely say each source file should have a reference to it too [13:43] missing licences from individual source files is a widespread failure/practice (depending on your POV) [13:44] the GPL just says that it's "safest" to add notices to each source file, not that you must [13:45] I think the idea there is that if you don't, people might rip out an individual file and say that they didn't know about its licence [13:45] cjwatson: It's an exception that people do it [13:45] cjwatson: exactly [13:45] mok0: I wouldn't go that far but it certainly isn't anywhere near universal [13:45] we still permit such things in the archive though [13:45] I have never heard of a legal basis for saying that a top-level licence wouldn't apply to the other files [13:46] The problem is: if just a couple of files are missing license clause, is it because upstream forgot, or did he rip the file off somebody [13:46] though if you want your package to enter debian at some point you better add a license note to each single file :) [13:46] a judge would not be looking at the individual files; he/she would be looking at the whole thing, and if there's a top-level file that says "everything in this package is under licence foo", then you'd have a pretty damn hard time persuading the judge otherwise [13:47] ogra: is that a requirement for Debian? [13:47] mok0, not sure, but i had a bunch of packages i had to work on, even if its not, you will drown in a bunch of bugs about it there [13:47] Debian's ftpmasters will complain about inconsistent licences of course, but I've never heard of them complaining about missing licence statements in individual source files [13:47] and I would be extremely surprised if they did [13:48] cjwatson: I've done a ton of reviews, and I rarely see the license clauses included properly [13:48] no, its rather the self declared debian license police that pokes you with bugs about it :) [13:48] some Ubuntu archive administrators have got into the habit of complaining about that, and personally I think it is substantial overkill [13:48] cjwatson: Ok. So if I ask them to add the Apache license to the tarball and have them put a file that said who the copyright holder is and references the Apache license, that would acceptable? [13:48] soren: yes, I'd say so [13:49] cjwatson: Lovely. Thanks! [13:50] I've been telling uploaders that without a license file in orig.tar.gz, we can't distribute the package [13:50] I've also told them to _attempt_ to get upstream to add clauses to indiv. file [13:50] s [13:50] yes, you clearly must have some statement of the licence in the tarball [13:50] well [13:50] actually, I think it's permissible to get an e-mail clarification from upstream and to put that in debian/copyright, pending a new upstream release [13:50] I have done that myself in the past [13:51] cjwatson: that's a good idea [13:52] hello. i use alpha-3 with latest updates. http://www.markshuttleworth.com/wp-content/uploads/2008/12/jaunty904_notifications_example1_web_092.swf - this notification system looks very useful, but how can view it in action? i mean, which apps and what kind of events supports such notifications? and technical question - it's just some impove of notification-daemon, or something else? and where i can find out, which api's in which languages allow to initiate s [13:52] uch notifications? i will be very appreciate for any useful information :-) [13:54] ia: that's work in progress, not (as far as I know) yet in jaunty [13:54] cjwatson: oh, right. just in some news they tells, that it's already can be seen in work :-) [13:58] however, how do you think, it's some layer over notification-daemon, or some brand new notification system? if second, then how it names? [14:03] ia: no idea, sorry [14:06] Keybuk: during my upgrade test in kvm I got no udevd started message (except for one) and the /dev/null permissions look ok too - that was a default ubuntu-desktop base-image that I used for the test [14:06] cjwatson, jharr yes i didn't realize that jharr was building a chroot. thanks for the extra comments === davmor2 is now known as davmor2-away [14:52] james_w, pochu: Pushed new lp-set-dup script in ubuntu-dev-tools [14:54] lool: cool, did you port it to lplib? :-) [14:54] Yes [14:55] ah, nice, thanks [14:56] lool: in the end, bug 78596 should be fixed, but for the meantime that'll be useful :) [14:56] Launchpad bug 78596 in malone "Automatically handle moving duplicates across when duplicating a bug with dupes" [High,Triaged] https://launchpad.net/bugs/78596 [14:56] pochu: Agreed [14:56] james_w, pochu: BTW happy to get any review [14:58] jpds: Hey I pushed some 3/4 ubuntu-dev-tools changes; I'd like to upload the package, but would love you to have a look to check I didn't break anything; how are you building the package? debuild -i good enough? [15:00] lool: looks pretty good to me. Would it be better to do the obvious thing if I request a bug be duplicated against a bug that is already a duplicate of something else? [15:00] though the rarity of that situation and the added complexity of doing a check for circular references may not be worth it [15:01] pitti, back to the foomatic-filters 4.0.0 SRU, all changes (see newest changelog entry in Jaunty package) are bug fixes, and for me it looks like that all are regressions against Hardy. And the Infinite loop when supplying a page range is even a security vulneribility, as a user can block the printing system by sending a job with page-specific option setting. [15:02] pitti, every fix by itself is a small patch (up to 10 modified lines), only the modification to fix the infinite loop is somewhat bigger. [15:03] james_w: I preferred failing and offering the good command line to run [15:03] tkamppeter: do we have some LP bugs which correspond to the changes? please use those for the SRU [15:03] james_w: (just need to copy paste the suggested command line) [15:03] yeah, it's sensible, but a tool telling you *exactly* what to run is normally pretty bad UI [15:04] the safety check may justify it though [15:04] pitti, for the two items mmarked appropriately in the debian/changelog, yes, I can at least add another one for the infinite loop vulnerability. [15:04] james_w: I didn't want to autofix it, but I guess I could prompt to ack the change and proceed indeed [15:05] that could work [15:05] what's the proper way of asking for an application to be included in the default Ubuntu desktop install? [15:06] lool: on line 52, suggestion is unused, isn't it? [15:06] as you're dying in the next line without using it [15:06] pochu: ah thanks, forgot to drop a die() on line 53 [15:07] pochu: (fixed) [15:16] james_w: I implemented prompting to use the duplicate of main bug [15:17] thanks lool, you rock [15:17] Eh thanks for the good comments [15:19] pitti, I have reported the infinite loop problem as bug #318816 [15:20] Bug 318816 on http://launchpad.net/bugs/318816 is private [15:28] pitti, I have also reported bug 318818 now. [15:28] Launchpad bug 318818 in foomatic-filters "Intrepid fails LSB 3.2 tests on foomatic-filters" [Undecided,New] https://launchpad.net/bugs/318818 [15:29] tkamppeter: is the lsb failure actually something to worry about? it's not something SRU worthy per se [15:30] pitti, I do not know how important LSB failures are considered at Ubuntu. Therefore I reported that. Most important is the infinite loop, and all the rest can be considered as regressions against Hardy. === bluesmoke is now known as Amaranth [15:43] https://wiki.ubuntu.com/UbuntuDeveloperWeek to start in #ubuntu-classroom in 17 minutes [15:55] DktrKranz, ping [15:55] pitti: can you have a look at http://launchpadlibrarian.net/21351698/buildlog_ubuntu-jaunty-i386.glib2.0_2.19.5-0ubuntu1_FULLYBUILT.txt.gz ? It looks as if pkgstriptranslations is running twice in parallel on the same package, and the result is a corrupted translations tarball (which is crashing the publisher, which is how we noticed it) [15:57] pitti, apport -- when a report is generated i assume its the reporting script's reposinsibility to prevent a double trigger of the report? === davmor2-away is now known as davmor2 [15:59] could somebody please unban me from #ubuntu.... i made one funny ha ha and somebody screamed for the ops [16:00] apw: double trigger? if you mean it triggers while you are still writing it: you need to create it as 000, write it completely, and then chmod it to 600 [16:00] cjwatson: looking [16:00] grndslm: this isn't an escalation channel - go to #ubuntu-ops, please [16:00] k thanks [16:01] no i mean if i find file /foo and that is my trigger, when i converted that into a spool file, i assume it is _my_ responsibility to remove /foo as well [16:02] cjwatson: ugh, how weird; I don't have an offhand idea, I need to try and reproduce this in a chroot [16:02] apw: it could be done in the apport init script if you don't need it any more for other purposes [16:04] my worry is if we don't will we not file the same bug every boot from then on [16:04] pitti, I have added everything for the foomatic-filters SRU to bug 318816 now (you are subscribed to it) and nominated the bug 303691, bug 299918, and bug 318818 for Intrepid. [16:05] Bug 318816 on http://launchpad.net/bugs/318816 is private [16:05] Launchpad bug 303691 in foomatic-filters "Intrepid, print broken with Minolta PagePro 8L printer" [High,Fix released] https://launchpad.net/bugs/303691 [16:05] Launchpad bug 299918 in foomatic-filters "Cannot print duplex in intrepid with Ricoh Aficio 2060, Ricoh Aficio MPC3000 or Brother HL-4050cdn using the openprinting drivers" [High,Fix released] https://launchpad.net/bugs/299918 [16:05] Launchpad bug 318818 in foomatic-filters "Intrepid fails LSB 3.2 tests on foomatic-filters" [High,New] https://launchpad.net/bugs/318818 [16:05] pitti, ahh we do remove it anyhow, good [16:06] cjwatson: thx for the help. I now realize that with binfmt-support. Somewhere along the line /usr/bin/perl was fine in the chroot, but perceus builds a cpio archive (which was fine) but the kernel apparently has issues decompressing cpio archives that have hardlinked files in them. [16:06] jharr: the *kernel* - are you sure? that should be entirely userspace and using only very common syscalls [16:06] cjwatson: perl was ending up as a zeroed file. [16:06] if link(2) is failing you have pretty bad problems! [16:07] sure, you described the symptoms earlier; I was questioning your attribution of the cause to the kernel [16:07] cjwatson: the cpio archive was the initrd. [16:07] ah, I see [16:07]