[01:13] <theacolyte> Interesting, may have found a security hole, maybe not
[01:14] <theacolyte> Using the built-in desktop sharing feature, the password authentication feature does not work
[01:14] <theacolyte> The client asks for a password, but the password fails auth
[01:14] <theacolyte> The ONLY way it works is without a password
[03:25] <gcarrillo> hey guys
[03:25] <gcarrillo> if im running gutsy and i installed the pidgin-dev packages
[03:26] <gcarrillo> and downloaded the pidgin source
[03:26] <gcarrillo> i can expect it to build correctly right?
[03:26] <gcarrillo> You must have libxml2 >= 2.6.0 development headers installed to build.
[03:26] <gcarrillo> i get that message
[03:26] <crimsun> no.  apt-get build-dep pidgin.
[03:27] <gcarrillo> cool, let me try that
[03:27] <crimsun> (you've mistaken pidgin-dev for pidgin-dev's build-dependencies.)
[03:28] <gcarrillo> i see
[03:28] <gcarrillo> that's pretty cool
[03:33] <gcarrillo> crimsun: that worked, thank you
[03:33] <crimsun> np.
[05:27] <DShepherd> when are the gnome 2.20.1 updates going to hit the ubuntu repos?
[08:29] <sebastian^> good morning folks :)
[08:51] <pwnguin> interesting.
[08:51] <pwnguin> google fixed liferea
[10:57] <xivulon>  I am getting closer to wubi-7.10 release, would you guys mind testing it? http://wubi-installer.org/devel/minefield/
[10:57] <xivulon> Please make any comment on http://ubuntuforums.org/forumdisplay.php?f=234
[11:46] <annma> hi people
[11:46] <annma> anyone is already in Boston?
[12:03] <jordi> crimsun: ping
[13:31] <Tonio_> archive admin available ?
[13:55] <Hobbsee> Tonio_: very unlikely, what were you after?
[13:55] <Tonio_> Hobbsee: about ppa, isn't there a way to drop a package ?
[13:55] <Tonio_> Hobbsee: searched for that option for hours without any success
[13:56] <Hobbsee> Tonio_: no.  ask in #launchpad, usually, and they can do it, or file a launchpad question on soyuz
[13:56] <Hobbsee> archive admins cant do it
[13:56] <Hobbsee> or just upload a newer version
[13:56] <Hobbsee> 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] <Tonio_> Hobbsee: I hope the option is comming along in the next future
[13:57] <Tonio_> Hobbsee: thanks for the infos :)
[13:57] <Hobbsee> Tonio_: no problem
[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] <ubotu> Launchpad bug 157286 in ubuntu "System really slow like if no DMA from Edgy" [Undecided,New]
[15:03] <bddebian> Heya
[15:16] <TheNewAndy> I have a patch for apt-url which I think others might find useful, but I'm not
[15:17] <TheNewAndy> so familiar with how to go about getting it reviewed/accepted.
[15:17] <TheNewAndy> I imagined that posting it as a 'bug' on launchpad would be the best way
[15:17] <Hobbsee> TheNewAndy: have a look at https://wiki.ubuntu.com/MOTU/Contributing
[15:17] <TheNewAndy> 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
[15:54] <mdomsch> is there a specific package owner for each package in main?
[15:56] <Hobbsee> mdomsch: some of them.  not all.
[15:56] <persia> 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] <Hobbsee> mdomsch: looking at who's uploaded it recently should give you an indication
[15:59] <mdomsch> Hobbsee, where do I see who uploaded a package?
[15:59] <mdomsch> I see the Maintainer line (e.g. if it came straight from Ubuntu) in the control file
[16:00] <Hobbsee> mdomsch: aptitude changelog <packagename>
[16:00] <Hobbsee> mdomsch: you can query launchpad about it, or you can also look up changelogs.ubuntu.com
[16:00] <Hobbsee> the first and third tend to be quicker.  teh first is my preference.
[16:00] <mdomsch> but the name in the changelog is who made the change, not necessarily who uploaded into Ubuntu
[16:01] <mdomsch> e.g. the hwdata package
[16:01] <mdomsch> but that's a fair start
[16:01] <Hobbsee> mdomsch: ah, true
[16:02] <Hobbsee> 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/<release>-changes, and decrypt the gpg key :)
[16:02] <Hobbsee> havent found a faster way than that
[16:02] <Hobbsee> LP may show the info now.  they keep swapping what they do and don't show.
[16:02] <Hobbsee> mdomsch: by version number, hwdata looks synced.
[16:03] <Hobbsee> the autosyncer is on from that point, so it's likely from that.
[16:03] <mdomsch> Hobbsee, it's synced to debian, but debian pulls from fedora
[16:03] <Hobbsee> (some of the maintainers of main packages are in debian, not ubuntu)
[16:03] <Hobbsee> mdomsch: right.  ie, fedora-specific stuff?
[16:04] <mdomsch> that's fine, thanks.  I'm just trying to get some coordination around this package
[16:04] <mdomsch> and understand who the players are
[16:04] <Hobbsee> ah, right
[16:04] <mdomsch> Fedora generates the package, debian pulls it, ubuntu pulls from debian
[16:04] <Hobbsee> mdomsch: for that one, looks like fedora and debian.  doesnt look like nayone from ubuntu specifically is touching it :)
[16:04] <Hobbsee> yup
[16:04] <Hobbsee> or, at least, until the autosync gets turned off.
[16:04] <mdomsch> so I can either poke 3 distros to add a pile of monitors, or I can get it into fedora and wait
[16:04] <Hobbsee> probably.
[16:05] <Hobbsee> it's not that hard to push, if you want to get it here.  no idea about debian.
[16:05] <Hobbsee> of course, they might look favorably if you say who you are, and such :)
[16:05] <Hobbsee> 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] <Hobbsee> cool
[16:06] <Hobbsee> dude, this downloading at 0.9kBps is *not* cool!
[16:06] <Hobbsee> s/kBps/KBps/
[16:06] <mdomsch> 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] <Hobbsee> nice!
[16:07] <Hobbsee> mdomsch: like i say, if you know what you're doing, it's not hard to get sponsorship into main.
[16:07] <mdomsch> so folks won't be able to complain that their newest 2407WFP-HD monitor isn't listed in displayconfig-gtk
[16:07] <Hobbsee> so you dont have to wait for all 3 distros
[16:07]  * Hobbsee nods
[16:07] <Hobbsee> i'm impressed - ubuntu actually detects my correct monitor, now!
[16:07] <Hobbsee> first release!
[16:08] <ScottK> Hobbsee: Does Kubuntu benifit from this too or does it use another list?
[16:08] <Hobbsee> it's only taken since edgy.
[16:08] <Hobbsee> ScottK: no idea, tbh.  i think it uses another list.  i think it's also buggy, so no one uses it.
[16:08] <Hobbsee> ScottK: 915resolution is what i've used in the past, just to make the screen readable, without me gouging my eyes out
[16:08] <ScottK> Bummer.
[16:09] <Hobbsee> pity mdomsch didnt show up a couple of releases ago.  i could have hounded him to fix ti :)
[16:09] <mdomsch> hehe
[16:09] <Hobbsee> (while it was still broken)
[16:09] <Hobbsee> speaking of which, i should find another battery at some point.
[16:10] <Hobbsee> not worth it at this point in the year, though
[16:10] <Hobbsee> mdomsch: maybe i'll just blame you anyway.
[16:12] <ScottK> 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] <Hobbsee> 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] <Hobbsee> 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] <Hobbsee> ScottK: i'm deeply unimpressed about how i cant seem to remove the xserver-xorg-video-i810 stuff without X breaking, though.
[16:14] <Hobbsee> i seem to need both that and -intel.
[16:14] <Hobbsee> or at least, under kubuntu i do.
[16:14] <tepsipakki> that's true
[16:14] <Hobbsee> last i knew, they conflicted, so...
[16:14] <Hobbsee> or i'm remembering wrong :)
[16:15] <Hobbsee> tepsipakki: why?
[16:15] <tepsipakki> well, -intel has issues with some chips
[16:15] <tepsipakki> so -i810 is still here
[16:16] <tepsipakki> and the dependancy chain goes up to {k,}ubuntu-desktop, so removing the metapackage would mean removing -desktop as well
[16:16] <Hobbsee> tepsipakki: i seemed to be able to remove it with great problem - i just had no X :)
[16:16] <tepsipakki> fingers crossed that we actually can drop -i810 during hardy :P
[16:16] <tepsipakki> oh
[16:17] <Hobbsee> tepsipakki: or is 965 an issue-filled chip?
[16:17] <ScottK> tepsipakki: So my 2 year old hardware will become unsupported?
[16:17] <Hobbsee> er, without great problem
[16:17] <tepsipakki> ScottK: which is that?
[16:17] <tepsipakki> ScottK: debian doesn't have -i810 since -intel 2.0 came out
[16:18] <ScottK> OK, so i810 is supported in that?
[16:18] <tepsipakki> ScottK: sure, every chip, but some of them have issues
[16:18] <tepsipakki> Hobbsee: how does it break?
[16:19] <ScottK> 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] <tepsipakki> heh
[16:19] <tepsipakki> Hobbsee: speaking of which, you are an archive-admin?-)
[16:19] <Hobbsee> 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] <Hobbsee> tepsipakki: FSVO archive admin, yes.
[16:19] <ScottK> FSVO?
[16:19] <Hobbsee> for some value of
[16:20] <tepsipakki> Hobbsee: so you can't do syncs?
[16:20] <ScottK> Ah.  Yes.
[16:20] <Hobbsee> tepsipakki: correct.
[16:20] <tepsipakki> bummer
[16:20] <Hobbsee> yeah, i know.
[16:20] <tepsipakki> great that the archive is open, but a first batch of syncs would've been equally nice :)
[16:21] <tepsipakki> Hobbsee: do you happen to have "i810" in xorg.conf, instead of "intel"?
[16:22] <Hobbsee> tepsipakki: yeah.
[16:23] <Hobbsee> tepsipakki: buildds still have plenty to build, due to the autosync.
[16:23] <Hobbsee> but i'd imagine it'll take a couple of weeks
[16:23] <Hobbsee> (conferences and such)
[16:23] <Hobbsee> ah, this one is using intel.
[16:23] <tepsipakki> 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] <Hobbsee> ahhh
[16:24] <Hobbsee> well, they did last i checked
[16:24] <Hobbsee> tfheen: may be around
[16:24] <Hobbsee> but i think he's in the air by now
[16:24] <zul> tepsipakki: well it is a new dev cycle :)
[16:25] <tepsipakki> Hobbsee: you probably have all that xserver-video-all depends on :)
[16:25] <tepsipakki> zul: ah, the pain! :)
[16:25] <Hobbsee> tepsipakki: yeah.  but cant it pick my card, and deal?
[16:25] <Hobbsee> tepsipakki: it's not like i'm going to swap out my video card :)
[16:25] <tepsipakki> Hobbsee: not yet, but it'll be discussed at FOSSCamp & UDS
[16:26] <Hobbsee> xserver-xorg depends on it
[16:26] <Hobbsee> tepsipakki: cool :)
[16:26] <tepsipakki> autoloading based on the pci-ids that the drivers have
[16:27] <Hobbsee> tepsipakki: can i safely remove the rest?
[16:27] <tepsipakki> yes
[16:27] <tepsipakki> but it'll save you like 2MB :)
[16:28]  * Hobbsee shrugs
[16:29] <antoranz> Hi guys! I'm having problems linking (static) to libalsa09.a
[16:29] <antoranz> can anybody give me a hand here?
[16:30] <antoranz> forget it... the channel is not for application development under ubuntu... but maybe the problem is raleted to ubuntu
[16:32] <antoranz> 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] <antoranz> SYMBOL TABLE; I mean
[16:32] <ScottK> Hobbsee: Are universe packages being allowed to build right now?
[16:32] <antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_format
[16:32] <antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_channels
[16:33] <antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_rate_near
[16:33] <antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_buffer_time_near
[16:33] <antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_period_time_near
[16:33] <Hobbsee> ScottK: i think so
[16:33] <antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params
[16:33] <Hobbsee> !paste | antoranz
[16:33] <ubot3> 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] <ScottK> Hobbsee: OK.  Thanks.
[16:33] <ScottK> For both the answer and the kick.
[16:33] <Hobbsee> ScottK: no reason why they wouldnt be
[16:33] <ScottK> OK.  I've got stuff that's been sitting around for a long time, but no trouble.
[16:34] <persia> ScottK: Main autosync gets priority...
[16:34] <ScottK> OK.  That'd do it.
[17:14] <Adri2000> 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] <ScottK> Adri2000: That or just make it work with the current pbuilder.
[17:26] <Adri2000> ScottK: ah. I'm still waiting for your solution
[17:27] <ScottK> Adri2000: Make the authoritative source for the package one I can use and I'll be glad to.
[17:28] <Adri2000> I'm not sure to understand what you mean
[17:29] <ScottK> 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] <Adri2000> ScottK: http://adrishost.homeip.net/~adri2000/ubuntu/pbuilder-dist
[17:30] <ScottK> What about it?
[17:31] <Adri2000> wget it, cp it, edit the new one, diff it with the new one you edited to create a patch you can give me
[18:06] <glledo> has somebody noticed in Gutsy that Firefox -> Help -> Release Notes pops up Edgy release notes?
[18:08] <mdke> glledo: the only way to find out for sure is to search for a bug
[18:08] <glledo> didnt find any
[18:09] <glledo> ok, lets submit it
[18:09] <mdke> then I suspect that no one has
[18:13] <glledo> doh, bug 140998
[18:13] <ubotu> 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] <ubotu> 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] <Kopfgeldjaeger> hi
[19:19] <warsocket> 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] <ion_> fork, close stdout, open /dev/null, exec. Now please read the topic.
[19:26] <warsocket> kk tnx
[19:49] <IntuitiveNipple> Anyone about can give me some quick guidance for doing SRU updates for hardy and gutsy-proposed ?
[19:50] <LaserJock> IntuitiveNipple: you won't be doing an SRU for hardy
[19:50] <LaserJock> IntuitiveNipple: and for Gutsy have a look at https://wiki.ubuntu.com/StableReleaseUpdates
[19:50] <IntuitiveNipple> well no but... step #1 is to create an update for hardy, then one for gutsy-proposed
[19:51] <IntuitiveNipple> I am doing/have done... my questions are more about technicalities
[19:51] <LaserJock> ah, well yes, you want to make the changes first in Hardy usually
[19:51] <LaserJock> IntuitiveNipple: ask away and see if anybody knows
[19:51] <IntuitiveNipple> 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] <LaserJock> IntuitiveNipple: changelog
[19:52] <IntuitiveNipple> 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] <IntuitiveNipple> oh good. So, are these steps correct?
[19:53] <IntuitiveNipple> 1. grab the latest source package from the hardy repo, apply the changes, create the debdiff
[19:53] <LaserJock> _bernie: http://people.ubuntu.com/~scott/uds-boston-2007/
[19:54] <IntuitiveNipple> 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] <LaserJock> I don't think so
[19:55] <IntuitiveNipple> 3. Upload both to the LP bug with a rational for why and then Nominate it for release?
[19:55] <IntuitiveNipple> s/rational/rationale/
[19:55] <LaserJock> IntuitiveNipple: I would get the fix into hardy first
[19:55] <LaserJock> make sure it works
[19:55] <LaserJock> then file the SRU
[19:56] <LaserJock> but basically you're on the right track
[19:56] <IntuitiveNipple> 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] <IntuitiveNipple> LaserJock: What's the procedure for testing them with Hardy if I'm not running a Hardy install?
[19:58] <LaserJock> IntuitiveNipple: you can use a chroot or pbuilder environment
[19:59] <LaserJock> or VMware, VirtualBox, etc.
[19:59] <IntuitiveNipple> 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] <LaserJock> IntuitiveNipple: one of the reasons to test in Hardy first is typos or packaging mistakes
[20:00] <IntuitiveNipple> LaserJock: I assume the same applies to testing in Gutsy then? Especially when the changes are trivial
[20:01] <IntuitiveNipple> 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] <LaserJock> IntuitiveNipple: yes, even more so in gutsy-proposed
[20:02] <IntuitiveNipple> Right... I'll crack on with these debdiffs now ... thanks alot :)
[20:23] <mako_> _bernie: yes, i will attend uds
[20:30] <theacolyte> 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] <mako> _bernie: i haven't figured it out yet
[20:38] <mako> but i haven't really looked much either
[20:39] <Mez> mako *hugs* long time no see
[20:39] <Nafallo> theacolyte: sounds like a fault in the client.
[20:39] <Nafallo> theacolyte: try with another client.
[20:53] <mako> Mez: i'm around
[20:56] <Mez> mako, still with OLPC?
[20:57] <theacolyte> Nafallo: already did, realvnc and ultravnc
[20:58] <mako> Mez: yep
[20:58] <Mez> good to hear ;)
[21:01] <sbalneav> Up at 0500 tomorrow, on the plane by 7:30, at Boston by 14:00
[21:01] <sbalneav> mako: What's the quickest way from Logan? Subway or Taxi?
[21:04] <mako> sbalneav: quickest? taxi
[21:04] <mako> sbalneav: like $25-30
[21:05] <mako> sbalneav: alternately take the silver line and red line.. i think i edited the wiki directions
[21:05] <mako> it's not really that much longer
[21:05] <sbalneav> cool.
[21:05] <sbalneav> thx
[21:09] <wasabi> I notice apport stopped asking me to submit things, a month ago.
[21:14] <LaserJock> wasabi: I think they turned that off for release so the general user population wasn't bugged about it
[21:14] <LaserJock> and we didn't get a flood
[21:14] <wasabi> Ahh.
[21:23] <Nafallo> theacolyte: weird
[21:40] <IntuitiveNipple> 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] <ubotu> Launchpad bug 137406 in update-notifier "apport stopped working" [Low,Won't fix] https://launchpad.net/bugs/137406
[21:52] <theacolyte> I'll just put in a bug report probably
[22:00] <evan_pi> 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] <evan_pi> 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] <evan_pi> The spec is at https://blueprints.launchpad.net/ubuntu/+spec/simplify-removable-drives-and-media
[22:02] <evan_pi> Is anybody out there?
[22:02] <LaserJock> evan_pi: I think it probably meant the ubuntu-devel mailing list
[22:02] <LaserJock> evan_pi: or maybe better ubuntu-devel-discuss
[22:03] <evan_pi> It mentioned the devel-discuss mailing list and the irc channel
[22:07] <LaserJock> ok :-)
[22:29] <IntuitiveNipple> Is this correct? "apt-get source -t hardy <package>" fetches the gutsy source even though the hardy repositories are enabled in /etc/apt/sources.list
[22:29] <Amaranth> IntuitiveNipple: Isn't it 'apt-get source foo/hardy'?
[22:30] <IntuitiveNipple> is it?
[22:30] <Amaranth> I believe so
[22:30] <IntuitiveNipple> I was going by the man pages and the --help
[22:30] <IntuitiveNipple> no, that doesn't work
[22:31] <IntuitiveNipple> It *seems* as if it fetches the source for the installed binary version, regardless
[22:33] <LaserJock> actually
[22:33] <LaserJock> I think it grabs it from the first deb-src it finds
[22:33] <LaserJock> unless that bug has been fixed, which is possible
[22:35] <IntuitiveNipple> 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] <IntuitiveNipple> All I want to do is automate generating the debdiffs for hardy and gutsy-proposed, grrr
[22:36] <geser> IntuitiveNipple: I tried it here and "apt-get source -t hardy package" (or -t gutsy) behaves as expected
[22:37] <IntuitiveNipple> really? what've you got in your /etc/apt/sources.list ?
[22:37] <geser> IntuitiveNipple: does the package has an other version in hardy already?
[22:37] <IntuitiveNipple> There's one version in hardy repos
[22:38] <IntuitiveNipple> I wonder if it is because i've only added the deb-src lines to sources.list
[22:39] <geser> IntuitiveNipple: see my test in http://paste.ubuntu-nl.org/42289/
[22:39] <geser> IntuitiveNipple: I've also only added the deb-src line, run apt-get update and it worked
[22:39] <IntuitiveNipple> that's what I did here, too
[22:41] <geser> IntuitiveNipple: which package do you try?
[22:42] <IntuitiveNipple> update-notifier (devscripts works for me too)
[22:43] <IntuitiveNipple> It is apparently there: http://packages.ubuntu.com/hardy/source/update-notifier
[22:44] <geser> yes, as hardy starts as a copy of gutsy
[22:44] <geser> currenty gutsy and hardy has update-notifier 0.61
[22:45] <IntuitiveNipple> 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] <geser> no, but does it matter if you get the source for 0.61 from gutsy or hardy (they should be identical)
[22:47] <LaserJock> I think it picks from the earlist source if there's more than one
[22:48] <LaserJock> it is the same files
[22:48] <IntuitiveNipple> The changelogs should have different 'release' strings, and that's crucial for what I'm doing
[22:48] <LaserJock> no, they don't
[22:48] <LaserJock> the changelog will only change with a new upload
[22:48] <IntuitiveNipple> ahhh.
[22:49] <geser> there was no upload of update-notifier for hardy till now (only the archive copy from gutsy)
[22:49] <LaserJock> with a pool archive structure for a given version the files are all the same, regardless of release
[22:49] <IntuitiveNipple> 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] <IntuitiveNipple> ahhh... so what you mean is, it's linked on the server?
[22:50] <LaserJock> that's all they do
[22:50] <IntuitiveNipple> hmmm but that still doesn't explain why apt-get fetches from the hardy repo
[22:50] <LaserJock> point to where in the pool you can get the file
[22:50] <geser> 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] <IntuitiveNipple> hmmm
[22:51] <IntuitiveNipple> geser: that'd suggest re-ordering the deb-src lines might affect it... worth a try
[22:52] <SEJeff> IntuitiveNipple, If the versions are the same, why generate a debdiff? It seems like maybe you are doing something wrong?
[22:52] <LaserJock> I think it doess affect it, last I tried
[22:53] <IntuitiveNipple> Nice one geser! Re-ordering the deb-src lines in sources.list so hardy is first has solved it
[22:53] <LaserJock> I agree with SEJeff
[22:54] <IntuitiveNipple> 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] <IntuitiveNipple> So I need the current source, dupe it, apply the patches, update the changelog, debuild, then create the debdiff
[22:55] <SEJeff> Which means you should increment the version
[22:55] <SEJeff> Like 1.2.3-2 or -ubuntu0 or whatnot. The versions still are not the same
[22:56] <IntuitiveNipple> 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] <SEJeff> 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] <SEJeff> If I download sysutils 1.0 from the gutsy or hardy repo, it is still the same source
[22:56] <SEJeff> (pretend that is a valid sysutils ver)
[22:57] <IntuitiveNipple> 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] <SEJeff> Use case of why it would break being?
[22:57] <SEJeff> This seems like a process problem that you can fix with error checking and defensive programming to me.
[22:58] <SEJeff> IntuitiveNipple, Your idea is really cool though. A lot of people would appreciate it
[22:58] <LaserJock> IntuitiveNipple: your real question is if -t is respected if they *aren't* identical packages
[22:59] <SEJeff> LaserJock, And if they aren't identical packages + the version number is the same, an MOTU should be flogged :)
[22:59] <LaserJock> SEJeff: sure, but I think he's wanting non-identical version numbers
[22:59] <IntuitiveNipple> 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] <IntuitiveNipple> 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] <SEJeff> ok
[23:01] <LaserJock> IntuitiveNipple: I don't want to necessarily discourage you, but that sounds like a really bad idea :-)
[23:01] <SEJeff> *nods*
[23:01] <LaserJock> SRUs need lots of focused attention to every detail
[23:01] <geser> IntuitiveNipple: I guess "apt-get source -t gutsy update-notifier" tells you that it got it from hardy now.
[23:02] <LaserJock> and there's no way that a bug fix in hardy will apply the same to gutsy, etc.
[23:02] <LaserJock> so I would really discourage automatic SRU scripts
[23:02] <IntuitiveNipple> All I do now is "debdiff-package.sh [-g <package> [-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] <IntuitiveNipple> geser: Grrrr yes!
[23:03] <crimsun_> jordi: pong
[23:03] <IntuitiveNipple> LaserJock: The two releases are dealt with separately, totally independently - two passes of the process
[23:04] <LaserJock> right, but still
[23:04] <LaserJock> so  you script changes the version and release, and makes a debdiff, and that's all?
[23:05] <IntuitiveNipple> 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] <LaserJock> so it doesn't do any more than I mentioned?
[23:07] <IntuitiveNipple> 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] <IntuitiveNipple> I get a set of y/n prompts at key points with the option to over-ride
[23:08] <LaserJock> k
[23:09] <LaserJock> that doesn't sound too bad
[23:09] <geser> IntuitiveNipple: what happens if the package doesn't use dpatch?
[23:09] <LaserJock> I wouldn't do it, but well, that's me
[23:09] <IntuitiveNipple> geser Then I do it manually
[23:10] <IntuitiveNipple> I rarely mess with packages so when I do I don't want to be pissing about re-remembering all the steps.
[23:10] <LaserJock> but for me it's remembering the steps that makes me confident in what I'm doing
[23:10] <LaserJock> as perhaps the steps have changes since last I did it
[23:11] <LaserJock> but that's just me
[23:11] <IntuitiveNipple> I prefer automated tools to handle repetitive tasks; I focus on the stuff the computer can't do
[23:11] <LaserJock> I do everything manually
[23:11] <IntuitiveNipple> Working on the kernel is so much easier than messing about with packages :)
[23:11] <LaserJock> I can understand that, but I find many packaging taskes are not really repetitive
[23:12] <IntuitiveNipple> 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] <LaserJock> except if they change ;-)
[23:13] <IntuitiveNipple> which basically boils down to creating a debdiff and attaching to an LP bug report for someone else to deal with
[23:13] <IntuitiveNipple> Easy enough to amend the script to deal with changes, and then forget it again