| * jdong just spent a good chunk of time editing https://help.ubuntu.com/community/UbuntuBackports | 00:15 | |
| jdong | updated the 3-year-old description of the project :D | 00:15 |
|---|---|---|
| ScottK | Yeahhh. | 00:16 |
| jdong | and also tried to reorganize the rules/requirements and the process for triage a bit more clearly | 00:16 |
| RAOF | jdong: Yay! | 00:18 |
| jdong | RAOF: figured mentioning the -extras repo (last used in Warty) in the first 3 lines is a sign that the document is outdated :D | 00:19 |
| RAOF | :) | 00:20 |
| jdong | now to figure out how to merge https://wiki.ubuntu.com/BackportRequestProcess into the main document... | 00:22 |
| RAOF | I should probably file some backports requests. Kvm at least is *much* faster, and now supports smp guests. | 00:23 |
| jdong | laziness, how do I get a TOC to show up on a wiki page? | 00:24 |
| === `23meg is now known as mgunes | ||
| bddebian | Heya gang | 00:44 |
| RAOF | Good $TIME_OF_DAY bddebian ;) | 00:49 |
| bddebian | Hi RAOF | 00:50 |
| ajmitch | hello | 00:52 |
| * ajmitch waves to Hobbsee | 00:52 | |
| Hobbsee | hey ajmitch! | 00:52 |
| bddebian | Heya ajmitch | 00:52 |
| LaserJock | hi bddebian ajmitch Hobbsee et al | 00:53 |
| bddebian | Heya LaserJock | 00:54 |
| ajmitch | ponies! | 00:54 |
| StevenK | Right. Ponies! | 00:54 |
| Hobbsee | yes, ponies are mandatory. | 00:55 |
| lifeless | Pony! | 00:55 |
| lifeless | ponyponypony pony! | 00:55 |
| * RAOF calls his psychic pony back from vacation. | 00:55 | |
| LordKow | interesting, i just searched for a source file on google and my first result was "the society for the protection of unborn children" | 00:55 |
| LordKow | okay well i guess their abbreviation would be the source file im looking for | 00:56 |
| Hobbsee | RAOF: it's gone the way of my psychic frog | 00:58 |
| RAOF | I didn't know you had a psychic frog! My pony's been holding out on me! | 00:59 |
| LordKow | has anyone ever forgotten their birthday? | 01:03 |
| jdong | hmm PPA's look nice for Backports triage but a key lacking feature is the ability to notify on build success | 01:03 |
| jdong | LordKow: yeah, I have been guilty of that | 01:03 |
| LordKow | yea its now 7:04pm on November 20th and it is just now that i realized its my birthday heh | 01:04 |
| jdong | LordKow: well happy birthday | 01:04 |
| LordKow | thanks | 01:04 |
| RAOF | jdong: Is the absence of a build-failure email enough? | 01:04 |
| RAOF | Heh. Happy birthday! | 01:04 |
| jdong | RAOF: considering the build queue tends to be $a_really_long time, not really | 01:04 |
| jdong | I guess I still need to do a bit more thinking about how to handle this | 01:05 |
| jdong | definitely the PPA will remain a key piece of my plans for backport triage | 01:05 |
| jdong | just I'm not sure if PPA alone suffices, or shall I have something that crawls the PPA's and bug reports | 01:06 |
| jdong | I guess I'll try to organize my thoughts on how I want an upload to a PPA be connected to a bug report, then file that information as a LP feature request and see where that takes me | 01:06 |
| RAOF | for bug in lpbugs.backports() : if check_ppa_build() : lpbugs.set_confirmed() kinda thing? | 01:07 |
| jdong | RAOF: yeah. Better if it can be hooked as an event from the ppa and build daemons | 01:08 |
| jdong | RAOF: i.e. Upload pings the bug report with .changes, no status change | 01:08 |
| jdong | RAOF: all build updates (success/depwait/fail) ping the bug report | 01:09 |
| jdong | that would suffice | 01:09 |
| jdong | RAOF: it's also a problem that depwait for backports == fail but PPA's do not treat it so harshly :) | 01:09 |
| Hobbsee | jdong: apparently the option is planned for "i know what the hell i'm doing, let me have my components back" | 01:10 |
| Fujitsu | Hobbsee: Ooh, good. | 01:10 |
| Fujitsu | Do we get pockets too? | 01:10 |
| Hobbsee | no idea | 01:10 |
| Hobbsee | mark didn't mention them :) | 01:10 |
| jdong | okie, question for you guys: | 01:14 |
| RAOF | jdong: Ah, yeah. depwait is not a good thing ;) | 01:14 |
| jdong | so my current TODO list is blocking on faad2's build. It FTBFS'ed on all arches due to xmms-dev being uninstallable.... | 01:14 |
| jdong | So I looked into that, uploaded a rebuild of xmms to resolve that..... | 01:15 |
| LordKow | anyone here have a ppc setup? new crash build w/ an extension that is built only on ppc systems. | 01:15 |
| jdong | Currently the rebuild is done on 2 archs, namely i386 which I care the most about atm... | 01:15 |
| jdong | should I upload a faad2 that build-deps specifically >= the rebuild version of xmms? | 01:15 |
| jdong | because if the buildd tries to install the earlier, the build will bomb out | 01:16 |
| jdong | but if I put the build-dep there, it'll depwait until the xmms package builds on that arch in question | 01:16 |
| RAOF | Why is that a problem? | 01:16 |
| jdong | RAOF: why is what a problem? | 01:16 |
| RAOF | That it'll depwait until the dependency is built. | 01:17 |
| jdong | RAOF: I guess it isn't. I'm just wondering if I am being impatient | 01:17 |
| RAOF | I suppose it means you might be building a stack where the bottom piece FTBFS on some archs, but apart from that... | 01:17 |
| jdong | I mean the alternative would be to wait 3 centuries or whatever for all xmms to build and then requesting give-back | 01:18 |
| jdong | I figure it's better to upload a tighter build-dep on faad2 so at least I can have ONE arch that's built and ready to go | 01:19 |
| Hobbsee | jdong: this is true, but where is this building for? | 01:19 |
| jdong | Hobbsee: hardy universe | 01:19 |
| jdong | Hobbsee: xmms -> gpac (libgpac-dev) -> mpeg4ip (libmp4v2-dev) -> gtkpod-aac | 01:20 |
| jdong | that's the chain I'm working on | 01:20 |
| jdong | so there's a lot waiting on this stupid xxms thing | 01:20 |
| jdong | err insert faad2 between gpac and mpeg4ip | 01:20 |
| jdong | just wanted to make sure nobody'd get pissed at me if I uploaded a rebuild of faad2? | 01:20 |
| Hobbsee | jdong: wait a sec | 01:21 |
| Hobbsee | jdong: right, xmms should be taken next | 01:22 |
| jdong | Hobbsee: yeah xmms already has good build on ppc and i386 according to LP | 01:22 |
| LordKow | what is the proper way to put LP: #whatever into the changelog? i think there was a wiki on this somewhere but i cant find it | 01:22 |
| Fujitsu | LordKow: LP: #whatever | 01:23 |
| jdong | Hobbsee: so I need faad2 to depend on the good version of xmms, the rebuild. | 01:23 |
| Hobbsee | jdong: well, the others are being taken now | 01:23 |
| Hobbsee | er... | 01:23 |
| jdong | Hobbsee: unless I want to request give-back once all xmms's are definitely done | 01:23 |
| Hobbsee | oh, i see why lamont says this doesnt work | 01:23 |
| zul | grr.. | 01:23 |
| Hobbsee | jdong: right. *now* the xmms stuff should be taken once the current lot has finished building. | 01:24 |
| jdong | Hobbsee: ok, so would it be okay to upload faad2 depending on xmms >= $rebuild_ver? | 01:25 |
| Hobbsee | jdong: if you like, otherwise i should be able to give faad2 back | 01:26 |
| jdong | Hobbsee: are you sure xmms has built on all arches? | 01:26 |
| jdong | AFAICT LP says only i386 and ppc | 01:26 |
| Hobbsee | jdong: it has not, as yet. | 01:26 |
| Hobbsee | read what i said :) | 01:26 |
| Hobbsee | [12:24] <Hobbsee> jdong: right. *now* the xmms stuff should be taken once the current lot has finished building. | 01:26 |
| * Hobbsee hits retry on i386 adn ppc | 01:27 | |
| jdong | Hobbsee: ah you can retry arch-by-arch? | 01:27 |
| Hobbsee | yup | 01:27 |
| jdong | Hobbsee: ok, that's where my misunderstanding was. That'd be good then, please do :) | 01:27 |
| Hobbsee | already done for those that have built. | 01:27 |
| Hobbsee | poke me when xmms2 has built on !lpia, please | 01:28 |
| Hobbsee | or maybe !lpia+hppa | 01:28 |
| jdong | Hobbsee: will do. thank you | 01:28 |
| Hobbsee | no problem | 01:28 |
| leonel | if hardy feature freeze is scheduled for february 14fh means that no new package versions can be added to Hardy ?? | 01:33 |
| LaserJock | leonel: no | 01:34 |
| LaserJock | leonel: it means no new features | 01:34 |
| azeem | new packages are new features this time I thought | 01:34 |
| LordKow | bug 164229 | 01:35 |
| ubotu | Launchpad bug 164229 in crash "Please merge crash-4.0-4.9-1 (universe) from Debian unstable (utils) " [Undecided,Confirmed] https://launchpad.net/bugs/164229 | 01:35 |
| azeem | unless you get an exception, that is | 01:35 |
| LaserJock | I think that FF is also upstream version freeze for hardy | 01:35 |
| azeem | would be strange that it wouldn't be new package freeze as well then | 01:35 |
| LaserJock | yes | 01:36 |
| azeem | uh, or maybe I misread the initial question | 01:36 |
| LaserJock | I read it to mean new uploads period | 01:36 |
| === tudenbart is now known as dothebart | ||
| Hobbsee | LaserJock: new package freeze == ff == uvf | 01:38 |
| Hobbsee | it's changed | 01:39 |
| Hobbsee | which means that we're going to need to be relatively ruthless about the queue | 01:39 |
| LaserJock | Hobbsee: that's what I was trying to say | 01:39 |
| RAOF | Hm. gnome-power-manager is a little bit overprotective when it can't get HAL information. It's just turned off my laptop as soon as the battery-low light started flashing :( | 01:48 |
| leonel | LaserJock: what I meant was that PostgreSQL 8.3 beta 3 came out today and maybe for january there will be a PostgreSQL 8.3 release and I think would be great to have it included in Hardy | 01:52 |
| LaserJock | leonel: you might need to file an exception if it's after the freeze then | 01:54 |
| azeem | leonel: january isn't february 14th | 01:54 |
| * slangasek checks his calendar | 01:54 | |
| leonel | azeem: and Maybe isn't a thing that will happen for sure | 01:55 |
| leonel | LaserJock: thanks | 01:55 |
| Ubulette | https://edge.launchpad.net/+builds/palmer ??? | 02:00 |
| Ubulette | Started 12 hours ago ? | 02:00 |
| Fujitsu | Oh dear, who blew up Soyuz? | 02:02 |
| Hobbsee | that would appear to have finished building. | 02:02 |
| Fujitsu | Hobbsee: Apparently not. | 02:02 |
| Hobbsee | well, from the build log | 02:05 |
| StevenHarperUK | Hi- I have a Question, once my package gets past the NEW Queue - https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=&start=60- how do I supply future updates, I have a 0.2.1.14 ready to replace it. | 03:02 |
| StevenHarperUK | My package is easycrypt - 3rd in the queue | 03:02 |
| Hobbsee | do the update, subscribe ubuntu-universe-sponsorts | 03:03 |
| Hobbsee | -t | 03:03 |
| StevenHarperUK | Sorry Hobbsee so you mean join the Launchpad team? | 03:04 |
| Hobbsee | NO. read the fine description. | 03:05 |
| Hobbsee | subscribe != join | 03:05 |
| Hobbsee | is *this* why so many people appear to have trouble. | 03:05 |
| StevenHarperUK | Right so you mean on Launchpad (implied) I subscribe to that team? | 03:06 |
| * Fujitsu didn't see the `to' in Hobbsee's statement. | 03:06 | |
| Hobbsee | uh, no, read what i said. | 03:07 |
| ajmitch | Hobbsee: LP terminology is unclear? | 03:07 |
| Hobbsee | subscribe the bug. read the team description. | 03:07 |
| Hobbsee | ajmitch: if you've got suggestions on how to fix it, go right ahead. | 03:07 |
| StevenHarperUK | "do the update" : on what ? where? | 03:07 |
| * Hobbsee checks the second link in the topic | 03:08 | |
| * Hobbsee would suggest seeing the section marked "Preparing New Revisions" | 03:09 | |
| * ajmitch was looking for such a link to the latest new upstream version sponsorship rules | 03:09 | |
| Hobbsee | ajmitch: with feature freeze? | 03:09 |
| ajmitch | given that persia posted to the list about it in the last couple of days | 03:09 |
| ajmitch | no, just how to go about it | 03:09 |
| Hobbsee | oh right | 03:09 |
| Hobbsee | not sure, havent read it yet :) | 03:09 |
| StevenHarperUK | Cheers Hobbsee I can see what you mean now | 03:10 |
| ajmitch | about interdiff, etc | 03:10 |
| * ajmitch digs for archives | 03:10 | |
| ajmitch | https://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002767.html | 03:10 |
| StevenHarperUK | Hobbsee: Thanks I have all the info now, I just have to wait till it gets processed. Thanks | 03:12 |
| ajmitch | sigh, such arduous duties for work | 03:13 |
| * ajmitch has to make the ultimate sacrifice today | 03:13 | |
| StevenHarperUK | Can I have your PC when your gone then? | 03:13 |
| ajmitch | no | 03:15 |
| StevenHarperUK | Was worth a shot.. | 03:16 |
| Fujitsu | ajmitch: With what horrors have you been tasked? | 03:16 |
| ajmitch | leaving work early to go to the pub | 03:17 |
| Hobbsee | <gasp> | 03:18 |
| StevenK | Isn't that an Australian thing to do? | 03:19 |
| ajmitch | we can manage that here as well | 03:19 |
| Hobbsee | you just take a sheep with you | 03:20 |
| pwnguin | new zealand is like the australian canada | 03:20 |
| * ajmitch lobs an exploding sheep at Hobbsee | 03:22 | |
| * Hobbsee shrugs, seeing as it exploded in the ocean | 03:22 | |
| ScottK | Boiled mutton? | 03:23 |
| StevenHarperUK | Chuck another Moose on the Barbie? | 03:24 |
| pwnguin | too much S*K | 03:25 |
| * StevenK adds to the mix | 03:25 | |
| * Hobbsee stirs, puts through the blender. | 03:26 | |
| ajmitch | blended boiled mutton? | 03:26 |
| ajmitch | ick | 03:26 |
| pwnguin | im just gonna throw it out there: skowalik is more rare than StephenK | 03:26 |
| pwnguin | or stevenk | 03:26 |
| TheMuso | lol | 03:27 |
| Fujitsu | StevenK: Why have you not given up your nick already? | 03:28 |
| spowers | maybe this is a dumb question considering who i'm asking, but can i get a reasonable approximation of a gutsy install in a chroot by using debootstrap? | 03:28 |
| StevenK | Fujitsu: Grrm? | 03:29 |
| jdong | sure, debootstrap is an easy way of initializing a Debian/Ubuntu environment | 03:29 |
| pwnguin | spowers: im pretty sure you can just use pbuilder to do what you want | 03:29 |
| pwnguin | and i think it uses debootstrap | 03:29 |
| Fujitsu | StevenK: You don't meet the standard of the Evil Empire. | 03:29 |
| jdong | spowers: is this for the purpose of build testing Ubuntu packages? | 03:29 |
| jdong | spowers: or for something else? | 03:29 |
| StevenK | Fujitsu: Oh, plap off | 03:29 |
| spowers | nfs-rooted box | 03:29 |
| jdong | spowers: oh, then (1) yes (2) this is not a support channel | 03:30 |
| spowers | jdong: in that case, it's for build testing packages, and thank you :) | 03:30 |
| jdong | *blink* | 03:30 |
| * jdong walks away | 03:30 | |
| pwnguin | well if its for building test packages, you should be using pbuilder :P | 03:30 |
| pwnguin | spowers: lying isnt nice | 03:30 |
| jdong | spowers: though thanks, the humor has brightened a long stressful day :) | 03:31 |
| spowers | well, sorry if i used the wrong venue, but i didn't even want to try asking #ubuntu | 03:31 |
| pwnguin | answers.launchpad.net seems to work okay for me | 03:32 |
| Hobbsee | Fujitsu: it's The Evil Canonical Empire (tm), tyvm. | 03:32 |
| Fujitsu | Hobbsee: Ah, sorry. | 03:32 |
| Fujitsu | Or ®? | 03:32 |
| * StevenK sighs | 03:32 | |
| ajmitch | Hobbsee: sorry, did I forget to grovel at the mention? | 03:33 |
| Hobbsee | ajmitch: yes, but StevenK will have to do something about that, not me | 03:33 |
| ajmitch | ah | 03:33 |
| StevenK | I will? What? | 03:33 |
| ajmitch | StevenK wouldn't do anything though | 03:33 |
| ajmitch | you'd beat me up, however | 03:34 |
| * Hobbsee is not a part of The Evil Canonical Empire (tm), so can do nothing. | 03:34 | |
| ajmitch | no, but you'd still beat me up, just for fun :P | 03:34 |
| Hobbsee | oh, of course. that goes wihtout syaing. | 03:35 |
| Fujitsu | Did this Gutsy machine just turn into a Mac? I've got a very System 7ish watch as a cursor on a blank screen. | 03:35 |
| TheMuso | Fujitsu: lol | 03:35 |
| ajmitch | it's always been like that | 03:35 |
| Fujitsu | And woot, PAM seems fscked too. | 03:35 |
| Hobbsee | Fujitsu: it's from too much computer use . your eyes are doing that | 03:35 |
| RAOF | Hm. Has hal died in Hardy for anyone else? | 03:39 |
| ajmitch | nope | 03:40 |
| ajmitch | not silly enough to run hardy :) | 03:40 |
| RAOF | Soft! | 03:40 |
| * TheMuso is staying well away from hardy for a while. Chroots are good enough for me. | 03:40 | |
| * ajmitch likes his working system for now | 03:40 | |
| ajmitch | https://bugs.edge.launchpad.net/ubuntu/+source/tzdata/+bug/164254 looks odd | 03:40 |
| TheMuso | I am in agreeance with ajmitch. | 03:40 |
| ubotu | Launchpad bug 164254 in tzdata "tzdata upgrade: /usr/sbin/tzconfig: No such file or directory" [Undecided,New] | 03:40 |
| jdong | oh look at my functional hal from gutsy. | 03:41 |
| * ajmitch has an older tzdata, but its postinst doesn't reference tzconfig | 03:41 | |
| Hobbsee | RAOF: nope | 03:41 |
| RAOF | Hobbsee: Ak. So either it's a config issue, or I've upgraded at an inopportune time. | 03:41 |
| Hobbsee | RAOF: or i just havent seen the effects yet | 03:42 |
| ajmitch | you probably need to reboot for it to die | 03:42 |
| RAOF | Hobbsee: Heh, restarted recently? | 03:42 |
| ajmitch | or RAOF has half-upgraded stuff | 03:42 |
| Hobbsee | RAOF: define recently | 03:42 |
| RAOF | Today? | 03:42 |
| RAOF | After your last update? | 03:43 |
| Hobbsee | not yet | 03:43 |
| Hobbsee | i did alst night | 03:43 |
| RAOF | Eh. It'll either fix itself after a while or I'll file a bug. | 03:44 |
| RAOF | Either way, gutsy still works :) | 03:44 |
| pwnguin | RAOF: oh you fool. | 03:45 |
| pwnguin | you installed the policykit | 03:45 |
| RAOF | pwnguin: This is true. Or at least by "installed" you mean "had pulled in by automated updates". | 03:45 |
| pwnguin | heh | 03:45 |
| pwnguin | sucker | 03:45 |
| RAOF | That's the breaker? | 03:46 |
| pwnguin | almost certainly | 03:46 |
| pwnguin | thats been the only updates in the last few hours | 03:46 |
| pwnguin | its something thats almost guarenteed not to work out smoothly on first go, too ;) | 03:47 |
| RAOF | What? A security system accidentally forbidding access to important stuff? Surely not! | 03:47 |
| pwnguin | i think theres a rebuild in the works | 03:47 |
| pwnguin | good luck | 03:48 |
| RAOF | Eh, it'll work eventually. | 03:48 |
| RAOF | And then I can go back to nouveau. | 03:48 |
| pwnguin | i should probably push out a thinkfinger rebuild for hardy now that my laptop is running it | 03:50 |
| pwnguin | i kinda wish people could report bugs to my ppa, as i have a hard time tracking what i have and havent fixed after a few weeks | 03:51 |
| TheMuso | Well, I'll wait till I do my epic post to my blog, which is currently being reviewed by a family member./c | 03:58 |
| TheMuso | ugh wronog window. | 03:58 |
| TheMuso | and accessibility scewed up | 03:58 |
| TheMuso | screwed | 03:58 |
| StevenK | Whoda thunk it | 03:59 |
| * StevenK hides | 03:59 | |
| TheMuso | heh | 03:59 |
| TheMuso | Well, somehow I managed to up arrow to that while trying to restart the at-spi registry daemon. | 03:59 |
| ajmitch | heh | 03:59 |
| pwnguin | are there any programs besides gnome-panel that affect fullscreen apps? | 04:00 |
| pwnguin | like a dock at the bottom | 04:01 |
| spowers | you mean have netwm hints so maximized windows should avoid them? fspanel, wmaker's dock... kicker? | 04:03 |
| pwnguin | ok, GNOME apps | 04:03 |
| pwnguin | and yes, things that hint that maximized windows shouldn't overlap them | 04:04 |
| pwnguin | currently i have an upstream using always on top, i'd like to be able to point out another project that managed to get it working with metacity | 04:04 |
| pwnguin | awesome | 04:06 |
| pwnguin | https://edge.launchpad.net/~satanic/+archive | 04:06 |
| TheMuso | hmmm. I am not sure if I like the idea of the get-build-deps script using aptitude... | 04:07 |
| RAOF | pwnguin: avant-window-navigator? | 04:14 |
| pwnguin | RAOF: does that actually stop apps from maximizing under it? | 04:17 |
| RAOF | It's got an option to. | 04:17 |
| pwnguin | does it work? | 04:17 |
| RAOF | Last time I chekced, yes. | 04:17 |
| pwnguin | with metacity? | 04:18 |
| * Hobbsee wants to try that | 04:18 | |
| RAOF | Indeed. And xcompmgr | 04:18 |
| RAOF | Hobbsee: Go ahead. Now in hardy universe :) | 04:18 |
| Hobbsee | :P | 04:18 |
| Hobbsee | dont know how it works, though | 04:18 |
| pwnguin | cellwriter guy was saying metacity was kicking cellwriter out of the struts it set up | 04:18 |
| persia | Riddell: re: bug 158252: Could you suggest what additional changes should be made to "reduce to the minimal case"? Should debian/rules be adjusted to not copy the autotools hints in clean: ? Separately, is this checked for packages that copy the autotools hints in configure: ? | 04:18 |
| ubotu | Launchpad bug 158252 in dspam "dspam won't start: /var/run/dspam missing in tmpfs" [Undecided,In progress] https://launchpad.net/bugs/158252 | 04:18 |
| Hobbsee | RAOF: under what? | 04:19 |
| RAOF | Hobbsee: Under what? avant-window-navigator is the package name. | 04:19 |
| pwnguin | its not in hardy yet | 04:19 |
| Hobbsee | oh, it's in new | 04:19 |
| RAOF | Ah, of course. | 04:19 |
| RAOF | Hm. Who uploaded it, though? | 04:20 |
| persia | seb128, looks like | 04:21 |
| persia | (bug #118589) | 04:21 |
| ubotu | Launchpad bug 118589 in ubuntu "[needs-packaging] Avant Window Navigator" [Wishlist,Fix committed] https://launchpad.net/bugs/118589 | 04:21 |
| Fujitsu | Ooh, shiny! | 04:22 |
| jdong | ooh shiny indeed :) | 04:22 |
| RAOF | Ah. seb128 was using lp & didn't leave any comments on revu. | 04:23 |
| RAOF | Yay duplication! | 04:23 |
| Hobbsee | seb doesnt, no | 04:23 |
| Fujitsu | Gnah, no instant-apply, but it has buttons like it should. | 04:24 |
| bluefoxicy | this is fun | 04:32 |
| bluefoxicy | every time I start thunderbird it crashes on load message | 04:32 |
| bluefoxicy | rm compatibility.ini | 04:32 |
| bluefoxicy | apport doesn't even pick it up. | 04:32 |
| Hobbsee | it must just hate you' | 04:34 |
| * TheMuso seriously considers going offline. That CG lightning bolt was close. | 04:36 | |
| ScottK | bluefoxicy: You are being told to use a real mail client. | 04:36 |
| StevenK | TheMuso: CG? | 04:36 |
| TheMuso | StevenK: Cloud to ground. | 04:36 |
| RAOF | TheMuso: OOoooh. There's actual rain happening somewhere? Yay! | 04:36 |
| TheMuso | RAOF: Yep, its absolutely pooring down here. | 04:37 |
| RAOF | Yay! My brother's up, maybe we can throw a huge electrical storm for him. | 04:37 |
| bluefoxicy | ScottK: I used evolution for a while. I couldn't handle EDS constantly pushing its working set to 850MB while evolution ran its own 600MB for a 200 message mailbox open for an hour. | 04:37 |
| TheMuso | If it makes it to Sydney, I guess you could. | 04:37 |
| RAOF | TheMuso: Can you blow *really hard* in my direction? :) | 04:37 |
| ScottK | bluefoxicy: I'm a Kmail fan myself. | 04:38 |
| bluefoxicy | I try to keep Qt stuff off my system | 04:38 |
| TheMuso | F***K that was close. | 04:38 |
| TheMuso | I'm outa here. | 04:38 |
| ScottK | bluefoxicy: I work at the same thing with GTK. | 04:39 |
| === tritium_ is now known as tritium | ||
| nixternal | which one of you decided to break libgpg-error? | 04:50 |
| nixternal | StevenK: ?? was it you? :) | 04:50 |
| nixternal | Riddell: or was it you? :) | 04:50 |
| StevenK | Broke how? | 04:51 |
| nixternal | in batteling to fix the .la issue, you broke the .so :) | 04:51 |
| nixternal | StevenK: there is no .so files anymore and it is breaking my kde4 builds | 04:51 |
| nixternal | s/is/are/ | 04:51 |
| StevenK | Yes there are, they are under /lib | 04:51 |
| StevenK | It is not my fault libtool is FITH | 04:51 |
| nixternal | hehe | 04:51 |
| nixternal | libtool suxorz | 04:52 |
| nixternal | make[2]: Entering directory `/home/kde-devel/kde/build/KDE/kdepimlibs' | 04:52 |
| nixternal | make[2]: *** No rule to make target `/usr/lib/libgpg-error.so', needed by `lib/libgpgme++-pth.so.1.0.0'. Stop. | 04:52 |
| nixternal | that would explain that then | 04:52 |
| * nixternal wonders why it is looking under /usr/lib all of a sudden | 04:52 | |
| StevenK | libgpgme++ is probably broken, then | 04:52 |
| * nixternal is looking at it right now as a matter of fact | 04:54 | |
| Ubulette | nixternal, I've proposed a patch for that, i've been ignored :( | 05:00 |
| LaserJock | phew, almost got gcompris done | 05:00 |
| * LaserJock had the bright idea of creating a Main-only hardy pbuilder | 05:01 | |
| StevenK | LaserJock: Ponies! | 05:01 |
| nixternal | Ubulette: what is that? | 05:01 |
| nixternal | this is freakin' annoying | 05:01 |
| Hobbsee | Ubulette: did you subscribe the sponroship team? | 05:01 |
| LaserJock | StevenK: yeah, yeah, getting there | 05:01 |
| * Hobbsee ponders banning LaserJock from all ubuntu channels, until he produces poniez. | 05:01 | |
| Ubulette | i've posted my patch in the bug that did the /usr/lib -> /lib migration | 05:01 |
| StevenK | Haha | 05:01 |
| nixternal | there is no libgpgme++-pth anywhere on thsi system | 05:02 |
| jdong | Hobbsee: quick make him flood in and out a few times :D | 05:02 |
| persia | Ubulette: Which bug #? | 05:02 |
| Hobbsee | Ubulette: doesn't answer the question | 05:02 |
| Ubulette | bug 139635 | 05:03 |
| ubotu | Launchpad bug 139635 in libgpg-error "[cryptsetup] library dependency in /sbin/cryptsetup" [Undecided,In progress] https://launchpad.net/bugs/139635 | 05:03 |
| Ubulette | patches are in comments 30 and 31 | 05:04 |
| Ubulette | tested locally, and in my ppa | 05:04 |
| Ubulette | i'm using those debs since | 05:05 |
| persia | Ubulette: Looking at the bug log, it appears indeed that these patches were not submitted to sponsors for upload. You might want to review https://wiki.ubuntu.com/SponsorshipProcess | 05:08 |
| Ubulette | persia, i'm used to post patches everywhere using the respective native bug system. it works well, except here | 05:13 |
| persia | Ubulette: Ubuntu's processes are a bit different than other places. There is a search for finding proposed patches, but bugs with the patch tag are higher priority, and bugs for which someone actively requests sponsorship are higher priority still. | 05:14 |
| Fujitsu | Ubulette: We have almost 40000 bugs. We don't poll them all regularly for patches. | 05:14 |
| StevenK | 10,000 source packages, 40,000 bugs and roughly 40 people. | 05:15 |
| jdong | meh that's just 1000 per person :) | 05:15 |
| * persia feels inadequate, being only subscribed to 1/4 of quota | 05:15 | |
| StevenK | Hah | 05:15 |
| jdong | and if we store the database on reiserfs, only like 10 per person | 05:15 |
| bddebian | heh | 05:16 |
| Fujitsu | jdong: ... why? | 05:16 |
| jdong | :D | 05:16 |
| Fujitsu | Had bad experiences with it, have we? | 05:16 |
| jdong | Fujitsu: nah, just like to spread the popular joke sarcastically :) | 05:16 |
| jdong | Fujitsu: my experiences with the reliability of reiserfs have been generally positive | 05:16 |
| Fujitsu | I have similar experiences. | 05:17 |
| LaserJock | man, that reminds me | 05:17 |
| StevenK | If you want to be shown reiser sucks: | 05:17 |
| LaserJock | I get the San Fran. area news | 05:17 |
| Fujitsu | LaserJock: About ponies? | 05:17 |
| LaserJock | and they have updates on Reiser's case | 05:17 |
| Fujitsu | Aha. | 05:17 |
| Fujitsu | I haven't see an update on that in quite a while. | 05:17 |
| LaserJock | he's made himself co-counsel this last week | 05:17 |
| LaserJock | his kid was on the stand | 05:17 |
| LaserJock | real sad | 05:18 |
| StevenK | Create 10-12 reiserfs images on a reiser filesystem, and then run fsck over it. The reiser fsck trawls the entire filesystem looking for things that look like b-trees, and stitches them all together ... | 05:18 |
| Fujitsu | Hahaha, yes. | 05:18 |
| RAOF | Whoops. | 05:18 |
| Fujitsu | reiserfsck is known to be armed and dangerous. | 05:18 |
| Fujitsu | Sometimes I really question aptitude's dependency resolution algorithm. | 05:19 |
| StevenK | Fujitsu: Oh? | 05:19 |
| jdong | Fujitsu: agreed | 05:19 |
| Fujitsu | Why, when I try to remove beagle, does it want to take ekiga, gnome-terminal, nautilus, rhythmbox, ubuntu-desktop, etc. with it? | 05:19 |
| StevenK | Fujitsu: It doesn't trawl the filesystem looking for things that look like b-trees, right? :-) | 05:19 |
| jdong | on reiserfsck that is | 05:19 |
| persia | Fujitsu: Are you removing libbeagle0? | 05:20 |
| jdong | reiserfsck is delaying mkfs.reiserfs. | 05:20 |
| Fujitsu | persia: That is one of the things, yes. | 05:20 |
| Fujitsu | Is there some evil panel applet that wants it? | 05:20 |
| StevenK | Actually, if you screw up the b-tree bad enough, reiserfsck == mkfs.reiserfs. | 05:20 |
| persia | Fujitsu: Some of those binaries are compiled against the library, to provide support if beagled is available, and would break if it were removed. | 05:20 |
| Fujitsu | Ahh. | 05:20 |
| jdong | Fujitsu: nautilus apparently wants it | 05:20 |
| Fujitsu | Thanks persia, didn't think it'd be that. | 05:20 |
| Fujitsu | StevenK: Hahah. | 05:20 |
| jdong | StevenK: yeah, though that shouldn't be a part of normal operation per se | 05:21 |
| persia | Fujitsu: When aptitude whines, check build-depends :) | 05:21 |
| jdong | StevenK: I've never seen reiserfs corrupt itself without hardware issues to blame too | 05:21 |
| * Fujitsu has never had to reiserfsck, fortunately. | 05:21 | |
| jdong | StevenK: but if that ever happens, you are absolutely on your own :D | 05:21 |
| Fujitsu | And I used to have a lot of filesystems running it. | 05:21 |
| StevenK | I've never run reiserfs. I don't plan on. | 05:21 |
| jdong | StevenK: a more concerning problem is that currently AFAIK there is *one* kernel developer that shows interested in bug-fixing reiserfs | 05:21 |
| jdong | the other one apparently quit | 05:21 |
| StevenK | Hah, does that mean Namesys is still paying people? | 05:22 |
| jdong | StevenK: no, the one guy is a SUSE dev, novell's paying him | 05:22 |
| StevenK | Ah | 05:22 |
| jdong | presumably because they still have supported releases that default to Reiser | 05:22 |
| StevenK | Oh that's right, I forgot SuSE did that stupidity | 05:22 |
| StevenK | I am quite happy with ext3. | 05:23 |
| jdong | StevenK: at the time I guess it made sense. reiserfs was the first Linux journaling FS and performed way faster than ext2 even | 05:23 |
| StevenK | XFS if I want a filesystem that can resize online | 05:23 |
| jdong | StevenK: since then ext3 has made improvements and proven itself to have a nice upgrade path | 05:23 |
| Fujitsu | StevenK: You can't resize ext3 online? | 05:23 |
| jdong | StevenK: and ext3 can be resized online too :) | 05:23 |
| LaserJock | anybody know if dh_python will cause problems for a package that has a pycompat? | 05:23 |
| Fujitsu | LaserJock: Why are you using either of them? | 05:24 |
| Fujitsu | They're both deprecated. | 05:24 |
| StevenK | Fujitsu: Not without kernel patches when the machine in question was installed | 05:24 |
| jdong | StevenK: need to reserve some resize_inodes (manpage) | 05:24 |
| persia | LaserJock: isn't dh_python deprecated? | 05:24 |
| LaserJock | Fujitsu: *I'm* not, debian is | 05:24 |
| Fujitsu | StevenK: Ah, Dapper? | 05:24 |
| StevenK | Fujitsu: Right | 05:24 |
| Fujitsu | LaserJock: Tell Debian that they're wrong. | 05:24 |
| LaserJock | persia: yes | 05:24 |
| persia | LaserJock: Update to the New Python Packaging Policy :) | 05:24 |
| LaserJock | I'm just trying to figure out if it's gonna actually cause problem | 05:24 |
| StevenK | Fujitsu: The machine was dragged into service at about Edgy's release, running Dapper | 05:24 |
| Fujitsu | Which is decidedly unnew. | 05:24 |
| Fujitsu | StevenK: Aha. | 05:24 |
| StevenK | Fujitsu: So I think the choice of XFS is justified. :-) | 05:25 |
| Fujitsu | StevenK: Certainly. | 05:25 |
| persia | Fujitsu: Well, that's the problem with relative adjectives in nomenclature. Look at the modernist movement for another example of people with good ideas and poor names :) | 05:25 |
| Ubulette | nixternal: you're on your own then. feel free to fix the mess. | 05:25 |
| nixternal | Ubulette: ln -s :) for the time being at least | 05:26 |
| RAOF | LaserJock: Are they using one of dh_py{central,support} as well as dh_python, or just dh_python? | 05:26 |
| jdong | StevenK: IMO there's still a purpose that justifies every FS. I still use a reiserfs loopback for my pbuilder build dir | 05:26 |
| LaserJock | RAOF: looks like just dh_python, one sec | 05:26 |
| Fujitsu | ... now that beagle is gone, tracker of course takes over the CPU and disk. | 05:26 |
| StevenK | jdong: Ew | 05:26 |
| Ubulette | nixternal, lol, locally, that's enough for sure ;) | 05:27 |
| persia | Fujitsu: Again, you can't purge the libraries, but you can remove the daemon & agent. | 05:27 |
| nixternal | it built my kde4 pimlibs, that's all that makes me happy right now | 05:27 |
| jdong | StevenK: why ew? reiserfs can nuke a build environment in 1.5 seconds. How long does it take for ext3 to clean up a builder? :) | 05:27 |
| Fujitsu | persia: Right. | 05:27 |
| LaserJock | just dh_python | 05:27 |
| persia | jdong: Try LVM snapshots: no cleanup time | 05:27 |
| jdong | persia: I'll have to invest the effort to set up LVM though, but that's on the list for my next reformat | 05:28 |
| * Fujitsu is in fact moving a machine over to LVM right now, for sbuild. | 05:28 | |
| StevenK | Mmmm, sbuild | 05:29 |
| * StevenK hugs his schroot/sbuild setup | 05:29 | |
| nixternal | my lazy arse still hasn't completed my sbuild box | 05:29 |
| LaserJock | ugg | 05:29 |
| LaserJock | gimmie pbuilder/dchroot any day ;-) | 05:30 |
| nixternal | gimme conary/rmake any day ;) | 05:30 |
| LaserJock | pfft | 05:30 |
| persia | My only complaint with sbuild / LVM is that the source image must be the same size as the target image. I'd really like to have a heap of 2GB source images, and 10GB (or so) targets to handle larger package builds. | 05:30 |
| LaserJock | nixternal: that stuff is cheating | 05:30 |
| LaserJock | ;-) | 05:30 |
| nixternal | hehe | 05:30 |
| Fujitsu | persia: You could do that fairly easily. | 05:30 |
| nixternal | but man is it easy | 05:30 |
| persia | LaserJock: dchroot is only a wrapper for schroot now. | 05:30 |
| jdong | emerge -uDav world!! | 05:31 |
| LaserJock | persia: I know :( | 05:31 |
| Fujitsu | Hm, maybe not, I forget how snapshots work... | 05:31 |
| LaserJock | persia: which caused my quite a bit of consternation when that happened | 05:31 |
| persia | Fujitsu: Really? Do I need to do something to grow the filesystem when I make a snapshot? | 05:31 |
| persia | LaserJock: Why? I've not yet found something dchroot could do that schroot didn't also handle. I'd be interested in the counterexample. | 05:32 |
| Fujitsu | persia: You could easily add a hook to resize2fs, but changing the size of the length of the snapshot might not be possible... | 05:32 |
| * Fujitsu looks. | 05:32 | |
| * persia finds resize2fs not lightning fast | 05:32 | |
| LaserJock | persia: it took me a while to figure out schroot.conf. dchroot was brain-dead easy | 05:32 |
| jdong | Fujitsu: some combination with unionfs could prove interesting. | 05:32 |
| jdong | </crack> | 05:32 |
| LaserJock | persia: but now that I've got the hang of it it *is* nicer | 05:33 |
| LaserJock | *is | 05:33 |
| persia | LaserJock: Ah. Config skew. I see. Wasn't there a compatibility layer, or was that broken? (I migrated use prior to the official migration). | 05:33 |
| mebrown | as the maintainer of 'mock' in fedora, I have been greatly puzzled by the debian chroot build stuff... | 05:33 |
| StevenK | mebrown: Why? We like to be sure our packages can build on a base system with only what we specify it needs. | 05:34 |
| StevenK | mebrown: Also it means you don't need to be running the release you're building for. | 05:34 |
| mebrown | yes, but when I was trying to use it, it required a lot of setup. | 05:34 |
| mebrown | mock basically does all that for you out of the box with zero setup. | 05:35 |
| StevenK | mebrown: A lot of setup is running pbuilder create and waiting ten minutes? | 05:35 |
| mebrown | dedicating LVM partitions to do builds sounds crazy | 05:35 |
| persia | mebrown: From a very quick look, I'd say that it's just different tools. mock seems to map to pbuilder / sbuild / etc. The various means of implementing the underlying chroots can be adapted to any chroot/build manager. | 05:35 |
| persia | mebrown: Not large partitions, but it's a lot faster to snap a known good clean environment than reliably populate a new one. | 05:36 |
| mebrown | So, when I have a source package in rpm, if I want to rebuild the package with mock, one command: "mock -r TARGET_DISTRO rebuild name_of.src.rpm" | 05:36 |
| Fujitsu | mebrown: sbuild -d hardy something.dsc | 05:36 |
| mebrown | and I can rebuild in a chroot for any target distro. | 05:36 |
| persia | mebrown: Sure, I use sbuild -A -d TARGET_DISTRO package.dsc | 05:37 |
| mebrown | sbuild sets up a chroot? | 05:37 |
| persia | mebrown: sbuild has a hook mechanism to a variety of chroot builders. | 05:37 |
| mebrown | do I have to do any setup, or does that work out of the box? | 05:37 |
| persia | I have it using schroot with LVM snapshots to get a clean one, but one could also untar tarballs, or just create a new one, if one wished. | 05:37 |
| Fujitsu | sbuild requires a little more setup than alternate, slightly slower, solutions such as pbuilder. | 05:38 |
| persia | mebrown: If you have a working chroot, it works out of the box. | 05:38 |
| mebrown | persia, the "if you have a working..." part is the hard part, then. | 05:38 |
| persia | Fujitsu: Well, sbuild / schroot / LVM requires a little setup. sbuild on it's own also works. | 05:38 |
| Fujitsu | persia: True. | 05:39 |
| jdong | meh IMO nothing beats pbuilder with ease of setup | 05:39 |
| jdong | but sbuild doesn't look terribly unreasonable either | 05:39 |
| LaserJock | how do you move into a dir in debian/rules? | 05:39 |
| minghua | LaserJock: cd? | 05:39 |
| persia | mebrown: There are sensible defaults. My memory is that the current sbuild default is to use schroot, and that the current schroot default is to create a chroot in tmpfs. | 05:39 |
| mebrown | mock will automatically cache just about everything and internally manages it all. So if you do a clean build for a distro you have never built, it will take a while to pull down the chroot packages and whatnot. | 05:39 |
| LaserJock | is it ${cd; blah blah} | 05:40 |
| RAOF | LaserJock: cd, and then make sere that you don't linebreak :) | 05:40 |
| mebrown | but after that, it caches everything (basically creates a root tarball that it uses as a cache), and keeps everything up-to-date with zero user configuration. | 05:40 |
| persia | mebrown: OK. Different question: why isn't mock in Ubuntu :) | 05:40 |
| RAOF | <tab>cd $FOO ; bar1 ; bar2 ; etc... | 05:40 |
| minghua | LaserJock: I know "(cd foo; bar)" works. I don't know if it's the best way to do it. | 05:40 |
| mebrown | what i am trying to find out is if there is something like that already for ubuntu that I am missing... | 05:40 |
| LaserJock | minghua: ah, that's the one | 05:41 |
| Fujitsu | It would be very simple to create a pbuilder wrapper to do that, I think. | 05:41 |
| Fujitsu | Or sbuild. | 05:41 |
| persia | mebrown: Most of the tools have sensible defaults, but I don't think anyone's gone so far as to write the pbuilder hook to download trusted known-good build chroots. | 05:41 |
| mebrown | would actually be willing to abstract mock enough to use with ubuntu. But seems like you already have a plethora of tools... | 05:41 |
| persia | Fujitsu: sbuild might be a little harder, as it would need schroot to be able to autodefine a source, which needs yet more hooks. | 05:42 |
| minghua | mebrown: Does mock builds a minimal environment of the other distro? | 05:42 |
| mebrown | ah. so mock comes out of the box with preconfigured configs to build all supported distros. You dont need to configure anything and it creates the chroot on the fly. | 05:42 |
| persia | mebrown: Actually, we like having lots of tools. This way we can more easily expose bugs in one or another of them. | 05:42 |
| Fujitsu | persia: mk-sbuild-lv makes that fairly simple. | 05:42 |
| mebrown | but, it makes it *much* more difficult for a new person to get up to speed... | 05:43 |
| persia | Fujitsu: If you use LVM, and have available space in the VG, yes. | 05:43 |
| === greeneggsnospam is now known as jsgotangco | ||
| === zakame_ is now known as zakame | ||
| mebrown | I am considered fairly proficient in fedora, but trying to port some packages to ubuntu and it just feels harder. | 05:43 |
| persia | mebrown: A lot of that difficulty is documentation, rather than actual uset effort. | 05:43 |
| jdong | mebrown: probably because you are familiar with the fedora setup more :) | 05:43 |
| jdong | mebrown: I feel similar inadequate doing RPM packaging | 05:43 |
| jdong | similarly* | 05:44 |
| mebrown | true enough, and I am not trying to hide that fact... | 05:44 |
| jdong | mebrown: nothing to hide, something to be proud of :) | 05:44 |
| jdong | at the end of the day, we're all on the same team :) | 05:44 |
| mebrown | So: so far I have heard 'sbuild' 'pbuilder' and maybe another or so... | 05:44 |
| mebrown | where are the docs for each? | 05:44 |
| persia | !pbuilder | 05:45 |
| ubotu | pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto | 05:45 |
| persia | !sbuild | 05:45 |
| ubotu | Sorry, I don't know anything about sbuild - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 05:45 |
| persia | Grrr.. You should! | 05:45 |
| jdong | persia: we should add that factoid if there's a wiki page associated | 05:45 |
| persia | ubotu: sbuild is https://help.ubuntu.com/community/SbuildLVMHowto | 05:45 |
| StevenK | persia: I think you need someone like Hobbsee to say that | 05:45 |
| jdong | StevenK: meh they get it in -ops | 05:46 |
| persia | ubotu: sbuild is a system to easily build packages in a clean schroot environment. To get started with SBuild, see https://help.ubuntu.com/community/SbuildLVMHowto | 05:46 |
| mebrown | So: what would be nice would be a nice interface to all this that is one command to rebuild a source package... | 05:46 |
| persia | StevenK: If I don't have permission, it goes into the moderation queue. | 05:46 |
| StevenK | persia: Ah | 05:46 |
| mebrown | without having to preconfigure *anything* | 05:46 |
| persia | mebrown: We don't want to have one command to do it, we'd welcome more. | 05:46 |
| mebrown | ok. For fedora/redhat/etc, mock is that. | 05:47 |
| jdong | persia: it would be nice, as I think mebrown is suggesting, for sbuild/pbuilder to work almost entirely out of the box | 05:47 |
| StevenK | Which is difficult | 05:47 |
| mebrown | and it is roughly 1200 lines of python code. | 05:47 |
| minghua | mebrown: Two commands isn't really that much more. | 05:47 |
| jdong | but yeah, pbuilder is already trivial to set up | 05:47 |
| jdong | it's a single create command | 05:47 |
| ScottK | jdong: I think that's the goal of pbuilder-dist in ubuntu-dev-tools | 05:48 |
| jdong | ScottK: awesome | 05:48 |
| ScottK | It pretty much does. | 05:48 |
| jdong | ScottK: I might have to retire prevu when that happens, and just contribute a mangle-backport-version type tool | 05:48 |
| persia | mebrown: So, such a one-stop solution would cache known good systems, or generate them with debootstrap when requested, and then run through the debian build process by calling debian/rules targets. | 05:48 |
| minghua | And I assume Debian/Ubuntu people prefer the two command process because using chroots is faster. | 05:48 |
| persia | minghua: mock uses chroots | 05:48 |
| mebrown | mock automatically caches the results and internally manages it. | 05:49 |
| minghua | s/chroots/old chroots/ | 05:49 |
| mebrown | s/results/chroots/ | 05:49 |
| persia | minghua: mock even uses old chroots, if they are up to date | 05:49 |
| minghua | Okay. I agree mock is better. But I feel pbuilder is simple enough. | 05:49 |
| * persia isn't sure mock is better, only that it looks good | 05:50 | |
| mebrown | so two commands. Is this right? | 05:50 |
| mebrown | sudoe pbuilder create | 05:50 |
| mebrown | sudo pbuilder build pkg.dsc | 05:50 |
| persia | mebrown: Currently, we have one setup command, and one build command. | 05:50 |
| LaserJock | !packagingguide | 05:50 |
| ubotu | packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports | 05:50 |
| LaserJock | woot | 05:50 |
| persia | There are different options for each, depending on the selected backends | 05:50 |
| mebrown | how do you build against different distros? | 05:50 |
| LaserJock | my bot foo is still good | 05:51 |
| * TheMuso returns. | 05:51 | |
| TheMuso | That was an awesome storm. | 05:51 |
| LaserJock | !sbuild | 05:51 |
| ubotu | Sorry, I don't know anything about sbuild - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 05:51 |
| RAOF | TheMuso: Please send it this way, then ;) | 05:51 |
| persia | mebrown: You select different target chroots. The systems only currently work for Debian-style chroots: I don't think we can generate an RPM without alien. | 05:51 |
| mebrown | I have a build system set up for mock where it automatically builds me rhel4, rhel5, fedora 7, fedora 8, fedora-devel, and suse packages all for i386 and x86_64. | 05:51 |
| mebrown | I am trying to set up similar for debian. | 05:51 |
| TheMuso | RAOF: I think there is enough in it for it to get to Sydney. | 05:51 |
| * RAOF is certain TheMuso has a weather-control system *somewhere* | 05:51 | |
| TheMuso | If it doesn't go north first. | 05:52 |
| mebrown | persia, not trying to do rpm. | 05:52 |
| mebrown | just trying to build debs. | 05:52 |
| Hobbsee | !sbuild is https://help.ubuntu.com/community/SbuildLVMHowto | 05:52 |
| ubotu | But sbuild already means something else! | 05:52 |
| persia | mebrown: If you're just targeting dsc -> deb, then it's just a matter of selecting the right chroot. | 05:52 |
| mebrown | but I need to do it for ubuntu sid i386/x86_64, feisty i386/x86_64, gutsy ..., hardy... | 05:52 |
| persia | Hobbsee: Please see the second suggestion in queue, as it's more verbose, and better :) | 05:52 |
| LaserJock | persia: try !sbuild now | 05:53 |
| persia | mebrown: Different chroots | 05:53 |
| Hobbsee | fixed. | 05:53 |
| * persia cheers Hobbsee's magic bot wranging powers | 05:53 | |
| persia | err wrangling | 05:53 |
| LaserJock | I beat Hobbsee to it | 05:53 |
| LaserJock | :p | 05:53 |
| minghua | mebrown: I *think* "sudo pbuilder --create --debootstrapopts --variant=buildd" is probably more correct. | 05:54 |
| persia | mebrown: More verbosely, when I build for Debian, I currently use `sbuild -A -d sid foo.dsc` or `sbuild -A -d etch foo.dsc`, and when I build for Ubuntu I use `sbuild -A -d gutsy foo.dsc` or `sbuild -A -d hardy foo.dsc`. | 05:54 |
| persia | LaserJock: In that case, you get a golden whip: now please find matching ponies :) | 05:55 |
| mebrown | persia, would that work out of the box on a clean ubuntu install, or do I need to configure stuff first? | 05:55 |
| persia | mebrown: You'd need chroots for the different targets. As Fujitsu mentioned before, if you're using sbuild on LVM, the mk-sbuild-lv.sh script does that fairly easily. As minghua mentioned, if you're using pbuilder on tmpfs, the pbuilder-create script does that fairly easily. | 05:56 |
| Fujitsu | Can anybody make sense of the last comment on bug #162396 | 05:56 |
| ubotu | Launchpad bug 162396 in compiz-fusion-plugins-main "Mouse jumps to other screen when using "enhanced zoom desktop"" [Undecided,New] https://launchpad.net/bugs/162396 | 05:56 |
| Fujitsu | Erm, not that. | 05:56 |
| Fujitsu | Bug #162296 | 05:56 |
| ubotu | Launchpad bug 162296 in ircii-pana "CVE-2007-4584 stack based buffer overflow via long MODE command" [Medium,Confirmed] https://launchpad.net/bugs/162296 | 05:56 |
| ScottK | mebrown: If you look at the pbuilder-dist script that I mentioned earlier (in ubuntu-dev-tools) you name it based on what distro you want it to make. | 05:57 |
| jdong | Fujitsu: totally unrelated to bug report | 05:57 |
| persia | mebrown: If you want to have mock handle the chroots differently, you may want to initially create them with debootstrap on demand, and manage them internally. debootstrap should have support for most Debian/Ubuntu releases by default. | 05:57 |
| Fujitsu | jdong: That's what I thought. | 05:57 |
| jdong | Fujitsu: shows basic understanding of buffer overflow though <g> | 05:58 |
| mebrown | persia, I'm not really trying to modify mock to handle deb stuff. I'm just trying to take what I already know about mock and map it to ubuntu concepts. | 05:58 |
| mebrown | and since I happen to be the current maintainer/upstream for mock, I know it pretty well... | 05:58 |
| * minghua should port ubuntu-dev-tools to Debian... | 05:59 | |
| mebrown | What I like about mock is that, on a completely clean system, 1) install mock, 2) run "mock rebuild package.src.rpm" will rebuild a package. Zero setup or overhead. | 05:59 |
| jdong | mebrown: sounds to me like on a basic level, mock == pbuilder + running pbuilder create on pbuilder build when build environment does not exist yet | 05:59 |
| mebrown | jdong, basically, it sounds like that, yes. | 05:59 |
| jdong | mebrown: I don't think that's too hard to even hackishly script in 10 lines of Python to emulate the identical behavior | 06:00 |
| persia | mebrown: OK. At a base level, each chroot is built from a given release, and so has base software & /etc/apt/sources.list for that release. The build system goes into a chroot, installs the build dependencies, and builds the package by calling debian/rules targets. Everything else is just various wrappers to this, with various different choices. | 06:00 |
| jdong | mebrown: I write prevu, a backporting tool that uses pbuidler in the background and workflow is as easy as (1) install (2) sudo prevu-init (3) prevu <sourcepkg> | 06:00 |
| mebrown | persia, mock works almost exactly the same way, it just doesnt make user have to manage chroots manually. | 06:00 |
| jdong | mebrown: and prevu is nothing more than a bit of scripting on top of pbuilder.... | 06:01 |
| minghua | Honestly I don't see the need of a tool like mock in Debian/Ubuntu. It's just not a common user case. | 06:01 |
| jdong | mebrown: in all honesty creating a pbuilder requires copying 1 line of code from a wiki page, and I think that's a reasonable expectation from someone wanting to build source packages | 06:01 |
| mebrown | minghua, like I said, I'm not trying to port mock to ubuntu, I'm trying to get up to speed... | 06:01 |
| persia | mebrown: Right, which is why I think it's good. If mock is ported to Ubuntu, I'd suggest using as much of mock as possible: the things to change would be to use debootstrap to generate the chroots if they don't previously exist, and call the right targets. | 06:01 |
| * persia has been discussing the wrong goal, and ceases | 06:02 | |
| minghua | mebrown: I understand. I am just trying to say Ubuntu probably doesn't have such a tool and doesn't need one. | 06:02 |
| mebrown | persia, I have a workflow for creating my rpms, and am trying to understand how best to map that workflow to building debs. | 06:03 |
| * mebrown copies scrollback text for further review... | 06:03 | |
| persia | mebrown: In that case, the big difference is that the user needs to manage the chroots manually. Beyond that, there are two primary schools: pbuilder and sbuild. Both are good. | 06:03 |
| jdong | mebrown: apart from running a pbuilder create command, the only thing, pbuilder's build command should do exactly what mock has been doing for you :) | 06:04 |
| mebrown | where I was getting hung up is managing base.tar.gz files... | 06:05 |
| mebrown | seems like I shouldn't have to do that by hand. | 06:05 |
| Fujitsu | mebrown: What management? | 06:05 |
| mebrown | creating them, for one thing. | 06:05 |
| jdong | mebrown: base.tgz is created by a pbuilder create command, a one time ordeal | 06:05 |
| mebrown | what if you are building against a development distro that is changing? | 06:06 |
| mebrown | do you have to recreate base.tgz every day/week/month? | 06:06 |
| LaserJock | you update the chroot | 06:06 |
| jdong | mebrown: periodically run the pbuilder update command | 06:06 |
| mebrown | I am capable of dealing with this. | 06:07 |
| LaserJock | so pbuilder build to create it initially, and then pbuilder update periodically to keep it updated | 06:07 |
| jdong | s/build/create | 06:07 |
| persia | mebrown: The base install also only contains a small number of packages, so if they are out of date, it's not such a big issue: updated libraries are typically pulled from the archives. | 06:07 |
| Fujitsu | Updating it on each builds seems like overkill. | 06:07 |
| mebrown | I would like to just point out that having a nice silly wrapper that hides all that would be nice. This is what mock does for the rpm world. | 06:07 |
| LaserJock | jdong: darn, yeah | 06:07 |
| * TheMuso updates his sbuild chroots daily. | 06:08 | |
| persia | TheMuso: with cron, or manually? | 06:08 |
| TheMuso | persia: Manually. | 06:08 |
| mebrown | ouch. | 06:08 |
| TheMuso | persia: The boxes I have sbuild on are usually shut down of a night. | 06:08 |
| LaserJock | I do it before I build | 06:08 |
| persia | I keep being tempted by cron, but never quite dare. I'm hoping someone else will try it first, and report success. | 06:08 |
| LaserJock | I don't build all that often | 06:08 |
| persia | LaserJock: every time? | 06:08 |
| mebrown | wouldnt it be possible to add some extra intelligence to pbuilder to automatically create the chroot if it doesnt exist, and keep it updated if it does? | 06:09 |
| TheMuso | persia: I have a script that updates all my chroots in one single run. | 06:09 |
| LaserJock | persia: well, once before I start a packaging project | 06:09 |
| jdong | mebrown: considering the amount of work that goes into testing, verifying, editing, and other maintenance that goes into my everyday work, I don't think managing pbuilder is anywhat significant overhead time | 06:09 |
| LaserJock | persia: I don't usually do more than one package / day | 06:09 |
| * mebrown shuts up for a while and reads docs. | 06:09 | |
| TheMuso | And, that adds time to getting a package built. | 06:09 |
| persia | mebrown: Sure, but each chroot requires a tarball: this may not be interesting for people who have limited disk space: an optional hook might be nice though. | 06:09 |
| jdong | mebrown: but if you want to, while learning pbuidler yourself, script it in a fashion more automagic, you are of course welcome :) | 06:09 |
| minghua | mebrown: The "keep it updated if it exists" part is quite unfriendly to off-line work. | 06:10 |
| mebrown | thank you, everybody... | 06:10 |
| mebrown | jdong, yeah, I've heard that before... | 06:10 |
| mebrown | that is how I wound up owning mock in the first place... | 06:10 |
| LaserJock | hehe | 06:10 |
| jdong | :) | 06:10 |
| jdong | it's the global language of FOSS | 06:10 |
| persia | LaserJock: Ah. If your build frequency is less than once a day, I suppose before every build makes sense. | 06:10 |
| jdong | LaserJock: these octahedral coordination complex thingies hurt! | 06:11 |
| persia | minghua: for offline, don't you need a local mirror anyway? In that case, wouldn't it just update off the local mirror? | 06:11 |
| mebrown | minghua, actually it is funny because I've never had anybody ask to make mock work off-line. | 06:11 |
| LaserJock | persia: yeah :( | 06:12 |
| mebrown | it wouldnt work offline very well, anyways, because it has to pull build deps into the chroot after untarring the root. | 06:12 |
| jdong | mebrown: lucky :) I've had someone ask me to make prevu work behind proxies in the first few weeks of public release :D | 06:12 |
| minghua | persia: Not really. My apt cache is usually good enough. | 06:12 |
| mebrown | jdong, mock works perfectly well behind a proxy... | 06:12 |
| LaserJock | mebrown: we have apt caches so if you've built the package before you can do it without net connection | 06:12 |
| persia | minghua: Ah. Right. "Maintainer" model vs "Sponsor" model. My apt-cache is useless most of the time. | 06:12 |
| minghua | mebrown: Maybe mock's user cases are different. But I use pbuilder off-line quite often. | 06:13 |
| mebrown | LaserJock, I actually just added a 'yum cache' to mock for the last release. You still need a small net connection to do the equivalent of 'apt-get update', though. | 06:13 |
| minghua | persia: Yeah. And the "package has a maintainer" vs. "a MOTU can touch all universe packages" model. :-) | 06:13 |
| LaserJock | mebrown: if you're chroot is updated it's no problem | 06:14 |
| mebrown | minghua, I use mock off-line a bit, but I just keep a mirror on my disk. | 06:14 |
| LaserJock | so you could update in the morning and work all day offline pretty much if you've got the packages in the cache | 06:14 |
| persia | minghua: That's different. There are people in Debian who sponsor all sorts of random things, and people in Ubuntu who focus on a few packages. | 06:14 |
| minghua | persia: True, but percentage wise, I believe there is a big difference. | 06:15 |
| LaserJock | so to have a "mock" mock you'd pbuilder update && pbuilder build with a builder create if it doesn't already exist? | 06:15 |
| minghua | persia: My Ubuntu apt cache is less useful than the Debian one, too. | 06:15 |
| persia | minghua: Likely true. I think the sponsor count is similar in absolute numbers, but Ubuntu doesn't have the same quantity of maintainers. | 06:15 |
| persia | LaserJock: Right, but mock as different internals | 06:15 |
| mebrown | LaserJock, pretty much. | 06:16 |
| jdong | LaserJock: pretty much | 06:16 |
| mebrown | LaserJock, basically, it comes pre-configured out of the box. One command to rebuild a package. | 06:16 |
| mebrown | LaserJock, "mock rebuild package.src.rpm" or, optionally, "mock -r DISTRO_CFG rebuild package.src.rpm" | 06:16 |
| jdong | does our default pbuidlerrc enable the universe/multiverse components? | 06:16 |
| * persia suspects it might be difficult to distinguish bugs in mock from bugs in package build processes with only mock | 06:16 | |
| minghua | persia: Yeah. I don't know how many DDs are open to any sponsored packages though. | 06:17 |
| mebrown | it automatically downloads the rpm packages to create a chroot, creates it, installs build deps and rebuilds the package. | 06:17 |
| persia | minghua: Same for Ubuntu :) | 06:17 |
| mebrown | persia, not really. | 06:17 |
| jdong | mebrown: that's (1) pbuilder create (2) pbuilder update (3) pbuilder build | 06:17 |
| jdong | mebrown: if you put the 3 in a bash script you're all set :) | 06:17 |
| persia | mebrown: With nothing to compare behaviour against? | 06:17 |
| minghua | persia: I know quite a few Debian sponsors that just quietly sponsors a few certain packages, repeatedly. | 06:17 |
| mebrown | persia, builds in mock work exactly the same as builds outside of mock... | 06:17 |
| persia | minghua: True. | 06:18 |
| persia | mebrown: Ah, so mock is just a wrapper to another build system? | 06:18 |
| mebrown | mock does the chroot setup, and then hands off to 'rpmbuild', which is the normal command to build rpms. | 06:18 |
| minghua | Debian/Ubuntu have more than one build system, though... | 06:18 |
| LaserJock | mebrown: but it's creating a new chroot each time? | 06:18 |
| Fujitsu | sbuild and pbuilder should always return the same results, as they use the same basic build system. They don't. | 06:19 |
| mebrown | LaserJock, essentially, yes. For reproducability. But, behind the scenes, it caches just about everything | 06:19 |
| * persia things lvm snapshots are faster than caches | 06:19 | |
| mebrown | LaserJock, there are three levels of caching. If you want 100%, always-reproducable builds, you turn off two of those levels, as they could "theoretically" cause build variability. But even with those two levels turned off, it is blazing fast. | 06:20 |
| mebrown | On my machine, a tiny-package build is 1min 10secs. | 06:20 |
| mebrown | with full chroot setup included in that. | 06:20 |
| mebrown | If you eliminate the root cache and ccache to ensure 100% reproducability, that jumps to 2min 30 sec. | 06:21 |
| jdong | am I imagining things, but do PPA's build faster than the hardy queue? | 06:21 |
| persia | jdong: It depends on current queue size... | 06:23 |
| StevenK | jdong: Keep in mind there are a lot less builds queued for PPAs, and 3 builders for each arch. | 06:34 |
| persia | Contributors: when sending patches for sponsorship, please ensure that you are subscribed to the bug. | 06:34 |
| jdong | StevenK: wow, looks like we got the raw end of the deal | 06:35 |
| StevenK | jdong: It was only 1 per arch before UDS. | 06:35 |
| jdong | heh | 06:35 |
| jdong | well I guess the PPA's have to deal with much more than the 50 or so of us, right? :) | 06:35 |
| TheMuso | Yeah | 06:37 |
| * TheMuso reckons they could do PPA builds for PPC if they used mol. | 06:37 | |
| LaserJock | mebrown: so it's similar to pbuilder anyway | 06:37 |
| mebrown | LaserJock, yes, exactly. Just a bit easier to get started with (imho, of course) | 06:38 |
| * mebrown is busy installing gutsy into KVM to run some tests to try to get pbuilder running. | 06:39 | |
| StevenK | TheMuso: How? MOL is Mac On Linux | 06:41 |
| === czessi_ is now known as Czessi | ||
| persia | Doesn't MOL expect a PPC anyway? | 06:43 |
| minghua | persia: I believe so. | 06:44 |
| StevenK | persia: I thought MOL was PPC-only | 06:44 |
| * StevenK needs a fast non-desktop machine that he queue builds on. | 06:45 | |
| persia | StevenK: I think one can run it on m68k as well, as I wouldn't be surprised to see it work on i386 once there's not so much reliance on Rosetta. | 06:45 |
| persia | StevenK: Get one of the little sff boxes, and tuck it somewhere. Servers are big, and not much faster. | 06:45 |
| StevenK | persia: My current desktop is sff. | 06:46 |
| persia | StevenK: Right. You said "non-desktop". I'm suggesting another one under your desk :) | 06:46 |
| StevenK | persia: 20cm x 20cm x 30cm | 06:46 |
| StevenK | persia: It involves building another machine, though. | 06:47 |
| persia | StevenK: For the non-desktop, you don't need the width: you could probably do something with a multi-core proc in 10 x 15 x 25. | 06:49 |
| StevenK | persia: The heatsink for this machine is non-stock Intel is roughly taking up 1/3 of the internal space | 06:50 |
| TheMuso | StevenK: Yes, but it can run Linux. | 06:50 |
| persia | Yep. That's the problem with modern processors :) | 06:50 |
| TheMuso | StevenK: So, a mol instance running Linux would probably be ok. | 06:51 |
| StevenK | persia: I don't see that as a problem, it means space in the machine is effiently used, even though heatsinks aren't very efficent. | 06:51 |
| persia | StevenK: Still, hard to get it down to 2 x 5 x 10 for something with sufficient power to be worth it. | 06:52 |
| StevenK | persia: Does the Q1 count? :-) | 06:54 |
| StevenK | 20 x 10 x 2 | 06:54 |
| persia | StevenK: Not really. Firstly, that's larger than I'd like, and secondly, it's not a high-throughput processor (or it could be, but the case warms significantly). The HW is optimised for bursty use. | 06:55 |
| StevenK | persia: Besides, I'd rather not drop the width, because then you lose the 5.25" drive bay | 06:56 |
| persia | I found a Core2 non ULV case at 16.5 x 16.5 x 5, but smaller is proving difficult. | 06:56 |
| StevenK | You want smaller? | 06:56 |
| persia | StevenK: The Q1 is so large that I can't see the point of carrying it: if I need to have a bag, I'd rather a decent sized screen. | 06:57 |
| persia | For a little build queue, finding something to hide on the back of the desk seems nice, but size really isn't as important. | 06:57 |
| StevenK | persia: My X40 is more than double the size | 06:57 |
| persia | StevenK: My Z3200 is half the size | 06:58 |
| StevenK | But it's ARM, isn't it? | 06:58 |
| persia | StevenK: So? | 06:58 |
| StevenK | ARM processors don't require 4 times their weight or more in cooling. | 06:59 |
| * persia thinks in terms of use cases for actual devices, rather than architecture | 06:59 | |
| StevenK | persia: Sure, my problem with modern Intel processors is a cooling one :-) | 06:59 |
| persia | Yep. The choices seem to currently be ULV or having difficulty getting beneath about 1.25 liters | 07:01 |
| StevenK | ULV processors still require (for their size, and power draw) massive amounts of cooling. | 07:02 |
| persia | If you run i386 ULV at the speeds most ARM run, you also don't need the vast cooling supply, but you can only get so much done. | 07:02 |
| StevenK | I've yet see a i386 ULV at only 200MHz :-) | 07:02 |
| StevenK | yet to see | 07:02 |
| persia | StevenK: Less cooling. I can find ULV around 7.5L, but ULV doesn't tend to do well with high continuous load. | 07:02 |
| StevenK | persia: Yup. Continuous load was not one of the primary concerns. :-) | 07:03 |
| persia | StevenK: Err. I was thinking 600-800, but I'll admit not to seeing anything until 1200 in the wild. | 07:03 |
| LucidFox | http://revu.tauware.de/details.py?package=avant-window-navigator <-- isn't this version already in the archive? https://launchpad.net/ubuntu/+source/avant-window-navigator | 07:03 |
| persia | StevenK: For a buildd? | 07:03 |
| StevenK | persia: Yeah. My ARM knowledge is a little out of date. | 07:03 |
| StevenK | persia: No, for ULV processors. | 07:03 |
| persia | People still ship 100MHz ARM, but it tends to be deep embedded, rather than for full-function devices. People still ship 100MHz ULV 486 derivatives for that matter :) | 07:04 |
| RAOF | LucidFox: Yes it is. Thanks for reminding me, seb didn't archive it when he uploaded it. | 07:04 |
| persia | StevenK: Right. ULV gets you down to about 0.75L. I'm still waiting :) | 07:04 |
| StevenK | persia: I think you might be waiting a while. :-) | 07:05 |
| persia | Err. Nevermind. You've listed 400cc above. I'm mistaken :) | 07:05 |
| StevenK | Which is 400cc? | 07:06 |
| persia | StevenK: Not too much. There's a couple pre-announcements out, and one of the new Fujitsus almost fits in my pocket. | 07:06 |
| persia | StevenK: Q1 (from your numbers above: 20x10x2 (although I thought it was closer to 20x10x2.3) | 07:06 |
| LucidFox | also, http://revu.tauware.de/details.py?package=genpo - is in the queue now: https://launchpad.net/ubuntu/hardy/+queue?start=40 | 07:06 |
| * persia archives genpo | 07:07 | |
| StevenK | persia: That was a rough meaursement with a ruler :-) | 07:07 |
| persia | StevenK: Still, it's maybe ~500cc. I apparently can't judge volumes when looking at things in the store (I usually just try to stuff them in my pocket). | 07:08 |
| StevenK | persia: Don't the store people not like that? :-) | 07:09 |
| StevenK | "Look! He's trying to fit stuff in his pocket! Get him!" | 07:10 |
| persia | StevenK: Actually, they tend to sympathise with me, and try to lead me over to the devices that do fit. pocketable is marketable here. | 07:10 |
| persia | On the other hand, I'm not looking for a fancy phone :( | 07:11 |
| persia | (or things like the N810 or EM1, which don't have keyboards or USB host) | 07:11 |
| StevenK | The N810 does have a keyboard. | 07:12 |
| * persia looks again | 07:12 | |
| persia | That's not a keyboard: that's a keypad. Worse yet, it's square, and all the keys are lined up. | 07:13 |
| persia | EM1 has the same issue (and does two-way silding, so the base can be pulled to the right for PDA-mode) | 07:13 |
| persia | EM-One pics at http://www.sharp.co.jp/corporate/news/070219-a.html | 07:14 |
| StevenK | That doesn't look too bad. | 07:15 |
| persia | Only issues I have are that I can't type at a decent speed on the keypad, and that it doesn't have either an HD or a CF slot for a microdrive. | 07:15 |
| StevenK | persia: And the N810 "keypad" isn't square | 07:16 |
| persia | StevenK: I stand corrected. My complaint is about the lack of offsets: I expect the 'I' key to be a little left of the 'K' key. | 07:19 |
| persia | (N810 isn't in the shops here, so I've never played with the actual hardware) | 07:20 |
| StevenK | persia: ... the N810 isn't in any shops at all, if I recall correctly | 07:22 |
| persia | http://www.fmworld.net/product/hard/pcpm0709/biblo_loox/lu/info/index.html#anc02 is the smallest current device I can find with proper key offsets, now that tha Zaurus is discontinued. | 07:24 |
| persia | StevenK: Where are they sold? | 07:24 |
| TheMuso | Yay. More rain here. | 07:24 |
| StevenK | persia: I don't think anywhere yet. | 07:25 |
| persia | Ah. I thought it was released. | 07:28 |
| TheMuso | Another storm... think I'm off again | 07:36 |
| dholbach | good morning | 07:43 |
| jdong | good evening :) | 07:47 |
| siretart | no, good morning! :) | 07:50 |
| Hobbsee | morning dholbach | 07:50 |
| dholbach | heya siretart, hey Hobbsee | 07:53 |
| * siretart hugs jdong, Hobbsee and dholbach | 07:53 | |
| dholbach | HUGS! :) | 07:54 |
| * jdong hugs everyone good night :) | 07:54 | |
| * dholbach hugs y'all :) | 07:54 | |
| Hobbsee | :) | 07:56 |
| ajmitch | hi dholbach | 08:00 |
| dholbach | heya ajmitch | 08:00 |
| === \sh_away is now known as \sh | ||
| \sh | moins | 08:06 |
| persia | gnomefreak: Could I convince you to use the new shiny interdiff method of submitting new upstreams to the sponsors queue? Instructions are available from https://wiki.ubuntu.com/MOTU/Sponsorship/Interdiff | 08:12 |
| \sh | persia, reading your document, you mean, that we attach a debdiff and an interdiff? | 08:13 |
| persia | \sh: A debdiff or an interdiff. Most things are debdiffs, but when debdiff doesn't work (for new upstreams), I'm happy to receive an interdiff, and don't want to try to track status in both REVU and a bug. | 08:14 |
| \sh | persia, ah ok... | 08:18 |
| persia | Of course, there's still a gap: there's no good way to request sponsorship of new binary objects in a native package, but that's a harder issue to solve, | 08:19 |
| persia | \sh are you planning any new upstreams soon? | 08:20 |
| gnomefreak | persia: i will try one real fast i still need to get some sleep but i would like to get them upgrded before new releases are out. | 08:22 |
| \sh | persia, tbh, I'm trying to go back to do some merging...but right now, I'm still working on sec fixes | 08:23 |
| persia | gnomefreak: Understood. Are they not new upstream versions then? In that case, a debdiff should be sufficient. | 08:23 |
| persia | \sh: For merges, I'd actually prefer a debdiff against Debian, as that represents the work of the merger, rather than an interdiff which combines the merger's work with the Debian updates. | 08:24 |
| gnomefreak | sunbird is new upstream features/security iceape is stritly security upgrade | 08:24 |
| \sh | Fujitsu, ping tomcat ... how do we proceed with this package...it really needs some love... | 08:25 |
| persia | gnomefreak: In that case, just attach the iceape debdiff to the bug, and someone will likely look at it within a few hours (or maybe a day at most). For sunbird, you'll have to look at interdiff or wait for REVU. | 08:25 |
| \sh | persia, ah you mean with new upstream ubuntu packages with -0ubuntuX | 08:25 |
| persia | \sh: Exactly. debdiffs don't work well for that, but it doesn't require full REVU | 08:26 |
| * persia admits this is an edge case being addressed | 08:26 | |
| gnomefreak | when i wait for revu the packages dont get pushed. i have uploaded > 6 packages to revu and only gwget was pushed the rest were never looked at and ended up missing a few upgrades for it so i did them still no push | 08:26 |
| persia | gnomefreak: That's not surprising, and is why I wrote the docs on interdiff. The sponsors queue is significantly more reactive than the REVU queue, and seems the appropriate way to review work to keep packages in shape (rather than NEW packages). | 08:27 |
| persia | gnomefreak: Basically, if you are updating the package for the same upstream version, we want a debdiff. If there is a new upstream, we want an interdiff. See http://wiki.ubuntu.com/MOTU/Contributing under "Preparing New Revisions" for a discussion. | 08:28 |
| gnomefreak | ok i will try it out see how it works | 08:29 |
| persia | gnomefreak: Great. Thanks, both for trying interdiff, and for all your efforts to keep those packages in shape. | 08:29 |
| gnomefreak | np i love packaging ;) | 08:30 |
| gnomefreak | persia: interdiff -z -p1 packagename_version-revision.diff.gz packagename_newversion-newrevision.diff.gz check.interdiff doesnt work it gives me the options output | 08:33 |
| persia | gnomefreak: Hrm. It worked for me. Which package are you trying? | 08:33 |
| slangasek | did you mean to use > check.interdiff? | 08:33 |
| gnomefreak | lightning-sunbird | 08:33 |
| slytherin | Can anyone tell me how can I find bugs where small amount of work is needed? | 08:34 |
| \sh | well, the only problem with security fixes is, that you have to maintain at least 4 chroots, and if you help debian to fix stable security, you need at least 2 more | 08:34 |
| gnomefreak | no because its not on there | 08:34 |
| persia | gnomefreak: OK. I'll try here, and see if I can replicate the issue. | 08:34 |
| gnomefreak | i will try that | 08:34 |
| \sh | slytherin, try searching on launchpad for bugs with the bitsize (sp) tag | 08:34 |
| gnomefreak | persia: wiki doesnt have the > that is needed | 08:34 |
| slangasek | "bitesize" | 08:34 |
| persia | gnomefreak: Thanks. I'll chase why. | 08:35 |
| persia | gnomefreak: Typo. Thanks for finding it. | 08:36 |
| slytherin | \sh: I have fixed a small problem previously in tagtool. The problem is that it is recommended that we fix the problems for hardy. also most of the times the developers recommend that we forward bugs to debian. I am not able to understand how I can fix bugs in gutsy. | 08:36 |
| gnomefreak | persia: your welcome, during interdiff -z oldversionofpacakge.diff.gz newversion.diff.gz | gzip --best -c - > oldversion_newversion.interdiff? | 08:37 |
| persia | slytherin: First, a bug gets fixed in hardy. Then, if it is considered critical, the fix is backported to Gutsy. See the Stable Release Updates documentation for criteria. | 08:39 |
| gnomefreak | example lightning-sunbird_0.5_0.7.interdiff would be last line (file that i name) | 08:39 |
| persia | !sru | 08:39 |
| ubotu | Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 08:39 |
| persia | gnomefreak: That works. The filename doesn't really matter, although I prefer ones that are semantically meaningful when I later grep my sponsoring archive. | 08:40 |
| gnomefreak | meaning that having both versions in it? | 08:40 |
| gnomefreak | would be best? | 08:40 |
| === LucidFox is now known as Sikon_Stargate | ||
| persia | gnomefreak: That tends to be best, but can be wordy. Also, naming it to match the candidate version-revision works. Use whatever is most meaningful for your in your patch archive (you do keep a patch archive, right?) | 08:41 |
| gnomefreak | define patch archive | 08:41 |
| \sh | slangasek, right bitesize | 08:42 |
| persia | gnomefreak: A place where you keep your patches for later reference when someone asks you what you did for a given change. | 08:43 |
| gnomefreak | yeah on my branch | 08:43 |
| slytherin | persia: ok. will keep that in mind | 08:44 |
| persia | gnomefreak: Ah, if you're doing all this in VCS, the nomenclature doesn't matter for you. My personal preference is for something like lightning_sunbird_05-0ubuntu4_07.interdiff, but anything works | 08:44 |
| gnomefreak | persia: i have a ~/downloads/patches but it has few in it since i havent had to work with much lately | 08:45 |
| persia | Err. lightning-sunbird_05-0ubuntu4_07.interdiff | 08:45 |
| gnomefreak | persia: uploading interdiff, i didnt get that into it but i did use packagename_0.5-0.7.interdiff | 08:47 |
| gnomefreak | its uploaded to bug report | 08:47 |
| persia | gnomefreak: That works too :) I'll grab it. | 08:47 |
| gnomefreak | https://bugs.edge.launchpad.net/ubuntu/+source/lightning-sunbird/+bug/164278 this one | 08:47 |
| ubotu | Launchpad bug 164278 in lightning-sunbird "Please sponsor this package for Hardy" [Undecided,New] | 08:47 |
| gnomefreak | ill work on debdiff for iceape | 08:47 |
| pwnguin | man, how did i miss the amoeba package? | 08:50 |
| gnomefreak | persia: wait on sunbird please | 08:58 |
| gnomefreak | persia: yeah dont do it i screwed up it should be nobinonly (as it is on revu :( | 08:59 |
| persia | gnomefreak: I'm sending for rework anyway: 1) no mention of rework of the autoconf patch, 2) no watch file or get-orig-source | 08:59 |
| gnomefreak | yeah i gave it to you from wrong build dir | 08:59 |
| persia | That makes sense :) | 08:59 |
| gnomefreak | did the interdiff work right atleast? | 09:00 |
| persia | gnomefreak: Sure. I have a clean looking lightning-sunbird_0.7-0ubuntu1.diff.gz in my working directory. | 09:00 |
| gnomefreak | k | 09:00 |
| gnomefreak | debdiff on iceape is taking forever | 09:00 |
| persia | gnomefreak: lots of changes? | 09:03 |
| gnomefreak | yep just upstream changes | 09:03 |
| persia | gnomefreak: upstream patches to the same version number? I guess I'm confused about how mozilla packaging works. | 09:04 |
| gnomefreak | iceape 1.1.5 now is 1.1.6 they were all security releases | 09:05 |
| gnomefreak | and will be until 2.x | 09:05 |
| gnomefreak | debdiff iceape_1.1.5-1ubuntu0.7.10.dsc iceape_1.1.6-1ubuntu0.7.10.dsc > iceape_1.1.6-1ubuntu0.7.10.debdiff | 09:05 |
| persia | gnomefreak: Well, if you're moving from 1.1.5 to 1.1.6, I'd prefer an interdiff with a new tarball. | 09:05 |
| gnomefreak | that is right command right? | 09:05 |
| gnomefreak | ok i can do that | 09:06 |
| persia | No. debdiff is for packaging changes for the same upstream, or for merges from debian. You want an interdiff in this case (much smaller) | 09:06 |
| persia | Alternately, I'd be happy with the output of `debdiff iceape_1.1.6-1.dsc iceape_1.1.6-1ubuntu0.7.10.dsc > iceape_1.1.6-1ubuntu0.7.10.debdiff` | 09:07 |
| persia | gnomefreak: Also, is this for hardy, or an SRU target? | 09:09 |
| gnomefreak | persia: iceape is for security release gutsy-security and sunbird is for hardy | 09:10 |
| persia | gnomefreak: OK. Got it now. | 09:11 |
| gnomefreak | iceapes interdiff is attaching | 09:11 |
| gnomefreak | bug 164278 and i ill do sunbird with nobinonly in a minute | 09:12 |
| ubotu | Launchpad bug 164278 in lightning-sunbird "Please sponsor this package for Hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/164278 | 09:12 |
| \sh | gnomefreak, please subscribe ubuntu security team for the sec update | 09:12 |
| gnomefreak | crap | 09:12 |
| persia | \sh: even for universe? | 09:13 |
| \sh | persia, even for universe...kees and jdstrand are the only people who can upload to -security pocket | 09:13 |
| persia | Ah! I understand. Thanks. | 09:13 |
| \sh | persia, but only for real security fixes...not bug fixing for a broken app | 09:13 |
| gnomefreak | ok iceape has security team and interdiff is there | 09:13 |
| \sh | gnomefreak, did you add the CVEs? | 09:14 |
| \sh | gnomefreak, and is iceape in feisty as well vulnerable? (when it's in feisty ;)) | 09:14 |
| gnomefreak | \sh: cant for iceape there arnt any just mozilla bug fixes, i looked for 2 days | 09:15 |
| gnomefreak | \sh: iceape only in gutsy and hardy for now hardy will be getting the official branding | 09:15 |
| \sh | gnomefreak, hmm...bug no? :) | 09:15 |
| gnomefreak | i listed them | 09:16 |
| \sh | gnomefreak, no lp bug no ;) | 09:16 |
| persia | \sh bug #164276 | 09:16 |
| ubotu | Launchpad bug 164276 in iceape "Please sponsor iceape for gutsy-secuity" [Undecided,New] https://launchpad.net/bugs/164276 | 09:16 |
| \sh | gnomefreak, ah...could you do the following and follow security update policy? | 09:17 |
| Ubulette | please, don't do hardy, just gutsy for iceape | 09:18 |
| \sh | gnomefreak, https://wiki.ubuntu.com/SecurityUpdateProcedures | 09:18 |
| persia | gnomefreak: I've archived the REVU uploads. They are still available by URL, and will get unarchived if commented or reuploaded, but I think you'll get a faster response with the interdiffs in the bugs. | 09:19 |
| persia | Ubulette: Why wouldn't we want to also close bugs in hardy? | 09:19 |
| gnomefreak | Ubulette: thats all i did was gutsy | 09:19 |
| Ubulette | gnomefreak, i know you know :) | 09:19 |
| gnomefreak | persia: seamonkey will be in hardy | 09:20 |
| \sh | gnomefreak, are those fixes cherry picked? no bug fixes which are not fixing those CVEs? | 09:20 |
| gnomefreak | Ubulette: they cant do anything in hardy since the changelog has gutsy-security | 09:20 |
| persia | gnomefreak: Ah. That makes sense, but I'd still like to close security bugs until the package removal is approved. | 09:20 |
| gnomefreak | \sh: mainly the fixes were for 1.1.5 they were adding more as i understand it | 09:20 |
| gnomefreak | persia: we have it ready afaik Ubulette if its ready follow instuctions above to get it pushed in asap than i will file a bug to remove iceape from hardy | 09:21 |
| \sh | gnomefreak, well, you mentioned only CVE bug fixes...(please change the changelog according to SecurityUpdateProcedure).... | 09:21 |
| gnomefreak | \sh: what package are you looking at? | 09:21 |
| gnomefreak | i dont have changelogs in my head atm | 09:22 |
| \sh | gnomefreak, https://bugs.edge.launchpad.net/ubuntu/+source/iceape/+bug/164276 | 09:22 |
| ubotu | Launchpad bug 164276 in iceape "Please sponsor iceape for gutsy-secuity" [Undecided,New] | 09:22 |
| Ubulette | seamonkey 1.1.6 is ready for review for hardy for a while too, but changes are huuuuge so I still need to hear from my reviewer | 09:23 |
| persia | Ubulette: You might upload to REVU for comments :) | 09:23 |
| gnomefreak | \sh: * Fixes Mozilla bugs 39412, 400406, 400421, 400735, 400744, 400939, 400976 are the bugs that were fixed, no cves for these fixes anywhere on mozilla | 09:23 |
| ubotu | Mozilla bug 39412 in General "Relative URLs under file:// are broken" [Normal,Verified: worksforme] http://bugzilla.mozilla.org/show_bug.cgi?id=39412 | 09:24 |
| ubotu | Mozilla bug 400406 in Layout "Layout badly broken in 2.0.0.8, CSS issue with floats or negative margins or display property..." [Major,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=400406 | 09:24 |
| ubotu | Mozilla bug 400421 in Layout "Removing AREA element makes the image disappear" [Major,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=400421 | 09:24 |
| ubotu | Mozilla bug 400735 in XBL "New startup crash [@ nsXBLBinding::AllowScripts]" [Critical,Verified: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=400735 | 09:24 |
| ubotu | Mozilla bug 400744 in General "Pure virtual function call and crash invoking context menu" [Critical,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=400744 | 09:24 |
| \sh | gnomefreak, reading the interdiff it mentions: | 09:24 |
| \sh | --- iceape-1.1.5/debian/changelog | 09:24 |
| \sh | +++ iceape-1.1.5.orig/debian/changelog | 09:24 |
| \sh | @@ -1,497 +0,0 @@ | 09:24 |
| \sh | -iceape (1.1.5-1ubuntu0.7.10) gutsy-security; urgency=low | 09:24 |
| \sh | - | 09:24 |
| \sh | - * Upstream security release | 09:24 |
| \sh | - * Fixes CVE-2007-4841, 2007-5338, 2007-5337, 2007-5334, 2007-3511, | 09:24 |
| ubotu | Mozilla Firefox before 2.0.0.8, Thunderbird before 2.0.0.8, and SeaMonkey before 1.1.5 allows remote attackers to execute arbitrary commands via a (1) mailto, (2) nntp, (3) news, or (4) snews URI with invalid "%" encoding, related to improper file type handling on Windows XP with Internet Explorer 7 installed, a variant of CVE-2007-3845. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4841) | 09:24 |
| \sh | - 2007-2894, 2007-2292, 2007-1095, 2007-5339, 2007-5340, 2007-4965 | 09:24 |
| \sh | - * debian/patches/99_configure.dpatch: Updated for new release | 09:24 |
| \sh | - | 09:24 |
| gnomefreak | \sh: and your point? | 09:25 |
| gnomefreak | i know what it says im looking at it | 09:25 |
| \sh | gnomefreak, those are security fixes, please backport them to actual gutsy release... | 09:25 |
| gnomefreak | \sh: ?? iceape is only going into gutsy | 09:26 |
| gnomefreak | no need for backport since it is security release | 09:26 |
| \sh | gnomefreak, yes...but iceape is already in gutsy, so for CVE fixes, we backport patches for those security issues | 09:27 |
| \sh | gnomefreak, there is no "new version release for security". | 09:27 |
| gnomefreak | \sh: afaik for CVE/security releases go to gutsy-security not backport | 09:27 |
| \sh | gnomefreak, you stay with the version in the archive...and patch the source...new releases have to go via -backports, bug fixes, which are not fixing security relevant stuff are going to -proposed, and then -updates | 09:28 |
| gnomefreak | \sh: did you read the bugs? | 09:28 |
| \sh | gnomefreak, yepp... | 09:28 |
| gnomefreak | did you read release notes? | 09:28 |
| persia | \sh: There are sometimes exceptions, and mozilla apps tend to get approved. | 09:28 |
| \sh | persia, well, but those fixes are easy to apply to the actual version in gutsy...there is no need for a new upstream release | 09:29 |
| persia | \sh: Yes, I'd agree. There's something odd there, and I haven't sorted what. | 09:30 |
| gnomefreak | persia: please check new interdiff on bug 164278 and you might want to explain wha tyou need me to do after since i didnt do nobinonly the first one. big differences in changelog and friends as for the autoconf2.13 i had to run it to update for new release | 09:30 |
| ubotu | Launchpad bug 164278 in lightning-sunbird "Please sponsor this package for Hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/164278 | 09:30 |
| gnomefreak | \sh: i follow security releases per mozilla and the less hacking i have to do the better it is (if youve ever played with mozilla code you will know why its easier this way | 09:31 |
| * gnomefreak still hasnt gone to sleep, going for smoke | 09:31 | |
| \sh | gnomefreak, yes I know how hard it is to play with mozilla....:) we have more candidates like this in our archives...back to dapper :) | 09:33 |
| \sh | but regarding debians version changelog for 1.1.5-1 | 09:35 |
| \sh | iceape (1.1.5-1) unstable; urgency=low | 09:35 |
| \sh | * New security/stability upstream release. | 09:35 |
| \sh | * Fixes mfsa-2007-29 to mfsa-2007-36, also known as CVE-2007-1095, | 09:35 |
| \sh | CVE-2007-2292, CVE-2006-2894, CVE-2007-3511, CVE-2007-4841, | 09:35 |
| \sh | CVE-2007-5334, CVE-2007-5337, CVE-2007-5338, CVE-2007-5339, | 09:35 |
| persia | gnomefreak: That looks much better. Thanks. Unfortunately, I'm not seeing debian/remove.binonly.sh in the updated diff, and still want a watch file or get-orig-source rule. | 09:35 |
| \sh | CVE-2007-5340. | 09:35 |
| \sh | * debian/remove.nonfree: Remove some more object files. | 09:35 |
| \sh | * debian/patches/99_configure.dpatch: Updated. | 09:35 |
| \sh | * debian/rules: Force the use of -fvisibility=hidden instead of system | 09:35 |
| \sh | wrappers to avoid FTBFS with gcc 4.2. Closes: #377178. | 09:35 |
| \sh | * debian/patches/65_composer_charset.dpatch: Avoid save page dialog when | 09:35 |
| \sh | closing unmodified blank page due to previous patch. Stolen from | 09:35 |
| \sh | bz#400372. | 09:35 |
| \sh | -- Mike Hommey <mh@glandium.org> Sat, 03 Nov 2007 14:51:40 +0100 | 09:35 |
| persia | !pastebin | \sh | 09:35 |
| huats | morning everyone | 09:35 |
| ubotu | Mozilla Firefox before 2.0.0.8 and SeaMonkey before 1.1.5 do not properly implement JavaScript onUnload handlers, which allows remote attackers to run certain JavaScript code and access the location DOM hierarchy in the context of the next web site that is visited by a client. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1095) | 09:35 |
| ubotu | CRLF injection vulnerability in the Digest Authentication support for Mozilla Firefox before 2.0.0.8 and SeaMonkey before 1.1.5 allows remote attackers to conduct HTTP request splitting attacks via LF (%0a) bytes in the username attribute. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2292) | 09:35 |
| ubotu | Mozilla Firefox 1.5.0.4, 2.0.x before 2.0.0.8, Mozilla Suite 1.7.13, Mozilla SeaMonkey 1.0.2 and other versions before 1.1.5, and Netscape 8.1 and earlier allow user-assisted remote attackers to read arbitrary files by tricking a user into typing the characters of the target filename in a text box and using the OnKeyDown, OnKeyPress, and OnKeyUp Javascript keystroke events to change the focus and cause those characters to be inserted into a file upload | 09:35 |
| persia | \sh: Especially please use a pastebin when listing bug numbers and CVEs! | 09:36 |
| \sh | persia, sorry...:) | 09:36 |
| * persia misses ubotu | 09:37 | |
| gnomefreak | persia: in rules file you can make the orig tarball still sincei havent removed it and i dont know why the script didnt show up i did it as i was told to do it | 09:37 |
| persia | gnomefreak: Odd. I wonder why it didn't work for me: trying again... | 09:38 |
| gnomefreak | i didnt leave the script in the package as i was told to run it in package using path to where it is | 09:38 |
| gnomefreak | unpack tarball and ./ /home/gnomefreak/remove.script in unpacked upstream tarball | 09:40 |
| \sh | persia, I checked last security upload from debian for etch...even they are backporting the CVE fixes to their source version (which is 1.0.11 | 09:40 |
| gnomefreak | \sh: we dont merge it from debian | 09:40 |
| gnomefreak | matter of fact we take very little help from debian | 09:41 |
| gnomefreak | normally we push to debian since we are first to have it working | 09:41 |
| \sh | gnomefreak, no question, but I would like to see our version just sec fixed, and not introducing new upstream versions in stable releases... | 09:41 |
| \sh | gnomefreak, this is a no go, e.g. for hardy | 09:41 |
| gnomefreak | \sh: iceape isnt going into hardy | 09:41 |
| warp10 | Hi all! | 09:42 |
| gnomefreak | and iceape firefox thunderbird are all security releases firefox 2.0.0.scrrelease# iceape 1.1.scrrelease# | 09:42 |
| TheMuso | Gotta love two power outag in the sme afternoon/evenin. | 09:42 |
| gnomefreak | \sh: 2.0 will be new upstream release since they wont have 1.2.x series | 09:43 |
| elkbuntu | persia, he takes forever to sync | 09:43 |
| gnomefreak | this is how mozilla defines them | 09:43 |
| persia | elkbuntu: -ENOCONTEXT | 09:43 |
| elkbuntu | persia, teh bot | 09:43 |
| persia | elkbuntu: Ah. Thanks for looking at it. | 09:44 |
| elkbuntu | persia, i figured you'd have seen the join 2 lines up :Þ | 09:44 |
| persia | elkbuntu: I saw that, just didn't link "he" to the bot, nor you to the wrangler restoring it. | 09:44 |
| gnomefreak | \sh: yes i agree in the sense maybe it should be in -proposed but since mozilla defines it as security release thats why i have target gutsy-security | 09:45 |
| elkbuntu | persia, no prob | 09:45 |
| persia | gnomefreak: Based on http://paste.ubuntu.com/2124/, I'm not sure how to get upstream (and still don't see the mentioned debian/remove.binonly.sh | 09:46 |
| gnomefreak | persia: you run script in source dir you dont put the script in package | 09:47 |
| gnomefreak | persia: what about the rules file | 09:47 |
| gnomefreak | update-orig: $(CURDIR)/../$(DEBIAN_MOZ_APPLICATION)_$(DEBIAN_MOZ_SOURCE_VERSION).orig.tar.gz | 09:48 |
| gnomefreak | that is your orig tarball thing in rules | 09:48 |
| persia | gnomefreak: OK. Thanks. update-orig: works (although I'm fairly sure that Debian policy recommends "get-orig-source" as the rule name). | 09:48 |
| gnomefreak | since i was told by asac to run the script in tarball using poath to script as he did with ff tb | 09:48 |
| gnomefreak | persia: thats been there since iceape was started in ubuntu and iirc that is how debian does it as well | 09:49 |
| gnomefreak | seeing as i build our sunbird and me or asac will do iceowl for debian | 09:50 |
| persia | gnomefreak: Now I get "make: *** No rule to make target `sunbird-0.7-source.tar.bz2', needed by `/home/persia/src/scratch/sponsor/lightning-sunbird-0.7+nobinonly/../lightning-sunbird_0.7+nobinonly.orig.tar.gz'. Stop." | 09:50 |
| \sh | gnomefreak, yes, but I tbh I don't really care about mozilla...we have to take care about the security, and we can cherry pick the fixes from mozilla upstream and add them to the dpatch system for the latest version in gutsy easily | 09:50 |
| \sh | gnomefreak, so we have no new version introduced, but fixed all vulnerabilities | 09:50 |
| \sh | gnomefreak, I have a similiar problem with wireshark/ethereal | 09:50 |
| persia | gnomefreak: Also, I don't really care how Debian does it, I more care about having a standard interface to make it easy for me to sponsor :) | 09:51 |
| \sh | gnomefreak, in dapper we have the last release of ethereal, and this version can't be security fixed in a proper way, without introducing the next release of wireshark, which introduces more problems then ever... | 09:51 |
| gnomefreak | than i guess i will wait for asac to et back since he is the one that made rules file and told me how to run script and told me to push iceape as security since he is our core-dev maintainer of moz packages in ubuntu | 09:52 |
| gnomefreak | notice only change made was control file running script in source tarball and changelog oh and updated autoconf patch using autoconf2.13 | 09:53 |
| persia | gnomefreak: That might work. We'd like to help, but I'm just not having any luck getting the new upstream (even with the update-orig rule), and \sh is sharing his troubles in trying to do similar things, hoping to be able to get one of the security team to get the upload earlier. | 09:53 |
| \sh | gnomefreak, but you can ask jdstrand or keescook about this...could be that they have a different opinion then I have regarding this special case | 09:53 |
| gnomefreak | persia: it has always worked for me but we use mozclient for most part to make our orig.tar.gz so i dont use the rules way anymore as its easier the other ways | 09:54 |
| * gnomefreak can care less wher eit goes i just followed what asac had said to do | 09:55 | |
| persia | gnomefreak: If the other ways were documented for automation, I'd be happy to use it. Why not have the mozclient call in debian/rules / | 09:55 |
| persia | s/\/\?/ | 09:55 |
| persia | Err.. s/\//\?/ | 09:55 |
| gnomefreak | since he is paid dev i trust what he says is fine | 09:55 |
| * persia continues to claim that it doesn't matter whether one gets paid | 09:56 | |
| \sh | persia, +1 :) | 09:56 |
| gnomefreak | it doesnt matter but since he is paid i tend to follow instructions from him since he is one taking blame unless i screw something up | 09:57 |
| gnomefreak | and i didnt | 09:57 |
| Ubulette | persia, i'm the author of mozclient, it's usable, useful and used by our team, yet, it's not packaged as a deb. my plan is to make a cdbs-like extension | 09:57 |
| persia | Ubulette: Ah. That's why I can't use it: it's not packaged :) Please hurry :) | 09:57 |
| gnomefreak | so im not seeing a problem, iceapes rules for orig should work fine i havent used it in 5 months or so but worked last i used it | 09:58 |
| Ubulette | you can use it, just bzr pull it | 09:58 |
| gnomefreak | persia: use the branch | 09:58 |
| persia | gnomefreak: I get "make: *** No rule to make target `sunbird-0.7-source.tar.bz2', needed by `/home/persia/src/scratch/sponsor/lightning-sunbird-0.7+nobinonly/../lightning-sunbird_0.7+nobinonly.orig.tar.gz'. Stop. | 09:58 |
| persia | " | 09:58 |
| gnomefreak | no building needed | 09:58 |
| gnomefreak | persia: i wouldnt know i dont use it for sunbird i used it for iceape | 09:58 |
| persia | gnomefreak: I refuse to work around buggy package code. Maybe someone else will upload, but not being able to use the published interface blocks me. Is it that hard to fix? | 09:59 |
| Ubulette | http://www.sofaraway.org/ubuntu/tarballs/lightning-sunbird_0.7.orig.tar.gz | 09:59 |
| * persia is suspicious of random unofficial tarballs | 09:59 | |
| Ubulette | then don't take it | 10:00 |
| Ubulette | i don't mind | 10:00 |
| persia | Ubulette: It's that I sponsor lots of uploads every day. I have a fairly rigid set of rules in place so that I can't easily make a mistake in doing so. Someone who knows anything at all about the package, or uses it might be in a different position when reviewing. | 10:01 |
| persia | gnomefreak: I'll resubscribe the sponsors queue. The interdiff looks great: I'm just having trouble. | 10:02 |
| * TheMuso has not seen the sponsors queue so small in ages! Well done all to those who have helped. | 10:03 | |
| gnomefreak | persia: whats wrong with tarball on revu | 10:03 |
| TheMuso | /c/c | 10:03 |
| gnomefreak | that is the one used to build it so its offifical | 10:03 |
| gnomefreak | official | 10:03 |
| persia | gnomefreak: Same issue as with Ubulette's. I never upload REVU tarballs, even when the second advocate on REVU. | 10:03 |
| gnomefreak | persia: why they are the ones used to build package | 10:04 |
| persia | gnomefreak: I don't use them to build packages. | 10:04 |
| TheMuso | persia: Why don't you upload advocated packages from revu? | 10:04 |
| gnomefreak | oh and sunbird wont beable to use orig in rules since mozilla has it set up weird since its still "testing" | 10:04 |
| persia | TheMuso: I do upload, just with upstream tarballs. | 10:04 |
| TheMuso | persia: Right. | 10:05 |
| persia | (or scripted-mangled tarballs verified from upstream) | 10:05 |
| gnomefreak | orig == upstreams | 10:05 |
| gnomefreak | most of our apps have enbedded tarballs | 10:05 |
| Ubulette | http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.7/source/lightning-sunbird-0.7-source.tar.bz2 | 10:06 |
| persia | gnomefreak: I believe you, I just am extra-paranoid about these things, in part because of the volume I have. As I said, I think the interdiff is good, and have resubscribed the sponsors team with a note that someone more familiar with mozilla packaging would do well to upload. | 10:07 |
| persia | Ubulette: Thanks. | 10:08 |
| gnomefreak | that makes exactly 3 people 1 motu 1 core and Ubulette that are familiar with moz apps that im aware of and the 2 that can push are gone | 10:08 |
| persia | gnomefreak: Right. That's why I'm encouraging you to change things to follow standard interfaces: it makes it not matter if we're familiar with the packaging. | 10:09 |
| * gnomefreak ponders sleeping for an hour | 10:09 | |
| persia | Ubulette: I'm still getting an error from update-orig: with that tarball in the parent directory. Is there something else I have to do? | 10:10 |
| \sh | net-snmp for edgy is building, dapper still to go.... | 10:11 |
| Ubulette | persia, i don't remember the code in rules but a rename should be enough | 10:12 |
| persia | Just `mv lightning-sunbird-0.7-source.tar.bz2 sunbird-0.7-source.tar.bz2`? | 10:12 |
| Ubulette | maybe even sunbird_0.7-source.tar.bz2 | 10:13 |
| \sh | hi s1024kb | 10:14 |
| persia | Ubulette: debian/rules is looking for sunbird-0.7-source.tar.bz2, as far as I can see. Is there another step involved, or are the differences between _ and - being ignored? | 10:14 |
| s1024kb | \sh: hi | 10:14 |
| s1024kb | \sh: had added you in jabber | 10:14 |
| \sh | s1024kb, yeah...just approved the request :) | 10:14 |
| gnomefreak | persia: should be lightning-sunbird_0.7 | 10:15 |
| persia | gnomefreak: the upstream tarfile? | 10:15 |
| gnomefreak | persia: what i normally do there is once i grab it ill change the - to a _ | 10:16 |
| persia | gnomefreak: Maybe I've received the wrong upstream file then. I have lightning-sunbird-0.7-source.tar.bz2 | 10:16 |
| gnomefreak | let me look hold on | 10:16 |
| persia | gnomefreak: Thank you. | 10:16 |
| gnomefreak | lightning-sunbird-0.7-source.tar.bz2 | 10:18 |
| gnomefreak | that is upstream tarball | 10:18 |
| persia | OK. I have the right upstream then. Now, update-orig is looking for sunbird-0.7-source.tar.bz2 : should I be running a different rule? | 10:19 |
| gnomefreak | source package isnt called sunbird | 10:20 |
| persia | gnomefreak: Right. I just don't understand how to get the right orig.tar.gz. Anyway, I've hit a time wall for now: if you post instructions here or to the bug, I'll take another look when I'm free again. | 10:21 |
| gnomefreak | persia: the orig.tar.gz is on revu | 10:21 |
| gnomefreak | persia: we never used update-orig in sunbird but since we used same rules file for ff thats why its there | 10:22 |
| gnomefreak | persia: we havent deemed it needed and since 0.5 is in repos and you can see the difference from 0.5 and 0.7 this shouldnt be an issue or it would have been given back when first introduced package | 10:23 |
| gnomefreak | if it was new to ubuntu i could understand | 10:23 |
| \sh | ok..net-snmp dapper patched, building.. | 10:29 |
| warp10 | When I produce a debdiff (for example, for a merge), if I need to correct, say, a typo, can I modify the debdiff or do I need to modify the source tree, rebuild, and re-debdiff? | 10:35 |
| soren | warp10: If you don't add or remove any lines but just change existing ones, editing the debdiff should be safe. You should check that it still applies cleanly, though. | 10:37 |
| soren | warp10: Don't tell anyone I said that, though. | 10:37 |
| warp10 | soren: thanks... my lips are sealed. | 10:38 |
| \sh | anyone wants to cve fix horde3 ? :) | 10:40 |
| === Sikon_Stargate is now known as LucidFox | ||
| slytherin | TheMuso: ping | 10:55 |
| TheMuso | slytherin: Hi there. | 10:55 |
| slytherin | TheMuso: Regarding the call for MOTU PPC. I am interested. I have been learning packaging recently and now have an old iBook G4 now (got from my brother). :-) | 10:56 |
| slytherin | TheMuso: I have already requested membership for the team you mentioned but not yet approved. | 10:57 |
| proppy | is there a PPC port on the way ? | 10:57 |
| StevenK | Ubuntu has had a PPC port since Warty | 10:58 |
| TheMuso | slytherin: Great. | 10:58 |
| TheMuso | Unfortunately I have no admin powers on that team, so can't do anything unfortunately. | 10:58 |
| TheMuso | proppy: All I'm doing is gathering people interested in helping maintain the ppc port, as canonical have dropped official support for it. | 10:59 |
| persia | gnomefreak: Don't worry too much. I'm not the only sponsor, but likely one of the most picky. Just because I can't figure out how to generate the file doesn't mean someone else won't upload it. I suspect you've still a better chance than with an REVU entry. | 11:00 |
| proppy | TheMuso: nice | 11:00 |
| slytherin | TheMuso: the ubuntu-ppc team has same purpose right? | 11:01 |
| TheMuso | slytherin: Well actually, it seems that the team is just for show. Nothing is really done with it so far as I can tell. | 11:02 |
| === cprov-away is now known as cprov | ||
| persia | dholbach: Umm.. A merging recipe is tricky, as too much depends on the merge process. For something well understood, frequently just applying the debdiff from patches.ubuntu.com to the new Debian revision and editing the changelog is sufficient, but the key is understanding it. Are you sure you want a recipe? (I have logs) | 11:04 |
| dholbach | persia: I'm sure there are straight-forward merges whose main steps are shared across a big range of different types of merges | 11:06 |
| persia | dholbach: Sure, there are plenty of merges that could be handled by a script, which is part of what MoM and DaD try to do. The key is that every merge should be done with deep research and understanding of the nature of the changes: I'm really not sure that can be put in a recipe. | 11:07 |
| persia | To put it another way, I've found myself cleaning up after too many merges to want to encourage people to do them with less research. | 11:08 |
| persia | This is especially prevalent when there's a mistake in the Debian changelog, or something not updated perfectly in the Ubuntu changelog. | 11:09 |
| * Hobbsee thinsk it's particularly good when people file a bug, subscribe the sponsors, and list the DAD url in it, as the only piece of information. | 11:09 | |
| \sh | persia, I think the missing part for merges is, that there is no real explanation of the change the merger did, so that there is always the question: why he/she did this..so we have always ask, if it's not a trivial change | 11:09 |
| dholbach | hrm, I just feel that the Merging doc on UbuntuDevelopment is a bit too general to help people with doing merges and the examples we have on other merges wiki pages are out of date | 11:09 |
| persia | dholbach: I'll agree it's general, but I don't think merging is a good way for new people to help: they should be fixing bugs or packaging new stuff. Merging is hard, and has too many special cases. | 11:10 |
| dholbach | OK | 11:10 |
| dholbach | persia: I'll follow up on my mail | 11:10 |
| persia | \sh: If it's not well expressed in the changelog, that's bad practice on the part of the merger. With properly written changelogs, we should never encounter that. | 11:11 |
| \sh | .oO(and how should I do a session on security fixing) | 11:11 |
| persia | dholbach: Thanks. I just wanted to discuss with you before replying negatively on the ML :) | 11:11 |
| proppy | is g++ -shared ../libjuce.a -o libjuce.so, the correct way to generate a shared library from a static file ? | 11:13 |
| proppy | (it is packaging related, because the upstream makefile only generate a static .a, and I'm trying to package it at http://juce.aminche.com/) | 11:16 |
| fernando | moin all | 11:17 |
| proppy | I guess I've to generate it from the .o, since the file generated by g++ -shared ../libjuce.a -o libjuce.so really doesn't look like a shared library when passed to nm | 11:18 |
| proppy | hi fernando | 11:18 |
| slytherin | TheMuso: I will make a comment on your post just for the record | 11:18 |
| slytherin | dholbach: are you too busy to check mails on bluetooth list? | 11:19 |
| slytherin | dholbach: I mean ubuntu-bluetooh | 11:19 |
| dholbach | slytherin: I'm not an admin anymore - the mobile team takes care of bluetooth nowadays | 11:19 |
| norsetto | dholbach: Is this https://wiki.ubuntu.com/MOTU/Merging not helpful? It should contains everything a newcomer needs to know about merging | 11:27 |
| dholbach | norsetto: I'll merge it into UbuntuDevelopment/Merging too | 11:28 |
| === Adri2000_ is now known as Adri2000 | ||
| norsetto | dholbach: note that it was revised recently to make sure it is up to date and to bring it more in line to the needs of new contributors | 11:29 |
| dholbach | norsetto: that's great | 11:29 |
| dholbach | norsetto: yeah, it looks very good | 11:30 |
| warp10 | norsetto, dholbach: let me say that MOTU/Merging is *really* useful and plain for a new contributor, as I'm experiencing | 11:31 |
| norsetto | warp10: I'm glad to hear that :-) | 11:31 |
| warp10 | norsetto: :) | 11:32 |
| persia | norsetto: LASH is good, LASH is grand, everyone should always use LASH :) | 11:32 |
| StevenK | slytherin: fetching data for ubuntu-bluetooth@lists.ubuntu.com ... nothing in queue | 11:32 |
| * persia steals a bug | 11:32 | |
| norsetto | persia: I would check with debian first, perhaps they have good reasons to not enable it (looks like a mistake though) | 11:33 |
| slytherin | StevenK: I just wanted to make sure that my mail with subject 'agenda for hardy' was sent. | 11:33 |
| persia | norsetto: The main reason is that the debian-multimedia team is swamped, and tend to test integration issues in 64studio before rolling into Debian. | 11:33 |
| norsetto | persia: there seems also to be a new lash issue upstream which fix some bugs, can you check if debian has it already? | 11:34 |
| dholbach | slytherin: http://lists.ubuntu.com/archives/ubuntu-bluetooth | 11:35 |
| persia | norsetto: Umm, do you have a pointer to anything? | 11:35 |
| persia | (I'm happy to check Debian, etc., it's just I have no idea what "issue" is being discussed) | 11:35 |
| norsetto | persia: its in the bug report, if I remember it correctly was issued around 10 days ago | 11:36 |
| slytherin | dholbach: It is there. I will wait for replies. :-) | 11:36 |
| persia | norsetto: 0.5.4. Right. Sure. I'll look for a sync / merge / upgrade for that: fixing memory leaks is good. Thanks for pointing it out. | 11:37 |
| norsetto | warp10: thanks for testing tagtool, appreciate it! | 11:40 |
| warp10 | norsetto: :) I'm waiting for mono-addins build too, looks like it's still in queue | 11:41 |
| === dholbach_ is now known as dholbach | ||
| StevenK | TheMuso: Ping | 11:42 |
| TheMuso | StevenK: yes? | 11:44 |
| \sh | bah...I hate dbs | 11:48 |
| \sh | didn't we have a MONO team? | 11:51 |
| dholbach | \sh: slomo, ajmitch, bhale are the MONO team :) | 11:53 |
| norsetto | dholbach: looks like a TRIO team to me .... | 11:53 |
| \sh | slomo, wanna fix CVE-2007-5197? :) | 11:53 |
| ubotu | Buffer overflow in the Mono.Math.BigInteger class in Mono 1.2.5.1 and earlier allows context-dependent attackers to execute arbitrary code via unspecified vectors related to Reduce in Montgomery-based Pow methods. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5197) | 11:53 |
| Amaranth | Wow | 11:54 |
| Amaranth | That's quite a description | 11:54 |
| \sh | Amaranth, hehe | 11:55 |
| \sh | Amaranth, but in the end, it's just a oneline | 11:55 |
| \sh | r | 11:55 |
| norsetto | dholbach, persia: from the email on motu-mentors looks like we have at least 2 APAC available for a Q&A session | 11:59 |
| dholbach | norsetto: rock and roll! :) | 11:59 |
| persia | norsetto: Two who want one and would find 13:00 UTC inconvenient? | 12:00 |
| norsetto | persia: yes, perhaps its a good idea to send and email to the lists to ask if there are more people interested in an "asian" session | 12:01 |
| Hobbsee | norsetto: ... asia-pac != asian. | 12:02 |
| norsetto | Hobbsee: yes, but about same time. They pop up around 00:00 UTC saying good morning | 12:03 |
| persia | norsetto: Depending on the time of day, I suspect it might be nice to hit the Americas as well. I'm just not sure if there's enough benefit to something like 04:00 UTC to hold it, or whether it would be better to try something closer to 0:00 UTC, which is early on this side, but perhaps useful in the Americas | 12:03 |
| norsetto | persia: easy does it, do both ;-) | 12:03 |
| persia | norsetto: Err. Neither time is very convenient for me, but I'm mostly interested in avoiding the crickets... syndrome. | 12:04 |
| * norsetto check the timezones | 12:05 | |
| \sh | slomo, mono fixes are done ;) just need to testbuild | 12:06 |
| === Kranz is now known as DktrKranz | ||
| * norsetto --> lunch | 12:27 | |
| * persia severely dislikes tarball-in-tarball packaging | 13:26 | |
| Fujitsu | persia: It seems to be a fairly silly idea. | 13:27 |
| persia | Fujitsu: The tradional proponents argue that it correctly enforces separation of concerns, far better than just pretending to keep everything in debian/ I can see the point, but find actually digging to the source frustrating. | 13:28 |
| persia | Fujitsu: Further, it's just convenience. Nothing is actually distributed as tarball-in-tarball, it only looks that way. | 13:29 |
| * persia stops defending the opinion previously declared to be disliked, realising that holding such a position is silly and counterproductive | 13:29 | |
| dholbach | talk to pitti about it :) | 13:34 |
| dholbach | not sure he still does it | 13:34 |
| persia | Right. I lose. LASH can be upgraded by someone else, and needs to have the python bindings enabled anyway. | 13:38 |
| === tudenbart is now known as dothebart | ||
| joejaxx | jdong: :D congrats | 13:55 |
| persia | Riddell: regarding bug #158252: How would you suggest adjusting for the "minimal changes"? Should debian/rules be hacked to not copy the autotools hints in clean: ? Separately, is this class of checking done for packages that copy autotools hints in configure: ? | 14:03 |
| ubotu | Launchpad bug 158252 in dspam "dspam won't start: /var/run/dspam missing in tmpfs" [Undecided,In progress] https://launchpad.net/bugs/158252 | 14:03 |
| Riddell | persia: add patch, edit changelog, debuild -S | 14:04 |
| persia | Riddell: That's what I did: debian/rules clean: copies config.sub & config.guess. The upload was rejected for changing those. I'm curious why. | 14:04 |
| Riddell | it does? autotools are crazy | 14:05 |
| persia | I'm especially curious as I suspect you discovered this by running debdiff, and would not have noticed if the copy happened in configure;, which is becoming ever more common. | 14:05 |
| Riddell | that's the right place to do it, clean: shouldn't make things less clean | 14:06 |
| persia | Riddell: I'll agree autotools are crazy :) | 14:06 |
| Riddell | persia: well, if it's unavoidable, upload again and I'll let it through | 14:06 |
| persia | dh_make recommends clean: for some reason. | 14:06 |
| persia | Riddell: Well, I could patch it to configure: as well, if you'd prefer to read that. | 14:06 |
| Riddell | persia: no, that would be an even less minimal SRU :) | 14:07 |
| persia | Riddell: :) | 14:07 |
| mok0 | I usually remove the statement from rules that copies config.sub & config.guess. Make no sense | 14:09 |
| === neversfelde_ is now known as neversfelde | ||
| mok0 | We really, really, need a replacement for dh_make | 14:10 |
| persia | Riddell: Uploaded. Short & pretty debdiff available from http://launchpadlibrarian.net/10284133/dspam_3.6.8-5ubuntu1.1.dsc.diff | 14:10 |
| persia | mok0: I don't suppose you'd like to submit a patch for dh-make that put it in configure: rather than in clean: ? | 14:11 |
| mok0 | persia: I don't see why you'd want it at all... | 14:11 |
| persia | mok0: Otherwise you need to do it manually all the time in order to get the new hints for new architectures or changes in architectures. | 14:12 |
| persia | Doing it manually is prone to mistake, and means carrying the patch in the diff.gz (which also happens with clean:, but see the earlier comment about clean: making things less clean) | 14:13 |
| mok0 | persia: I'll think about it | 14:15 |
| * minghua always copy config.{sub,guess} in config.status target. | 14:17 | |
| * persia cheers minghua for being sane | 14:17 | |
| minghua | Err... I hope that's not something really worth cheering about. | 14:19 |
| Riddell | persia: accepted, sorry for the hassle | 14:21 |
| persia | minghua: In context, it is. A very large number of packages do it in clean, which makes debdiffs hard to read. | 14:21 |
| minghua | Yeah, blame dh_make. | 14:21 |
| persia | Riddell: No worries. I kick those out of the sponsors queue if the person doesn't run filterdiff. It's just harder when you're looking at actual packages :) | 14:21 |
| persia | minghua: I do. | 14:22 |
| === cprov is now known as cprov-lunch | ||
| bddebian | Heya gang | 14:28 |
| persia | bddebian: I wanted to ask you about the craft package. I recently uploaded a trival fix, and noticed it seemed to be completely useless. There's even a bug reporting that it isn't any fun. Do you know if there's a good current replacement that could be used for justification of removal? | 14:30 |
| bddebian | Heya persia. I don't think I'm familiar with craft, what is it? | 14:32 |
| persia | bddebian: Warcraft 2-like multi-player real-time strategy game | 14:32 |
| bddebian | Ahh | 14:33 |
| bddebian | Well antargis might be if I could figure out the status of the damn thing :) | 14:33 |
| siretart | jdong: FYI: Waiting for approval: vdr-plugin-xineliboutput 1.0.0~rc2-3ubuntu1~gutsy1 (source) | 14:34 |
| persia | OK. I'll wait for that, and then push the removal. I wonder if it's acceptable to file an ITO followed by an RoM comment to purge things... | 14:34 |
| bddebian | persia: heh | 14:35 |
| bddebian | Well that's pretty much what I'm going to end up doing with quake2 I think | 14:35 |
| bddebian | persia: Where's the "not any fun" bug? :) | 14:38 |
| persia | bddebian: Debian bug #355230, last comment | 14:38 |
| ubotu | Debian bug 355230 in wnpp "RFA: craft -- Warcraft 2-like multi-player real-time strategy game" [Normal,Open] http://bugs.debian.org/355230 | 14:38 |
| * bddebian thinks we have a LOT of games that aren't any "fun" :-) | 14:39 | |
| persia | I found that when I was looking to push back the patch, and decided it wasn't worth pushing back. | 14:39 |
| persia | Note that Ubuntu doesn't have freecraft, so that comment doesn't apply. | 14:39 |
| bddebian | Oh shite, yeah, I forgot about freecraft | 14:40 |
| bddebian | Dang freecraft isn't a games team package either | 14:41 |
| persia | bddebian: Blender asked upstream to stop: the devs work on boswars now. Please don't try to revive it. | 14:42 |
| bddebian | What freecraft or craft? Or both? :) | 14:44 |
| bddebian | Bos Wars is fairly cool actually :-) | 14:44 |
| persia | bddebian: freecraft. I don't think craft ever became popular enough for Blender to care. | 14:44 |
| * persia wants boswars, but doesn't have a deb | 14:44 | |
| bddebian | Hmm, I'm trying to remember what the hold-up on boswars was now... | 14:50 |
| persia | I thought you were waiting for a RSN new upstream release | 14:50 |
| bddebian | We have 2.4.1 packaged up | 14:52 |
| geser | Hi bddebian | 14:52 |
| bddebian | Things just move sooo damn slow in that team :_( | 14:52 |
| bddebian | Heya geser | 14:52 |
| persia | bddebian: is it non-free or contrib maybe? | 14:52 |
| persia | Ah. Needs upload then. | 14:52 |
| bddebian | No, just some stupid shit they want to clean up. I'll see if I can kick it in the ass | 14:54 |
| * persia cheers | 14:54 | |
| bddebian | Stupid tarball ships .dlls and such | 14:54 |
| === propp1 is now known as proppy | ||
| * persia archives everything in REVU that was uploaded or superseded by another upload | 14:55 | |
| persia | bddebian: Urk. That's frustrating, but I suspect it's the opposite for people who need them. | 14:55 |
| bddebian | Aye :-) | 14:55 |
| slomo | \sh: thanks for caring for that | 14:57 |
| slomo | \sh: for hardy it's done already though | 14:57 |
| effie_jayx | hello people | 15:00 |
| proppy | wow boswars is nice | 15:01 |
| === gouki_ is now known as gouki | ||
| \sh | slomo, yepp...I just finished patching from gutsy to dapper...I'll testbuild now and upload the patches | 15:13 |
| siretart | slomo: hey there! long time no see, how's it going? | 15:27 |
| LaserJock | !merging | 15:35 |
| ubotu | Sorry, I don't know anything about merging - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 15:35 |
| LaserJock | !sync | 15:35 |
| ubotu | Sorry, I don't know anything about sync - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 15:35 |
| LaserJock | !newpackage | 15:36 |
| ubotu | The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports | 15:36 |
| \sh | !selfdestruction | 15:36 |
| ubotu | Sorry, I don't know anything about selfdestruction - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 15:36 |
| LaserJock | hehe | 15:36 |
| zul | \sh: hehe | 15:36 |
| zul | !longpointystick | 15:36 |
| ubotu | Sorry, I don't know anything about longpointystick - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 15:36 |
| \sh | it's so stupid here right now, unbelievable | 15:36 |
| zul | hmmm? | 15:36 |
| LaserJock | !packagingguide | 15:36 |
| ubotu | packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports | 15:36 |
| LaserJock | ok, so I fixed that one | 15:37 |
| \sh | we sold some hp blades and other hp servers with ilo ... question from the customer: "Where is the ilo password?" | 15:37 |
| zul | \sh: whoops.. | 15:37 |
| \sh | oh wow...they threw away old stinky hardware from a second hand hardware store...and now they have professional hardware, and they don't know anything about it... | 15:38 |
| \sh | well,....open the machine (non-blades) and read the stickers inside... | 15:38 |
| jdong | joejaxx: thanks man :) | 15:44 |
| joejaxx | jdong: you are most welcome :) | 15:47 |
| jdong | libwxgtk2.6-dev: Depends: libwxgtk2.6-0 (= 2.6.3.2.1.5ubuntu12) but it is not going to be installed | 15:53 |
| jdong | do we have some wx transition going on? | 15:53 |
| LaserJock | wow, that's some upstrem version number | 15:53 |
| LaserJock | good 'ol wx | 15:53 |
| jdong | :) | 15:59 |
| jdong | I think they are lacking numbers though | 15:59 |
| === cprov-lunch is now known as cprov | ||
| \sh | cu later ppl | 16:55 |
| === \sh is now known as \sh_away | ||
| === propp1 is now known as proppy | ||
| === asac_ is now known as asac | ||
| === emgent_ is now known as emgent_work | ||
| === emgent_work is now known as emgent_ | ||
| === emgent_ is now known as emgentwork | ||
| === emgentwork is now known as egentili | ||
| === cprov is now known as cprov-away | ||
| james_w | It looks to me as though dh_icons only looks in /usr/share/icons, and only looks for png, svg and jpg icons, so calling it when installing an xmp in to /usr/share/pixmaps is unneeded. Does anyone disagree? | 18:50 |
| bddebian | dh_icons is deprecated I think | 18:57 |
| pochu | bddebian: nope, dh_iconcache is, dh_icons is the replacement :) | 18:58 |
| bddebian | Oh yeah, that's it | 18:59 |
| pochu | I think someone mentioned a FTBFS log similar to this... Does anyone have a clue about what may have happened? It built in all the other archs fine... http://launchpadlibrarian.net/10374729/buildlog_ubuntu-hardy-hppa.gstreamer0.10-ffmpeg_0.10.2-4ubuntu1_FAILEDTOBUILD.txt.gz | 19:06 |
| jdong | flacenc.c:989: internal compiler error: in delete_output_reload, at reload1.c:7958 | 19:13 |
| jdong | heh that's an error nobody likes to see | 19:13 |
| RainCT | hi | 19:14 |
| pochu | jdong: but is that gcc's problem, right? or is it gstreamer? | 19:15 |
| pochu | heya RainCT | 19:15 |
| jdong | pochu: well on planet Utopia, nothing in source code one does should *ever* be able to cause that compiler error | 19:15 |
| pochu | hmkay | 19:16 |
| === davro is now known as davromaniak | ||
| jdong | pochu: do people on hppa actually watch movies on their machines? :D | 19:19 |
| zul | ask lamont :) | 19:19 |
| pochu | I don't even know where hppa is used, servers? | 19:19 |
| jdong | pochu: it's used? | 19:20 |
| zul | no seriously ask lamont | 19:20 |
| dhdfoo | the hppa workstations are pretty slow by today's standards | 19:20 |
| imbrandon | dhdfoo: your speaking ot someone on a p200 :) | 19:21 |
| pochu | jdong: hmm... http://launchpadlibrarian.net/10343029/buildlog_ubuntu-hardy-amd64.openvrml_0.15.10-10%7Egaspa1_FAILEDTOBUILD.txt.gz | 19:22 |
| zul | imbrandon: yeah but that is just one of the "computers" you own | 19:22 |
| pochu | looks related, although that one is g++ | 19:22 |
| imbrandon | zul: heh well its my main workstation atm :) | 19:22 |
| jdong | pochu: eep! | 19:22 |
| zul | imbrandon: heh well you suck then ;) | 19:23 |
| nxvl_work | imbrandon: hi!, did send me the e-mail? | 19:23 |
| pochu | that was mentioned in launchpad-users ML, I'll replay to ubuntu-devel-discuss | 19:23 |
| === zen-afk is now known as zenrox | ||
| imbrandon | nxvl_work: actualy i was just writing it now ;) | 19:23 |
| imbrandon | i got really busy yesterday | 19:23 |
| nxvl_work | imbrandon: \o/ | 19:23 |
| nxvl_work | imbrandon: that's ok, sometimes it happends :D | 19:24 |
| imbrandon | :P | 19:24 |
| nxvl_work | imbrandon: how was you daughter's birthday? | 19:24 |
| imbrandon | good good, she had a blast | 19:25 |
| imbrandon | got her first mp3 player ( time for me to load linux on it ) hehe | 19:25 |
| nxvl_work | heh | 19:25 |
| james_w | Does anyone know which transition it is that means many packages need an added Build-Depends on libxext-dev? | 19:40 |
| dhdfoo | hey - I have notes in REVU about some packages that I need to update them for hardy, what exactly is involved in doing this? | 19:43 |
| pochu | dhdfoo: s/gutsy/hardy/ in debian/changelog, I guess. | 19:43 |
| dhdfoo | oh ah | 19:44 |
| dhdfoo | okay :) | 19:44 |
| james_w | and build it in hardy rather than gutsy. | 19:44 |
| james_w | and test it there as well :) | 19:44 |
| dhdfoo | so I should set up a hardy chroot or installation | 19:44 |
| dhdfoo | ok | 19:44 |
| james_w | unfortunately the tools in gutsy have trouble if you ask for a hardy chroot. You can get a gutsy one and upgrade it. | 19:45 |
| dhdfoo | yeah that sounds like a reasonable way to go | 19:46 |
| === Pici` is now known as Pici | ||
| ajmitch | oh dear, norsetto trying to encourage us to actually use a blog | 19:59 |
| jdong | what are those? | 19:59 |
| ajmitch | something that the cool kids use | 20:00 |
| zul | uh...ok... | 20:01 |
| zul | if people want to know what Im doing then they can ask | 20:01 |
| === nuu is now known as nu | ||
| === nu is now known as nuu | ||
| jdong | zul: soo... whatcha doin'? | 20:03 |
| zul | jdong: stuff :) | 20:03 |
| jdong | haha :) | 20:03 |
| erable | Hi, I had created a package and I have a problem with license and copyright for this class (it is in Public Domain). | 20:38 |
| norsetto | ajmitch: hehe, don't say that to my wife ... | 20:41 |
| erable | in debian/copyright, license = domain public ? copyright ? | 20:41 |
| RainCT | erable: do you know who the author is? | 20:41 |
| erable | RainCT: yes but it'snt a valid mail address. | 20:42 |
| slangasek | erable: if it's truly in the public domain, best to put author: $person, and copyright: in the public domain | 20:43 |
| slangasek | erable: but you should be careful that it's truly in the public domain; for instance, it's my understanding that authors in Europe can't assign works to the public domain | 20:43 |
| DaveMorris | also public domain starts after a certain time in different countries | 20:44 |
| DaveMorris | eg those guitar tabs in Cananda | 20:44 |
| erable | I think it is in the public domain: http://sourceforge.net/projects/qextserialport/ | 20:45 |
| slangasek | DaveMorris: the "after a certain time" is so long in all relevant countries that no programs we ship are covered by it, so it would have to be some really old data... | 20:45 |
| mok0 | I just read the guidelines for new packages. I didn't realize you have to open a needs-packaging bug in LP | 20:46 |
| erable | Thanks | 20:48 |
| slangasek | erable: I'm afraid that I would assume these authors are European, and therefore a statement of "public domain" is not legally binding; I would suggest trying to contact them somehow and ask for an explicit license | 20:49 |
| mok0 | It seems noone has ever submitted such a bug | 20:49 |
| ajmitch | norsetto: oh? :) | 20:50 |
| erable | slangasek: Ok, I'll do. Thanks | 20:50 |
| norsetto | ajmitch: I lost count of how many she has .... | 20:51 |
| mok0 | ajmitch: We are considering migrating our systems from nis to ldap. Is that possible with gutsy? | 20:57 |
| === Adri2000_ is now known as Adri2000 | ||
| ajmitch | mok0: just with migration-tools | 21:02 |
| mok0 | ajmitch: thx I'll check it out | 21:03 |
| RainCT | Adri2000: a short guide on how to get DaD working on local computer would be awesome :P | 21:20 |
| TheMuso | /c/c | 21:20 |
| TheMuso | ugh | 21:20 |
| erable | Hi, What is this linda Warning : The library libqextserialport has a different SOVER versus the shlibs file ? | 21:25 |
| slangasek | erable: did you create a shlibs file by hand? | 21:27 |
| erable | slangasek; yes. | 21:27 |
| erable | slangasek: Here: http://revu.tauware.de/revu1-incoming/qextserialport-0711072120/qextserialport-1.1/debian/ | 21:29 |
| slangasek | erable: ok; why did you create it by hand instead of using dh_makeshlibs? e.g., "dh_makeshlibs -V 'libqtextserialport (>= 1.1)'"? | 21:31 |
| slangasek | er, "libqext" of course, not "libqtext" | 21:32 |
| slangasek | erable: anyway, what do you get if you run objdump -p /path/to/library | grep SONAME? | 21:34 |
| slangasek | (I don't see anywhere in the upstream source where this is set...) | 21:34 |
| proppy | librsvg != libsvg ? | 21:38 |
| erable | slangasek: SONAME libqextserialport.so.1 | 21:39 |
| slangasek | erable: ok, then I conclude it's a bug in linda :) | 21:39 |
| erable | cool :) | 21:40 |
| * StevenK grumbles | 21:40 | |
| StevenK | Linda probably correctly concludes 1 != 1.1 and then complains | 21:41 |
| slangasek | huh? | 21:41 |
| slangasek | libqextserialport 1 libqextserialport1 (>= 1.1) | 21:41 |
| LordKow | i dont need to mention changes done via MOM do I? they're debian/ stuff like changing maintainer, changing a build-depend. these were all done in the last ubuntu release MOM simply refreshed them in the merge | 21:41 |
| slangasek | the sover field there is "1" | 21:41 |
| slangasek | the shlibs look correct, and they match the soname of the lib; so linda is wrong | 21:42 |
| StevenK | slangasek: That was a pure guess without looking at Linda's code | 21:42 |
| StevenK | slangasek: But my point is that 1 != 1.1, and Linda is parsing something wrong somewhere | 21:42 |
| slangasek | LordKow: when you write a changelog entry for an updated merge, you should re-list the changes that are outstanding wrt upstream (Debian or otherwise) | 21:43 |
| slangasek | StevenK: ok, as long as we agree it's a linda bug :) | 21:43 |
| LordKow | slangasek, so this would include changes to the debian directory done by MOM too? | 21:43 |
| slangasek | LordKow: MoM doesn't "do" changes to build-depends, it just merges the changes which were previously done; so those are precisely the kind of changes you should be listing, yes | 21:44 |
| slangasek | changes to the maintainer field generally don't get listed more than once, from what I've seen | 21:45 |
| LordKow | yea exactly, a build-depend was changed in the last ubuntu release. MOM merged this change into the new version. i will go ahead and mention the "change" against debian (even though its not a NEW change) | 21:45 |
| StevenK | slangasek: So, what does it mean when an Alpha keeps spewing register contents and "Not tainted" ? | 21:47 |
| slangasek | StevenK: it means a kernel problem mmkay | 21:47 |
| slangasek | :) | 21:47 |
| erable | Thanks slangasek and StevenK :-) | 21:47 |
| StevenK | slangasek: It looks like only 2 lines, and it isn't stopping, which makes me not suspect the kernel. | 21:47 |
| LordKow | okay should the Maintainer be a specific person, or should it be Ubuntu MOTU Developers? | 21:48 |
| LordKow | this is an ubuntu universe package and the maintainer was set to a person (not Ubuntu MOTU) | 21:48 |
| StevenK | slangasek: Okay, now it's readable "CIA Machine check: vector=0x630" | 21:50 |
| * StevenK sighs, as he suspects memory | 21:50 | |
| * StevenK tars up stuff quickly | 21:51 | |
| StevenK | Grumble. I suspect one of the SIMMs has died | 21:53 |
| LordKow | i know a lot of ubuntu devs will grumble when i say this but I think they should file bug reports for all of the merges they are doing too :) | 21:55 |
| StevenK | Uh huh | 21:56 |
| StevenK | LordKow: That doesn't scale | 21:56 |
| slangasek | file bug reports why? | 21:56 |
| slangasek | StevenK: isn't CIA the crappy IDE controller? | 21:57 |
| LordKow | so the contributors dont do it too. however, i just realized the dev doing the merge would be notified of the bug report and would (hopefully) be quick to respond to the bug report | 21:57 |
| StevenK | slangasek: I hope not, since this thing doesn't have an IDE controller. :-) | 21:58 |
| slangasek | heh | 21:58 |
| StevenK | slangasek: It's an Alcor, if that helps any | 21:58 |
| StevenK | slangasek: The other clue that it's memory is "correctable ECC error" | 21:59 |
| StevenK | slangasek: I can pastebin one or two if you want to see now that I can actually ssh to the machine | 22:00 |
| mathiaz | StevenK: can I merge the icecast2 package ? | 22:03 |
| StevenK | mathiaz: Sure, mainly because I've not looked at it | 22:04 |
| mathiaz | StevenK: well - you're the last one that touched it (IIRC) | 22:04 |
| StevenK | Hrm. /srv, /etc/apache2, /usr/local/lib. I think that covers everything | 22:04 |
| StevenK | mathiaz: Right, probably because it depended on a transition | 22:05 |
| mathiaz | StevenK: yes. it was the libcurl3 -> libcurl4 transition. | 22:05 |
| LordKow | do we (ubuntu) use debian's upstream categories in .desktop files? debian changed their categories apparently. I'm not sure if we're synched with them or using our own categories | 22:05 |
| StevenK | mathiaz: Please don't say 'libcurl' around me :-) | 22:06 |
| * StevenK shivers | 22:06 | |
| LordKow | "- updated “Category” field “Application;Graphics;” to “Graphics;3DGraphics;”." (debian) | 22:06 |
| pochu | LordKow: I'd say yes, go for it. | 22:07 |
| pochu | Isn't Application deprecated? | 22:07 |
| pochu | (so that'd be why they changed it) | 22:07 |
| LordKow | okay. so would that create a shortcut in the Graphics->3DGraphics folder or is it merely an internal categorical thing? | 22:08 |
| LordKow | er not folder, but menu. | 22:08 |
| pochu | nope, It will remain as Graphics afaik | 22:08 |
| LordKow | okay so my final problem with this merge is setting the Maintainer. should I just keep it as it was in the previous ubuntu package? | 22:10 |
| LordKow | i was under the impression that all universe packages should have Maintainer set as "Ubuntu MOTU Developers" but I gues that is not the case | 22:11 |
| pochu | LordKow: who is the old one? | 22:11 |
| pochu | LordKow: that's the usual practice, but there are exceptions... | 22:11 |
| LordKow | +Maintainer: Lukas Fittl <lfittl@ubuntu.com> | 22:12 |
| * pochu doesn't know then | 22:12 | |
| imbrandon | LordKow: no all ubuntu packages must have @ubuntu.com address as the maintainer | 22:12 |
| imbrandon | most just fall into the MOTU email though | 22:12 |
| pochu | imbrandon: if it's a merge it should, shouldn't it? | 22:12 |
| pochu | as per spec... ;) | 22:12 |
| imbrandon | per spec says an @ubuntu.com address that is all | 22:13 |
| LordKow | https://launchpad.net/ubuntu/+source/blender | 22:13 |
| pochu | imbrandon: and you said not all need an @ubuntu.com address :) | 22:13 |
| pochu | oh | 22:13 |
| pochu | no, all... | 22:13 |
| imbrandon | correct | 22:14 |
| pochu | I read 'not all' :-) | 22:14 |
| LordKow | if all need an ubuntu address im not sure how contributors would ever be able to do merges ;) | 22:14 |
| * pochu shuts up :( | 22:14 | |
| pochu | LordKow: ubuntu-motu@lists.ubuntu.com ;) | 22:14 |
| imbrandon | LordKow: if you dont have a @ubuntu.com address is when you change it to the MOTU field | 22:14 |
| StevenK | LordKow: Then they set to Ubuntu MOTU Developers like 99% of the packages should be. | 22:14 |
| LordKow | okay, i will set Maintainer accordingly | 22:15 |
| === `23meg is now known as mgunes | ||
| LordKow | oh good thing I saw this, do we use the Uploaders field in control or shall I leave it as the debian uploaders? | 22:18 |
| Kmos | LordKow: leave it there if there is one from debian | 22:19 |
| LordKow | k :) | 22:19 |
| LordKow | danke | 22:19 |
| slangasek | StevenK: I'm not particularly familiar with Alcor, sorry | 22:22 |
| StevenK | slangasek: I think the time has come for me to shift services to another machine anyway :-) | 22:24 |
| TheMuso | How long as cdbs been symlinking things like docs and changelogs between packages, even though they are dependent on each other? | 22:28 |
| TheMuso | And, should such warnings from lintian as: W: libglibmm-utils-dev: debian-changelog-file-is-a-symlink be ignored? | 22:28 |
| slangasek | TheMuso: even though they are, or even though they aren't? | 22:30 |
| TheMuso | slangasek: I've got a source package I'm looking at on revu, that uses cdbs, and creates two shared library packages, and two dev packages. One shared library package has the changelogs and docs etc, and all 3 others have symlinks pointing to the parent libs doc dir, since all the other packages depend on this one parent lib. | 22:32 |
| TheMuso | if that makes sense... | 22:32 |
| TheMuso | So I'm wondering whether I should ignore the above lintian warning. | 22:32 |
| slangasek | so you mean "when they are dependent on each other", rather than "even though they are dependent on each other"? | 22:32 |
| imbrandon | slangasek: those mean the same thing ... | 22:33 |
| slangasek | er, no? | 22:33 |
| LordKow | <sarcasm>I loooveee undocumented command line parameters | 22:33 |
| TheMuso | slangasek: Yeah. | 22:34 |
| slangasek | TheMuso: so to answer that question, then, it's been doing that a month and two days :) | 22:36 |
| TheMuso | slangasek: Right, so those warnings can be safely ignored I presume. | 22:36 |
| slangasek | TheMuso: is the dependency between these packages strictly versioned? | 22:39 |
| slangasek | TheMuso: if so, then yes; if not, I would suggest making it strictly versioned, so that you never have to worry about your packages not matching the changelog (or other docS) | 22:40 |
| TheMuso | slangasek: Not everything is strictly versioned, I'll make a note of that to the package uploader, thanks. | 22:42 |
| LordKow | blender devs really need to clean up their code. i think their is a compiler warning for every line of blender code | 22:57 |
| Burgundavia | they also need a UI, one that doesn't like the 90s | 22:58 |
| huats | norsetto: Hey | 23:09 |
| norsetto | huats: heilá | 23:09 |
| huats | just to let you know that the modification in tagtool works... | 23:10 |
| huats | is it enough or do you need an email attesting it ? | 23:10 |
| norsetto | huats: yes, we need a +1 comment | 23:11 |
| norsetto | huats: mercí! | 23:12 |
| huats | :) | 23:12 |
| huats | norsetto: done | 23:13 |
| norsetto | huats: much obliged | 23:14 |
| huats | :) | 23:15 |
| huats | do you also need the mono-addins test ? | 23:15 |
| norsetto | huats: hope you didn't leave any trace of tomato sauce on the report ... | 23:15 |
| huats | LOL | 23:15 |
| huats | no, but in my stomach | 23:15 |
| huats | there is much more | 23:15 |
| huats | :) | 23:15 |
| huats | (I had to finish yesterday ones) | 23:15 |
| RainCT | good night | 23:19 |
| LordKow | nooooo if my backlight is going out im not going to be happy. im not sure how much Dell will charge but im guessing it will be copious amounts of money for a screen replacement | 23:23 |
| norsetto | night all | 23:35 |
| * TheMuso kicks proftpd-dfsg. | 23:39 | |
| StevenK | proftpd has files that can't be redistributed? Who knew. | 23:40 |
| TheMuso | StevenK: Its not that. The Debian package ships with a module that doesn't want to load at proftpd startup, and so far, I can't work hout how to fix it, other than disabling the module, which I'd rather not do, as so far as I know, its language related. | 23:41 |
| slangasek | s/can't be redistributed/aren't available under DFSG terms/ | 23:41 |
| TheMuso | So, the Debian package is broken, and I don't want to ship a broken package. | 23:41 |
| StevenK | Ha! | 23:45 |
| StevenK | Retribution! | 23:45 |
| s1024kb | proppy: good morning | 23:46 |
| proppy | s1024kb: hi ! | 23:47 |
| proppy | s1024kb: good night :) | 23:47 |
| s1024kb | proppy: wanna ask you a question: now i had finished a merging, want to report the bug, i see the package is already on the list, is it i should select that one? | 23:48 |
| TheMuso | Oh yay! Its a symbol load error. The module builds, but obviously doesn't have a needed symbol. | 23:49 |
| proppy | s1024kb: which list? | 23:50 |
| proppy | s1024kb: (also I'm not a MOTU, so maybe I'm not the best person to ask to :) | 23:50 |
| s1024kb | proppy: https://launchpad.net/ubuntu/+filebug | 23:51 |
| proppy | oh ok | 23:52 |
| proppy | you want to report a bug | 23:52 |
| proppy | and someone already reported it right ? | 23:52 |
| proppy | you need to purpose your work as a comment then | 23:53 |
| s1024kb | proppy: yes | 23:53 |
| proppy | and look forward coordinating with the person currently working on | 23:53 |
| proppy | depending of the status | 23:53 |
| proppy | and the assignee | 23:53 |
| s1024kb | proppy: the status is "fixed released", and the assignee is \sh, our friend | 23:55 |
| s1024kb | proppy: should i choose this bug and "add a comment"? | 23:56 |
| proppy | it means it has already been taken care of | 23:56 |
| proppy | you should coordinate with \sh_away | 23:56 |
| proppy | who is currently away | 23:56 |
| proppy | can you past me the bug number ? | 23:56 |
| s1024kb | proppy: haha no problem, i will see him this afternoon. #17221 | 23:57 |
| proppy | bug #17221 | 23:58 |
| ubotu | Launchpad bug 17221 in ubuntu "yappy: new changes from Debian require merging" [Wishlist,Fix released] https://launchpad.net/bugs/17221 | 23:58 |
| proppy | s1024kb: you should check with your mentor what you need to do | 23:58 |
| proppy | for that not to happen again | 23:58 |
| proppy | maybe checking for the bug report in the first time, and dropping a comment telling you're on it | 23:59 |
| proppy | won't have result in a duplicate work | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!