[00:28] <rjune_> hefe_bia__: cat /etc/lsb-release will clue you in to the version in the chroot
[03:36] <nellery> emgent: is UTU manually updated?
[03:38] <emgent> nellery: auto-updated.
[03:39] <coppro> is there any way to see what packages were installed recently?
[03:39] <emgent> check every 10 min
[03:39] <coppro> no, to my computer
[03:39] <coppro> my compiz skydome broke and I have no clue what broke it; I need to see what packages have been updated
[03:39] <emgent> coppro: please use #ubuntu
[03:39] <nellery> emgent: okay, thanks
[03:39] <emgent> nellery: np.
[03:39] <coppro> ok
[03:41] <coppro> also, the dhcp3 packages are in main and universe, yet display an "All rights reserved" message. This doesn't seem right.
[04:13] <artfwo> hello! guys, i have a question on debhelper compability: I want to use some v7 features, like dh_lintian - but will the package build on ubuntu 8.04 with those?
[04:14] <RAOF> artfwo: Yes; debhelper has been backported.
[04:14] <RAOF> artfwo: And the only way for new packages to get to Hardy is through backports, so...
[04:14] <artfwo> then PPA build system includes v7 as well?
[04:15] <LaserJock> artfwo: I don't think so
[04:15] <RAOF> Good question.  I don't think the PPAs do build against backports.-
[04:19] <artfwo> sadly, but true. just checked the build logs - it only uses -updates and -security
[04:19] <jdong> no they don't build against backports :)
[04:19] <jdong> I would have a lot more people screaming at me if it did
[04:19] <coppro> why?
[04:19] <LaserJock> jdong: for sure
[04:20] <LaserJock> 1) building against things that not a everybody is likely to have is not a good idea
[04:21] <LaserJock> 2) -backports has potential to have real changes that would affect packages, different cmake and Qt4 version for instance
[04:21] <coppro> hmm... ah
[04:22] <artfwo> okay, I guess I'll stick with manual installation of lintian_overrides then
[04:23] <artfwo> thanks everyone for your help!
[04:24] <coppro> so, anyone know why a main/universe package is displaying an "all rights reserved" message?
[04:25] <LaserJock> where is it displaying it?
[04:26] <artfwo> yes, there is quite a number of such notices - in libicu for instance
[04:26] <ajmitch> :0:> less /usr/share/common-licenses/BSD
[04:26] <ajmitch> Copyright (c) The Regents of the University of California.
[04:26] <ajmitch> All rights reserved.
[04:26] <coppro> that's the license though
[04:27] <coppro> not the program
[04:27] <coppro> (any dhcp3 program in this case)
[04:29] <coppro> just run it and it says "Copyright 2004-2008 Internet Systems Consortium"
[04:29] <coppro> "All rights reserved"
[04:30] <artfwo> I have another question on sourcepkg compability: Lintian on Intrepid gives the warning "out-of-date-standards-version 3.7.3 (current is 3.8.0)" - is it okay to update the policy to 3.8.0 if I'm going to build the package on Hardy as well?
[04:31] <ajmitch> why is the "All rights reserved" an issue?
[04:31] <ajmitch> from what I can see, it used to be required or at least expected in order to assert copyright
[04:32] <ajmitch> anyway, I have to run
[04:32] <LaserJock> it's no longer required according to wikipedia, but is still seen regularly
[04:34] <coppro> all rights are clearly not reserved; there's a license
[04:34] <coppro> that allows me to distribute it
[04:34] <LaserJock> but I think they are saying they are reserving their rights to say how it is licensed, not sure about that though
[04:35] <LaserJock> i.e. the default is full copyright with all rights reserved, *then* you poke holes in it with the license
[04:35] <coppro> well, I wouldn't expect any program to say that I can't copy it if it's in main
[04:37] <LaserJock> coppro: I don't think it *is* saying that
[04:37] <coppro> the program, as run, provides no exception
[04:37] <coppro> which at least implies that I can't copy it
[04:37] <ScottK-laptop> artfwo: First, don't update the standards version unless you actually update the package to meet that standard.  Generally if it's a package we get from Debian, you shouldn't change it.
[04:38] <ScottK-laptop> There's really no point in updating it for Hardy in any case.
[04:38] <ScottK-laptop> Often you can just ignore that warning.
[04:38] <LaserJock> coppro: it's MIT licensed
[04:38] <artfwo> ScottK-laptop: okay, thanks
[04:39] <coppro> LaserJock: the program implies the exact opposite
[04:39] <ScottK-laptop> coppro: The way I think we are supposed to interpret "All Rights Reserved" is All rights not explicitly given away.
[04:39] <ScottK-laptop> It's any implicit rights.  Not the ones enumerated.
[04:39] <coppro> ok, fair enough. Then it should enumerate the rights when run, if it says All rights reserved
[04:40] <ScottK-laptop> There is no implicit right to say you can't run it (except AGPL explicitly says you need to meet certain conditions).
[04:40] <coppro> to run, yes
[04:40] <coppro> but I think, personally, that the text is misleading
[04:41] <LaserJock> it's maybe not the clearest, but I don't think it's necessarily wrong
[04:45] <ScottK-laptop> coppro: I'm not a fan of it, I agree it's confusing, but it's quite common.  It used to be required (it's not anymore) and the practice lingers through inertia and folklore.
[04:46] <coppro> well, removing it or adding another line about the license is a simple patch
[04:46] <coppro> but part of it is in main, so I guess it's up to canonical
[04:47] <LaserJock> coppro: just because it's in Main doesn't mean Canonical has to do it
[04:48] <LaserJock> it means a Core Dev needs to sponsor a patch
[04:48] <coppro> ok.
[04:49] <ScottK-laptop> Note that both the people you are discussing this with are core-dev and neither works for Canonical.
[04:50] <StevenK> Both of those can be fixed. :-P
[04:51]  * coppro is not very familiar with the system, then
[04:52] <LaserJock> coppro: that's ok, we're all here to learn
[04:52] <coppro> some more than others, clearly
[04:52] <coppro> oh right, I have an important question
[04:53] <coppro> is a copyright notice really required in every source file if the package is distributed with such a notice?
[04:54] <LaserJock> usually there is a "header" for each file
[04:54] <coppro> yeah, the package I'm packaging doesn't have such a thing
[04:54] <LaserJock> a quite common occurance is for somebody to say license the program as GPL and forget the a couple files are actually Academic-only or something
[04:54] <coppro> none of the files have any such license
[04:55] <LaserJock> so having it in every file helps us to make sure the license is correct
[04:56] <ScottK-laptop> coppro: My experience is that as long as there is a LICENSE or COPYING file in the source tarball that has the full license in it, the archive admins will hold their nose and accept it.  It MUST have the full license in it though and it should be in every file.
[04:57] <coppro> there's a file license.terms with an MIT license in it; I've been told by some sources that isn't enough
[05:00] <tonyyarusso> Erm, do any of you geniouses know where I could get help on hostname resolution with avahi?  I seem to be stumping everyone I find (or just confusing them).
[05:02] <ScottK-laptop> It's supposed to just magically work.
[05:02] <tonyyarusso> well, it works, just not the way I want it to
[05:03] <jmarsden> Does anything at http://avahi.org/wiki/Avah4users help?
[05:03] <tonyyarusso> jmarsden: perhaps - hadn't seen that yet
[05:03] <jmarsden> A quick Google found it for me... hopefulyl it will help.
[05:09] <\sh> so...it's 6am in germany...and we are finished with our nightshift...time for a beer...
[05:28] <quentusrex> Can someone help me debug something?
[05:29] <quentusrex> ls
[05:29] <jmarsden> quentusrex: ls works, it does not generally need debugging?
[05:29] <quentusrex> haha,
[05:30] <quentusrex> no. I'm trying to install munin with mysql plugin. it's a default plugin in the munin-node package.
[05:30] <quentusrex> but it can't connect to mysql... :(
[05:30] <quentusrex> but I can easily connect manually...
[05:31] <jmarsden> quentusrex: Then most likely it is looking in the wrong place (IP address and port) or using the wrong username/pw for auth.
[05:31] <quentusrex> I've got the user and password correct I'm really sure...
[05:32] <quentusrex> my $MYSQLADMIN = $ENV{mysqladmin} || "mysqladmin";
[05:32] <quentusrex> my $COMMAND    =      "$MYSQLADMIN $ENV{mysqlopts} extended-status";
[05:32] <quentusrex> that is part of the mysql plugin (in perl) that is creating the command
[05:32] <quentusrex> but I run the command manually:
[05:32] <quentusrex> /usr/bin/mysqladmin -u debian-sys-maint -p********* status
[05:32] <quentusrex> and it works.
[05:33] <jmarsden> So what is the env var mysqlopts being set to?
[05:33] <quentusrex> it's on a test lan mysql server so here:
[05:33] <quentusrex> [mysql*]
[05:33] <quentusrex> user root
[05:33] <quentusrex> env.mysqladmin /usr/bin/mysqladmin
[05:33] <quentusrex> env.mysqlopts -u debian-sys-maint -pk3f4nIlErsLzJq8B
[05:34] <jmarsden> OK.  If you change the my $COMMAND line to say  my $COMMAND    =      "echo $MYSQLADMIN $ENV{mysqlopts} extended-status";
[05:34] <jmarsden> does it do what you expect?
[05:38] <quentusrex> it prints 'yes'
[05:39] <quentusrex> Here is the contents of $COMMAND: mysqladmin  extended-statusn
[05:39] <jmarsden> quentusrex: That's not what I would have expected...!  I'll try munin out here, let me install it and see what I find...
[05:40] <quentusrex> it's missing the entire opts part.
[05:40] <jmarsden> That would explain the inability to work...
[05:40] <quentusrex> yup, $ENV{mysqlopts} is blank...
[05:42] <quentusrex> so.... I don't know how to 'fix' that...
[05:47] <quentusrex> alright, found the problem.
[05:47] <quentusrex> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408452
[10:06] <pmjdebruijn> http://revu.ubuntuwire.com/details.py?package=lensfun if somebody has a little time to look at it?
[10:48] <hyperair> i'm trying to package libsigx, but it doesn't seem to have a SONAME. what should i do?
[10:56] <pmjdebruijn> hyperair: why do you need the SONAME?
[10:56] <hyperair> pmjdebruijn: because i'm packaging a library?
[10:56] <pmjdebruijn> hyperair: I ment why do you need it explicitly?
[10:57] <hyperair> hmm i don't?
[10:57] <hyperair> @_@
[10:57] <hyperair> the lib file is /usr/lib/libsigx-2.0.so
[10:57] <pmjdebruijn> hyperair: does build fail? does lintian complain?
[10:57] <hyperair> i'm trying to build
[10:58] <hyperair> lintian..
[10:58] <hyperair> wait
[10:58] <pmjdebruijn> what error do you get while building?
[10:58] <hyperair> W: sigx source: substvar-source-version-is-deprecated libsigx-dev
[10:58] <pmjdebruijn> that's unrelated
[10:58] <hyperair> sorry, i meant the build isn't complete
[10:58] <hyperair> okay, so what does that lintian warning mean?
[10:58] <pmjdebruijn> hyperair: lintian explains it, if you read further
[10:59] <hyperair> gimme a moment
[11:00] <hyperair> aah
[11:00] <hyperair> i see
[11:00] <hyperair> thanks
[11:00] <hyperair> =D
[11:13] <elmargol> someone knows if there is an open bug about linux not supporting fat32 (properly)?
[11:15] <hyperair> what's wrong with linux's fat32 support?
[11:16] <elmargol> I had to copy some files from a pendrive on to my home directory. and the whole system stops working
[11:16] <hyperair> define stops working
[11:17] <elmargol> I removed the stick and after 1-2 minutes the system works again...
[11:17] <hyperair> eh?
[11:17] <elmargol> hyperair: Well the panel stops working, the windows are frozen
[11:17] <hyperair> hmm
[11:17] <hyperair> pastebin your dmesg log
[11:18] <hyperair> it's probably an issue that's not related to vfat
[11:18] <elmargol> have to see if I can find it ... this was 2 days ago
[11:18] <elmargol> I had to reboot to vista in order to copy the data on my disk :(
[11:21] <elmargol> http://paste.ubuntu.com/83931/
[11:23] <hyperair> elmargol: there's something wrong with your pendrive
[11:23] <hyperair> get it checked
[11:23] <elmargol> it is not my pendrive and it works 100% on windows
[11:23] <hyperair> try formatting it again
[11:24] <hyperair> it said Buffer I/O error
[11:24] <hyperair> that means there's a hardware error with your pendrive
[11:24] <elmargol> NOT my pendrive. and I don't have it here. The bug is that it works on windows
[11:37] <hyperair> i'm very sure that if format it in ntfs, it'll have the same issue
[11:37] <hyperair> and in any other file system
[11:53] <pmjdebruijn> elmargol: seriously... high changes are you pendrive is broken somehow...
[11:54] <elmargol> pmjdebruijn: ok explain to my why it works perfect on windows
[11:58] <pmjdebruijn> elmargol: explain to me why I have a hunderd pendrives which work great with Ubuntu
[11:58] <pmjdebruijn> elmargol: maarja, the flash memory itself is fine, the the usb controller in the stick is quasi-broken
[11:58] <pmjdebruijn> as in broken by design
[11:58] <pmjdebruijn> but everything gets tested with Windows (even if it's broken), when it works with Windows it gets a seal of approval, and goes to market
[12:00] <elmargol> thats no excuse
[12:00] <pmjdebruijn> elmargol: huh?
[12:00] <elmargol> a) you unmount the drive and give an error message (and don't freeze the system)
[12:00] <pmjdebruijn> elmargol: I have a hunderd pendrives that just work
[12:01] <pmjdebruijn> elmargol: well that's weird indeed
[12:01] <elmargol> or b) you have some debug mode where it tries to work
[12:01] <elmargol> You can't just leave a user with a frozen system and say well your hardware is shit go away and die
[12:01] <pmjdebruijn> elmargol: it should crash linux, that's true
[12:01] <pmjdebruijn> elmargol: shouldn't
[12:02] <pmjdebruijn> elmargol: but the hardware is probably the root cause
[12:02] <pmjdebruijn> elmargol: linux' fault is just handling is badly
[12:02] <elmargol> well i have this bugs not only on pendrives... if you mount a cifs share and loose your wlan the system hangs too
[12:02] <elmargol> this is a common issue on linux
[12:02] <pmjdebruijn> elmargol: cifs never has been very reliable
[12:03] <pmjdebruijn> elmargol: that why gnome has gnome-vfs... which is not kernel side, and thus can't crash your kernel
[12:03] <elmargol> the kernel does not crash... the applications just wait... and wait and wait...
[12:03] <pmjdebruijn> elmargol: the question is, this usb pendrive issue, did you test with other ubuntu releases
[12:03] <elmargol> and after 20-30 seconds it times out
[12:04] <pmjdebruijn> elmargol: that seems like sane behaviour...
[12:04] <elmargol> the timeout is way to long
[12:06] <pmjdebruijn> elmargol: well file a bug on gnome-vfs
[12:06] <elmargol> pmjdebruijn: I'm using kde
[12:07] <pmjdebruijn> elmargol: then file a bug on the kde counterpart...
[12:07] <elmargol> and this is not kde or gnome specific if you cd to the path it hangs too
[12:07] <pmjdebruijn> elmargol: I don't know how KDE does it mounting
[12:07] <pmjdebruijn> elmargol: what path?
[12:07] <pmjdebruijn> elmargol: how did you mount it?
[12:08] <elmargol> pmjdebruijn: i just plug it in... i guess hal mounts it?
[12:08] <pmjdebruijn> elmargol: how does the mount command list the mount
[12:08] <pmjdebruijn> elmargol: huh?
[12:08] <pmjdebruijn> elmargol: hal mounts cifs?
[12:09] <elmargol> pmjdebruijn: ahh you mean cifs.. mom
[12:09] <pmjdebruijn> elmargol: anyway, this probably isn't the proper channel for that
[12:09] <pmjdebruijn> elmargol: motu is primarily for universe packages
[12:09] <elmargol> ok... i give up
[12:10] <pmjdebruijn> elmargol: you should probably ask on #ubuntu
[12:10] <elmargol> there are a ton of open bug reports... noone cores... and i have this issues 2,5 years now
[12:10] <pmjdebruijn> elmargol: did you file the bug on the proper package?
[12:11] <pmjdebruijn> elmargol: filing good accurate bugs is very important in getting them fixed
[12:11] <elmargol> roflmao
[12:11] <pmjdebruijn> huh?
[12:12] <elmargol> You don't believe that do you?
[12:13] <pmjdebruijn> elmargol: seriously, what do you expect
[12:13] <pmjdebruijn> elmargol: developer will prioritize...
[12:13] <elmargol> if a bug takes more than 10 minutes developers just ignore it :D
[12:13]  * pmjdebruijn is just another user, btw
[12:14] <pmjdebruijn> elmargol: You don't believe that do you?
[12:14] <elmargol> I believe that 100%
[12:15] <pmjdebruijn> elmargol: well, I can't help you with that... please check if you properly filed your bugs... and ask help on an appropriate channel... like I said, #ubuntu-motu isn't the best place for the bugs you're talking about...
[12:18]  * directhex thinks there's a pinkware error alongside the hardware error
[12:58] <pmjdebruijn> directhex: pinkware?
[13:13] <mgdm> pmjdebruijn: I think he means brains :)
[13:31] <logari81> does anybody know what I have to do when I get the following error after uploading an update of a package?
[13:31] <logari81> http://revu.ubuntuwire.com/?archive=4208
[13:40] <pmjdebruijn> mgdm: oh
[13:56] <ScottK> hmmmm.  Brainzzzz.
[14:07]  * mgdm shuffles away from ScottK 
[14:11] <ScottK-laptop> If it's going to take you that long to shuffle, it's probably too late already.
[15:02] <logari81> unfortunately my client crashed, and possibly lost any answers on my question about:
[15:02] <logari81> http://revu.ubuntuwire.com/?archive=4208
[15:05] <ScottK-laptop> logari81: No one answered you, but I've asked a REVU hacker to take a look at  it.
[15:05]  * ScottK-laptop waves to NCommander.
[15:08] <mgdm> Would someone be able to have a look at the diff in https://bugs.edge.launchpad.net/hardy-backports/+bug/306280/ ? (Despite appearances, this is nothing to do with Hardy Backports...)
[15:09] <quadrispro> bug 307020
[15:10] <logari81> ScottK-laptop: do you think I should try to upload the package again or is it already correctly uploaded despite of that error?
[15:10] <logari81> this is the link to the package
[15:10] <logari81> http://revu.ubuntuwire.com/details.py?upid=4208
[15:11] <ScottK> logari81: I suspect it is correctly uploaded, but don't know for certain.
[15:13] <bddebian> Heya gang
[15:15] <ScottK> heya bd.
[15:15] <ScottK> Urgh.  Not enough coffee for proper tab completion yet.
[15:16] <ScottK> heya bddebian.
[15:16] <Nafallo> meeh
[15:16] <Nafallo> reminding me of my lack of coffee isn't fair :-P
[15:18] <rjune> blah
[15:19]  * jdong has a 2.5lb bag to finish in the coming week
[15:19] <bddebian> Heya ScottK
[15:19] <jdong> I don't want it to go stale over my winter break
[15:19] <jdong> nor do I want to take the bag home through the airport because then I seem like some crack dealer
[15:20] <ScottK> Odd.
[15:20]  * ScottK measures coffee staleness in months and years, not days and weeks.
[15:20] <geser> Hi bddebian
[15:20] <jdong> winter break is ~1.5mo
[15:21] <jdong> and I don't have a really great airtight container
[15:21] <bddebian> Heya geser
[15:21] <jdong> that's going to be on my christmas shopping list.
[15:21] <ScottK> Freezer?
[15:21] <jdong> I suppose that works too
[15:29] <leonel> scottK hello !   do you know  why bug 271546 are not yet fixed on  dapper and gutsy ??
[15:30] <ScottK> leonel: No.
[15:30] <ScottK> jdstrand_ or kees ^^
[15:30] <ScottK> leonel: Go have a look at r4550 in the clamav svn.
[15:35] <rjune> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <--- in the Method section of that, should dget -xu URL be dget -x URL?
[15:36] <jdong> rjune: -u allows unsigned extraction right?
[15:36] <jdong> yes
[15:36] <jdong> so that is correct
[15:36] <jdong> otherwise if you don't have the package's signing key in your GPG keyring, newer dget refuses to extract
[15:36] <rjune> jdong, when I do dget -xu, I get an error that -u is not known.
[15:37] <rjune> ok, it's a recent change then
[15:37] <jdong> I'm pretty sure it works Hardy+
[15:37] <leonel> scottK   to enable  the chm ??
[15:37] <ScottK> leonel: Yes.  Then you can test if the vulnerability is real or not.
[15:38] <rjune> jdong, doesn't work in hardy, might work in intrepid
[15:39] <ScottK> jdong: Personally, I consider unsigned extraction failure a feature.  It reminds me to go fetch their GPG key and check if I'm going to do anything with the code.
[15:39] <rjune> ScottK, nobody is complaining about it. just trying to verify the behaviour is correct
[15:40] <leonel> well .. I guess is real since the module is disabled  and clamav fixed the bug
[15:40] <ScottK> leonel: It's real for 0.94, but is it real for 0.92?
[15:41] <ScottK> rjune: I wouldn't recommend -xu to people myself.
[15:42] <ScottK> But then I do crazy stuff like make sure md5sums match before I upload a tarball too.
[15:42]  * rjune shrugs. not my wiki.
[15:42] <jdong> ScottK: I mostly agree when human intervention is there
[15:42] <jdong> ScottK: for prevu it was more of an annoyance that dget started failing in Hardy for unsigned packages
[15:42] <jdong> s/unsigned/unknownly signed/
[15:42] <jdong> it wouldn't make any sense to automatically fetch and trust a GPG key either
[15:43] <ScottK> True.
[15:43] <ScottK> My main concern is DNS cache poisoning and so if you're fetching the GPG key from a different domain than the code, then at least your odds are better.
[15:44] <ScottK> i.e. they have to successfully poison both of them.
[15:59] <rjune> does fakeroot depend on cdbs?
[16:00] <jdong> do you mean to ask the other way around?
[16:01] <jdong> ScottK: well my secondary concern is it takes a human to verify whether or not a package is signed by the right person and whether I got the right key for the person... IMO automating that and giving a false sense of security is worse than just plain assuming the data can be compromise.
[16:01] <rjune> jdong, no
[16:01] <rjune> jdong, I installed fakeroot and went to run it
[16:01] <jdong> it's always been my belief that security done wrong is worse than nothing done at all
[16:01] <rjune> it failed because cdbs was not installed
[16:01] <jdong> rjune: fakeroot has nothing to do with cdbs or Debian at all.
[16:02] <jdong> fakeroot is a standard Linux command that can be used on any distribution to give the appearance of root access.
[16:02] <jdong> what you're seeing is probably your package's build scripts being run with fakeroot that need cdbs.
[16:08] <rjune> jdong, https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <-- working through that
[16:08] <rjune> which allows for using fakeroot or as roo
[16:08] <rjune> as root
[16:08] <rjune> so I installed fakeroot
[16:08] <rjune> which failed because it didn't install cdbs as a dependancy.
[16:09] <rjune> which gets back to my initial question. does fakeroot depend(require, need) cdbs. your answer seems to be yes it does.
[16:23] <jdong> rjune: NO, fakeroot does not depend on cdbs.
[16:23] <jdong> rjune: fakeroot doesn't do anything but change your user to look like it's root.
[16:23] <jdong> but if you run something under fakeroot, it can require other things like cdbs.
[16:23] <jdong> that's like me running sudo firefox
[16:23] <jdong> and concluding sudo requires X, GTK, Mozilla, XulRunner, etc.
[16:24] <rjune> ok, so cdbs is required by the build scripts
[16:24] <jdong> that's correct
[16:24] <jdong> for your particular package you're working with, yes :)
[16:25] <rjune> then the web page should be updated to indicate you need to install cdbs
[16:25] <rjune> which it does.
[16:25] <rjune> dammit, missed that line
[16:26] <jdong> whoops :)
[16:26] <rjune> I hate it when I do that.
[16:31] <rjune> jdong, is cdbs a standard requirement for building packages?
[16:32] <jdong> rjune: no
[16:32] <ScottK-laptop> rjune: No.  Some use it.  Some don't.
[16:32] <rjune> do debs have such a concept as build requires?
[16:32] <jdong> yes.
[16:32] <jdong> Build-Depends
[16:33] <jdong> generally only a small subset of them is required to build the source target with debuild -S
[16:33] <rjune> so then cdbs should be in the build-depends for anything that requires cdbs?
[16:33] <jdong> yes
[16:33] <jdong> otherwise the package would not build
[16:34] <rjune> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <-- I'm still here.
[16:34] <rjune> it says to install cdbs at the beginning, but I'm wondering if updating the dsc file is a better solution
[16:36] <jdong> look in debian/control
[16:36] <jdong> cdbs is absolutely listed in the build depends
[16:36] <jdong> otherwise the package would not build in the Ubuntu build system
[16:37] <rjune> then why does it not error immediately when I try to build it with cdbs not installed?
[16:37] <rjune> Instead I got an error these files are missing
[16:38] <jdong> because to evaluate the build conditions cdbs is used.
[16:38] <jdong> the makefile debian/rules will immediately die a horrible death trying to find the cdbs scripts
[16:40] <rjune> so upon attempting to build something with deb, it does not first verify all the build-requires are installed?
[16:40] <rjune> or does cdbs do that verification?
[16:40] <jdong> in the case of cdbs, cdbs does that verification.
[16:41] <jdong> the actual rule for reading the build requirements is a part of the build script.
[16:41] <jdong> and in the case of cdbs, the build script (debian/rules) is surprisingly empty except for a bunch of cdbs includes.
[16:42] <rjune> so if I do  debuild -S -sa, then cdbs is responsible for looking at Build-Depends and making sure everything is installed?
[16:42] <directhex> the build system used in debian/rules is
[16:42] <jdong> correct
[16:42] <directhex> which in this case is cdbs
[16:43] <directhex> it might be something different, in theory
[16:43] <rjune> ok, then just install cdbs because it's effectively required to do package building. even if it isn't a strict technical one.
[16:43] <jdong> for your package, yes.
[16:43] <jdong> because it was made with cdbs
[16:43] <jdong> not all packages are made with cdbs.
[16:44] <jdong> it is one of several build systems that are available for use
[16:44] <directhex> dh7!
[16:45] <rjune> jdong, right, not everything uses cdbs, it's not a technical requirement. but a fair number of packages do, and when they do, there's no way to verify it before hand. so just install it so you have it
[16:46] <jdong> well, I suppose.
[16:46] <jdong> it doesn't hurt to have cdbs around.
[16:46]  * directhex hurts jdong 
[16:47] <jdong> eewww proposal 8!
[16:47] <jdong> *ducks*
[16:47] <rjune> what other require engines should I have installed?
[16:48] <Laney> Wait, what?
[16:48] <Laney> The build system gets build-deps?
[16:49] <jdong> Laney: the buildsystem usually calls a standard debhelper mechanism that checks them yes
[16:49] <Laney> I thought that dpkg-buildpackage did that
[16:49] <Laney> parsing of control
[16:51] <jdong> Laney: yes, but before doing so:
[16:51] <jdong> unless ($noclean) { withecho(@rootcommand, @debian_rules, 'clean');
[16:51] <jdong> }
[16:51] <jdong> which runs the debian/rules target
[16:51] <jdong> which you're screwed on if one of the included makefiles isn't available :)
[16:52] <jdong> which is why it's helpful to use an internal variant of pdebuild to even buidl source packages
[16:52] <rjune> jdong, any other engines besides cdbs Ishould have installed?
[16:52] <Laney> But that doesn't actually install anything itself
[16:52] <jdong> rjune: get them when they come.
[16:52] <Laney> You have to have stuff used in the clean target installed to build source packages
[16:52] <jdong> don't waste time now trying to foresee every build dependency you might need in the future.
[16:52] <jdong> there's a few packages that are evil enough to require a substantial amount of stuff to execute their clean target
[16:52] <Laney> But I don't think anything actually check that - building will just bomb out?
[16:53] <rjune> but seeing as I won't know what they are until I get an error about them. which may or may not provide information as to what I actually need. I figured I would ask.
[16:53] <jdong> Laney: yeah...
[16:53] <Laney> ok
[16:53] <Laney> I guess I was confused as to what you were saying
[16:53] <jdong> depending on how you clean.
[16:53] <Laney> right
[16:53] <jdong> if you are doing a fakeroot debian/rules clean, yeah it'll bomb out.
[16:53] <jdong> but if cleaning is a part of a debuild/dpkg-buildpackage sequence, you're okay
[16:54] <jdong> those check build deps before cleaning
[17:11] <pmjdebruijn> I just fixed the amd64 issue with my package, can someone review the corrected version ( http://revu.ubuntuwire.com/details.py?package=lensfun )?
[17:31] <superm1> crimsun, I've not tested that snapshot.  i've tested the stuff in intrepid and hardy at this point
[17:44] <DRebellion> sebner, I checked the amd64 cifer binary from the packages before adding the chrpath --delete and after, and chrpath reports that neither of them contain rpath tags
[17:44] <sebner> DRebellion: how that? O_o
[17:44] <DRebellion> sebner, i'm not sure
[17:45] <DRebellion> sebner, perhaps there wasn't a problem after all?
[17:45] <sebner> DRebellion: I'll recheck that today or tomorrow. Besides this issue your package could be advocated so I'll try to solve that
[17:45] <DRebellion> sebner, ok thanks.
[19:16] <`Chris> Hello #ubuntu-motu! Can anyone direct me to some beginner tutorials for packing and maintaining packages in Ubuntu?
[19:16] <DRebellion> `Chris, dive in: https://wiki.ubuntu.com/PackagingGuide/Complete
[19:17] <`Chris> Thanks a bunch DRebellion
[19:18] <DktrKranz> `Chris, you could also look at https://wiki.ubuntu.com/MOTU/GettingStarted (it has some references to Ubuntu development) and http://www.debian.org/doc/debian-policy/ (for packaging rules in general).
[19:22] <rjune> ogra, You get your package?
[19:22] <morgs> jdong: are you on motu-sru?
[19:23] <morgs> I urgently need to get bug 263173 approved for SRU
[19:24] <morgs> jdong, nxvl, cody-somerville ^ please?
[19:25] <ogra> rjune, yeah, we'll try it tonight ;)
[19:31] <rjune> fantastic
[19:35] <hyperair> http://revu.ubuntuwire.com/details.py?package=sigx <-- review, anyone?
[19:35]  * hyperair officially hates scons
[19:36] <jpds> hyperair: Wow, we could make a club.
[19:37] <hyperair> jpds: you've got bad experiences with scons too?
[19:37] <jpds> hyperair: Pretty much, I personally prefer cmake
[19:38] <hyperair> i prefer autotools
[19:38] <hyperair> cmake has too damn much caps
[19:38] <hyperair> hurts my eyes
[19:39] <jpds> hyperair: In the CMakeLists.txt files? The commands don't have to be caps.
[19:39] <hyperair> oh
[19:39] <hyperair> ah well. i'm sticking to autotools for the time being
[19:39] <hyperair> as for my scons comment, i say it from the packaging point of view
[19:41] <hyperair> first i realize that cdbs doesn't have support for scons. then i realize that there is a sample scons.mk and scons-vars.mk that could be included in cdbs, but isn't for some reason or other. then i realize that the lib i'm trying to package comes with a wonderful scons file that DOESNT HAVE DESTDIR
[19:41] <hyperair> or any other method of specifying alternate root
[19:41]  * hyperair headdesks
[19:42] <slytherin> hyperair: I guess that is why someone wished you luck for scons
[19:43] <hyperair> slytherin: oh yeah that. must be
[19:43] <hyperair> i found on nabble two people who were trying to come up with packaging for sigx
[19:43] <hyperair> they were doing it for debian, and for some strange reason, they wanted to rewrite the build system in the process
[19:44] <hyperair> that was in august, and there hasn't been any news from them
[19:44] <hyperair> maybe i should try contacting them
[19:45] <slytherin> geser: remember I filed bug for removing libjaxp1.2-java from archives in intrepid cycle? Looks like it was not blacklisted. The source has appeared in jaunty queue.
[19:49] <cody-somerville> morgs, approved
[19:50] <slytherin> Can any archive admins please blacklist libjaxp1.2-java and remove the source from jaunty queue? I am looking for the removal bug.
[19:51] <slytherin> bug #251973
[19:53] <fabrice_sp> Hi. Anybody to have a look at bug #306754? I pasted a debdiff to fix a FTBFS (also happen in Intrepid).
[19:54] <geser> slytherin: did it pass the (source) NEW queue already?
[19:55] <slytherin> geser: nope.
[19:55] <geser> slytherin: the please try to get an archive admin REJECT it and add it to the sync blacklist
[19:57] <slytherin> geser: so should I try on #ubuntu-devel?
[19:57] <geser> yes
[19:57] <geser> if it isn't the archive yet, we don't have to remove it again
[19:57] <slytherin> fabrice_sp: Did you check the build logs. The package has built fine on i386 and some other architectures.
[19:57] <slytherin> geser: ok
[19:58] <fabrice_sp> slytherin: yes, but i was before gcc 4.3 was the default compiler
[19:58] <fabrice_sp> there is the same bug in Debian, with the same patch
[19:59] <fabrice_sp> but the package maintainer seems 'dead'
[19:59] <slytherin> fabrice_sp: my mistake. Didn't check that it was last built in gutsy.
[20:00] <fabrice_sp> slytherin: :-) This package also needs a porting to amd64 :-/ I'm on it, but it's huge
[20:00] <slytherin> geser: By the way, do you think I should raise a high priority bug for libquartz-java problem in Debian? I have not received any reply to my mail on debian-java ML.
[20:02] <geser> slytherin: have you tried to get an opinion about it from #debian-devel/OFTC?
[20:02] <slytherin> geser: No. I was thinking about that. Will try tomorrow.
[20:03] <geser> it sounds like at least "important" or even higher (which would make it a RC-bug) but I'm not sure if it's RC or not
[20:56] <sebner> bobbo: CONGRATULATIONS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :D :D :D
[20:56] <rjune> ?
[20:56] <DktrKranz> bobbo, \o/
[20:56] <DRebellion> rjune, he got MOTU status.
[20:56] <DRebellion> bobbo, congrats ;)
[20:56] <slytherin> bobbo: Congratulations. :-)
[20:57] <loevborg> Hi. I uploaded a package to revu, but it doesn't show up on my profile page on revu.ubuntuwire.com. What could I have done wrong?
[20:57] <rjune> bobbo, yay! good job
[20:57] <DRebellion> loevborg, how long ago did you upload it? It usually takes ~5 minutes to show up.
[20:57] <rjune> DRebellion, I assume that means he can commit directly?
[20:58] <loevborg> DRebellion: >45min
[20:58] <DRebellion> rjune, yes.
[20:58] <loevborg> It's my first upload btw, so maybe I messed up the pgp key or something.
[20:59] <DRebellion> loevborg, perhaps =/ . Maybe one of the revu admins is around to help...
[21:00] <slytherin> loevborg: have you ever logged in revu before uploading the package?
[21:01] <loevborg> slytherin: maybe I haven't logged in before _adding my pgp key_!
[21:02] <bobbo> DktrKranz, sebner, slytherin, rjune: Thanks alot guys! :D
[21:03] <loevborg> slytherin: should I re-upload after re-logging in?
[21:03] <rjune> bobbo, how long did it take?
[21:03] <slytherin> loevborg: your pgp key gets synced from launchpad. so if you had not logged in to revu at least once before uploading the package then that is root cause of your problem.
[21:03] <bobbo> rjune: My first upload was in January this year, so ~1 year
[21:04]  * slytherin is felling sleepy, quits
[21:10] <loevborg> hah now it worked
[21:43] <Hellow> Hello
[21:43] <Hellow> How specifically would I get a package included into the Universe repository for Jaunty?
[21:45] <laga> Hellow: thru REVU
[21:45] <joaopinto> Hellow, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[21:45] <Hellow> thanks
[21:45] <directhex> Hellow, is it Free Software? that's a good start
[21:46] <Hellow> it is under the BSD license
[21:46] <Hellow> #netrek is the channel that the people that want the package in the Universe is
[21:48] <Hellow> could one of you join in there and explain to them how to get it in?
[21:49] <Hellow> I cannot sufficiently explain it without making rather large errors.
[21:49] <laga> they could just ask in here themselves, or read the wiki pages and ask questions if they arise
[21:49] <Hellow> ok
[21:50] <rjune> laga, howdy
[21:50] <laga> hi rjune
[21:50] <rjune> save my memory, you were/are a regular in #ltsp right
[21:50] <laga> yes :)
[21:51] <Hellow> ask these people, akb4
[21:51] <laga> i used to be, now there's not so much time anymore. i'll be working on ltsp/mythbuntu-diskless again over christmas break
[21:51] <akb4> ok. Hi there, all.
[21:53] <akb4> I'm part of a group that has a package in debian sid. It's a game. (Oldest active internet, in fact). We'd like it in ubuntu. I'm not sure we can come up with a maintainer. Help?
[21:54] <LaserJock> akb4: if the package is already in sid then it should be in Ubuntu too
[21:55] <akb4> does that happen automatically?
[21:55] <LaserJock> pretty much yeah
[21:55] <Hellow> didnt know that xD
[21:55] <LaserJock> the archive admins get a list of the applications from Debian that are new and will generally let them in
[21:55] <LaserJock> if you want to make sure we can look
[21:56] <Hellow> the package is netrek-client-cow, fyi
[21:56] <LaserJock> was just going to ask :-)
[21:56] <Hellow> heh
[21:56] <LaserJock> oh, was going to ask akb4 that
[21:56] <LaserJock> or are you working on the same
[21:56] <LaserJock> ?
[21:56] <Hellow> we are working on the same
[21:56] <Hellow> I was the person who originally started up with all the Ubuntu related stuff
[21:57] <mgdm> I read about netrek the other day, somewhere
[21:57] <Hellow> (in that project)
[21:57] <akb4> mgdm: I'd love to know where
[21:57] <mgdm> the jargon file, IIRC?
[21:57] <akb4> ok, not listed on packages.ubuntu.com
[21:57] <Hellow> it was recently added to sid, as far as I know
[21:58] <LaserJock> akb4: ok, it's fairly new and in non-free
[21:58] <akb4> now, the original upload went to the "non-free" section about 3-4 weeks ago. that was a mistake, and the debian maintainer just submitted a new upload an hour ago.
[21:58] <LaserJock> that would probably be the reason we don't have it yet
[21:58] <LaserJock> ah
[21:58] <LaserJock> I believe that will make a big difference
[21:59] <LaserJock> I believe, though could be wrong, that we don't automatically import from non-free
[21:59] <Hellow> that should be correct LaserJock
[21:59] <akb4> once the deb mirrors have it in the correct section, what's the likely propagation time to ubuntu?
[21:59] <Hellow> Dont they upload packages to Universe and Multiuniverse later in the development cycle, LaserJock?
[22:00] <LaserJock> well, looking at https://wiki.ubuntu.com/JauntyReleaseSchedule
[22:00] <LaserJock> it looks like you have until Christmas :-)
[22:01] <LaserJock> at Debian Import Freeze (DIF) is when we stop automatically importing from Debian
[22:01] <akb4> ok. how fast does the import occur once debian has it?
[22:02] <LaserJock> akb4, Hellow: what I would do is keep an eye on our archive and see if it goes through
[22:02] <LaserJock> if it hasn't by Christmas give us a ping
[22:02] <Hellow> would it be included into the Intrepid repo also?
[22:02] <LaserJock> that I'm not exactly sure, if I had to guess I'd say maybe a week or so
[22:02] <LaserJock> Hellow: no
[22:02] <LaserJock> Intrepid is out the door, only critical and security updates
[22:03] <LaserJock> you could however perhaps ask for a backport
[22:03] <Hellow> Naa, Jaunty is close enough :)
[22:04] <Hellow> Now you can see why I could not give a straight answer without making serious errors while describing this...
[22:04] <LaserJock> so I'd just keep an eye on the situation
[22:04] <akb4> LaserJock: thanks very much. Hellow: yep, I figured it was something like this.
[22:04] <LaserJock> if, for whatever reason, it doesn't show up before Christmas let us know
[22:04] <LaserJock> after Christmas we can manually do it
[22:05] <akb4> ok, I'll try to keep an eye on it.
[22:05] <LaserJock> akb4, Hellow: thanks for checking in
[22:06] <akb4> sure thing.
[22:06] <Hellow> np
[22:06] <LaserJock> it's always helpful when Debian people show interest in what's going on, makes for a smoother ride :-)
[22:47] <nhandler> bobbo: Congrats on becoming a MOTU!
[22:47] <ScottK> bobbo: Congratulations.
[22:48] <bobbo> thanks guys! :D
[22:48] <nhandler> bobbo: So, what is your first upload going to be ?
[22:48] <bobbo> already made it, libparted transition
[22:49] <ScottK> netrek-client-cow appears to be in Debian New.
[22:49] <james_w> congratulations bobbo
[22:50] <jcastro> bobbo: \o/
[22:50] <bobbo> :D
[22:53]  * nhandler is glad he didn't do this on identi.ca
[23:00] <emgent> bobbo: congrats :)
[23:05] <RainCT> bobbo: congrats!