[01:45] <mnabil_> hello guys, is there's a how to for creating a virtual ubuntu package ?
[01:49] <persia> mnabil_: Not really.  Why do you need one?
[01:49] <sladen> mnabil_: virtual ubuntu package?
[01:50] <sladen> mnabil_: can you expand the question; what type of 'virtual'?
[01:50] <mnabil_> persia, actually , i'm building a custom system based on ubuntu, so i wanna make an update scheme using apt , so i can grab some package under one name
[01:50] <persia> mnabil_: I'd suggest making a meta-package rather than a virtual package.  It is more likely to meet your needs.
[01:50] <mnabil_> sladen, actually , like ubuntu-desktop i think
[01:50] <sladen> mnabil_: a meta-package ?
[01:50] <mnabil_> persia, cool , link me to the how to :D , or i can google ?
[01:51] <mnabil_> sladen, is this a meta package :D
[01:51] <persia> mnabil_: Better to just look at the source of an existing one.  Start with apt-get source ubuntu-desktop.
[01:51] <mnabil_> the packages, ubuntu-desktop, xubuntu-desktop are called meta packages ?
[01:52] <mnabil_> persia, so this is called meta package then ?
[01:52] <sladen> mnabil_: apt-cache search meta| grep -i meta.*package && apt-get source packageofyourchoicetouseasanexample
[01:53] <persia> mnabil_: A meta-package is a package that only contains dependencies information: no content.  A virtual package is one that doesn't even exist, but is used by other packages for dependencies management.
[01:53] <mnabil_> sladen, yea, i just ask about the category name ,  i think i have conflict between the meaning of metapackage , and virtual package :D
[01:54] <mnabil_> persia, so, ubuntu-desktop is a meta package , right ?
[01:54] <sladen> mnabil_: yes
[01:55] <mnabil_> sladen, thanks alot, sorry i new to ubuntu , and debian like distros,   i didn't use any :D
[01:55] <mnabil_> i'm a gentoo user
[01:56] <sladen> eg.  "mail-transport-agent" is a virtual package.  exim/postfix/sendmail all Provide: it
[01:56] <sladen> but there is no such package itself
[01:57] <mnabil_> sladen, yea, i'm reading , thanks alot :)
[02:47] <dazza> hi, is it possible to create a 3TB ext3 filesystem with the standard ubuntu desktop kernel?
[04:40] <Hobbsee> lamont: any idea why you made changes to kinput2?
[04:41] <lamont> Hobbsee: because it annoyed me???
[04:41] <lamont> no clue./
[04:41]  * lamont goes looking
[04:41] <Hobbsee> lamont: oh, excellent, it's not even in intrepid anymore, apparently (makedepend)
[04:42] <Hobbsee> oh *nice*.  it hasn't existed apart from dapper.
[04:43] <lamont> Hobbsee: it's called "xutils-dev" :-)
[04:43] <lamont> Provides: imake, makedepend, xorg-build-macros, xmkmf
[04:44] <Hobbsee> lamont: ahhh, so that moved.  right
[04:44] <lamont> you could certainly go with the "I bet it works, please sync 3.1-10.1 from sid, kthx" and then add the xutils-dev build-depend if it doesn't... :-)
[04:45] <lamont> given that it's built everywhere in debian, I expect that you can just sync it and have success
[04:45] <Hobbsee> lamont: yeah.  well, seeing as i just synced it, taht's what i'll be doing.
[04:45] <lamont> heh
[04:45]  * lamont bets we can't sync a package from sid/NEW though. :0(
[04:46] <lamont> http://people.ubuntu.com/~lamont/ISDN.png <-- why I'm not sure about the reliability of copper some days...
[04:47] <lamont> gotta love those hard flat tops where one channel goes *splat*
[04:48] <Hobbsee> lamont: you cna sync from anywhere that has a .dsc address, it appears.
[04:48] <lamont> OTOH, I'd trade $something for something from the current century
[04:48] <Hobbsee> heh
[04:48] <lamont> Hobbsee: NEW queue isn't readable.
[04:48] <Hobbsee> i was thinking of sid, but yes.
[04:48] <Hobbsee> oh, i see.  sid/new as in the one thing, not either of them
[04:48] <lamont> right
[04:49] <lamont> bind9_1:9.5.0.dfsg-1 is sitting in NEW, bound for sid
[04:49] <lamont> stupid soname changes
[04:49]  * Hobbsee trouts whoever put in the requiring a debian maintainer field as a multi-affects bug.
[04:49] <lamont> if it takes too long, I'll just upload a ~0ubuntu1 version. :D
[04:50] <lamont> ??
[04:50] <Hobbsee> ah, damn.  now it's frozen my firefox.
[04:50] <Hobbsee> bug 23035-
[04:50] <Hobbsee> bug 230350
[04:51] <lamont> 2008-05-14  by  Luca Falavigna
[04:52]  * Hobbsee trouts him again
[04:52] <Hobbsee> i thought it was.
[04:52] <Hobbsee> i just couldn't load the bug again, to check.
[05:17] <lamont> Hobbsee: just mass close it and open new ones... :-)
[05:17] <lamont> or not
[05:17] <lamont> anyway, iz bedtime
[05:17] <lamont> g'night
[05:18] <twb> Does Ubuntu have a document anywhere defining what requirements must be met before an upgrade will be allowed into a (already released) release?
[05:19] <twb> I realize it'll basically amount to "only if it fixes critical security bugs", but I'd like to be able to refer to the full document.
[05:21]  * lamont bets that a search for "stable release update" on the wiki would be fruitful
[05:22] <lamont> twb: that's the rule for -security.  -updates is a bit easier.  though not my much
[05:23] <twb> So the wiki is considered the official place for that document?
[05:24] <twb> I want to know what the Ubuntu developers are *committing* to, not an explanation of the intent.
[05:25] <twb> (I'm reading https://wiki.ubuntu.com/StableReleaseUpdates now.)
[05:27] <lamont> those are the rules that are applied wrt updates to stable releases
[05:28] <lamont> which direction are you coming at the question from?  trying to get something in, or trying to avoid upgrades that you don't want?
[05:29] <twb> From the persepective of a corporation deploying LTS
[05:29] <twb> And personally as a Debian user who likes policy to be written down in great detail.
[05:32] <twb> I'm looking at the upgrade list of a fresh desktop LTS install, and there are a lot of upstream point releases being included (e.g. gnome-about [1:22.2.1-0ubuntu6 -> 1:2.22.2-0ubuntu1].  As a Debian user, I have a deep-seated fear of allowing upstream to introduce new code to a stable release, because new upstream = new regressions.
[05:32] <twb> Althogh looking at apt-cache policy I can see that example has come from -updates not -security.
[05:33] <lamont> the shortest answer to that is to just not include hardy-updates in sources.list
[05:33] <twb> Nod.
[05:33] <Chipzz> twb: for the gnome packages in ubuntu, that's perfectly normal
[05:34] <lamont> OTOH, hardy has a 8.04.1 release (which lands in updates, almost certainly) scheduled for august, which is when the upgrade from dapper->hardy is supposed to be fully happy and such... hence the higher rate of churn in -updates right now
[05:34] <lamont> and yeah, ubuntu tracks gnome very religiously
[05:35] <twb> So -updates constitutes the upgrades from version Nr0 to Nr1, where 1 is the latest micro(?) release?
[05:36] <twb> Oh sorry, https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions is something else
[06:49] <TheMuso> Hobbsee: That is a very very weird sync.
[06:55] <Hobbsee> TheMuso: sorry?
[06:58] <TheMuso> Hobbsee: Those two packages that have your name against them on the intrepid changes list.
[06:59] <Hobbsee> TheMuso: yes, i know.
[06:59] <Hobbsee> TheMuso: i can't sign with the archive key, of course.
[07:00]  * TheMuso nods.
[07:00] <Hobbsee> TheMuso: it's using sync-source.py, which effectively downloads the package, resigns, then lets you upload it
[07:00] <TheMuso> Wouldn't it be better to request a sync?
[07:12] <Hobbsee> TheMuso: perhaps.  i just wanted to save work, and knock it off the MoM list
[07:12] <Hobbsee> although i'm aware it's not off yet
[07:34] <ernstp> where can I find documentation about all the details of the debian/rules file?
[07:57] <bimberi> ernstp: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[07:58] <ernstp> bimberi: perfect!
[10:21] <uga> guys, anybody can tell what's the difference between libssh-2 and libssh2-1 ?
[10:22] <uga> it's very confusing, both support ssh2
[10:26] <nxvl> libssh-2 seems to be the 2 debian version of libssh
[10:27] <nxvl> and libssh2-1 must be the 1st debian version of libssh2
[10:27] <uga> nxvl: it supports ssh2 though
[10:27] <nxvl> dunno
[10:27] <nxvl> but folowing the debian version rules
[10:27] <nxvl> that must be the loginc
[10:27] <nxvl> logic*
[10:27] <uga> I thought at first that libssh-2 was ssh1, but the url in says they disabled ssh1 by default
[10:27] <uga> and the maintainer of the package is the same guy :/
[10:28] <uga> http://packages.debian.org/sid/libssh2-1
[10:28] <uga> http://packages.debian.org/lenny/libssh2-1-dev
[10:28] <uga> uh-oh...
[10:28] <uga> sid and lenny. that may mean something
[10:29] <uga> oh sorry, no wrong pastes I go nuts now ;)
[10:30] <nxvl> those ones are libssh2 both of them
[10:31] <nxvl> also
[10:31] <nxvl> that's a question you should ask on debian-devel
[10:31] <nxvl> since they are debian packages
[10:31] <nxvl> not ubuntu ones
[10:32] <uga> nxvl: errrm... that's because in my google search debian packs appeared, but it seems ubuntu took the names from debian
[10:32] <uga> I'm on ubuntu, not on debian =)
[10:33] <uga> and ubuntu.com seems timing out on me :/
[10:34] <nxvl> packages.ubuntu.com
[10:34] <nxvl> or check in launchpad
[10:34] <uga> trying, but the server refuses
[10:34] <nxvl> launchpad.net/ubuntu/+source/$PACKAGENAME
[10:36] <uga> that doesnt' seem to work for me, unless package name needs more than the name
[10:39] <uga> nxvl: sigh, it's not possible this way, unless someboy fixes packages.ubuntu.com... I tried from a different host with no luck
[10:40] <uga> nxvl: but you can sure check apt-cache search libssh and you'll see both
[10:40] <uga> whose names, have obviously been inherited from debian
[10:43] <uga> here you are  http://rafb.net/p/vsTMei98.html
[10:51] <nxvl> mm
[10:51] <nxvl> there is the difference in the descriptions
[10:51] <nxvl> one is the client side library
[10:51] <nxvl> and the other a programmers library
[10:51] <uga> nxvl: from a kde-dev guy:
[10:52] <uga> [11:43] <pusling> uga: the first one is libssh2 soname1 and the other one is libssh soname2
[10:52] <uga> [11:43] <pusling> uga: I guess you should blame the upstreams of those two difeferent projects for choosing so similar names ;)
[10:52] <uga> that should explain what's going on
[10:52] <uga> I wonder if the two packages are needed
[10:52] <uga> anymore
[10:52] <nxvl> ask the DM
[10:52] <nxvl> or send and e-mail to colin
[10:53] <uga> seems the right thing to do yes
[12:16] <GnineX> whois GnineX
[12:16] <GnineX> oops..
[12:20] <geser> Hobbsee: could you please give back irssi on i386 (CHROOTWAIT)? Thanks.
[12:42] <Kopfgeldjaeger> do we already know which kernel version will be in intrepid?
[13:13] <Hobbsee> geser: given back.  poor rothera.
[13:13] <Hobbsee> wait.
[13:15]  * Hobbsee does it manually, and sacrifices a goat to launchpad to ensure that buildd.py works again soon
[13:16] <cody-somerville> \o/
[13:17] <geser> Hobbsee: buildd.py works for me. I use it to do give-backs for universe packages.
[13:18] <Hobbsee>   File "/usr/lib/python2.5/urllib2.py", line 506, in http_error_default
[13:18] <Hobbsee>     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
[13:18] <Hobbsee> urllib2.HTTPError: HTTP Error 500: Internal Server Error
[13:18] <geser> hmm
[13:18] <Hobbsee> repeatable.
[13:19] <geser> I took the script from people.ubuntu.com/~pitti/scripts and adjusted only the path to my LP cookie.
[13:23]  * Hobbsee yoinks new changes
[13:23] <Hobbsee> nope.  still an internal server error.
[13:25] <geser> really interesting why it works for me but not for you. You probably have to much permissions :)
[13:25] <Hobbsee> perhaps so.
[13:30] <geser> or simply LP doesn't like you anymore :)
[13:31] <persia> Did LP ever?  I always imagined Hobbsee's stick taming LP for the rest of us.
[13:32] <Hobbsee> LP doesn't like me for being australian.
[13:32] <geser> move to europe
[13:35] <Hobbsee> yeah well.  i wouldn't mind doing that.
[14:11] <cjwatson> persia: FWIW equivs might be a better thing to point people at than ubuntu-desktop. ubuntu-desktop is designed for ease of maintenance in Ubuntu, not so much for comprehensibility by everyone else ...
[14:11] <persia> cjwatson: Ah.  Thanks.
[14:12] <persia> Wow!  a meta-meta-package :)
[14:12] <cjwatson> it's kinda cool
[14:13] <ion_> http://gitweb.heh.fi/?p=ion/ubuntu/ion-meta.git;a=tree
[15:59] <smarter> Could someone please have a look at bug #236526 ?
[15:59] <smarter> https://bugs.launchpad.net/ubuntu/+source/devscripts/+bug/236526 - "uupdate should appends -0ubuntu1 instead of -1 to the version number"
[16:12] <sladen> smarter: ideally that would detect if you're on Debian, or Ubuntu and select the default postfix based on that
[16:12] <sladen> otherwise we have to keep a patch against Debian
[16:14] <a7p> hi everyone - I found a removal request on a certain Package an I'd like to have further information on that - can anyone give me a direction to look into?
[16:14] <a7p> https://launchpad.net/ubuntu/intrepid/+source/vim-latexsuite/20060325-4.1
[16:14] <a7p> is the package in question
[16:16] <sladen> a7p: removal?
[16:16] <sladen> a7p: from whom?  for what reason?
[16:17] <a7p> sladen, I've got absolutly no idea, not that the package was especially important to me - there is written: Removal requested  on 2008-05-05.
[16:18] <a7p> or does that mean something entirely differend?
[16:21] <sladen> a7p: where did the message come from?  where did you see the messagE?
[16:22] <sladen> ah, on that URL  "Removal requested  on 2008-05-05. "
[16:23] <sladen> it was uploaded by the auto-syncer
[16:54] <cjwatson> a7p: to perhaps clarify what sladen said, that "Removal requested" just means that internal stuff in Launchpad decided to remove *that version* of vim-latexsuite
[16:54] <cjwatson> a7p: you can tell this because there's also a message about it being superseded by a later version
[16:54] <cjwatson> a7p: https://launchpad.net/ubuntu/+source/vim-latexsuite shows that it's still in the archive
[17:15] <a7p> cjwatson, ah, thank you very much for the information ...
[17:15] <a7p> did not get that connection.
[17:45] <smarter_> sladen: I've attached a new patch to https://bugs.launchpad.net/ubuntu/+source/devscripts/+bug/236526
[17:49] <sladen> smarter: looks very good
[17:49] <smarter> thanks ;)
[17:49] <sladen> smarter: I wonder if there's a more reliable way than  grep Ubuntu /etc/issue
[17:49] <sladen> there's /etc/lsb-release but I have a feeling that is only meant to be accessed via  the 'lsb-release' command
[17:49] <smarter> lsb_release -i
[17:50] <smarter> $(grep Ubuntu $(lsb_release -i)) maybe, but it doesn't look good
[17:51] <sladen> if [ `lsb_release --short --id` = `Ubuntu` ] ; then ... maybe?
[17:51] <sladen> it could even got inside a switch statement
[17:51] <smarter> good idea
[17:51] <smarter> I'll try to do that
[17:55] <geser> smarter: you might look how dch does it, but it also uses the output of lsb_release -is
[17:55] <Mithrandir> which is what sladen is suggesting.
[17:56] <Mithrandir> oh, you were suggesting a way to look more at the code around it; just ignore me. :-)
[18:09] <a7p> #225411 is fixed in Intrepid, and the commited patch works for hardy - I'm just bilding a diff for gustys package - how should I procede?
[18:09] <sladen> bug #225411
[18:10] <sladen> ubugtu...
[18:42] <smarter> sladen: new patch: https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/236526
[18:54] <sladen> smarter: that's close enough I'd be happy with it
[18:55] <sladen> smarter: I'd generally do   test -x /usr/bin/lsb_release && ...   as it's mandated where 'lsb_release' is and avoids PATH
[18:58] <sladen> smarter: case "$(test -x /usr/bin/lsb_release && /usr/bin/lsb_release --short --id 2>/dev/null)" in  Ubuntu)
[22:32] <cjwatson> sladen: prefer which or type to any use of hardcoded PATH
[22:33] <sladen> cjwatson: can do.  Do you also want a --distribution override a la the other utilities?
[22:33] <cjwatson> this is just a drive-by review, haven't looked that far ...
[22:34] <cjwatson> (I don't use uupdate myself any more so I'm not really a good person to answer that)
[22:36] <geser> wasn't one reason for the --distribution override that one can work on Debian package on a Ubuntu system and vice versa? so the same should apply for uupdate, shouldn't it?
[22:36] <cjwatson> slightly more interested right now in why valgrind is failing on my openssh build :-/
[22:46] <Keybuk> cjwatson: hang on, didn't this exact same thinking just cause the world a lot of hurt? :p
[22:47] <cjwatson> that was failing in the usual way
[22:47] <cjwatson> this is valgrind outputting nothing but:
[22:47] <cjwatson> valgrind: mmap(0x0, 294912) failed in UME with error 13 (Permission denied).
[22:47] <cjwatson> strace has:
[22:47] <cjwatson> open("build-deb/ssh-add", O_RDONLY)     = 3
[22:47] <cjwatson> [...]
[22:48] <cjwatson> mmap2(NULL, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES (Permission denied)
[22:56] <Keybuk> cjwatson: kees woz 'ere ?