[00:00] <Neurostu> so pbuilder is more in-line with dpkg-buildpackage
[00:00] <mok0> Neurostu: yes, only it does in in a chroot enviroment
[00:01] <mok0> Neurostu: ... after downloading and installing all Build-depends packages
[00:01] <Neurostu> and the chroot environment allows you to build packages for a specific architecture even if your machine is a different architecture
[00:01] <Neurostu> ?
[00:02] <mok0> Neurostu: uhm, only if you have an amd64
[00:02] <ajmitch> usually only in the case of building i386 packages on amd64
[00:02] <mok0> Neurostu: then you can build for i386 arch too
[00:02] <mok0> ajmitch beat me to it :-)
[00:03] <Neurostu> ok so do you guys prefer the pbuilder route over dpkg-buildpackage?
[00:04] <mok0> Neurostu: depends. But it's good because you don't need to pollute your machine with a whole bunch of -dev packages
[00:04] <RAOF> Pbuilder is useful in that it is closer to how your packages are built on the buildd.  It'll catch failure to build due to insufficient build-dependencies, for example.
[00:09] <Neurostu> so I've been trying to read the debian library packaging guide... but I'm not sure what changes I need to make to the rules file
[00:13] <Neurostu> I wasn't sure if I need to run dh_makeshlibs instead of dh_make, when I try dh_makeshlibs i get "find: debian/libsomanetwork: No such file or directory"
[00:14] <RAOF> Neurostu: These two tools may be named similarly, but they do entirely different things.
[00:15] <RAOF> dh-make creates a debian/ directory contianing useful templates for a new source package.
[00:15] <Neurostu> right... I've been using it to do that for a while
[00:15] <RAOF> dh_makeshlibs is normally run from debian/rules, and creates a package.shlibs file that provides dpkg-shlibdeps with informaiton about library dependencies.
[00:16] <Neurostu> I'm guessing that I need to add dh_makeshlibs to a specific place in the rules file
[00:17] <RAOF> Yes; it'd be in the binary: rule, IIRC.
[00:17] <RAOF> But this is not a simple proposition; library packaging is a complex beast, with all sorts of crazy pitfalls.
[00:19] <Neurostu> right that's what they said above.  So i found the dh_makeshlibs in the rules file generated by dh_make, I just uncommented it and I'll see if that works
[00:20] <ajmitch> RAOF: quoting me now?
[00:20] <RAOF> ajmitch: Am I?  Only unintentionally? :)
[00:20] <ajmitch> 10:48 < ajmitch> library packaging is a complex beast, full of pitfalls
[00:21]  * RAOF is much less original than he thinks.
[00:25] <Neurostu> ok so the 2nd package built and installed.  It just looks like I'm having problems with glade now...
[00:30] <Neurostu> so the src/ directory has the .glade file, and when I run dpkg --contents <package2.deb> it isn't included in the package, where would I go about getting it included in the .deb
[00:35] <RAOF> Neurostu: Is it installed as a part of the build process?
[00:36] <mok0> Heh, try out this coolness: http://goosh.org/
[00:37] <Neurostu> hmm... let me check
[00:41] <Neurostu> So when I run make install it gives me the same error
[00:41] <Neurostu> so its a problem I will have to work on with the developer
[00:42] <Neurostu> thanks for your help
[00:55] <jml> RAOF: cryptomnesia!
[01:00] <persia> Neurostu: You can work around it by force-installing the missing glade files with dh_install
[01:12] <Neurostu> dh_install is that a command I run or do I add that line to rules?
[01:12] <persia> Neurostu: dh_install goes in debian/rules.  Read the man page to determine how to get your files installed.
[01:12] <RAOF> It's a command you run from rules.  'man' is your friend.
[01:13] <Neurostu> man --> is a great friend  sometimes I forget that...
[01:13]  * persia curses RAOF's cogent concise commentary
[01:13]  * RAOF find's it a pity 'RAOF' doesn't start with 'c'.  Alliteration FTW!
[01:14] <persia> Right.  Should have used a given name :)
[01:14]  * RAOF is indicted for cruely to the common appostrophe.
[01:15] <Neurostu> sorry for my pedantic questions, but what man entry am I looking at (dh_make?)
[01:15] <RAOF> dh_install.
[01:15] <RAOF> Also, debhelper.  'man debhelper' will give you an overview of the dh_* helpers.
[01:17] <RAOF> Aha!  I think I've caught a fundamental disconnect.  The debian/rules file is just a makefile.  As such, all of the tab-indented lines are just passed to a shell to be run.
[01:17] <persia> RAOF: Well, passed to a series of shells.  Don't try any fancy shell scripting...
[01:18] <RAOF> Oh, yeah.  One shell per line.
[02:12] <bddebian> Heya gang
[02:13] <nixternal> boo
[02:14] <RAOF> Howdie bddebian.
[02:14]  * RoAkSoAx giving a talk about merging xD
[02:15] <bddebian> Hi RAOF
[02:30] <mneptok> persia: konban-wa
[02:34] <RoAkSoAx> anyone know why i cant install a pbuilder for intrepid?
[02:34] <RoAkSoAx> it shows me this: E: No such script: /usr/share/debootstrap/scripts/intrepid
[02:35] <RAOF> Oh, because you haven't upgraded your debootstrap to the version in hardy-proposed or hardy-backports, I forget which.
[02:35] <RoAkSoAx> oh right, cool thnaks, forgot to enable backports :)
[04:35] <soonick_cancun> hello everyone. I have just signed up to launchpad, and signed a code of conduct so i could get started helping to ubuntu. But i dont know where can i start. I have readen a little but i think i would lear faster if i actually did something.
[04:35] <soonick_cancun> can someone give me a clue how to start?
[04:35] <persia> soonick_cancun: Well, this channel is mostly about contributing to development.
[04:36] <soonick_cancun> im fine about it
[04:36] <persia> We tend to review the open bugs, and close them, with a bit of updating to new versions as well.
[04:36] <soonick_cancun> so how can i get a bug to fix?
[04:36] <persia> I'd recommend taking a look at https://wiki.ubuntu.com/MOTU/Contributing, picking a bug that annoys you, and fixing up the package as much as you can.
[04:37] <persia> One source of bugs people consider easy is to look at https://launchpad.net/ubuntu/+bugs and select the "bitesize" tag on the left (I forget the real URL).
[04:37] <soonick_cancun> should i join bugsquad?
[04:38] <persia> soonick_cancun: Depends on your interest.  My experience was that working with bugsquad gave me a lot of confidence with the processes, and helped me find packages I could help fix.
[04:39] <soonick_cancun> well i need confidence with the process, so i think ill do it :P
[04:39] <persia> soonick_cancun: Most of the bugsquad coordination is on #ubuntu-bugs.  Here we tend to focus on the code changes related to the bugfixes.
[04:40] <soonick_cancun> do i need to join bugsquad to fix a bitesize bug?
[04:40] <soonick_cancun> should i go to that channel to get help with the process?
[04:40] <persia> soonick_cancun: Nope.  Anyone can fix bugs.
[04:41] <persia> bugsquad tends to look at bugs, and try to make sure they are well-understood.
[04:41] <persia> That way developers (who may also be bugsquad) can use that understanding to prepare a patch, and get it to users.
[04:43] <soonick_cancun> ah, that seems helpful. So i can find a bitesize bug i am interested, go to bugsquad to find a deep explanation about it, fix it and then come here for help to upload it?
[04:44] <persia> soonick_cancun: the deep explanation ought be in the bug.  The bugsquad team tries to help get it there.  Unfortunately, they only process 2500-3000 bugs a week, so not every bug is as complete as would be easy for a new developer.
[04:46] <soonick_cancun> so i should get one, fix it and they should help me upload the solution?
[04:46] <persia> soonick_cancun: If you pick one, and fix it, and prepare a patch, the relevant sponsors will upload it.  See https://wiki,ubuntu.com/MOTU/Contributing
[04:48] <soonick_cancun> ok, then i guess ill try that
[04:49] <soonick_cancun> should my next doubts be directed to bugsquad?
[04:51] <persia> soonick_cancun: Depends on the doubt.  If it's about bug management, bugsquad are the group to ask.  If it's about development participation, this is the place to ask.
[04:54] <soonick_cancun> ok, ill go to bugsquad then to get some help to get started. Thank you very much for the orientation persia
[04:54] <persia> soonick_cancun: Thanks for helping with Ubuntu
[04:55] <soonick_cancun> to soon to say that, but i hope i get there :P
[07:24] <poolie> hi
[07:24] <poolie> i want to package bzr 1.6beta1 for our ppa
[07:25] <poolie> is 1.6~beta1-1~ppa1 an appropriate name/
[07:26] <RAOF> poolie: That suggests that its got a Debian revision.
[07:26] <soren> If it were me, I'd probably stick "0ubuntu" in there, too, and get 1.6~beta1-0ubuntu1~ppa1
[07:26] <RAOF> _Exactly_ what I was going to suggest ;)
[07:26] <soren> :)
[07:27] <poolie> hm interesting
[07:27] <poolie> so it seems like people should be doing that for most ppa packages?
[07:27] <RAOF> Unless, of course, that it is based on the 1.6~beta1-1 debian package :)
[07:27] <soren> poolie: Mostly, yes.
[07:29] <persia> poolie: That format should be followed if the package is intended to be a temporary upgrade for an installed Ubuntu system.  If you have other intentions, other version formats may be suitable, but we can't really help so much.
[07:29] <poolie> it's not a temporary fix, i guess it's closest to being a backport
[07:29] <poolie> in that i'm packaging it for dapper..hardy
[07:30] <persia> poolie: Let's call that temporary, under the assumption there may be an official backport later :)
[07:30] <directhex> then i'd suggest something other than ~ppa1
[07:30] <directhex> something alphabetically earlier than the letter "d"
[07:31] <persia> directhex: Good point!
[07:32] <directhex> since official backports get a ~distro extension, so a "ppa1" package would not be replaced by an official dapper, edgy, etc
[07:37] <poolie> like "b"? :-)
[07:38] <poolie> oh sorry, i mistyped before, it's actually ~bazaar1
[07:42] <RAOF> That would work ;)
[07:58] <dholbach> good morning
[07:58] <poolie> hello dholbach
[07:59] <dholbach> hi poolie
[08:01] <ajmitch> hey dholbach
[08:01] <dholbach> hi ajmitch, hi slomo_
[09:09] <huats> morning everyone
[09:10] <BugMaN> morning huats :)
[09:10] <Balachmar> Hi, I was trying to build a package for hardy (blender 2.46) using pbuilder and the stuff from debian experimental
[09:10] <persia> Balachmar: Did it work?
[09:11] <Balachmar> It fails, because it doesn't find the libftgl-dev. But it is in the repo, but as ftgl-dev (so without the lib)
[09:11] <Balachmar> How could I make this build ok, can I somehow create a symlink kind of link to that package?
[09:13] <slytherin> Balachmar: just change the dependency in debian/control file, add a changelog entry documenting the change.
[09:14] <Balachmar> slytherin: I'll have a look
[09:15] <Balachmar> Because I was using the dsc file, So I guess I'll have to change something in the tar.gz file as well
[09:19] <Balachmar> ok, made the change in the diff file. See what it does
[09:20] <Balachmar> the ftgl-dev should be deprecated in interpid, according to the diff file (at least it is deprecated in debian)
[09:20] <wgrant> Balachmar: I've got a working Blender 2.46 in my PPA.
[09:20] <wgrant> I just backported ftgl.
[09:20] <persia> Balachmar: It's best to never change the tar.gz file.  This is the entire purpose of the diff.gz file.
[09:20] <wgrant> https://launchpad.net/~wgrant/+archive
[09:20] <wgrant> Balachmar: It doesn't work by simply altering the dependency.
[09:20] <Balachmar> @persia: I kind of got that
[09:21] <Balachmar> @wgrant: ok, so you have already backported blender 2.46 to hardy! Great!
[09:21] <Balachmar> Then I might try something else, to be useful
[09:22] <Balachmar> wgrant: What did it take to create the package?
[09:23] <wgrant> Balachmar: I simply took blender and ftgl from experimental and uploaded them to my PPA, with a new changelog entry.
[09:24] <Balachmar> wgrant: That was ofcourse my nest step, to take ftgl as well :)
[09:26] <Balachmar> wgrant: So you first created the ftgl package and uploaded it to your ppa, then you could build the blender package as well, since it was able to find the ftgl and then you uploaded it to your ppa as well. Am I right?
[09:27] <wgrant> Balachmar: Correct. But you need not bother yourself with that - just grab them from my PPA.
[09:28] <Balachmar> wgrant: already doing that :) Just curious if I was right on how you did it :)
[09:28] <Balachmar> So that I can help out with packaging in the future.
[09:35] <gaspa> wgrant: i can't fully understand your comment.... ( about the patch system... i used the one in the package... or there's something wrong?
[09:42] <nicolasvw> Hello, is there a tool that can be used to get fresh sources using the debian/watch file ?
[09:43] <james_w> nicolasvw: "uscan"
[09:46] <nicolasvw> james_w: thankx !
[09:50] <wgrant> gaspa: Ooops, indeed, I was looking through it too quickly and automatically mentally stripped out the leading +. Ignore me.
[09:51] <gaspa> wgrant: fine. ;) thanks.
[10:04] <gaspa> wgrant: feisty done. for intrepid perhaps i could drop some ubuntu deltas, so it takes a little more. :)
[10:10] <sistpoty|work> hi folks
[10:13] <Laney> lo
[10:20] <norsetto> greetings and salutations
[10:20] <dholbach> hiya sistpoty|work, hi norsetto
[10:20] <dholbach> hey Daviey
[10:20] <sistpoty|work> hi dholbach
[10:21] <sistpoty|work> hi norsetto
[10:21] <Daviey> hey dholbach!
[10:21] <norsetto> morning dholbach
[10:21] <dholbach> how are you guys doing? :)
[10:21]  * norsetto is surviving
[10:21]  * Daviey is GOOD
[10:21] <dholbach> norsetto: is it that bad?
[10:22] <norsetto> dholbach: survival is good, its extintion which is bad :-)
[10:23] <dholbach> norsetto: right... but if "survival" is everything or your only pressing concern.... :-)
[10:23]  * laga ponders going for MOTU
[10:23] <laga> so i'll have to do some merges, i guess
[10:25] <dholbach> laga: there's a lot of stuff on http://wiki.ubuntu.com/MOTU/TODO - you could pick some bitesize bugs or something from http://daniel.holba.ch/really-fix-it
[10:25] <laga> thanks, bookmarked.
[10:25]  * Daviey didn't know about really-fix-it
[10:27] <persia> Daviey: It's the ultimate source of prepared fixes just waiting for someone to snipe them :)
[10:35] <geser> Hi *
[10:38] <norsetto> heya geser
[11:09] <gaspa> wgrant: it's enough sending the diff also for intrepid, or should i file another bug, for merge?
[11:21] <laga> does https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions also apply to universe/multiverse?
[11:22] <laga> we're missing lots of upstream fixes for MythTV in hardy - and there's no way i'll do an SRU for 20 patches :)
[11:24] <wgrant> gaspa: Don't bother filing another bug.
[11:24] <gaspa> cool. :D all done, then.
[11:26] <wgrant> gaspa: Danke.
[11:26] <gaspa> :)
[11:28] <gaspa> wgrant: uops. No, wrong diff. just a minute.
[11:30] <persia> laga: The rules apply.  On the other hand, those are general exceptions.  Any given upload is considered by the SRU team.  Note that except in special circumstances, it's unlikely to be accepted as just a new upstream.
[11:31] <laga> persia: sad.
[11:32] <persia> laga: Why?  Stability is key.  What's bad about a single SRU with 20 patches?
[11:32] <directhex> maintainer time
[11:32] <laga> i'd love to pull in a new snapshot from their release-0-21-fixes branch, get some testing done (maybe 10 positive comments instead of the usual 2) and be done.
[11:32] <laga> persia: because SRUs are supposed to be non-invasive.
[11:32] <geser> laga: be happy that you don't need to do a SRU for each patch :)
[11:33] <persia> laga: You could ask the SRU team.  Note that if the release-0-21-fixes branch is all bugfixes, and you document the bugs & fixes, there's a good chance it would be approved.
[11:34] <persia> It's mostly about documentation and testing, rather than hard & fast rules.  As long as it's transparent to the user, and doesn't break anything, and doesn't change the feature set, it is likely fine.
[11:34] <directhex> laga, question is, has the protocol version been bumped at all since 0.21?
[11:34] <laga> directhex: no
[11:34] <laga> they didn't do it this time :)
[11:35] <laga> persia: i'll talk to motu-sru then. thanks
[11:35] <directhex> laga, well, that makes it easier to argue that an update is non-invasive, since it (shouldn't) break mixed setups
[11:35] <laga> doing a backport would be much easier, but hardy-backports isn't enabled by default :(
[11:35] <directhex> laga, personally i want the update, for greyfoxx's upnp fixes
[11:36] <laga> directhex: you can always use the weekly fixes builds.. i still need to push them, though ;)
[11:36] <persia> laga: Also, the policy is that backports aren't permitted as a bugfix channel.
[11:36] <laga> persia: indeed.
[11:37] <directhex> laga, can't you enable backports by default in mythbuntu?
[11:37] <laga> directhex: we (accidentally) did that for 7.10.
[11:37] <laga> then 0.21 came out
[11:37] <laga> it was a terrible mess :(
[11:37] <directhex> laga, oh. oops.
[11:38] <directhex> laga, shove one of the mythbuntu ppa repos in, then?
[11:38] <laga> there have been at least 60 commits to the release-0-21-fixes branch since the last mythtv upload to hardy. too lazy to count properly now.
[11:39] <laga> directhex: we're already doing that for the weekly builds, but we usually want to stay as close to the ubuntu archives as possible
[11:41] <laga> persia: does motu-sru have a dedicated mailing list?
[11:41]  * directhex wonders what the chances would be for putting backports of mono on hardy. the mono developers are... unkind... about ubuntu's neolithic versions, and the problems it causes them for support
[11:41] <persia> laga: Nope.  Coordination is on the ubuntu-motu@ list.  There is often a representative here, but they've all been hiding recently.
[11:42] <wgrant> directhex: They could adopt a less ridiculous attitude.
[11:42] <wgrant> directhex: Distributions won't upgrade stable releases at upstream's whim.
[11:42] <persia> directhex: If the intrepid mono compiles and works on hardy, and you can organise a few testers, getting them into -backports might be possible (although the rdepends list is *vast*)
[11:42] <wgrant> They need to realise that, if they don't already.
[11:44] <directhex> wgrant, remind me of ubuntu's approach to firefox versions
[11:45] <wgrant> directhex: That's because Mozilla upstream is insane, and unlikely to change.
[11:45] <persia> directhex: That's the other option: upsteam gets deeply involved in Ubuntu integration, and petitions the Technical board.
[11:46]  * persia notes that this tends to make upstream match Ubuntu schedule rather than the other way around, so isn't a good solution for those wishing to maintain their own schedule)
[11:47] <laga> the whole "upstream's schedule should be linked to ubuntu's" is insane anyways.
[11:47] <directhex> i can't see them changing their releases to match. if anything motivates them, it'll be SLES timescales
[11:47] <directhex> but in SLES world, updates DO happen to stable releases
[11:48] <persia> laga: Personally, I don't see any reason for upstream to match Ubuntu, but not matching comes with the consequence that Ubuntu shipped versions may not match latest upstream.
[11:48] <laga> of course. that's not a bad thing.
[11:48] <persia> Exactly.  The point is that no upstream can have it both ways.
[11:49] <persia> (except Mozilla, and we'd rather not do that, except that it can't be called Mozilla if we extract and ship security patches, because upstream is, as noted, insane)
[11:56] <sistpoty|work> note to self: don't try ctrl-alt-backspace in a vm, if the keyboard is not grabbed *G*
[11:57] <schmiedc> gg
[11:57] <geser> :)
[11:57] <soren> sistpoty|work: Even then... ?
[11:57] <soren> sistpoty|work: I thought you couldn't work around ctrl-alt-backspace being sent to your own X serveR?
[11:58] <sistpoty|work> soren: no idea actually
[11:58] <soren> Regardless of keyboard grab, focus or whatnot..
[11:58] <soren> sistpoty|work: Otherwise, it would fail to be the final resort kind of way of killing your X server if your input goes bonkers.
[11:59] <directhex> in vmware, you do ctrl-alt-space, then let go of space, and do backspace/f1/whatever whilst keeping ctrl-alt going
[11:59] <directhex> it seems to behave
[11:59] <sistpoty|work> soren: *nod*, that makes sense
[11:59] <soren> directhex: I wonder how they pull that off..
[11:59] <soren> *shrug*
[12:00] <directhex> magicks, of the dark variety
[12:01] <soren> :(
[12:05] <soren> persia: ping
[12:06] <persia> soren: Yes, I have too much RAM.  Sorry :(
[12:06] <soren> persia: I have an alternate patch here..
[12:06] <persia> pasties?
[12:07] <soren> moment..
[12:08] <soren> Gah.. I accidentally pushed it to launchpad.
[12:08]  * soren kicks bound branches.
[12:09] <persia> Heh.
[12:09] <persia> This is part of why I like CVS.  You do your work locally with quilt or the like, and then push the patches on purpose :)
[12:09] <soren> persia: http://bazaar.launchpad.net/~ubuntu-virt/ubuntu-jeos/trunk/revision/69
[12:09] <soren> You /like/ CVS?
[12:14] <persia> soren: Well, I like that I never commit by accident.  it's the not committing by accident that tends to be an issue.
[12:14] <TheMuso> lol
[12:15] <persia> Anyway, about this patch: are you sure `rm -rf root` won't delete target when INSTALL_IN_PLACE is "YEAH"?
[12:16] <soren> persia: Reasonably.
[12:17] <persia> soren: OK.  I recently had a bad experience with rm -rf and symlinks, but it wasn't Ubuntu, so it may be safe.
[12:17] <soren> persia: Now I'm completely sure. Just tested it.
[12:17] <soren> persia: Could you take it for spin real quick?
[12:17] <persia> soren: Excellent.  The rest looks good, although I'd still like the tmpfs option for those making images that can fit in tmpfs, but it's likely a personal preference :)
[12:18] <soren> persia: That's what "-d /dev/shm" is for :)
[12:18] <persia> real quick?  No.  I'll start a run, but it takes a while.
[12:18] <soren> I do it all the time on my workstation.
[12:18] <persia> soren: Ah.  right :)
[12:27] <persia> soren: all the different ways I try to run that fail with debootstrap: ... Permission denied :(
[12:28] <soren> :$
[12:28] <soren> Er..
[12:28] <soren> Ok.
[12:30] <persia> soren: Mind you, I just pulled the script from bzr, and am running it in a local directory.  Might that be breaking some assumption?
[12:31] <soren> persia: No, that should be fine. I think I know what's wrong.
[12:37] <soren> persia: *headdesk*
[12:42] <soren> persia: Grab from the bzr tree again, and try again, please.
[12:44] <Balachmar> Hey, just found this bug: https://bugs.launchpad.net/ubuntu/+source/blender/+bug/235424 And I know that wgrant actually already has packages for blender 2.46 for hardy. So what should be done for this bug to be squashed?
[12:46] <ogra> Balachmar, well, just wait until its built in intrepid and ask for a backport :)
[12:47] <Balachmar> ogra: OK, I was just checking of maybe I could do something to help :) And I tend to prefer to look at packages I know/use
[12:48] <ogra> Balachmar, well, laga seems to be responsible for getting it from experimental into ubuntu according to http://merges.ubuntu.com/universe.html
[12:48] <ogra> i'm sure he appreciates help
[12:48] <ogra> oh, err
[12:48] <ogra> not laga, sorry
[12:49] <Balachmar> you mean Daniel Hahler
[12:50] <ogra> yeah
[12:50] <Balachmar> I'll send the guy an e-mail then.
[12:50] <ogra> right, ask him if you can help :)
[12:52] <soren> persia: Any better?
[12:52] <persia> soren: Sorry.  As is so often the case, today is the scullery maid's night off.  Just pulling now...
[12:53] <soren> persia: O_o
[12:53] <StevenK> Heh
[12:58] <persia> soren: At least it is running debootstrap, which isn't usually possible on my system.  Things are looking good.
[12:58] <soren> persia: Coolness.
[12:58] <persia> soren: Is this targeted as a replacement in -updates, or for intrepid?
[13:03] <soren> persia: The former.
[13:10] <persia_ume> soren: it ate my workstation :(
[13:10] <soren> persia_ume: You are kidding of course?
[13:11] <persia_ume> Not really.  I'm currently at stage 1/5, 741/1906 of a fdisk recovery
[13:11] <soren> Whuh...
[13:12] <persia_ume> s/fdisk/fsck/ (my brain is apparently also affected)
[13:12] <persia_ume> I'm not sure either.  Everything looked good, and then the screen went black and the BIOS started
[13:13] <soren> Heh... I somehow doubt that could be my fault. :)
[13:13] <soren> persia_ume: Although.
[13:13] <soren> ....
[13:13] <soren> What happens if you fill your /tmp up completely?
[13:14] <persia_ume> I wasn't really doing much else: I was I/O bound hard enough to block most other activities.
[13:14] <persia_ume> But I was using --in-place, which should use the local image, rather than /tmp, right?
[13:15] <soren> No, it still puts the stuff in /tmp, but loop mounts the final images instead of using a temporary directory to build the system.
[13:15] <persia_ume> Ah, and my /tmp was full of random stuff (some of which was large)
[13:16] <soren> Well, if your system misbehaves if your tmpfs fills up with stuff, that's a bug elsewhere :)
[13:16] <persia_ume> (And I don't have very much more than 2x RAM)
[13:16] <persia_ume> soren: Yes, but the --tmpfs flag worked for me...
[13:17] <persia_ume> (as did the crude hack that broke it for everyone else)
[13:17] <persia_ume> I suppose the correct answer is that people who want to mount things like me ought mount something else and use -d
[13:17] <soren> Well, it worked fine for me, too. I just stumbled when I was running ubuntu-vm-builder inside a vm with 96 MB ram,.
[13:17] <soren> Boom!
[13:18] <persia_ume> heh
[13:18] <amikrop> Why this https://wiki.ubuntu.com/PackagingGuide/Complete is required to follow? It is quite complicated. This one http://www.ibm.com/developerworks/linux/library/l-debpkg.html looks very simple and easy.
[13:19] <soren> persia_ume: Well, with --in-place we support a nosuid and nodev /tmp. That something else doesn't support a tmpfs filling up is not really in scope for me :)
[13:19] <persia_ume> amikrop: There are no restrictions on which packaging guide you use, so long as the resulting package complies with the policy defined in the debian-policy package on the current development release.
[13:20] <persia_ume> soren: Makes sense.  I suspect the set of people who have /tmp on /tmpfs and the set of people who have /tmp nodev,nosuid has a small intersection.
[13:23] <amikrop> persia_ume: I find https://wiki.ubuntu.com/PackagingGuide/Complete complex. Are there any other more simple guides that lead to hardy-debian-compliant packages?
[13:23] <amikrop> persia: I find https://wiki.ubuntu.com/PackagingGuide/Complete complex. Are there any other more simple guides that lead to hardy-debian-compliant packages?
[13:24] <persia> amikrop: no need to repeat yourself :)
[13:24] <persia> Anyway, there's the Debian packaging guide.  There are also lots around the net.
[13:24] <persia> The debhelper 7 guide is interesting, as is the CDBS documentation.
[13:24] <persia> You can check yourself against most of policy by running lintian against your packages (both source and binary)
[13:25] <persia> My personal recommendation is to take a source package, create a debian directory, add copyright and control to match other packages you've seen (and the source on which your package is based)
[13:25] <persia> Use dch --create to create debian/changelog
[13:25] <geser> amikrop: forget the ibm guide as fast as you can, with this guide you won't get any package into Debian or Ubuntu
[13:25] <persia> And start a debian/rules based on what you like.
[13:26] <amikrop> geser: OK :-/
[13:26] <amikrop> persia: So, what guide do you suggest?
[13:27] <amikrop> geser: Can't I create compliant packages as simply as with the ibm guide?
[13:27] <soren> "the ibm guide"?
[13:28] <persia> amikrop: I typically suggest the Ubuntu one, but no guide can be both simple and complete: there are too many ways to create a valid package.
[13:28] <amikrop> Or, much more simply than the Ubuntu Packaging Complete Guide?
[13:28] <amikrop> persia: Which is the simplest?
[13:28] <amikrop> soren: http://www.ibm.com/developerworks/linux/library/l-debpkg.html
[13:28] <persia> amikrop: I've not made a comparison, but I'm guessing it's wrong :)
[13:29] <persia> Based on what I see from that URL, I'm guessing the IBM guide is the simplest, but it misses the point of a source package entirely.
[13:30] <persia> As a result, the package cannot be easily modified or distributed, and won't work on multiple architectures.
[13:30] <amikrop> persia: So, should I follow the Ubuntu one? It is complicated in the way that it uses many tools, and says too much about the rules file and stuff. The thing is that I don't want to compile stuff. My package has some basg scripts, some Python scripts, and some object code. I also want to be able to write some simple postinst and postrm files.
[13:31] <persia> amikrop: OK.  You can't package object code without compiling it: that won't work on multiple platforms.
[13:31] <amikrop> s/basg/bash
[13:31] <persia> That said, for the rest, just put everything you want in a directory structure that makes it easy to understand.
[13:31] <persia> Make sure you have a license in COPYING in the root directory.
[13:31] <amikrop> persia: The object code is not open source.
[13:32] <persia> amikrop: That's OK.  This is your package, for your use.
[13:32] <geser> amikrop: the guide tries to be general, if you don't have nothing to compile, you can skip this step
[13:32] <amikrop> (The object code is not mine.)
[13:32] <persia> amikrop: Do you have the source?
[13:32] <geser> amikrop: how is it licensed?
[13:32] <amikrop> persia: no
[13:33] <amikrop> freeware
[13:33] <amikrop> It is not a common license.
[13:33] <amikrop> It is theirs. A custom license.
[13:33] <amikrop> It allows distribution.
[13:33] <persia> amikrop: OK.  You won't be able to make a compliant package.  Go back to the IBM guide, but be warned that this can't easily be distributed.
[13:33] <amikrop> geser: But it says too much about many tools, like dh_* and many many other stuff. It makes thing really complicated.
[13:34] <laga> well, the guide probably tries to be complete.
[13:34] <wgrant> laga: And useful.
[13:34] <amikrop> I find it confusing.
[13:34] <laga> making binary-only packages isn't exactly a common use case in the FLOSS world.
[13:34] <geser> amikrop: it can be easy and it can be hard, depending on the source
[13:34] <amikrop> laga: It is not my choice.
[13:35] <persia> amikrop: To ask a different question: who is the target audience for the package?
[13:35] <amikrop> persia: end-users
[13:35] <persia> amikrop: Surely, but what sort?  Internal, Customers, The World?
[13:36] <amikrop> Just users that want to connect to the Internet easily with a usb modem.
[13:37] <amikrop> geser: Is this section https://wiki.ubuntu.com/PackagingGuide/Complete#head-b1e654041de2f572282304b43e4b5191866afe46 enough to package some simple stuff?
[13:39] <persia> amikrop: There are a few different open-source packages out there for that purpose.  You say "It's not my choice".  Why do you want to package these specific objects?
[13:39] <persia> amikrop: "Packaging From Scratch" is the hardest way to package :)
[13:40] <geser> but it's easier to use than cdbs if you source isn't like cdbs expects it
[13:41] <persia> True, but debhelper is typically easier still.  Anyway, for just images, python, glade, bash, etc. I find CDBS + debian/install painless.
[13:41] <persia> (that's python *scripts*, not modules)
[13:43] <amikrop> Look. I want to install some Python scripts, some Bash scripts, and some Object code (architecture-independent). Also, I want to write a minimalistic postinst and postrm. Just that.
[13:44] <amikrop> What is the most simple way to do this?
[13:45] <soren> persia: The conclusion was that the patch was good, right?
[13:46] <persia> soren: The conclusion was that the patch was likely to work for people not me, and that I should complain to someone else :)
[13:46] <soren> persia: :) gotcha
[13:47] <Hobbsee> santiago-ve: were you the one looking at kguitar on the weekend?
[13:49]  * Hobbsee merges spamprobe.
[13:49] <schmiedc> is it a better idea to start with packaging on a "real" machine or should i setup a vm instead?
[13:49] <amikrop> So, what should I read in order to accomplish that simply?
[13:58] <persia> schmiedc: Either works.  If you go for the real machine, either have a test machine for using the development release or create some chroots for testing.
[14:00] <schmiedc> ok
[14:00] <schmiedc> thx
[14:16] <amikrop> How can I do what I need, then? What do I need to read?
[14:24] <amikrop> Any suggestions?
[14:31] <amikrop> persia, geser: Excuse me, but I didn't understand the conclusion. What guide/section should I read to cover my needs?
[14:41] <persia> amikrop: I don't really understand your needs, and don't tend to recommend guides anyway.
[14:42] <amikrop> persia: OK. I want my package to install some Python scripts, some Bash scripts and some Object code. I also want to write a simple postinst and a simple postrm script. What should I read?
[14:44] <persia> amikrop: See, I'm really not sure that's what you want.  I think you likely either want to work with upstream to have their source (even if you don't distribute it) or want to select a different upstream.
[14:44] <persia> Packaging object code is fraught with difficulty, and even the best packagers routinely make significant mistakes.
[14:45] <persia> Further, I'm fairly certain nobody has written a guide that lets you do that successfully and reliably.
[14:45] <wgrant> And you are unlikely to find guidance for packaging severely non-free software here.
[14:46] <geser> amikrop: one question: what kind of object code is it if it's arch-independent?
[14:46] <amikrop> OK. Let's forget about object code. How can I package some simple python/bash scripts?
[14:46] <persia> amikrop: That's easy.  I listed it all earlier.
[14:46] <amikrop> geser: It is related to the ueagle-atm kernel module.
[14:46] <geser> amikrop: I'd suggest something with debhelper like described in the "Packaging from Scratch" section
[14:46] <amikrop> persia: You mean the Complete Ubuntu Packaging Guide?
[14:47] <geser> amikrop: does it get upload to the modem? i.e. is it a firmware?
[14:47] <amikrop> geser: Yes.
[14:47] <persia> amikrop: No, I mean the step-by-step instructions on creating an orig.tar.gz from your scripts, and which files to create in debian/ to generate a source package.
[14:47] <amikrop> persia: Which URL is this?
[14:48] <persia> http://irclogs.ubuntu.com/2008/06/03/%23ubuntu-motu.html
[14:50] <persia> amikrop: Sorry.  That's won't be up to date for another 15 minutes, but it will be from 14:27
[14:50] <emgent> heya
[14:51] <persia> Or is it.  I'm lost.
[14:51] <amikrop> geser: So, "Packaging from Scratch" is it?
[14:52] <geser> amikrop: that would be my suggestion
[14:52] <persia> Anyway, to summarise.  Put everything in a directory to make it easy to modify.  Put the license in COPYING.  Use that to make orig.tar.gz.  Unpack again.  Add debian/copyright and debian/control.  Use dch --create for debian/copyright.  Use the 1-line debian/rules from the CDBS documentation.  Indicate your installation in debian/install.
[14:52] <amikrop> geser: OK. Thanks.
[14:53] <amikrop> persia: I will try. Thanks.
[14:54] <santiago-ve> Hobbsee, yes i was working with kguitar
[14:56] <afflux> nicolasvw: gdecrypt download link updated, thanks for the hint
[14:57] <devfil> asac: ping
[14:58] <sebner> persia: may I merge xgalaga?
[14:58] <persia> sebner: Please, and anything else of mine excepting freqtweak.
[14:59] <afflux> hi sebner :)
[14:59] <sebner> persia: ^^, I haven't got that much time so I'm just taking ones that are fast to process
[14:59] <sebner> hoi afflux =)
[14:59] <persia> sebner: Heh.  Most of mine are likely from RCbugs or just quick & easy anyway :)
[15:00] <sebner> persia: ^^ We'll see. hmm xgalaga. Remaining change: .desktop, attached patch in BTS 329 ago  -.-
[15:00] <sebner> *329 days
[15:01] <persia> sebner: Yes, well.
[15:01] <persia> He doesn't want to maintain "third-party" packages anymore.
[15:02] <sebner> persia: how should I understand "third-party" ?
[15:02] <persia> sebner: xgalaga is actually up for adoption, although I've enough I'm not doing that I'm not going to take that now.
[15:03] <sebner> persia: ah understood
[15:04] <nicolasvw> afflux: np, will get back at it then ;)
[15:04] <persia> sebner: re: third-party: http://kitenet.net/~joey/blog/entry/a_change/
[15:04] <afflux> nicolasvw: have fun with updating, I guess a simple uupdate will do.
[15:05] <afflux> nicolasvw: ah, please check that all links in the debian/ dir now point to gdecrypt.pentabarf.de instead of just pentabarf.de :)
[15:05] <afflux> forgot to change this in debian/copyright on last update, iirc.
[15:06] <nicolasvw> afflux: will do ;)
[15:06] <sebner> persia: ah. thanks
[15:06] <afflux> thanks
[15:10] <afflux> nicolasvw: err wait. could you wait a minute? I just found two bugs in the ubuntu gdecrypt package. Will check them and provide fixes.
[15:11] <sebner> persia: should I add a "Version=1.0" though validation doesn't complain?
[15:11] <persia> sebner: Yes, please.
[15:11] <nicolasvw> afflux: Let me know
[15:11] <afflux> nicolasvw: will do
[15:11] <persia> sebner: and update the BTS please.
[15:11] <sebner> persia: *polish*
[15:12] <sebner> persia: before or after the merge ^^
[15:12] <persia> sebner: Doesn't really matter.   Will do =)
[15:13] <persia> Thank you.
[15:24] <sebner> Has somebody haXX0red LP? It's so damn slow ... again ^^
[15:24] <persia> It at least isn't working at all for me.    Hard balance then :)
[15:26] <mok0> no, no, we want him up and busying about
[15:26] <sebner> mok0: hey my syncs are really syncs \o/ Are you tired reviewing my syncs (yesterdays discussion)
[15:27] <mok0> sebner: I never get tired of your syncs ;-)
[15:27] <sebner> mok0: hrhr
[15:27] <sebner> ScottK: You have the good contacts to LP folks. speed them up :P
[15:27] <ScottK> It seems even more slow than usual to me.
[15:28] <ScottK> sebner: They mostly run when they see me coming.
[15:28]  * sebner is wondering why ^^
[15:28] <ScottK> It's sufficiently slow that it even breaks http://downforeveryoneorjustme.com/
[15:28] <sebner> lol
[15:28]  * ScottK doesn't have two or three hours to explain.
[15:28] <persia> someone whose attention isn't split by a meeting could go ask in #launchpad...
[15:29] <mok0> ScottK: Hmm, it says it's just me...
[15:30] <ScottK> Hmmm.  I got "The server encountered a temporary error and could not complete your request." more than once.
[15:30] <Laney> It seems fine for me
[15:30] <mok0> sebner: now that I've got you, I was looking at a sync of yours...
[15:31] <sebner> mok0: hmm?
[15:31]  * mok0 tries desperately to find it again
[15:31] <mok0> ah, openbox
[15:31] <sebner> ah
[15:31] <sebner> well, normally reserved for geser =)
[15:32] <sebner> mok0: you can have a merge. just a sec ;)
[15:32] <mok0> sebner: uh-uh, I'll keep my hands off then
[15:32] <sebner> mok0: pfff. don't pick the nice syncs :P
[15:32] <sebner> bug #237082
[15:32] <mok0> sebner: the bug should be assigned to geser, then
[15:33] <sebner> mok0: he is subscribed
[15:33] <mok0> lol
[15:33] <sebner> -.-
[15:33] <sebner> bug #237082
[15:33] <sebner> ubottu: go go go
[15:33] <mok0> gogogogo
[15:33] <sebner> -.-
[15:33] <mok0> rofl
[15:33] <sebner> mok0: https://bugs.edge.launchpad.net/ubuntu/+source/xgalaga/+bug/237082   =)
[15:34] <mok0> sebner: another desktop file addition
[15:34] <sebner> mok0: unfortunately
[15:34] <sebner> isn't norsetto the .desktop guy?
[15:34] <mok0> I will sponsor it if you send that to the Debian maintainer
[15:35] <sebner> mok0: it is there since 329 days but I'll update it
[15:35] <mok0> We don't want all those tiny deltas
[15:36] <mok0> sebner: you mean it's been on the bug tracker for 329 days?
[15:36] <sebner> mok0: exactly
[15:36] <persia> mok0: xgalaga is up for adoption.  It's in git.  Grab Joey's git, and update it, and take it over (after getting Joey's approval and confirming with Debian-Games), if you like.
[15:36] <persia> mok0: Also, we do want delta for .desktop files, as we don't support Debian menu files very well.
[15:39] <mok0> persia: But if the DM will put it in, that's better
[15:40] <geser> sebner: as I don't have currently time to check the openbox sync I've subscribed u-u-s to the bug. So mok0 can review it if he has time.
[15:40] <mok0> persia: I don't have an interest in xgalaga, really
[15:40] <sebner> geser: ah good to know, thanks
[15:40] <sebner> mok0: go go go =)
[15:40] <persia> mok0: Agreed.  It's not worth keeping a delta without a BTS entry unless we really, really, need to do so.
[15:40] <mok0> sebner: It's not clear to me why the Ubuntu delta can be scrapped
[15:40] <sebner> mok0: openbox? sec
[15:41] <sebner> mok0: because we synced it a long time .. reduce the double work ..
[15:41] <mok0> sebner: but it must have been repackaged for a reason
[15:41] <soren> kirkland: There's nothing technically wrong with putting me and jamie as uploads in your ubuntu-virt package, but it's a bit confusing since we don't use it in Ubuntu.
[15:41] <sebner> mok0: hardy release maybe?
[15:42] <soren> kirkland: uploaders, I mean.
[15:42] <kirkland> soren: oh, right
[15:42] <kirkland> soren: i'll fix that and put another revision in REVU
[15:42] <kirkland> soren: i was mirroring what I saw in another package
[15:42] <sebner> mok0: not sure if it's ready for the hardy release maybe
[15:42] <sebner> mok0: the debian version to sync I mean
[15:43] <soren> kirkland: While you're at it, please make a copy of the GPL and stick it in the top level directory of the package. Call it COPYING.
[15:44] <sebner> RainCT: can you give us feedback?
[15:44] <kirkland> soren: it's currently in debian/copyright
[15:46] <soren> kirkland: Not quite.
[15:47] <soren> kirkland: debian/copyright actually specifically says: You should have received a copy of the GNU General Public License
[15:47] <soren> along with this program.  If not, see <http://www.gnu.org/licenses/>.
[15:47] <soren> kirkland: The package looks fine, so I'm going really nitpicky on you right now :)
[15:47] <soren> kirkland: Your .PHONY target in debian/rules refers to a checkroot target which doesn't exist.
[15:48] <sebner> mok0: later, are you reviewing the merge or should I subscribe u-u-s?
[15:48] <soren> kirkland: the build-stamp target seems superfluous.
[15:48] <soren> kirkland: So does the install target.
[15:48] <kirkland> soren: hmm, okay
[15:48] <soren> And build is missing from .PHONY.
[15:49] <soren> kirkland: There's a tiny, tiny bug in debian/control, but that's more of an issue with ubuntu-vm-builder, actually :)
[15:49] <mok0> sebner: I will review it
[15:49] <sebner> mok0: fine =) *convinced* =)
[15:50] <sebner> mok0: And now I also have the LP number in the changelog ^^
[15:51] <soren> kirkland: A package must not depend on a package of lower priority than itself, and u-v-b is priority: extra, but I think it's ok to change u-v-b to optional.
[15:51] <kirkland> soren: okay, what bug is that?
[15:51] <kirkland> soren: ah
[15:52] <Iulian> How do I add an icon to the Programming category? I did have a look at standards.freedesktop.org but I couldn't find anything.
[15:53] <afflux> nicolasvw: I added a patch for bug 231303, please add that one to the packaging using dpatch.
[15:53] <amikrop> Sorry for disturbing again, but I have a problem with dh_make. I don't really get how it works. We get into the directory where we have our filesystem tree and run dh_make?
[15:54] <Iulian> amikrop: You have to run dh_make in the source dir.
[15:54] <persia> amikrop: Be careful with dh_make.  It makes many assumptions, some of which are completely wrong, and contains lots of files you don't need.
[15:55] <Iulian> amikrop: You might want to have a look at man dh_make
[15:55] <amikrop> I have a directory. Let's say "my-package/". Inside there are two directories, e.g. "etc/" and "usr/". Where do I run dh_make?
[15:55] <sebner> persia: but a beginner shouldn't create the files manually I suppose O_o
[15:56] <mok0> sebner: yes, good boy...
[15:56] <sebner> ^^
[15:56] <amikrop> Wait, dh_make is about source archives. I don't have a source archive. I just want to place some Python scripts into the filesystem.
[15:56] <persia> sebner: Why not?
[15:57] <persia> sebner: amikrop can basically copy his special custom license for copyright, needs to do control anyway, and can use a 1-line CDBS rules.
[15:57] <sebner> persia: Just think that scare a little bit
[15:57] <sebner> persia: well, this is a special case
[15:58] <amikrop> I mean, I don't have a .tar.gz file with C source code in it. I just want to place some Python script into specific directories.
[15:58] <amikrop> *scripts
[15:58] <persia> amikrop: Right.  As I said before, first create your tar.gz file with your scripts, and then package it.
[15:59] <kirkland> soren: okay, if that's all, i'll go make those changes happen
[15:59] <amikrop> "Packaging from Scratch" assumes that I have C source.
[15:59] <amikrop> Which I want to compile.
[16:00] <soren> kirkland: That's all I could find.
[16:00] <soren> kirkland: :)
[16:00] <amikrop> persia: But how to package it? How can I tell debhelper where I want it to put my scripts?
[16:00] <kirkland> soren: k
[16:00] <persia> amikrop: Your 1-line CDBS debian/rules will call dh_install.  You put the instructions in debian/install.  man dh_install
[16:01] <amikrop> OK
[16:02] <RainCT> sebner: eh?
[16:02] <RainCT> :P
[16:03] <sebner> RainCT: -.-, can we sync openbox? We you started packaging at your own?
[16:04] <amikrop> It seems I am missing something here. All I know about packaging is "the IBM guide". I haven't understood anything from "Ubuntu Complete Packaging Guide". I think I am missing the essence (I am not a native English speaker). Can someone explain the basics, please?
[16:04] <amikrop> Such as ... what do we do?
[16:05] <RainCT> sebner: if no (important) changes are lost by doing so, yes
[16:05] <amikrop> I would be grateful.
[16:05] <sebner> RainCT: second question? We = why ^^
[16:06] <RainCT> sebner: and what do you mean with "you started packaging at your own"?
[16:06] <RainCT> sebner: I just uploaded the new version in time for hardy
[16:06] <sebner> RainCT: -0ubuntu1, so because of the time you didn't sync it from debian?
[16:07] <mok0> RainCT, sebner, I just ack'ed the openbox sync
[16:07] <mok0> sebner: RainCT forked it off in Jan 2008
[16:08] <amikrop> persia: Can you please explain me the basics? Don't assume that I know anything. It would be really nice if you could explain me what do we do. Just the very basics. How do we start, for example. I can't understant "Ubuntu Complete Packaging Guide".
[16:08] <amikrop> *understand
[16:09] <mok0> sebner: the earlier version was 3.4.5-1, and RainCT created 3.4.6-0ubuntu1
[16:09] <RainCT> right.. I don't remember now but that was probably when FF was approaching
[16:09] <sebner> mok0: you have the responsibility :P xD
[16:09]  * persia is distracted by many things, but may explain later, if sufficienly motivated to lecture
[16:09] <sebner> mok0: no to be honest I don't see something that speaks against a sync =)
[16:10] <mok0> sebner: right
[16:10] <sebner> mok0: ah kk, just can't remember but I wasn't requesting a sync just for fun so it should be right ^^
[16:10] <sebner> RainCT: fine, thanks
[16:10] <RainCT> and I updated openbox and obconf and send patches for both to Debian (obconf was updates some days later with the changes from my patch)
[16:10] <mok0> sebner: but your request was not really adequate, I am sorry to say
[16:10] <sebner> persia: no stress, calm down =)
[16:11] <sebner> mok0: I'll have to learn to explain/write more. thanks for the hint
[16:12] <lukehasnoname> Guys, I can't get into #ubuntu (using mibbit) so I'll ask here quickly: I need a CHM reader. CHM viewer won't show pages correctly, anything else that works?
[16:12] <mok0> sebner: yeah, you have to provide the reasons why, "time to sync" is not convincing
[16:12] <mok0> lukehasnoname: CHM??
[16:12] <amikrop> geser: Or, could you help me, please? I have not understood anything from "Ubuntu Complete Packaging Guide". Could you explain the very basics? Like, what do we do?
[16:13] <sebner> mok0: I just don't want to steal the reviewer all the work :P Everybody has to train his brain xD
[16:13] <mok0> sebner: very funny ha, ha, ha.
[16:13] <lukehasnoname> Microsoft Compiled HTML Help
[16:13] <lukehasnoname> mok0
[16:14] <persia> lukehasnoname: This still isn't a support channel.  There's a way to get into #ubuntu with mibbit: read the instructions in the redirect.
[16:14] <mok0> Feel the force, lukehasnoname...
[16:15] <kirkland> soren: okay, so I should drop the Uploaders line entirely?
[16:15] <lukehasnoname> props persia. I didn't get that floodbot message last time. Sorry to interrupt
[16:15] <kirkland> and as for Maintainer, I put myself...  Is that correct?
[16:15] <soren> kirkland: It's not incorrect :)
[16:15] <mok0> "compiled html" ... that would be Microsoft allright
[16:16] <soren> kirkland: We generally put either motu or core-dev, but as long as it's an @ubuntu.com address, you're fine.
[16:16] <kirkland> soren: what is correct?
[16:16] <soren> kirkland: And yes, drop the uploaders line entirely.
[16:16] <kirkland> soren: dropped.
[16:16] <kirkland> soren: i'll make motu the maintainer
[16:16] <soren> kirkland: its presence suggests a Debian origin, which clearly is not the case :)
[16:17] <soren> kirkland: Alright. It's: "Ubuntu MOTU developers<EMAIL_ADDRESS>[16:17] <kirkland> soren: right, thanks.
[16:18] <kirkland> soren: okay, cp /usr/share/common-licenses/GPL-3 to COPYING in the top level of the package
[16:19] <mok0> ok, sebner your stuff is off the table now
[16:19] <kirkland> soren: checkroot removed
[16:19] <sebner> mok0: fine. May I find more? ^^
[16:19] <kirkland> soren:  all references to build-stamp removed
[16:20] <mok0> sebner: go right ahead. Of course they can always sit in the queue
[16:20] <kirkland> soren: what about build and binary-arch targets?  they're empty too.....
[16:20] <soren> kirkland: You need binary-arch.
[16:21] <soren> kirkland: It's mandatory.
[16:21] <soren> kirkland: So is build.
[16:21] <kirkland> ok
[16:21] <soren> kirkland: install is not, so feel free to drop that.
[16:21] <soren> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[16:21] <kirkland> soren: thanks.
[16:21] <sebner> mok0: IIRC they are in queue ^^
[16:22] <kirkland> soren: okay, as for the priority, i think ubuntu-vm-builder should be increased to "optional" for intrepid....  what do you think?
[16:22] <sebner> bug #234162
[16:22]  * persia will be giving a special packaging lesson on how to package scripts, webapps, and firmware installers in #ubuntu-classroom starting at 15:30 UTC today.
[16:22] <sebner> mok0: =)
[16:22] <kirkland> soren: sorry, i see that you said that above
[16:23] <sebner> persia: that's in 8 minutes xD
[16:23] <mok0> Hey, that's in 7 minutes!!
[16:23]  * persia goes off for a snack
[16:23]  * mok0 rushes over to #ubuntu-classroom to get a good seat
[16:23] <sebner> persia: but don't come too late xD
[16:23] <kirkland> soren: okay, so I'm going to leave ubuntu-virt as "optional", and submit a patch/branch to you changing u-v-b to optional
[16:23] <soren> kirkland: Alright.
[16:23] <sebner> mok0: ACK my sync first. I like my description  ;)
[16:24] <geser> mok0: what's in #u-classroom?
[16:24] <soren> It's secret.
[16:24] <kirkland> soren: do I bump the version from 1.0 to 1.1 now when I push to REVU again?
[16:24] <geser> hmm, /me has to look himself then
[16:25] <mok0> geser: eerrr persia's giving a class there?
[16:25] <mok0> sebner: I have to verify that of course...
[16:25] <sebner> mok0: sure :)
[16:25] <soren> kirkland: No.
[16:27] <mok0> hmph, I can't join u-classroom...
[16:28] <mok0> there
[16:29]  * sebner winks mok0
[16:29]  * mok0 hugs sebner
[16:29]  * sebner hugs mok0 back =)
[16:29] <kirkland> soren: crap, sorry, got your response too late....
[16:30] <kirkland> soren: I built and uploaded ubuntu-virt_1.1 to REVU
[16:30] <schmiedc> when does the lesson start there?
[16:30] <kirkland> soren: PPA's won't take an updated package with the same version number
[16:30] <mok0> schmiedc: now
[16:30] <kirkland> soren: I assumed REVU was the same
[16:30] <schmiedc> :)
[16:31] <kirkland> soren: besides, i kinda wanted the changelog entry, so that I can go back through all the advice i got on this package
[16:31] <soren> kirkland: Right.
[16:32] <persia> kirkland: Many reviewers will discourage multiple changelog entries on REVU
[16:34] <kirkland> persia: seriously?
[16:35] <kirkland> hrm  :-/
[16:36] <ScottK> kirkland: The purpose of REVU is to get packages reviewed for inclusion in the archive.  The debian/changelog should be appropriate for that.  You can use review comments to keep track of what's happened between each upload.
[16:38] <kirkland> ScottK: okay thanks.  the confusion really comes from the difference between the PPAs and REVU.  PPAs will reject a second upload of a version already present.  Evidently REVU will not.
[16:38] <ScottK> No.  That's a feature of REVU.  You can do multiple uploads of the intended package until you get them right.  REVU will also give you diffs between the uploads.
[16:40] <Hobbsee> RainCT: ping
[16:41] <kirkland> ScottK: okay, can I revert the change?  ie, back it down from 1.1 to 1.0 by uploading again?
[16:41] <RainCT> Hobbsee: pong
[16:41] <Hobbsee> RainCT: your gweled upload....
[16:41] <Hobbsee> RainCT: did you test it?
[16:41] <RainCT> yes, I've it installed right now
[16:42] <RainCT> Hobbsee: because of the menu?
[16:42] <Hobbsee> RainCT: yeah.  looks like it's changed the default language for everyone.
[16:42] <Hobbsee> RainCT: was that intentional?
[16:43] <kirkland> ScottK: Already uploaded to revu.tauware.de
[16:43] <kirkland>
[16:43] <kirkland> ScottK: looks like no
[16:43] <RainCT> Hobbsee: no, I have to look at that some day
[16:43] <Hobbsee> RainCT: fixing it now - there's a patch.
[16:43] <Riddell> Iulian: ping
[16:43] <RainCT> Hobbsee: oh ok, great :)
[16:43] <RainCT> Hobbsee: was this caused by the upload?
[16:43] <ScottK> kirkland: On revu you can ask someone to nuke the upload and start over.
[16:43] <Hobbsee> RainCT: looks like the patch did a whole bunch of the glade file over again, including changing language.
[16:43] <Hobbsee> RainCT: yup
[16:44] <Hobbsee> RainCT: the original patch shows the french.
[16:44] <kirkland> REVU people: can you nuke ubuntu-virt so that I can start over?  problems with the versioning of the package, and it's just getting more confusing....
[16:44] <Iulian> Riddell: pong
[16:44] <Riddell> Iulian: giver seems to have two wrapper scripts, giver and givere, the only difference is that givere is sh not bash, is that intended?
[16:45] <RainCT> Hobbsee: uops, sorry then
[16:45] <Iulian> Riddell: Hmm, no, I don't think so. It should be the same as giver.
[16:45] <Riddell> Iulian: but givere is intended to be there?
[16:45] <Hobbsee> RainCT: the more amusing thing is that i've only noticed this tonight.
[16:46] <ScottK> RainCT or Hobbsee: Would one of you please nuke ubuntu-virt off REVU for kirkland?
[16:46] <Iulian> Riddell: Not really, no. I will have a look at it to be sure.
[16:46] <RainCT> ScottK: sure
[16:46] <ScottK> kirkland: ^^
[16:47] <kirkland> ScottK: thanks much!
[16:47] <ScottK> RainCT: Thanks.
[16:47] <kirkland> RainCT: let me know when I can upload again
[16:47] <ScottK> RainCT: Didn't MOTU used to have a nuke this package button on REVU?
[16:47] <RainCT> ScottK: it depends on which level you have, contributor or admin.. but as a MOTU you should be admin
[16:48] <RainCT> ScottK: to be sure, you don't even have the 'archive' button?
[16:49] <RainCT> kirkland: done :)
[16:49] <kirkland> RainCT: cool, thanks
[16:50] <ScottK> RainCT: I have archive, but not nuke.
[16:50] <RainCT> ScottK: ah. and if you archive something and then go to the archived uploads page, there isn't nuke?
[16:50] <ScottK> Ah.  Didn't try that.
[16:50] <RainCT> (or even without archiving anything)
[16:51] <ScottK> RainCT: That's it.  Thanks.
[16:51] <RainCT> np :)
[16:52] <kirkland> RainCT: hmm, it's still telling me "Already uploaded to revu.tauware.de" ... is there some meta data in my local directory blocking an upload?
[16:52] <sistpoty|work> kirkland: yes a .upload file (you can use dput -f)
[16:52] <RainCT> moment
[16:53] <RainCT> ah, right
[16:53] <RainCT> sistpoty|work: no need to run that root script manually or?
[16:53] <RainCT> (root script = script as root)
[16:53] <sistpoty|work> RainCT: hm? which one?
[16:54] <sebner> sistpoty|work: I just merged xgalaga. You'll like that game ^^
[16:54] <ScottK> kirkland: Alternatively just delete the .upload file and then dput normally.
[16:54] <RainCT> sistpoty|work: wasn't there a file which you have to execute to completely clean up nuked stuff?
[16:54] <sistpoty|work> sebner: haven't tried it yet iirc
[16:54] <sistpoty|work> RainCT: yes, /me looks
[16:55] <sistpoty|work> RainCT: /srv/uploads/removals.txt
[16:55] <RainCT> sistpoty|work: so is it necessary to run this file before someone reuploads?
[16:55] <sistpoty|work> RainCT: and it should always only be run manually
[16:56] <RainCT> yeh
[16:57] <sistpoty|work> RainCT: no, it's completely unrelated, as every new upload will result in a new upid, and hence in a new directory on the server
[16:58] <RainCT> ok :)
[16:58] <Iulian> Riddell: I don't think it's intended to be there. Afaics givere is the same as giver. I'd have to talk to upstream to be sure but it's pretty inactive, didn't get any mail from them.
[16:58] <Iulian> Riddell: Is there anything you might want to suggest?
[16:58] <nicolasvw> afflux: got that, thankx for the patch
[17:02]  * Hobbsee ponders actually doing a SRU.
[17:02] <kirkland> soren: okay, REVU issues sorted out, uploaded a new copy of ubuntu-virt_1.0
[17:02] <kirkland> soren: http://revu.ubuntuwire.com/details.py?package=ubuntu-virt
[17:02] <sebner> mok0: thanks =) Now I only have *1* merge left
[17:04] <emgent> heya people
[17:21] <Riddell> Iulian: I don't mind, I accepted it
[17:22] <Neurostu> when specifying dependencies in control, do I need to specify each library individually or can in use wildcards like: libboost*
[17:22] <Iulian> Riddell: Ok, I will fix it in the next upload.
[17:23] <geser> Neurostu: use ${shlibs:Depends} and dh_shlibdeps in debian/rules to get this field filled during build
[17:26] <Neurostu> geser: so i found dh_shlibdeps in my rules file, what is the syntax to list the libs under that? Also can I use wild cards or do I need to specify the libs one by one
[17:26]  * sistpoty|work heads home... cya
[17:27] <geser> Neurostu: dh_shlibdeps checks the binaries of your package which libs there are linked with, look up the packages they are in and puts this into the variable ${shlibs:Depends}
[17:30] <sebner> *tumbs up* for persia  =)
[17:32] <Neurostu> Sorry, I know it can be hard to explain thing to noobs, but I just want to make sure I get this.  I have dh_shlibs uncommented in rules, and I have Depends: ${shlibs:Depends} in my control file,  is that all I need? Or do I need to specify the list of dependencies
[17:32] <geser> Neurostu: that's all you need
[17:32] <geser> Neurostu: at least for libraries
[17:33] <geser> if you need some other packages too then you must add them manually to Depends
[17:37] <Neurostu> ok great. Thanks
[17:41] <Iulian> Would anyone like to sponsor bug 237018? Here you can find the debdiff http://paste.ubuntu.com/16606/plain/
[17:46] <mok0> Iulian: I'll sponsor it if you promise to forward the mods to the DM
[17:48] <Iulian> mok0: I was doing that right now.
[17:48] <mok0> Iulian: cool :-)
[17:48] <sebner> mok0: I made the experience that we should report that back to debian and wait for a sync ^^
[17:49] <mok0> sebner: then we have to remember to get back to it.
[17:50] <mok0> sebner: if the DM uploads a new version, it will be auto-synced
[17:50] <sebner> mok0: assign the bug to ourself ... dunno. I just heard that very often
[17:50] <mok0> sebner: I know
[17:50] <sebner> mok0: why autosynced?
[17:50] <mok0> because the DM will bump the release by 1
[17:51] <mok0> sebner: automerged, of course
[17:51] <sebner> ^^
[17:51] <sebner> kk
[17:54] <Iulian> A package shouldn't be synced forever, if I'm not wrong.
[17:54] <Iulian> And afaics this package was synced every time.
[17:56] <Iulian> Although I see a lot of packages without an Ubuntu change.
[17:57] <mok0> Iulian: we strive to reduce the number of packages with Ubuntu changes
[18:00] <Iulian> mok0: Right.
[18:02] <mok0> Iulian: but as was said earlier today on the channel, it is sometimes difficult to get the DM to include .desktop entries quickly
[18:03] <Iulian> mok0: Well, they are not so important for a package.
[18:03] <mok0> Iulian: what about the copyright on the icon?
[18:03] <mok0> Iulian: Debian doesn't use them
[18:05] <Iulian> mok0: I'm looking for a copyright. This is the website from where I downloaded it http://developer.imendio.com/issues/browse/GGL-71
[18:05] <mok0> Iulian: that is the most minimalistic debian/copyright I have seen to date... I would not pass in Ubuntu
[18:05] <mok0> s/I/it/
[18:06] <Iulian> mok0: Yea, that's what I thought in the first place.
[18:06] <mok0> Iulian: hm, it says it's qgit's icon...
[18:06] <Iulian> mok0: Indeed
[18:06] <ScottK> Not sure about the package you are looking at now, but debian/copyright on a lot of older packages would seem skeletal if going through New today (Debian or Ubuntu).
[18:07] <sebner> mok0: Do we "have" to convert a .png to a xpm?
[18:07] <mok0> ScottK: it's qgit
[18:07] <ScottK> So I guess it's not so old.
[18:07] <mok0> sebner: yes
[18:07] <ScottK> sebner: No binary files in debian dir.
[18:07] <sebner> kk
[18:07] <mok0> sebner: or uuencode it
[18:09] <Iulian> mok0: So the best way would be to talk to the DM to include the desktop file I created.
[18:10] <slytherin> geser: ping
[18:11] <mok0> Iulian: yes, absolutely, but he may not be motivated to release a new package version just for Ubuntu
[18:11] <geser> slytherin: pong
[18:11] <slytherin> geser: Can you please advocate xml-commons-external?
[18:12] <sebner> mok0: some days ago I reported a change back and 2 hours later he released a new version (though with a lot other changes but somehow lucky) ^^
[18:12] <Iulian> mok0: Exactly
[18:12] <geser> slytherin: will to later today, I'm now in a meeting
[18:12] <slytherin> geser: Ok.
[18:13] <mok0> Iulian: exactly, my comment or sebners?
[18:13] <Iulian> mok0: Your comment.
[18:14] <Iulian> mok0: First of all I should talk to him to see if he is preparing a new upload, if yes I will tell him to include the desktop file too.
[18:14] <mok0> Iulian: But, we need to find out where that icon comes from
[18:14] <mok0> Iulian: ... and the .xpm
[18:15] <Iulian> mok0: The .xpm is the icon I converted from .png
[18:15] <mok0> Iulian: sure, but we only have that guy's word that it's a qgit icon
[18:16] <mok0> It'd be nice to find it and see what the copyright of it is
[18:16] <Iulian> mok0: Yea, that would be nice indeed.
[18:17] <mok0> Iulian: otherwise you have to make one :-P
[18:18] <Iulian> mok0: Ehh?
[18:18] <Iulian> mok0: You have to be kidding me.
[18:18]  * mok0 never kids
[18:18] <Iulian> mok0: To be honest, I don't know nothing about how to create an icon.
[18:19] <mok0> Iulian: but seriously, I don't think we can add an icon as a special Ubuntu feature without knowing that it is allowed
[18:19] <mok0> Iulian: It's just a square image that you scale down to 48x48
[18:19] <mok0> Iulian: The Gimp
[18:20] <Iulian> mok0: Uhmm, yeah, I forgot completely about the copyright thingie.
[18:20] <Iulian> mok0: Do I have to do it manually?
[18:20] <mok0> Iulian: I know... "it's just a little picture..."
[18:20] <Iulian> mok0: With my touchpad? :P
[18:21] <Iulian> mok0: Heh :)
[18:21] <mok0> Iulian: I was thinking... how about taking those little red & black lines and dots from the screenshot
[18:22] <mok0> http://sourceforge.net/project/screenshots.php?group_id=139897&ssid=33933
[18:22]  * Iulian is looking
[18:22] <mok0> green actually
[18:23] <Iulian> mok0: Right
[18:23] <mok0> Iulian: looks a bit like the "old" one
[18:23] <mok0> Iulian: then put a Q in there perhaps
[18:24] <Iulian> mok0: Ohh, you're right. I would have to change that.
[18:24] <Iulian> mok0: Yea, maybe.
[18:24]  * Iulian is opening gimp.
[18:24]  * mok0 has to go cook dinner...
[18:25] <Iulian> mok0: Enjoy
[18:55] <YokoZar> Is anyone here a Debian sponsor?  I'd like to get a package into universe that's currently waiting for sponsorship in Debian: http://mentors.debian.net/debian/pool/main/l/libtorrent-rasterbar/
[18:55] <YokoZar> I could just upload it to Ubuntu myself, but it seems like it'd be better to go the Debian route first.  The package has been waiting for a Debian sponsor for a few weeks now
[19:02] <Neurostu> So I'm almost done getting my packages built... I got them to compile but I get the following error when I try to install them, here are the last few lines of the error: http://mwl.pastebin.com/m72720411
[19:02] <Laney> Neurostu: Did you install using dpkg?
[19:02] <Neurostu> I specified the package that I need to run the program in the control file so shouldn't it automatically download when I run dpkg -i package.deb
[19:03] <Neurostu> yes I used dpkg
[19:03] <geser> Neurostu: sudo apt-get -f install
[19:03] <slytherin> YokoZar: If you are uploading it to Debian already then it is better to file a sync bug once it gets accepted.
[19:03] <geser> Neurostu: dpkg -i doesn't install the dependencies for you, only apt-get
[19:03] <slytherin> Neurostu: dpkg doesn't work that way
[19:04] <Neurostu> ok, can apt-get install from a local deb? or does it only install from repos?
[19:04] <geser> Neurostu: only from a repo, but it can be a local repo
[19:05] <Neurostu> ok great thanks
[19:08] <Neurostu> Great, it grabbed the needed packages from the ubuntu repos! Thanks! you guys really have helped me out a ton!
[19:17] <YokoZar> slytherin: I'm not a Debian developer, that's why I need a Debian sponsor to do it (it's not my package, but a package I want to upload depends on it)
[19:20] <slytherin> YokoZar: Fine. My point is that once someone sponsors it into Debian, file a sync bug. You will have wait for a while.
[19:20] <slangasek> er, no sync bug needs to be filed
[19:20] <slangasek> we're in auto-sync mode right now
[19:21] <YokoZar> slytherin: Yeah, that was my thought.  Just wanted to poke around here and hope I can get it sponsored so I can get working on the dependent packages ;)
[19:30] <ScottK> slytherin: Also there's no harm in waiting a while at this point in the release cycle.
[19:30] <slytherin> :-)
[19:31] <slytherin> geser: One more request. I have filed bug 235737 for moving glassfish-javaee to universe. It will be great if you can verify and ack it.
[19:46] <Laney> Huh? Someone confirmed one of my merge bugs
[19:48] <ScottK> Laney: Put it back and point the triager too https://wiki.ubuntu.com/Bugs/HowToTriage#head-0670f256d42484d8f9d0cec896eb2c05e43388e3
[19:48] <Laney> ScottK: Thanks, will do
[20:24] <aDmos> hi an alle. ist deutsch als sprache ok?
[20:24] <laga> english is much preferred
[20:24] <aDmos> ok, sorry
[20:33] <Neurostu> can anyone recommend some literature on how to sign packages? I've tried reading the ubuntu wiki page but it isn't making a lot of sense
[20:35] <schmiedc> how to you mean sign?
[20:36] <geser> Neurostu: where are you struck?
[20:36] <schmiedc> isn't it with gpg
[20:37] <geser> yes, it is
[20:37] <Neurostu> So I've built my packages but when I install them it says: WARNING: The following packages cannot be authenticated!
[20:37] <Neurostu> yes I want to sign with gnupg
[20:38] <schmiedc> have you attached your key to your launpad acc?
[20:38] <Neurostu> so I don't even  have a key yet...
[20:38] <Neurostu> or a launchpad acct
[20:39] <schmiedc> i am pretty new to that stuff myself
[20:40] <schmiedc> so from where do you want to install your packages?
[20:40] <Neurostu> geser: from what I've read, it looks like all I need to do is great a signature and then pass that to dpkg-buildpackage to sign the package, is this right
[20:40] <geser> Neurostu: ah, you talk about repository signing
[20:40] <Neurostu> I'm going to host them from my own webserver
[20:41] <Neurostu> geser: yes I think so..
[20:42] <geser> you need to sign the Release file
[20:42] <geser> and on the client add the public key you signed the repository with
[20:42] <geser> depending on the software you use to manage the repository it can perhaps automate this all
[20:42] <geser> (the signing of the Release file)
[20:43] <RoAkSoAx> wouldn't be easy to just use a PPA?
[20:43] <geser> RoAkSoAx: PPAs aren't signed
[20:43] <Neurostu> so what is a Release file?  So I haven't been using any software to manage the repo, i've just been doing it all by hand (granted the repo only has 2 packages in it and probably won't grow past 10 packages or so)
[20:44] <RoAkSoAx> true
[20:45] <RoAkSoAx> but instead of setting a hole new repo server would be easy to have a PPA, right?
[20:45] <Neurostu> So, we already have a webserver running, it is hosting our SVN repo, and our wiki
[20:45] <Neurostu> we would like to keep everything in house as well
[20:48] <Neurostu> Geser: So all I need to do is create a release file, sign it, and give my users the public key?
[20:49] <geser> yes
[20:49] <laga> falcon is a very nice piece of software to manage a repository. just in case you don't want to do it all manually.
[20:49] <geser> Neurostu: see e.g. http://falcon.kaarsemaker.net/ for an easy repository manager which can create a gpg-signed repository
[20:50] <Neurostu> ty
[20:52] <NielsE> I'm working on the packagingGuide with the gnu-helloWorld, now I want to change the text of the manpage, where can I do that? ./man/hello.1 gets overwritten each time I "debuild"
[20:52] <lukehasnoname> laga and geser thanks for that, I've wondered what it takes to set up a repo
[20:55] <ScottK> lukehasnoname: Falcon is pacakged and in the Ubuntu repository for Hardy.
[20:57] <LaserJock> mok0: ping
[21:00] <LaserJock> norsetto: ping
[21:01] <sebner> LaserJock: huhu, how are you? how are you doing with your studies?
[21:01] <LaserJock> pretty good
[21:01] <norsetto> LaserJock: yessir!
[21:02] <LaserJock> norsetto: libitpp SRU
[21:02]  * norsetto stands on attention
[21:02] <LaserJock> norsetto: where are we with that
[21:02] <norsetto> LaserJock: yessir yes
[21:02] <norsetto> LaserJock: the bug report says it all
[21:02] <LaserJock> I poked around with it this morning and it builds fine
[21:03] <norsetto> LaserJock: it builds fine, it installs fine, it runs fine
[21:03] <LaserJock> is that sufficient for a "works for me"?
[21:03] <norsetto> LaserJock: last I talked with pitti he was pretty happy with it, I don't know why he hasn't uploaded yet, perhaps just busy with other stuff
[21:04] <LaserJock> norsetto: OK, I'll add a "builds/installs fine here, please move to -updates"
[21:04] <norsetto> LaserJock: okki dokki, it won't hurt, thanks for checking it
[21:04] <LaserJock> norsetto: thanks for doing the SRU
[21:05] <norsetto> LaserJock: my pleasure
[21:13] <norsetto> sebner: how are things going with eggdrop?
[21:14] <sebner> norsetto: will fight it on weekend.  When should I start =)
[21:16] <DktrKranz> sebner, you only receive a "uploaded, thanks ;)", no money
[21:16] <\sh> sebner, just do your abi and study :)
[21:16] <laga> sebner: you doing your abi this year?
[21:16] <sebner> folks, I'm young. don't destroy my dreams xD
[21:16] <sebner> laga: yes
[21:16] <\sh> if you don't do that, you'll end like me...old, motu and stressfull senior unix admin...you don't want to do that
[21:16] <sebner> laga: in 3 weeks
[21:17] <laga> sebner: good luck. my GF will be done on thursday. :)
[21:17] <sebner> \sh: no, I hate server stuff :P
[21:17] <sebner> laga: ^^ thanks
[21:17] <laga> sebner: i got mine last year.. and i didn't enjoy the process, so be smarter than me and actually start studying when there's still time left.
[21:17] <laga> ;)
[21:18] <sebner> laga: I discovered that ^^
[21:18]  * norsetto wonders what of the 3 is worse: old, motu or senior unix admin
[21:18] <mario_limonciell> how do you earn an application binary interface?
[21:18] <\sh> sebner, the only way to fly is working with servers...desktops are so user oriented
[21:18] <schmiedc> to late for me to start early enough :P
[21:18] <laga> mario_limonciell: http://en.wikipedia.org/wiki/Abitur :)
[21:18] <sebner> \sh: I'm a user, I'm merging for users ^^
[21:18] <mario_limonciell> laga, oh that's a lot less enjoyable
[21:18] <\sh> norsetto, you don't say anything ;)
[21:19] <mario_limonciell> i'll continue to pretend that you meant what i thought you did by ABI
[21:19] <laga> mario_limonciell: well, i rather have abi than ABI - ABIs tend to change a lot.
[21:19] <norsetto> \sh: well, I'm not a senior unix admin :-)
[21:20] <sebner> norsetto: If you don't say you are old, you aren't old xD
[21:20] <\sh> oh well...my boss told me this morning, that I have to give some presentation how the internet actually works for all our development horses ;)
[21:20] <sebner> lol
[21:20] <schmiedc> nice
[21:20] <\sh> na
[21:21] <\sh> if you do some development on web apps or other things using the net, you should already know
[21:21] <schmiedc> ähmm right
[21:22] <\sh> anyways...time to move my old body to the couch and waiting for food
[21:22] <\sh> bbt
[21:22] <schmiedc> gg enjoy
[21:22] <ScottK> \sh: You need another ~10 years before you're allowed to complain about old.
[21:27] <LaserJock> the u-u-s queue is quite long :(
[21:27] <sebner> what's up MOTUs?
[21:27] <sebner> clean the queue :P
[21:28] <schmiedc> where is the queue?
[21:29] <geser> schmiedc: https://bugs.edge.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs
[21:30] <geser> LaserJock: it's not that long if you ignore bug #230350
[21:31] <geser> btw: could someone with more patient try to open that bug and check if there is something to sponsor?
[21:31] <LaserJock> it would be good to clean out the bugs that aren't really appropriate and they should all be triaged (proper status and Importance)
[21:33] <NielsE> I'm working on the packagingGuide with the gnu-helloWorld, now I want to change the text of the manpage, where can I do that?
[21:34] <nicolasvw> geser: they're a few of those upthere I never get to open... lp timeouts on me each time ;)
[21:34] <NielsE> I have changed about every file, but when I install the .deb it gives me the original manpage
[21:36] <norsetto> NielsE: my guess is that you are not installing the updated package, what version would that be? And what version have you installed? You can check with debdiff (or directly in the .diff.gz) if your change was applied correctly
[21:38] <schmiedc> cya
[21:38] <NielsE> norsetto: the changes are beïng applied, the .diff for example note's that ./doc/hello.texi has changed
[21:38] <sebner> norsetto: I'm not working on eggdrop right now but I have a (stupid) question about the control file. why just doesn't we set a "eggdrop replaces eggdrop-ssl" and the other way round?
[21:39] <norsetto> sebner: why would you want to do that? Is not the right use for the replaces
[21:40] <sebner> norsetto: dunno, it's just that my brain tells me that that is the most logical solution xD
[21:41] <geser> nicolasvw: the famous "Missing Debian Maintainer field" bug, it has too many tasks that LP times out regularly
[21:42] <ScottK> geser: There was a fix for that on (IIRC) dogfood.  Dunno if it's deployed now or now.
[21:43] <sebner> ScottK: correct my it that's not true but it seems that this maintainer thing is the fault of the MOTUs since a contributor doesn't get his debdiff uploaded without a missing MOTU field!?
[21:43] <norsetto> sebner: replaces will overwrite the other package, conflicts will just refuse to install
[21:43] <ScottK> sebner: Depends on who uploaded it.
[21:43] <ScottK> sebner: Some of them date to before we had a policy to change the maintainer.
[21:43] <sebner> ScottK: but not all :P
[21:44] <ScottK> Yes.
[21:45] <sebner> norsetto: if I have eggdrop installed and want to install -ssl it conflicts so I have to remove the one first. Replaces does this automatically for me so why isn't that the best solution??
[21:45] <norsetto> sebner: because some users may do that without knowing, like installing eggdrop and eggdrop-ssl at the same time
[21:45]  * ScottK hands sebner update-alternatives
[21:46] <sebner> norsetto: what happens if I install both at the same time?
[21:46] <sebner> ScottK: hmm?
[21:46] <norsetto> sebner: you really want to use replaces when a package "functionally" replaces another one
[21:47] <ScottK> sebner: The alternatives system is the way you're supposed to deal with multiple packages doing the same job in the same file namespace.
[21:47] <sebner> ScottK: ah I know that from java ^^
[21:47] <sebner> norsetto: ah I think I'm understanding slowly
[21:48] <LaserJock> I can actually get to the Debian Maintainer bug now
[21:48] <nicolasvw> woohoo LaserJock ;)
[21:49] <sebner> norsetto: like libungif and libgif or how that was called!?
[21:52] <norsetto> sebner: dunno about that
[21:53] <sebner> norsetto: nvm. Will bug you again on weekend =)
[21:53] <apachelogger> sebner: that was/is a transition
[21:54] <apachelogger> the libgif src now creates a libungif package which is eventually empty and just depends on libgif
[21:54] <sebner> apachelogger: yes but the both libs have the same functionality?
[21:54] <apachelogger> yep
[21:54] <sebner> so I'm right
[21:54] <sebner> ^^
[21:54] <LaserJock> I got a question about the u-u-s queue, should unsub'ing when a task is done or is not ready for action?
[21:55] <LaserJock> I noticed that u-u-s is subscribed to a total of ~ 2k bugs
[21:55] <sebner> LaserJock: 2k? xD rofl
[21:55] <ScottK> LaserJock: How many of those are the Debian Maintainer bug?  It'll show up once per affected package.
[21:56] <cody-somerville> I only see 139 bugs.
[21:56] <ScottK> Have I mentioned lately that I'm not a fan of the LP U/I.
[21:56] <LaserJock> well, I think there are only ~ 100 total for the Debian Maintainer
[21:56] <LaserJock> cody-somerville: that's the open bugs
[21:56] <LaserJock> there are 2k total subscribed
[21:56] <sistpoty> <- off to bed
[21:56] <sistpoty> gn8 everyone
[21:57] <ScottK> LaserJock: Most people don't bother to unsubscribe if they've fixed it.  I don't see that as a real problem.
[21:57] <LaserJock> ScottK: it's not particularly, I just wonder if it eventual would bite us in the butt if it just keeps going up
[21:58]  * cody-somerville wonders if launchpad is 32bit of 64bit.
[21:58] <cody-somerville> *or
[21:58]  * norsetto wonders if launchpad is real
[21:59] <LaserJock> but more important are the Incomplete bugs and ones that are not ready or appropriate for u-u-s
[21:59] <ScottK> It's a pretty beefy postgres DB on the back end, I think it won't be a problem.
[22:01] <sebner> norsetto: maybe canoncial released a haXX0r virus that makes a illusion -> LP xD
[22:01] <LaserJock> I think maybe we should close the Debian Maintainer bug
[22:01] <LaserJock> how are we even supposed to work with debdiffs, etc. on that thing
[22:02] <LaserJock> s/we/you all/ ;-)
[22:02] <ScottK> LaserJock: I think it's like the Perl 5.10 transition bug.  It'd have been better not filed, but at this point the damage is done.
[22:02] <ScottK> LaserJock: I'd do it from bugmail myself.
[22:02] <sebner> ScottK: how to process this then? Automatically rebuild als the packages against new perl?
[22:03] <LaserJock> ScottK: which bugmail? from u-u-s subscription?
[22:03] <ScottK> Well if you're subscribed to bugs for any of the affected packages, you get it all.
[22:03]  * ScottK certainly does for both.
[22:03] <LaserJock> I just wonder if we could at least unsub u-u-s
[22:03]  * ScottK sort of assumed that was generally applicable.
[22:03] <LaserJock> it's rather pointless, IMO
[22:03] <ScottK> Agreed.
[22:04] <norsetto> LaserJock: my guess is that if you unsubscribe it, it is going to be subscribed again in no time
[22:05] <LaserJock> norsetto: why? we can send an email to -motu
[22:05] <ScottK> LaserJock: Then the next hopeful who attaches a debdiff subscribes it again.
[22:05] <LaserJock> hmmpf
[22:06] <LaserJock> surely we can handle a small deviation from normal workflow
[22:06] <norsetto> LaserJock: about workflow, where are we with this election business!?
[22:07] <LaserJock> hmm
[22:07] <ScottK> LaserJock: I say we assign it to they guy that filed it and make him sponsor all the uploads.
[22:07] <ScottK> they/the
[22:07] <LaserJock> ScottK: that's not a bad idea :-)
[22:08] <LaserJock> ScottK: it's not a terribly important bug, IMO, since we already decided to change as we uploaded
[22:09] <ScottK> Agreed.
[22:09]  * ScottK just wishes he could unsubscribe from the bugmail.
[22:09] <ajmitch> good morning
[22:09]  * cody-somerville wishes he didn't get unwanted bugmail.
[22:09] <LaserJock> norsetto: my guess is we may just want to have a consensus on how many people to have on the team
[22:09]  * cody-somerville wishes bugs didn't exist.
[22:10] <LaserJock> norsetto: if it's ok to just add all 3 then we're ready to go
[22:10] <norsetto> morning ajmitch
[22:10] <sebner> cody-somerville: do would you do then for (x)ubuntu? ^^
[22:10] <cody-somerville> :O
[22:10] <norsetto> LaserJock: lets say, if somebody is not ok then we change ;-)
[22:11] <sebner> first do = what ^^
[22:11] <cody-somerville> sebner, jerk! Xubuntu is not buggy :P
[22:11] <sebner> cody-somerville: Oh sorry. I forgot :P
[22:11] <norsetto> cody-somerville: does xubuntu use gconf keys?
[22:11] <LaserJock> norsetto: well, follow up sistpoty's email with that please
[22:11] <LaserJock> norsetto: just a "If nobody objects I say we add all 3" or some such
[22:12]  * andrew_sayers wishes he had bugs enough to complain about :p
[22:12] <norsetto> LaserJock: indeed
[22:12] <cody-somerville> norsetto, Isn't that done on the application level?
[22:12] <norsetto> cody-somerville: ok, so, there is no infrastructure being provided by the desktop manager?
[22:13] <cody-somerville> norsetto, Not at the moment. They are working on something calling xfconf for 4.6 which will ship with 8.10
[22:13] <cody-somerville> norsetto, Applications that use gconf use gconf
[22:14] <ajmitch> LaserJock: good to see you back amongst us (again) ;)
[22:14] <LaserJock> ajmitch: bah
[22:14] <norsetto> cody-somerville: ok, good to know. Still on xubuntu, do you know what path its used as the default path in file dialogues? $HOME or something else?
[22:15] <cody-somerville> norsetto, $HOME usually
[22:16] <norsetto> cody-somerville: I see, I got a report about one of the applications I packaged where a user is reporting that in the save dialogue the path is always / in xubuntu
[22:16] <cody-somerville> norsetto, what application?
[22:17] <norsetto> cody-somerville: I don't have xubuntu, but its $home in gnome or kubuntu, so I was wondering
[22:17] <cody-somerville> norsetto, I have ubuntu-desktop installed
[22:18] <cody-somerville> norsetto, but we do install gconf
[22:18] <cody-somerville> norsetto, but if a package in ubuntu adds the key and we don't ship that package...
[22:19] <norsetto> cody-somerville: what do you mean you don't ship it? Its in our repo.
[22:19] <cody-somerville> norsetto, We do ship it
[22:19] <cody-somerville> norsetto, What I am saying is that if another package we don't ship installs the key you're using, we might not have it
[22:21] <norsetto> cody-somerville: I wouldn't know about that. Anyhow, if you want to check the bug, its bug 236887. I set it to invalid for the time being, perhaps you can understand why on xuubuntu its doing that?
[22:21] <cody-somerville> norsetto, just because it doesn't work in Xubuntu doesn't mean it isn't a bug in your package
[22:22] <norsetto> cody-somerville: thats why I would like a xubuntu guy to check it out, I can't reproduce in gnome/kubuntu
[22:23] <cody-somerville> norsetto, Instead of closing the bug you should have marked it as incomplete and given a test case for someone else to try and confirm.
[22:23] <cody-somerville> norsetto, If you'll do that, I'll be happy to try and reproduce it.
[22:23] <norsetto> cody-somerville: I can do that, no problem.
[22:23] <cody-somerville> Thanks :)
[22:26] <norsetto> cody-somerville: done, thanks for helping
[22:29] <cody-somerville> norsetto, no problem
[22:32] <lukehasnoname> I'm surprised mono isn't in multiverse
[22:32] <ScottK> Why?
[22:32] <ScottK> Theories of maybe it has patent problems don't count.
[22:32] <directhex> because novell si teh devil
[22:33] <directhex> now, someone sponsor my mono 1.9.1 merge
[22:33] <ScottK> mono is in Main, isn't it?
[22:33] <directhex> yeah
[22:33] <ScottK> So this would be the wrong channel.
[22:34] <directhex> true
[22:34] <ScottK> directhex: Did you subscribe ubuntu-main-sponsors?
[22:34] <directhex> ScottK, aye
[22:34] <ScottK> That should be enough then.
[22:34]  * norsetto looks around for masochist core-devs
[22:34] <lukehasnoname>  no
[22:34] <lukehasnoname> it is in universe
[22:35] <directhex> no, it's in main
[22:35] <ajmitch> incorrect, main
[22:35] <lukehasnoname> monodevelop (1.0+dfsg-1ubuntu1) [universe]
[22:35] <lukehasnoname> er
[22:35] <lukehasnoname> gm
[22:35] <ScottK> lukehasnoname: He said mono
[22:35] <lukehasnoname> er, hm
[22:35] <lukehasnoname> ya
[22:36] <directhex>      1.2.6+dfsg-6ubuntu3 0
[22:36] <directhex>         500 http://mirror.ox.ac.uk hardy/main Packages
[22:37] <lukehasnoname> as soon as I pasted that I thought, "wait, this argument is too easy
[22:37] <lukehasnoname> "
[22:37] <ScottK> Well then.  You were right about one thing.
[22:38] <ScottK> ;-)
[22:39] <lukehasnoname> I guess main is handled by core devs
[22:39] <lukehasnoname> check, ya
[22:40] <ScottK> Yes and for mono, not this one.
[22:42] <directhex> i'll just poke slomo_ some more.
[22:50]  * ajmitch used to do mono merges, but hasn't touched it for awhile
[22:54] <directhex> well, the debdiff is done, checked, verified, and working for me. but there's all that handwavey "other" stuff that happens in the background to turn bugs into packages
[22:58] <Jazzva> norsetto: Regarding bug 236887, it is mentioned in changelog for gnome-mplayer 0.6.2 as fixed. Should I close the bugreport. gecko-mediaplayer uses gnome-mplayer, so I suppose that gnome-mplayer can be the source of the problem.
[22:59] <Jazzva> norsetto: to close it in the changelog, that is...
[23:01] <norsetto> Jazzva: you mean this one "Fix problem with 'Save As..' where filename started with a /"?
[23:01] <Jazzva> Yep... It sounds similar to the bugreport...
[23:02] <norsetto> I'm not sure actually
[23:02] <Jazzva> Oh, I think I misread it
[23:03] <norsetto> jazzva: but you could be right
[23:03] <norsetto> jazzva: I think you got it right :-)
[23:03] <Jazzva> Well, we can ask upstream, if that's what they meant...
[23:04] <norsetto> jazzva: well, upstream is not very responsive in this kind of questions, you may try
[23:04] <Jazzva> norsetto: I think I saw a bugreport on their BTS, so I'll check again...
[23:04] <norsetto> jazzva: lets check their bts
[23:05] <ember> a package using epoch needs his package.symbols with epochs too?
[23:06] <Jazzva> norsetto: It's not there. I'll file a bugreport, just to see if the change in the ChangeLog is the fix for the bug reported.
[23:06] <norsetto> Jazzva: no, don't do that, just wait a sec
[23:06] <Jazzva> k
[23:09] <guest22> Can someone explain the procedure for submitting a new version of a package already accepted into Ubuntu? Is the review process the same as for a new package?
[23:11] <ScottK> guest22: No.  Make the package, attach the diff.gz to a bug, and subscribe ubuntu-universe-sponsors (if the package is in universe)
[23:15] <norsetto> Jazzva: no, I can't find any reference, but looking at the code I think this is indeed the problem reported
[23:16] <Jazzva> Hmm, we might ask the reporter to test the new package... Dunno, to upload it to the PPA for hardy and to post the link. What do you think?
[23:16] <Jazzva> norsetto ^^
[23:17] <guest22> ScottK: That procedure also holds if the update corresponds to new upstream source? Presumably the diff.gz is just on the debian directories, and the build system access the new upstream source by using the watch file?
[23:17] <norsetto> Jazzva: no, the report is clear, the filename that starts with a /, just close it in the changelog, I'll mark the bug as fix committed
[23:17] <norsetto> jazzva: thanks!
[23:17] <Jazzva> norsetto: No problem. Glad I can help :)
[23:19] <ScottK> guest22: That's the case I was specifically mentioning.  When you make your new source packages, diff.gz is one of the files produced.
[23:19] <ScottK> The sponsor should retrieve the source tarball themselves.
[23:21] <guest22> Sorry, my question wasn't clear. When uploading to REVU, the full debian source package is provided. In this case, only the diff.gz is uploaded, so the source package has to be built by someone before it's included as an update.
[23:23] <norsetto> ok, now that jazzva made my day I can go to bed
[23:23] <norsetto> g'night all
[23:23] <Jazzva> norsetto: You'll have the diffs in the morning ;)
[23:24] <ScottK> guest22: That's correct.  You need to build the source package to make the diff.gz and then the sponsor will make it again when they review/upload it.
[23:26] <guest22> ScottK: And in this case the sponsor is any MOTU who becomes involved by noticing an open bug report, as opposed to noticing a new package for review on REVU?
[23:26] <ScottK> Yes.  This is why you subscrive ubuntu-universe-sponsors.  That puts it on the list to be looked at.
[23:28] <guest22> ScottK: OK, thanks for the explanation.
[23:28] <ScottK> No problem.


[10:51] <czajkowski> maco: ping
[14:30] <maco> czajkowski: pong
[14:31] <czajkowski> maco: the dc loco we re approved you guys cycle didn't we?
[14:31] <maco> yes
[14:31] <czajkowski> maco: by any chance do you have a date?
[14:31] <czajkowski> trying to find logs
[14:33] <maco> april 20
[14:33] <czajkowski> maco: thanks
[17:22] <czajkowski> no hypatia


[06:44] <bkerensa> Any LoCo Council people awake?
[07:16] <bkerensa> anyone awake on loco council?
[07:20] <nigelb> popey: ^
[07:21] <nigelb> Also, czajkowski ^
[07:21]  * nigelb refraints from using the bot
[07:21] <nigelb> If its something really urgent, you can use the bot to ping them all
[07:22] <popey> h
[07:22] <popey> *hi
[07:22] <popey> bkerensa: wassup?
[07:22] <popey> I am about to leave for work, but type what you need and we will see it, or email us
[07:22] <rww> Washington state is up, technically
[07:22] <bkerensa> popey: Hi, Just wondering how we would find out why Oregon LoCo isnt on loco.ubuntu.com I guess its supposed to be automated but were not listed :) we have events coming up we need to post
[07:24] <nigelb> bkerensa: could you link me to the launchpad team please?
[07:24] <rww> psh, I can answer that one. Because you're not in ~locoteams
[07:24] <nigelb> ^ that.
[07:24] <rww> (assuming the link to https://launchpad.net/~ubuntu-us-pnw on the [[OregonTeam]] wikipage is the right team)
[07:25] <rww> although looking at it, you probably mean ~ubuntu-us-or, which is :\
[07:26] <bkerensa> nigelb: http://www.launchpad.net/~ubuntu-us-or
[07:27] <nigelb> bkerensa: ah, your team was recently added into ~locoteams
[07:28] <nigelb> I'll poke chris to nudge the script that updates the teams
[07:28] <bkerensa> yeah a day or two ago but my understanding is the script runs every 15 minutes pulling from launchpad
[07:28] <bkerensa> :)
[07:29] <nigelb> I'm guessing something broke. There has been issues with that machine.
[07:29] <bkerensa> cool
[07:29] <bkerensa> :)
[07:30] <nigelb> any, poked chris. I'll poke him again in his am.
[07:30] <nigelb> *anyway
[12:28] <paultag> nigelb: we already did
[12:28] <paultag> nigelb: ubuntu-us-or was added days ago, the migrate script runs every 20 minutes, something failed
[12:29] <paultag> nigelb: both mike and chris know
[12:31] <nigelb> paultag: yeah, they told me.
[12:32] <paultag> kk
[15:09] <h00k> I always forget to add this to my autojoin.
[15:09] <h00k> Greetings from Wisconsin.
[15:15] <paultag> h00k: Howdy :)
[19:02] <bkerensa> :)
[19:05]  * bkerensa pokes nigelb
[19:07] <nigelb> hey
[19:07] <nigelb> so, this is the comment from paultag.
[19:07] <nigelb> 12:28 < paultag> nigelb: ubuntu-us-or was added days ago, the migrate script runs every 20 minutes, something failed
[19:07] <nigelb> 12:29 < paultag> nigelb: both mike and chris know
[19:07] <nigelb> so, yeah. We're aware and we're trying to fix :-)
[19:49] <dscassel> Anybody have a script to auto-generate team report wiki markup from the LoCo directory?
[19:49] <dscassel> That would be handy...
[19:50] <pleia2> I wish :) if you write one I'd love a copy
[19:50] <YoBoY> +1
[19:50] <dscassel> :)
[19:50] <czajkowski> bug already filed re team reports in the LD
[19:50] <czajkowski> find more developers :)
[19:50] <dscassel> I'll get on it in my copious free time. :)
[19:51] <pleia2> yeah, I haven't done it myself because there are a couple bugs/projects lurking out there for it
[19:51] <pleia2> https://launchpad.net/ubuntu-teamreports is still out there
[19:52] <dscassel> I don't think it needs to be all singing and dancing.  I'll probably want to edit it to add details anyway.
[19:52] <dscassel> tho if someone did the singing and dancing one, I wouldn't complain.
[19:52] <pleia2> :)
[19:54] <mhall119> dscassel: we provide a wonderful API for fetching that kind of data from LD
[19:54] <mhall119> even a python library for it
[19:57] <dscassel> mhall119: Ooh. Nice.
[21:01] <mhall119> dscassel: https://wiki.ubuntu.com/LoCoDirectory/API
[21:01] <mhall119> also https://wiki.ubuntu.com/LoCoDirectory/API/Clients
[22:58] <bkerensa> :P  @ paultag
[23:00] <paultag> bkerensa: :P
[23:09]  * nigelb should try to work on team reports.
[23:19]  * bkerensa needs to do the same :)


[00:06] <cachio> niemeyer, I am gonna build it by hand
[01:10] <cachio> niemeyer, -rw-r--r-- 1 root root 676M Aug  5 00:57 /home/image/all-snap-amd64.img
[01:11] <cachio> this is the size in that machine
[02:26] <niemeyer> cachio: That's pretty large.. we have 2GB of RAM.. doesn't seem so surprising that it's failing
[02:27] <cachio> niemeyer, well, in fact in this machine I see 1GB
[02:27] <niemeyer> cachio: Wat?
[02:27] <cachio>  https://paste.ubuntu.com/25243786/
[02:27] <cachio> yes
[02:27] <cachio> the vm1 is the one failed
[02:27] <cachio> the 2 is another one
[02:27] <niemeyer> That'd explain it.. let me double-check
[02:27] <cachio> sure
[02:28] <niemeyer> /o\
[02:28] <niemeyer> cachio: That's the issue
[02:29] <niemeyer> cachio: and that's why it was so hard to reproduce
[02:29] <cachio> niemeyer, yes
[02:29] <niemeyer> cachio: We had a 1/70 chance of breaking
[02:29] <cachio> niemeyer, hehe
[02:29] <niemeyer> cachio: Sorry for the trouble, my bad
[02:29] <cachio> niemeyer, np
[02:30] <cachio> niemeyer, happy to help
[02:31] <niemeyer> cachio: Problem fixed.. Spread-50 is now 2GB as well
[02:32] <cachio> niemeyer, is spread50 the only one? is it needed to check the others?
[02:32] <niemeyer> cachio: I've just checked
[02:32] <niemeyer> It was indeed the only one
[02:32] <cachio> niemeyer, nice
[02:32] <cachio> niemeyer, nice weekend in that case
[02:33] <niemeyer> The original 50 had a hardware issue, and I replaced it.. that's when I got it wrong
[02:33] <niemeyer> cachio: Thanks, you too
[22:26] <Son_Goku> niemeyer, I did a thing: https://forum.snapcraft.io/t/in-progress-snapd-2-27/572/10?u=conan_kudo
[22:26] <Son_Goku> hopefully zyga can remember what he did last time to fix this so that it won't be released broken for 2.27
[22:27] <Son_Goku> I tried scrolling back through the commits, but alas... there's a lot :D
[22:31] <niemeyer> Son_Goku: Thanks for reporting, let's get that fixed next week
[22:31] <Son_Goku> awesome


[01:05] <guiverc> I know nothing about japanese (or really any non-english usage of a pc)... user asking for some direction with Lubuntu 22.04/jammy and japanese+english here (if anyone can help)  https://ubuntuforums.org/showthread.php?t=2497551


[09:31] <CIA-4> ubiquity: evand * r3254 ubiquity/debian/ (3 files):
[09:31] <CIA-4> ubiquity: Move the ubiquity icon into the ubiquity-ubuntu-artwork package
[09:31] <CIA-4> ubiquity: (LP: #322174).
[11:42] <CIA-4> libdebian-installer: cjwatson * r191 ubuntu/ (debian/changelog src/system/subarch-arm-linux.c): merge from Debian 0.62
[12:08] <CIA-4> libdebian-installer: cjwatson * r192 ubuntu/ (debian/changelog src/parser_rfc822.c):
[12:08] <CIA-4> libdebian-installer: Remove rather silly fwrite _FORTIFY_SOURCE workaround, since Ubuntu's
[12:08] <CIA-4> libdebian-installer: glibc no longer requires this.
[12:10] <CIA-4> libdebian-installer: cjwatson * r193 ubuntu/debian/changelog: releasing version 0.62ubuntu1
[12:18] <CIA-4> choose-mirror: cjwatson * r610 ubuntu/debian/changelog: merge from Debian 2.28
[13:49] <CIA-4> choose-mirror: cjwatson * r611 ubuntu/Mirrors.masterlist: update Mirrors.masterlist to Debian 2.28
[14:07] <maxagaz> hi
[14:09] <maxagaz> I get an error when installing ubuntu via pxe, apt-mirror-setup failed for unknown reasons
[14:09] <cjwatson> will need to see the full syslog
[14:09] <maxagaz> is there a log somewhere ?
[14:10] <cjwatson> go back to the main menu and select "save debug logs"
[14:11] <CIA-4> choose-mirror: cjwatson * r612 ubuntu/debian/changelog: releasing version 2.28ubuntu1
[14:14] <maxagaz> how to run a preseed install in debut mode ?
[14:15] <maxagaz> i need to check which line of the preseed didn't work for my pxe install
[14:15] <cjwatson> doesn't work that way
[14:15] <cjwatson> not really, anyway
[14:16] <cjwatson> it'll be easier if you just show me the syslog :)
[14:16] <cjwatson> that said, you can add this boot parameter to get more verbosity in the logs: DEBCONF_DEBUG=developer
[14:16] <cjwatson> but it takes practice to read the results
[14:17] <maxagaz> cjwatson, are you talking to me ?
[14:18] <cjwatson> maxagaz: yes
[14:20] <maxagaz> cjwatson, where to put the DEBCONF_DEBUG=developer ?
[14:21] <cjwatson> don't worry about that yet
[14:21] <cjwatson> just show me the syslog from your current installation run
[14:24] <maxagaz> cjwatson, there's nothing about it in /var/log/syslog
[14:24] <cjwatson> don't try to interpret it; just show me the whole thing
[14:24] <cjwatson> oh, and show me the preseed file, with any passwords removed but no other changes
[19:59] <DogWater> Is anyone aware of why the Jaunty installer indicates that you need to reboot before it can use a newly created partition?
[20:00] <cjwatson> it only does that if the disk was busy before it started - e.g. you had a mounted partition on that disk
[20:00] <cjwatson> and that's just a constraint imposed by the kernel
[20:04] <DogWater> How could the partition be mounted if it is a brand new machine?
[20:29] <cjwatson> DogWater: "e.g."
[20:30] <cjwatson> DogWater: for a more accurate diagnosis, I'd need to see syslog+partman
[23:31] <CIA-4> partman-auto: cjwatson * r290 ubuntu/ (debian/changelog lib/auto-shared.sh):
[23:31] <CIA-4> partman-auto: Only ensure that there is at least one primary partition after
[23:31] <CIA-4> partman-auto: autopartitioning on partition tables that use extended partitions.