[00:00] <james_w> that's not the file that it is complaining about though?
[00:00] <MTecknology> no, I assumed that's where it was happening at
[00:01] <MTecknology> would you be willing to help me fix this in a query? - like I said - /me is noob to this stuff
[00:01] <james_w> in here is better
[00:01] <MTecknology> I want to learn how this whole process works and I figured practice is the best place :)
[00:01] <james_w> partly so others can help or learn
[00:01] <MTecknology> ok
[00:01] <MTecknology> so - the chroot
[00:02] <james_w> and partly because I'm supposed to be doing something else :-)
[00:02] <james_w> do you understand what conffiles are?
[00:02] <MTecknology> oh
[00:02] <james_w> in the dpkg sense that is
[00:02] <MTecknology> I've never seen the word conffiles before
[00:02] <james_w> ok, no problem
[00:02] <james_w> a package can mark certain files as "conffiles"
[00:03] <james_w> this means that dpkg will handle them differently to any other file
[00:03] <james_w> normally when a package is upgraded all the old files are overwritten with the new versions
[00:03] <james_w> this means that if you modify them your changes will be lost when you upgrade
[00:04] <james_w> if that was to happen for configuration files that you are *supposed* to edit, then it would be bad
[00:04] <james_w> so dpkg treats these files differently
[00:04] <MTecknology> ok - I know where you're going now :)
[00:04] <james_w> when it installs the first version of the package it records the md5sum of the file that it puts on disk
[00:05] <james_w> it does that in /var/lib/dpkg/info/*.conffiles
[00:05] <james_w> have a look at that now
[00:05] <james_w> then when it upgrades the package it first checks if the new version of the file in the .deb is different to the old one. If it is the same it does nothing with it.
[00:05] <james_w> if it has changed then it starts the process of installing it
[00:06] <james_w> but first it has to check if you modified the file
[00:06] <james_w> it gets the md5sum of the file on disk
[00:06] <james_w> if that matches what it recorded originally then it overwrites the file, as you haven't modified it
[00:06] <james_w> and writes the new md5sum in to the .conffiles file so that it can do the same next time
[00:07] <MTecknology> so the md5sum that it's keeping for what the old copy was is probably wrong?
[00:07] <james_w> if the md5sum doesn't match then you have modified it
[00:07] <james_w> so it prompts you
[00:07] <james_w> exactly, the file isn't modified, but what is on disk isn't what is recorded
[00:07] <james_w> that could be a few things
[00:08] <MTecknology> I have the md5sum of what the old file should be
[00:08] <james_w> such as another package editing the file in its upgrade scripts(which is forbidden)
[00:08] <james_w> or the sequence of upgrades that Steve did led to inconsistency for other reasons (such as a mistake when changing the "owner" of the file)
[00:09] <james_w> you are in an intrepid chroot?
[00:09] <MTecknology> no - no idea how
[00:09] <MTecknology> but I did have this same error happen to me and I saw it pop up a few other places - jsut fyi
[00:09] <james_w> that's fine
[00:09] <james_w> when was the last time you installed fresh?
[00:10] <MTecknology> about a month ago w/ 9.04
[00:10] <MTecknology> I did a fresh 9.04 vm today
[00:10] <james_w> and you saw it upgrading that?
[00:10] <MTecknology> no updates to it yet
[00:11] <james_w> I'm interested because Steve started from hardy, and the more we can narrow it down, the less work that it is
[00:11] <james_w> you said that you saw this prompt?
[00:11] <MTecknology> I'll do updates on the vm
[00:11] <MTecknology> ya
[00:12] <MTecknology> I'm botting up the vm
[00:12] <MTecknology> I'll do updates to it
[00:14] <MTecknology> dloading 270 updates
[00:19] <MTecknology> james_w: anything I should grab an md5sum of prior to letting the update finish?
[00:20] <james_w> MTecknology: extract the md5sum recorded in /var/lib/dpkg/ and md5sum of the file on disk
[00:22] <MTecknology> james_w: I just grabbed /var/lib/dpkg/info/*
[01:14] <binarymutant> should I add a line to my changlelog for every bug I fix or are minor bugs not worth a changelog entry?
[01:15] <cody-somerville> Put 'er all in
[01:15] <cody-somerville> No need to have one per line though
[01:15] <cody-somerville> You can have multiple on one line
[01:15] <binarymutant> thanks for the info cody-somerville :)
[01:15] <cody-somerville> np
[01:18] <MTecknology> james_w: ran off for supper - apparently things went good this time
[01:18] <james_w> ah
[01:20] <Ampelbein> hi. i need help with a package upgrade, gnome-nds-thumbnailer to version 1.2.1. the current version is synced from debian and got a patch in debian/patches which doesn't seem to get applied. 'debian/rules patch' gives an error (dh: Unknown sequence patch (chose from: binary binary-arch binary-indep build clean install)) should i ask the debian-maintainer if that's intentional or just add the patch-target in the new version myself?
[01:21] <MTecknology> james_w: so... how should I handle that bug report?
[01:22] <MTecknology> james_w: do I need to now do a dist-upgrade from 8.10 -> 9.04 ?
[01:22] <james_w> I think that would be useful
[01:22] <james_w> if you install an intrepid chroot and then grab the information, then dist-upgrade, that will start to help
[01:23] <james_w> have a look at debootstrap for creating a chroot
[01:23] <MTecknology> create a chroot for an entire installation?
[01:23] <james_w> do that, chroot in, and then install ubuntu-desktop
[01:23] <james_w> they don't install everything by default
[01:23] <james_w> actually, you may not need ubuntu-desktop
[01:23] <dtchen> james_w: (thanks again for package-import- quite time-conserving)
[01:24] <MTecknology> ubuntu-minimal ?
[01:24] <james_w> dtchen: ah, cool, what do you use it for?
[01:24] <cody-somerville> minimal is pulled in by bootstrap
[01:24] <dtchen> james_w: everything
[01:24] <james_w> MTecknology: ubuntu-standard perhaps
[01:24] <MTecknology> ok
[01:24] <james_w> dtchen: ah, cool :-)
[01:24] <james_w> MTecknology: you need at least vim-tiny installed :-)
[01:24] <MTecknology> james_w: any idiots guid to doing it?
[01:25] <james_w> there's probably lots on debootstrap, it's pretty old and well used
[01:25] <james_w> nothing to hand I'm afraid
[01:25] <james_w> and I'm heading to bed
[01:26] <james_w> g'night all
[01:26] <MTecknology> james_w: but but but... what about when I get to the error? :P
[01:26] <james_w> heh
[01:26] <MTecknology> g'night - thanks for the lessons :)
[01:26] <james_w> np
[01:26] <james_w> thanks for working on the bug
[01:31] <dtchen> bigon: Ampelbein has a question regarding dh7 and not-applied 01schema.patch in the cdbs -> dh7 conversion
[01:31] <dtchen> bigon: err, for gnome-nds-thumbnailer
[01:31] <dtchen> Ampelbein: probably a missing /rules hunk
[01:32] <Ampelbein> oh. didn't see he was in here, sorry.
[01:54] <MTecknology> I used debootstrap to install 7.04 - but networking isn't working
[01:55] <MTecknology> I used debootstrap to install 7.04 - but it's not working right - http://pastebin.com/mb8317b2 ***
[01:55] <MTecknology> that's a better question
[02:07] <Ampelbein> dtchen: thanks. i changed debian/rules to http://paste.ubuntu.com/143206/ , is this ok or is there a new "way to go" with dh7?
[02:37] <MTecknology> I'm curious - is there a point where people that are motu's start getting revenue from their work?
[02:46] <binarymutant> MTecknology, motu is a volunteer job as far as I know
[02:46] <binarymutant> MTecknology, looks good on a resume though :)
[02:46] <ScottK> MTecknology: 7.04 is long out of support.
[02:47] <MTecknology> binarymutant: how can people devote so much time to ubuntu and still have a job?
[02:47] <MTecknology> ScottK: right?
[02:47] <binarymutant> MTecknology, love of the community? or love of code maybe
[02:47] <ScottK> A lot of the people involved are students.
[02:48] <MTecknology> I'm sophmore in college
[02:48] <ScottK> So you've got lots of free time.
[02:48] <binarymutant> :P lols
[02:48] <MTecknology> ya... a whole lot of it... :S
[02:48] <MTecknology> oh! sarcasm :P
[02:49]  * ScottK works a ~60 hour a week job and has a wife and 3 kids.  Trust me.  He has a lot of free time.
[02:49] <MTecknology> oh! sarcasm :P
[02:49]  * imbrandon yawns
[02:50] <binarymutant> an hour a day could go a long way I think
[02:50] <MTecknology> sry for repeat
[02:50] <MTecknology> I've been pushing about 8+hr/day on this - blowing off work and homework
[02:50] <MTecknology> and working on crap during classes
[02:50] <binarymutant> :/
[02:51] <binarymutant> MTecknology, made motu yet?
[02:51] <MTecknology> nope
[02:51] <imbrandon> MTecknology: thats not sustainable though
[02:51] <imbrandon> :)
[02:51] <MTecknology> imbrandon: it has been for about 1yr :P
[02:51] <MTecknology> binarymutant: I'm not going for motuy
[02:51] <binarymutant> MTecknology, have you applied for it yet? 8+ hours seems like a lot
[02:51] <ScottK> OTOH, stuff that used to take me an hours or two is sometimes the work of minutes now that I know more.
[02:51] <MTecknology> binarymutant: not working on motu
[02:51] <imbrandon> ScottK: :)
[02:52] <binarymutant> MTecknology, oh
[02:52] <imbrandon> ScottK: work smarter, not harder ! right ?
[02:52] <MTecknology> launchpad.net/ubuntu-drupal launchpad.net/drupal-projects launchpad.net/~mtecknology
[02:52] <MTecknology> binarymutant: ^
[02:52] <ScottK> Absolutely, but you've got to get up the learning curve first.
[02:52] <ScottK> MTecknology: It seems very strange to me to call something ubuntu-drupal when it's not in Ubuntu?
[02:53] <MTecknology> binarymutant: I'm going for bug control
[02:53] <MTecknology> ScottK: hm?
[02:53] <imbrandon> MTecknology: good work, i'd love to see ubuntu's drupal support come upto snuff before the next LTS, lord knows its sadly lacking
[02:53] <imbrandon> would make my package management for work manytimes lighter :)
[02:53] <MTecknology> imbrandon: ScottK: wiki.profarius.com/UbuntuDrupal
[02:54] <ScottK> This topic does not exist yet
[02:54] <binarymutant> MTecknology, the TOS on your site is pretty long :/
[02:54] <MTecknology> binarymutant: profarius.com?
[02:54] <binarymutant> ya
[02:55] <MTecknology> err.....
[02:55] <imbrandon> bad link
[02:55] <MTecknology> wiki.ubuntu.com/UbuntuDrupal
[02:55]  * imbrandon wonders why he got pointed to the wiki
[02:55] <imbrandon> heh
[02:56] <MTecknology> explaining that ubuntu-drupal isn't it's own package
[02:57] <imbrandon> great goals , only one huge huge huge missing one that keeps fortune 500 companies like the one i work for from using the Drupal in Ubuntu vs a Ubuntu Server + Drupal from drupal.org
[02:57] <imbrandon> MTecknology: yea i'm pretty familiar with how ubuntu packages drupal, its my "day job" per se
[02:58] <imbrandon> basicly that its 7 major revisions behind, a no no for security. so we roll our own for our clients like cartoonnetwork.de that just launched
[02:59] <imbrandon> and others
[03:00] <MTecknology> imbrandon: my drupal installs use latest source
[03:00] <MTecknology> imbrandon: but ubuntu-drupal is an installation profile
[03:00] <ScottK> Which gets back to a thing called ubuntu-drupal that doesn't use the Ubuntu Drupal.
[03:00] <ScottK> It seems wrong to me.
[03:01] <imbrandon> hrm, yea very wrong
[03:01] <MTecknology> ScottK: oh, that's what you meant
[03:01] <ScottK> Yes.
[03:01] <MTecknology> ScottK: it doesn't matter whether use use latest or ubuntu version
[03:02]  * ScottK suspects that if all the people doing work to not use the Ubuntu Drupal package put a small fraction of that effort into maintaining the Ubuntu package, it'd be quite usable for everyone.
[03:03] <MTecknology> ScottK: what?
[03:03] <imbrandon> ScottK: exactly, one thing i've had on my "todo" for 6 motnhs
[03:03] <imbrandon> bus alas back to the time thing :)
[03:03] <imbrandon> s/bus/but
[03:03] <ScottK> I hear pretty regularly about "We use upstream drupal because the Ubuntu package is x, y, z ..."
[03:04] <imbrandon> ScottK: yea, its not even useable
[03:04] <ScottK> If those people would help out with the Ubuntu package, they would save time and effort in the long run and make things better for everyone.
[03:04] <MTecknology> I think you're confused - the Ubuntu-Drupal package is a set of modules and a theme (installation profile) for drupal sites - aimed at LoCo teams
[03:04] <imbrandon> MTecknology: yes we did at first, i think thats a very wrong name
[03:05] <MTecknology> It used to be called Drupal-LoCo
[03:05] <ScottK> MTecknology: You also mentioned using upstream drupal for your installs and not the Ubuntu package.
[03:05] <MTecknology> but it's not a loco thing anymore so that's the name that everyone agreed on
[03:05] <imbrandon> it should be like ubuntu-drupal-modules and ubuntu-drupal-themes , and be targeted to the version in the repos
[03:05] <imbrandon> for ubuntu-drupal
[03:05] <ScottK> Agreed.
[03:06] <MTecknology> ScottK: I moved most of my drupal hosting to 1&1
[03:06] <imbrandon> right but your project is just some modules and themes, thus a very wrong project / package name has been choosen
[03:06] <imbrandon> IMHO
[03:06] <MTecknology> launchpad.net/ubuntu-drupal-theme ; code.launchpad.net/~ubuntu-drupal-modules
[03:07] <imbrandon> ok so it looks like its been started
[03:07] <imbrandon> whats the problem ?
[03:07] <MTecknology> ?
[03:07] <MTecknology> i never said there was
[03:07] <MTecknology> you guys started attacking it :P
[03:08] <imbrandon> not attacking, dont take it that way
[03:08] <imbrandon> irc is hard to convey feelings, no feelings, just sugestions
[03:08] <MTecknology> not exactly the word I meant
[03:08] <imbrandon> but that project/wiki for /UbuntuDrupal is named wrong IMHO, makes confusion
[03:10] <imbrandon> hrm, all this talk has me motivated to update the package
[03:10] <ScottK> \o/
[03:10] <imbrandon> ScottK: what point are we in the freeze/cycle ? i've been out for a few months
[03:10] <ScottK> imbrandon: Post beta.  Feature Freeze.
[03:11] <imbrandon> k, i'll make the updates now, but an upload looks like it will have to wait
[03:11] <ScottK> imbrandon: For a drupal update I can wave a magic wand over it and make it OK.
[03:11] <imbrandon> ahh nice , ok
[03:11] <MTecknology> lol
[03:11] <imbrandon> yea 6.3 is far too old to be usefull
[03:11] <ScottK> imbrandon: Just file a bug asking for a feature freeze exception with a little whining about how broken the current package is an ping me.
[03:12] <imbrandon> ScottK: kk
[03:15] <MTecknology> imbrandon: fyi - 99.999% of the time, I'm a "go with repo" guy - but with drupal, the way I set it all up just made more sense
[03:16] <imbrandon> MTecknology: understood, just trying to give a little advice from a long time ( and reciently inactive ) core-dev :)
[03:17] <imbrandon> nice its actually broken out into drupal{5,6} for jaunty :) makes updates MUCH easier it looks like
[03:17] <MTecknology> imbrandon: ya, I figure you know your stuff when every single change to the wiki gets emailed to you
[03:17] <imbrandon> MTecknology: hahah you noticed ?
[03:17] <MTecknology> ya
[03:17] <MTecknology> did you actually sign up for (.*) ?
[03:17] <imbrandon> actually i think i deavtivated all but a few pages a week or so ago
[03:18] <imbrandon> no not .* but i had ALOT
[03:18] <MTecknology> any reason for all of them?
[03:18] <MTecknology> I'm guessing you didn't read them all
[03:18] <imbrandon> at one point in time ( about 8 months ago ) i was a very active dev
[03:19] <imbrandon> easy to keep tabs in email IMHO
[03:19] <MTecknology> oh
[03:19] <MTecknology> almost done dloading updates for 8.10
[03:19] <imbrandon> job stole alot of my time, and i've slowly been ramping back up to speed
[03:20] <MTecknology> job in a year is going to rip away all my time
[03:20] <MTecknology> I've been trying to learn to code for drupal professionally so I can find a job either there on in it admin when I graduate
[03:21]  * ScottK imagines 'guy who maintains drupal for Ubuntu' would be a decent resume bullet.
[03:21] <imbrandon> yea, i'm a "professional" drupal module develoepr and wordpress plugin developer, if you can call it that, i get paid to code custom modules/plugins , so i guess i'm a "pro"
[03:21] <wgrant> ScottK: Bullet as in a way to kill it?
[03:22] <ScottK> Bullet as in item on a list, but maybe.
[03:22] <imbrandon> wgrant: bullet , as in a UL item
[03:22] <imbrandon> err <ul>
[03:22] <wgrant> I know, I know, I was just expressing my dislike of PHP.
[03:22] <imbrandon> ahhh :)
[03:22] <MTecknology> I like php
[03:23] <imbrandon> php pays the bills, so i cant compalin ( much )
[03:23] <imbrandon> i wish it would fix my typing
[03:25] <wgrant> Our development platform at $WORK is a nice combination of Python, PostgreSQL and Ubuntu. No PHP. It is good.
[03:25] <imbrandon> isnt ajmitch still makin a living with php too ?
[03:25] <ScottK> wgrant: dislike/realistic assessment
[03:25] <MTecknology> I don't like pgsql
[03:25] <wgrant> ScottK: Perhaps so.
[03:26] <wgrant> MTecknology: Why not?
[03:26] <imbrandon> ours is ubuntu LTS + apache + php5 + mysql/oracle ( and a standard eclipse ide with pdt installed )
[03:26] <imbrandon> wgrant: ^^
[03:26] <wgrant> It is hugely better than MySQL.
[03:26] <MTecknology> wgrant: they way it works feels akward
[03:26] <ScottK> I've consulted on some projects with really serious SQL people and they always prefer pg over mysql.
[03:26] <ScottK> wgrant: Consider he likes php and it all falls into place.
[03:26] <wgrant> ScottK: That's what I thought.
[03:26] <wgrant> MTecknology: How?
[03:27] <imbrandon> yea , mysql is still really young, its getting better with Sun's support, but still has a year or so to catch up to pg
[03:27] <MTecknology> wgrant: when I played with it everything I read was talking about creating a user for it and using a certain user to interact with it, etc
[03:27] <wgrant> MySQL claimed that it was a relational database for years before it had reasonable foreign key or transaction support.
[03:27] <wgrant> MTecknology: It happens to have a pluggable security model, the default mode of which uses local user accounts (ident) authentication.
[03:28] <imbrandon> yea no transactions and/or stored proc was a killer for a long time
[03:28] <MTecknology> wgrant: oh - so if I changed that it woulda behaved the same?
[03:28]  * ScottK recalls being in a conversation with a customer that was an all mysql shop and the project was being prototyped using pg.  They wanted to switch.  The answer was double the development time and the number of developers essentially.
[03:28] <imbrandon> wow
[03:29] <ScottK> IIRC it was lack of a CIDR data type that was the killer for that project.
[03:29] <wgrant> MTecknology: It can behave almost identically to MySQL  with regard to authentication, but it's more flexible.
[03:29] <MTecknology> oh
[03:29] <MTecknology> maybe someday I'll play with it again
[03:29] <MTecknology> atm - mysql does the job very well for me
[03:29] <imbrandon> wget http://ftp.drupal.org/files/projects/drupal-6.10.tar.gz
[03:29] <imbrandon> errr
[03:29] <ScottK> Oh, forgot.  Also twice as much hardware too.
[03:30] <MTecknology> why more hardware??
[03:30] <MTecknology> is'mt pgsql supposed to be lighter/faster?
[03:30] <ScottK> Because pg was substantially faster at what we were doing.
[03:31] <wgrant> Does anybody know of any benefits that MySQL has over PostgreSQL? Apart from some rumoured PG speed issues that go away with tweaking...
[03:31] <wgrant> Plus, until yesterday, there weren't a dozen approximately equal PostgreSQL forks.
[03:31] <imbrandon> wgrant: project support, if your not doing it from scratch most everything support ( only sometimes ) MySQL
[03:31] <ScottK> wgrant: You can only install one version at a time in Debian, so those multiple version transition issues go away.
[03:32] <wgrant> ScottK: What version issues?
[03:32] <ScottK> wgrant: That was sarcasm.  I think a great feature of the pg packaging in Debian/Ubuntu is you can have multiple versions installed at the same time.
[03:32] <wgrant> ScottK: Ahhh, I see.
[03:32] <ScottK> I think the mysql packaging is more basic.
[03:33] <imbrandon> ScottK: well yea but MySQL runs multi instances with one ( set of ) binaries
[03:33] <imbrandon> so no real need for more than one
[03:33] <wgrant> MySQL packages are versioned, but 4.1 and 5.0 weren't coinstallable IIRC.
[03:33] <ScottK> Yes.
[03:33] <wgrant> That is, the package names are versioned.
[03:34] <wgrant> That was very WTFy.
[03:34] <ScottK> And 5.0/5.1 are in Ubuntu, but not Debian and I doubt that will last.
[03:34] <imbrandon> ahh you ment diffrent versions not just diffrent instances of it
[03:34] <ScottK> Yes
[03:34] <imbrandon> debian has no 5.x ?
[03:34] <imbrandon> ouch
[03:34] <ScottK> Debian has 5.1 in experimental.
[03:35] <imbrandon> wow, now i rember why i run ubuntu lts vs debian
[03:35] <imbrandon> 5.x has been out and stable for AGES
[03:35] <MTecknology> I have asp.net - it makes idiots think they have a clue how to write code
[03:35] <MTecknology> http://pastebin.com/d3647f3b3
[03:36] <savvas> what does that code do? :)
[03:36] <imbrandon> asp.net isnt too bad
[03:36] <MTecknology> savvas: right now, it breaks horribly
[03:36] <imbrandon> savvas: nothing, thats the html markup , the real code is in the accompanying .cs filer
[03:36] <imbrandon> files*
[03:37] <MTecknology> http://www.dsustuff.com/cbarne/Lab8/Default.aspx
[03:37] <savvas> imbrandon: so there's a <script> somewhere in the html file that the server processes?
[03:38] <savvas> aaaah wait
[03:38] <savvas> I got it :P
[03:38] <imbrandon> not really, its named the same as the aspx, like Default.cs , and the webserver looks for it on run, and compile Default.dll and uses is like a MVC kinda thing
[03:38] <imbrandon> asp.net is its own beaste
[03:39] <imbrandon> ( or Default.vb , if you want VB.net vs. C#.net code )
[03:39] <imbrandon> etc
[03:39]  * wgrant stabs VB a few times.
[03:40] <imbrandon> or Default.php if using PHP.net or Default.py for IronPython, etc. any .net compatable lang )
[03:40] <imbrandon> you get the point
[03:40] <savvas> yep :)
[03:40] <savvas> thanks
[03:40] <wgrant> PHP.net?
[03:40] <wgrant> I want to go and kill somebody.
[03:40] <imbrandon> 99% of asp.net code is done in c# though from what ive seen personaly
[03:41] <MTecknology> i did asp.net coding for a year and never saw its worth
[03:41] <imbrandon> wgrant: yea PHP and Python and Ruby etc all have .net counterparts/msil compilers
[03:42] <imbrandon> dunno why one would use them, but they exist and are "supported"
[03:42] <imbrandon> so really asp.net can be any language as long as it can be compiled into msil
[03:55] <MTecknology> GAH!
[03:56] <MTecknology> did this thing already get patched?
[03:56] <MTecknology> I've been trying to reproduce and fix this thing for about 8hr today
[04:00] <MTecknology> hopfully 8.10 -> 9.04 reproduces the error and I can pause the thing, create a snapshot, and then fight with it more
[04:02] <AirBender> Hello guys
[04:02] <AirBender> I'm having problems with some documentation packages
[04:02] <AirBender> I think they're all from universe repo
[04:03] <AirBender> the problem is triggered with a mal formed install-info command in the postinst script of the packages
[04:03] <AirBender> the command lacks an argument with the destination directory
[04:03] <ScottK> AirBender: What packages?
[04:03] <AirBender> for example...
[04:03] <ScottK> Please pastebin the exact errors.
[04:03] <AirBender> texlive-base-bin-doc
[04:03] <AirBender> ok
[04:04] <AirBender> I will reproduce the last one, executing the command)I've commented it in the postinst script=
[04:08] <AirBender> http://pastebin.ubuntu.com/143246/
[04:09] <AirBender> I have install-info 4.9 in my system
[04:10] <AirBender> running jaunty, but I have the problem since intrepid
[04:10] <AirBender> amd64
[04:10]  * hyperair_ wonders what install-info is
[04:10] <MTecknology> !info install-info
[04:10] <MTecknology> !info install-info jaunty
[04:11] <hyperair_> lol
[04:11] <AirBender> the package is texinfo
[04:11] <MTecknology> !find install-info
[04:11] <MTecknology> oh
[04:11] <hyperair> ooh cool
[04:12] <AirBender> I think it manages how the information for the info "package" command is installed
[04:12] <hyperair> ah
[04:13] <hyperair> so what's this about anyywa
[04:13] <DanMcGoo> hi
[04:13] <DanMcGoo> I have a litlle problem with dpkg-buildpackage
[04:13] <AirBender> for me is quite useless so far, but it's really anoying having to manually edit the postinst files anytime them fail
[04:14] <DanMcGoo> it build my package correctly, but its exit code seems to be an error
[04:14] <DanMcGoo> does anyone know why ?
[04:15] <dtchen> DanMcGoo: you'll need to provide full output from the dpkg-buildpackage invocation
[04:15] <dtchen> some of us are good at guessing, but you probably don't want that
[04:16] <DanMcGoo> ok, so how can I provide the full output ?
[04:16] <dtchen> e.g., pastebin
[04:17] <hyperair> !pastebin
[04:17] <DanMcGoo> yep I found it
[04:17] <DanMcGoo> actually should I provide you evrything or only the last lines ?
[04:17] <dtchen> full output
[04:18] <DanMcGoo> I don't think the make ouput will help you so much as far as my package builds correctly
[04:18] <DanMcGoo> ok ^^
[04:19] <AirBender> ScottK: nano is another example, but I think this isn't from universe, so I was wrong about that.
[04:19] <ScottK> Also nano is in the default install, so if it was generally broken and not just on your system, I think someone would have noticed.
[04:21] <AirBender> yes, that's what can't understand, since I have seen some other reports about that, but not as much as I think there should be
[04:23] <ScottK> AirBender: Does /usr/share/info/dvips.info exist?
[04:23] <AirBender> it's gzipped but yes
[04:25] <MTecknology> Hurray, finally installing the 8.10->9.04 updates in my vm
[04:25] <MTecknology> I'm getting really excited to hit this error
[04:25] <DanMcGoo> done it, here it is: http://pastebin.ubuntu.com/143249/
[04:29] <AirBender> oh my God!!
[04:29] <DanMcGoo> I'm going out for lunch< i will be back in 1 hour I think
[04:29] <AirBender> I found it
[04:29] <DanMcGoo> c u
[04:29] <AirBender> after a year
[04:31] <AirBender> the problem is I have manually compiled texinfo a year ago
[04:31] <dlynch> hi, this morning my jaunty install hard locked up without warning, and it no longer boots from the ext4 partition in which it was installed. This seems like a serious bug worth investigating, but to be frank, I don't know how to approach this the best way. Should I boot from the most recent live CD of jaunty and try to take a look at some log files or something?
[04:32] <AirBender> and it seems the newer version needs the directory to be explicitly given
[04:32] <AirBender> I have renamed the /usr/local/ version of install-info and now it doesn't fail
[04:32] <AirBender> the compiled version is from 2007 and the ubuntu version is from 1995
[04:35]  * imbrandon goes to check on the wordpress versions
[04:35] <ScottK> dlynch: You should ask in #ubuntu+1
[04:35] <dlynch> ScottK ok, thanks and sorry for the noise
[04:37] <MTecknology> !info texlive
[04:38] <AirBender> ScottK: what do you think about this issue?
[04:38] <MTecknology> How do list dependencies for a package?
[04:38] <ScottK> AirBender: It sounds like you installed something that caused a problem and removed it.
[04:39] <AirBender> sure, it's clear, but why is ubuntu using such an old version of install-info
[04:39] <imbrandon> AirBender: no one in debian or ubuntu has taken the time to update it :) go for it , heh
[04:39] <AirBender> haha lol
[04:40] <AirBender> but the problem isn't that simple, because all the packages should be updated first
[04:40] <AirBender> and dh_install-info script
[04:41] <imbrandon> exactly why it prob hasent been done yet
[04:42] <AirBender> I think a good starting point could be to change the dh_install-info behavior, since the packagers use it to automatically generate this commands
[04:43] <AirBender> and then on the next release, all the packages will be correctly generated for the use of the newer install-info versions
[04:43] <AirBender> but I'm not a "Master of the Universe", so I could be missing some important details lol
[04:48] <AirBender> Ok, time to Sleep, many thanks for your time ScottK
[04:49] <ScottK> AirBender: I think that's the start of a plan, but it takes someone to work on it.  Good night and you're welcome.
[04:51] <AirBender> I'll be glad to help, but think I don't have the nedded skiils yet
[04:51] <ScottK> Guess how you get them ....
[04:51] <ScottK> Note that this isn't something we'd consider now.  It'd be for Karmic.
[04:53] <StevenK> ScottK: So, why does clamd suck so memory? :-)
[04:53] <dtchen> DanMcGoo: there's nothing really wrong per se. it failed to sign (because you probably didn't specify an explicit key), but the deb is still there.
[04:54] <ScottK> StevenK: Which one?
[04:54] <AirBender> well, I will continue learning how to create my own packages, and will see if then I feel like I can do something useful for ubuntu
[04:54] <AirBender> Good night guys
[04:54] <StevenK> ScottK: 0.92.1
[04:54] <ScottK> StevenK: Because you should be using backports.
[04:54] <StevenK> But backports make me cry
[04:55] <ScottK> StevenK: I know that can be the case sometimes but for clamav you really want the latest.
[04:56] <ScottK> Actually once we update the 0.94.2 already in hardy-backports with a couple of security patches from the 0.95 release, I'm going to recommend it gets pushed to -security/-updates anyway.
[04:58] <StevenK> ScottK: That sounds like a plan
[04:58] <StevenK> Does 0.95 use less RAM?
[04:58] <DanMcGoo> dtchen: yes I know that the deb is here. And the signature failure is supposed to be only a warning...
[04:59] <ScottK> StevenK: Dunno.  I've been focused on does it crash and does it find virii (no and yes) and do all the rdepends build/work.
[05:00] <DanMcGoo> so is there a a way to bypass this problem ?
[05:01] <StevenK> ScottK: Heh. I've been trying to figure out if ClamAV has found anything. If it hasn't I was going to stop using it.
[05:05] <MTecknology> hrm - I'm starting to think that handling/fixing bugs isn't in my realm of should do's
[05:07] <ScottK> MTecknology: Why not?  It's generally a good path for getting started as an Ubuntu developer.
[05:08] <wgrant> It's a much better path than drowing us in new packages.
[05:09] <MTecknology> wgrant: new packages?
[05:10] <MTecknology> ScottK: I've been negleting my loco some(a lot)
[05:10] <MTecknology> ScottK: and I'm not really getting this stuff - but I suppose it's one of those massive learning curves and no realy easy way to start picking it up
[05:11] <ScottK> MTecknology: There is a significant learning curve.  Bug fixing is one way to get the smallest learning curve as you don't have to learn everything all at once as you do with packaging new stuff from scratch.
[05:12] <MTecknology> ScottK: I meant a huge learning curve with just bug fixing
[05:13] <ScottK> Right.
[06:36] <balarka> maco,  hi
[06:36] <maco> hi
[06:37] <balarka> just created a/c in launchpad and looking for bugs
[06:37] <balarka> could you help me find simple ones
[06:37] <balarka> plzz
[06:39] <balarka> maco, as yesterday daniel was mentioning we need to search in launchpad
[06:39] <balarka> maco, right?
[06:40] <maco> balarka: http://qa.ubuntu.com/reports/launchpad-database/unfixed-bugs-with-patches.html
[06:40] <maco> take a look at that link
[06:40] <balarka> maco, sure..
[06:40] <maco> those bugs have patches attached but not necessarily debdiffs
[06:40] <maco> you can create debdiffs out of the patches
[06:41] <maco> just like last night
[06:41] <balarka> maco, how do you know if the patches are attached to them?
[06:41] <balarka> maco, did they mentioned anywhere?
[06:41] <maco> when you add an attachment there's a checkbox that says "this attachment is a patch"
[06:42] <balarka> ooh
[06:42] <balarka> got it
[06:42] <balarka> let me pick one
[06:42] <balarka> maco, what does the status field indicate?
[06:43] <maco> ...the status?
[06:43] <maco> of the bug
[06:43] <balarka> oh
[06:43] <maco> https://wiki.ubuntu.com/Bugs/Status
[06:43] <balarka> so they confirmed it as a bug
[06:43] <balarka> right?
[06:43] <maco> yes
[06:44] <maco> triaged means there's enough info there to work on fixing it
[06:44] <balarka> ooh
[06:44] <AnAnt> Hello, if upstream got a NEWS & Changelog file, which is better to install as upstream changelog ?
[06:44] <AnAnt> usually NEWS has a summarized list of changes (which I think is more interesting to users), and Changelog has detailed changelog (that I think is more interesting to those interesting in development itself)
[06:45] <balarka> maco, so i picked this one https://bugs.launchpad.net/ubuntu/+source/sepolgen/+bug/352610
[06:45] <balarka> maco, from this how to proceed.. i could not find any resources like source
[06:46] <maco> balarka: apt-get source sepolgen
[06:46] <dholbach> good morning
[06:46] <maco> hi dholbach
[06:46] <dholbach> hi maco
[06:46] <balarka> hi dholbach
[06:46] <dholbach> hiya balarka
[06:46] <balarka> good morning too
[06:47] <balarka> dholbach, i am on my way to fix a bug.. (my first bug ever!)
[06:47] <maco> dholbach: is it summer time or are you up early?
[06:47] <balarka> dholbach,  i failed to do it yesterday :(
[06:47] <maco> eh, practice, right?
[06:47] <dholbach> maco: summer time, 7:47
[06:48] <dholbach> balarka: enjoy it :)
[06:48] <balarka> dholbach, just want to know if you guys can help me a bit
[06:48] <dholbach> just ask
[06:48] <balarka> dholbach, maco  i picked this bug: https://bugs.launchpad.net/ubuntu/+source/sepolgen/+bug/352610
[06:48]  * dholbach might be on and off though
[06:48] <balarka> dholbach, sure.. thanks!
[06:48] <maco> dholbach: the dog?
[06:49] <dholbach> maco: and other stuff I need to get done today
[06:49] <maco> ah! gsoc proposals,,,right
[06:49] <dholbach> eh?
[06:50] <maco> dholbach: summer of code proposals are due today. i need to write mine
[06:50] <dholbach> ah ok
[06:51] <Kamping_Kaiser> hi all. is there an easy way to determine if the debconf settings on postgres changed between the version in hardy and hardy-backports?
[06:51] <balarka> dholbach, maco i did sudo apt-get source sepolgen
[06:51] <balarka> and got the source
[06:51] <maco> balarka: not sudo
[06:51] <balarka> but sudo worked
[06:51] <maco> but it set the permissions all to root
[06:51] <balarka> i mean i got the source downloaded
[06:51] <maco> which means you cant operate on it
[06:51] <balarka> oh
[06:52] <dholbach> Kamping_Kaiser: which source package?
[06:52] <balarka> oh ok
[06:52] <balarka> deleted and got it again
[06:52] <balarka> without sudo
[06:52] <maco> ok
[06:52] <balarka> and whatz next
[06:52] <maco> get the patch
[06:52] <maco> and pull up the logs from last night
[06:52] <Kamping_Kaiser> dholbach, er, not sure. I'll have to go and check. (thought there might be a generic thing, not package specific)
[06:52] <balarka> you mean use patch -i ?
[06:52] <balarka> right?
[06:53] <dholbach> balarka: did you check out  https://wiki.ubuntu.com/PackagingGuide/Recipes ? there should be some helpful stuff in there too
[06:53] <balarka> dholbach, nope.. i am going through it now
[06:53] <balarka> dholbach, thanks
[06:54] <dholbach> rock on
[06:54] <balarka> dholbach, will be back to chat after reading it
[06:54] <balarka> :)
[06:54] <maco> balarka: i meant download the patch thats attached to the bug
[06:55] <balarka> maco, oh ok
[06:55] <dholbach> Kamping_Kaiser: there's this diff functionality on https://launchpad.net/ubuntu/+source/postgresql-8.3 for example
[06:55] <dholbach> Kamping_Kaiser: if you know which package to look for, it would give you the quickest results, I guess
[06:55] <Kamping_Kaiser> dholbach, thanks. I'll go and have a play around.
[06:56] <dholbach> super
[06:59] <Kamping_Kaiser> i thought they'd fixed launchpad timeouts. *mutter*
[06:59] <balarka> maco, how can i download the patch.. its not attached to the bug from the bug link
[07:00] <balarka> maco, i am sorry if you told me how to do that before
[07:00] <maco> balarka: yes it is. look on the right side
[07:00] <maco> there's a "bug attachments" section
[07:00]  * Amaranth wonders what the trick to building the wine package on 64-bit is
[07:01] <balarka> oh ok
[07:01] <maco> Amaranth: that's possible?
[07:02] <Amaranth> maco: sure, it gets built as a 32-bit binary
[07:02] <maco> oh
[07:02] <Amaranth> but it still puts libraries in lib for me instead of lib32
[07:02] <Amaranth> so dh_install fails
[07:02] <balarka> maco,  i got the patch now ?
[07:02] <balarka> i need to get the diff right?
[07:03] <Amaranth> maco: There is sort of support for 64-bit too but you can't run 32-bit apps on a 64-bit build so it is a bit worthless
[07:04] <balarka> dholbach, do you have a page where we get all the steps we did yesterday?
[07:04] <balarka> i mean web link for that
[07:04] <maco> balarka: https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-02
[07:04] <dholbach> balarka: just the log, but the stuff in PackagingGuide/Recipes should be similar
[07:05] <maco> balarka: a patch is a diff
[07:05] <maco> usually it's "diff -uN"
[07:05] <balarka> dholbach, the recipes doesnt show how to appoly a patch
[07:05] <balarka> *apply
[07:06] <dholbach> right, but other than that the "Debdiff" one should be fairly similar
[07:07] <balarka> dholbach, so i got the source package from apt-get source
[07:07] <balarka> dholbach,  and the command dget -xu that we used
[07:07] <balarka> dholbach, yesterday are both of them same?
[07:08] <maco> essentially, yes
[07:08] <balarka> becoz on apt-ge source also got me .dsc
[07:08] <balarka> and other fiels
[07:08] <balarka> maco, ooh cool
[07:08] <maco> apt-get source gets the ones for whatever version of ubuntu you're running
[07:08] <balarka> oh perfect
[07:08] <dholbach> check out "man dget" for more info too
[07:08] <maco> the dget way is how you do it for versions other than the one you're running, so if you're on intrepid and wantto work on jaunty's package...
[07:08] <maco> of course, dget requires that you know where the dsc is online. you can find them on packages.ubuntu.com
[07:10] <balarka> oh ok
[07:10] <balarka> yes.. for that we need to know the link of package
[07:11] <balarka> and one another ques.. i want to install bzr
[07:11] <balarka> can u suggest a latest version of it
[07:11] <balarka> yesterday i am pretty sure.. i could not proceed after that
[07:11] <maco> dholbach ditched bzr on the howto yesterday when he realized there were intrepid users
[07:11] <balarka> i would like to use bzr now and thereafter
[07:11] <balarka> maco, ooh
[07:12] <maco> but anyway, look in the log, there's a link to the bzr ppa
[07:12] <balarka> bzr doesnt work for intrepid is it?
[07:12] <maco> there's bzr going pretty far back, its just that the new version on the server and the old version in intrepid are incompatible
[07:12] <balarka> you mean https://launchpad.net/~bzr/+archive/ppa
[07:12] <maco> yes
[07:12] <balarka> oh ok
[07:13] <maco> go to that website and itll tell you how to add it
[07:13] <balarka> oh ok
[07:13] <maco> next week's lesson is on a particular bzr feature, so its good to install it
[07:14] <maco> you'll be prepared
[07:14] <balarka> maco,  yes
[07:14] <balarka> true
[07:14]  * maco can't wait for the lesson on the 23rd
[07:14] <balarka> maco, one fundamental ques.. i use ubuntu 8.. so its draper drake?
[07:15] <maco> no
[07:15] <balarka> maco, pardon my ignorance
[07:15] <maco> 8 which?
[07:15] <maco> 8.04 or 8.10?
[07:15] <balarka> 8.10
[07:15] <maco> there is no "8"
[07:15] <maco> ok thats intrepid
[07:15] <maco> dapper is 6.06
[07:15] <balarka> oh ok
[07:15] <balarka> how to check the ubuntu version?
[07:15] <balarka> at command line
[07:15] <balarka> ?
[07:16] <dholbach> lsb_release -a
[07:16] <maco> balarka: lsb_release -a
[07:16] <balarka> oh ok
[07:16] <balarka> oh.. it says mine is hardy :P
[07:16] <balarka> its 8.04
[07:17] <maco> ok then
[07:18] <balarka> where will be the sources.list located?
[07:18] <maco>  /etc/apt/sources.list
[07:19] <balarka> oh ok
[07:19] <balarka> thanks
[07:22] <balarka> maco,  i got bzr 1.13
[07:22] <balarka> so how to proceed with it?
[07:22] <balarka> from here
[07:23] <maco> well you dont need bzr for what you're doing because the patch is its own file
[07:24] <maco> so anyway, see where the logs talk about "patch -p1"?
[07:24] <maco> do that stuff
[07:28] <balarka> maco, patch -p1 < ~/patch
[07:28] <balarka> can you explain me this command
[07:28] <balarka> what it does
[07:28] <balarka> i know patch is keyword command
[07:28] <balarka> what is p1
[07:30] <dholbach> check out   man patch
[07:30] <balarka> ok
[07:34] <balarka> dholbach, do i need to copy the patch into the package dir to appoly it?
[07:34] <dholbach> balarka: no
[07:37] <balarka> File to patch: sepolgen-ubuntu.patch
[07:37] <balarka> patching file sepolgen-ubuntu.patch
[07:37] <balarka> Hunk #1 FAILED at 313.
[07:37] <balarka> 1 out of 1 hunk FAILED -- saving rejects to file sepolgen-ubuntu.patch.rej
[07:37] <balarka> i got this when i tried to do:
[07:37] <balarka>  patch  < /home/balarka/bug1/sepolgen-ubuntu.patch
[07:38] <balarka> dholbach, can you tell me what wrong i did here
[07:39] <dholbach> balarka: it's a problem we had in the session too - if you read up in the log you'll see what I said about patches not applying cleanly any more
[07:39] <dholbach> balarka: in that case you need to review the patch and apply the changes manually in the code
[07:40] <maco> or at least fix the context lines of the patch so itll apply
[07:40] <balarka> dholbach, so patches not applying cleanly means is there err from our side?
[07:40] <maco> it means the patch was made against a different version of the code than we have
[07:40] <maco> so you need to massage it a bit to make it apply
[07:40] <balarka> maco, oh
[07:41] <balarka> oh ok
[07:41] <balarka> and the diff patch says:
[07:41] <balarka> @@ -313,7 +313,7 @@
[07:41] <dholbach> balarka: https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-02 - at around 07:57
[07:41] <balarka>
[07:41] <balarka>      def __len__(self):
[07:41] <balarka>          """Return the unique number of role allow statements."""
[07:41] <balarka> -        return len(self.roles)
[07:41] <balarka> +        return len(self.role_types.keys())
[07:41] <balarka>
[07:41] <balarka>      def add(self, role, type):
[07:41] <balarka>          if self.role_types.has_key(role):
[07:42] <balarka> oh ok
[07:42] <balarka> dholbach  so you said "I updated it to apply cleanly"
[07:42] <balarka> dholbach, so you massaged it right?
[07:42] <mrooney> What is the proper way to get a packaging branch into a source package to build it? doing something like "bzr export sourcepackage lp:package/packaging" doesn't work because you can't seem to export to an existing directory
[07:43] <balarka> dholbach, as per yesterdays lo
[07:43] <balarka> log
[07:43] <dholbach> mrooney: try installing bzr-builddeb and see if     bzr bd -- -S works for you :)
[07:44] <dholbach> balarka: yes, as I said https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-02 - at around 07:57 :-)
[07:44] <balarka> yes.. i read that
[07:44] <mrooney> dholbach: oh okay, how does that know where the packaging branch is?
[07:44] <dholbach> mrooney: just check out the branch, then try that command
[07:44] <balarka> dholbach, so you suggest any editor to dig into python's code to edit manually
[07:45] <dholbach> right-o
[07:45] <balarka> dholbach, i heard in pythong a tab plays major role
[07:45] <mrooney> dholbach: checkout, or export?
[07:45] <dholbach> mrooney: checkout
[07:46] <dholbach> balarka: yep
[07:46] <balarka> dholbach, can you suggest an  editor pls
[07:46] <dholbach> any will do
[07:46] <balarka> oh ok
[07:46] <dholbach> just go and play with it for a bit
[07:46] <balarka> sure..
[07:47] <balarka> and in the diff file .. as you said how can we identify which one needs to be
[07:47] <balarka> replaced with
[07:47] <balarka> the existing code
[07:47] <mrooney> dholbach: missing changelog error?
[07:47] <dholbach> mrooney: which branch?
[07:47] <mrooney> lp:wxbanker/0.5
[07:48] <dholbach> mrooney: erm... that's not a "packaging branch" - there's no "debian/" in there :)
[07:48] <mrooney> oh I do that from the packaging branch?
[07:48] <mrooney> I see :)
[07:49] <dholbach> if you keep it all in a branch anyway, I'd just add another branch that includes the debian/ stuff - WDYT?
[07:50] <maco> balarka: its possible the comment line before it changed or maybe the line after the changes. look for things like that
[07:51] <maco> oh he's gone ok
[07:52] <mrooney> dholbach: I see, this seems functional, but I want to grab the upstream
[07:53] <dholbach> mrooney: you still can...  "bzr pull <upstream branch>"  and you should be all set
[07:53] <mrooney> so that I can build it for ubuntu
[07:53] <dholbach> mrooney: you won't even get conflicts if all you do in that packaging branch is just adding debian/ :)
[07:54] <mrooney> dholbach: okay let me take a step back, I check out the packaging into say, build/, so I have build/debian
[07:55] <mrooney> now I pull the upstream into build, then run bd?
[07:56] <dholbach> as far as I know, "bzr bd" will first try getting an upstream tarball via debian/watch, then try to see if the orig tarball in the archive fits
[07:56] <dholbach> james_w is a good person to talk to about this :)
[07:57] <mrooney> dholbach: oh I see, I don't care about an upstream tarball here, I want to get trunk
[07:57] <dholbach> I personally think I'd just get branch off of upstream, add the packaging in there and use that branch as a basis
[07:57] <mrooney> I want to say automate a nightly build
[07:58] <dholbach> if you track upstream in a bzr branch anyway, I don't think it makes sense to have a branch that just contains "debian/"
[07:59] <mrooney> oooh
[07:59] <mrooney> dholbach: where should the packaging go then?
[08:00] <dholbach> bzr checkout upstream; bzr branch upstream jaunty-package; cd jaunty-package; cp -r ~/packaging/debian .; bzr add debian
[08:00] <dholbach> does that make sense? :)
[08:02] <mrooney> ...maybe
[08:02] <mrooney> dholbach: can you check out my short script at http://paste2.org/p/176741 and tell me if I am doing anything stupid
[08:03] <dholbach> or just    bzr branch lp:upstream jaunty-package
[08:03] <mrooney> the idea is you would run it like ./builder.sh 0.5 ~ppa1
[08:03] <mrooney> so $1 is the series and $2 is the version modifier
[08:03] <dholbach> then you should always be able to bzr pull from lp:upstream
[08:04] <dholbach> you can do that, of course - I just think the other thing might be easier
[08:04] <mrooney> lines 5-7 is basically my original question, of if there was a better way to do that
[08:05] <mrooney> dholbach: okay, it feels backwards to generate the orig.tar.gz from the source, is that the correct way to do this in this case?
[08:06] <dholbach> once you have it set up, you'd just run:       bzr merge lp:upstream; bzr commit -m "merge with upstream"; dch -v `bzr revno` "New Upstream checkout."; bzr bd -- -S; cd ..; dput ppa *.changes
[08:07] <dholbach> mrooney: but if your approach works, just go ahead with it
[08:08] <dholbach> there's also some autoppa project in LP somewhere which does something like this
[08:09] <mrooney> dholbach: oh right yes
[08:09] <mrooney> well I will try this and see how it works, thanks for letting me know at least it isn't insane
[08:10] <dholbach> it could absolutely be worse ;-)
[08:10] <mrooney> I am thinking of making a testing ppa, and setting up a server which gets notified on commits, runs the tests, and if they pass, builds and uploads to the ppa
[08:11] <mrooney> it seems like a fun continuous deployment adventure!
[08:43] <Toadstool> good morning
[09:55] <savvas> good morning!
[09:55] <iulian> Morning
[10:17] <savvas> there's a problem with python3.0 and python3.0-minimal in jaunty: http://paste.ubuntu.com/143374/plain/
[10:18] <dholbach> savvas: https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/354228
[10:19] <savvas> ah cool, thanks :)
[10:30] <savvas> about bug 337696 - there's a patch, but ubuntu foundations team is assigned to it, do I have to subscribe ubuntu universe sponsors?
[10:30] <savvas> https://launchpad.net/bugs/337696
[10:56] <savvas> DktrKranz: about bug #340901, can I ask for an FFe instead? I made a 0.0.3 release: http://launchpadlibrarian.net/24733041/gapti-dsc_and_tar-gz.tar.gz
[11:08] <DktrKranz> savvas: are changes related to Python 2.6 only?
[11:20] <savvas> DktrKranz: I don't know what you mean, but there are no improvements, other than proper packaging for python 2.6 :) here are the changes introduced: http://paste.ubuntu.com/143395/
[12:50] <wintellect> Hi all
[12:52] <wintellect> I'm looking at giving back to the ubuntu community by getting involved in pkgs. I have been reading https://wiki.ubuntu.com/PackagingGuide/Basic but do not understand something. Which file(s) are submitted for approval for a pkg? Is it the .dsc?
[12:53] <directhex> wintellect, a "debian source package" is made from three files. the dsc is essentially useless on its own - but it the file which you sign with your GPG (when relevant) and contains shortcuts to the other two (for simplicity)
[12:54] <directhex> the "orig" is the original upstream tarball, repackaged as a .tar.gz if required. you should submit it so people can verify that the source is definitely legal & licenses followed, and that there are no undistributable parts in it
[12:54] <directhex> the "diff" is a patch containing all changes you make - which should usually mean all the packaging specifics (the debian/ folder)
[12:56] <wintellect> directhex: thank you - that is very helpful to know and understand. I have a small app I wrote that i am looking to learn pkg building with and perhaps I'll submit it one day. Again, thank you.
[13:20] <mok0> DktrKranz: ping
[13:39] <DktrKranz> savvas: no features, no need for FFe then
[13:39] <DktrKranz> mok0: pong
[13:39] <mok0> DktrKranz: hi, just wanted to ask you to translate an italian bug report
[13:39] <DktrKranz> fire it
[13:40]  * mok0 tries to find it
[13:40] <mok0> bug 339965
[13:41] <savvas> DktrKranz: thanks, but what's the process? should I rename the title to use that new version?
[13:42] <mok0> DktrKranz: what does "l'archivio del pacchetto è rovinato" mean?
[13:43] <DktrKranz> mok0: it's "package archive is broken"
[13:43] <mok0> DktrKranz: ah. This is not a bug then
[13:43] <mok0> DktrKranz: now I have you, I need an FFe :-P
[13:43] <DktrKranz> it seems not
[13:44] <DktrKranz> a partial download, probably
[13:44] <DktrKranz> mok0: and I need money! :)
[13:44] <mok0> DktrKranz: you have a paypal account??
[13:44] <DktrKranz> savvas: just find a sponsor, in the meantime you can rename it
[13:45] <DktrKranz> mok0: bank transfer, more clean ;)
[13:45] <mok0> Cayman Islands?
[13:45] <DktrKranz> luxembourg
[13:46] <mok0> DktrKranz: bug 334405
[13:46] <mok0> DktrKranz: Actually, this can be sync'ed, I found out.
[13:46] <savvas> DktrKranz: cool, thank you  :)
[13:49] <DktrKranz> mok0: which qt version we ship right now? (/me is not a KDE guy)
[13:49] <mok0> qt4
[13:50] <mok0> DktrKranz: It's using the latest qt version
[13:50] <DktrKranz> 4.5?
[13:51] <ScottK> Yes
[13:51] <mok0> DktrKranz: it's not a versioned depends, so the default version
[13:52] <DktrKranz> it has some rdependencies (as commented in the report), any impact on those?
[13:53] <mok0> DktrKranz: Stellarium 0.10 series is a serious update of the graphics interface. We have 0.10.0 in jaunty's archive, but it's really a beta version
[13:58] <mok0> DktrKranz: stellarium has no rdepends
[14:04] <mok0> DktrKranz: celestia is a standalone app, it Suggests: stellarium. Science-astronomy is a meta package that Recommends: stellarium and a bunch of other apps.
[14:09] <DktrKranz> mok0: indeed
[14:11] <DktrKranz> mok0: acked
[14:12] <DktrKranz> uh... kde3bindings needs adjustment for Py2.6, do we still support it?
[14:14] <iulian> mok0: Could you please give me the bug #?  I can have a look at it as well.
[14:14] <iulian> Oh, got it.
[14:15]  * iulian was looking in the wrong place.
[14:19] <iulian> mok0: Do you have a ChangeLog/NEWS file of stellarium?
[14:19] <iulian> I'd like to see what features brings this new upstream version.
[14:19] <ScottK> DktrKranz: I thought for KDE3 the Python bindings were in a seperate package?
[14:20] <iulian> s/features/new features/
[14:22] <DktrKranz> ScottK: after a quick look, kde3bindings has a python-dcop package, which needs love
[14:22] <ScottK> Ah.  Right.
[14:22] <DktrKranz> I don't know if it has to be managed separately, though.
[14:22] <ScottK> I'm not sure that even works anymore.
[14:22] <mok0> iulian: will check
[14:22] <ScottK> Kubuntu has no need of kde3bindings.
[14:22] <ScottK> It's only not removed in case of 3rd party scripts.
[14:23] <mok0> iulian: I think the 0.10.0 -> 0.10.2 change is mainly bug fixes
[14:23] <ScottK> There should be no rdepends in the archive at all.
[14:24] <DktrKranz> ScottK: so it could be demoted at this point
[14:24] <ScottK> It has been.  It's in Universe.
[14:24] <mok0> iulian: upstream's changelog is copied into the 2 comments by Jesper and Christ
[14:25] <DktrKranz> $ rmadison -u ubuntu -s jaunty -a source kde3bindings
[14:25] <DktrKranz> kde3bindings | 4:3.5.10-1ubuntu2 |        jaunty | source
[14:25] <DktrKranz> $
[14:25] <DktrKranz> it seems not
[14:25] <ScottK> Urgh.
[14:26] <ScottK> Should have been.  I'll look into it.
[14:28] <iulian> mok0: Oh, sorry, haven't noticed.
[14:29] <DktrKranz> ScottK: anyway, we're almost there. IIRC, only 5 package remaining, but they all FTBFS.
[14:29] <ScottK> Yep.
[14:30] <DktrKranz> They need NCommander strong hands :)
[14:31] <iulian> mok0: Accepted, please go ahead.
[14:31] <mok0> iulian: thanks!
[14:39] <ScottK> DktrKranz: Could you look at the gapti update?  From what I saw in the bug it seems like it might be a good idea.
[14:39] <mok0> I'm off into the sunshine, see you later!
[14:40] <DktrKranz> ScottK: sure
[14:44] <DktrKranz> savvas: is gapti in Debian?
[14:45] <ScottK> DktrKranz: IIRC it is, but hasn't been touched there in a LOOONG time.
[14:46] <savvas> DktrKranz: not as far as I can see: http://packages.qa.debian.org/g/gapti.html http://packages.debian.org/search?keywords=gapti
[14:46] <ScottK> DktrKranz and savvas: Nevermind.  I was thinking of a different package.
[14:47] <savvas> I honestly don't know if I should drop the whole gapti thing
[14:48] <savvas> I wonder if anyone is using it :)
[14:48] <ScottK> Dunno, but if there's a new upstream that addresses Python 2.6 compatibility we should probably have it.
[14:49]  * DktrKranz agrees.
[14:50] <savvas> ok, I guess it can last a bit longer hehe
[14:50] <DktrKranz> savvas: so it only needs pushing in Ubuntu, an easy one :)
[15:00] <savvas> true, I don't mind, at least I've learned how to use setup.py - useful for another project :)
[15:01] <savvas> how to write *
[15:08] <DktrKranz> savvas: :)
[15:24] <atrejut1> \join #ubuntu-devel
[15:24] <bddebian> Heya gang
[15:25] <ScottK> heya bddebian.
[15:28] <ScottK> directhex: Did you know monodevelop-java is currently uninstallable?
[15:31] <bddebian> Hi ScottK
[15:33] <directhex> ScottK, it's on my todo - meebey should upload 2.0-final packages this evening for most of monodevelop, which i prepared yesterday. they've been designed to be syncable despite some build-dep differences
[15:33] <ScottK> directhex: OK.  I've been going through uninstallables and wanted to make sure you knew.
[15:33] <directhex> ScottK, afaik the problem is an error in tightened binary deps, which don't allow for +dfsg in the binary-version
[15:38] <imbrandon> morning all
[15:38] <directhex> ScottK, i definitely fixed an issue with monodevelop-java hating +dfsg monodevelop last night in svn, so it's on the todo ;)
[15:39] <ScottK> OK
[15:39] <directhex> problem is, 3 of the monodevelop plugins are maintained in git, and i'm struggling to deal with those. git confuses my feeble brain :(
[15:46] <atrejut> hello all... I followed dholbachs packaging training session yesterday and decided to try what I learned on a separate bug (LP: #338158) which has an upstream patch, but somehow I'm running into trouble and need some help... is this the right place to ask?
[15:46] <jpds> Yes, absolutely.
[15:48] <atrejut> ok. so unlike the example bug in dholbachs session the package uses cdbs. so I used cdbs-edit-patch to add the patch. but when I run debuild it always tells me 'Patch debian/patches/egg-endless-loop.patch is not applied.'
[15:50] <atrejut> but manually I could apply it just fine, it's not that the patch doesn't apply really...
[15:50] <ScottK> DktrKranz: apt-cache unmet shows more that 5 for python 2.6 for me.
[15:52] <imbrandon> morning bddebian
[15:54] <bddebian> Heya imbrandon
[15:55] <DktrKranz> ScottK: xulrunner is going to be dropped, two need a-a to sync and one uploaded recently.
[15:55] <ScottK> DktrKranz: OK.
[15:55] <DktrKranz> there's a obsolete package too
[15:56] <ScottK> Did you file for removal?
[15:56] <DktrKranz> pyqwt, I need to figure out if it can be replaced by pyqwt5
[15:56] <DktrKranz> and the same for pyqwt3d
[15:57] <DktrKranz> they all FTBFS, though
[15:57] <ScottK> OK.  Well if it's broken and unfixable, then I'd say just remove it.
[15:57] <ScottK> Particulalry if it's Qt 3 and has no rdepends.
[15:57] <DktrKranz> two in a not sane way, and upstream is dead
[15:58] <ScottK> Out with them I say then.
[15:59] <DktrKranz> they've no rdepends
[15:59] <DktrKranz> (IIRC)
[16:00] <DktrKranz> for csound, its maint asked me to upgrade scons in debian (move from exp to unstable, actually), and we could sync it
[16:05] <atrejut> jpds: any ideas?
[16:05] <jpds> atrejut: Are you sure there's a patch system included in debian/rules?
[16:06] <atrejut> it lists 'include /usr/share/cdbs/1/rules/simple-patchsys.mk' (amongst others)
[16:07] <jpds> Hmm, odd.
[16:07] <ScottK> atrejut: Did you get the 'not applied' when making the source package only or also when building the .deb?
[16:07] <imbrandon> atrejut: are you shure it dident just inform you it hadent been applied yet and then applied it ? do you have the full output of the build ?
[16:08] <hyperair> easy way to test: run debian/rules patch
[16:09] <atrejut> hyperair: yes, that gives a success message
[16:10] <hyperair> atrejut: then it should work fine during build
[16:10] <imbrandon> ScottK: you know , i had an idea for a new "blueprint" i think you might be intrested in putting your 0.2c on ( i havent drafted it yet, it just came to mind last night )
[16:10] <ScottK> ?
[16:11] <atrejut> ok, so I can just ignore the debuild message? (http://paste.ubuntu.com/143527/ in case you want to look over it)
[16:11] <imbrandon> ScottK: ok background, you know we have 6month + LTS cycles, and a full rolling release is bad(tm) [ like gentoo ]
[16:11] <ScottK> atrejut: Yes.  Not applied is what you want for the source package.
[16:11] <atrejut> ScottK: ok, thanks, I was getting confused there...
[16:12] <ScottK> atrejut: No problem.  Better to ask.
[16:12] <imbrandon> ScottK: so the nightly build spec got me thinking why not have a subset ( maybe a special component ) for "rolling release packages" like clamav et al
[16:12] <imbrandon> or does backports fill that "ok" enough
[16:12] <ScottK> imbrandon: The problem with that is rdepends and you need differences between Ubuntu releases.
[16:12] <ScottK> I think it fills it OK enough.
[16:13] <imbrandon> ScottK: yea , i hadent thought it through yet, just came to me
[16:13] <ScottK> For example, with clamav you need different configs for Dapper, Gutsy/Hardy, and Intrepid/Jaunty.
[16:13] <ScottK> What we really need is a better way for people to install just a few select packages from backports.
[16:14] <imbrandon> true, that would be best
[16:14] <ScottK> mvo did some work on that for Jaunty, but it didn't quite make it.
[16:14] <imbrandon> cool ok
[16:15] <imbrandon> yea if we coudl get it in place before the next LTS it would rock
[16:15] <imbrandon> :)
[16:15] <ScottK> On my list for UDS.
[16:16] <imbrandon> adobe flash and a few webapps come to mind also, but you got the idea
[16:21] <ScottK> DktrKranz: kde3bindings is still in Main on purpose as it turns out.
[16:32] <DktrKranz> ScottK: oh, what it the reason?
[16:32] <ScottK> [11:20:35] <Riddell> ScottK: kde3bindings is in main for libsmoke1 used by perl-qt used by debconf
[16:33] <DktrKranz> yeah
[16:36] <imbrandon> libsmoke1 is used by php-qt too ( if i ever get arround to fixing it )
[16:45] <MTecknology> So, I want to use debootstrap, but I don't know where to grap the stuff for a mirror to keep the files on my system - anyone know where to get these files?
[16:47] <ScottK> DktrKranz: Have you got a list of bugs for the Python packages that still need doing?
[16:49] <DktrKranz> ScottK: I can sort it out very quicly
[16:51] <ScottK> DktrKranz: Thanks.  I got asked for a list at the release team meeting.
[16:52] <hyperair> MTecknology: pbuilder --create
[16:53] <hyperair> MTecknology: if you want a list of debian mirrors, it's in /usr/share/python-apt/templates/Debian.mirrors, and for ubuntu, it's in /usr/share/python-apt/templates/Ubuntu.mirrors
[16:53] <MTecknology> hyperair: thanks
[16:55] <hyperair> MTecknology: np
[16:55] <MTecknology> hyperair: oh... so I'd need to grab an entire repo(parts of it I want) to do that?
[16:56] <hyperair> MTecknology: what?
[16:56] <hyperair> no wait what are you attempting to do?
[16:58] <DktrKranz> ScottK: http://paste.ubuntu.com/143555/
[16:58] <ScottK> DktrKranz: Thanks.
[16:59] <DktrKranz> some haven't bugs (such as swig1.3), I plan to test them sooon
[16:59] <ScottK> DktrKranz: I actually uploaded imgseek today (rebuild) so it should be off the uninstallable list.
[16:59] <ScottK> OK
[16:59] <MTecknology> I want to use debootstrap to create a little testing ground. I don't want to download everything every time since I might do it a couple times, so I just want to grab whatever I need to create a local mirror for debootstrap
[16:59] <DktrKranz> ScottK: ah, fine
[17:01] <ScottK> DktrKranz: I find more than that.  For example mgltools-scenario (which I will do).
[17:01] <ScottK> DktrKranz: How are you generating your list?
[17:02] <DktrKranz> edos-debcheck with some UNIX tools
[17:05] <ScottK> OK.  I'm using apt-cache unmet and finding stuff you aren't.
[17:05] <DktrKranz> such as?
[17:05] <DktrKranz> so I can check why I have these differences
[17:05] <ScottK> The mgltools-scenario is one exaemple
[17:06] <DktrKranz> amd64?
[17:06] <sbeattie> MTecknology: apt-cacher or apt-cacher-ng will let you cache locally without mirroring everything.
[17:07] <DktrKranz> ScottK: maybe I realized, my edos-debcheck run doesn't include multiverse
[17:07] <ScottK> Ah.
[17:07] <ScottK> Yes.  That's in multiverse.
[17:09] <MTecknology> sbeattie: I'm playing with debmirror right now
[17:11] <sbeattie> DktrKranz: do you check multiple arches? I've found at least one that's uninstallable on amd64 only (pose-skins) because the dependency (pose) FTBFS on amd64.
[17:11] <MTecknology> hrm - I forgot how to find the fastest mirror without using synaptic
[17:13] <DktrKranz> sbeattie: only i386, but I can run for every arch
[17:23] <MTecknology> Any ideas what's wrong with this?  debmirror --nosource --method=http --arch=i386 --section=main,restricted,universe,multiverse --host=astromirror.uchicago.edu/ubuntu -d intrepid,intrepid-security,intrepid-updates,jaunty,jaunty-security,jaunty-updates /home/michael/UbuntuMirror/
[17:24] <DktrKranz> MTecknology: which error do you receive?
[17:25] <MTecknology> DktrKranz: 404
[17:26] <kees> MTecknology: http://astromirror.uchicago.edu/ubuntu/dists/  doesn't have jaunty
[17:26] <kees> I recommend se.archive.ubuntu.com
[17:26] <MTecknology> oops - thanks
[17:28] <MTecknology> Download of dists/intrepid-security/Release failed: 404 Not Found Download of dists/intrepid-security/Release.gpg failed: 404 Not Found Download of dists/intrepid-updates/Release failed: 404 Not Found Download of dists/
[17:28] <MTecknology> I'm still getting that
[17:35] <MTecknology> closer, but not quite - http://pastebin.ca/1381023
[17:41] <MTecknology> I just made an rsync script to do it :P
[17:55] <slytherin> does anyone know how can I make use of rsync to update daily CD?
[17:56] <mathiaz> slytherin: https://help.ubuntu.com/community/RsyncCdImage
[17:57] <slytherin> mathiaz: does it work for alternate CD as well?
[17:58] <mathiaz> slytherin: yes
[18:01] <slytherin> trying now.
[18:03] <slytherin> mathiaz: doesn't seem to be working for me. It is downloading complete CD I believe, the progress status is not very helpful.
[18:04] <ScottK> I'd appreciate it if some motu who knows about GTK stuff would look at Bug #205218.
[18:04] <slytherin> ScottK: I will take a look
[18:04] <mathiaz> slytherin: do you already have a local copy of th e iso?
[18:05] <ScottK> slytherin: Thanks.
[18:05] <slytherin> mathiaz: yes I have
[18:05] <mathiaz> slytherin: did you adjust the path correctly for the image you wanna get?
[18:06] <slytherin> mathiaz: Yes, I did.
[18:06] <mathiaz> slytherin: I usually double-check by browsing http://cdimage.ubuntu.com
[18:06] <slytherin> mathiaz: I usually update the image using jigdo.
[18:07] <slytherin> damn, I messed up something
[18:30] <fabrice_sp> Hi. Is there a way to get the previous source of a package, before a patch? Since I upgrade xserver-xorg-video-intel, this morning, my computer freeze when screensaver comes up, and I 'd like to compile and test the previous version
[18:30] <slytherin> fabrice_sp: I don't think so.
[18:31] <ScottK> fabrice_sp: You can both source and binary off Launchpad.
[18:33] <fabrice_sp> ScottK, also previous version of binary?
[18:33] <ScottK> Yes
[18:34] <fabrice_sp> I have to chenge my glasses then, because I've not been able to find it... I'll look better then
[18:34] <fabrice_sp> thanks for the tip
[18:34] <fabrice_sp> :-)
[18:40] <maco> ScottK: 1:2.4.12+dfsg-1.3ubuntu1 <-- not a sensible version number, right? should just be 1:2.4.12-0ubuntu1?
[18:43] <LaserJock> that's sensible, not sure it it's right
[18:44] <ScottK> maco: What's the current version and what are you updating?
[18:44] <ScottK> ... to
[18:44] <maco> openswan from 2.4.12+dfsg-1.3 to 2.4.14
[18:44] <maco> like i said in -devel, bunch of security and bug fixes
[18:44] <ScottK> Then you'll want 1:2.4.12+dfsg-0ubuntu1
[18:45] <ScottK> You'll need to figure out what got removed due to non-freeness, remove it and repack the tarball.
[18:45] <maco> with 2.4.14 insted of .12 :P
[18:45] <LaserJock> shouldn't that be 1:2.4.14+dfsg-0ubuntu1
[18:45] <LaserJock> stupid numbers
[18:46] <maco> what does +dfsg mean? they ripped out non-dfsg-free stuff?
[18:46] <LaserJock> yes
[18:46] <maco> i see...
[18:46] <LaserJock> it means that the .orig.tar.gz has been modified specifically
[18:47] <maco> i didnt think orig could be modified....ok
[18:48] <LaserJock> well, that's why we make it clear that it has been modified
[18:48] <LaserJock> because that's about the only time you ever should mess with the .orig.tar.gz
[18:49] <maco> Remove additional non-free draft RFCs from upstream tarball. <-- found
[20:15] <directhex> Subject: 	monodevelop_2.0+dfsg-1_i386.changes REJECTED
[20:15] <directhex> fiddlesticks
[20:46] <savvas> any main sponsors here? I would like your opinion on bug #315679 - should I try to merge the new version of libmtp in Debian?
[20:52] <iulian> savvas: You'll find more main sponsors in #ubuntu-devel rather than here.
[20:52] <savvas> thanks for the tip :)
[20:54] <timClicks1> hi all, new to packaging etc - am interested in https://bugs.launchpad.net/sahana/+bug/271260 - is there anything I can do to help move this along?
[20:55] <directhex> timClicks1, a per-reviewed source package is an ABSOLUTE minimum
[20:55] <directhex> timClicks1, an attached deb may as well be an attched conficker.exe
[20:56] <timClicks1> *nod*
[20:56] <timClicks1> okay,  cheers for the heads up
[21:00] <directhex> timClicks1, google for "ubuntu revu"
[21:00] <savvas> timClicks1: also read https://wiki.ubuntu.com/PackagingGuide :)
[21:03] <timClicks1> :) ta all
[21:04] <ScottK> !revu > timClicks1
[21:04] <ScottK> Also, we're just a few weeks from a release right now, so we aren't taking new packages at the moment.
[21:05] <timClicks1> no, i recognise that
[21:06] <timClicks1> i just thought i would get things on track as much as possible before the 9.10 cycle
[21:07] <timClicks1> revu looks like a great tool
[21:08] <directhex> it provides a convenient packaging pedestal for people to throw balls at
[21:08] <directhex> in the coconut shy analogy in my mind
[21:09] <savvas> directhex: you package monodevelop-java, right? do you happen to know why the binary dependencies are so restrictive? bug #347702
[21:10] <directhex> savvas, because the beta/alpha versions were not forward-compatible, the dependencies were tightened so only monodevelop 1.9.3 could be used with monodevelop-java 1.9.3.
[21:10] <directhex> savvas, minor oversight: monodevelop is not version 1.9.3, it's version 1.9.3+dfsg
[21:10] <directhex> savvas, this is fixed in pkg-cli-apps svn
[21:11] <directhex> savvas, but we need to get the packages in svn pushed to debian, for syncing.
[21:12] <savvas> I see :)
[21:14] <directhex> savvas, it's a huge change - change the "a" to "." in control
[21:14] <directhex> savvas, problem was meebey forgot that "+" > "a" - fortunately, "." > "+"
[21:15] <directhex> savvas, http://svn.debian.org/wsvn/pkg-cli-apps/packages/monodevelop-java/trunk/debian/changelog?op=file&rev=0&sc=0
[21:15] <savvas> directhex: wait, so this is going to be fixed, as soon as it is sync'ed from Debian?
[21:15] <directhex> savvas, yep
[21:16] <savvas> cool, thanks for the quick fix though :)
[21:17] <directhex> savvas, we need to upload monodevelop (and plugins) 2.0. this needs coordination with debian-release (because apparently monodevelop is blacklisted until evolution-data-server enters squeeze, or somesuch craziness)
[21:19] <savvas> understood, I'll comment that bug with the link you gave me
[21:20] <savvas> ah you have :P
[21:34] <james_w> one to add to the python list: bug 342916
[21:51] <mrooney> what do people use for managing upstream changelogs? I want to create one and it looks like I can use dch with -c, but I don't know what to put in for the UNRELEASED section
[21:55] <jpds> 'Changes go here.'
[21:57] <mrooney> jpds: is that an answer to my question?
[21:59] <jpds> mrooney: Well, I usually put that instead of a blank "* ..." line in my UNRELEASED entries.
[22:00] <mrooney> interesting
[22:00] <mrooney> I am just trying to figure out how to create and maintain a changelog for an arbitrary project, basically
[22:00] <mrooney> I figure dch is a good tool
[22:04] <wintellect> Good evening all
[22:05] <wintellect> I am reading through https://wiki.ubuntu.com/PackagingGuide/Complete but am unsure on something...
[22:06] <wintellect> a command is given to create a pbuilder environment - fine. However, does a new pbuilder environment need to be created after using said environment to create a pkg with? Or is there a command to "clean" the envirnoment before using it on another environment - or is cleaning not necessary?
[22:07] <wintellect> s/another environment/another pkg/
[22:10] <jpds> wintellect: The pbuilder cleans up the chroot environment automatically after a build.
[22:12] <jpds> wintellect: You have use the same base pbuilder environment as many times as you like with multiple packages.
[22:12] <wintellect> jpds: perfect. Thanks for clarifying that
[22:16] <jpds> wintellect: So when you build a package: the base tarball with the base distribution is unpacked and the necessary build dependencies (specified in the source package) are installed. The package builds itself as defined by the maintained, afterwards, pbuilder rm -rf's the build chroot.
[22:16] <jpds> maintainer*
[22:18] <wintellect> jpds: that's a sweet setup :)  As it should be :D
[22:23] <wintellect> is "debuild" now called "debuild-pbuilder" or am I missing a pkg? The doc says to use "debuid" but I don't have it on my system
[22:23] <wintellect> s/debuid/debuild/
[22:24] <jpds> debuild should be in devscripts.
[22:25] <wintellect> jpds: again, thanks. The docs didn't make that clear
[22:32] <nhandler> wintellect: You also might be interested in installing ubuntu-dev-tools (which also causes devscripts to be installed)
[22:46] <wintellect> nhandler: thanks
[22:47] <wintellect> I have now successfully created the hello_2.1.1*.deb file  :D
[22:49] <nhandler> Very nice wintellect.
[22:50] <wintellect> nhandler: thanks. I'd like to get involved with pkgs - and contribute to the community in this way (somehow)
[22:50] <wintellect> Love Ubuntu and would thoroughly enjoy being parft of it
[22:51] <nhandler> wintellect: I would suggest reading through https://wiki.ubuntu.com/MOTU/GettingStarted
[22:51] <nhandler> We also have a mentoring program that you might be interested in: https://wiki.ubuntu.com/MOTU/Mentoring
[22:52] <nhandler> We are also having weekly packaging training sessions: https://wiki.ubuntu.com/Packaging/Training
[22:52] <wintellect> yeah, I'd like to be mentored at some point. I think it's fantastic that ubuntu has that program!
[23:32] <hyperair> at least it's easier to find sponsors in ubuntu than debian.
[23:39] <savvas> eh? :)
[23:39] <hyperair> really.
[23:39] <savvas> no I mean... who were you commenting? :P
 yeah, I'd like to be mentored at some point. I think it's fantastic that ubuntu has that program!
[23:40] <hyperair> that.
[23:40] <nhandler> mentoring != sponsoring
[23:41] <dtchen> ok mister pedantic.
[23:41] <hyperair> =p
[23:41] <savvas> ok :)
[23:41] <hyperair> hehehe
[23:42] <savvas> sponsoring is a kind of mentoring, sponsors always tend to point you at the right direction, isn't it? :)
[23:42]  * hyperair nods
[23:42] <savvas> at least that's what I've noticed so far
[23:43] <hyperair> and once you get everything right, they upload your package =)
[23:43] <savvas> and most importantly, I got two "savvas: ROCK!" comments by dholbach :P
[23:43] <hyperair> now, either debian lacks DDs, or DDs who sponsor.
[23:43] <hyperair> if you thought revu was bad, see how many outstanding packages there are on debian-mentors.
[23:43]  * hyperair envies savvas
[23:44] <hyperair> well i got a hug from dholbach =)
[23:44]  * nhandler gives savvas a hug to make things even ;)
[23:44] <savvas> on "embrace thy ubuntu neighbour" day? :P
[23:45] <hyperair> nope
[23:45] <hyperair> it was something to do with nautilus-share
[23:45] <hyperair> about getting an update uploaded before i could get nautilus-share into debian.
[23:47] <savvas> it's really great how you show your appreciation to each other :)
[23:48] <hyperair> hahah
[23:48] <savvas> ok, I now understand what I've said, but think of it in a kind way! :P
[23:49] <hyperair> kind way?
[23:49]  * hyperair is confused
[23:49] <savvas> never mind, I have a nasty cold
[23:50]  * savvas coughs and spreads influenza through chips and bits and bytes
[23:53]  * hyperair fans his notebook
[23:53] <hyperair> ugh my eyes are closing on their own.
[23:53] <hyperair> oh my, it's daybreak!
[23:53]  * hyperair jumps into bed
[23:55] <hyperair> ziroday`: wtf are you doing here so early
[23:55] <hyperair> nevermind, bedtime for me.
[23:57] <savvas> The peer has reset their connection :p
[23:58] <nhandler> Darn peer, always kicking people offline :P


[00:36] <blahdeblah> How long should I be expecting it to take for a publish of a successful build to make it into the PPA?  I've got this one that happened an hour ago that hasn't made it in yet: https://launchpad.net/~paulgear/+archive/ubuntu/nftables/+build/23733619
[01:24] <blahdeblah> I guess the answer is "a bit longer" - it's published now
[01:24] <sarnold> :)
[16:43] <gurupras-> The Launchpad site now has new logos now! \o/ Some of the launchpad-related sites and properties will be updated soon.
[16:45] <guruprasad> Not sure what happened to my nick when I posted my previous post
[16:48] <tomwardill> wooo! new shiny logos :D


[13:08] <didrocks> hey fginther, how are you?
[13:12] <fginther> didrocks, good morning. I'm good, how are you?
[13:13] <didrocks> fginther: I'm fine thanks!
[13:13] <didrocks> fginther: FYI, I changed slightly customise_preseed_file to support "full ppa arg"
[13:14] <didrocks> fginther: I was thinking we should start deprecating preseed.cfg and only have one autopilot job in the end, what do you think?
[13:15] <fginther> didrocks, I'll need to take a closer look. I'm not as familiar with the utah config files as the others
[13:16] <didrocks> fginther: ah, do you think the UTAH config changes?
[13:20] <fginther> didrocks, not necessarily, I rarely modify it, which is probably why I'm a little behind on what it's doing
[13:21] <didrocks> fginther: do you think you will have time to have a deeper look this week?
[13:21] <didrocks> I think a good target is:
[13:21] <didrocks> - just one autopilot job
[13:21] <didrocks> - we pass ppa (no ppa or CHECK_WITH_WHOLE_PPA means full dist-upgrade)
[13:21] <fginther> didrocks, yes, of course. I just can't give an opinion right now :-)
[13:21] <didrocks> - we can pass installed_package
[13:21] <didrocks> - and a tests list
[13:23] <fginther> didrocks, Oh, then are you thinking of creating a 'generic' autopilot job, which is then called by multiple 'check' jobs?
[13:23] <didrocks> fginther: exactly
[13:23] <didrocks> with different parameters
[13:24] <didrocks> we track the regressions/number of failures per job
[13:24] <fginther> didrocks, then yes. I agree it's a good idea. Will need to study the implementatino
[13:24] <didrocks> great ;)
[13:24] <didrocks> fginther: especially as we have raring/ and head/
[13:24] <didrocks> meaning, doubling the number of jobs
[13:24] <didrocks> so better to have a generic one
[13:25] <fginther> didrocks, speaking of regressions. Have you considered basing regressions on a 'known test failures' list?
[13:25] <fginther> or is that how it works now.
[13:26] <didrocks> basically, we record the number of test failing by $release/$stack/$config
[13:26] <didrocks> so we already have that tracking
[13:26] <didrocks> (the -check job is doing the distribution)
[13:27] <fginther> didrocks, got it
[13:28] <didrocks> fginther: do you have some xml template example to pass parameters to another job?
[13:29] <fginther> didrocks, yes, one moment
[13:31] <fginther> didrocks, we have templates that pass all parameters to another job and a predefine list of parameters...
[13:31] <fginther> in ci/jenkins-templates/autolanding-config.xml.tmpl
[13:31] <didrocks> fginther: the predefine is what I would need. Looking at that, thanks! :)
[13:31] <fginther> The project defined in the builder section passes all parameters
[13:32] <didrocks> ok, CurrentBuildParameters
[13:33] <didrocks> otherwise
[13:33] <didrocks> parameterDefinitions?
[13:33] <didrocks> or rather PredefinedBuildParameters
[13:33] <fginther> yes, PredefinedBuildParameters
[13:33] <didrocks> the separator is \n?
[13:34] <fginther> yes
[13:34] <fginther> didrocks, When using CurrentBuildParameters, any parameter that is not defined in the target job is ignored
[13:35] <didrocks> fginther: ah excellent, so I can even parameterize them right now
[13:35] <didrocks> fginther: even if we didn't merge the "unity autopilot jobs" yet
[13:35] <fginther> didrocks, yes
[13:37] <didrocks> fginther: ok, tell me once you'll have the time to have a look at the rest of the jobs, we can coordinate and planning changing that ;)
[13:37] <didrocks> fginther: right now, I'm changing the triggering template already
[13:37] <fginther> didrocks, good idea. that will make it easier
[13:37] <didrocks> exactly!
[13:42] <dandrader> paulliu, that's the blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-testing
[13:43] <dandrader> paulliu, so after you find the component you wanna test, make sure it's not already being worked on by someone else and add an entry with your task there
[13:46] <dandrader> paulliu, if I'm not mistaken the components under the Panel suddir don't have tests yet. so you might wanna start there.
[13:47] <paulliu> dandrader: ok.. got it
[14:23] <cyphermox> mterry: hey
[14:23] <cyphermox> http://<IP_ADDRESS>:8080/view/cu2d/view/Raring/view/Indicators/job/cu2d-indicators-raring-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_hud_13.04.0daily13.04.01-0ubuntu1.diff
[14:24] <cyphermox> didn't we already release this kind of changes?
[14:24] <mterry> cyphermox, I sure thought so
[14:25] <mterry> cyphermox, archive has those changes
[14:25] <cyphermox> weird
[14:25] <mterry> cyphermox, oh
[14:25] <cyphermox> well, I'm going to wait before publishing that anyway, bamf has changes that aren't closing a bug :/
[14:25] <mterry> cyphermox, I think we manually pushed those to archive.  So this may be the automerger catching up
[14:26] <cyphermox> should have been merged in hud a long time ago :)
[14:26] <mterry> cyphermox, I would have thought that too...
[14:26] <cyphermox> anyway, cool, I'll investigate to see why it gets pcked up now
[14:27] <didrocks> mterry: cyphermox: if that was manually uploaded, and was manually merged back, it can appear in the diff
[14:27] <didrocks> mterry: cyphermox: as the diff is bzr diff -r <last autolanding rev> debian/
[14:27] <cyphermox> didrocks: yeah, but if it was manually merged back, that should have happened more than a month ago ;)
[14:28] <didrocks> cyphermox: not if we didn't get anything more to release for bamf?
[14:28] <cyphermox> didrocks: not looking at bamf right now, but hud
[14:29] <didrocks> ah ok ;)
[14:29] <cyphermox> yeah, no extra changes either
[14:30] <cyphermox> perhaps there was not publish of indicators since, but I find that hard to believe
[14:32] <didrocks> fginther: https://code.launchpad.net/~didrocks/cupstream2distro-config/autopilot-jobs-factorization-step1/+merge/156357, do you mind having a look?
[14:32] <didrocks> fginther: some examples of deployement:
[14:32] <didrocks> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-2.2check/configure
[14:33] <didrocks> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/configure
[14:33] <didrocks> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/OIF/job/cu2d-unity-head-2.2check/configure
[14:33] <didrocks> (last one have no parameter, just the ppa one)
[14:33] <didrocks> cyphermox: before you go on manual publishing, I'm deploying a small change for the -check job on indicators
[14:34] <didrocks> cyphermox: done
[14:34] <cyphermox> didrocks: ok
[14:34] <cyphermox> not going to publish this until bamf is fixed
[14:34] <didrocks> ok :)
[14:34] <didrocks> maybe mterry can still publish unity though ;)
[14:34] <didrocks> mterry: btw, I've added the "force manual publishing mode"
[14:34] <fginther> didrocks, taking a look
[14:34] <mterry> didrocks, for raring?
[14:35] <didrocks> mterry: no, in daily release, it's a parameter on the stack, I just need to write the doc ;)
[14:35] <didrocks> so if you want to force that at some point, it's possible :)
[14:35] <mterry> didrocks, yeah, I suppose I can publish unity.  the indicator stack doesn't have any weird FFe API changes or anything, right cyphermox?
[14:35] <mterry> :)
[14:35] <cyphermox> mterry: nope
[14:35] <cyphermox> it's some small bug fixes
[14:36] <mterry> didrocks, ah...  you're talking for unity-greeter.  Cool
[14:36] <didrocks> mterry: yeah, we can build that stack if you feel it and force manual publishing ;)
[14:36] <mterry> didrocks, cool, thanks.  Not urgent now, but maybe post raring
[14:37] <didrocks> yep ;)
[14:37] <cyphermox> urr, wait a second
[14:38] <mterry> didrocks, so are we ready for enabling the "apps" stack for head?  I had it disabled, but if the infrastructure is ready for it...
[14:40] <cyphermox> ok
[14:40] <didrocks> mterry: yeah, it would be good to have an autopilot job (or the factorized one, see my discussion with fginther) for the -check steps
[14:40] <didrocks> mterry: as you know which commands to list and which packages needs to be installed
[14:41] <mterry> didrocks, that's something I can specify in the config file?  OK, will look
[14:41] <didrocks> mterry: see the MP above ^
[14:41] <didrocks> mterry: fresh from the press! :-)
[14:42] <mterry> oh
[14:43] <mterry> didrocks, ah I see, awesome
[14:43] <didrocks> mterry: before those infos were hardcoded in the jenkins job
[14:43] <didrocks> mterry: the goal is just to have one
[14:43] <mterry> indeed, good
[14:44] <didrocks> mterry: I still don't like the fact that we have to hardcode the binaries we want to install (in the not "check with whole ppa") case
[14:46] <mterry> didrocks, couldn't these be moved to dep8 tests?  That way, the info would be in the packaging, in the same branch
[14:46] <didrocks> mterry: dep8 tests are just per packages, not for a whole stack, right?
[14:46] <didrocks> mterry: we can't have autopkgtests with a real machine
[14:46] <didrocks> (so with opengl)
[14:46] <didrocks> which is an issue for unity for instance
[14:48] <mterry> didrocks, oh.  Why can't we test on real machine?
[14:48] <didrocks> mterry: that's why jibel told me, the infra is just on vm and it's not trivial to get a real machine provisionned apparently
[14:48] <mterry> didrocks, weird.  OK.  And yeah, dep8 is per-package
[14:49] <didrocks> mterry: but I agree, I would prefer way more having a per stack/something like dep8
[14:49] <mterry> didrocks, but those tests all live in one package.  And dep8 can specify other packages to be installed
[14:49] <mterry> (I mean, each test lives in exactly one package)
[14:49] <didrocks> that's interesting, we can do that
[14:49] <mterry> didrocks, it's still hardcoding binaries, but you're doing it in the source at least
[14:50] <mterry> didrocks, but the non-real machine is kind of a blocker
[14:50] <didrocks> mterry: indeed, but we need to think of a way of dealing with that better, I agree
[14:50] <didrocks> mterry: the hardcode is used multiple times btw:
[14:50] <didrocks> - only apt-get install <those packages>
[14:51] <didrocks> - filters then that you only get those packages in the pre-seed
[14:51] <didrocks> (if you didn't use "check with whole ppa")
[14:51] <didrocks> that enables us to ensure that you didn't transition an ABI in a stack
[14:51] <didrocks> depending on another stack
[15:03] <didrocks> mterry: FYI, unity is in approved. It will be interesting to see how in production the daily release will handle it tomorrow even if I designed for it :)
[15:04] <didrocks> (basically, it should only collect the new listed bugs, but still -v<last_published_version_in_distro>)
[15:05] <mterry> didrocks, ah.  so the changelog and the changes file have different contents finally.  :)
[15:06] <didrocks> mterry: yep ;)
[15:07] <didrocks> thanks fginther :)
[15:07] <didrocks> fginther: should we discuss and go ahead for the factorization tomorrow together?
[15:08] <didrocks> fginther: I think I'll have some cycles to help
[15:08] <fginther> didrocks, yes. I will have studied up on the utah configuration by then
[15:09] <didrocks> fginther: excellent, thanks!
[15:09] <fginther> didrocks, you're welcome
[15:14] <kgunn> paulliu: i know you were looking for possible area to dig into some testing....nothing's been done for panel/indicators
[15:16] <paulliu> kgunn: yeah. But that's completely new. I'd like to dig into some area that I can read and mimic first to get used to the code.
[15:26] <kgunn> paulliu: you could also look for low hanging fruit of fixme/todos  in the code base
[15:27] <paulliu> kgunn: ok.
[15:27] <kgunn> paulliu: this sheet....has a little map i created....with comments on big/small/prioirty etc
[15:27] <kgunn> paulliu: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoGvOYxwuvpFdEJ5dURFb3Y0cnlKeEcxc0piNDZrWXc#gid=0
[15:27] <paulliu> ok
[16:10] <luv> mardy: moi, Im working on the logout functionality for ubuntu online accounts - so I have put together a python script which simulates the functionality: http://pastebin.blesmrt.net/3135/
[16:11] <luv> though, it looks like signon_identity_signout and signon_identity_remove are pretty much broken ... also UOA plugin for gnome control center can't really deal with an account with deleted identity (and there is more issues :-/),  but that's something I would eventually take care of
[16:12] <luv> btw are you based in Finland? I spent one year in Espoo :-)
[16:13] <luv> (the interesting bits are around lines 35 - 55  )