[00:02] <verwilst> i have a line "$(INSTALL_FILE) debian/templates/zabbix_proxy.conf.in $(TMP_PROXY_PGSQL)/usr/share/doc/zabbix-proxy-pgsql/zabbix_proxy.conf"
[00:02] <verwilst> why does it save this as a .gz?
[00:02] <verwilst> i have the same line somewhere else ( just slightly different filename ) and it doesnt get a .gz appended
[00:03] <azeem> verwilst: things in /usr/share/doc get gzipped if they're bigger than a threshold
[00:03] <azeem> see man dh_compress for how to exclude that one
[00:04] <verwilst> otherwise dbconfig-common errors out with error: template infile /usr/share/doc/zabbix-proxy-mysql/zabbix_proxy.conf does not exist
[00:04] <azeem> things should never depend on stuff in /usr/share/doc
[00:04] <azeem> users should be able to purge the docs if they want
[00:05] <verwilst> hm
[00:06] <verwilst> ( it's an already existing deb that i'm upgrading
[00:06] <verwilst> so it's bad practice?
[00:06] <azeem> verwilst: didn't you or somebody else introduce those proxies recently?
[00:06] <azeem> or was that another package?
[00:06] <verwilst> euh
[00:06] <verwilst> or maybe it was me on this channel?
[00:07] <verwilst> i better hope so damned, all that work i spent already!
[00:07] <verwilst> ;)
[00:07] <azeem> so the other binary packages in there also use templates from /usr/share/doc?
[00:08] <verwilst> azeem: ah no it's not dbconfig
[00:08] <azeem> ?
[00:08] <verwilst> it's postinst
[00:08] <verwilst> dbc_generate_include_args="-U -o template_infile=/usr/share/doc/zabbix-proxy-mysql/zabbix_proxy.conf"
[00:10] <verwilst> hm, it is dbconfig.. :P don't know what dbconfig has to do with that file though
[00:15] <verwilst> ah, i do now
[00:18] <verwilst> azeem: i should put the config file examples in /usr/share/zabbix-proxy/?
[00:18] <azeem> config files belong under /etc
[00:18] <verwilst> myeah but it's a template
[00:19] <verwilst> with _DBC_xxx_ stuff in it and such
[00:20] <verwilst> actually zabbix-agent has ./usr/share/zabbix-agent/zabbix_agentd.conf but zabbix-server has./usr/share/doc/zabbix-server-mysql/zabbix_server.conf
[00:20] <verwilst> azeem: tell me where to put it and i'll make it so ;)
[00:21] <azeem> I don't know about web apps and their templates, sorry
[00:21] <verwilst> web apps?
[00:21] <verwilst> it could be the template of any app
[00:21] <verwilst> it's a c daemon..
[00:24] <verwilst> /usr/share/<app> seems better than /usr/share/doc/<app> though :)
[00:24] <verwilst> so i'll use that in the meantime
[00:54] <persia> verwilst: /usr/share/$(package) should contain anything that could be described as "software", /etc/$(package) should contain "configuration", and /usr/share/doc/$(package)/examples example data that the package doesn't actually use for anything, but which a user may wish to later inspect.
[00:56] <persia> dmoerner: I've moved the page to https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling, because scripts are code too :)
[00:56] <verwilst> persia: so what about config templates?
[00:56] <verwilst> with DBC macro's and such?
[00:58] <persia> verwilst: It very much depends on the need for them.
[00:58] <verwilst> how's that?
[00:58] <persia> If they are needed by the package at install time or run time, they belong in /etc/ or in /usr/share
[00:58] <persia> If they are only needed by the user, they belong in /usr/share/doc/examples
[00:59] <verwilst> well the DB params are configured through dbconfig
[00:59] <persia> In the first case, if they are expected to be changed by the user, they belong in /etc, and if they are never expected to be changed by the user, they belong in /usr/share
[01:00] <verwilst> they should be changed by the user, but the initial configure should happen through dbconfig
[01:00] <verwilst> :)
[01:00] <verwilst> if i dput a package
[01:00] <verwilst> can i see it on my ppa page right away?
[01:00] <persia> OK.  That which is expected to be changed by the user ought be a conffile, and ought be in /etc, so that changes by the user are preserved on package upgrade.
[01:01] <verwilst> ah yes i can :)
[01:01] <verwilst> hm ok
[01:01] <verwilst> and how do i handle dbconfig then?
[01:01] <persia> See, I don't see how the specific use of dbconfig in this case makes any difference.
[01:02] <verwilst> a /etc/zabbix/zabbix_proxy.conf.default or something?
[01:02] <verwilst> and when you do a dpkg-reconfigure, it copies the .default to zabbix_proxy.conf with _DBC_DBNAME_ and such replaced?
[01:02] <verwilst> or am i missing something here? ;)
[01:03] <persia> So the template isn't actually intended to be modified by the user?
[01:04] <verwilst> yeah it is
[01:04] <verwilst> dbconfig only deals with the db part of the config ( so that shouldnt be needing any modification afterwards
[01:05] <verwilst> but there are other options in that file too
[01:05] <persia> Doesn't really matter.
[01:05] <persia> Essentially, from what you've described, you have some file, and you use that file to generate a configuration file.
[01:06] <persia> The generated configuration file is what most users are likely to edit, no?
[01:06] <persia> So the source file wouldn't be edited by the users.
[01:06] <verwilst> idd
[01:08] <persia> Note that I suspect you may have an additional issue: specifically that you may not preserve user modification of the configuration file if they run dpkg-reconfigure
[01:08] <verwilst> yeah
[01:08] <persia> Of course, you may: I'm just guessing here.
[01:08] <verwilst> how is that normally handled?
[01:09] <persia> There are a few strategies.  If you flag it as a conffile, and ship a working default configuration each time, the user is notified if they have changed it, and can reconcile your changes.
[01:10] <persia> If you have part of the file that will always be changed, but most won't be changed, you might consider splitting that out into a separate file, so that you can change the base configuration, and only the user modifies the e.g. database connection configuration
[01:10] <verwilst> that only works if the config format allows including other files
[01:10] <verwilst> right?
[01:10] <persia> Some people like the ucf framework to help with this, and others have complex parsing scripts in the postinst
[01:10] <persia> Indeed.
[01:11] <verwilst> which isnt the case i'm afraid
[01:11] <verwilst> anyways, im sooo tired :) it's way too late
[01:11] <persia> You may just end up with something where the user needs to manually fix it on each upgrade, which is ugly, but better than wiping user config each time (especially because this violates the debconf-is-not-a-registry rule)
[01:12] <verwilst> my first ppa upload just built succesfully! jaj! :)
[01:12] <verwilst> persia: or reming dbconfig from zabbix?
[01:12] <verwilst> removing*
[01:13] <persia> I tend to prefer to comment things out rather than removing them, but that can cause another issue: after installation, software should work without further user tinkering.  It may not work ideally, but it should work.
[01:14] <verwilst> gm
[01:14] <verwilst> an issue for another day ;)
[01:14] <verwilst> goodnight!
[01:15] <verwilst> thanks for the info persia!
[06:07] <tuxmaniac> in a src tarball if one of the files is LGPL and the remaining GPL then in the debian/copyright. Can i specificy something like this. http://paste.ubuntu.com/42076/
[08:15] <Iulian> Good morning.
[08:32] <probono> hi all, can someone give a 2nd opinion on my package of a little python app, http://revu.ubuntuwire.com/details.py?package=liveusb please?
[10:20] <RainCT> morning
[10:20] <probono> morning
[10:24] <jpds> morning
[10:24] <probono> can i bribe RainCT or jpds into looking @ my package? ;-)
[10:25] <jpds> Sure, I have PayPal.
[10:25] <jpds> Joking, which package is it?
[10:25] <probono> liveusb :)
[10:26] <jpds> Ahhh, I was trying to put the Ubuntu intrepid daily on my USB with that yesterday.
[10:26] <probono> jpds: let me guess, it didn't work because 10,000 windows popped up
[10:27] <jpds> probono: No, it didn't let me say where the .iso file was.
[10:27]  * laga will offer 10 merges next cycle for the first two problems each found in http://revu.ubuntuwire.com/details.py?package=mythtv-theme-metallurgy-wide - 4 merges for every problem after that :)
[10:27] <probono> ah ok, it's designed to run _from_ the live cd
[10:27] <jpds> probono: I figured that out after running it ;-)
[10:27] <Iulian> laga: Hahah
[10:28] <laga> Iulian: getting desperate here ;)
[10:28]  * RainCT tries to find as many errors as possible in laga's package ;P
[10:28] <Iulian> Me too.
[10:28] <laga> that's the spirit.
[10:29] <laga> don't forget to ACK it ;)
[10:29] <Iulian> laga: Do you have a needs-packaging bug in LP?
[10:30] <Iulian> laga: If yes, close it in the changelog.
[10:30] <jpds> probono: I think having a LP: #### in changelog, will close that bug..
[10:30] <laga> Iulian: i don't have one.
[10:30] <probono> jpds: shouldn't it?
[10:30] <Iulian> laga: Well, file one then.
[10:31] <RainCT> laga: how do you want to get a FFe without bug? :P
[10:31] <jpds> probono: Ignore that, I was looking at the bzr diff.
[10:31] <RainCT> laga: and most probably the package will be rejected (by archive admins) if you don't mention the bug where the exception was granted in debian/changelog
[10:32] <jpds> probono: Upstream tarball has no COPYING/LICENSE file.
[10:32] <laga> alright, i'll get an exception granted then.
[10:33] <probono> jpds: does it need one as it's a native package?
[10:33] <jpds> probono: Yes.
[10:34] <RainCT> laga: the README isn't interesting
[10:34] <geser> laga: looking at your package: how comes that the themeinfo.xml says version 1.1 while the the changelog says 1.0?
[10:34] <jpds> probono: cp /usr/share/common-licenses/GPL-2 . - should do it.
[10:34] <geser> laga: please word-wrap the license text in debian/copyright
[10:35] <probono> thanks jpds
[10:35] <laga> RainCT: upstream README? it is interesting for those wanting additional colour schemes
[10:36] <Iulian> laga: Also please consider changing to ttf-dejavu as ttf-bitstream-vera is scheduled for removal in Debian.
[10:36] <laga> geser: i don't know. the upstream release is 1.0 and i doubt the theme version is used for anything interesting anyways, so that's not worth fixing
[10:36] <RainCT> laga, no, because the homepage should be in a Homepage: field in debian/control ;)
[10:37] <laga> RainCT: yeah, but people won't know if there is anything interesting on that homepage :)
[10:37] <RainCT> laga: they should look then :P
[10:37] <laga> pff.
[10:38] <laga> ;)
[10:38] <RainCT> (and most people won't look at the README file anyway. it's more likely that they go to the homepage first)
[10:38] <laga> that's not a reason not to install it
[10:38] <RainCT> (ah, and the README is supposed to have info about the package itself, not about others)
[10:38] <laga> i often look at the README file. it's not my fault new users don't know that /usr/share/doc/ exists :)
[10:39]  * laga gives up and removes the darn README
[10:39] <Iulian> laga: See debian bug #461308
[10:39] <geser> laga: do I understand it correctly that this package is for multiverse?
[10:39] <RainCT> laga: note that you can use * with dh_install
[10:39] <laga> geser: yes
[10:41] <laga> geser: it depends on mythtv-common which is in multiverse
[10:41] <RainCT> laga: unless I'm missing something, you don't need the dirs files
[10:43] <laga> i blame superm1, i based it on his package
[10:43] <geser> laga: IIRC you don't need XS- before Vcs-* anymore
[10:43] <laga> RainCT: you're correct, it looks like i don't need the *dirs files
[10:45] <RainCT> laga: the description is supposed to explain what the package containsm, not how to use it.. but well I don't know if it's policy for mythbuntu to have bad descriptions so feel free to ignore that :P
[10:47] <laga> that line won't kill anyone :)
[10:47] <laga> great, why did lintian start to throw warnings at me *now* about files being executable when they shouldn't be? i didn't change anything
[10:49] <laga> Iulian: is ttf-dejavu a drop-in replacement for ttf-bitstream-vera?
[10:49] <laga> or does the package need to be changed?
[10:52] <RainCT> jpds: how do I unencript that? XD
[10:52] <RainCT> jpds: ah, nvm
[10:52] <jpds> ...
[10:55] <probono> jpds, still looking at liveusb? or was that the only change necessary?
[10:55] <jpds> probono: I have to go out for a sec, brb.
[10:55] <probono> alright
[10:57] <Iulian> laga: ttf-dejavu is a replacement for ttf-bitstream-vera. Afaics that bug was reported a while ago and there has not been any activity in it recently.
[10:58] <Iulian> laga: I don't know if it's going to be removed from Ubuntu too.
[11:00] <laga> Iulian: okay, then i'll leave it in right now. if it ever gets removed from ubuntu, it should be an easy task if it's indeed a simple drop-in replacement
[11:00] <laga> i have no clue how the font subsystems work and i'm not exactly keen on finding out right now - lots of other stuff to do for intrepid.
[11:01] <Iulian> laga: Sure, your choice.
[11:02] <laga> hum. is there a nice tool to line-wrap documents? doing this manually is a bit annoying
[11:06] <wgrant> A word processor, LaTeX, or a web browser should work fine.
[11:07] <laga> i've used "reformat". worked reasonably well
[11:18] <persia> laga: There are also line-wrapping functions in many text editors, including both vim and emacs, which seem to carry most pathos.
[11:18] <laga> okay. 10 merges for the needs-packaging thing, 10 for the line wrapping in debian/copyright, 2 for the README file (because i don't agree with RainCT on that one ;)), 4 for the homepage field, and 4 for the X-VCS things
[11:19] <laga> 30 merges. i hate you guys.
[11:19] <persia> tuxmaniac: You ought identify the LGPL file, and document that it is LGPL, the (likely different) copyright holder and author, and include the LGPL excerpt indicating the license.
[11:19] <persia> laga: You did offer :)
[11:19] <laga> yeah ;)
[11:20] <persia> If you want to get a head start, the RCbugs page lists a number of things which may wish to be merged.
[11:20] <laga> it'll contribute towards my MOTU application, so i'm not complaining too much.
[11:20] <laga> persia: for intrepid?
[11:21] <persia> laga: Indeed.  Debian is near release now, and closing *lots* of release-critical bugs.  Some of these also affect Ubuntu packages, and represent changes that would not violate FeatureFreeze.  Fixing these is a good thing, else we release with RC bugs with known fixes, which doesn't look so good.
[11:22] <laga> hum. i might do some of these later today, but i've got a small patch for mythtv to finish first
[11:23] <sebner> persia: Is a FFe for *xneur worth it? What do you think?
[11:23] <persia> sebner: Absolutely no idea.  What bugs would it close?
[11:23] <laga> so, how do i exclude a README file when using CDBS? using DEB_DH_ALWAYS_EXCLUDE?
[11:24] <persia> laga: Or include a debian/docs file containing only that you want included.
[11:26] <sebner> persia: I have to make further investigation but it seems that it won't close anything
[11:27] <RainCT> laga: bah. if you do the 2 merges anyway, you can leave it there :P
[11:27] <persia> sebner: OK.  Why should it be upgraded?
[11:27] <sebner> persia: new features as well as bug fixes ^^ and we still have a svn version
[11:27] <laga> RainCT: alright ;)
[11:28]  * sebner --> lunch
[11:28] <persia> sebner: Right.  So, go investigate the bug fixes, and decide if any of them are important.
[11:33] <up_the_irons> is it me, or does the package 'weechat' have no binaries? (i'm on hardy)
[11:34] <RainCT> up_the_irons: right.. the package is empty o_O
[11:34] <directhex> /usr/bin/weechat-curses
[11:34] <directhex> Package: weechat
[11:34] <directhex> Depends: weechat-common (= 0.2.6-1), weechat-curses (>= 0.2.6-1)
[11:34] <up_the_irons> directhex: ah, thanks!
[11:34] <persia> up_the_irons: You need to select one of the front-ends.
[11:35] <laga> i'd like to point out that it's usually a good idea to bzr push before using rm -rf
[11:35]  * laga goes to re-do five revisions or so
[11:36] <up_the_irons> persia: gotcha
[12:07] <sebner> persia: homepage is in russian and Changelog in the tarball is pretty outdated :(
[12:08] <persia> sebner: Some of us (not me) do read Russian: perhaps you could get help from someone?
[12:09] <persia> Also, the Debian changelog likely references some bugs closed: those might be helpful in determining if it's worth updating.
[12:09] <sebner> persia: kk, thx :)
[12:11] <laga> RainCT, Iulian, geser: i've corrected the problems you mentioned. http://revu.ubuntuwire.com/details.py?upid=3598
[12:11] <laga> no, i won't offer more merges now
[12:17] <Iulian> I forgot to count, how many do you have until now?
[12:17] <laga> 30
[12:18] <Iulian> Bleah, that's nothing :)
[12:18] <laga> hah
[14:05] <RainCT> Bah, I hate #ubuntu. Every time I go there for help I end up answering questions instead of getting an answer to mine XDD
[14:05] <sebner> RainCT: xD xD xD
[14:12] <k0p> hehe
[14:12] <k0p> :)
[14:13] <persia> RainCT: Ask a question.  I've had *much* better answers in questions than on #ubuntu
[14:14] <RainCT> persia: you mean ask it here? If so:   I'm trying to setup polipo but it doesn't work on any computer beside that one where it is installed... http://paste.ubuntu.com/42152/plain/  Any idea what the problem could be?
[14:17] <persia> RainCT: No, I mean ask on answers.launchpad.net.  Check if it's a DNS issue.
[14:17] <albert23> RainCT: proxyAddress = "192.168.1.20" might help?
[14:18] <RainCT> persia: Ah OK. How could it be a problem with DNS if it's a IP?
[14:18] <RainCT> persia: err. just tried with google's IP, same problem.
[14:20] <RainCT> albert23: no, as Apache handles the request then
[14:21]  * RainCT files a question. persia, albert23: thanks
[14:23] <persia> RainCT: Although it's not the issue, if you happened not to have working DNS on that machine, it might not be able to pass the request properly.
[14:25] <RainCT> persia: Ah. Doesn't polipo have it's own DNS resolver?
[14:27] <persia> RainCT: I don't know, and I don't know how w3m interacts with a proxy, and I don't know if an issue with DNS would be with the polipo server or with the client.
[14:28] <persia> That said, it's always a good thing to check first when trying something with a name doesn't work :)
[14:30] <tuxmaniac> persia: i had done that. I wanted to verify whether the format pasted here -> http://paste.ubuntu.com/42076/ is correct before uploading to REVU
[14:31] <tuxmaniac> persia: oops
[14:31] <tuxmaniac> persia: now I realise why you gave that. :-) pasted wrong copyright file :P
[14:32] <tuxmaniac> persia: sorry for the trouble. here is updated link http://paste.ubuntu.com/42160/
[14:33] <persia> tuxmaniac: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[14:34] <persia> Alternately: http://wiki.debian.org/Proposals/CopyrightFormat
[14:34] <persia> Something in-between is not ideal.
[14:46] <laga> persia: i'm looking at rcbugs now
[14:47] <laga> persia: acl2 is fixed in debian (was FTBS), but it's also a new upstream version. should i request a sync/merge anyways?
[14:50] <persia> laga: Well, you'll have to figure that out, but I'll look at this one with you, and you can use the same methods for the rest.
[14:51] <persia> First, we ought look at Debian bug #494328 to make sure we understand the issue
[14:52] <persia> It appears that this was originally filed as a FTBFS bug, so we can check the build status of acl2.  I tend to look at http://qa.ubuntuwire.com/ftbfs for a quick overview of build failures.
[14:53] <persia> It doesn't appear there, so we can look at the launchpad page: https://launchpad.net/ubuntu/intrepid/+source/acl2/3.3-1.1
[14:53] <persia> As you can see, it built fine in Ubuntu, so maybe we don't have that issue.
[14:54] <laga> hum.
[14:55] <persia> Another good thing to check is the Debian changelog: I usually get it from pacakges.qa.debian.org: so we visit http://packages.qa.debian.org/a/acl2.html to see what else was fixed.
[14:56] <persia> This says that it also fixed Debian bug #482594 but I don't think we need to worry about that, as we're not enforcing the new source format for intrepid.
[14:56] <laga> yes, they've fixed another FTBS there
[14:56] <laga> so they fixed two FTBS which don't seem to affect intrepid. and the new upstream release can't happen because we're in feature freeze
[14:57] <persia> There's also an open bug in Ubuntu, but it's unrelated: you might check if that was fixed either in the current version or in the new upstream version while you're inspecting the package.
[14:58] <persia> Now, it's only 5 days old, and Debian is frozen, so we might look for a mail requesting a freeze exception, but first let's look at the upstream changelog to see what happened there.
[14:58] <persia> Upstream has a homepage at http://www.cs.utexas.edu/users/moore/acl2/
[14:58] <persia> There's a nice "Differences with 3.3" link.
[15:00] <persia> While my lisp is lousy, and I've never used ACL2, none of the described bugfixes look critical to me.
[15:00] <persia> Now, for the freeze exception request.
[15:01] <persia> The Debian Release team mailing list has an overview page at http://lists.debian.org/debian-release/
[15:01] <persia> Since the package upload is 5 days old, we want to look in the August 2008 archives.
[15:02] <laga> nothing.
[15:04] <persia> Right.  So that means that the fixes are two FTBFS bugs that don't affect Ubuntu, some stuff upstream, but nothing that seems to indicate it's exceedingly urgent according to upstream, and nothing that closes any Debian or Ubuntu bugs.
[15:04] <persia> It also means that the Debian Maintainer doesn't think this update is sufficiently essential it must be in Lenny.
[15:04] <persia> So, based on that, do you think it's worth a sync or a merge?
[15:04] <laga> no.
[15:05] <persia> That'd be my thought too.  So, comment why it's not important on the rcbugs page, and pick the next package.
[15:05] <laga> alright, thanks a lot. that was very helpful
[15:05] <persia> Any questions about the investigation process to understand how to get information necessary to make the decision?
[15:06] <laga> no, i think i can find my way around
[15:07] <persia> laga: Just one thing: sometimes a package isn't rebuilt for each release.  In this case, the intrepid version is different than the hardy version, so we know we built it in intrepid.
[15:07] <persia> If the hardy and intrepid versions are the same, and it's an FTBFS bug, it's worth building in a local chroot to verify that it didn't become FTBFS with the changes in the toolchain.
[15:07] <laga> persia: can you give me a quick (fake) example?
[15:07] <laga> ah.
[15:10] <persia> https://launchpad.net/ubuntu/+source/bing has never been updated or recompiled in Ubuntu since the first import.
[15:11] <persia> You can see that fairly clearly from the "Version history" report :)
[15:12] <laga> indeed ;)
[15:14] <persia> So, despite the fact that we have bing binaries built, we have no idea if bing builds today (although it was successful three weeks ago (because it's not listed at http://builder.ubuntuwire.com:9998/dist/intrepid/arch/i386/failed)
[15:31] <laga> i wonder if there are greasemonkeys scripts to make the ubuntu wiki more.. usable
[15:37] <persia> laga: How is it not usable?
[15:38] <laga> persia: i find it hard to navigate. mediawiki always has a menu on the left
[15:38] <laga> maybe some kind of menu tree would be nice
[15:39] <persia> Indeed, and implementing that *in* the wiki would be vastly better than using a greasemonkey script.
[15:39] <laga> haha :)
[15:39] <persia> Mind you, you probably want to talk about it on some mailing list (not sure which) beforehand.
[15:39] <laga> um, that'd probably qualify as a "long time goal"
[16:17] <tuxmaniac> it will be great if someone reviews the package http://revu.ubuntuwire.com/details.py?package=gresistor and givees their valuable comments. I am planning to rise a exception for the same.
[16:17] <tuxmaniac> reason for the delay is upstream just responded and updated the source tarball with the full copy of the license
[16:42] <Adri2000> zul: what happened to the fail2ban sru? it's hasn't even been accepted into -proposed it seems?
[16:46] <Adri2000> zul: or rather, have you uploaded it?
[16:50] <devfil> ScottK: ping
[18:59] <porthose> I am updating a package, I have a diff.gz of the new package do I just attache that to an update bug in launchpad and follow the FFE process?
[19:02] <dmoerner> porthose, if this is just a bug fix, make a debdiff. if it's an upstream update, then make an interdiff
[19:02] <dmoerner> https://wiki.ubuntu.com/MOTU/Contributing
[19:03] <porthose> dmoerner: thx :)
[19:04] <persia> porthose: dmoerner: That page is actually out of date (I'll fix it now).  For an upstream update, yes, please only attach the updated diff.gz
[19:05] <dmoerner> persia, thanks for the heads up
[19:05] <tuxmaniac> Any idea how to find whether a particular emacs mode is already packaged or not? pardon me if its really stupid.
[19:06] <azeem> tuxmaniac: maybe search for the filename?
[19:07] <tuxmaniac> azeem: apt-cache search does not yield the result. Checked in the -goodies package. Not there. But there are several other extras also.
[19:07] <tuxmaniac> azeem: check for the filename where?
[19:08] <azeem> packages.ubuntuc.om
[19:08] <azeem> eh, packages.ubuntu.com, or apt-file
[19:20] <tuxmaniac> anybody using emacs willing to give me some small test feedback? Please open emacs and check whether vhdl-mode is installed by default. thanks in advance.
[19:44] <NCommander> tuxmaniac, how can I check?
[19:44] <NCommander> (I have emacs installed, but I really don't know it)
[19:57] <tuxmaniac> NCommander: just press Alt + x
[19:57] <tuxmaniac> and type vhdl <press tab>
[19:57] <tuxmaniac> if it auto completes then it is installed
[19:58] <NCommander> It's installed by default on intrepid
[19:58] <tuxmaniac> hmm. then bug 258867 is invalid. :-)
[19:59] <NCommander> yay
[20:00] <tuxmaniac> NCommander: hehe it was me who rised it. and then realised it is already there today
[20:00] <tuxmaniac> but wanted another tester :-) thanks a lot
[20:01] <NCommander> heh
[20:01] <NCommander> No problem
[20:01] <NCommander> I used to play with VHDL back in the day
[20:01] <NCommander> I have a new embedded Coldfire board I'm playing with now
[20:01] <tuxmaniac> NCommander: the funny thing is someone in fedora actually packageed it *again* only to later find today that it is already in as part of emacs-common
[20:02] <tuxmaniac> I am the culprit there too. I rised the wishlist request there also
[20:02] <tuxmaniac> I am feeling bad for such low quality bug report from my side
[20:02]  * NCommander hits tuxmaniac with a blunt object
[20:02] <NCommander> :-)
[20:03] <NCommander> Don't worry, we all have our off days
[20:03] <NCommander> What embedded architectures do you work on tuxmaniac ?
[20:03] <tuxmaniac> my be OT on this channel. can we take it on pm?
[20:03] <NCommander> This channel goes OT all the time, but sure
[20:06] <james_w> hi NCommander, were you secretary for the motu-release meeting?
[20:06] <NCommander> I was, but I had to leave half way through
[20:06] <NCommander> d'oh, I said I was going to write notes
[20:07]  * NCommander gets right on that
[20:07] <james_w> thanks
[21:50] <jpds> james_w: Do you know much on how launchpadlib works?
[21:51] <james_w> jpds: a little
[21:51] <james_w> jpds: not so much the internals though
[21:51] <jpds> james_w: I don't know why, but I keep getting: "launchpadlib.errors.HTTPError: HTTP Error 401: Unauthorized", when I do: "user = launchpad.me"
[21:51] <james_w> you have set up the OAuth credentials correctly?
[21:52] <jpds> Yes, and written them to ~/.launchpadlib/ubuntu-dev-tools/credentials.txt
[21:52] <jpds> credentials.load(open(lpCredentials))
[21:52] <jpds> launchpad = Launchpad(credentials, EDGE_SERVICE_ROOT)
[21:53] <jpds> I don't understand how launchpad.me does not work with that.
[21:55] <jpds> I can do: launchpad.people["jpds"] - just fine tho.
[22:09] <james_w> jpds: I'm not sure, sorry, #launchpad might be able to help
[22:10] <jpds> james_w: Tried there, noone was around, but I guess it's !weekend.
[22:10] <james_w> jpds: I expect so
[22:14] <jpds> james_w: I'll try again tomorrow.
[22:26] <alex-weej> does anyone know if there's some way for me to install files to a system as if it was from a deb but without the deb?
[22:26] <toobaz3> what  do you mean for "as if"?!
[22:27] <alex-weej> i.e. so i can track the files and uninstall them as if it was a package
[22:27] <alex-weej> well i am thinking for things like Unreal Tournament from disc
[22:27] <alex-weej> i don't want to have to build an intermediate deb file that is 4 GB big
[22:27] <toobaz3> m
[22:27] <toobaz3> I see
[22:27] <directhex> yes
[22:27] <directhex> look at how flashplugin-nonfree works
[22:28] <directhex> or quake2-data from debian (AFAIK it's not in ubuntu)
[22:28] <alex-weej> flashplugin-nonfree does not track the files it downloads
[22:28] <toobaz3> alex-weej: sure?
[22:28] <toobaz3> I think it does remove the plugin if removed
[22:28] <alex-weej> yes but it does it itself as postinst prerm
[22:28] <toobaz3> right
[22:28] <alex-weej> so if you do a dpkg -S on any of the files
[22:29] <alex-weej> it won't work
[22:29] <alex-weej> it would be cool if flashplugin-nonfree did it the way i am suggesting instead
[22:29] <alex-weej> much like how Gentoo Ebuilds work
[22:30] <toobaz3> can it be done with the actual infrastructure?
[22:30] <toobaz3> maybe with a placeholder
[22:30] <alex-weej> with DPKG, that is what i am asking here
[22:30] <alex-weej> :)
[22:30] <toobaz3> actually
[22:30] <toobaz3> maybe
[22:30] <alex-weej> i wonder how alien does it...
[22:30] <toobaz3> you can, with a simple script
[22:30] <alex-weej> afaik it installs RPMs to the system as if it was a Deb
[22:30] <toobaz3> make a file hierarchy
[22:31] <toobaz3> but touch - instead of copying - every
[22:31] <toobaz3> file
[22:31] <toobaz3> and then add a "cp" for every file in the "install" target
[22:31] <alex-weej> doesn't the dpkg manifesto know, say, the hashes of the files it installs?
[22:31] <toobaz3> I don't think so
[22:32] <alex-weej> lame
[22:32] <toobaz3> files can be edited
[22:32] <toobaz3> (config files, i.e)
[22:32] <toobaz3> anyway
[22:32] <toobaz3> this would work, I think
[22:33] <alex-weej> well i am actually asking with view to writing a blueprint
[22:33] <toobaz3> but probably it's more work than just make a list of the files you  copy
[22:33] <alex-weej> so hacks, though interesting, aren't much use :)
[22:33] <toobaz3> and then remove every file on the list
[22:33] <toobaz3> exactly
[22:33] <toobaz3> well
[22:33] <toobaz3> it would be of use
[22:34] <toobaz3> if you plan to redistribute it to people already owning original files
[22:34] <alex-weej> i am thinking it would be possible to build some sort of hook into the process between the deb file extraction and the installation where more files can be added
[22:34] <toobaz3> frankly, I don't know
[22:34] <toobaz3> maybe in some pre-installation script
[22:34] <toobaz3> but I'm ignorant about it
[22:39] <toobaz3> hey, MOTUs, https://wiki.ubuntu.com/MOTU/Contributing says "Add the patch tag to the bug" if I post a patch... but can it be done from a normal user?!
[22:39] <james_w> toobaz3: it can
[22:39] <toobaz3> well... so I'm blind?
[22:39] <toobaz3> (yes, I am)
[22:39] <toobaz3> how?
[22:40] <james_w> if you click the "edit" link next to the title of the bug there will be a text entry for entering tags
[22:40] <toobaz3> wow
[22:41] <toobaz3> thanks
[23:14] <NCommander> ScottK, I take it you don't like the idea of having all packages in bzr?
[23:47] <toobaz3> tuxmaniac: finally had time to comment gperiodic (I do comment occasionally on REVU, but I have absolutely no authority, I'm not MOTU)