[00:00] but it's not a problem to have (>= 2.1.3-9) :) [00:00] anyway I won't insist on that change [00:00] but I think you might want cairo-dock-dev (<< 2.1.3-10-lucid.1~) too [00:01] mmh, yes maybe you're right [00:03] * persia gets a little disturbed by the packaging message "warning: using ubuntu without xulrunner-dev. we reccomend installing it" : that at least deserves some attribution definining "we". [00:06] persia: which package? [00:06] micahg: I got the message building mongodb source. I'm unsure which package generates it. [00:06] persia: k, seems weird [00:07] At least surprising. [00:18] * jdong scratches head at http://i.imgur.com/fWsQv.png [00:19] jdong: Why is this confusing? [00:20] persia: trying to figure out what usecase this is for. [00:20] People giving presentations. [00:20] I've always moaned about the usefulness of OOo Impress vs Powerpoint [00:20] but this seems like a step in the opposite direction [00:20] maybe I'm being too critical on version 0.1 [00:21] jdong: 1) you're being critical on version 0.1 2) lots of folks don't need fancy stuff (like me), and prefer to just have a few lines of text with a fairly standard background. [00:21] That said, consider abiword, gnumeric, etc. [00:21] S5 is pretty good for simple presentations [00:21] I totally support (2), but I don't think (2) involves removing features from a more powerful presentation tool [00:21] (and hey, if people want to do stuff, and they enjoy it, let'm do it: maybe something wonderful will happen) [00:22] I agree with the latter [00:22] jdong: Based on racarr's blog entries, I think it's a matter of only having completed the framework and now adding features, rather than stripping an existing tool. [00:23] persia: *nods* I'm just a bit bitter from my experiences using Powerpoint vs OOo impress to put together simple presentations.... [00:23] counterintuitively, I found PowerPoint much easier to use in that I spent less time wrestling with the tool [00:24] nice touches like automatically transforming bulleted lists (outlines) into flowchart graphics [00:24] jdong: You could always use tex [00:25] persia: yup, that's typically been what I've done -- except the TeX slide-making software suffers from the general problem with TeX in my experience -- god forbid you actually want to tweak an existing style/template [00:25] Of course you don't. Clearly, you want to write your own :) [00:26] hehehe that actually does sound like fun [00:26] * persia used to love TeX and is now somewhat happier to admire it's glory from afar [00:26] *nods* :) [00:26] But *no* other tool I've ever seen lets you do what TeX lets you do. [00:27] TeX is bigger and more muscly than you: fight it at your considerable peril [00:27] Indeed, but if you can make freinds... [00:27] I still love TeX a lot [00:27] May you continue to do so for many years [00:28] I sure hope so :) [00:28] erm [00:28] * Laney spies a lot of dpkg-shlibdeps warnings [00:28] The key to continuing to get along is to never end up not using it for a protracted period. Relearning TeX is harder than learning it the first time. [00:41] matttbe: cairo-dock doesn't seem very multi monitor aware :( [00:41] (uploading the plugins) [00:42] matttbe: of course yes :) it depends of what you have set in Position [00:42] with xinerama (Advanced mode) [00:42] I'm just talking about the first launch [00:43] mmh yes, it's maybe better to enable xinerama and set the monitor 0 by default? [00:43] I wouldn't know what the potential implications of that are ;) [00:44] :) in fact, no developer has a dual monitor :) [00:44] so when there is a bug, it's hard to fix it :) [00:44] is there any reason why ${shlibs:Depends} isn't on the integration package? [00:45] no problem for me except with libGL.so because I've installed nvidia drivers from nvidia website [00:45] shouldn't be a problem [00:45] I'm going to add it and upload [00:45] no ! [00:45] sorry, I'm tired :) [00:46] integration package doesn't require the dependencies [00:46] thanks fabounet :) [00:46] they are not loaded if the librarires is not present on the user's system [00:46] this is because [00:47] they are plug-ins to bind the dock with the Desktop Environment [00:47] like GVFS, KIO, Thunar-VFS [00:47] Laney: so do not add it :) [00:47] I thought we recommended against xinerama setups these days. [00:47] Laney: this is the reason that I've split integration plug-ins [00:47] fabounet: what do you think of (01:43:15) matttbe: mmh yes, it's maybe better to enable xinerama and set the monitor 0 by default? [00:47] ok [00:47] the correct plug-in is loaded according to your system, the others are ignored [00:48] ok [00:48] I'm not sure this is a clean solution, but it's what we already have [00:49] well for now it's just a matter of enabling the option in the config panel, it's 1 click [00:49] it could be done by default if we think it's definitey better to have the dock on one screen than on the middle of two screens [00:49] I can't say since I don't have dual screen ^^ [00:50] but it's not useful on the middle of two screens :) [00:53] are we going to start using the debian packages? === RoAkSoAx_ is now known as andreserl [00:54] thank you for the upload Laney ! [00:54] no worries [00:54] I hope that in the future we can sync the packages from Debian [00:55] so please try to work with the packaging team there [00:55] Laney: mmh, I don't know because we had many problem with the debian packagers :) . Deb packages are already done but he want to rebuild it [00:55] but yes, I will try to do that [00:56] they have quite a particular view of the packaging, like splitting the plug-is package into 30 packages (1 for each plug-in) [00:56] that's not so unusual really [00:57] it makes sense in the context of a package manager too [00:57] but he has split all plug-ins into different packages, I don't know if it was for the fun or not but it's harder to manage [00:57] it can be good but he only split the binaries and not the data... [00:57] yes, of course [00:57] that's the approach I'd favour to be honest [00:58] but alas, it's time for bed [00:58] goodnight [00:58] I don't like this way for many reasons, but the packager has accepted to make a meta-package that group all the packages in 1, so this is a good solution I think [00:58] thank you Laney and good night [00:59] (yes, having a metapackage is also common and a good idea) [00:59] (breadth + depth) [00:59] byeee [00:59] thanks, good night === RoAkSoAx_ is now known as andreserl [01:22] matttbe: he needs to build every package he uploads himself for (i hope) obvious reasons. [01:24] carstenh: yes I understand, it's obviously! [01:25] carstenh: do you know what we have to do now? Just waiting? [01:26] matttbe: I don't know what you want to achieve [01:26] and I didn't read the whole backlog [01:27] :) we want to update two packages in Lucid [01:27] to fixed a annoying crash [01:28] sorry, no idea. someone with upload permissions needs to upload it but I don't know what the recommended way to find a sponsor/uploader is. [01:29] ok, I'll be back tomorrow! [01:29] oh, and I hope you talked about he wanted running dpkg-buildpackage himself, recreating the packaging is useless [01:29] matttbe: Didn't Laney just sponsor your stuff? [01:30] persia: he has merged my branch into lp:ubuntu/cairo-dock (and plug-ins) [01:30] so I suppose he did the job [01:31] I beleive he merged and uploaded. [01:32] persia: so what we have to do now? just waiting? [01:32] matttbe: Yep. You can see the uploads at https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= [01:33] Now you're waiting for an archive admin to approve them. [01:33] This isn't likely to happen prior to the RC release. [01:33] (which is on the 22nd: today for some, tomorrow for others) [01:34] oh great ! Thank you for your help persia [01:34] matttbe: No problem. Just remember the procedure we went through at the beginning. That ought get you sponsored when you need it in the future. [01:35] yes, ok! [01:35] just another question: when do you go to sleep persia :) ? If I remember well, you lives in Japan [01:35] It's 9:30 am here, so it's a normal time to be awake. [01:35] ah ok :) [01:35] That said, I'm not particularly diurnal, so there's no good answer to the question. [01:36] :P [01:38] YokoZar: It's part of the ubuntustudio packageset. I didn't go so far as to check the seeds. Let me look into it. [01:38] ScottK: persia clarified [01:38] * ajmitch didn't think that persia actually slept [01:38] What was rhe result of the clarification? [01:38] ScottK: it's a build-depend of the package that was FTBFS earlier [01:38] * ScottK only skimmed 20 hours of backscroll [01:39] So is it urgent to get in and does ubuntustudio care? [01:39] No and yes. [01:39] It would be lovely to get it in just *after* RC release. [01:40] As most commercial plugins use VST, which is the bit that FTBFS. [01:40] ScottK: dssi-vst is part of ubuntustudio-audio and is FTBFS because of the wine stuff [01:40] But images wouldn't be tested if there was a respin now. [01:40] Well we could update Wine1.2 and Wine but not dssi-vst and that woulnd't cause a respin would it? [01:40] Either way I suppose it's best to just wait after RC [01:40] library dependencies ... [01:41] Thank you. [01:41] Is wine-1.2 a run time depends or just build-time? [01:41] That's my thought. [01:41] * persia checks [01:41] ScottK: wine1.2 or wine can satisfy runtime depends, but wine 1.0 is needed as build dependency, and wine1.0 currently has no binary packages because the dummy packages in wine1.2 (which my upload removes) were overriding them [01:42] Depends: libwine [01:42] so runtime [01:42] persia: I'll also need to do an update of dssi-vst as well [01:42] persia: that's basically a rename in the control file and rebuild [01:43] Then I either need the appropriate Ubuntu Studio person to say they want to respin for this (and get slangasek to agree to do it) or it needs to wait [01:43] yeah have it wait [01:43] waiting sounds easier to me [01:44] I'm confident that Ubuntu Studio testers won't be able to run through the tests again if there is a respin. [01:44] (although I'm not the appropriate person) [01:45] slangasek would strongly counsel the Ubuntu Studio people not to do a respin at this stage [01:46] That's what I figured it added up to. === rgreening_ is now known as rgreening [01:47] But I was also 10 hours in meetings today with 2 1/2 hours of driving on each end, so my level of focus is not ideal. [01:51] I agree with persia, we struggle to get Ubuntu Studio images tested once, twice probably would not happen [01:52] * persia suspects ScottL might qualify as the appropriate person [02:02] * TheMuso doesn't think we should respin. [04:45] ScottK: ping [04:45] micahg: Pong [04:45] ScottK: hi, I just realized I forgot about a package in universe that might need to be upgraded, but I wanted your opinion [04:45] OK [04:46] ScottK: mantis is currently at 1.1.8 and 1.2 was released about a month ago [04:46] ScottK: 1.2 has a lot of new stuff and no more releases are planned for 1.1.x [04:47] Unless the release is known to fix important bugs/the current one is badly broken, it's probably better to wait and backport from maverick. [04:47] ScottK: but there are DB changes between the releases so it's not a simple upgrade [04:47] Even better reason to wait. [04:47] ScottK: ah, ok, didn't know that was a good option, ok, I'd prefer to do that actually [04:47] micahg: I'm glad you pinged. I wanted to discuss your libjdic-java upload with you. [04:48] ScottK: yes [04:48] Due to the xulrunner specific bit in debian/rules, the package needs updating each time the xulrunner version changes, right? [04:49] ScottK: each major version change, not minor I hope [04:49] Wouldn't in make more sense to build-depend on the versioned xulrunner directly? Then all the archive management tools we have would catch this as a package that needed attention. [04:50] As you have it now, it can sliently become unbuildable if xulrunner-dev starts pointing at a new version. [04:50] ah, you're saying build on xul-192-dev instead of xulrunner-dev [04:50] Yes [04:50] ScottK: makes sense [04:50] ScottK: do you want to reject the upload and I'll make that change [04:50] micahg: I'll reject the current upload and you can reuse the same version number. [04:50] ScottK: great, I'll have chrisccoulson upload the new version tomrorow [04:51] OK [04:51] Done [04:52] the new version from Debian actually FTBFSs, so that's why we kept this version [04:52] * ajmitch obviously needs to do more to keep the queue busy [04:52] ajmitch: Yes. Please. [04:52] micahg: Keeping the version that builds is great. [04:52] ScottK: I promised to fix it for the next release :) [04:53] it's the same upstream version though? [04:53] ajmitch: yes [04:53] * ajmitch was wondering why you hadn't merged in the other 3 debian revisions there [04:53] ajmitch: I just started handling the xul rdepends :) [04:53] brave [04:57] ajmitch: hopefully the bravery will be enough to let me be a MOTU :) [04:58] You've got to survive the bravery first. [04:58] * micahg wonders if he should start fishing for testimonials... [04:58] That's always the tricky bit with being brave. [04:58] micahg: IME sponsors will start to tell you when they think you're ready. [04:59] ScottK: ah, yes, I've heard that [04:59] When you're really ready they make the application for you, but AFAIK that's only happened once and it was for core-dev. [05:00] I've gotten better, the first several uploads, it took me 4 or 5 debdiffs before I had it right, now it's usually one or 2 [05:00] That's good. [05:00] Another good sign is when people start being suprised you aren't a MOTU already. [05:00] * micahg should be patient [05:08] ajmitch: libjdic patch is attached to the bug if you want to sponsor :) [06:41] wgrant: ping [06:42] evening peeps [07:35] persia: original branch is lp:~ubuntu-dev/ubuntu-dev-tools/syncpackage === hannesw_ is now known as hannesw [08:50] micahg: Hi. [08:51] wgrant: hi [08:52] wgrant: I was wondering if I can request a xulrunner rdepends category for the multidistrotools [08:52] wgrant: for next cycle [08:54] micahg: Not much seems to depend on xulrunner itself -- do you want xulrunner-1.9.2? [08:54] wgrant: yes, the binary and build rdepends on xulrunner-1.9.2, xulrunner-dev, or xulrunner-1.9.2-dev would be great [08:57] wgrant: also any xul-ext* binaries would be great too [08:57] wgrant: or rather their sources [09:01] wgrant: would it help if I give you wiki pages with the source pkg names? [09:04] micahg: If there's a list that's kept up to date, I can scrape that. [09:04] Otherwise I'll work out the rbuilddepends stuff. [09:04] wgrant: I don't know if it'll be kept up to date [09:21] good morning [09:59] Hey guys! [10:00] there was a problem with the compilation of the new version of Cairo-Dock https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/568083 [10:00] Launchpad bug 568083 in cairo-dock-plug-ins "Please update Cairo-Dock to v2.1.3-10" [Undecided,Fix released] [10:01] I see in the buildlog that plug-ins have been compiled with the 'old' version of cairo-dock-core and cairo-dock-dev (the API) (2.1.3-6) and not with the new version as core (2.1.3-10-lucid). [10:01] I've added a restriction (cairo-dock-dev (>= 2.1.3-9)) but it has downloaded the old version (Get:160 http://ftpmaster.internal/ubuntu/ lucid/universe cairo-dock-dev 2.1.3-6-0ubuntu1 [106kB]) [10:02] So the package needs to be re-compiled [10:02] without any changes [10:02] what can I do? === james_w`` is now known as james_w [11:14] is this warning also true for upstart jobs ? http://pastebin.com/DjeLRJEf [11:19] upstart jobs are in /etc/init/blah.conf [11:19] not in /etc/init.d/blah [11:20] c_korn: it's a bug in lintian to show that warning for upstart jobs; the current lintian in lucid isn't supposed to show that warning for upstart jobs [11:20] * hyperair wonders why debian doesn't switch to upstart. it seems to be really awesome. [11:21] hm, there is just a file "upstart" in the debian directory. so it gets installed to the wrong directory ? [11:22] (the debian/rules uses cdbs) [11:22] man dh_installinit [11:22] cdbs should also call it [11:23] hyperair: because upstart doesn't support non-Linux kernels [11:23] c_korn: what version of lintian are you using? [11:23] slangasek: oh =( [11:23] slangasek: why not? [11:24] hyperair: because it relies on lots of cutting-edge (non-standard) Linux kernel features to do its job [11:24] slangasek: ah i see. [11:26] slangasek: 2.3.4ubuntu2 [11:26] c_korn: link to the package? [11:27] (the wiican package) [11:27] http://revu.ubuntuwire.com/revu1-incoming/wiican-1001021618/wiican-0.2.1/debian/ [11:27] http://revu.ubuntuwire.com/p/wiican [11:27] Hello, anyone here who works on the evtouch package? [11:30] c_korn: aaah, why in the world is that device mode 0666? [11:30] c_korn: ok, double-checking here, it seems that the lintian check is still buggy [11:31] c_korn: lintian should not warn about missing rc?.d symlinks for upstart jobs, because the /etc/init.d/ script is just a compatibility wrapper [11:34] c_korn: btw, 'invoke-rc.d udev restart' in the postinst is wrong; you should be calling udevadm trigger --subsystem-match= --action=change [11:35] lrwxrwxrwx root/root 0 2010-04-22 11:32 ./etc/init.d/wiican -> /lib/init/upstart-job [11:36] yes [11:40] If i want to get a touch screen added to the evtouch package whats the best way of doing it please? === nobawk is now known as zz_nobawk === zz_nobawk is now known as nobawk === nobawk is now known as zz_nobawk [12:49] Hi everybody! There is a high importance bug in netbeans package. Should I follow a SRU to fix it or there is a chance to get an approval from motu-release and upload as an exception? [12:50] juli_: We are still accepting bug fixes. [12:50] So I'd suggest try to get it in for release. It will be easy enough to retarget to an SRU if it doesn't make it. [12:51] ScottK, thanks! so I should create a debdiff for a fix and ask an exception ... where? [12:51] juli_: If it's just a bugfix you don't need to ask the release team, just subscribe ubuntu-sponsors. [12:52] actually I have rights for upload of netbeans package.. but I thought it is a freeze [12:53] juli_: There is, but the releae team will review it in the queue after upload. [12:54] Formal FFe is only needed for new features. [12:54] At this point we just review everything. [12:54] ScottK, so for me it is the same upload as usually, right? [12:55] matttbe: You should find out why the versioned BD didn't work and then ask for it to be uploaded again [12:55] Hello, the latest version of Cairo-Dock-Plug-Ins has not been compiled with the right version of Cairo-Dock. I've reported the bug, the branch and the patch there : https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/568083 [12:55] Ubuntu bug 568083 in cairo-dock-plug-ins "Please update Cairo-Dock to v2.1.3-10" [High,Confirmed] [12:55] juli_: Yes. Please just be sure to explain yourself well in debian/changelog [12:55] ScottK, ok, thank you a lot! [12:55] juli_: ping me after you upload and I'll look right away. [12:55] Laney: I see in the buildlog that plug-ins have been compiled with the 'old' version (2.1.3-6) and not with the new version as core (2.1.3-10-lucid). I've added a restriction (cairo-dock-dev (>= 2.1.3-9)) but it has downloaded the old version (Get:160 http://ftpmaster.internal/ubuntu/ lucid/universe cairo-dock-dev 2.1.3-6-0ubuntu1 [106kB]) So the package needs to be re-compiled [12:56] ScottK, ok [12:56] matttbe: yes, but *why* didn't the version constraint work? [12:57] shouldn't this be enforced in the upstream configure script as well? [12:57] I don't know... maybe a bug with the builder [12:57] no, I doubt that [12:57] :) [12:58] laney@pheasant> dpkg --compare-versions 2.1.3-6-0ubuntu1 ge 2.1.3-9 && echo yes ~ [12:58] yes [12:58] see [12:58] it's the version constraing that is broken [12:58] In any case a new upload will solve it and please do so soon, I'd like to get as much Universe stuff in now before the Main post-RC changes take the builders [12:58] ScottK: hey, should we still ping an archive admin for sync req or use pitti's script? [12:58] Laney: yes but there is an restriction... [12:58] I know, but I'm saying that is is *not working* [12:58] yes I see [12:58] probably because of the - in the upstream version, but I'm not sure [12:58] anyway I'll upload the rebuild [12:59] Laney: I've post a tiny patch [12:59] that doesn't fix the issue, but it should be alright anyway as the new cairo-dock has been published now [13:01] Laney: with the previous version (2.1.3-6) this restriction worked: it failed for some arch because the version of cairo-dock-dev wasn't >= 2.1.3-6 [13:02] it works if you put a - at the end [13:02] I'll do that [13:02] (but it would be easiest if you just used . in your versions) [13:03] Laney: ok I see [13:05] Laney: BTW thank you for you help and sorry for the problem :) [13:06] these things happen ;) === vish is now known as mac_v === mac_v is now known as vish [13:22] Is it safe to push a packaging branch which I merged using import-dsc? [13:22] as in, the importer hadn't caught up with Debian [13:27] Laney: If you don't upload now, you may miss the pre-RC window. [13:27] juli_: ^^^ [13:27] I'm about to be away for a while and I don't know exactly when it will come out. [13:28] ScottK: test building [13:28] OK. [13:28] I can upload without doing that if you want [13:28] Go ahead and upload and then once you're done ping me it's OK to accept. [13:29] If it doesn't go well it's easy enough to reject. [13:29] ok [13:29] ScottK, I've just uploaded... hope it is not too late [13:34] Shouldn't be. [13:35] Greetings. [13:36] ScottK: seems good, please accept [13:36] ScottK, I also attached debdiff to a bug in case if you want to see the changes [13:37] ScottK: I'm also uploading a merge of pandoc [13:38] to fix FTBFS on sparc and armel [13:39] OK. [13:48] ScottK, thank you! === ogra_ is now known as ogra [14:20] I'm not getting any mail from soyuz about the pandoc upload [14:24] oh, but it is in the queue [14:25] ScottK: Can we discuss hardware issues? [14:33] ScottK: can you accept glabels please? I've updated to the new version in Debian and synced in Ubuntu. It fixes an issue with new glib: you can now add items to your label instead of having a segfault :) [14:43] huhu RainCT [14:43] Hey sebner [14:46] persia: are you around? [15:17] directhex: I adid accept it. [15:18] Zombie: I'm reasonably certain I'm not the right person to talk to. [15:18] directhex: Sorry, that wasn't meant for you. [15:18] moo? [15:19] It was meant for didrocks and since he's not here, you got the tab complete. [15:20] ScottK: I'm there :) [15:20] ScottK: but if you are using weechat, there is some weird tab complete with it at least [15:20] didrocks. Odd, my client doesn't show you. [15:20] ScottK: oh? [15:21] ScottK: well, in any case, thanks for accepting it :) [15:21] You neither show up in the user list nor are available for tab complete. [15:21] ScottK: which client are you using? [15:21] didrocks: We are still processing sync requests, so you could have filed it as a normal one, FYI. [15:21] didrocks Quassl [15:21] ...sl/sel [15:22] ScottK: ok, I wasn't sure about using pitti's script or not. I'll file new one if needed as normal [15:22] well, I'll ask to nijaba, he is using the same client [15:22] others seems to see me [15:23] don't know if bip proxy is putting a weird property on the server side :/ [15:42] YokoZar: wine1.2 is accepted once it's built/published on the archs it build on, feel free to upload whatever it was that need to come after it. [15:59] kreuter: Am now. Fiddling with diffs. [15:59] persia: great. let me know if anything doesn't make sense. [16:00] ScottK: there is a bug-fix/security update for vlc today, can we still take that, or do we need to wait for SRU, only non-bug fixes are translation updates [16:00] kreuter: Not so far, although some of the diffs didn't apply cleanly to the package: it's more a matter of getting distracted in the middle. [16:00] micahg: If it can be built/tested by ~Sunday we can probably take it. [16:01] It shuld have testing beyond "it builds" [16:01] u/ou [16:01] ScottK: I'll see what I can do, thanks [16:01] if I get lucky, it'll get into Debian before then :) [16:21] micahg: Is there any reason that Build-Depends: and Depends: xulunner-dev should cause issues? Some other patches are required for xulrunner-1.9.2-dev, but I'm wondering how tight to set build-deps/deps [16:21] persia: for which package? [16:21] micahg: bug #557024 [16:21] Launchpad bug 557024 in mongodb "mongo / mongod as packaged can't load libmozjs.so" [Undecided,New] https://launchpad.net/bugs/557024 [16:21] The patch doesn't apply, so I'm pulling out bits. [16:22] persia: I'm sorry, should I generate another patch? [16:22] persia: how are you doing mozjs? I made a wrapper for another app [16:23] I might have taken that diff against our upstream master, not 1.2.x. [16:23] persia: it seems that if you're using xulrunner-1.9.2 script to get the GRE/dir then you should directly depend on the appropriate dev package [16:23] micahg: Is that best practice, or is there another way kreuter should do it? [16:24] persia: it's best practice for now AFAIK ( I assume you're talking about mozjs) [16:24] micahg: Yep. OK. Thanks. [16:25] persia: here's what I did for edbrowse: http://launchpadlibrarian.net/43565621/edbrowse_3.4.1-1_3.4.1-1ubuntu1.diff.gz [16:25] kreuter: No worries: it's close enough: I just wanted to also check that it's right. [16:25] * micahg wonders how we missed that [16:25] micahg: Right. Thanks. [16:26] micahg: For future note, kreuter is upstream+Debian maintainer, so if you run into issues with mongodb in the future, he can probably make sure we don't need much divergence. [16:26] I'm not the debian maintainer. [16:26] Antonin Kral is. [16:27] kreuter: You're not? You're listed as "Maintainer" in the diff in the bug. [16:27] persia: I'll subscribe myself to the package in case there are xul issues [16:27] persia: that's because we (10gen) make debian packages too, and so we need something there in the upstream control file. [16:27] Ah, it all makes sense now. [16:28] micahg: Cool. Thanks. [16:28] micahg: AFAIK, there are no xulrunner issues, just that 1.9.1 got deprecated very recently. [16:28] kreuter: we dropped it from Lucid [16:28] kreuter: in ubuntu we havn't had mozjs since xulrunner-1.8 though === bdrung is now known as bdrung_home === keffie_jayx_ is now known as effie_jayx [16:47] matttbe: is the package alright now? === zz_nobawk is now known as nobawk === traveller__ is now known as traveller [18:42] does cdbs require a series file? [18:45] ari-tczew: the simple cdbs patch system? no, it applies them in lexicographic order (series is part of quilt) [18:45] thanks! [18:45] Note that many CDBS packages use quilt. [18:45] but you can use cdbs (the packaging style) with quilt [18:46] I'm checking patch system by $ what-patch [18:46] then cdbs is the "simple-patch" patching system from cdbs [18:51] I'm trying to make some sense of apt/repo terminology. It seems that debian and ubuntu use suite and codename differently. Is there any glossary explaining this stuff? [18:52] samgee: How do you find them different? I don't pretend a perfect understanding, but I thought the terminology was the same. [18:58] persia, I read somewhere that debian uses codename as the development codename and when it releases it should be known by its suite name (stable, testing, ...). Ubuntu seems to use codename for the whole release (hardy) and suite for the "sub-releases" (hardy-updates). [18:59] Ah, OK. [18:59] So codename/release name is handled the same. [19:00] So, Debian lenny became Debian 5.0 on release, and Ubuntu karmic became Ubuntu 9.10 on release. [19:00] well, that's yet another way of looking at it [19:01] The difference in suite handling exists: Ubuntu has spearate suites for updates, whereas debian has -proposed-updates which get folded into the release directly. === yofel_ is now known as yofel [19:11] samgee: I know only of the LP API documentation, and it's also mentioned on the +queue pages (and probably others) [19:11] samgee: And if this doesn't make it clear: you really don't need to know the answers to use the tools :) [19:13] persia, I know, but I'm working on a script to handle a repo and I'd like it be understandable by everybody, so I want to use the common terms [19:14] Ah, this makes more sense. You might look at some other scripts (falcon, reprepro, launchpad, dak, mini-dinstall, etc.) to see if you can crib from there. [19:14] I've looked at some python-apt source code and other code/docs. There seems to be a lot of confusion about it. [19:18] searching web for ubuntu+codename+suite+pocket doesn't give much useful results. There's lots of stuff you can apparently stick in your pocket, though. :) [19:19] samgee: in debian dak (from an external view, internal things are more complicated), the tool that does everything that is related to the archive, decides to which "suite" it moves your package depending on the changelog entry, though there are exceptions, e.g. there is no stable-security subdirecctory under dists. [19:22] samgee: http://www.debian.org/doc/developers-reference/pkgs.html#distribution [19:22] carstenh, that's more of an explanation about what it's for. I'm looking for a simple explanation about what it is. [19:26] ScottK: I have a bug fix for sbuild, is universe frozen now? Can I upload it? [19:26] mdeslaur: Upload away [19:26] thanks ScottK [19:27] samgee: oldstable is the former release, stable is the current release, testing is the next release, unstable contains packages that move to testing when there are no problems with them after normally 10 days, experimental contains experimental stuff that is not ready for unstable, *-proposed-updates are packages that are proposed by a debian developer for inclusion in the distribution, which release manager decide [19:28] samgee: but i guess i still don't understand your question :) [19:31] (and the releasenames are symlinks pointing to oldstable, stable and so on, changing these is called releasing ;)) [19:31] carstenh, I'm looking for a definition of codename and suite that my mother would understand. [19:31]