[00:28] <jdong> ajmitch: hmmmm hmmmmmmm, well I remember watching in amusment when temugen was figuring out what muttrc only changed colors of some emails...
[00:28] <jdong> but I don't know how I can qualify that as serious data loss, denial of service, etc etc etc
[00:29] <jdong> but at the same time the patch is so simple I can't fathom what'd go wrong (famous last words)....
[00:29] <jdong> hmm....
[00:29] <jdong> I'd say ask for a second opinion for the SRU
[00:29] <jdong> if this were an esoteric Universe package I'd honestly say yes, but given that this is mutt, I'm a bit more careful.
[00:31] <ajmitch> but given that it's a patch that's from upstream, and in lucid via debian?
=== wgrant_ is now known as wgrant
[00:46] <jdong> ajmitch: if I say yes, would you have my back if someone WTFs me? :)
[00:47] <ajmitch> sure
[00:47]  * ajmitch uses mutt every day, but not on karmic :)
[00:48] <jdong> awesome :)
[00:48] <jdong> mutt hasn't exactly changed in the last decade *ducks*
[00:48] <temugen> there were a lot of other upstream patches, though :P Not sure what for since mutt is usually rock solid. I can't believe I actually ran into that coloring bug
[00:49] <jdong> temugen: hahaha I'd rather not go candy-picking, let's just take care of ones people stumble into.
[00:49] <temugen> jdong: I agree :)
[00:49] <jdong> temugen: it's no fun to fix a bug until you can point and laugh at someone who was affected
[00:49] <jdong> (KIDDING, kinda)
[00:49] <jdong> (don't quote me exactly)
[00:49] <temugen> quoted
[00:50] <jdong> :)
[00:50]  * ajmitch pastes that into the LP bug
[01:02] <TheMuso> jdong: You still using a macbook?
[01:02] <jdong> TheMuso: yes sir
[01:03] <TheMuso> jdong: Are you aware that grub2 now allows an easier way of setting the intel SATA controller to AHCI?
[01:03] <TheMuso> That is, if you still use a machine with an Intel SATA controller.
[01:04] <jdong> TheMuso: oh, said Macbook with the Intel chipset has been retired to the folks
[01:04] <jdong> TheMuso: but that's awesome to know
[01:04] <jdong> TheMuso: new Macbook Pro has far more amusing gripes about jack sense and those fun topics :)
[01:04] <TheMuso> jdong: Yeah, the setpci command/module allows things to be adjusted so.
[01:04] <TheMuso> jdong: I am sure.
[01:06] <jdong> TheMuso: ah, nice. Yay GRUB2
[01:06] <jdong> TheMuso: have you ever been scared about all the functionality they're putting into bootloaders these days? :)
[01:06] <TheMuso> jdong: No.
[01:07] <jdong> TheMuso: 5 years ago it would've been a joke, but now.... how long will it be before my bootloader supports ssh'ing or a busybox shell?
[01:07] <TheMuso> heh
[01:07] <TheMuso> Anyway, I now use grub2 for my 2008 mbp to enable AHCI.
[01:10] <jdong> cool
[01:11] <directhex> i wish grub2 would stop adding non-functional osx entries
[01:11] <TheMuso> directhex: Yeah, we should try and address that somehow...
[01:11] <jdong> I've never tried any of those entries but assumed they hilariously don't work.
[01:12] <directhex> garbage IME
[01:12] <directhex> i chain load grub2 from refit
[01:12] <jdong> I don't like the switch of hotkeys either for bringing up the menu
[01:12] <jdong> I was doing technical review for a new edition of a Ubuntu book...
[01:13] <jdong> and now there's a hilarious number of "if you're using Legacy GRUB.... if you're using GRUB2....."
[01:14] <RAOF> jdong: Yeah, they hilariously don't work.
[01:14] <jdong> whoo! hilarious! :)
[01:15] <directhex> did anyone see my tinkering?
[01:16] <imbrandon> what tinkering ?
[01:18] <RAOF> The themeing tinkering?
[01:18] <directhex> imbrandon, http://imgur.com/AHlSI
[01:18]  * imbrandon looks
[01:18] <directhex> RAOF, precisely
[01:18] <imbrandon> directhex: grub2 ?
[01:18] <directhex> imbrandon, aye
[01:19] <imbrandon> nice, i was tinking with some animated plymoth things
[01:19] <imbrandon> untill i unterly broke my booting
[01:19] <imbrandon> lol
[01:19] <imbrandon> should have done it in a VM
[01:19] <imbrandon> directhex: isnt grub2 hidden by default in lucid though ?
[01:20] <directhex> imbrandon, yeah, unless you re-enable it, or have multiple OSes
[01:21] <mannyv> what would be the new version  for an SRU on opendchub 0.8.0-5?
[01:21] <imbrandon> directhex: :)
[01:22] <directhex> mannyv, you generally wouldn't SRU directly to lucid, you'd have a fixed version in maverick
[01:25] <mannyv> directhex, there is an exploit in opendchub 0.8.2 that will give a shell, in 0.8.0 it will not give a shell but it does crash the deamon
[01:25] <directhex> mannyv, have you filed a security bug? that's a good start
[01:29] <ScottK> With a patch is even better.
[01:29] <mannyv> its been fixed upstream, and in sqeeze and I wanted to try brining the fix into lucid
[01:30] <mannyv> maverick should be fine because the patch will be autosynced
[01:30] <ScottK> Does the new upstream release just fix this issue or does it include other stuff too?
[01:31] <mannyv> ScottK it is a new version, moves from 0.8.0 to 0.8.2
[01:31] <ScottK> How about 0.8.1 to 0.8.2?
[01:31] <ScottK> For a post release update we need just the fix for the security issue.
[01:33] <mannyv> ScottK, I don't see a 0.8.1 either in LP or BTS
[01:33] <mannyv> so should I will file a bug report with the patch and a schroot test build/install against lucid?
[01:34] <ScottK> mannyv: How about upstream?
[01:34] <ScottK> Yes.  That would be great.
[01:34] <mannyv> ok i will do that then come back =)
[01:34] <mannyv> I still dont quite get what you are asking about 0.8.1
[01:35] <imbrandon> we try to make sru's as little as possible, only fixing the issues, new versions are fro -backports normaly
[01:35] <imbrandon> but if its security its a whole nother ball game
[01:36] <imbrandon> speaking of ball games, nixternal, you watchin the sox and royals playin ?
[01:49] <psusi> temugen, I can't get a mouseover to work on that svg, though I can see the file names when I look at the raw svg
[01:55] <jdong> psusi: browser?
[01:55] <psusi> jdong, chromium or firefox
[01:55] <jdong> interesting...
[01:55] <jdong> which chromium?
[01:55]  * jdong grumbles about more browser fun
[01:56] <psusi> didn't know there was more than one
[01:56] <jdong> psusi: ah so many builds of chromium
[01:56] <temugen> hehe my chromium renders it on mouseover :-/
[01:56] <jdong> stable (windows-only), beta, dev, SVN nightlies, ... ... ...
[01:56] <jdong> I'm guessing temugen runs the dev channel
[01:56] <jdong> psusi: add-apt-repository ppa:chromium-daily/dev?
[01:57] <imbrandon> google-chrome ftw ;)
[01:57] <psusi> hrm... ok
[01:57] <temugen> psusi: view-source:http://svg-whiz.com/svg/Tooltip2.svg or you can add that <script> tag to the svg
[01:57] <temugen> that will use the title tag that's already on all of the blocks and give you a big and pretty tooltip :)
[01:58]  * jdong can't wait for the HTML5 browser disparities to start happening
[01:58] <jdong> and wow what's up with the PPA lagtime
[01:58] <jdong> (err, OT)
[01:58] <temugen> psusi: or I can have it autoadd the script for you, but it seems like something that the SVG renderer should take care of and not us
[01:59]  * jdong semi-sarcastically brings up the idea of cashing in LP karma points for buildscores
[02:00] <psusi> I'm not quite sure what to do with that
[02:00] <temugen> psusi: the script tag?
[02:00] <psusi> yea
[02:01] <psusi> cut everything in the script tag and put it where in the svg?
[02:01] <temugen> psusi: http://pastebin.com/6G0CpedZ You should be able to copy and paste that just above the first <path element
[02:02] <temugen> I should probably test it out first to not send you on a goose chase :)
[02:04] <psusi> didn't work... hrm...
[02:04] <temugen> psusi: yea that's going to take a little more work :-/ hang on
[02:04] <temugen> looking into it
[02:04] <psusi> k
[02:05] <jdong> psusi: or you can just use a shinier newer chromium....
[02:05]  * jdong has no idea what explains the same software not working on two machines the same way :)
[02:05] <psusi> ohh?  let me update
[02:05] <jdong> psusi: yeah that'd be my guess to the difference between your setups.
[02:06] <jdong> plus chromium is one of those things that does awesomely improve overnight (tm), running the dev channel on Linux is really nice.
[02:06] <temugen> psusi: but if not, I just got the big tooltips working too (3 things to add, or I can add them in the template and you can bzr up, your choice)
[02:09] <psusi> ok, upgraded to the new chromium, still no popup
[02:12] <temugen> psusi: it's like a tooltip, you have to let the mouse sit there for a second
[02:12] <temugen> but I assume you tried that already
[02:12] <temugen> so I'll start adding the script to the template
[02:13] <psusi> that other example page worked
[02:14] <psusi> chromium sure does burn up a lot of cpu whenever I move the mouse over this thing though
[02:18] <temugen> psusi: yes it does :P ok, you can update. I really prefer to keep this up to the renderer in the future, though
[02:19] <temugen> and note collision detection/whatever still burns through a core on my machine
[02:19] <wgrant> jdong: Er, the PPA build queues appear to all be under 90 minutes. Am I missing something?
[02:20] <wgrant> jdong: That's still bad, but not as utterly deplorable and inexcusable as it has been for the last couple of weeks.
[02:20] <psusi> there we go!
[02:20] <jdong> wgrant: oh is it still 90 minutes?
[02:21] <jdong> wgrant: I was uploading last week to 2 of my PPA's and the builds got estimated for 3 days and built in 2 or so
[02:21] <wgrant> It should be down to 0 soon.
[02:21] <jdong> wgrant: and I noticed https://edge.launchpad.net/~chromium-daily/+archive/dev still has packages waiting for build?
[02:21] <jdong> uploaded 33hrs ago
[02:21] <wgrant> It's still processing the backlog from the buildd-manager breakage this morning.
[02:21] <wgrant> Hmm.
[02:21] <jdong> but ah, glad to hear the queue is clearing up
[02:22] <wgrant> Oh.
[02:22] <wgrant> i386 is still well behind.
[02:22] <jdong> "start in 9 hours"
[02:22] <jdong> ok
[02:22] <wgrant> I guess there are tonnes of superseded dailies still to go, so it won't really be that long.
[02:23] <wgrant> In a couple of months the dailies will be shuffled off into their own build pool, so they will disrupt and be disrupted less significantly.
[02:23] <jdong> ah okay, cool
[02:23] <psusi> son of a bitch!
[02:23] <psusi> they are bloody symlinks ;)
[02:23] <temugen> psusi: OH DAMMIT
[02:23] <temugen> *headdesk*
[02:24] <psusi> the file names listed in ureadahead --dump are symlinks, and the files they point to are left on the outer areas of the disk
[02:24] <psusi> hehe
[02:24] <psusi> I optimized the symlink instead of what it points to
[02:24] <jdong> HAHAHAHAHAHA
[02:24] <temugen> HAHAHHA
[02:24] <psusi> lol
[02:24] <jdong> WHOOOOOOOO!
[02:24] <jdong> XD
[02:24] <temugen> CLASSIC!
[02:24] <ajmitch> obvious fix is "Don't Do That"?
[02:24]  * psusi searches for ls flag to follow symlinks
[02:24] <jdong> temugen: maybe it should upon encountering a symlink list.append(mentioned file)
[02:24] <lifeless> psusi: realpath ?
[02:25] <jdong> temugen: and ok actually getting ureadahead-like data on symlink (e.g. calling FIEMAP) is an exercise left to the reader.
[02:25] <jdong> XD
[02:25] <temugen> jdong: well this isn't a problem with the grapher since the grapher reads directly from ureadahead
[02:25] <psusi> looks like I want ls -H
[02:25] <psusi> now let me try again with a -H thrown in
[02:25] <jdong> temugen: oh ureadahead gives the name of symlinks but actually reads the right files?
[02:25] <temugen> jdong: that's what it sounds like
[02:25]  * jdong slaps himself for doubting Keybuk.
[02:25] <jdong> :)
[02:25] <ScottK> jdong: Aren't you supposed to be studying or something?
[02:26] <jdong> ScottK: gah, the downside of a multitasking laptop. Thanks mom!
[02:26] <temugen> jdong: well, I'm not terribly certain actually...
[02:26] <psusi> no, ureadahead reads the real file because that's what you get when you open() the symlink
[02:26] <temugen> psusi: ok, that makes sense
[02:26] <psusi> but it gives the symbolic name in the pack file, which I was running ls -i on to get the inode number
[02:27] <temugen> *grin*
[02:27] <psusi> and that got me the inode number of the link rather than what it pointed to
[02:27] <temugen> yea
[02:27] <temugen> well, you got half of the link types right!
[02:28] <psusi> there, put THAT list in your defrag and smoke it
[02:32] <psusi> hrm...
[02:35] <temugen> psusi: hrm?
[02:36] <psusi> the picture didn't change much...
[02:36] <psusi> when it says at ##### what is that number?  the block number?
[02:36] <psusi> OHH
[02:36] <temugen> byte
[02:36] <psusi> I need to rebuild the pack file ;)
[02:36] <temugen> yes you do :P
[02:36] <psusi> it's not checking their actual location, rather just going with the pack file
[02:37] <temugen> yes exactly
[02:37] <psusi> well, looking at it in debugfs, it certainly looks like this file is where it should be... guess I'll go reboot and rebuild the pack file, hehe
[02:51] <psusi> now that is a thing of beauty
[02:51] <psusi> and damnit, imageshack doesn't like .svg
[02:54] <psusi> had to convert it to png... http://img15.imageshack.us/img15/8039/afterl.png
[02:55] <psusi> oh, and I think I found a bug in the sound system it booted too fast... only heard the last half of the startup sound
[02:55] <psusi> like it started trying to play it before the sound card was fully initialized
[02:56] <ScottK> I think we aren't going to slow the boot so you can hear the sound.
[02:57] <psusi> lol... no, but it should wait to start playing the sound until it actually is initialized ;)
[02:57] <psusi> http://img59.imageshack.us/img59/2714/faldaralucid201005052.png
[02:58] <psusi> looks like ureadahead is now spending half of its total execution time in the big open() hole.. need to get that fixed and oh boy, total time spent in ureadahead should be less than 2 seconds
=== nobawk is now known as nobawk|away
[03:04] <psusi> oh yea, forgot to throw my modified ureadahead into the mix...
[03:13] <psusi> very nice.... getting there now... just a little bit further to the 10 second mark
[03:17] <psusi> umm.... whoa...
[03:17] <psusi> I actually got it booting faster from the old rotational drives than my new ssd
[03:17] <psusi> that's.... fubar
=== nobawk|away is now known as nobawk
[03:25] <pace_t_zulu> hey guys i am trying to build gcc-4.2.3 on lucid ... i get the following error
[03:26] <pace_t_zulu> pbuilder-satisfydepends-dummy: Depends: gcc-4.3-base which is a virtual package.
[03:26] <pace_t_zulu> obviously i am using pbuilder
[03:27] <pace_t_zulu> i can understand how a depend that depends on a later version of the package being built might be an issue
[03:32] <nixternal> imbrandon: I hate the sox!
[03:35] <ScottK> lucas: I think now'ish would be a good time for a baseline rebuild on Maverick.  It looks like the toolchain is mostly in place.  Any chance of that soon?  Will you be at UDS again?
[03:40] <imbrandon> nixternal: lol
[03:48] <psusi> there we go... keybuck was right... ureadahead was in hdd mode... had to fix that and now bootchart shows 5.1 seconds ;)
[03:49] <ajmitch> psusi: 5.1 from grub to desktop?
[03:49] <psusi> ajmitch, that's the time on the top of the bootchart... I think it stops counting once you log in
[03:50] <ajmitch> not too bad anyway, I guess
[03:50] <psusi> oddly, it was 5.1 seconds the first time, then I turned on auto login and tried again and it went to 7 seconds
[03:50] <psusi> I am GOING to get it down under 10 seconds on the rotational disks ;)
[03:50]  * ajmitch would be happy to see < 30 seconds some days
[03:51] <ajmitch> though I don't run bootchart, so I can't really tell what the actual time is
[03:51] <psusi> you don't get that now?  outch...
[03:51] <psusi> apt-get install bootchart ;)
[03:51] <ajmitch> from 0.000000 to seeing fglrx spam in /var/log/dmesg is 38 seconds, I think
[03:51] <psusi> now I need to go file a bug about the login sound playing before the hardware is initialized, hehe
[03:51] <psusi> omg, do you not have ureadahead enahbled?
[03:52]  * psusi doesn't use fglrx
[03:52] <ajmitch> this is solely going from /var/log/dmesg, assuming that it's seconds in the left-most column
[03:52] <psusi> yea, that's the kernel monotonic time
[03:52] <ajmitch> so I don't know how much I can trust the numbers
[03:52] <ajmitch> [    3.986695] EXT3-fs: mounted filesystem with ordered data mode.
[03:52] <ajmitch> [   36.602443] udev: starting version 151
[03:53] <ajmitch> when it has lines like that (30-second jump there?)
[03:53] <psusi> whoa
[03:53] <psusi> this is lucid right?
[03:53] <ajmitch> yes
[03:54] <ajmitch> it doesn't really make sense to me, and overall the laptop doesn't feel too slow
[03:54] <psusi> ohh... laptop... SLOW hd
[03:54] <ajmitch> ureadahead is installed, fwiw :)
[03:54] <ajmitch> probably 5400 RPM, 320GB
[03:55] <psusi> but with a good defrag, and ureadahead, should be able to get down to ~10 seconds ;)
[03:55] <ajmitch> where good implies stable & tested :)
[03:55] <psusi> hehe
[03:55] <ajmitch> you need to get your crack into maverick soon
[03:55] <ajmitch> also, still on ext3 here, no ext4
[03:56] <psusi> ahh, that's another reason
[03:56] <psusi> upgrade to ext4
[03:56] <ajmitch> which to do properly, involves moving all data off, mkfs, and move it back on?
[03:56] <ScottK> Ah, the fun of moving back to syncing from Unstable.
[03:56] <psusi> ureadahead gets slowed down by indirect blocks on ext3.. extents for the winz
[03:57]  * ScottK went from 4 pending Universe merges to 25.
[03:57]  * psusi smacks xchat for autocorrecting his use of "teh"
[03:57] <ajmitch> ScottK: MoM is running?
[03:57] <ScottK> ajmitch: Apparently.
[03:57] <psusi> ajmitch, naw, you can use tune2fs to enable most of the new features and get most of the benefits... especially if you follow it with a chattr -R +e
[03:58] <ajmitch> psusi: nice, I might grab a live CD & try it out
[03:58] <psusi> basically the only thing you can't flip on is flex_bg, which just makes fsck a bit faster
[03:58]  * ajmitch doesn't seem to have many merges
[03:59] <ajmitch> and it looks like we need to go through & clean out the old comments from last time about sync bugs, etc
[04:01] <ScottK> Feel free to take libxml2.  I'm probably the last person here who should be caring about the Gnome xml library.
[04:01] <temugen> psusi: heck yes!
[04:02] <psusi> ajmitch, actually you don't need a livecd
[04:02] <ajmitch> I think I even uploaded that at one point in the distant past
[04:02] <psusi> ajmitch, just flip on the bits with tune2fs and force a fsck on reboot
[04:02] <psusi> temugen, eh?
[04:02] <ajmitch> psusi: that sounds too easy
[04:02] <temugen> psusi: I just got a change to look at the fragraph and the bootchart; awesome job!
[04:02] <temugen> chance*
[04:03] <jdong> psusi: *WOW* impressive graph!
[04:03] <temugen> psusi: are you moving symlinks to the front as well?
[04:03] <psusi> jdong, which one?
[04:03] <jdong> psusi: your fragraph
[04:04] <psusi> temugen, no... since unless they are very long, they don't actually have any blocks
[04:04] <jdong> psusi: now interesting question: What if you turn off ureadahead?
[04:04] <psusi> jdong, ohh, right
[04:04] <jdong> psusi: or.... replace it with a simple dd from start_block to end_block of=/dev/null?
[04:04] <psusi> jdong, then it won't speed up your boot? ;)
[04:04] <jdong> psusi: but your files are already so closely packed.
[04:04] <psusi> jdong, basically that's what ureadahead should result in...
[04:04] <jdong> psusi: butt what about your open() overhead?
[04:04] <psusi> jdong, yea... so ureadahead should be able to slurp them up real fast
[04:05] <jdong> psusi: or.... what about backgrounding ureadahead?
[04:05] <jdong> psusi: tricking it to think that it's a SSD
[04:05] <psusi> jdong, going to rework it to not bother open()ing at all
[04:05] <jdong> psusi: but won't the next time the file need to be open()ed the same overhead be incurred once?
[04:05] <psusi> naw, backgrounding not good since you will get out of order reads while other things try to access stuff
[04:05] <jdong> psusi: will seeking around that tiny ring be that big of a deal?
[04:05] <jdong> psusi: your OS and disk firmware both have readahead/elevators ;-)
[04:05] <psusi> I need to modify the tracer to map the raw disk blocks each file uses, then append the directories those files live in to the list
[04:06] <psusi> then at boot time, call readahead() on the raw block device to slurp up the directories, AND the files
[04:06] <psusi> all in one gigantic sequential read
[04:07] <psusi> rather, right now it maps the raw blocks to figure out the order in which the files should be read
[04:07] <psusi> I just need to use the raw address to pass to readahead() on the raw block device during boot instead of passing the file relative addresses to readahead() on the file
[04:08] <psusi> but yea, you still want the directory blocks read too so that when the file is really open()ed it is there... so need to get the tracer to add the directories themselves to the pack
[04:08] <psusi> then it should be about 1-2 seconds of pegging the disk as max, and done.
[04:09]  * psusi beats the hell out of lp
[04:10] <psusi> any idea how to search for a bug that mentions foo AND bar?  not OR?
[04:10] <psusi> neither foo AND bar nor +foo +bar work
[04:10] <ScottK> psusi: Google.
[04:11] <temugen> psusi: so how exactly are the symlinks laid out in ext3/4? I thought they were generic files unlike hardlink inode additions
[04:12] <psusi> temugen, ext2+ stores the link destination in the inode if it is short enough to fit, no external blocks needed
[04:12] <temugen> psusi: ah, awesome! I didn't know that. thank you :)
[04:13] <psusi> think it was 30 or 40 characters
[05:59] <ScottK> YokoZar: Would you please look at Spring and either upload a merge or request a sync.
[05:59] <YokoZar> ScottK: will do
[05:59] <ScottK> Thanks.
[06:00] <persia> Or better, go push anything outstanding into DG VCS, request an upload and *then* request a sync.
[06:10] <gladk> Hi, all
[06:11] <gladk> Sorry, I am new in packaging, and I am a little embarrassed with a very short debian/rules file, which was created by dh_make. Can anybody give me a link, where I can see an example of this new debian/rules? Thank you
[06:15] <RAOF> gladk: That'd be a debhelper 7 rules file?  It's pretty awesome, and, as you can see, pretty short :).
[06:15] <gladk> Right!
[06:15] <gladk> http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-defaultrules it is here described
[06:15] <gladk> but no examples
[06:16] <gladk> all faqs, what I have found are with long rules file
[06:18] <RAOF> So, debian/rules is Just A Makefile™ with some defined rules.  The dh7 mini-rules file takes advantage of fallback rules.
[06:18] <RAOF> The “%:” rule is “I'm a rule that matches anything.  If you can't find a more specific rule, call me”.
[06:19] <arand> Is the "Packaging and MOTU Q&A" session happening?
[06:19] <RAOF> In the mini rules file, that just calls “dh $@”.  The $@ is a special variable, which contains the target of whatever the rule should be.
[06:20] <micahg> arand: 1 more hour
[06:20] <RAOF> So, in this makefile, when you call “debian/rules build”, make goes “can I find a build: rule?  No.  Can I find a fallback that would match build?  Yeah, the %: rule.  That tells me to call ‘dh build’”
[06:20] <persia> arand: In -classroom?  If it's scheduled now, the instructor may be busy: try asking questions here.
[06:20] <micahg> arand: or rather 40 minutes
[06:21] <arand> micahg: Ah, ( right.. UTC != BST)
[06:40] <dholbach> good morning
[06:41] <micahg> dholbach: do you have a few minutes to chat about daily builds?
[06:41] <dholbach> no, I'm sorry
[06:41] <dholbach> but later on we can - I have not much experience with the topic yet
[06:41] <dholbach> there might be others who know much more about it than I do
[06:41] <micahg> dholbach: I saw you scheduled the blueprint for the daily builds discussion for lucid
[06:41] <dholbach> james_w for example, but I guess he's not up yet
[06:42] <dholbach> micahg: yes, I need to prepare myself for these
[06:42] <micahg> dholbach: not about making them, about integrating into Ubuntu workflow
[06:43] <dholbach> yes, the idea being that lots of teams benefit from them already, so we try the spread the word about them and see if we can improve things, etc.
[06:43] <dholbach> I haven't investigated the procedure much yet
[06:44] <micahg> dholbach: well, we were thinking of building a release type picker for mozilla products (daily, beta, stable) and I was wondering if this is something to discuss as a global thing at your session or if I should make a separate session
[06:44] <dholbach> micahg: I think we should talk about it there
[06:45] <dholbach> micahg: it'd be great to hear more about best practices and this seems to work well for you guys
[06:46] <micahg> dholbach: k, then I'll plan to attend your session then and bring it up
[06:46] <micahg> dholbach: thanks
[06:46] <dholbach> micahg: thank YOU :)
[07:24] <YokoZar> ScottK: did you have any insight into the Wine issue I showed you earlier?
[07:44]  * imbrandon wakes up
[07:44] <imbrandon> i hate it when i only sleep for 3 hours and then wake, makes for a long day
[07:45] <imbrandon> moins dholbach
[07:45] <dholbach> hi imbrandon
[07:46] <ajmitch> hi dholbach, imbrandon :)
[07:47] <imbrandon> heya ajmitch
[07:47] <imbrandon> ajmitch: havent heard anything from "jak" yet :(
[07:48] <ajmitch> np
[07:48] <ajmitch> there's no rush there
[07:48] <imbrandon> oh i know, was more to let you know, i'm the impatient one :)
[07:49] <imbrandon> i still havent touched software-center though and am hesitant to put up a "repo" to test without it
[07:52] <imbrandon> has openweek already started today ?
[07:54] <imbrandon> bzr lp-open ?
[07:55] <ajmitch> :0:> bzr help lp-open
[07:55] <ajmitch> Purpose: Open a Launchpad branch page in your web browser.
[07:55] <ajmitch> Usage:   bzr launchpad-open [LOCATION]
[07:56] <imbrandon> hrm, what if it wasent a on lp to begin with ?
[07:56] <ajmitch> this is for working with ubuntu package branches
[07:56] <ajmitch> if it's not on LP, you don't need to do that to submit merge proposals :)
[07:57] <ajmitch> since you'd just be pushing a new branch
[07:59] <imbrandon> guess it would work for things that have upstream mirrored on LP too
[08:00] <ajmitch> if the branches have a common ancestor to merge
[08:00] <persia> it's Patch Day!  Anyone with time to help review patches, please come to #ubuntu-reviews and join in!
[08:01]  * imbrandon will come review some in a few, goona check whats going on in -classroom incase he is intrested
[08:02] <persia> Great!
=== baddog is now known as Guest27073
=== Guest27073 is now known as baddog
[08:40] <Laney> persia: please add me to ubuntu-sponsors
[08:41] <toabctl> i want to build modemmanager from the git-repository. i cloned the repository and copied the debian/ dir from modemmanager-0.3 to the git-reprository. if i try to build with "dpkg-buildpackage -us -uc -rfakeroot" i got the following error:config.status: error: cannot find input file: `po/Makefile.in.in'
[08:41] <toabctl> make: *** [config.status] Fehler 1
[08:41] <toabctl>  
[08:41] <toabctl> any ideas?
[08:44] <imbrandon> toabctl: is there an autoget.sh ? rcs checkouts are normaly not prepared to build right away without some prep work, like autogen and/or configure
[08:44] <imbrandon> depending on the type of source
[08:44] <toabctl> imbrandon, yes, there's a autogen.sh
[08:45] <imbrandon> run it, then try to build
[08:45] <toabctl> imbrandon, should i first execute ./autogen.sh and then try to build the package?
[08:45] <imbrandon> yes, since you did a checkout instead of using the upstream tarbal
[08:46] <persia> Laney: done.  Thanks!
[08:47] <toabctl> imbrandon, now it works. thanks!
[08:47] <imbrandon> np
[08:47] <Laney> cheers!
[08:48] <toabctl> next question is how to name the package in debian/changelog . it's a git-checkout so i should mention this in the version? is there a version-name-guide anywhere?
[08:48] <persia> There isn't a version guide.
[08:49] <persia> Most people tend to do things like 1.2.3+gitYYMMDD or similar.
[08:49] <persia> Where 1.2.3 is the last released version.
[08:49] <toabctl> persia, ok. thanks.
[08:49] <toabctl> persia: and then without 0ubuntu1 or something like this?
[08:50] <persia> Oh, the stuff after the '-' is the same.
[08:50] <toabctl> would be "modemmanager (0.3+git20100506) lucid; urgency=low" correct=
[08:50] <persia> So 1.2.3+git20100506-0ubuntu1 would work.
[08:50] <toabctl> ah.ok
[08:54] <imbrandon> and your new tar you carefuly craft would be modemanager_0.3+git20100506.orig.tar.gz for version modemanager (0.3+git20100506-0ubuntu1~tobactl1) lucid;
[08:54] <imbrandon> :P
=== nobawk is now known as nobawk|away
=== nobawk|away is now known as nobawk
[09:27] <Rhonda> bug #576287 needs someone from the ubuntu-sponsors team to look at it :)
[09:28] <ubottu> Launchpad bug 576287 in wesnoth-1.8 "Sync wesnoth-1.8 1:1.8.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/576287
[09:39] <sebner> Rhonda: depending on how long you can wait :P
[09:46] <toabctl> how can i configure if modemmanager starts or not? when i kill it, it will be restarted every time. i want to start it manually with the --debug option.
[09:47] <Rhonda> sebner: Not for you to be approved into the team. ;)
[09:48]  * persia notes that sebner *is* a sponsor
[09:49] <Rhonda> oh
[09:49] <Rhonda> I can be your Debian sponsor, sebner :P
=== mathiaz_ is now known as mathiaz
[09:55] <persia> sebner: So, are you looking at that (or will you soonish?), or ought someone else?
[10:22] <sebner> persia: I'm willing to look but I can't create a maverick  pbuilder :(
[10:23] <sebner> Rhonda: ;D
[10:24] <persia> sebner: What's not working?
[10:24] <Rhonda> sebner: What's the problem?
[10:24] <sebner> persia: I: Installing core packages...
[10:24] <sebner> W: Failure trying to run: chroot /var/cache/pbuilder/build/2062/. dpkg --force-depends --install
[10:24] <sebner> E: debootstrap failed
[10:24] <Rhonda> Can you create a lucid pbuilder, do a pbuilder --login --save-after-login and change the sources.list?
[10:25]  * persia tries a schroot build
[10:26]  * sebner tries
[10:27] <Rhonda> When I can't bootstrap directly I usually take the chroot from the former release, copy it and change the sources.list and then do a regular --update
[10:31] <sebner> Rhonda: well, I never had problems, OTOH I never created a pbuilder that soon in the dev cycle (toolchain not ready etc)
[10:44] <ogra> persia, are you aware that http://qa.ubuntuwire.org/ftbfs/ still points to lucid ?
[10:44] <ogra> someone should probably change the default :)
[10:44] <persia> Why?
[10:45] <ogra> because maverick is of intrest now ?
[10:45] <persia> Until the archive opens, there's little point, and it's better to focus on SRUs.  http://qa.ubuntuwire.org/ftbfs/maverick.html is boring.
[10:45] <persia> Shortly after archive-open, all the lucid FTBFS packages will get retried, and that page will be interesting again.
[10:46] <persia> And then it makes sense to change the default.
[10:46] <persia> So, unless something strange happens, the default will probably change sometime this weekend.
[10:47] <persia> But needs stable toolchain first, which, if nothing else, probably needs a fix for eglibc on armel :)
[10:47] <persia> (but that''s already being investigated by the toolchain folks)
[10:48] <persia> Oh, and gcc on ia64 would be helpful :)  I'm not sure why kdeplasma-addons was tried: seems early for that.
[10:49] <l3on> Hi all... I'm trying to packaging a lib for ubuntu (karmic) but I have some problems with SHLIB in amd64 (i386 is fine). There are known issue for SHLIB in amd64?
[10:49] <imbrandon> persia: you are a schroot user correct ?
[10:50] <persia> l3on: Not for me.  Could you be more verbose?
[10:50] <persia> imbrandon: Yes.
[10:50] <persia> sebner: My maverick schroot created fine.  Maybe try a different debootstrap-mirror?
[10:51] <sebner> persia: bah, kk. Will try later
[10:51] <imbrandon> persia: i'm trying to get it to export DISPLAY=:1 on schroot login, i cant figure out a way to acatualy make it work, do you auto set your display for X programs ?
[10:52] <persia> imbrandon: Have you tried with just `schroot -p ...` ?
[10:52] <imbrandon> yes :(
[10:52] <l3on> persia: yes of course... take a look at build logs here -> https://launchpad.net/~l3on/+archive/dtn2/+packages
[10:52] <persia> How didn't that work?
[10:52] <l3on> persia: in particular liboasys
[10:52] <persia> l3on: oasys?
[10:52] <imbrandon> persia: i';m not sure, probably because outside the chroot i the DISPLAY is not :1
[10:53] <imbrandon> and -p preserves the env
[10:53] <l3on> persia: yes
[10:53] <persia> imbrandon: How about `DISPLAY=:1 schroot -p ...`
[10:54] <imbrandon> that was the next step, then there was putting "export DISPLAY=:1" inside a script and calling schroot /path/to/script/inside/chroot
[10:54] <imbrandon> also failed to set it ( or even run the script )
[10:54] <persia> l3on: So, which variable isn't being set, and how?
[10:54] <l3on> persia: in Makefile I see this:
[10:55] <persia> imbrandon: OK.  If you set DISPLAY=:1 manually inside the schroot, does it work?
[10:55] <sebner> persia: same failure with lucid, I guess my connection is bad as it failed to retrieve some packages
[10:55] <persia> sebner: Aha.  That makes sense.  Best of luck!
[10:55] <carstenh> imbrandon: DISPLAY=xy schroot -c sid -p works
[10:55] <imbrandon> persia: yes
[10:56] <imbrandon> carstenh: hum ...
[10:56] <l3on> persia: this is the Makefile -> http://dtn.hg.sourceforge.net/hgweb/dtn/oasys/raw-file/375fcbb4b5c4/Makefile
[10:56] <l3on> persia: look for "installlibs"
[10:56] <l3on> ehm... installlib
[10:57] <persia> l3on: So, how is SHLIB_EXT defined?
[10:57] <carstenh> imbrandon: though I'm still using 1.2.x, newer version might behave different
[11:00] <l3on> persia: this is realy funny. The configure script could enable-shlibs, but there is no effect. SHLIB_EXT is defined in Rules.make as "" (null). This in amd64, in i386 instead all works fine, and I have shlibs without do give to configure --enable-shlibs option.
[11:00] <imbrandon> persia / carstenh: http://paste.ubuntu.com/428866/
[11:01] <persia> l3on: You may want to add a bunch of echo statements, and then compare the two build logs carefully.  Something is arch-specific, and it's specific to that code.
[11:01] <sebner> persia: Rhonda , DktrKranz is willing to do it after lunch :)
[11:02] <l3on> persia: I'm not so expert in packaging, have you 5 minutes trying to find out the problem?
[11:03] <imbrandon> persia: we ever hear anymore from the fella doing the linux-rt stuff? i offered to review his stuff , gave him my email and such and never heard anything yet
[11:04] <persia> l3on: It would take me ~20 to prepare the environment to compare.  You needn't be an expert: just compare the build logs side-by-side until you find a difference.  Then add `echo ${SHLIB_EXT}` in a few places to try to narrow down where it is/isn't being set.
[11:04] <persia> abogani: imbrandon is looking for you ^^
[11:04] <l3on> Ok persia :)
[11:05] <persia> l3on: Once you find the part that is different, come back, and we can probably help you find a way to fix it.
[11:05] <imbrandon> persia: thanks
[11:08] <carstenh> imbrandon: schroot has a debug option
[11:09] <persia> imbrandon: I can't replicate (and I've tried lots of different ways).  http://paste.ubuntu.com/428871/ demonstrates my experience.
[11:09] <imbrandon> carstenh: k i'll look for it now, i have to run for a few hours ( maybe shorter ) thanks for the input though ( its anoying to export the display every time , lol )
[11:10] <persia> imbrandon: You might want to look at dropping some scripts in /etc/schoot/ then :)
[11:11] <imbrandon> persia: k, might be something buggy with my homedir mounts too, since i have the same use and home inside and out of the chroot so .Xauthorty might be finky
[11:11] <imbrandon> s/use/user
[11:11] <persia> imbrandon: Play with echo first.  Once you are sure you're setting the variables you need, then try to use them :)
[11:11] <imbrandon> yup yup
[11:12] <imbrandon> k got to run, thanks for all the great pointers
[11:12] <imbrandon> bbiab
[11:13] <lucas> ScottK: I will be at UDS. will do a rebuild during it
[11:16] <sebner> Rhonda: bahhhhh, 1.8.1 not in unstable ... *waiting*
[11:16] <ricotz> Laney, hello, any response on the docky SRU?
[11:16] <sebner> hio ricotz :)
[11:16] <ricotz> sebner, hi
[11:17] <sebner> ricotz: .3 will be bugfix only I guess, if important stuff I guess there is no problem with a SRU
[11:18] <ricotz> sebner, yes, 2.0.x are bugfix-only releases and indeed it includes important fixes ;-)
[11:19] <sebner> ricotz: heh, I know, I uploaded 2.0.1 :P
[11:22] <sebner> ricotz: btw, suggestion: Theme changes should include also the docky dock icon, I want to have the blue one, not the brown one but I don't want to use clearlooks theme in ubuntu :P
[11:22] <ricotz> sebner, hopefully directhex finishes 2.0.3.1 soon ;-) and an SRU member confirms it for lucid :P, until the same game for 2.0.4 ;-)
[11:22] <directhex> huh?
[11:23] <directhex> oh, docky
[11:23] <directhex> fine fine
[11:23]  * sebner waves at directhex :D
[11:23] <ricotz> directhex, hi, yes, docky git tree seems to be ready ;-)
[11:24] <sebner> ricotz: git tree? Our git tree is up to date (2.0.2) but you use bzr on LP, or am I missing something?
[11:24] <directhex> updaing my pbuilder
[11:24] <ricotz> sebner, http://git.debian.org/?p=pkg-cli-apps/packages/docky.git;a=shortlog
[11:25] <sebner> ricotz: yeah, that's our git tree ;)
[11:28] <ricotz> sebner, the docky icon is colored with the selection color to better blend in, not sure we gonna change that, it is possible to change the color with a gconf-key
[11:29] <sebner> ricotz: ohh, I totally missed that 2.0.3.1 is already out :D why the .1 btw?
[11:29]  * sebner searches gconf key
[11:30] <sebner> ricotz: value 187 is brown? What's blue then?
[11:30] <ricotz> sebner, there was a problem with 2.0.3 release
[11:30] <sebner> kk
[11:31] <ricotz> sebner, this value shifts your selection color, so you need to try
[11:31]  * sebner tries
[11:34] <sebner> ricotz: with clearlook the value is 7 but it doesn't change when using my theme :(
[11:35] <directhex> sebner, you want to update to .1 before sponsoring i guess
[11:35] <directhex> oh, Laney did it already
[11:35] <directhex> man, i'm just crap at computers
[11:35] <sebner> didrocks: yep, Laney is our speedy gonzales :D
[11:36] <ricotz> sebner, try a negative value
[11:36] <sebner> @directhex
[11:36] <sebner> ricotz: no change
[11:36] <directhex> test building
[11:37] <directhex> slowly
[11:37] <sebner> directhex: lucky you, I can't even set-up a pbuilder ¬_¬
[11:38] <ricotz> sebner, we dont have gconf live updates, so docky should not run while change values manually - http://wiki.go-docky.com/index.php?title=GConf_Settings
[11:38] <sebner> ricotz: ohoho!
[11:39]  * sebner kills docky
[11:40]  * sebner hugs ricotz :D
[11:40] <sebner> ricotz: works now, had to use a negative value though
[11:40] <ricotz> directhex, how strict is the debian cli policy since docky is started with "exec mono ..." instead of "exec /usr/bin/cli ..."?
[11:41] <ricotz> sebner, good :)
[11:41] <sebner> ricotz: well, we can patch it (or are we doing it already?)
[11:42] <ricotz> sebner, it is not patched yet, just a thought
[11:43] <sebner> ricotz: policy is law :P http://pkg-mono.alioth.debian.org/cli-policy/ch-appendix.html#s-wrapper-script-example
[11:52] <directhex> ricotz, it's not something i ever remember to check
[11:52] <directhex> meebey on the other hand may notice and grump at you
[11:55] <sebner> heh
[11:55] <abogani> imbrandon: I'm just start to work on linux-rt for Maverick. :-)
[12:08] <Rhonda> sebner: What, not in unstable?? Is.
[12:09] <Rhonda> sebner: What is http://packages.debian.org/unstable/wesnoth-1.8 otherwise?
[12:09] <sebner> Rhonda: bah, QA site sucks :P
[12:09] <Rhonda> … or did you fall into the pit of the different source package again?
[12:09] <sebner> Rhonda: my tools pulled 1.6.5 though :P
[12:09] <Laney> ricotz: is there already another version planned?
[12:10] <Rhonda> sebner: wesnoth != wesnoth-1.8
[12:10] <Laney> I don't want to keep updating lucid all the time
[12:10] <sebner> Rhonda: ohohoo! You have to tell me such things :P
[12:10] <sebner> Laney: 0.3.4 says LP
[12:10] <Rhonda> sebner: The bugreport said wesnoth-1.8. I thought it would be useful to put it in there. :P
[12:10] <Laney> we don't routinely update
[12:11] <sebner> Rhonda: /me = stupid, 300 MB?!?!?!?!?!?
[12:11] <sebner> Rhonda: bah, *that* will take some time
[12:11] <ricotz> Laney, hi, there is a milestone set, but without plans to release
[12:11] <Rhonda> sebner: Good art isn't for free. ;)
[12:12] <Laney> ok then
[12:12] <Laney> ricotz: you can fix the wrapper upstream, no hurry
[12:12] <sebner> Laney: btw, imho the last remaining bits for pinta is copyright. Bareftp is more urgent now so you would have to wait 1-2 days if you don't want to do it
[12:12] <Laney> what do you want to do with the copyright?
[12:12] <sebner> Rhonda: bah :P
[12:12] <sebner> Laney: update
[12:13] <Rhonda> sebner: No, for real. But yes, the music is most of the size, images are also a fair amount.
[12:13] <sebner> Laney: maaaaaaaany new files, http://git.debian.org/?p=pkg-cli-apps/packages/pinta.git;a=commitdiff;h=1f2ff34f970d97d2df9e776e80efccba49fa660a
[12:13] <ricotz> Laney, sorry, the wrapper wont be updated, we not only support debian
[12:13] <sebner> ricotz: then we have to patch it
[12:13] <Laney> what's the problem?
[12:13] <sebner> Rhonda: well, takes some time time
[12:14] <Laney> sebner: you can do it, i'm not interested in that
[12:14] <sebner> Laney: I thought you :P lazy Laney
[12:14] <sebner> *so
=== nobawk is now known as nobawk|away
[12:14] <Laney> well they should be covered by the default
[12:14] <sebner> Laney: new author ;)
[12:15] <Laney> like i said, not fussed
[12:15] <Laney> :)
[12:15]  * sebner throws rotten tomatoes at Laney :P
=== nobawk|away is now known as nobawk
[13:10] <Breaking_Pitt> Hello guys
[13:11] <Breaking_Pitt> I have a lot of packages to do so every time I try a new one it comes with a different error
[13:11] <Breaking_Pitt> how can I avoid this error file-in-unusual-dir usr/local/lib/python2.5/site-packages/
[13:13] <POX> Breaking_Pitt: --prefix=/usr
[13:14] <POX> but first of all, you have to use python2.5 from package, not the local one
[13:18] <Breaking_Pitt> sorry POX ?
[13:18] <POX> Breaking_Pitt: Please paste output of: ls -la `which python2.5`
[13:19] <Breaking_Pitt> one moment please
[13:22] <Breaking_Pitt> POX -rwxr-xr-x 1 root root 1175796 2010-01-24 17:09 /usr/bin/python2.5
[13:22] <POX> please pastebin your debian/rules
[13:23] <Breaking_Pitt> ok
=== effie_jayx_ is now known as keffie_jayx
[13:37] <l3on> persia: hi... around? :D
[13:40] <Breaking_Pitt> POX I have decided that I will buil it from scrach when you want to build a package for a library using dh_make you select single binary or library?
=== Breaking_Pitt is now known as Breaking_Lunch
[13:44] <POX> Breaking_Lunch: depends on the type of package :P, `man dh_make` should have some info about it (I don't use dh_make), for python modules it will be single binary most probably (I'd use py2dsc instead of dh_make, though)
[13:49] <ScottK> lucas: Glad to hear you are coming.  It'll be good to see you again.
[13:49] <ScottK> YokoZar: No.  Got distracted.
[14:54] <philps> anyone know how to programmatically determine what disks are usb flash drives
[14:54] <philps> or maybe this is the wrong room.  let me know.
[14:55] <ScottK> It may be that #ubuntu-app-devel (or something close to that) is better.
[14:56] <philps> sounds good
[15:05] <lavlu> hi, i want to submit one package to ubuntu repository. the .deb package is fully functional. install fine and work fine. what should i do now ?
[15:05] <ScottK> !REVU | lavlu
[15:05] <ubottu> lavlu: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[15:06] <lavlu> thanks ScottK
[15:08] <ScottK> yw
[15:17] <sebner> persia: around for a SRU question?
[15:21] <ScottK> nhandler: Did you get a chance to look at that patch?
[15:23] <sebner> There is a crasher bug in bareftp 0.3.1 (which we have in lucid),  0.3.2 is bugfix only except translation updates, new 0.3.3 fixes this crasher bug but has also new features, what do you suggest?
[15:23] <sebner> cherry pick the crasher bug fix or go with 0.3.2+fix?
[15:24] <lfaraone> sebner: what sort of bugs?
[15:26] <sebner> lfaraone: http://pastebin.com/imE1q9Ux
[15:29] <ScottK> sebner: I suggest just the crash fix.
[15:29] <sebner> ScottK: sure?
[15:30] <lfaraone> sebner: "    + Improved drag'n drop. More user friendly on multiple selection" reads like a new feature.
[15:30] <ScottK> Minor bug fixes don't fit SRU criteria.
[15:30] <sebner> lfaraone: that's a bug for me :P
[15:30] <sebner> ScottK: aye aye then
[16:01] <lfaraone> How should a debian package handle depending on iceweasel? (should it be "iceweasel | firefox | abrowser" ?)
[16:03] <micahg> lfaraone: yes
[16:04] <micahg> lfaraone: be careful with version requirements of firefox if appropriate
[16:05] <ScottK> micahg: Why can't firefox provide iceweasel?
=== Breaking_Lunch is now known as Breaking_Pitt
[16:06] <ScottK> No versioned provides would be one good reason, bit it'd save a lot of modifying packages.
[16:07] <micahg> ScottK: That's a good question, I defer to asac or chrisccoulson
[16:07] <ScottK> OK.
[16:08] <micahg> speaking of asac: (10:05:39 AM) ScottK: micahg: Why can't firefox provide iceweasel?
[16:09] <chrisccoulson> i don't see any reason why firefox couldn't provide iceweasel
[16:10] <ScottK> That would certainly cut down on the number of packages that need merging.
[16:11] <micahg> chrisccoulson: should I add that to the general team discussion for UDS?
[16:12] <chrisccoulson> micahg - yeah, can do
[16:12] <micahg> chrisccoulson: just subscribed you also
[16:12] <chrisccoulson> thanks
[16:39] <Breaking_Pitt> I'm getting this error some advice? make[1]: *** No rule to make target `clean'.  Stop.
[16:40] <lfaraone> ScottK: maybe I'm missing something: how can we SRU something if it can't be fixed in the development release until maverick opens up?
[16:41] <ScottK> lfaraone: pitti will pocket copy from lucid-updates to maverick when it does.
[17:04] <Breaking_Pitt> I'm getting this make[1]: *** No rule to make target `clean'.  Stop.
[17:04] <Breaking_Pitt> some advice please?
[17:07] <ScottK> You need to have that target.  Why make thinks you don't is impossible to know without seeing the makefile in question.
[17:08] <Breaking_Pitt> is the debian/rules created by default by the dpkg-buildpakage
[17:08] <Breaking_Pitt> and has a clean: entry
=== yofel_ is now known as yofel
[17:11] <Breaking_Pitt> ScottK, http://pastebin.com/94kAsFCe this is my rules file
[17:13] <ScottK> That's a fragment of your debian/rules file and not your debian/rules file.
[17:14] <Breaking_Pitt> ok here it goes again http://pastebin.com/ksyGQ8DE
=== nobawk is now known as nobawk|away
[17:19] <Breaking_Pitt> ScottK, can you see something wrong?
[17:19] <ScottK> Sorry, I'm tied up with something else ATM.
[17:19] <Breaking_Pitt> ok
[17:27] <alket> Hi
[17:29] <alket> the current version of Bluefish in Ubuntu Universe is 1.*.* but in 15 March Blufish 2.0 came out
[17:29] <alket> when it is going to be an update ?
[17:30] <alket> ?
[17:31] <alket> anyone ?
[17:32] <astraljava> Might take a while. Debian unstable still has 1.0.7, so syncing to Maverick won't make it. Someone should package the latest version.
[17:33] <alket> astraljava thank you for response
[17:34] <astraljava> np :)
[18:09] <mannyv> I have had a go at my first potential security update if anyone has a moment would you mind providing feedback? https://bugs.launchpad.net/ubuntu/+source/opendchub/+bug/576507
[18:09] <ubottu> Launchpad bug 576507 in opendchub "OpenDcHub 0.8.1 Remote Code Execution Exploit" [Undecided,New]
[18:10] <persia> mannyv: For security-specific feedback (and procedures), #ubuntu-hardened may be more appropriate. (although I'm looking now)
[18:10] <mannyv> persia, ok thanks
[18:12] <persia> I'm not 100% sure, but I *think* you want -5ubuntu1 for maverick and -5ubuntu0.1 for lucid.
[18:12] <persia> Also, I *think* you want to target lucid-security
[18:12] <kees> both true
[18:12] <persia> The patch itself would benefit from application of http://dep.debian.net/deps/dep3/
[18:13] <mannyv> yeah i was pretty certain i got the versions wrong
[18:14] <persia> Based on the disclosure, it looks like prior versions are unaffected, but I believe it's best practice to attempt the exploit and see if they also need patching.
[18:14] <persia> dapper has 0.7.14 and the rest have 0.7.15
[18:16] <mannyv> ok so next steps for me would be to a) attempt on 0.7.{14,15}, b) create a seperate debdiff for each affected version, c) fix patch tagging ?
[18:18] <lfaraone> Is "lshell impropely handles shell expansions" a SRU-worthy fix? ("ll -a" -> "ls -l-a" rather than -> "ls -l -a")
[18:19] <lfaraone> ... at the same time, there's a security flaw in lshell that needs fixing apparently. Should these be separate uploads to the different pockets?
[18:24] <ScottK> lfaraone: Ask the secuirty team in #ubuntu-hardened.  I had one recently they said to put throught the SRU process first and then they'd also put it out through -security.
[19:54] <RainCT> geser: uhm good question, now that you mention it I have no idea what resolution those screens have. In any case, way more than enough :P
[19:56] <persia> No such thing.
[19:57]  * RainCT is confused. persia: was that for me?
[19:57] <RainCT> ah that there is not enough resolution?
[19:58] <persia> RIght.
[19:58] <persia> Human vision is about 60750x40500 pixels.
[19:58] <persia> Nobody makes displays like that.
[19:59] <persia> Actually, more like 80000x40000, but as two overlapping 60000x40000 fields.
[20:01] <RainCT> Well, I suppose there isn't much to gain with 40.000 pixel displays
[20:02] <persia> Well, you only need that resolution if you've built a 1" display and have it against your eye.
[20:02] <RainCT> lol
[20:03] <persia> For a standard monitor position, you only need about 9000x450
[20:03] <persia> Err, 9000x4500.
[20:03] <persia> Anything less and it's distinguishable from non-rendered objects.
[20:03] <persia> (well, depends on display size, distance, etc.)
[20:04]  * persia fails at math *again* : ~9000x6750 (at 4:3)
[20:08] <steev> hey all, I've got an issue with WINE and I need a newer openal (1.12.854 which was released in March) No problem I thought, I did a builddep of libopenal1, grabbed the patches and the 1.12.854 sources... but now for the life of me, I cannot seem to get it to create packages with the correct version # - what am i missing that I need to change?
[20:10] <persia> steev: I'd recommend starting from the Ubuntu openal sources, and running `uscan` in the package directory.  This will create a new source package with the new openal.
[20:34] <ScottK> YokoZar: I answered your wine question in the bug.
[20:36] <steev> persia: is there a 1.12.854 sources somehow?
[20:37] <persia> upstream.  All the packaged ones I know about got deleted.
[20:37] <persia> But like I said, it's one command to create a packaged 1.12.854 source.
[20:37] <persia> Just download the current lucid source, and run `uscan` in the package directory.
[20:38] <anoteng> Anybody care to enlighten me on why a precompiled binary in the source, installed with debian/install file gets corrupted? The size of the file is reduced from 2,7mb to 208 bytes? according to file, it's still a 32bit ELF binary though...
[20:38] <persia> This will download the upstream sources, and prepare a (separate) packaged directory with the udpated sources.
[20:38] <persia> anoteng: dh_strip maybe?
[20:38]  * anoteng reading manpage
[20:40] <steev> persia: hot.  that is awesome
[20:41] <ari-tczew> while using command 'dch -i' output target is lucid - is it correct (instead of maverick)? my distro is lucid
[20:41] <persia> ari-tczew: In my experience, it defaults to the target of the distribution you're running.  You want maverick if you are trying to upload to maverick.
[20:44] <imbrandon> precompiled binary in the source ? eww, why would you do that
[20:44] <anoteng> persia, adding export DEB_BUILD_OPTION="nostrip" to the top of the rules file should do the trick then right?
[20:44] <anoteng> imbrandon, i know it's not a good thing, but upstream insists...
[20:45] <imbrandon> cant be put in te archive either iirc
[20:45] <persia> anoteng: Something like that.
[20:46] <imbrandon> not just "not a good thing" but like very very very very very bad in 99% cases ( unless you are bootstrapping a new compiler )
[20:46] <anoteng> I know, I'm just trying to get the package working for know, then I'll make a policy compliant package later..
[20:46] <ScottK> imbrandon: If it's distributable, it could go in Multiverse.
[20:46] <persia> anoteng: Under what license is this source?
[20:46] <anoteng> gpl3
[20:47] <ScottK> Then don't use the pre-compiled binary.
[20:47] <imbrandon> just out of curiosity what software is it ?
[20:47] <persia> anoteng: Typically GPL3 software can't be distributed in compliance with the license with precompiled binaries.
[20:48] <anoteng> DamnVid, a python application.
[20:48] <anoteng> ok, maybe I'll try again to talk him out of it then..
[20:49] <persia> anoteng: The only way I know that would make it possible would be to compile another copy of the precompiled binary at build time, do a bitwise comparison to ensure the created binary was the same artifact as the precompiled binary, and then fail the build if it wasn't.  Otherwise, you can't know that the sources you distribute create the binary you distribute, which is a requirement of GPLv3.
[20:49] <imbrandon> anoteng: what is the precompiled binary ? ffmpeg ?
[20:49] <persia> Note that the original authors of software are *not* bound by these requirements, as they hold licenses other than those they offer to their users.
[20:49] <anoteng> yes
[20:49] <imbrandon> anoteng: no no no no, dont include ffmpeg in the source, esp precompiled
[20:49] <imbrandon> no no no
[20:49]  * imbrandon chants more
[20:51] <anoteng> mkay... will drop it then. But the application has some paths hardcoded. Do I need to patch the source, or can I simply make links?
[20:51] <imbrandon> anoteng: is there a reason it cant link against the normal ffmpeg ?
[20:51] <imbrandon> anoteng: patch it
[20:52] <imbrandon> and repack the tarbal +dfsg if it has the ffmpeg binary in the upstream tar
[20:52] <anoteng> I guess it's just to make life easier for the author, debugging etc.
[20:52] <psusi> anyone got any idea what could be causing this? Unable to obtain lock lp-69637264:///~psusi/ubuntu/lucid/ureadahead/mine/.bzr/branch/lock held by psusi@bazaar.launchpad.net on host crowberry [process #19287]
[20:52] <imbrandon> makes life hell for everyone else though
[20:52] <anoteng> +dfsg ???
[20:52] <psusi> locked 5 hours, 13 minutes ago
[20:52] <persia> psusi: Ask in #launchpad, but bzr break-lock seems to be the commonly-suggested solution.
[20:53] <psusi> hrm... k... the help file says not to use it unless you are sure the process is dead
[20:53] <imbrandon> anoteng: debian free software guidelines , e.g. remove the non-free bits from the tar, its a sticky situation for a first package
[20:53] <persia> anoteng: Debian Free Software Guidelines: used to indicate that you've packaged a special derived version of the upstream source that has been modified to comply with http://www.debian.org/social_contract#guidelines
[20:54] <anoteng> ok, thanks everyone...
[20:55] <imbrandon> anoteng: now that you have peaked my intrest if you have any problems getting this "right" lemme know i should be mostly avail to help ya
[20:55] <imbrandon> :)
[20:55] <anoteng> imbrandon, thanks...
[20:58] <ari-tczew> I'm preparing a merge @maverick, and I want to use a bazaar instead deprecated debdiffs. What I must to do? get current ubuntu branch or debian branch?
[20:58] <ScottK> ari-tczew: debdiffs aren't deprecated.
[20:58] <ari-tczew> ScottK: ok, so now is trend on bazaar
[20:59] <ScottK> Shifting to distributed development via bzr is a long term goal.  The current tool set works better for some aspects of development than others.
[21:00] <ScottK> There's decent wiki documentation on merging with bzr, but personally I find it a lot more complex.  Don't let me stop you though.
[21:00] <geser> ari-tczew: https://wiki.ubuntu.com/DistributedDevelopment/Documentation has some documentation on how to merge with bzr
[21:08] <imbrandon> ScottK: open the maverick archives already mr admin , lol j/k i konw you have -0- control over that
[21:09] <ScottK> imbrandon: Pleanty of SRUs one could do in the meantime if you need your upload fix.
[21:10] <imbrandon> ive looked through some, most are packages i wouldent feel comfortable touching /me looks again
[21:10] <persia> imbrandon: There's a few hundred FTBFSs, plus RCBugs that always needs attention.
[21:10] <persia> Same as prerelease rush, except SRUs.
[21:10] <imbrandon> true, i forgot ftbfs was a valid sru
[21:11] <persia> FTBFS is a fairly critical bug, especially as all the binaries got deleted :)
[21:11]  * persia was given a hint on dvipsk-ja today \\o/
[21:11] <imbrandon> is lucas's list fairly updated or is the one on qa.uw.o better ?
[21:13] <ScottK> ari-tczew: In Bug 576592 you said that a sync was appropriate because all changes have been forwarded to Debian.  It would be appropriate if all changes have been incorporated in the Debian package you're asking to have sync'ed, just forwarding them isn't enough.  I suspect this is a language issue and that's what you meant.  Please clarify in the bug.
[21:13] <ubottu> Launchpad bug 576592 in twisted-conch "Sync twisted-conch 1:10.0.0-3 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/576592
[21:14] <ScottK> imbrandon: Lucas' list shows everything that failed a rebuild test.  Ubuntuwire just shows onese where the last in archive build failed.
[21:14] <geser> imbrandon: both lists should be pretty up-to-date
[21:14] <imbrandon> k
[21:14] <ScottK> Most of the removed binaries are in lucas' list, but not the uw one.
[21:14] <geser> imbrandon: or do you mean the FTBFS page for the rebuild archive on qa.uw.o?
[21:14] <ari-tczew> ScottK: so do I have to change explanation to: all changes have been incorporated in the Debian package ?
[21:15] <ScottK> ari-tczew: A comment in the bug is fine.
[21:16] <ari-tczew> ScottK: I thought about explanation: 'Packages are the same' as well, would be good?
[21:16] <ScottK> ari-tczew: "all changes have been incorporated in the Debian package" is clearer.
[21:17] <ari-tczew> ScottK: ok, I'll remember
[21:23] <bilalakhtar> what is the process to become a motu?
[21:25] <ari-tczew> !motu
[21:25] <ubottu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
[21:29] <bilalakhtar> people, what is the process of becoming a motu?
[21:29] <sebner> !motu | bilalakhtar  ;)
[21:29] <ubottu> bilalakhtar  ;): motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
[21:30] <ari-tczew> bilalakhtar: https://wiki.ubuntu.com/MOTU#So%20you%20want%20to%20be%20a%20MOTU?
[21:31] <pochu> !motu | ubotu
[21:31] <ubottu> ubotu: motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
[21:31] <pochu> !motu | ubottu
[21:31] <ubottu> pochu: motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
[21:31] <pochu> heh, I wanted to DoS it :-)
[21:31] <ari-tczew> pochu, you're hardcore :D
[21:32] <bilalakhtar> sebner: I mean after a person becomes a contributor, what is the process after that?
[21:32] <bilalakhtar> !motu > ubottu
[21:32] <ubottu> bilalakhtar, please see my private message
[21:33] <ari-tczew> sebner: please throw red tomatoes at ... :P
[21:34] <sebner> ari-tczew: nah, only at hyperair and Laney :P
[21:34] <bilalakhtar> red tomatoes?
[21:34] <ari-tczew> yhy :(
[21:34] <sebner> bilalakhtar: nah, rotten ones
[21:35] <bilalakhtar> is this an !ot going on?
[21:35] <sebner> !OT | bilalakhtar
[21:35] <ubottu> bilalakhtar: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics. Thanks!
[21:35] <sebner> :P
[21:35] <ari-tczew> bilalakhtar: did you found how to become a motu?
[21:35] <bilalakhtar> ari-tczew: somewhat
[21:35] <hyperair> sebner: why meeeeeeeeeeeeeeee
[21:36] <ajmitch> hyperair: why not?
[21:36] <sebner> hyperair: you can take it :P
[21:36] <bilalakhtar> !ot | sebnar
[21:36] <ubottu> sebnar: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics. Thanks!
[21:36] <bilalakhtar> I wanted to send that to you
[21:36] <bilalakhtar> i mean sebner
[21:36] <hyperair> ajmitch: meanie.
[21:36] <sebner> whatever
[21:36] <hyperair> sebner: 20 points if you can aim tomatoes into my mouth.
[21:37] <hyperair> sebner: -100 if you hit anywhere else.
[21:37]  * bilalakhtar throws a tomato into hyperair's mouth on behalf of sebner 
[21:37]  * bilalakhtar gets 20 points
[21:37] <hyperair> om nom nom
[21:37] <sebner> hyperair: hmm, rotten tomatoes are not consistent enough during the flight, You'll get hit all over your body :P
[21:37] <bilalakhtar> hyperair: you like rotten tomatoes?
[21:38] <hyperair> bilalakhtar: er i've got a time machine embedded in my mouth that reverses the time of the tomatoes.
[21:38] <bilalakhtar> bye then, so long
[21:39] <sebner> hyperair: I added black magic to them, your time machine doesn't work! :P
[21:39] <ari-tczew> !OT | $ALL
[21:39] <ubottu> $ALL: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics. Thanks!
[21:40] <hyperair> sebner: i've got a magic nullifier integrated in the said time machine
[21:40] <persia> Um, let's not do that again.
[21:40] <sebner> persia++
[21:40] <sebner> tz tz tz, bad hyperair
[21:40] <persia> The right answer is something like "Well, you apply to the DMB to be MOTU.  See the bottom of the wiki page".
[21:40] <ari-tczew> bilalakhtar: I saw that you didn't make any package, so just start contribute to ubuntu
[21:41] <sebner> ari-tczew: hrm, too late ;)
[21:41] <ari-tczew> sebner: heh, too young
[21:41] <sebner> :)
[21:44] <ari-tczew> hmm, I tried to merge package using bzr, please someone who is the mastermind in bzr merging to check my work bug 521390
[21:44] <ubottu> Launchpad bug 521390 in junitperf "Merge junitperf 1.9.1-7 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/521390
[21:45] <ajmitch> ari-tczew: it may not matter for that one, but we're grabbing stuff from unstable again for maverick
[21:46] <ajmitch> looks like it's -7 in testing & unstable anyway
[21:46] <ari-tczew> ajmitch: I know, but this is residue from lucid development. I'm lazy for changing it due to the same package in testing / unstable
[21:47]  * hyperair redirects the blame to sebner
[21:47] <ajmitch> ari-tczew: ok :)
[21:48]  * ajmitch just wishes the generated diff was against the debian branch
[21:48] <sebner> hyperair: EHHHHHHHH????
[21:48] <ajmitch> but I don't know if there's anything we can do to change that, it only makes sense for these merges
[21:49]  * hyperair chuckles
[21:50] <ari-tczew> ajmitch: I did following: bzr branch lp ubuntu... then bzr-merge lp debian... then do changes necessary for merge sense then bzr add resolve commit... then push and request a merge. is it ok?
[21:50] <persia> ajmitch: There's a way to get LP to give you that (assuming the branches are imported as I think they are), but it takes something like 14 clicks (at least last time I tried, with different branches).  It's often easier/faster to generate locally.
[21:50] <ajmitch> ari-tczew: I don't know, I'm still not familiar enouugh with it all ;)
[21:51] <ajmitch> afaik there are various tools like bzr merge-package, debcommit which we're to use
[21:51] <ari-tczew> ajmitch: yea, massacre
[21:52] <ari-tczew> I think that my merge is OK, but I'm waiting to response from mastermind of bzr
[21:52] <ari-tczew> maybe geser?
[21:52] <ajmitch> it looks to be ok
[21:53] <ari-tczew> ajmitch: do you will take it to sponsor? ;-D
[21:53] <ajmitch> though when I click on the diff, I don't see the change in debian/ant.properties listed in the changelog
[21:54] <ari-tczew> ajmitch: because diff which you saw is based on current ubuntu branch, so in current ubuntu's delta we have debian/ant.properties file
[21:55] <ari-tczew> I think that, maybe I'm wrong, so correct me
[21:55] <ari-tczew> debdiffs are not hard like bzr :(
[21:56] <ajmitch> yeah, I think you're right there
[21:56] <ajmitch> the general case for making packaging changes is that we want to see changes against the current ubuntu branch, it's only here that I want to see the diff against debian
[21:56]  * ajmitch grabs branches to check
[21:58] <ari-tczew> ajmitch: before doing a bzr merge, I'm doing merge based on debdiffs dsc dsc > .debdiff, then I'm applying debdiff to bzr branch
[21:58] <ari-tczew> so I got a debdiff, I can attach to bug, but I think that is beside the point
[21:59] <ajmitch> that sort of defeats the purpose of trying to use branches
[22:02] <ari-tczew> honestly I don't see a sense to merging bzr.
[22:02] <ajmitch> I'm sure there is a point, we're probably just doing it wrong :)
[22:02] <ari-tczew> This extends the time of our work
[22:02] <maxb> Keeping full history of packaging changes can be very useful
[22:02] <maxb> I'm really liking merging in bzr now
[22:03] <maxb> Sure, it takes some time to absorb the bzr koolaid
[22:04] <ari-tczew> maxb, my question: merging bzr is a merge code of source package? or merge a revisions as well?
[22:04] <maxb> I'm afraid I can't understand your question
[22:05] <ari-tczew> lol, so, you've got a 2 bzr branches. In ubuntu and in debian right?
[22:06] <maxb> right
[22:08] <ari-tczew> yea cool, maxb please look at:
[22:08] <ari-tczew> https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/junitperf/maverick
[22:08] <ari-tczew> https://code.launchpad.net/~ubuntu-branches/debian/sid/junitperf/sid
[22:09] <ari-tczew> bzr is splitted on: revisions changelog and source code
[22:09] <ScottK> maxb: Since each upload to the archive is a separate commit in bzr, even if you ignore bzr for merging, updating, etc, we are now keeping a full history.
[22:09] <ari-tczew> we're merging a source code right? but what about revisions changelogs?
[22:10] <persia> ari-tczew: WHat do you mean by "revision" in that question?
[22:10] <maxb> ari-tczew: I'm still having difficulty understanding what you mean. I have no idea what you mean by "bzr is splitted on: revisions changelog and source code" at all
[22:11]  * ari-tczew doing like rageman
[22:11] <ari-tczew> I mean revision's changelog like
[22:11] <ari-tczew> Recent revisions
[22:11] <ari-tczew> 5. By Thierry Carrez on 2009-09-02
[22:11] <ari-tczew>     * debian/control, debian/rules: Build with default-jdk
[22:11] <ari-tczew>     * debian/control: Runtime depend on headless JREs
[22:11] <ari-tczew>     * Added debian/ant.properties to force java2 code generation
[22:11] <ari-tczew>     * debian/control: Policy fixups:
[22:11] <ari-tczew>       - Bump debhelper to version 5 (also in debian/compat)
[22:11] <ari-tczew>       - Add ${misc:Depends} to Depends
[22:11] <ari-tczew>       - Set default section to java
[22:12] <ari-tczew>       - Move clean target deps to Build-Depends:
[22:12]  * ajmitch points to mr pastebin for your problems
[22:14] <ari-tczew> ok, please close this discuss thread, you won't understand what I mean
[22:14] <persia> ari-tczew: Do you mean the data from `bzr log` or the data in debian/copyright?
[22:15] <ari-tczew> persia: yea bzr log, that's right!
[22:15] <maxb> The merge looks fine to me, except that "Force java2 code generation" is a poor way to describe "Compile with Java 1.4 source and target version."
[22:16] <maxb> Furthermore, it would be useful to have some indication of whether using 1.4 is a higher or lower version that would be used by default, and when that ubuntu-local change could be dropped
[22:16] <ari-tczew> maxb: is modeled on the antecedents
[22:17] <maxb> It is part of the job of anyone doing a merge to look for opportunities to discard Ubuntu-specific changes where reasonable
[22:18] <ScottK> and make sure ones that are appropriate to Debian have been sent there.
[22:18] <ScottK> nhandler: Did you get a chance to look at that patch?
[22:20] <ari-tczew> persia: who will decide about MOTU applications on next DMB agenda 11th May?
[22:20] <persia> Same folk as usual.
[22:23] <sebner> persia: *you* created a maverick shbuild successfully, right?
[22:23] <persia> sebner: Yes, a nice fresh one, just when you asked.
[22:24] <sebner> persia: it seems there is a general problem with pbuilder. As I'm a little bit ill I'm heading to bed now, would you mind doing the sync request of wesnoth? (In fact just needs a testbuild, rest is fine)
[22:25] <persia> sebner: http://people.ubuntu.com/~persia/pull-soyuz-chroot needs a pbuilder hint, but can be a shortcut to get a chroot.
[22:25] <persia> (but yeah, I'll testbuild)
[22:25] <sebner> thx
[22:25]  * sebner is off then
[22:26] <maxb> ari-tczew: So in summary, your branch is fine, you just need to provide the debdiff between the debian version and your branch, and explain that the launchpad diff in the merge proposal is the diff between the existing ubuntu version and your merge, not what the reviewers have assumed it to be
[22:27] <persia> No.
[22:27] <persia> Really no.
[22:28] <persia> If one is going to use the bzr method, one should use it entirely, and do a merge-proposal.
[22:28] <maxb> persia: There *is* a merge proposal
[22:28] <ari-tczew> maxb: I don't believe.
[22:28] <persia> The sponsor should then *completely ignore* this merge proposal, and use bzr diff between the Ubuntu and Debian remote branches.
[22:29] <persia> Or rather the *candidate* and Debian remote branches.
[22:29] <ari-tczew> then I f|_|ck this due to too long work. don't have time for statistic
[22:29] <persia> If one uses the debdiff method, there's not much point to fiddling with bzr in the first place, unless one happens to like how bzr merges work.
[22:29] <persia> !ohmy | ari-tczew
[22:29] <ubottu> ari-tczew: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[22:30] <ari-tczew> persia and other, sorry
[22:30] <ari-tczew> I conclude that bzr merge is theft of time
[22:30] <ari-tczew> I like work on bzr with SRUs or security updates
[22:31] <ari-tczew> but merging between distros... sorry, no
[22:31] <maxb> bzr merge is fine and good, the problem is when sponsors aren't comfortable with bzr merging
[22:32] <persia> maxb: Rather the annoyance is that the merge proposal is completely useless to the sponsor.
[22:33] <ari-tczew> persia: where can I find a history of DMB  agenda meetings?
[22:33] <persia> ari-tczew: ubuntu-devel-announce@ archives is your best source
[22:33] <persia> Or check the wiki history
[22:35] <ari-tczew> yea, wiki history is good optin
[22:35] <ari-tczew> option
[22:38] <MTecknology> what's up with this version number having 2 ubuntu parts to it? 5.4.2.1~dfsg0ubuntu1-0ubuntu2
[22:42] <ari-tczew> what about changes on upgrading jaunty -> lucid? can I drop it for maverick?
[22:43] <maxb> MTecknology: someone Doing It Wrong? :-)
[22:43] <MTecknology> !info snmpd | maxb
[22:43] <ubottu> maxb: snmpd (source: net-snmp): SNMP (Simple Network Management Protocol) agents. In component main, is optional. Version 5.4.2.1~dfsg0ubuntu1-0ubuntu2 (lucid), package size 927 kB, installed size 1220 kB
[22:44] <MTecknology> maxb: I'm guessing 5.4.2.1~dfsg0ubuntu2 would have been right?
[22:46] <maxb> Oh
[22:46] <maxb> I see what's going on
[22:46] <maxb>   * Repackage upstream tarball to re-add the MIBs: even if they are not modifiable (which is questionable), this is not a reason to keep them out of Ubuntu main.
[22:47] <maxb> That is the critical changelog entry
[22:47] <maxb> So in this case, the version number, despite looking weird, is actually correct
[22:48] <maxb> It means:
[22:48] <maxb> [5.4.2.1] An upstream tarball
[22:48] <maxb> [~dfsg] repackaged by debian
[22:48] <persia> No.
[22:48] <persia> Repackaged to be DFSG-free
[22:48] <maxb> [0ubuntu1] repackaged again by ubuntu
[22:48] <maxb> [-0ubuntu2] and then packaged by ubuntu
[22:49] <persia> No, repackaged the *first* time by Ubuntu (otherwise would have been dfsg1)
[22:49] <persia> Bit it *should* be 5.4.2.1+dfsg...
[22:49] <persia> That's a horrid misuse of ~
[22:49] <maxb> persia: *No*
[22:49] <maxb> Repackaged first in debian. Re-repackaged in Ubuntu
[22:50] <persia> Well, then the numbers are not only an annoying example of doing it wrong, but they happen to be the wrong numbers too!
[22:50] <persia> dfsg0ubuntu1 *should* mean repackaged in Ubuntu but not (yet) repackaged in Debian.
[22:51] <maxb> dfsg0ubuntu1 is the only reasonable thing to do when the debian repackaging is just 'dfsg' with no numeral
[22:51] <persia> No, that should be dfsgubuntu1
[22:51] <persia> At least according to the way we usually do it.  See my wiki page for at least one way in which I find that completely wrong.
[22:52] <persia> (thankfully somewhat obsolete due to process changes in Debian)
[22:52] <maxb> No, because if debian then *do* make a dfsg2, dfsgubuntu1 is still greater than dfsg2
[22:53] <persia> yeah, but it should have been +dfsg1-1 in the first place.
[22:53] <persia> Anyway, lots of folks doing it wrong, repeatedly, and again.
[22:53] <maxb> Ideally yes, but the ubuntu numbering is the best approach consistent with the current versioning in debian
[22:57] <persia> I won't disagree, although it violates our "best practice" recommendations (see prior note about wiki page)
[22:57] <maxb> best practice?
[22:58] <persia> Yeah.  It's documented in several places that we're supposed to add "ubuntu1" when first diverging.
[22:58] <persia> Which is what dch does by default.
[22:58] <persia> So if you have "1.2.3+dfsg" as a native package, dch will give you "1.2.3+dfsgubuntu1"
[22:59] <maxb> That is an orthogonal issue. This is not a native package
[22:59] <persia> Only kinda.
[22:59] <maxb> Only completely
[22:59] <maxb> Interesting and painful issue you highlight on your wiki page, though, hinging on a very obscure detail of how versions are compared
[22:59] <persia> So, the first ubuntu1 was added to the upstream version: if we ignore the part after the "-", it's the same as updating a native package.
[23:00] <persia> maxb: It's not as bad anymore, because Debian changed how NMUs work, but yeah.
[23:01] <ari-tczew> what about changes on upgrading jaunty -> lucid? can I drop it for maverick?
[23:01] <persia> You suggest the insertion of a "0" as being least bad, which might be true, but it's different than just adding "ubuntu1", which is the recommendation in the context which was presumably used as an analogue to determine the version to select.
[23:02] <persia> In practice, most folk repacking in Ubuntu just use an upstream version following the rules that Debian would, without much regard for how it syncs/merges
[23:02]  * persia has a list of several hundred packages with the *same* apparent version, but different orig.tar.gzs
[23:03] <persia> ari-tczew: Depends on the nature of the change.  If it's still required for someone with an original jaunty install, no.
[23:03] <persia> Any upgrade from jaunty would have been lucid at some point, so if that takes care of everything so that the next upgrade doesn't need it, it can be dropped.
[23:04] <ari-tczew> persia: ok so I'll drop it, I thought so. thanks
[23:04] <maxb> The 'append ubuntu1' recommendation is regarding packaging changes rather than repacks, and incorporates the assumption that most/all version strings end with a numeric component, or, if they don't, the likelyhood of a numeric component being appended is very slim
[23:05] <fabounet> Hello !
[23:05] <fabounet> we have some bugs-fixs for Cairo-Dock, and we'd like to see them integrated on Lucid.
[23:05] <fabounet> Here is the bug report on LP :
[23:05] <fabounet> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/576647
[23:05] <ubottu> Launchpad bug 576647 in cairo-dock-plug-ins "Please update Cairo-Dock with the following patches" [Undecided,New]
[23:05] <maxb> The additional zero in the repacked tarball version here is insurance against the possibility of a second debian repack being labelled dfsg2 or somesuch
[23:05] <persia> ari-tczew: I didn't say drop it.  I said investigate and test.
[23:06] <persia> fabounet: With lucid released, the process gets a lot more complicated.
[23:06] <persia> !sru
[23:06] <ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[23:06] <persia> fabounet: So, you need to show that a bug meets one of the SRU criteria, and provide test cases, etc.
[23:06] <fabounet> they do :)
[23:06] <persia> Based on the bug you show, I think you've a chance, but be aware it's complicated, and will need a lot of handling.
[23:06] <fabounet> we have uploaded thepatches
[23:07] <fabounet> and give some indications on their critical level
[23:07] <persia> Right, but you need to document the test cases, etc.
[23:07] <persia> See the procedure documentation.
[23:07] <fabounet> do you have an example ?
[23:08] <fabounet> ah, I see there are 2 examples
[23:08] <fabounet> so basically we just need to add a test case ?
[23:09] <matttbe> Hello!
[23:09] <matttbe> persia: who can verify our modifications? SRU Verification team?
[23:12] <persia> matttbe: They will review the code changes, yes.  The process is (quickly): 1) update the bug with justification, details, test case, etc. 2) get it uploaded, 3) hear from the SRU team and address their concerns, 4) undergo the verification process, 5) get the update released.
[23:12] <persia> But see the wiki page for details.
[23:12] <matttbe> persia: thank you for this explanation!
[23:17] <fabounet> thanks, I've added the test cases
[23:19] <persia> OK.  Next is a minor nit: you want to target "lucid-proposed" instead of "lucid" for a proposed SRU.  If maverick weren't frozen, you'd want to target "maverick" first, and *then* lucid-proposed (have to fix the latest release first)
[23:21] <persia> You wanted to have described "ubuntu-sru" rather than "sru-verification" (so subscribe "ubuntu-sru" now)
[23:21] <persia> And be sure to nominate for lucid.
[23:21] <persia> s/described/subscribed/
[23:23] <matttbe> persia: thank you, ubuntu-sru has been subscribed but I don't understand what I've to do in order to update Lucid and Maverick versions
[23:24] <matttbe> should I have to add a tag lucid-proposed?
[23:24] <persia> maverick is frozen right now, so no need to worry about that.  Next week, you'll want to fix any bugs in maverick before they can be approved to be fixed in lucid.
[23:24] <persia> Nope, you want the "nominate for release" link.
[23:24] <persia> and then nominate for lucid there.
[23:25] <matttbe> ok, I see
[23:25] <persia> Heh.  The test case description doesn't make it easy for the verification team.  Is there any way to construct some artifical data that will force a crash?
[23:26] <matttbe> for most of them, it's easy to do the verification
[23:27] <fabounet> I think it's easier to just read the patch, than trying to reproduce the bug ^^
[23:28] <fabounet> the patches are indeed very straightforward
[23:29] <persia> OK.  Be warned the verification team may have comments :)
[23:30] <fabounet> ok thanks for the advice :)
[23:30] <fabounet> I'll take the time to explain them then
[23:31] <persia> The key is that some members of the verification team are just testers, and may not be good at reading code.
[23:31] <matttbe> So we just have to wait now? :)
[23:31] <persia> If there's a clear test case, that makes it easier for them, so it's faster to get verified.
[23:34] <fabounet> ok, well 2 bugs are definitely not easy to reproduce (actually I couldn't reproduce them myself, I just guessed the cause thanks to the different bug-reports soem users made)
[23:35] <matttbe> but for these two bugs, we've just added a new test for some special case (e.g. if the WM is launched after Cairo-Dock)
[23:37] <ubuntujenkins> hello I have a package that I have made using a dir2deb script that someone suggested (i did check it first). I would like these two commands as the last thing when the package is configured sudo texhash /usr/share/texmf-texlive' then updmap --enable Map ccicons.map . How/where would i add them to get them to run?
[23:38] <ubuntujenkins> any suggestions welcome
[23:41] <persia> ubuntujenkins: http://wiki.debian.org/MaintainerScripts
[23:42] <ubuntujenkins> thanks persia I will get reading
[23:44] <persia> fabounet: matttbe: Looks like your bug is in a good state.  Now you just need a sponsor, so subscribe the sponsors team ("ubuntu-sponsors").
=== nobawk|away is now known as nobawk
[23:44] <matttbe> persia: thank you, I will do that
[23:44] <persia> Someone will upload, and then the SRU team will review, and then the verification team will verify, and then it will be published (or someone will comment along the way)
[23:45] <ari-tczew> when maverick will be open?
[23:45] <ari-tczew> I'm very impatient :P
[23:46] <matttbe> ari-tczew: it's open :)
[23:46] <matttbe> ari-tczew: http://uppix.net/9/9/0/0565c5d1be002bcfc7a10271afa3e.png
[23:47] <ari-tczew> matttbe: are you sure? [00:24] <persia> maverick is frozen right now
[23:48] <matttbe> repositories are open, I just have some updates like gcc
[23:49] <matttbe> but the upload is maybe frozen now
[23:49] <matttbe> I don't know
[23:49] <maxb> https://launchpad.net/ubuntu/maverick
[23:49] <maxb> Status:
[23:49] <maxb>     Pre-release Freeze
[23:49] <persia> Right.  Frozen.
[23:49] <persia> Upoads work, but aren't required to be publised before pushing SRUs.
[23:51] <ari-tczew> before pushing SRUs? I don't understand. I'm interested in merges and syncs
[23:51] <maxb> I don't think you need to even upload to maverick to do a SRU, until the archive opens
[23:51] <micahg> persia: also pitti has said that -proposed can be pocket copied to maverick if nothing newer has been uploaded