[01:13] Interesting, may have found a security hole, maybe not [01:14] Using the built-in desktop sharing feature, the password authentication feature does not work [01:14] The client asks for a password, but the password fails auth [01:14] The ONLY way it works is without a password === cjwatson_ is now known as cjwatson === greeneggsnospam is now known as jsgotangco [03:25] hey guys [03:25] if im running gutsy and i installed the pidgin-dev packages [03:26] and downloaded the pidgin source [03:26] i can expect it to build correctly right? [03:26] You must have libxml2 >= 2.6.0 development headers installed to build. [03:26] i get that message [03:26] no. apt-get build-dep pidgin. [03:27] cool, let me try that [03:27] (you've mistaken pidgin-dev for pidgin-dev's build-dependencies.) [03:28] i see [03:28] that's pretty cool [03:33] crimsun: that worked, thank you [03:33] np. [05:27] when are the gnome 2.20.1 updates going to hit the ubuntu repos? === cprov-afk is now known as cprov-zz [08:29] good morning folks :) [08:51] interesting. [08:51] google fixed liferea === asac_ is now known as asac [10:57] I am getting closer to wubi-7.10 release, would you guys mind testing it? http://wubi-installer.org/devel/minefield/ [10:57] Please make any comment on http://ubuntuforums.org/forumdisplay.php?f=234 [11:46] hi people [11:46] anyone is already in Boston? [12:03] crimsun: ping === annma is now known as ann_away === Mez is now known as Mez|Away === Mez|Away is now known as Mez === Mez is now known as Mez|Away === Mez|Away is now known as Mez === ann_away is now known as annma === zul_ is now known as zul === Mez is now known as Mez|Away === Mez|Away is now known as Mez === cprov-zz is now known as cprov === Mez is now known as Mez|Away === Mez|Away is now known as Mez === Mez is now known as Mez|Away === Mez|Away is now known as Mez === Lure_ is now known as Lure === Mez is now known as Mez|Away === Mez|Away is now known as Mez === Mez is now known as Mez|Away === Mez|Away is now known as Mez [13:31] archive admin available ? [13:55] Tonio_: very unlikely, what were you after? [13:55] Hobbsee: about ppa, isn't there a way to drop a package ? [13:55] Hobbsee: searched for that option for hours without any success [13:56] Tonio_: no. ask in #launchpad, usually, and they can do it, or file a launchpad question on soyuz [13:56] archive admins cant do it [13:56] or just upload a newer version [13:56] apparently we're supposed to get it partway thru this cycle. but they originally said with the rollout yesterday - so who knows when it will *actually* get done. [13:56] Hobbsee: I hope the option is comming along in the next future [13:57] Hobbsee: thanks for the infos :) [13:57] Tonio_: no problem === Pici- is now known as Pici [14:09] <_mastro_> guys.. i've this bug: https://bugs.launchpad.net/bugs/157286 and i want to recompile my kernel without libata to see if i'm right supposing the problem is there... i've downloaded the kernel source (apt-get install linux-source-2.6.20-generic) make menuconfig starting from my actual 2.6.20-generic configu and changed: cpu optimization (Pentium 4), removed new libata support from device driver and readded the depr [14:09] <_mastro_> ecated old sata support i compiled with fakeroot make-kpkg --initrd .... linux_image linux_header) installed the deb packages and rebooted.. after the initrd image when it should start reading from this it don't do anything else... it stay there forever until i hit CTRL+ALT+CANC what's wrong??? i've compiled a lot of kernel on debian without having this issue... what am i missing? [14:09] Launchpad bug 157286 in ubuntu "System really slow like if no DMA from Edgy" [Undecided,New] [15:03] Heya [15:16] I have a patch for apt-url which I think others might find useful, but I'm not [15:17] so familiar with how to go about getting it reviewed/accepted. [15:17] I imagined that posting it as a 'bug' on launchpad would be the best way [15:17] TheNewAndy: have a look at https://wiki.ubuntu.com/MOTU/Contributing [15:17] but launchpad says that it doesn't use the launchpad bug tracker [15:20] <_mastro_> please can you help me debug a kernel problem with ubuntu? i've custom compiled it removing the new sata/pata architecture from device driver (the one that make /dev/hda become /dev/sda) but when i try to boot it stop right after the initrd image, when it should start reading from disk, it stop there and the only thing i can do is pressing CTRL+ALT+DEL and choose another kernel === cprov is now known as cprov-lunch === ryu2 is now known as ryu [15:54] is there a specific package owner for each package in main? [15:56] mdomsch: some of them. not all. [15:56] mdomsch: Not exactly. Many people focus on a few packages, and some teams claim some packages, but it's not a one-to-one mapping. For each package, there is at least one assignable person. [15:56] mdomsch: looking at who's uploaded it recently should give you an indication [15:59] Hobbsee, where do I see who uploaded a package? [15:59] I see the Maintainer line (e.g. if it came straight from Ubuntu) in the control file [16:00] mdomsch: aptitude changelog [16:00] mdomsch: you can query launchpad about it, or you can also look up changelogs.ubuntu.com [16:00] the first and third tend to be quicker. teh first is my preference. [16:00] but the name in the changelog is who made the change, not necessarily who uploaded into Ubuntu [16:01] e.g. the hwdata package === jwendell is now known as jwendell|lunch [16:01] but that's a fair start [16:01] mdomsch: ah, true [16:02] mdomsch: if you want to know who actually uploaded it (and keep in mind, it's the person in the changelog if they're a core dev), go to lists.ubuntu.com/-changes, and decrypt the gpg key :) [16:02] havent found a faster way than that [16:02] LP may show the info now. they keep swapping what they do and don't show. [16:02] mdomsch: by version number, hwdata looks synced. [16:03] the autosyncer is on from that point, so it's likely from that. [16:03] Hobbsee, it's synced to debian, but debian pulls from fedora [16:03] (some of the maintainers of main packages are in debian, not ubuntu) [16:03] mdomsch: right. ie, fedora-specific stuff? [16:04] that's fine, thanks. I'm just trying to get some coordination around this package [16:04] and understand who the players are [16:04] ah, right [16:04] Fedora generates the package, debian pulls it, ubuntu pulls from debian [16:04] mdomsch: for that one, looks like fedora and debian. doesnt look like nayone from ubuntu specifically is touching it :) [16:04] yup [16:04] or, at least, until the autosync gets turned off. [16:04] so I can either poke 3 distros to add a pile of monitors, or I can get it into fedora and wait [16:04] probably. [16:05] it's not that hard to push, if you want to get it here. no idea about debian. [16:05] of course, they might look favorably if you say who you are, and such :) [16:05] and go "he must know what he's talking about. we'll take it" [16:05] * mdomsch emailed noel@debian about how he does it [16:05] cool [16:06] dude, this downloading at 0.9kBps is *not* cool! [16:06] s/kBps/KBps/ [16:06] I've got a little script that downloads all the new monitor files from support.dell.com every week, and generates diffs against Fedora and Ubuntu now [16:06] nice! [16:07] mdomsch: like i say, if you know what you're doing, it's not hard to get sponsorship into main. [16:07] so folks won't be able to complain that their newest 2407WFP-HD monitor isn't listed in displayconfig-gtk [16:07] so you dont have to wait for all 3 distros [16:07] * Hobbsee nods [16:07] i'm impressed - ubuntu actually detects my correct monitor, now! [16:07] first release! [16:08] Hobbsee: Does Kubuntu benifit from this too or does it use another list? [16:08] it's only taken since edgy. [16:08] ScottK: no idea, tbh. i think it uses another list. i think it's also buggy, so no one uses it. [16:08] ScottK: 915resolution is what i've used in the past, just to make the screen readable, without me gouging my eyes out [16:08] Bummer. [16:09] pity mdomsch didnt show up a couple of releases ago. i could have hounded him to fix ti :) [16:09] hehe [16:09] (while it was still broken) [16:09] speaking of which, i should find another battery at some point. [16:10] not worth it at this point in the year, though [16:10] mdomsch: maybe i'll just blame you anyway. [16:12] Hobbsee: Getting to a common list (or Kubuntu can also understand the Ubuntu list) would seem like a worth Kubuntu feature goal. Particularly for an LTS release ... [16:12] ScottK: it would be useful if it actually used the displayconfig backend. but i've no idea how much common code there is. [16:12] X, and display related stuff is not my forte - i tend to stay away, so it doesn't break. [16:12] * ScottK knows there is some because in Feisty there were some conflicts. [16:12] * ScottK too. [16:14] ScottK: i'm deeply unimpressed about how i cant seem to remove the xserver-xorg-video-i810 stuff without X breaking, though. [16:14] i seem to need both that and -intel. [16:14] or at least, under kubuntu i do. [16:14] that's true [16:14] last i knew, they conflicted, so... [16:14] or i'm remembering wrong :) [16:15] tepsipakki: why? [16:15] well, -intel has issues with some chips [16:15] so -i810 is still here [16:16] and the dependancy chain goes up to {k,}ubuntu-desktop, so removing the metapackage would mean removing -desktop as well [16:16] tepsipakki: i seemed to be able to remove it with great problem - i just had no X :) [16:16] fingers crossed that we actually can drop -i810 during hardy :P [16:16] oh [16:17] tepsipakki: or is 965 an issue-filled chip? [16:17] tepsipakki: So my 2 year old hardware will become unsupported? [16:17] er, without great problem [16:17] ScottK: which is that? [16:17] ScottK: debian doesn't have -i810 since -intel 2.0 came out [16:18] OK, so i810 is supported in that? [16:18] ScottK: sure, every chip, but some of them have issues [16:18] Hobbsee: how does it break? [16:19] tepsipakki: OK. I know almost nothing about video, so I get excited when I see talk of what looks like removing support for what I have. [16:19] heh [16:19] Hobbsee: speaking of which, you are an archive-admin?-) [16:19] tepsipakki: i get dropped at a console, with no X. i don't remember more specifics than that, as it was a while ago. [16:19] tepsipakki: FSVO archive admin, yes. [16:19] FSVO? [16:19] for some value of [16:20] Hobbsee: so you can't do syncs? [16:20] Ah. Yes. [16:20] tepsipakki: correct. [16:20] bummer [16:20] yeah, i know. [16:20] great that the archive is open, but a first batch of syncs would've been equally nice :) [16:21] Hobbsee: do you happen to have "i810" in xorg.conf, instead of "intel"? [16:22] tepsipakki: yeah. === Martinp24 is now known as Martinp23 [16:23] tepsipakki: buildds still have plenty to build, due to the autosync. [16:23] but i'd imagine it'll take a couple of weeks [16:23] (conferences and such) [16:23] ah, this one is using intel. [16:23] they do? I see that the new xserver is being rebuilt (and failed) on and on :) [16:24] * Hobbsee wonders why she has an xorg-ati installed [16:24] ahhh [16:24] well, they did last i checked [16:24] tfheen: may be around [16:24] but i think he's in the air by now [16:24] tepsipakki: well it is a new dev cycle :) [16:25] Hobbsee: you probably have all that xserver-video-all depends on :) [16:25] zul: ah, the pain! :) [16:25] tepsipakki: yeah. but cant it pick my card, and deal? [16:25] tepsipakki: it's not like i'm going to swap out my video card :) [16:25] Hobbsee: not yet, but it'll be discussed at FOSSCamp & UDS [16:26] xserver-xorg depends on it [16:26] tepsipakki: cool :) [16:26] autoloading based on the pci-ids that the drivers have [16:27] tepsipakki: can i safely remove the rest? [16:27] yes [16:27] but it'll save you like 2MB :) [16:28] * Hobbsee shrugs [16:29] Hi guys! I'm having problems linking (static) to libalsa09.a [16:29] can anybody give me a hand here? [16:30] forget it... the channel is not for application development under ubuntu... but maybe the problem is raleted to ubuntu [16:32] in the SYMBOL of libalsa09.a (from the libao-dev package), snd_pcm_open (and close) are undefined (I think). Is that normal? [16:32] SYMBOL TABLE; I mean [16:32] Hobbsee: Are universe packages being allowed to build right now? [16:32] 00000000 *UND* 00000000 snd_pcm_hw_params_set_format [16:32] 00000000 *UND* 00000000 snd_pcm_hw_params_set_channels [16:33] 00000000 *UND* 00000000 snd_pcm_hw_params_set_rate_near [16:33] 00000000 *UND* 00000000 snd_pcm_hw_params_set_buffer_time_near [16:33] 00000000 *UND* 00000000 snd_pcm_hw_params_set_period_time_near [16:33] ScottK: i think so [16:33] 00000000 *UND* 00000000 snd_pcm_hw_params [16:33] !paste | antoranz [16:33] antoranz: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [16:33] Hobbsee: OK. Thanks. [16:33] For both the answer and the kick. [16:33] ScottK: no reason why they wouldnt be [16:33] OK. I've got stuff that's been sitting around for a long time, but no trouble. [16:34] ScottK: Main autosync gets priority... [16:34] OK. That'd do it. === cprov-lunch is now known as cprov [17:14] soren: are you going to re-merge pbuilder? (we need the new version to fix a pbuilder-dist bug), or can I do it? (I'll ask you to upload it for me then :)) [17:25] Adri2000: That or just make it work with the current pbuilder. [17:26] ScottK: ah. I'm still waiting for your solution [17:27] Adri2000: Make the authoritative source for the package one I can use and I'll be glad to. [17:28] I'm not sure to understand what you mean [17:29] Adri2000: You keep that package in a bzr repo and I don't do bzr. I'm not learning a new vcs to fix a bug. [17:30] ScottK: http://adrishost.homeip.net/~adri2000/ubuntu/pbuilder-dist [17:30] What about it? === _nightwish is now known as nightwish [17:31] wget it, cp it, edit the new one, diff it with the new one you edited to create a patch you can give me === jwendell|lunch is now known as jwendell === nightwish is now known as _nightwish [18:06] has somebody noticed in Gutsy that Firefox -> Help -> Release Notes pops up Edgy release notes? [18:08] glledo: the only way to find out for sure is to search for a bug [18:08] didnt find any [18:09] ok, lets submit it [18:09] then I suspect that no one has [18:13] doh, bug 140998 [18:13] Launchpad bug 140998 in firefox "Firefox: View Source > Help > Release Notes links to Edgy release notes in Feisty and Gusty (dup-of: 138968)" [Undecided,New] https://launchpad.net/bugs/140998 [18:13] Launchpad bug 138968 in ubufox "The Release Notes Menu on firefox shows ubuntu 6.10 notes" [High,Fix committed] https://launchpad.net/bugs/138968 [18:19] hi === pedro is now known as pedro_ [19:19] Does anyone here how to hide the output from checkinstall when callled in a c program via system("checkinstall args > /dev/null"); or popen("checkinstall args")); [19:21] fork, close stdout, open /dev/null, exec. Now please read the topic. [19:26] kk tnx [19:49] Anyone about can give me some quick guidance for doing SRU updates for hardy and gutsy-proposed ? [19:50] IntuitiveNipple: you won't be doing an SRU for hardy [19:50] IntuitiveNipple: and for Gutsy have a look at https://wiki.ubuntu.com/StableReleaseUpdates [19:50] well no but... step #1 is to create an update for hardy, then one for gutsy-proposed [19:51] I am doing/have done... my questions are more about technicalities [19:51] ah, well yes, you want to make the changes first in Hardy usually [19:51] IntuitiveNipple: ask away and see if anybody knows [19:51] like... is it a case of simply adjusting the changelog entry to read "gutsy-proposed" for the SRU, or does control need some kind of change too? [19:52] <_bernie> hello, I'm looking at the Boston UDS info in the wiki [19:52] IntuitiveNipple: changelog [19:52] I was looking at the emails in gutsy-changes and they show the 'gutsy-proposed' that makes it look like it came from 'control' not changelog, so I was somewhat confused [19:52] <_bernie> I can't find a more a more specific agenda... [19:53] oh good. So, are these steps correct? [19:53] 1. grab the latest source package from the hardy repo, apply the changes, create the debdiff [19:53] _bernie: http://people.ubuntu.com/~scott/uds-boston-2007/ [19:54] 2. grab the latest source package from gutsy-proposed (or, if there isn't one) gutsy, apply the changes (make sure changelog is for gutsy-proposed and LP # is quoted), then create the debdiff [19:54] <_bernie> thanks [19:54] <_bernie> LaserJock: is there anything planned for 27 and 28? [19:54] I don't think so [19:55] 3. Upload both to the LP bug with a rational for why and then Nominate it for release? [19:55] s/rational/rationale/ [19:55] IntuitiveNipple: I would get the fix into hardy first [19:55] make sure it works [19:55] then file the SRU [19:56] but basically you're on the right track [19:56] In these two cases I know they work on Gutsy. [19:56] <_bernie> mako_: hey! [19:57] <_bernie> mako_: are you going to attend to UDS? [19:57] LaserJock: What's the procedure for testing them with Hardy if I'm not running a Hardy install? [19:58] IntuitiveNipple: you can use a chroot or pbuilder environment [19:59] or VMware, VirtualBox, etc. [19:59] ahh of course... pbuilder! I've got them set up for every other release, but I'm on the kernel ACPI team so I rarely stray into packaging... but I'm hacking a few bugs atm [20:00] IntuitiveNipple: one of the reasons to test in Hardy first is typos or packaging mistakes [20:00] LaserJock: I assume the same applies to testing in Gutsy then? Especially when the changes are trivial [20:01] I've just spent the afternoon writing a script to automate package-updates into two commands after discovering what a minefield it is! [20:01] IntuitiveNipple: yes, even more so in gutsy-proposed [20:02] Right... I'll crack on with these debdiffs now ... thanks alot :) [20:23] _bernie: yes, i will attend uds === mako_ is now known as mako [20:30] Interesting, may have found a security hole, maybe not -- Using the built-in desktop sharing feature, the password authentication feature does not work -- The client asks for a password, but the password fails auth -- The ONLY way it works is without a password [20:36] <_bernie> mako: I'm trying to devide which days to go... do you have any particular plans? [20:38] _bernie: i haven't figured it out yet [20:38] but i haven't really looked much either [20:39] mako *hugs* long time no see [20:39] theacolyte: sounds like a fault in the client. [20:39] theacolyte: try with another client. [20:53] Mez: i'm around [20:56] mako, still with OLPC? [20:57] Nafallo: already did, realvnc and ultravnc [20:58] Mez: yep [20:58] good to hear ;) [21:01] Up at 0500 tomorrow, on the plane by 7:30, at Boston by 14:00 [21:01] mako: What's the quickest way from Logan? Subway or Taxi? [21:04] sbalneav: quickest? taxi [21:04] sbalneav: like $25-30 [21:05] sbalneav: alternately take the silver line and red line.. i think i edited the wiki directions [21:05] it's not really that much longer [21:05] cool. [21:05] thx [21:09] I notice apport stopped asking me to submit things, a month ago. [21:14] wasabi: I think they turned that off for release so the general user population wasn't bugged about it [21:14] and we didn't get a flood [21:14] Ahh. [21:23] theacolyte: weird === TreMobyl is now known as Solarion [21:40] Yeah, bug #137406 (and duplicates) covers it. I *had* created a patch but some random search earlier dropped me on an email from Matt Z detailing why it was disabled for R.C. [21:40] Launchpad bug 137406 in update-notifier "apport stopped working" [Low,Won't fix] https://launchpad.net/bugs/137406 [21:52] I'll just put in a bug report probably [22:00] I just created a blueprint for simplifying the Removable Drives and Media window, and the feature specifications page said I should announce it here. [22:00] The window currently requires the user to enter the bash command of the program. This is complicated for new users, who don't know the first thing about the cli. I propose that it be updated to use gui drop-down lists like in the Preferred Applications window. [22:00] The spec is at https://blueprints.launchpad.net/ubuntu/+spec/simplify-removable-drives-and-media [22:02] Is anybody out there? [22:02] evan_pi: I think it probably meant the ubuntu-devel mailing list [22:02] evan_pi: or maybe better ubuntu-devel-discuss [22:03] It mentioned the devel-discuss mailing list and the irc channel [22:07] ok :-) [22:29] Is this correct? "apt-get source -t hardy " fetches the gutsy source even though the hardy repositories are enabled in /etc/apt/sources.list [22:29] IntuitiveNipple: Isn't it 'apt-get source foo/hardy'? [22:30] is it? [22:30] I believe so [22:30] I was going by the man pages and the --help [22:30] no, that doesn't work [22:31] It *seems* as if it fetches the source for the installed binary version, regardless [22:33] actually [22:33] I think it grabs it from the first deb-src it finds [22:33] unless that bug has been fixed, which is possible [22:35] That's very annoying - is there an alternative way to automatically find the location of a source package that isn't currently installed/part of the current release? [22:35] All I want to do is automate generating the debdiffs for hardy and gutsy-proposed, grrr [22:36] IntuitiveNipple: I tried it here and "apt-get source -t hardy package" (or -t gutsy) behaves as expected [22:37] really? what've you got in your /etc/apt/sources.list ? [22:37] IntuitiveNipple: does the package has an other version in hardy already? [22:37] There's one version in hardy repos [22:38] I wonder if it is because i've only added the deb-src lines to sources.list [22:39] IntuitiveNipple: see my test in http://paste.ubuntu-nl.org/42289/ [22:39] IntuitiveNipple: I've also only added the deb-src line, run apt-get update and it worked [22:39] that's what I did here, too [22:41] IntuitiveNipple: which package do you try? [22:42] update-notifier (devscripts works for me too) [22:43] It is apparently there: http://packages.ubuntu.com/hardy/source/update-notifier [22:44] yes, as hardy starts as a copy of gutsy [22:44] currenty gutsy and hardy has update-notifier 0.61 [22:45] hmmm... why would apt-get fetch from gutsy's location if one exists for hardy? Is it some kind of bug in the releases files do you think? [22:47] no, but does it matter if you get the source for 0.61 from gutsy or hardy (they should be identical) [22:47] I think it picks from the earlist source if there's more than one [22:48] it is the same files [22:48] The changelogs should have different 'release' strings, and that's crucial for what I'm doing [22:48] no, they don't [22:48] the changelog will only change with a new upload [22:48] ahhh. [22:49] there was no upload of update-notifier for hardy till now (only the archive copy from gutsy) [22:49] with a pool archive structure for a given version the files are all the same, regardless of release [22:49] ok, so help me understand this. Why does apt-get fetch from the gutsy repo - presumably there's something in the sources files that is over-riding my using the -t release-target [22:50] ahhh... so what you mean is, it's linked on the server? [22:50] that's all they do [22:50] hmmm but that still doesn't explain why apt-get fetches from the hardy repo [22:50] point to where in the pool you can get the file [22:50] I guess because it sees that it can fetch the hardy version also from the gutsy archive which is listed before the hardy one [22:50] hmmm [22:51] geser: that'd suggest re-ordering the deb-src lines might affect it... worth a try [22:52] IntuitiveNipple, If the versions are the same, why generate a debdiff? It seems like maybe you are doing something wrong? [22:52] I think it doess affect it, last I tried [22:53] Nice one geser! Re-ordering the deb-src lines in sources.list so hardy is first has solved it [22:53] I agree with SEJeff [22:54] SEJeff: I'm automating my debdiff patch-creation procedure so once I've solved a bug I call a script and it does the job for me, including updating the changelog, version, release to release-proposed (for SRUs), and so on [22:55] So I need the current source, dupe it, apply the patches, update the changelog, debuild, then create the debdiff [22:55] Which means you should increment the version [22:55] Like 1.2.3-2 or -ubuntu0 or whatnot. The versions still are not the same [22:56] The version wasn't a problem, the problem was apt-get was ignoring the -t option and it seems, from what geser suggested, that the order of the deb-src lines in sources.list affects that... and now it appears to be solved [22:56] So it doesn't make sense that downloading a package of the exact same version from one or the other repo should matter. [22:56] If I download sysutils 1.0 from the gutsy or hardy repo, it is still the same source [22:56] (pretend that is a valid sysutils ver) [22:57] It does, because although for that specific package the contents are identical, I need to be sure the script will work for all circumstances [22:57] Use case of why it would break being? [22:57] This seems like a process problem that you can fix with error checking and defensive programming to me. [22:58] IntuitiveNipple, Your idea is really cool though. A lot of people would appreciate it [22:58] IntuitiveNipple: your real question is if -t is respected if they *aren't* identical packages [22:59] LaserJock, And if they aren't identical packages + the version number is the same, an MOTU should be flogged :) [22:59] SEJeff: sure, but I think he's wanting non-identical version numbers [22:59] SEJeff: The process for bug-fix updates, as explained to me, is to first create a fix for the developmeny release (hardy) which might or might-not have the same version as gutsy (doesn't matter if it does or doesn't), then do the same for gutsy-proposed and create an SRU. My script reduces the packaging step in each case to two commands. [23:00] LaserJock: The path used by apt-get is now reported as being hardy when i use -t hardy so I'm happy - as long as it is consistent [23:00] ok [23:01] IntuitiveNipple: I don't want to necessarily discourage you, but that sounds like a really bad idea :-) [23:01] *nods* [23:01] SRUs need lots of focused attention to every detail [23:01] IntuitiveNipple: I guess "apt-get source -t gutsy update-notifier" tells you that it got it from hardy now. [23:02] and there's no way that a bug fix in hardy will apply the same to gutsy, etc. [23:02] so I would really discourage automatic SRU scripts [23:02] All I do now is "debdiff-package.sh [-g [-t release] [--proposed] [-b base-dir]]", apply the fixes to the source, and then do "debdiff-package.sh" and it does the whole job for me [23:03] geser: Grrrr yes! [23:03] jordi: pong [23:03] LaserJock: The two releases are dealt with separately, totally independently - two passes of the process [23:04] right, but still [23:04] so you script changes the version and release, and makes a debdiff, and that's all? [23:05] I simply take the patch from my development tree, apply it to the source, and it gets packaged. I will do that for hardy and again for gutsy-proposed, with two sets of testing. But the script saves me messing about on the command-line [23:05] so it doesn't do any more than I mentioned? [23:07] It fetches the current source, dupes to the .orig directory, stops to let me apply the changes, then runs diff, asks for the patch title, suggested the name of the patch-file, runs dpatch, then updates the changelog version and possibly release (to -proposed) and asks me for the filenames and description of each change which it formats and adds to the changelog, adds my sig, then calls debuild and finally debdiff [23:08] I get a set of y/n prompts at key points with the option to over-ride [23:08] k [23:09] that doesn't sound too bad [23:09] IntuitiveNipple: what happens if the package doesn't use dpatch? [23:09] I wouldn't do it, but well, that's me [23:09] geser Then I do it manually [23:10] I rarely mess with packages so when I do I don't want to be pissing about re-remembering all the steps. [23:10] but for me it's remembering the steps that makes me confident in what I'm doing [23:10] as perhaps the steps have changes since last I did it [23:11] but that's just me [23:11] I prefer automated tools to handle repetitive tasks; I focus on the stuff the computer can't do [23:11] I do everything manually [23:11] Working on the kernel is so much easier than messing about with packages :) [23:11] I can understand that, but I find many packaging taskes are not really repetitive [23:12] The only involvement I'll have is applyin bug-fixes, so the steps I need to be involved in will generally be the same everytime [23:13] except if they change ;-) [23:13] which basically boils down to creating a debdiff and attaching to an LP bug report for someone else to deal with [23:13] Easy enough to amend the script to deal with changes, and then forget it again === fbond_ is now known as fbond === chuck_ is now known as zul