[00:14] <mrmojo> hi guys
[00:14] <fagan> mrmojo: hello
[00:14] <mrmojo> i am looking to get the source code for software-properties-gtk
[00:15] <mrmojo> specifically the version shipped in karmic
[00:15] <mrmojo> what's the best way to go about to get that
[00:15] <fagan> launchpad has everything ill get you a bzr for it
[00:16] <mrmojo> cheers man
[00:18] <fagan> mrmojo: here is a tar.gz https://edge.launchpad.net/ubuntu/karmic/+source/software-properties/0.75.4/+files/software-properties_0.75.4.tar.gz
[00:18] <fagan> go nuts :)
[00:19] <mrmojo> thanks
[00:19] <fagan> mrmojo: np
[00:24] <mrmojo> is there an IRC channel that I could join to ask questions about the source for this?
[00:24] <mrmojo> I'm not sure if it's a GNOME project or just Ubuntu-specific heh
=== asac_ is now known as asac
[00:32] <mrmojo> right i think I've fixed my 'bug', could someone point me to a guide on how to repackage my changes
[00:33] <feasty> I'm looking for some information on becoming a developer for Ubuntu. The wiki pages talks about starting a prospective developer by fixing bugs and working on new packages. If I were to look at working on a new package would it have to be a new package I have chose or is there a list of suggested packages I could choose from? I'm just looking at what I need to do to get myself started really. Can anyone help me?
[00:35] <RAOF> feasty: We need fixing bugs much more than we need new packages; unless there's some software that you'd really like to see in Ubuntu that isn't yet, there's no need to look at adding new packages.
[00:36] <feasty> RAOF: No I am happy fixing bugs.
[00:37] <RAOF> Excellent!
[00:38] <feasty> Where can I go to pick up a bug to fix? Launchpad?
[00:40] <fagan> mrmojo: ask here on monday for the dev in charge of that package and they will be able to help you
[00:40] <fagan> They can push the fix for you
[00:41] <mrmojo> It's actually not a fix for ubuntu
[00:41] <mrmojo> it's a fix for linux mint
[00:41] <mrmojo> though the bug has been marked as invalid
[00:41] <mrmojo> it's more of a fix for myself heh
[00:41] <lifeless> fagan: huh? you don't need to wait for a specific dev; just do the fix and propose it for merging.
[00:41] <lifeless> fagan: many devs are volunteers too
[00:41] <fagan> lifeless: true
[00:42] <fagan> very true since im one
[00:42] <fagan> mrmojo: id say if you tar.gz it someone in linux mint might package it for you
[00:43] <fagan> its a complicated process
=== bdefreese2 is now known as bddebian
[00:44] <mrmojo> ok
[01:27] <George_E> What package provides the opengl headers?
[02:11] <ebroder> Does anybody have any thoughts on bug #426614? binutils-dev is certainly very clear that nothing should link libbfd dynamically, and it seems we've discovered why
[02:11] <ubottu> Launchpad bug 426614 in oprofile "oprofile should not link libbfd dynamically" [Low,New] https://launchpad.net/bugs/426614
[02:12] <ebroder> I like Anders' patch and think it should be uploaded, but the decision almost feels out of scope for me to make on my own
[02:13] <ebroder> (Especially given fabricesp's objections)
[04:58] <ebroder> So...is there a standard response for the asshole-Debian-maintainer-who-doesn't-think-he-should-care-about-Ubuntu?
[05:00] <ScottK> ebroder: Ignore it.  You probably aren't going to change his mind.
[05:00]  * ebroder sighs
[05:05] <ScottK> ebroder: Over time, the fraction of Debian maintainers that react that way has declined.  Just give the factors that are at work more time.
[05:06] <ScottK> Additionally, he's perfectly within his rights not to worry about Ubuntu.
[05:06] <ebroder> I supposethat's true
[05:06] <ebroder> (I guess the rest of his reply was both civil and valid, even if I don't like it)
[05:09] <ebroder> I suppose the more productive question is this: is there anywhere that I can make a note that will be seen and respected that erlang should never be synced from Debian without a corresponding sync of erlang-doc?
[05:10] <ebroder> (I'd be OK with "never" applying only to manual post-DIF syncs)
[05:11] <StevenK> ebroder: That's very difficult if erlang has no Ubuntu changes
[05:12] <ebroder> Yeah, it doesn't, but this breakage has happened for the last two Ubuntu releases (erlang-doc doesn't get synced along with erlang, which makes the erlang-doc packages uninstallable because of the incredibly harsh conflicts in erlang)
[05:13] <StevenK> ebroder: Then you should file a seperate bug a few days later asking that -doc be sync'd?
[05:13] <ScottK> ebroder: Mostly someone needs to watch out for this stuff.  We have tools for uninstallable package detection that should show this.  Also this is potentially SRU worthy, so it can perhaps be fixed post-release if needed.
[05:13] <ebroder> StevenK: I don't personally care about the package - I'm just trying to come up with some way to prevent the breakage going forward
[05:14] <StevenK> ebroder: Read as, I'm not sure how the archive admins can help, without us having to special case erlang
[05:14] <ebroder> ScottK: Ok. I may try to pull Jaunty and Karmic SRUs together at some point in the near future
[05:16] <ScottK> StevenK: A check could, if someone contributed the patch, probably be put into MoM to make erlang-doc appear if it needed to be sync'ed.
[05:18] <ScottK> Perhaps ebroder would be motivated to provide it?
[05:19] <ebroder> Perhaps. Where is the source?
[05:21] <ScottK> ebroder: merge-o-matic project on Launchpad.
[05:21] <ebroder> Ok - I'll check it out
[05:26] <ebroder> Actually, I'll start by filing a bug - that way if I don't get to it now, at least it won't be forgotten
[06:13] <shankhs> hi i have changed prism to get prism-orkut , and i would like to make .deb package and put it in the repos.I have one problem i have never done such things and i want to learn any help?
[06:14] <ebroder> shankhs: I'm not sure it makes sense for Ubuntu to ship prism apps for specific websites. How do we choose which websites to include apps for?
[06:18] <shankhs> ebroder: you have a point but i am using this package to learn how to make  a .deb package and put it in the ubuntu repos.If thats not permitted then its fine.
[06:19] <ebroder> shankhs: I just think it's unlikely that such a package would be approved for being added to Ubuntu
[06:20] <shankhs> ebroder: ok
[06:20] <shankhs> ebroder: but i really want to learn
[06:20] <shankhs> any suggestions?
[06:20] <shankhs> :(
[06:21] <ebroder> shankhs: You could check out https://wiki.ubuntu.com/UbuntuDevelopment/
[06:21] <ebroder> There's a lot of docs being put together there
[06:22] <shankhs> ebroder: thanx i hope you guys do not get disturbed by noobs like me. :)
[06:22] <ebroder> shankhs: Not at all - we could always use more help. I'm just a little distracted at the moment because I'm about to go to sleep
[06:23] <shankhs> ebroder: ok good night
=== Guest87841 is now known as Zic
=== Zic is now known as Guest81151
=== Guest81151 is now known as Zic
[08:52] <shiki-> hi all
[08:52] <shiki-> any active dev who can give me a little help?
[08:54] <shiki-> well... when someone will be here: I get an error when I try to prepare a package for PPA upload. I got some PPA aldy, but I cant figure this error out. It gives : "debuild: fatal error at line 1334: \ dpkg-buildpackage -rfakeroot -d -us -uc -S -sa failed" when I use the "debuild -S -sa" command.
[08:54] <shiki-> I just need some hint where can I find that line 1134
[08:54] <shiki-> *1334
[08:55] <shiki-> ah lol ... wrong channel -.-
=== Zic_ is now known as Zic
=== Zic is now known as Guest40040
[09:01] <hyperair> +3 and that would be 1337
[09:01] <hyperair> he was so close..
[09:01] <maco> hahaha
[09:02] <maco> i dont even understand what happens on line 1334 of debuild
=== Guest40040 is now known as Zic
[09:02] <maco> (or really much of what debuild does at all)
[09:03] <hyperair> nor do i
[09:14] <cjwatson> Laney: oh, prod james_w at some point if it's out of date, or file a bug on the udd project
[09:15] <cjwatson> shiki-: line 1334 of debuild is not significant, it's just where it happens to do the error detection for subprocesses: in this case the real failure is in dpkg-buildpackage, and should have been output a little bit further up, so you'll need to read the output with care and judgement
[09:16] <shiki-> cjwatson: I found the problem already. Thanks for the description though. It was a typo/problem in the debian/changelog
[09:16] <shiki-> and sorry for messing in the wrong channel. :)
[09:30] <fqh> Hi, can anyone connect to network wth ADSL under ubuntu9.10?
=== fabrice_sp_ is now known as fabrice_sp
=== azeem_ is now known as azeem
[13:23] <xee> Hi, is there a channel where I can ask about packaging?
[13:23] <azeem> xee: #ubuntu-motu
=== emma_ is now known as emma
[14:29] <asac> kees: https://svn.pardus.org.tr/pardus/2009/stable/system/devel/gcc/files/note-gnu-stack.dpatch ...
[14:29] <asac> everywhere its +.section.note.GNU-stack,"",@progbits
[14:29] <asac> but on arm its
[14:29] <asac> +.section.note.GNU-stack,"",%progbits
[14:29] <asac> kees: any idea?
=== LucidFox_ is now known as LucidFox
[18:16] <asac> kees: unping. we figured it a while ago ...
[18:44] <youssef> Good evening. Anyone knows something about the fop bug (310882)?
[18:57] <youssef> see you later
=== markus__ is now known as thekorn
=== stgraber_ is now known as stgraber
[20:22] <YokoZar> mdz: I'm trying to remember what the policy was going to be regarding upstart jobs that we discussed at UDS.  Was it that start/restart should never fail (even with bad config), or that package install should never fail (even with a failing upstart job)?
[20:23] <mdz> YokoZar, I am of the opinion that maintainer scripts which fail due to transient error conditions are usually not best
[20:23] <mdz> and even some permanent ones, e.g. a daemon failing to start because something is wrong with its configuration
[20:24] <YokoZar> mdz: so something like start procps || true in the script?
[20:25] <mdz> YokoZar, unless something later in the maintainer script will fail in bad ways due to the daemon (or non-daemon in this case) failing, yes, that's what I would do
[20:25] <mdz> but this is not a policy, just my view
[20:25] <mdz> I have heard that slangasek has a different view
[20:25] <mdz> (for example)
[20:25] <YokoZar> Well one problem is that we don't have a good way of notifying the user that their daemon is failing
[20:25] <mdz> seems like a reasonable topic to chat with the TB about
[20:26] <YokoZar> and in this particular case we're responsible for the bad configuration somehow (haven't figured out where exactly, but no one manually modified sysctl.d here)
[20:26] <YokoZar> but yeah I agree ~ technical board
[20:26] <mdz> YokoZar, a bunch of errors from apt is not a very good way either ;-)
[20:27] <YokoZar> This is definitely true :)
[20:43] <YokoZar> mdz: I see you put it on the agenda for the technical board.  Thanks :)
[22:27] <kees> asac: what was the solution?  I'd like to add it to the top of https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
[22:28] <asac> kees: on arm @... is a asm comment ... so use %prog... and %object instead
[22:28] <asac> like:
[22:28] <asac> .section        .note.GNU-stack, "", @progbits
[22:28] <asac> ->
[22:28] <asac> .section        .note.GNU-stack, "", %progbits
[22:29] <kees> asac: interesting.  does %progbits work on non-arm (i.e. switch to using % everywhere instead of @?)
[22:30] <asac> i tried it and checked with readelf ... worked here on x86 ... but mybe double check
[22:31] <kees> ok cool, I'll updated instructions.
[22:32] <kees> s/ed/e/
[22:32] <asac> kees: yeah. but plesae double check ... i am not really familiar with this topic ;)
[22:32] <nixternal> everyone have their Google Waves right? I have 15 invites all of a sudden to hand out
[22:33] <kees> asac: it's possible that ARM is just doing the right thing regardless.
[22:33] <kees> asac: I will double-check
[22:34] <asac> kees: on ARM %progbits is definitly right (according to binutils doc)
[22:34] <asac> not so sure about other archs
[22:35] <asac> but i think it just does the right thing on those
[22:36] <kees> asac: which section of the gas docs talk about it?
[22:36] <kees> I'm reading http://sourceware.org/binutils/docs-2.20/as/index.html at the moment
[22:37] <asac> http://sourceware.org/binutils/docs-2.20/as/Section.html#Section
[22:37] <asac> "ote on targets where the @ character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the % character."
[22:37] <asac> kees: ^
[22:38] <asac> but i changed it and tried the same stuff on x86 ... and readelf looked identical
[22:38] <asac> so i assume that it at least works on x86* stuff
[22:38]  * kees nods
[22:38] <asac> (the % that is)
[22:48] <kees> asac: confirmed.  % is also what gentoo recommends.  I've updated the documentation.  thanks for finding that!
[22:48] <asac> welcome!
[22:48] <asac> thanks to chromium ;)
[22:49] <asac> i think that gas docs could be more clear ;)
[22:49] <asac> where what works ;)
[22:49] <asac> and if nothing works everywhere do something like here: http://sourceware.org/binutils/docs-2.20/as/Type.html#Type
[23:11] <George_E> Im having trouble getting dpkg_shlibdeps working. How do you have it put the Depends: info right into the control file?
[23:14] <RAOF> George_E: This is probably better in #ubuntu-motu, but it semes quiet enough here ATM.  You have ${shlibs:Depends} in the Depends: line, and that'll get replaced by the appropriate dependencies.
[23:16] <George_E> What args do I pass? When I did it it put the stuff in a file shvars
[23:16] <RAOF> George_E: You should be able to just call dh_shlibdeps, and it should do everything for you.
[23:17] <George_E> Ooh. Ok.
[23:17] <RAOF> Although context might be important if you're doing something more complicated than "I want to fill in the dependencies of my app package"
[23:18] <George_E> No. I just wanted to avoid copying and pasting.
[23:43] <bdrung_> jcastro, kenvandine: b-sides should drop arc-colors and depend on shiki-colors instead. we will probably move the wallpapers into shiki-colors and drop arc-colors. you should rename adblock-plus to xul-ext-adblock-plus (will be the name in lucid and works on karmic, too)