[01:33] <Megaqwerty> Hi, I have a question about the MOTU. I was wondering if you build a package for Ubuntu, do you have to watch the main site for new versions/patches/etc.? That's really the only thing holding me back from contributing, as I don't always have the time to do said actions.
[01:34] <Hobbsee> usually a good idea, yes
[01:34] <Hobbsee> sometimes people file bugs about software that's out of date
[01:34] <Hobbsee> there are also watch files, which let you scan for changes
[01:35] <Megaqwerty> Hobbsee: so, there's really no "Oh, here's a package that hasn't been updated/built yet, I guess I have time to help out..." It's really quite a commitment when you work on a project, right?
[01:36] <Megaqwerty> s/project/package/
[01:36] <Hobbsee> Megaqwerty: you do not need to work on "new packages" - you're quite free to do bug fixes, etc.
[01:36] <Hobbsee> Megaqwerty: or work in teams, which keep packages up to date
[01:37] <Megaqwerty> Hobbsee: so, are you saying joining a team is more like: A) Report on needed update posted B) Whomever has the time updates it ?
[01:38] <Hobbsee> Megaqwerty: yeah.  i don't do it like that - i just fix bugs, etc usually
[01:38] <persia> Megaqwerty: Well, joining a team is more like coordinating between team members about things to be done and who has time to do it.  Not just waiting for someone to have time.
[01:38] <Hobbsee> projects often have rss feeds, etc, so the info comes to you, too
[01:39] <Megaqwerty> persia: could you elaborate on how that works?
[01:41] <persia> Megaqwerty: Teams generally have mailing lists, dedicated IRC channels, and sometimes wiki pages that indicate who is working on what, and the currrent progress.  It's a little different for each team.  If your interests match a team, you'd do best to contact that team and ask "How can I help?".  If you just want to help out, chasing bugs is probably easiest.
[01:41] <Megaqwerty> persia: so, are the teams listed on the MOTU site?
[01:43] <persia> Megaqwerty: Some of them.  There are also teams that don't restrict themselves to universe or main, and work on a subset of software, like the mozilla team or the games team or the edubuntu team.
[01:43] <persia> Megaqwerty: A better question perhaps is, what interests you?
[01:46] <Megaqwerty> persia: well, anything really. I currently work on Getdeb packages which are generally pretty broad in spectrum. I like the environment where they have a bugtracker which lists what packages need to be updated or created, and I just pick whatever I feel I have the time to do. But I wanted to start contributing directly to ubuntu, which is what brought me here. So, I'm really up for anything that's not too difficult (anything with a makef
[01:47] <Megaqwerty> *Some form of a makefile
[01:48] <persia> Megaqwerty: If you're coming from getdeb, I'd like to encourage you to try to tackle part of http://qa.ubuntuwire.com/uehs/no_watch.php or http://qa.ubuntuwire.com/uehs/no_updated.php.  The first list is packages not maintained in Debian where we don't know the upstream status, and the second list is packages not maintained in Debian where we ship an older version.
[01:49] <persia> Getting these updated would be a great step towards having the most current software.  Most are in universe, so you'd be working with MOTU (although some belong to special teams: check the Maintainer entry in the source package).
[01:51] <Megaqwerty> persia: Thanks! let me look at the pages and see if I have any further questions about how this all works. :)
[01:52] <Megaqwerty> persia: Okay, so say I wanted to work on "anyevent" I would go to the launchpad page, build the latest version...then what?
[01:53] <persia> Megaqwerty: First, check to see if there is already an update bug, which would be tracking status.  If there isn't, or if it is unassigned, open one and assign yourself.  Then, update the package from CPAN to work with hardy, and create an interdiff for sponsor review.  You probably want to review https://wiki.ubuntu.com/MOTU/Contributing for hints and process.
[01:54] <Megaqwerty> persia: is an "interdiff" the same as a .diff.gz?
[01:55] <persia> Megaqwerty: No, it's the differences between two diff.gz files.  See https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[01:56] <Megaqwerty> persia: alright, cool. the name makes more sense now ;)
[01:57] <persia> Megaqwerty: We use interdiff to communicate packaging changes when there is a new upstream version, as debdiff mixes the packaging and upstream changes, and is confusing.  With an interdiff, the sponsors can construct the new diff.gz from the old diff.gz, and look at the specific changes when reviewing the work.
[01:59] <Megaqwerty> persia: okay, so how do I go about giving this diff to a sponsor? Attach it to the "new version" bug report?
[02:00] <effie_jayx> persia, I received the upload email... thanks
[02:00] <persia> Megaqwerty: First, test to make sure you can reconstruct your diff, then subscribe the sponsors queue.  See https://wiki.ubuntu.com/MOTU/Contributing#head-b205c74e27fe15e79e10c9e7f14d3cdfb359d81d for details.
[02:00] <persia> effie_jayx: There's another missing manpage in that package, but it takes so long to bootstrap, I'm not sure I want to build it again :)
[02:01] <effie_jayx> persia,  I also received some bug reports for builds... 4 different emails stating a build error...
[02:01] <effie_jayx> I don't quite understand those emails
[02:01] <effie_jayx> persia,  it takes a while to build ... yes...
[02:02] <persia> effie_jayx: The updated package failed to build when uploaded.  There seems to be a persistent problem right now.  If you need help understanding the mail, best to ask here (although I'm not the best person to answer).
[02:02] <effie_jayx> persia, State: Chroot problem
[02:02] <effie_jayx> I checked the log
[02:03] <effie_jayx> E: Internal Error, Could not perform immediate configuration (2) on libstdc++6
[02:03] <effie_jayx> it happens on 4 architectures...
[02:04] <Hobbsee> effie_jayx: it's broken
[02:05] <effie_jayx> Hobbsee,  the package?
[02:06] <effie_jayx> Hobbsee,  it builds ok here..
[02:06] <effie_jayx> should I add a build log?
[02:06] <Hobbsee> effie_jayx: no, the buildds are broken
[02:07] <effie_jayx> Hobbsee,  :S
[02:28] <Megaqwerty> persia: okay, I have more of a packaging question for you: Is use of cdbs encouraged, discouraged, or neither?
[02:29] <persia> Megaqwerty: neither really.  I like it, but that's me.  Best practice for an update is to try to keep the current packaging, except where you need to fix bugs.
[02:30] <Megaqwerty> persia: Cool. I wasn't planning on changing the rules, but from all of the package sources I've downloaded from Ubuntu, I could never really tell.
[02:31] <persia> Megaqwerty: For Debian packages, the tools used are chosen by the maintainer, and Ubuntu generally leaves those alone.  For new-in-Ubuntu packages, the tools are chosen by the initial packager, and others usually leave these alone.
[02:32] <Megaqwerty> persia: Got it.
[03:18] <cdm10> I'm new to Bash scripting and Debian packaging, and I need to know how to run some Python within my postinst and prerm scripts.
[03:20] <imbrandon> cdm10: the short anwser is "dont" postinst scripts are shell scripts, keep them that way :)
[03:20] <cdm10> imbrandon: alright, so I have to learn some shell-scripting... darn.
[03:20] <imbrandon> :)
[03:20] <cdm10> imbrandon: Anyway, I don't really understand the structure of it. I have one created by dh_make.
[03:22] <imbrandon> dh_make is only a template and often dosent fit what ou need it for, postinst is just a script that gets called after installation as the name implys
[03:22] <cdm10> imbrandon: alright... so, how might it be called, and how do I need to handle the different parameters that might be passed to it?
[03:22] <cdm10> I just want to add something to anacron when it installs, and remove it when it's removed.
[03:22] <nxvl> hey
[03:23] <nxvl> imbrandon: can u do me a favor?
[03:23] <imbrandon> are you using cdbs ?
[03:23] <imbrandon> heya nxvl
[03:23] <cdm10> imbrandon: yeah
[03:23] <imbrandon> sure
[03:23] <nxvl> imbrandon: please install tuxpaint-config and check if it apears on the menu
[03:23] <nxvl> imbrandon: you are using KDE, right?
[03:23] <imbrandon> nxvl: sure give me a moment
[03:23] <nxvl> imbrandon: thnx
[03:23] <imbrandon> not right now i'm not
[03:23] <nxvl> oh
[03:23] <imbrandon> i'm in gnome
[03:23] <nxvl> i need to check it on kde
[03:23] <nxvl> nevermind
[03:23] <imbrandon> actualy right now i'm at console but thats totaly seperate
[03:24] <imbrandon> :)
[03:24] <cdm10> imbrandon: yes to the cdbs question :)
[03:24] <nxvl> yep
[03:24] <nxvl> i'm working on bug #173294
[03:24] <ubotu> Launchpad bug 173294 in tuxpaint-config "There are no easy way to change tuxpaint configuration" [Low,Confirmed] https://launchpad.net/bugs/173294
[03:24] <nxvl> and as i have seen it installs the .desktop for kde
[03:24] <nxvl> and not for gnome
[03:24] <nxvl> so i wanted to make sure
[03:25] <imbrandon> cdm10: sure then make a anacron file and install it via the .install file in /etc/cron.daily or similar
[03:25] <imbrandon> is normaly how that is handled
[03:25] <minghua> imbrandon: Wrong advice.  I believe python is (partially) allowed in maintainer scripts in Ubuntu.  Perl is definitely allowed.
[03:25] <cdm10> imbrandon: Ah, so I don't have to muck around in anacrontab. That's good.
[03:26] <imbrandon> minghua: hrm strange , never seen it in practice
[03:26] <cdm10> imbrandon: I'm not sure what you mean by the .install file, and I also need some documentation as to how to create this file... could you help me with that?
[03:26] <imbrandon> cdm10: debian/<package>.install , it should be explained int he packing guide
[03:27] <imbrandon> lemme find a refrence
[03:27] <cdm10> imbrandon: thanks
[03:29] <cdm10> imbrandon: hmm, I don't see *.install in there. Would that be generated by dh_make? And, why can't I just add that cron file thingy to the files that my setup.py installs? (I'm using distutils)
[03:29] <cdm10> Do I have to create the .install file?
[03:29] <nxvl> imbrandon: to install a .desktop file it's only needed to dh_desktop on install at rules, doesn't it?
[03:29] <imbrandon> nxvl: yea
[03:29] <persia> install files are documented in man dh_install.
[03:30] <nxvl> is there a problem if the upstream install a desktop file and i add anotherone on debian/ ?
[03:30] <persia> maintainer scripts are demystified from http://women.debian.org/wiki/English/MaintainerScripts
[03:30] <nxvl> (the upstream one seems to work only for kde)
[03:30] <minghua> imbrandon: sudo's postinst, for example.
[03:30] <persia> nxvl: Don't do that.  If upstream puts it in the wrong place, move it.  Upstream .desktop files are better.
[03:31] <nxvl> persia: what i need to edit is the makefile, thats the way to do it?
[03:31] <minghua> imbrandon: The postinsts of linux-image-* in Debian are perl scripts too, not sure about Ubuntu though.
[03:31] <cdm10> persia: Is this file actually called <nameofpackage>.install, or is it called package.install?
[03:31] <imbrandon> nxvl: patch it
[03:31] <persia> nxvl: Yes.  patch the Makefile.
[03:31] <imbrandon> then send patch upstreams
[03:31] <persia> cdm10: Either debian/install or debian/<nameofpackage>.install, depending.  See the man page.
[03:31] <Amaranth> really? patch the Makefile?
[03:31]  * minghua also found bash's preinst is a ELF binary -- which makes sense.
[03:31] <Amaranth> I would just add a bit in rules to move the file
[03:32] <imbrandon> Amaranth: either way is better than making a new one
[03:32] <cdm10> persia: alright. So, when I dpkg_buildpackage it, it should put that file in the right place on the filestructure of the .deb?
[03:32] <nxvl> the most strange think is that it has some gnome lines commented
[03:32] <RenatoSilva>  Hi people, I'm building my 1st .DEB package, but I only know how to copy files to the system (lot of simplistic tutorials). To start, I want to know just how to put an icon of my application on the system menu. How???? Is this the wrong channel? Please let me know.
[03:32] <persia> Amaranth: That works too.  I just don't like mv in debian/rules, as it often causes the fails-to-build-twice-in-a-row bug.
[03:32] <Amaranth> eh, why does it need to build twice in a row? :P
[03:32] <persia> RenatoSilva: You need a .desktop file.
[03:32] <cdm10> RenatoSilva: You need to create a .desktop file and put it into the /usr/share/applications/ directory.
[03:32] <persia> Amaranth: To prove that debian/rules clean really does.
[03:33] <cdm10> RenatoSilva: You could look at other .desktop files as an example.
[03:33] <imbrandon> cdm10: that file tells where it to put the other files in the stuc , you really should read the package guide
[03:33] <cdm10> imbrandon: where would I find that? A google gives me this: http://www.debian.org/doc/maint-guide/
[03:33] <imbrandon> !packageguide
[03:33] <ubotu> packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[03:34] <cdm10> imbrandon: ah, thanks
[03:36] <RenatoSilva> cdm10: may I text-edit them? I'm taking a look right now....
[03:37] <cdm10> RenatoSilva: Nautilus is weird about .desktop files, you may have to drag them into gedit or run some editor on them.
[03:38] <RenatoSilva> cdm10: ok
[03:41] <cdm10> When creating a script for /usr/bin for a python app, is it better to have the script be a python script that imports and runs your application, or to have it be a shellscript that just executes your python script+
[03:41] <cdm10> ?
[03:42] <persia> cdm10: import and run
[03:42] <cdm10> persia: alright... just asking 'cause I noticed that system-config-printer just execs it.
[03:42] <persia> cdm10: With a shell script?
[03:43] <cdm10> persia: yep.
[03:43] <persia> Odd.  Most things I see are executable python scripts in /usr/bin/
[03:44] <RenatoSilva> cdm10: how to make this .desktop to appear somehwere?
[03:45] <cdm10> RenatoSilva: Not entirely sure, I just looked at other ones and followed their lead...
[03:46] <imbrandon> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn -I.bzr"
[03:46] <imbrandon> err
[03:47] <persia> .desktop entry spec is at http://standards.freedesktop.org/desktop-entry-spec/latest/, and the desktop menu spec (where things end up) is at http://standards.freedesktop.org/menu-spec/latest/
[03:47] <RenatoSilva> cdm10:  oh true!
[03:47] <RenatoSilva> cdm10: sorry
[03:47] <cdm10> persia: I'm wondering if there are some conventions for .desktop files specific to Ubuntu/Gnome.
[03:48] <persia> cdm10: There are a couple things used by the desktop team to hide some applications by default, etc.  For universe packages, we try to follow the standards, and push to Debian and upstream.  The advantage of getting them upstream is that otherwise they don't get translated.
[03:49] <RenatoSilva> I'm intending to put source and bin and extras altogether in a single folder, like a win application. In this way, what should be a good place to put the application base directory? /usr/local/myapp?
[03:49] <cdm10> persia: ok... does that spec have a list of the categories that can be used?
[03:50] <persia> RenatoSilva: You don't want to do that.  Please put executables in /usr/bin, architecture specific stuff in /usr/lib/<package>, and other stuff in /usr/share/<package>?
[03:50] <persia> cdm10: http://standards.freedesktop.org/menu-spec/latest/apa.html
[03:50] <cdm10> persia: thanks
[03:50]  * persia suggests reading the whole spec, and not just that page
[03:52] <RenatoSilva> persia: thank you, I always have seen lib as for libraries and share for shared files
[03:52] <RenatoSilva> persia: the executable is a single jar, put it directly on bin or must have a script calling java ?
[03:52] <persia> RenatoSilva: You may be interested in http://www.pathname.com/fhs/pub/fhs-2.3.html
[03:53] <persia> RenatoSilva: I'm the wrong person to ask about Java.  Best to ask questions generally of the channel.
[03:54] <RenatoSilva> ok
[03:54] <RenatoSilva> the executable is a single jar, put it directly on bin or must have a script calling java ?
[03:55] <imbrandon> RenatoSilva: looks like frostwire ( a java app ) uses a script, but i'm no java expert either and thats only one example and i dunno if its the best one
[03:55] <cdm10> What's the preferred mechanism for having an app run as root? Should I put #! /usr/bin/gksudo /usr/bin/env python into my launch script in /usr/bin? It seems sorta ugly...
[03:56] <Amaranth> cdm10: No the .desktop should call your program with gksudo
[03:56] <imbrandon> cdm10: have the desktop file use it
[03:56] <persia> cdm10: Please don't use #!/usr/bin/env python.  #!/usr/bin/python is much preferred.
[03:56] <cdm10> persia: alright, I'll fix that
[03:56] <persia> Amaranth: That won't work for KDE :(
[03:57] <cdm10> What worries me is having it work in both KDE and Gnome...
[03:57] <Amaranth> persia: Install two .desktop files
[03:57] <persia> Amaranth: Ugly, and hard to push upstream.
[03:58] <cdm10> How do I have it run the appropriate thing? (gksudo|kdesu)
[03:58] <persia> The menu package provides a `su-to-root` function, but menu isn't in the default Ubuntu install.  It's also possible to have a script that detects the right function, and calls that.  The better solution is to make the app not require root.
[03:59] <cdm10> persia: If I do put gksu/gksudo in the .desktop file, should I depend on it?
[04:00] <imbrandon> yes
[04:00] <cdm10> ok.
[04:00] <persia> cdm10: You could, but it would annoy KDE users.
[04:00] <imbrandon> persia: sometimes thats unavoidable, if the app is gtk youir going to anyhow
[04:00] <cdm10> Well, it's a GTK app... which would probably annoy them as well.
[04:00] <persia> imbrandon: True.
[04:01] <cdm10> This may be a bit offtopic, but it could save me from having to run as root.
[04:01] <cdm10> Are there user-specific anacrons, like with cron?
[04:01] <imbrandon> sure
[04:02] <Amaranth> http://f8d.org/?c=236
[04:02] <imbrandon> both in the main crontab and user crontabs can both run jobs as other users
[04:03] <imbrandon> m h dom mon dow user  command
[04:03] <cdm10> Actually, I'd rather have my app run as root... so, is there any best way to do this?
[04:03] <cdm10> depend on gksu, use it in the .desktop, NotShowIn=KDE?
[04:03] <imbrandon> one question, gui app on a cron ? sounds bad
[04:03] <cdm10> imbrandon: no, the gui part doesn't go into cron.
[04:03] <persia> cdm10: Can you not do something with capabilities?  Apps running as root are not ideal.
[04:04] <imbrandon> cdm10: dont use the NotShowIn , it will pull aditional deps in kde but no reason to disallow it
[04:04] <cdm10> imbrandon: alright
[04:04] <cdm10> persia: It's a backup application, and I'd like it to be able to run when no one's logged in, and I'd also like to have something running in anacron... and I'm not sure how to have anacron run something every day as each user.
[04:06] <persia> cdm10: Right.  Split the app into the portion that does backup and the portion that does configuration.  Have the backup run as root (or a backup user with capabilities) in anacron, configured by the postinst.  Grant a special group write access to the configuration file, and have the tool edit the file.
[04:07] <cdm10> persia: This is getting way more complex than I had planned :) but it sounds like the right way to do it.
[04:08] <cdm10> persia: Actually, I don't like that idea... because the user will be able to set the backup target, and if it's running as root, that's a great way to let normal users change stuff that should only be accessible by root... I could drastically change the app so that this wouldn't happen, but that's not really an option at this point.
[04:08] <persia> cdm10: As an added benefit, the .desktop file doesn't need to give root to the GUI configuration tool :)
[04:11] <cdm10> persia: but what about the problem of the user being able to set anything as the backup target?
[04:12] <persia> cdm10: Do you mean the security concern that one user could back up another user's files?  That's the reason one has to be a member of the backup group to be able to modify the configuration file.  Those users would be trusted.
[04:13] <cdm10> persia: No, one user could set any directory to be the target of the backup.
[04:13] <persia> cdm10: The worry of overwriting files then?  Same protection: trusted group.
[04:14] <cdm10> persia: I sorta wanted to make something that someone could install and have it Just Work without having to mess around with groups.
[04:14] <cdm10> persia: So, having it run as root could be a good idea... 'cause there's already a set of trusted users in place that can run it.
[04:15] <imbrandon> system administrators and root users dont always ==
[04:15] <persia> cdm10: Then just use one of the already trusted groups.  I forget whether adm or admin is default, but those seem reasonable.  In the default case, the installing user would be the trusted user.  In special cases, the administrators would modify the groups.
[04:15] <imbrandon> admin is default
[04:16] <persia> imbrandon: Very true, but they are likely the same for the standard use case, no?
[04:16] <cdm10> persia: So, that means users won't have to sudo-authenticate each time?
[04:16] <imbrandon> persia: mostly yea
[04:16] <persia> cdm10: Right.  The configuration file would be group-writable, so the backup admin (who would belong to that group) could edit the file.  Others would get a permission denied error (be sure to trap this in your code, and present a nice message).
[04:17] <cdm10> persia: Isn't it a better idea to have them sudo-authenticate, so they know that they're doing something that could potentially mess up their system?
[04:18] <cdm10> persia: I mean, someone could set some important folder as their backup target... rdiff-backup wouldn't prevent that, I don't think.
[04:18] <persia> cdm10: If you like.  I just don't like sudo for GUIs because of the potential for a bug in the GUI to crash the system.
[04:19] <cdm10> persia: hmm, I'll think about how to do this.
[04:19] <cdm10> Programming is one thing, but packaging... that's a minefield.
[04:19] <cdm10> It's confused me more than anything else in the process :)
[04:20] <persia> cdm10: The packaging can be simple, but it tends to expose lots of issues with the underlying code, which can make it very complex indeed :)
[04:20] <cdm10> persia: yeah...
[04:23] <cdm10> persia: So, if I were to do this groups thing... I'd use the admin group, which is the same as the group with sudo access (by default, in Ubuntu), right?
[04:23] <cdm10> persia: and I'd have to create the config file in the postinst so I could set the group ownership.
[04:23] <persia> cdm10: That'd be my quick & dirty suggestion.  There are other ways to do it as well.
[04:24] <persia> cdm10: You can push the config file normally, and use the postinst to reset ownership & permissions.
[04:24] <cdm10> persia: ok
[04:25] <cdm10> persia: I think I'll wimp out and just have it all run as root, for the time being... it's a work in progress, so I'll probably change it to a better way in the future.
[04:26] <cdm10> persia: Where can I find documentation on how to create a crontab file to put in cron.daily (which I'm told will be executed automatically by anacron)
[04:27]  * persia suspects the answer is in man dh_installcron, and suggests reading the debhelper man pages more generally, and asking questions generally of the channel.
[04:28] <cdm10> persia: sorry, I thought you had said something about the cron thing before, which is why I asked you... you're right, i'm bad at reading documentation, and should get better instead of annoying people on IRC :)
[04:29] <imbrandon> cdm10: apt-mirror uses dh_installcron you can look at it for a simple example of what your wanting
[04:29] <imbrandon> its pretty simplistic use of it
[04:29] <imbrandon> but i do recomend reading the doc stil
[04:30] <imbrandon> still*
[04:30] <cdm10> imbrandon: thanks
[04:31] <imbrandon> the quick and dirty is use dh_installcron in your rules ( or cdbs ) and make a debian/cron.d file with the correct info ( this is but just one way to accomplish this )
[04:31] <nxvl> imbrandon: are you using hardy or gutsy?
[04:32] <imbrandon> nxvl: gutsy with hardy and sid chroot(s)
[04:32] <imbrandon> i'll likely upgrade to hardy mid-jan
[04:32] <nxvl> imbrandon: i need to test the hardy menu entry, is there any way to check it with chroot?
[04:32] <cdm10> imbrandon: so, including the proper cdbs thingy will let me just stick a cron.d file into debian/ ? ok. Is there something like that for .desktop files? Right now, my setup.py file handles those.
[04:33] <nxvl> i have a hardy VM at work, but at home i can run one, my PC crashes if i try :P
[04:33] <imbrandon> if you use the debhelper.mk via cdbs yes just create a debian/cron.d ( please read on it though )
[04:33] <persia> cdm10: No, and it's a bug, but you do want to include dh_desktop in case someone fixes it in the future.
[04:34] <cdm10> persia: So, where should I stick my .desktop files? I have them in a data/ directory now.
[04:34] <imbrandon> cdm10: yea there is a dh_* ( debhelper ) script for damn near anything you want, and cdbs makes use of most of those , but its good to know what ones you need/want and what you can overide etc
[04:35] <cdm10> persia: I'd like to keep them in a place where my setup.py can find them, so I can install them from there until they fix the problem...
[04:35] <cdm10> imbrandon: ok, but the desktop one is broken?
[04:36] <imbrandon> correct
[04:36] <nxvl> imbrandon: did you use pbuilder as chroot or another one?
[04:36] <imbrandon> nxvl: generaly pbuilder as chroot, except for sid, i use a real debootstrapd chroot and sbuild both
[04:37] <nxvl> oh! ok
[04:37] <imbrandon> because i sometimes do gui stuff in my sid one so i have lots of other stuff mounted bind
[04:37] <imbrandon> with it
[04:39] <imbrandon> nxvl: depending on how complicted you want to get you cold probably use a nested x server and xhost+ localhost on it, then export DISPLAY=:X in the pbuilder-chroot and use ome gui apps in it
[04:39] <imbrandon> might need to bind mount tmp too not sure
[04:39] <imbrandon> could*
[04:39] <nxvl> imbrandon: i prefer to use VMs :D
[04:40] <imbrandon> nxvl: yea most of the time its far easier to use a vm
[04:40] <nxvl> and since i'm most of the time at work, it's not usual that i make whing at home
[04:40] <nxvl> i only came to my beth
[04:41] <imbrandon> :)
[05:03] <RenatoSilva> cdm10: are ypou still there?
[05:03] <RenatoSilva> and the others
[05:03] <cdm10> RenatoSilva: oh, hi... sorry 'bout that
[05:03] <imbrandon> persia: did you see irclogs.ubuntuwire.com ? december is a few days behind and i'd like to fix a few more things before i add a link to it etc but its generaly useable
[05:04] <imbrandon> err ircstats.uw.c
[05:04] <imbrandon> not logs
[05:04] <RenatoSilva> cdm10: about what?
[05:05] <cdm10> RenatoSilva: never mind
[05:05] <nxvl> finaly i'm happy with the changes :D
[05:05] <persia> imbrandon: I think you're duplicating http://ubuntuircstats.org/ (although your data goes back further).  What is the additional value?
[05:06] <RenatoSilva> cdm10: I want to thank you n everybody very very much coz I just have right now my first .DEB package in life! rs...magic! rsss
[05:06] <nxvl> now i can sleep well
[05:06] <nxvl> :D
[05:06] <imbrandon> persia: its going to be a join effort once worked out
[05:06] <imbrandon> joint*
[05:06] <RenatoSilva> cdm10: I want to share it with you, who wants to see it?
[05:07] <persia> imbrandon: OK.  I like the ubuntuircstats graphs better, but I like the ircstats.uw.c history.  Also, it'd be nice to have consistent naming, so I'm in favour of ircstats.uw.c.
[05:07] <cdm10> RenatoSilva: You should look into getting a PPA
[05:07] <RenatoSilva> cdm10: PPA?
[05:07] <cdm10> RenatoSilva: It's part of Launchpad, it lets you set up your own package repo
[05:08] <imbrandon> persia: yea the problem with the other graphs is its irssi log specific, and the historical data is all eggdrop
[05:08] <imbrandon> but thats all tech, it can be worked arround
[05:08] <persia> imbrandon: That's fine.  Can history usefully be extracted from irclogs.u.c ?
[05:09] <RenatoSilva> cdm10: hosted at Launchpad?
[05:09] <cdm10> RenatoSilva: yeah
[05:09] <imbrandon> after 2 or 3 hours of wgeting and some magling with shell scripts yea :)
[05:09] <nxvl> persia: how was the christmas out there?
[05:09] <RenatoSilva> cdm10: can't believe, very nice!
[05:09] <imbrandon> persia: in other words doable and will be done but takes a bit o work
[05:09] <persia> nxvl: Everyone went to work, and had a productive day.  Most people are frantically cleaning in preparation for next Monday.
[05:09] <imbrandon> all my data came from irclogs.u.c
[05:10] <persia> imbrandon: Understood.  My personal preference is for a reduced set of namespaces and close integration and collaboration with everyone.  Sounds like you're on the right path :)
[05:10] <imbrandon> yup yup :)
[05:11] <persia> imbrandon: Also, I really like the separation of word use frequency and nick reference on the ircstats.uw.c page.  If that could be kept, it would be nice.
[05:11] <nxvl> persia: wats next monday?
[05:11] <persia> nxvl: The 31st of January.
[05:11] <persia> s/January/December/
[05:12] <imbrandon> persia: yup
[05:12] <nxvl> oh right!
[05:14] <nxvl> persia: so there is no christmas spirit on Tokyo?
[05:14] <RenatoSilva> cdm10: I'm logged in on Launchpad. How to find this PPA?
[05:14] <nxvl> imbrandon: in USA there is a lot os christmas spirit or there is also not much?
[05:14] <persia> nxvl: Not especially.  It's not a popular holiday here.  Some people go out on dates.
[05:14] <cdm10> RenatoSilva: google for launchpad ppa, i'm sure you'll find a guide
[05:14] <imbrandon> nxvl: its really commercialy popular here
[05:15] <nxvl> imbrandon: same here
[05:15] <nxvl> imbrandon: but people say that it's a family holiday
[05:15] <imbrandon> RenatoSilva: http://www.google.com/url?sa=t&ct=res&cd=1&url=https%3A%2F%2Fhelp.launchpad.net%2FPPAQuickStart&ei=dONxR5n9FKHWeczmiTM&usg=AFQjCNFK9uNfZO57MR7ZCYjmToRT7Fy69Q&sig2=yHmN7DuTrz_tPm8rtBFIlg
[05:15] <imbrandon> err
[05:15] <imbrandon> https://help.launchpad.net/PPAQuickStart
[05:15] <imbrandon> there ya go
[05:16] <imbrandon> sorry bout the long paste
[05:17] <nxvl> RenatoSilva: also you can click on "PPA Archive" on the left and the click on help, top left
[05:18] <RenatoSilva> imbrandon: thank u
[05:19] <RenatoSilva> uouah, I have to become an Ubuntero rs
[05:20] <imbrandon> thats easy, just agree and sign the CoC
[05:20] <imbrandon> then upload it to LP
[05:20] <RenatoSilva> it seems theny get a src pkg and build there, I can't send a binary pkg ...
[05:20] <Hobbsee> ppa is broken currently
[05:20] <Hobbsee> i think
[05:21] <cdm10> RenatoSilva: yeah, so your build-depends have to be right
[05:21] <nxvl> i don't use PPA, and i haven't use it never
[05:21] <RenatoSilva> imbrandon: they accept binary pkgs?
[05:21] <imbrandon> RenatoSilva: correct, then it will build the binary from the source for i386 and x86_64
[05:21] <persia> RenatoSilva: Why would anyone want a binary package?
[05:21] <cdm10> RenatoSilva: they'll make a binary package for you on the server
[05:21] <imbrandon> Hobbsee: likely but it will be fixed eventualy* :)
[05:22] <RenatoSilva> persia: my source is Java, how they will know how to compile it?
[05:22] <Hobbsee> imbrandon: in some days, yes
[05:22] <cdm10> RenatoSilva: that's what your rules file is for...
[05:22] <persia> RenatoSilva: You will provide an automated build system and call it with debian/rules.
[05:23] <RenatoSilva> persia: but to build the app it must have installed a Java 6 compiler
[05:23] <cdm10> RenatoSilva: you need to put that in your build-depends
[05:23] <nxvl> RenatoSilva: what bug are you working at?
[05:23] <cdm10> and it'll install it before it attempts to compile it.
[05:23] <persia> RenatoSilva: Yes.  That's what the build-depends line in debian/control does.
[05:23] <imbrandon> RenatoSilva: sure then build-depends on IcedTea or gcj
[05:24] <RenatoSilva> cdm10: build-depends..hum... cool
[05:24]  * imbrandon goes back to uploading christmass pictures while i wait for libvisual to compile
[05:24] <imbrandon> Hobbsee: have a good christmass ?
[05:24] <RenatoSilva> cdm10: install before compiling??
[05:24] <Hobbsee> imbrandon: yeah :
[05:24] <nxvl> imbrandon: flickr?
[05:24] <Hobbsee> * :)
[05:24] <RenatoSilva> nxvl: bug?
[05:24] <cdm10> RenatoSilva: hmm?
[05:25] <imbrandon> nxvl: yea i store most all my pictures on flickr
[05:25]  * nxvl adds imbrandon as friend
[05:25] <cdm10> RenatoSilva: I'm not the best person to ask, actually. All I know is that you make a rules script to compile the package, and put the stuff you need in order to compile it in the build-depends.
[05:25] <RenatoSilva> imbrandon: I guess I'd build-depend from sun-java6-jdk
[05:25] <imbrandon> RenatoSilva: thats not possible on our buildd's
[05:26] <imbrandon> because of the lic screen
[05:26] <imbrandon> thus IcedTea or gcj
[05:26] <persia> imbrandon: Are you sure?  I thought there was some preseeding in place.
[05:26] <imbrandon> persia: ahh well if they fixed it reciently yes
[05:26]  * persia thinks it was only a few days ago
[05:26] <imbrandon> but not that i'm aware but i dont follow java closely
[05:26] <imbrandon> ahh very very likely then
[05:27] <imbrandon> RenatoSilva: then it looks like you can but you'll likely have to jump through a hoop or two
[05:27] <imbrandon> sorry i cant be more specific than that, its my extent of java experince
[05:27] <RenatoSilva> imbrandon: java is free software now
[05:27] <imbrandon> RenatoSilva: sure, well in a sense , but yea i'm aware
[05:28] <imbrandon> RenatoSilva: i was more specificly talking aobut the debconf question agreeing to the doj?? thing when installing on the buildds
[05:28] <imbrandon> but persia sugests thats likely fixed now
[05:29] <nxvl> RenatoSilva: aren't you working on a bug? whats your package? a debianization?
[05:29] <RenatoSilva> imbrandon: I guess many apps just can't leave original Sun Java 6 because the other compilers just don't do all the things Sun's one (version 6) does
[05:30] <imbrandon> RenatoSilva: i totaly understand the delima, i just dident know there was a solution untill just now
[05:30] <nxvl> i prefer not to use java at all :D
[05:30] <persia> RenatoSilva: Yes, but Sun Java 6 isn't free.  Java 7 will be free, and there are free Javas around.
[05:30] <imbrandon> nxvl: btw, fwiw my pics ( except the ones i'm currently uploading arent there yet ) are at http://www.flickr.com/photos/imbrandon/sets
[05:31] <imbrandon> since you asked :)
[05:31] <RenatoSilva> nxvl: my packange is just my 1st package rs.. I took a Java calculator I've wrote and packaged it into a .DEB right now rs...and the guys are telling me now about Lauchpad's personal repository rs
[05:31] <nxvl> imbrandon: i was looking at them :P
[05:32] <nxvl> RenatoSilva: oh ok, so there is a debianisation :p
[05:32] <imbrandon> Hobbsee: btw, got a sec? help me fill in the missing names of these KDE people, i forgot who some of them were :) lol /me is bad
[05:32] <imbrandon> http://www.flickr.com/photos/imbrandon/2092209213/in/set-72157603397616729/
[05:32] <RenatoSilva> persia: hum, why? source not completely opened still?
[05:33] <persia> RenatoSilva: Source is open, but license isn't DFSG-free.
[05:33] <Hobbsee> imbrandon: hm.  i think that's johnflux on the far left.
[05:33] <Hobbsee> imbrandon:  i don' tknow the other one
[05:33] <RenatoSilva> nxvl: what's a debianisation? someone learning hwo to build a .deb? rsss...
[05:34] <Hobbsee> imbrandon: don't quote me on that, though
[05:34] <imbrandon> ahh right yup john
[05:34] <imbrandon> okies
[05:34]  * Hobbsee was not at mtv
[05:34] <Hobbsee> and those two were not in sevilla :)
[05:34] <RenatoSilva> persia: DFSG?
[05:34] <nxvl> RenatoSilva: not, it's making a .deb package from a source for first time
[05:34] <imbrandon> yea i know, but you likely would have met the kde peeples :)
[05:34] <imbrandon> aleaste some of them :)
[05:34] <persia> RenatoSilva: http://www.debian.org/social_contract#guidelines
[05:35] <RenatoSilva> nxvl: so ...now I'm a deb packager
[05:35] <RenatoSilva> nxvl: rss
[05:35] <imbrandon> Hobbsee: yea i know its john , i rember now, he was my room mate at UDS MTV
[05:35] <nxvl> RenatoSilva: stuff like
[05:35] <LucidFox> When preparing a new upstream release, should I strive for prettification or minimal divergence if an older version is in Debian?
[05:35] <imbrandon> minimal divergence, then perfecion via a patch sent upstream
[05:35] <imbrandon> ( to debian )
[05:36] <imbrandon> so both :)
[05:36] <Amaranth> imbrandon: you were at mtv uds?
[05:36] <Amaranth> I don't remember seeing you there :P
[05:36] <RenatoSilva> nxvl: actually my interest on learning this is that every time a new version of Ubuntu comes, I have to follow some manual steps to get my modem working...
[05:36] <imbrandon> Amaranth: yea , i sat at your table talking beryl stuff most of the time, infact i made most of the beryl package while at uds
[05:36] <nxvl> are the modems stiff alive?
[05:36] <Amaranth> oh yeah
[05:36] <imbrandon> heh
[05:37] <Amaranth> didn't click as the same person
[05:37] <nxvl> i thougt there where extinct
[05:37] <imbrandon> that was me :)
[05:37] <Hobbsee> imbrandon: heh.  then surely you should know that :)
[05:37] <nxvl> s/stiff/still/g
[05:37] <RenatoSilva> nxvl: so I was thinking about packaging the process into a .deb, it'd be simply a driver package for Lucent/Agere which you install and get the winmodem working out of the box...
[05:37] <imbrandon> Hobbsee: yea i just had forgotten, it had been a whole
[05:37] <imbrandon> while*
[05:37] <LucidFox> If dropping dpatches, should I leave them in debian/patches and only remove from 00list, or delete them?
[05:38] <Amaranth> back then the only thing i was doing was trying to help them run the project properly :P
[05:38] <nxvl> RenatoSilva: sis you reinstall the whole system or just upgrade?
[05:38] <imbrandon> LucidFox: either works , i generaly leave them if I'm not the maintainer
[05:38] <nxvl> s/sis/did
[05:38] <LucidFox> ok
[05:38] <Amaranth> and I was actually sent there to try to persuade people to reject the whole idea
[05:38] <imbrandon> Amaranth: yup, i rember :)
[05:39] <RenatoSilva> nxvl: I just can't upgrade
[05:39] <imbrandon> oh i was really vocal against it if you rember, but i also made the packages too so it was a catch22
[05:39] <Amaranth> hehe
[05:39] <Amaranth> I'm a sucker for bling
[05:39] <nxvl> LucidFox: it's better to left the files and only delete the entrys from 00list, so if someone want that patch for somereasons it's still there
[05:39] <imbrandon> i think me and keybuk were the loudest for "not by default"
[05:39] <nxvl> RenatoSilva: why?
[05:39] <Amaranth> We had our own RDF thing going
[05:40] <chillywilly> what method does the desktop use to automatically mount removable media?
[05:40] <imbrandon> we litterly grilled Quinn for 2 hours one day
[05:40] <imbrandon> heh
[05:40] <Amaranth> right, you were asking the wrong person, should have talked to onestone :P
[05:40] <chillywilly> is it a udev thing?
[05:40] <persia> chillywilly: udev + hal + dbus + dbus-listener-of-choice
[05:40] <imbrandon> chillywilly: depends on the desktop, gnome and kde do it diffrently
[05:41] <Amaranth> chillywilly: it's a hal thing
[05:41] <nxvl> well, time to sleep
[05:41] <nxvl> read you tomorrow
[05:41] <chillywilly> ok, gnome
[05:41] <imbrandon> Amaranth: yea, but at that time Quinn was the "face at uds"
[05:41] <chillywilly> ok
[05:41] <cdm10> So, I'd like to put a crontab file in cron.daily to be run by anacron... do I jsut leave everything as *?
[05:42] <Amaranth> hal says "hey this thing got hooked up" and in gnome gnome-volume-manager says "ok, i'll mount it then"
[05:42] <imbrandon> cdm10: no
[05:42] <Amaranth> then talk over dbus
[05:42] <imbrandon> i dont think so
[05:42] <cdm10> imbrandon: what do I need to do then? The crontab(5) manpage doesn't really help with knowing how to use it with anacron.
[05:43] <imbrandon> hrm honestly i dont know, look at an existing cron.daily is the best awnser
[05:43] <imbrandon> i can come up with
[05:43] <Amaranth> err, they talk
[05:43] <Amaranth> long day :P
[05:43] <cdm10> imbrandon: i looked at the one for apt-mirror, but i'm not sure if it does what i want
[05:43] <persia> cdm10: man anacrontab
[05:43] <imbrandon> apt-mirror uses cron.d not cront.daily
[05:44] <cdm10> persia: I'm not looking to edit the anacrontab, I know how to do that... I was just told that the best way to add something to anacrontab with a package was to put something in cron.daily
[05:44] <cdm10> imbrandon: ah, someone recommended I look at that package.
[05:44] <imbrandon> cdm10: yea i did ( i maintain it and knew it used it )
[05:45] <cdm10> imbrandon: oh, ok.
[05:45] <persia> cdm10: Have you looked at the files currently installed in your local /etc/cron.daily?
[05:45] <imbrandon> but cron.d != cron.daily
[05:45] <cdm10> persia: Damn, that would be a smart idea.
[05:45] <imbrandon> hrm i said that about 5 lines ago
[05:45] <imbrandon> heh
[05:45] <imbrandon> 23:43:07 < imbrandon> hrm honestly i dont know, look at an existing cron.daily is the best awnser
[05:45] <imbrandon> lol
[05:45]  * persia was just repeating imbrandon's previous advice
[05:45] <cdm10> Damn, I feel stupid
[05:46] <imbrandon> heh no worries we're all at that point sometimes
[05:46] <cdm10> wait a sec, what cdbs thingy do I include to install the cron.* stuff?
[05:46] <cdm10> imbrandon: hopefully I can be a useful developer when I get this stuff figured out :)
[05:47] <imbrandon> it will call dh_installcron, so follow `man dh_installcron` instructions
[05:47] <imbrandon> it == cdbs
[05:47] <persia> cdm10: First, look through the dh_ commands to figure out which you want.  Then, look through the /usr/share/cdbs/1/ directory to figure out which to include.
[05:47] <cdm10> persia: alright, I'll do that, and write it down.
[05:51] <RenatoSilva> nxvl: because I'm on a dialed connection and have not the alternative CD :(
[05:53] <RenatoSilva> cdm10: well guys it'd be hard trying PPA now, so I've set the package at this location: http://br.geocities.com/br.renatosilva/jaca/jaca_1.0-20071105_all.deb.zip
[05:53] <RenatoSilva> extract the zip to get the .deb (yahoo denies .deb uploads)
[05:53] <cdm10> RenatoSilva: I'm no expert, so I'll let the others see if it's built properly...
[05:54] <RenatoSilva> cdm10: rs....you can trust, it will not rm-rf your HD rs....
[05:54] <cdm10> RenatoSilva: it's not that I don't trust it... I can look inside it without installing it... but I just won't be of any help in telling you whether it's properly set up.
[05:55] <RenatoSilva> cdm10: anyway you may want to open it and take a look into it to know what will be done exactly....but let me say...it's just an (super power) calculator with an icon on Gnome's menu :D
[05:56] <LucidFox> RenatoSilva> Why don't you upload the source package?
[05:56] <cdm10> RenatoSilva: alright, well, I'm just not that interesting in it right now...
[05:56] <RenatoSilva> LucidFox: upload to IRC? is it possible?
[05:56] <cdm10> damn, i meant interested
[05:57] <LucidFox> no, not to IRC
[05:57] <RenatoSilva> cdm10: I thank you anyway for your tips...:D
[05:57] <cdm10> np
[05:57] <LucidFox> to wherever the deb is
[05:57] <cdm10> Wait, is ppa actually broken?
[05:57] <LucidFox> No...
[05:57] <cdm10> oh, ok
[05:57] <LucidFox> Shouldn't be
[05:58] <cdm10> I was a bit confused with this talk of ppa not working
[05:58] <RenatoSilva> LucidFox: the deb is on mny machine and on the link I've provided, so I don't understando you rs....
[05:58] <RenatoSilva> understand rs
[06:06] <RenatoSilva> it was very nice to learn this, thank you everybody rs...
[06:08] <RenatoSilva> i'm going...bye
[06:24] <imbrandon> my christmas photos uploaded if anyone cares :P http://www.flickr.com/photos/imbrandon/sets/72157603548861205/
[06:26] <cdm10> What categories do I set in my .desktop file for it to appear in the Administration menu?
[06:26] <cdm10> Rather than preferences...
[06:29] <cdm10> Ah, never mind, got it.
[06:29] <imbrandon> System;Settings
[06:29] <imbrandon> ?
[06:29] <cdm10> imbrandon: Yeah, just figured that out. Sorry to spam channel...
[06:29] <cdm10> rather, sorry for spamming the channel
[06:29] <imbrandon> np
[06:35] <cdm10> I don't entirely understand the manpage for dh
[06:35] <cdm10> damn enter key got in the way
[06:35] <cdm10> for dh_install
[06:35] <cdm10> Is each line suppposed to be like...
[06:35] <cdm10> foo.desktop /usr/share/applications/
[06:37] <Hobbsee> cdm10: yes, i think so
[06:37] <cdm10> Hobbsee: alright, i will try that
[06:39] <cdm10> So, if I have /usr/share/cdbs/1/rules/debhelper.mk included in rules, that'll do everything including dh_installcron?
[06:42] <imbrandon> should yes
[06:42]  * persia notes that a .desktop file should only have one (1) Main category, so "System; Settings;" ends up showing twice in a menu, which is not preferred.
[06:43] <cdm10> persia: ok, thanks
[06:43] <cdm10> What's the purpose of the dirs file?
[06:43] <cdm10> Everything seems to work fine without it...
[06:44] <persia> cdm10: To work around broken build systems that don't create the right directories.  Alternately, to force directory creation to support odd dh_install workarounds for non-ideal build systems.
[06:44] <cdm10> persia: alright.
[06:45] <cdm10> Now, is there anything particular I should do with my .desktop file? Right now, my distutils setup.py handles it, but I remember someone saying something about putting it in debian/ for some reason.
[06:47] <imbrandon> other than install it in the correct location, nothing, debhelper.mk should take care of everything else
[06:47] <imbrandon> everything else == calling dh_desktop
[06:47] <cdm10> imbrandon: I read that dh_desktop doesn't handle installing it...
[06:48] <imbrandon> correct, thats why i said install it into the correct location firs
[06:48] <imbrandon> t
[06:48] <cdm10> ok, so it doesn't matter where it is in my initial file structure?
[06:48] <imbrandon> no as long as it ends up in the right place
[06:49] <cdm10> alright, thanks
[06:49] <cdm10> imbrandon: my rules file has debhelper first, then python-distutils.
[06:49] <cdm10> imbrandon: python-distutils is what installs the .desktop...
[06:49] <cdm10> could that cause a problem?
[06:49] <imbrandon> nope, should be good iirc
[06:49] <cdm10> alright
[07:42] <cdm10> In my .desktop file, I have my categories as follows: GTK;Archiving;System
[07:43] <cdm10> but it doesn't show up in System>Administration
[07:43] <persia> cdm10: Does it show up in System Tools?
[07:43] <cdm10> persia: hmm, hold on a minute
[07:44] <persia> I think you want "Settings" to end up in the System or Preferences menus.
[07:45] <cdm10> persia: I want it in System>Administration, not System>Preferences.
[07:45] <cdm10> yeah, it showed up in system tools
[07:45] <cdm10> Do I need both system and settings?
[07:45] <persia> cdm10: Take a look at the existing files that go there, and follow those as examples.  You should only have one Main Category, so System;Settings; is wrong.
[07:46] <cdm10> persia: Here's what I get from redhat-system-config-printer.desktop: GTK;Printing;HardwareSettings;Settings;System;X-Red-Hat-Base;
[07:47] <cdm10> from displayconfig-gtk.desktop: GNOME;GTK;Settings;HardwareSettings;System;
[07:47]  * persia looks at the spec again, convinced that is incorrect
[07:47] <cdm10> Just to triple-check, I looked at users.desktop
[07:47] <cdm10> GNOME;GTK;System;Settings;
[07:48] <persia> Right.  .desktop files with more than one main category are supposed to appear more than once in the menu.
[07:48] <cdm10> persia: strange...
[07:48] <cdm10> I looked at some others, and they're all like tat
[07:48] <cdm10> *that
[07:49] <persia> cdm10: I suspect there's something non-compliant with gnome-menu then.
[07:49] <cdm10> persia: I suppose... should I just go with the Settings;System thing then, since everyone else is doing it?
[07:50] <cdm10> Well, it at least put it in the right place...
[07:51] <persia> cdm10: You could.  I still say it is wrong, but it happens to be how /etc/xdg/menus/settings.menu defines things.
[07:51] <cdm10> persia: alright.
[07:53] <persia> cdm10: Note that this is an Ubuntu-specific workaround.  You likely shouldn't have two main categories in the .desktop file distributed upstream.  I'd suggest the use of a patch system to make that adjustment, rather than having the .desktop file in the orig.tar.gz with that modification.
[07:54] <cdm10> persia: ok... I'll look into that.
[08:09] <cdm10> When packages are upgraded from a repository, are they uninstalled and reinstalled with the newer version?
[08:10] <cdm10> If I am missing files in a newer version that I had in an older version, will they be removed from the system?
[08:22] <persia> cdm10: Normal files, or conffiles?
[08:22] <cdm10> persia: Normal ones, I think...
[08:22] <cdm10> persia: just ones in the data dir
[08:23] <persia> cdm10: dpkg should clean up for that, but the timing is complex.  Best to test.
[08:23] <cdm10> persia: actually, I just realized, it doesn't matter.
[08:23] <cdm10> persia: but I have one other question
[08:23] <cdm10> persia: if I add a dependency, will it just install when the user updates?
[08:24] <persia> cdm10: Depends on how the user does that.  The new package will depend on the new dependency, so most package managers should install it by default.
[08:25] <cdm10> persia: alright, sounds good. Thanks.
[08:27]  * persia notes that idling in the channel is a good way to get questions answered, even before one discovers one needs to know.
[08:58] <warp10> Hi all!
[09:01] <slytherin> is there a major chroot problem somewhere?
[09:02] <slytherin> I mean on some build machine. Because I am seeing many such cases on FTBFS page
[09:02] <persia> slytherin: It certainly appears so.  Given that it's the holiday break week, it may take a bit of time to be resolved.
[09:02] <slytherin> No issues.
[09:49] <LucidFox> Hmm. just got a bunch of chrootwait errors.
[09:51] <persia> LucidFox: libstdc++6 breakage?
[09:54] <LucidFox> yes
[09:57] <persia> LucidFox: Seems like lots of builds are failing from that now.  Should be fixed soon (although many people are on holiday).  I suspect there will be a mass give-back of the affected packages at that time.
[09:58] <persia> Looking at http://qa.ubuntuwire.com/ftbfs/, I'm guessing most of the listed DEPWAIT and CHROOTWAIT builds are waiting for the fix (as these numbers were previously smaller).
[10:10]  * apachelogger_ is wondering how kimwitu-doc manages to build on debian
[10:11] <persia> apachelogger_: It has never autobuilt on Debian.
[10:12] <persia> apachelogger_: The previous was just a note due to Debian upload policies.  For further information see Debian bug #430794
[10:12] <ubotu> Debian bug 430794 in kimwitu-doc "kimwitu-doc - FTBFS: sh: gs: command not found" [Serious,Open] http://bugs.debian.org/430794
[10:13] <apachelogger_> Date: Sat, 14 Jul 2007
[10:13] <apachelogger_> the bug seems to be stuck :(
[10:14] <persia> apachelogger_: Yep.  It's marked patch, and RC, but I'm guessing nobody feels like an NMU (maybe there aren't a lot of rdepends).  Easy fix though :)
[10:17] <StevenK> Who's the maintainer?
[10:17] <persia> StevenK: Michael Piefel
[10:19] <StevenK> Hrm. Don't know about him
[10:19] <persia> As in, whether NMUs are appreciated?
[10:20] <StevenK> Or if he's reponsive to bug reports and such
[10:22] <persia> Hobbsee: Does that belong in -devel as well?
[10:22] <Hobbsee> persia: probably
[10:22]  * Hobbsee wonders why she feels like she's about to black out.
[10:22] <Hobbsee> probably means i shouldn't be on irc or something
[10:23]  * apachelogger_ votes for more sleep
[10:24] <persia> Food is good too.
[10:24] <apachelogger_> meh, well done, now I'm hungry -.-
[10:36]  * Hobbsee had food :P
[10:37] <apachelogger_> bah
[10:37]  * apachelogger_ has 3 pbuilders on 3 machines running right now :P
[10:44]  * geser has now his breakfast
[11:40] <Hobbsee> geser: please check for rdepensd, and deal with them too
[11:40] <Hobbsee> (if there are any)
[11:41] <Hobbsee> hm, shouldn't be any
[11:54] <geser> Hobbsee: which bug/package?
[11:55] <Hobbsee> geser: liboh...one of them i did.
[11:55] <Hobbsee> libexiv
[11:55] <Hobbsee> er, libexif
[11:58] <geser> Hobbsee: I might be missing something but how can a patch influence other packages that it's necessary to check the rdepends?
[12:00] <Hobbsee> geser: i misread it on the bug.  thought it was a new upstream, maybe with an api change unlisted.  or something
[12:00] <Hobbsee> my brain is clearly screwed tonight.
[12:02] <geser> for hardy it's only the new security patch (0.6.16-2 -> 0.6.16-2.1)
[12:03] <Hobbsee> yeah
[12:03]  * Hobbsee drools
[12:03]  * Hobbsee now has white text in menus, etc
[12:05] <Hobbsee> now i can have my glassy panels, with readable text!
[12:08] <geser> bluekuja: we are past DIF, so no automatic sync of linuxdcpp for hardy anymore
[12:16] <mruiz> hi all
[12:34] <slytherin> Is anyone planning on packaging tomcat6?
[12:35] <persia> slytherin: Would you mind opening a separate bug for the libglazedlists-java sync request?  The Debian version looks fine, but I doubt the archive admins want to track all the FTBFS fixes.
[12:37] <slytherin> persia: Sure. Somehow debian.org is not responding properly at this time. So I couldn't verify yesterday or today.
[12:37] <persia> slytherin: Try packages.qa.debian.org, which has a .dsc download link, and was working fine for me several times today.
[12:43] <slytherin> persia: Done. bug 178583 I like 'Also Affects' feature of launchpad :-)
[12:43] <ubotu> Launchpad bug 178583 in libglazedlists-java "Please sync latest version from Debian, fixes FTBFS" [Undecided,New] https://launchpad.net/bugs/178583
[12:46] <persia> slytherin: I agree that also affects is a really nice feature, but please don't do that for a sync bug that's already ACK'd.  Also, you'll need to include the Debian changelog for libglazedlists-java.  Be prepared for a complaint from the archive admins (although it should be sane).
[12:46] <mruiz> hi all. I'm working on bug 177715. The patch is done, but I need guidance to go on...
[12:46] <ubotu> Launchpad bug 177715 in k9copy "k9copy spell check, "Insuffisant disk space"" [Low,In progress] https://launchpad.net/bugs/177715
[12:46] <slytherin> persia: I have included it just before your comment. But I will keep in mind to log different bugs for syncs
[12:47] <persia> slytherin: It's not a bad thing to have several tasks in a sync bug, it just breaks workflow when the tasks are changed after the ACK.
[12:47] <slytherin> hmm
[12:49] <persia> Typically multiple tasks are used when multiple packages must be changed to fix a specific issue, and multiple bugs are used when the same issue must be fixed in different packages.  Part of the reason is that people subscribe to bugs for specific packages, and want to know about things affecting those packages, but don't much care about the same thing needing to happen to other packages.
[12:50] <slytherin> Right. People use different bug tracking systems in different ways. :-)
[12:52] <slytherin> persia: Leaving now. See you tomorrow.
[12:58] <mruiz> I prepared this patch: http://pastebin.ubuntu.com/3014/ for the bug 177715. Why should I do: attach it to the bug in LP or put it into debian/patches ?
[12:58] <ubotu> Launchpad bug 177715 in k9copy "k9copy spell check, "Insuffisant disk space"" [Low,In progress] https://launchpad.net/bugs/177715
[12:59] <jpatrick> mruiz: put into debian/patches and make a debdiff
[13:00] <mruiz> jpatrick, thanks. Do I have to modify debian/rules too?
[13:01] <jpatrick> mruiz: it uses cdbs with simple-patchsys - no need :)
[13:02] <jpatrick> shove it in patches, dch -i, and attach a debdiff
[13:05] <jpatrick> mruiz: my personal preference is to make patches like: http://pastebin.ubuntu.com/3015/
[13:06] <mruiz> thanks jpatrick ... good advice :-)
[13:06] <jpatrick> mruiz: but if "debian/rules apply-patches" and "debian/rules reverse-patches" works it should be fine
[13:06]  * persia notes that hand-editing diffs can be very rewarding, but may cause issues.  Be careful in the process.
[13:07] <StevenK> It can also be very frustrating.
[13:07] <StevenK> You spend five minutes hand-editing a diff only to have patch say "What diff?"
[13:08]  * persia cheers the power of editdiff
[13:42] <bluekuja> geser, ah true...
[13:42] <bluekuja> geser, gonna request it manually then :)
[14:20] <mruiz> lintian said: E: k9copy source: outdated-autotools-helper-file admin/config.guess 2002-10-21
[14:20] <mruiz> E: k9copy source: outdated-autotools-helper-file admin/config.sub 2002-09-05
[14:20] <mruiz> . How can I solve this error?
[14:21] <Kmos> mruiz: autotools-dev to build-depends
[14:23] <jpatrick> mruiz: tell upstream to update their admin dir
[14:24] <persia> Err.  Neither of those is complete :)
[14:24] <persia> mruiz: Does the package update config.guess at build-time?
[14:25] <mruiz> persia, let me see...
[14:25] <jpatrick> persia: cdbs, I don't think so
[14:26] <mruiz> jpatrick, yes... cdbs :-(
[14:26] <mruiz> clean::
[14:26] <mruiz>         rm -f k9copy.1
[14:27]  * mruiz reading https://wiki.ubuntu.com/EmmetHikory, section Opinions, config.{sub,guess}
[14:27] <jpatrick> mruiz: that's fine, it's for the docbook
[14:27] <persia> mruiz: That's an opinion.  You have three choices:
[14:28] <persia> 1) Update the hints files at build time (my favorite), in which case you must, as Kmos indicated, build-depend on autotools-dev.
[14:28] <persia> 2) Update the hints files manually when you update the package.
[14:29] <mruiz> the solution number 1 worked fine.... thanks Kmos for this hint
[14:29] <persia> 3) Tell upstream to update their hints files (my second favorite), as jpatrick suggested.
[14:29] <persia> Arguments against #1 are that the package may not build the same twice.  Arguments for are that the package will automatically adapt to new architectures.
[14:30] <persia> Arguments against #2 is that it makes an ugly patch, and may be forgotten.  Argument for is that the maintainer prefers #3, but upstream hasn't gotten around to it yet.
[14:31] <persia> Argument for #3 is that it benefits everyone.  Argument against is that these files change frequently, and may be tuned for distributions, and so shouldn't be distributed upstream.
[14:31] <persia> There is no right answer.  My opinion is more that it should be done in configure: rather than in clean: if the automated update method is chosen.
[14:32] <mruiz> persia, then which commands should I add to debian/rules, section configure:: ?
[14:34] <jpatrick> mruiz: $(MAKE) -f admin/Makefile.common dist
[14:35] <jpatrick> that's from /usr/share/cdbs/1/class/kde.mk
[14:35] <persia> Bah.  I can't find the relevant dh_make example.  Check for the existence of /usr/share/misc/config.sub and config.guess, and copy them to the root directory, if they exist.
[14:36] <persia> s/root directory/root package directory/
[14:37] <persia> Also, because it's CDBS, you want to do it in makebuilddir/k9copy rather than in configure::
[14:48] <mruiz> jpatrick, I added  $(MAKE) -f admin/Makefile.common dist to build/k9copy:: , but the error is still there :-(
[14:49] <apachelogger__> mruiz: what's the error?
[14:49] <jpatrick> mruiz: I'd put it in makebuilddir/k9copy::
[14:49] <mruiz> apachelogger__, E: k9copy source: outdated-autotools-helper-file admin/config.guess 2002-10-21
[14:49] <mruiz> E: k9copy source: outdated-autotools-helper-file admin/config.sub 2002-09-05
[14:49] <apachelogger__> hrrhrr
[14:50] <apachelogger__> mruiz: first check the tarball
[14:50] <apachelogger__> some kde tarballs tend to have 2 versions of config.sub and guess
[14:50] <apachelogger__> due to lovely kdevelop
[14:51] <apachelogger> hehe
[14:52] <apachelogger> this one is just outdated :D
[14:52] <apachelogger> someone should bug stream ;-)
[14:52] <apachelogger> mruiz: can you please paste your debian/rules?
[14:53] <mruiz> apachelogger, http://pastebin.ubuntu.com/3017/
[14:55]  * apachelogger is wondering how anything in there should fix the autotools-helper-files
[14:56] <apachelogger> anyway
[14:56] <mruiz> apachelogger, ups... it was the old one
[14:56] <apachelogger> ^_^
[14:56] <apachelogger> mruiz: you should drop a note to upstream eitherway
[14:56] <apachelogger> there are also some backup files in the orig.tar.gz
[14:56] <apachelogger> e.g. configure~
[14:57] <mruiz> apachelogger, http://pastebin.ubuntu.com/3018/
[14:58] <apachelogger> uhm
[15:00] <mruiz> it is correct ?
[15:00] <apachelogger> well, it is correct, just not for your issue :P
[15:00]  * apachelogger is wondering why jpatrick tossed that line
[15:01] <jpatrick> apachelogger: it's in buildprep for kde
[15:01] <apachelogger> yeah, but what does it have to do with the autotools-helper-files?
[15:01] <jpatrick> prehaps just cp /usr/share/misc/config.sub .?
[15:01] <apachelogger> pretty much so
[15:03] <jpatrick> don't you just love cmake
[15:03] <apachelogger> ahh
[15:03] <apachelogger> cmake <3
[15:03] <apachelogger> anyway
[15:04] <apachelogger> mruiz: just add a build-dep on autotools-dev
[15:04] <mruiz> that's the easiest solution ;-)
[15:04] <apachelogger> buildcore.mk should then take care of the config.sub/guess update
[15:04] <apachelogger> mruiz: the only logical :P
[15:05] <apachelogger> doing it yourself in the rules file would be redundant with cdbs
[15:05] <apachelogger> talking about that, some cdbs include is rudundant there
[15:05]  * apachelogger investigates
[15:07] <apachelogger> I think autotools.mk can be removed
[15:08] <apachelogger> not completely redundant but kde.mk should take of all the important stuff
[15:27] <mruiz> thanks guys... I attached the debdiff to the bug and subscribed uus to review it :-)
[15:28]  * jpatrick looks
[15:29] <jpatrick> mruiz: kubuntu patches should kubuntu_0n_patchdesc.diff
[15:30] <jpatrick> it helps us seperate them from debian ones
[15:30] <mruiz> great idea
[15:30]  * mruiz updating the patch name...
[15:31] <jpatrick> apart from that looks good
[15:31] <mruiz> jpatrick, kubuntu_05_typo_fix.patch ?
[15:31] <jpatrick> that's fine
[15:34] <mruiz> jpatrick, the new debdiff is done and uploaded to LP :-)
[15:36] <jpatrick> a ver..
[15:39] <jpatrick> mruiz: erm, you didn't make changes to debian/rules
[15:42] <mruiz> jpatrick, yes because I solved the error (temporally) with the inclusion of autotools-dev as build-depends. I'm writing an email to upstream requesting an update of admin/ stuff
[15:43] <jpatrick> mruiz: yes, but changelog says you've edited the rules file
[15:43] <jpatrick> should I just remove * debian/rules ? :)
[15:44]  * mruiz dropping the line :-)
[15:47] <jpatrick> mruiz: so you're happy if I upload without that line?
[15:48] <mruiz> :-) the new debdiff is uploaded
[15:49] <mruiz> jpatrick, wait me a moment, please...
[15:49] <jpatrick> ok
[16:03] <mruiz> jpatrick, I added my pbuilder log to the bug
[16:06] <jpatrick> mruiz: subido, muchas gracias
[16:08] <mruiz> jpatrick, gracias a ti
[16:18] <mr_pouit> jpatrick: since a string has been changed, shouldn't .po be updated? (I'm not familiar with kde build system, maybe that's made automagically :p)
[16:18] <jpatrick> mr_pouit: the KDE pot extraction thing should do it
[16:20] <mr_pouit> ok ^^
[16:38] <andrea-bs> hi, could someone tell me if there will be the motu Q&A session on Friday?
[16:43] <norsetto> andrea-bi: since dholbach is on holidays and nobody else has volunteered yet, I don't think so (but will be happy to be corrected)
[16:44] <andrea-bs> ok, thanks anyhow
[17:00] <mruiz> I got an error in during the build of a package... https://launchpad.net/ubuntu/+source/k9copy/1.2.1-0ubuntu2/+build/479739 (chroot problem) I did the build with my pbuilder without problems. Where can I find more information about this issue ?
[17:00] <CheGuevara> ./topic
[17:02] <jpatrick> mruiz: don't worry, we're in for a massive giveback
[17:02] <mruiz> :-)
[17:02] <mruiz> -> Most builds are currently failing! thanks CheGuevara
[17:03] <CheGuevara> np :)
[17:04] <mruiz> I want to learn more about missing icons/menu entries bugs. Any advice?
[17:05] <xtknight> mruiz, have a question in particular?
[17:05] <xtknight> ive worked on a couple of these
[17:07] <mruiz> xtknight, I want to learn how is the procedure to deal with them :-) for instance bug 89353
[17:07] <ubotu> Launchpad bug 89353 in gnome-chess "no menu entry" [Low,Confirmed] https://launchpad.net/bugs/89353
[17:10] <xtknight> mruiz, ok  do you have an environment in which to reproduce this bug?
[17:11]  * mruiz installing the package
[17:11] <xtknight> it actualy works for me fine on Gutsy
[17:12] <xtknight> im not even sure if there's anything we can do for dapper
[17:12] <xtknight> electing for a bug fix maybe altho im not too familiar w/ the politics.  if you can reproduce on dapper we can go from there just for experience with fixing menu bugs
[17:13] <jpatrick> I don't think it'll get into -updates for an icon
[17:15] <mruiz> xtknight, gnome-chess doesn't have a menu entry on Feisty
[17:16] <xtknight> hold on i believe im mistaken
[17:16] <mruiz> xtknight, and Gutsy
[17:16] <xtknight> i dont think mine has an icon either.  it was another chess
[17:17] <mruiz> xtknight, glChess ;-)
[17:17] <xtknight> yea
[17:17] <xtknight> alright
[17:17] <mruiz> xtknight, then... go on ;-)
[17:17] <xtknight> lol ok give me a few secs to examine what's happening here
[17:18] <mruiz> ok...
[17:27] <xtknight> mruiz, does it appear in Other for you?
[17:27] <mruiz> xtknight, no
[17:29] <xtknight> ok, it does here.  seems to be directly related to deleting/adding /usr/share/gnome/apps/Games/gnome-chess.desktop
[17:30] <mruiz> ok
[17:31] <xtknight> not sure why exactly it is not appearing anywhere in the menu for you
[17:32] <mruiz> xtknight, I'm using Gutsy too
[17:32] <xtknight> maybe you need to do "sudo gtk-update-icon-cache"
[17:32] <xtknight> does that then make it appear in Other?
[17:33] <mruiz> no :-(
[17:33] <mruiz> it doesn't appear
[17:34] <xtknight> dpkg -s gnome-chess | grep Version
[17:34] <mruiz> Version: 0.3.3-6
[17:34] <xtknight> same
[17:35] <xtknight> well i can't think of what else i did
[17:35] <xtknight> sudo apt-get --purge remove gnome-chess
[17:35] <xtknight> sudo apt-get install gnome-chess
[17:35] <xtknight> maybe this will do it
[17:38] <mruiz> xtknight, the same problem
[17:39] <xtknight> mruiz, youre using gnome?
[17:39] <mruiz> xtknight, yes
[17:42] <xtknight> mruiz, ok let's try this.  moving it to a different gnome shortcut dir.  "sudo mv /usr/share/gnome/apps/Games/gnome-chess.desktop /usr/share/applications/"
[17:43] <mruiz> xtknight, after it the icon appeared on Other
[17:43] <xtknight> ah really
[17:43] <xtknight> ok
[17:44] <xtknight> mruiz, well these are just two different gnome shortcut directories.  i believe the /usr/share/gnome/apps* is legacy.  i don't know why it's flaky, but everything i see nowadays is in /usr/share/applications
[17:44] <xtknight> it seems to be linked to the problem
[17:45] <mruiz> xtknight, then what is the rationale to work on menu/icon missing bugs ?
[17:45] <xtknight> mruiz, well we can have the Debian package copy the shortcut to /usr/share/applications instead
[17:46] <xtknight> mruiz, you also want the shortcut to appear in Games, not Other, right?
[17:46] <mruiz> xtknight, sure... it's the correct place for gnome-chess
[17:46] <xtknight> mruiz, first let's get the source code for gnome-chess
[17:46] <mruiz> done :-)
[17:46] <xtknight> mruiz, "apt-get source gnome-chess" in somewhere convenient
[17:46] <xtknight> ok
[17:47] <xtknight> mruiz, see gnome-chess.desktop  in root dir of source?
[17:48] <mruiz> xtknight, yes
[17:48] <Kopfgeldjaeger> hi
[17:48] <xtknight> glchess appears in the right place, so let's look at the glchess shortcut file.  "cat /usr/share/applications/glchess.desktop | less"
[17:48] <Kopfgeldjaeger> could a sponsor have a look at bug #163287 ? (avidemux package update, https://bugs.edge.launchpad.net/ubuntu/+source/avidemux/+bug/163287 )
[17:48] <ubotu> Launchpad bug 163287 in avidemux "Please merge avidemux 2.4~preview3-0.0 from debian-multimedia.org experimental" [Undecided,Confirmed] https://launchpad.net/bugs/163287
[17:51] <mruiz> xtknight, gnome-chess doesn't have a Categories section
[17:51] <xtknight> mruiz, yup (good job ;))
[17:51] <xtknight> so i say put one in
[17:51] <xtknight> the one from glchess looks precisely appropriate (board game)
[17:52] <xtknight> for now use /usr/share/applications/gnome-chess.desktop, because this is our local file for testing
[17:56] <mruiz> I applied the changes and the icon appeared under Games ;-)
[17:58] <xtknight> mruiz, ok let's edit the .desktop in the source pkg to the same thing
[17:59] <mruiz> xtknight, but this changes isn't under debian directory. Should I apply a patch against the file?
[17:59] <xtknight> mruiz, yea we will have to make a patch for this
[18:00] <xtknight> do you know about making patches and all yet?
[18:00] <xtknight> like debdiffs
[18:00] <mruiz> yes
[18:00] <imbrandon> if there is a patch system inplace already , yes use it, if not patch hte source directly ( thats the rule of thumb )
[18:00] <xtknight> ok im a little rough on patching myself so i'll try and stick to helping you w/ the shortcut issue
[18:02] <xtknight> mruiz, we also need to make sure the .desktop is now installed in /usr/share/applications
[18:02] <imbrandon> mruiz: if you are in the source directory and have ubuntu-dev-tools installed you can run `what-patch` to see what patch system is in place already
[18:02] <xtknight> and we'll probably be modifying the debian dir for this
[18:02] <mruiz> thanks imbrandon
[18:02] <xtknight> imbrandon, cool, is this new?
[18:02] <xtknight> i always did it manually :P
[18:02] <imbrandon> xtknight: umm not especialy , few months atleaste
[18:03] <mruiz> imbrandon, cdbs
[18:03] <xtknight> yup
[18:03] <imbrandon> mruiz: ok then use simplepatchsys
[18:03] <imbrandon> eg make a diff and put it in debian/patches
[18:03] <imbrandon> :)
[18:04]  * imbrandon is afk again
[18:06] <mruiz> imbrandon, what is the difference between .diff and .patch extensions?
[18:07] <jpatrick> they're the same
[18:08] <xtknight> where's the spec for a .menu file in debian/ dir?
[18:09] <Spec> right here!
[18:09] <xtknight> :O
[18:10] <mruiz> hahaha
[18:17] <Spec> i'm not sure what a .menu file is
[18:17] <Spec> http://www.debian.org/doc/maint-guide/ch-dother.en.html#s-menu
[18:17] <Spec> also, man 5 menufile
[18:17] <Spec> and /usr/share/doc/debian-policy/menu-policy.html/
[18:21] <Ubulette> hmm, i have a dh_strip issue. any idea ? http://paste.ubuntu.com/3021/
[18:36] <mruiz> xtknight, we have to find the way to modify the current directory for .desktop file...
[18:36] <xtknight> mruiz, sorry i've gotta take off for a bit but i'll be back in a couple of hours.  i looked at it and actually i'm not sure.  there is a .menu file in debian/ that we may need to modify or eliminate altogether
[18:37] <mruiz> xtknight, don't worry
[18:37] <xtknight> i think the .menu script is putting it in the wrong dir
[18:37] <xtknight> alright well ill be back soon w/e the case
[18:37] <xtknight> good luck
[18:39] <mruiz> thanks xtknight
[18:43] <mruiz> Where can I find information to solve missing menu entries bugs?
[19:34] <zul> afternoon
[19:38] <Treenaks> hey zul
[20:16] <nxvl_work> can someone give me a hand with Bug #178046 ?? i don't know how to solve it
[20:16] <ubotu> Launchpad bug 178046 in dillo "dillo failed to unpatch" [Undecided,New] https://launchpad.net/bugs/178046
[20:17] <joejaxx> failed to unpatch?
[20:17]  * joejaxx goes to read
[20:18] <joejaxx> oh fun
[20:19] <nxvl_work> yep
[20:20] <nxvl_work> joejaxx: did you have a clue on how to fix it?
[20:23] <apachelogger> Oo
[20:23] <apachelogger> this patch is awful
[20:23] <apachelogger> and not just because of dpatch
[20:25] <nxvl_work> apachelogger: why? cause of the multiple files patched in there?
[20:26] <apachelogger> probably, namely because of it's size
[20:26] <apachelogger> 60k lines are just too many for a patch IMO
[20:26] <nxvl_work> wow, i haven't see that!
[20:27] <nxvl_work> 181 files patched on that file
[20:27] <apachelogger> well
[20:27] <apachelogger> nxvl_work: you probably can't do a lot about it
[20:28] <nxvl_work> apachelogger: why?
[20:28] <apachelogger> one of the patched files gets changed while building
[20:28] <apachelogger> so the patch can not be reverted
[20:28] <joejaxx> yeah
[20:28] <nxvl_work> apachelogger: how did you see that?
[20:28] <joejaxx> that seems to be it
[20:28] <apachelogger> nxvl_work: it's a guess
[20:28] <nxvl_work> oh!
[20:28] <nxvl_work> ok
[20:29] <apachelogger> but usually if a patch can not be reverted it's due to a changed file
[20:29] <nxvl_work> if i find it i can backup that file and then restore it
[20:29] <apachelogger> and looking at the size of the patch its more than likely
[20:29] <apachelogger> nxvl_work: yeah, something like that should fix it
[20:29] <nxvl_work> now, the thing is how to find it?
[20:30] <apachelogger> well, this is where it makes sense to have a lot small patch files instead of one big, at least in terms of package maintainability
[20:30] <apachelogger> nxvl_work: easiest solution would be to just backup all of the patched files
[20:31] <nxvl_work> apachelogger: easiest isn't always the best
[20:31] <apachelogger> you can of course manually try to revert the patch and try to get some proper error output
[20:32] <apachelogger> but really, the whole thing is just not worth it
[20:32] <nxvl_work> or split the patch in many little patches
[20:32] <apachelogger> yeah
[20:33] <norsetto> is it just my installation or scrollkeeper in hardy is broken?
[20:34]  * apachelogger is wondering why dillo upstream doesn't include that patch
[20:35] <norsetto> apachelogger: IIRC dillo upstream is no more
[20:35] <apachelogger> wooohooo
[20:35] <nxvl_work> is there any way to tell cut to print the last parameter?
[20:36] <apachelogger> so why not just change the tarball
[20:36] <apachelogger> -.-
[20:36] <apachelogger> some things just don't appear useful to me
[21:36] <awen_> trying to make the a pbuilder environment for another architecture i keep getting an error; anyone has any idea, what i'm doing wrong?
[21:36] <awen_> W: Failure trying to run: chroot /var/cache/pbuilder/build/9291/. mount -t proc proc /proc
[21:36] <awen_> pbuilder: debootstrap failed
[21:38] <joejaxx> you mean you are trying to cross-{build,compile}? on a non-native host
[21:38] <joejaxx> ?
[21:38] <DktrKranz> awen_, I haven't tried directly, but I think you can't run a say sparc pbuilder on a i386 platform
[21:39] <awen_> joejaxx: exactly
[21:39] <awen_> DktrKranz: okay... strange, that was what i got out of reading the pbuilder guide from the wiki
[21:40] <DktrKranz> awen_, you can run a i386 pbuilder on a amd64 host
[21:40] <DktrKranz> or a lpia one on i386
[21:41] <DktrKranz> but, unless you use something similar to qemubuilder, you can't run something designed for another port
[21:41] <joejaxx> :)
[21:41] <awen_> DktrKranz: so only some cross-builds are possible...
[21:42] <DktrKranz> If I don't miss something, yes
[21:42] <DktrKranz> well, cross-compilation should possible with some tools
[21:42] <DktrKranz> *should be possible
[21:42] <awen_> does the ppa only build for different ubuntu versions, or do they include the possibility of building for debian sid ?
[21:43] <DktrKranz> only for supported Ubuntu versions actually
[21:44] <awen_> DktrKranz: seems i have to give qemubuilder a try some time instead :)
[21:45] <DktrKranz> awen_, if you are successful, please ping. Learn to use it is on my TODO-list
[21:46] <DktrKranz> I used qemu to emulate sparc some time ago
[21:46] <awen_> DktrKranz: i'll do
[21:46] <joejaxx> DktrKranz: was it fun? serial console ftw :)
[21:47] <DktrKranz> joejaxx, it was not fun, kernel panics everywhere :)
[21:47] <DktrKranz> but I got it working, don't ask me how :)
[21:47] <DktrKranz> it was Debian, though
[21:48] <joejaxx> yeah
[21:48] <joejaxx> i would not try ubuntu on that
[21:48] <joejaxx> lol
[21:48] <joejaxx> DktrKranz: the install for sparc takes a long time too
[21:48] <joejaxx> lol
[21:48] <DktrKranz> I noticed...
[21:49] <joejaxx> well it is not worse than a S/390 install
[21:49] <joejaxx> haha
[21:49]  * DktrKranz really wants to try it on a *real* sparc box
[21:50] <joejaxx> DktrKranz: bah :P Solaris ftw :D
[21:51] <DktrKranz> mh... I need to grab some sparc stuff before attempting to look at it
[21:51] <joejaxx> what Solaris?
[21:51] <joejaxx> they have x86 solaris
[21:51] <DktrKranz> I know
[21:51] <joejaxx> but Solaris (SPARC) Solaris (x86) :D
[21:51] <joejaxx> gah
[21:51] <DktrKranz> starting from 10, IIRC
[21:52] <joejaxx> Solaris (SPARC) > Solaris (x86)*  :D
[21:52] <crimsun> from 9, at least.
[21:52] <joejaxx> 9
[21:52] <joejaxx> yeah
[21:52] <joejaxx> it was 9
[21:53] <joejaxx> well publically anyway
[21:53] <joejaxx> gah
[21:53] <joejaxx> cannto spell
[21:53] <joejaxx> cannot*
[21:53] <joejaxx> publicly*
[21:53] <joejaxx> publically is not a word lol
[21:54] <DktrKranz> it is a word, but is is not published on english dictionaries
[21:55] <joejaxx> :)
[21:56] <joejaxx> bbl :D
[21:56] <joejaxx> Treenaks: !! :P
[21:56] <joejaxx> ok
[21:56] <joejaxx> bbl
[22:05] <nxvl_work> is there any way to split a dpatch patch correctly?
[22:05] <nxvl_work> i have tried using filterdiff
[22:05] <nxvl_work> but something went wrong
[22:08] <crimsun> depends
[22:08] <crimsun> you can use splitdiff, or some magic with rediff, etc.
[22:09] <crimsun> ("some magic" could well be editdiff)
[22:14] <nxvl_work> mmm
[22:14] <nxvl_work> the thing with that is that dpatch has a different format than diff
[22:15] <nxvl_work> it need some lines that the diff utils doesn't take
[22:16] <crimsun> err?
[22:16] <crimsun> it's a unified diff
[22:16] <crimsun> just strip the metadata from the dpatch
[22:23] <nxvl_work> !?
[23:46] <imbrandon> mmmm new keyboard, maybe less typos :)
[23:46] <imbrandon> heh prob not
[23:56] <persia> mruiz: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles might be the documentation you sought.