[00:58] <fta> pochu, i gave it more thoughts, the xul path in liferea is not important since we are using static glue. it's detected by GRE at runtime. the Abort() comes from something else.
[00:58] <fta> pochu, i tracked it down to sqlite3
[00:59] <fta> pochu, see http://mxr.mozilla.org/mozilla-central/source/storage/src/mozStorageService.cpp#68  liferea aborts line 82
[01:08] <ozzilee1> Can anyone tell me where Ubuntu keeps track of what folder an app's launcher should go in? By folder I mean "Accessories", "Games", etc. It doesn't seem to be in the .desktop file...
[01:10]  * ozzilee1 will come back after watching a couple episodes of House...
[01:37] <persia> ozzilee, It's calculated based on the contents of (usually) /etc/xdg/menus/applications.menu which uses the Categories keys in the .desktop files.
[01:38] <persia> Some flavours (e.g. edubuntu or ubuntustudio) use different locations for customised applications.menu files, but the idea is the same.
[02:20] <fta> pochu, i just explained all that in bug 295490. please see my last comment.
[02:25] <NCommander> ScottK, ping?
[02:35] <andrew_sayers> ScottK: are you available to talk about the downgrading idea?
[02:36] <wgrant> Ewww.
[02:37] <Hobbsee> andrew_sayers: i'd be interested in the discussion
[02:37]  * Hobbsee is looking at brainstorm, for some stupid reason
[02:38] <andrew_sayers> Hobbsee: fair enough, what's your opinion on the matter?
[02:38] <Hobbsee> andrew_sayers: well, the only reliable way is goign to be a snapshot of the old system, which you can then go and restore.  How small can that snapshot be made?
[02:39] <Hobbsee> andrew_sayers: like 'doze does it, with their system backup / system restore stuff.
[02:39] <andrew_sayers> I don't know, but I have LVM and installing Intrepid is still on my todo list, so I can do a test if someone can tell me how to check the result.
[02:39] <Hobbsee> i guess you could flush out certain caches
[02:40] <Hobbsee> such as run stuff like 'apt-get clean', etc, first, and that sort of thing, to get it down
[02:40] <Hobbsee> i don't actually know how to get a snapshot of a linux system, i'm afraid.
[02:40] <Hobbsee> but i remember the stuff on backing up had some good info
[02:40] <ajmitch> trying to downgrade changes made to user configuration files wouldn't be easy
[02:40] <persia> Well, caches can be flushed, and unmodified files ignored.  It's mostly just grabbing unclaimed and modified files in /etc, dpkg --get-selections, and preserving /home to be able to restore assuming some reboots and the old disk.
[02:41] <Hobbsee> ajmitch: i don't think any sane person would even attempt that.
[02:41] <persia> The problem is that downgrades aren't well supported by apt, so it would need to be almost a reinstall to be known safe.
[02:41] <Hobbsee> ajmitch: it would be a "backup, and reimage" solution
[02:41] <ajmitch> Hobbsee: that's the problem - people wouldn't want to lose their mail, photos etc which can end up mixed in with per-account configuration
[02:42] <Hobbsee> andrew_sayers: http://www.psychocats.net/ubuntu/backup is the best thing i've found so far (and related links)
[02:42] <ajmitch> eg rolling back 2 weeks, you wouldn't want to be losing 2 weeks of stuff in /home
[02:42] <Hobbsee> ajmitch: well, I was assuming that it would be an immediate rollback, or at least, done within the next day or so
[02:42] <andrew_sayers> Hobbsee: thanks - I'll work it out if that turns out to be the way to go.  Losing mail would be a problem though - LVM is a bit of a blunt instrument in that regard.
[02:43] <ajmitch> some problems can take a bit longer than that to surface
[02:43] <Hobbsee> ajmitch: but warnings, etc, can be written about that "warning:  This will put your system back to X date, running Y version.  Please make sure you have backed up any important files that you have modified since then, and wish to keep"
[02:43] <Hobbsee> iirc, windows does the same thing?
[02:43]  * ajmitch shrugs
[02:43] <ajmitch> haven't dealt with windows much :)
[02:43] <Hobbsee> unless you keep the updated ~
[02:44] <andrew_sayers> I've heard the same about Windows, but I've never tried it.  I think it's just for specific stuff like the registry and c:\windows\blah
[02:44] <Hobbsee> which may be problematic if config files, etc, got updated.
[02:44] <ajmitch> and config files do get upgraded in interesting ways
[02:44] <Hobbsee> andrew_sayers: no, it does the entire thing.  I triedit a while ago.  I just don't remember what it does with the stuff in mydocs.
[02:45] <ajmitch> one reason why sharing /home between different versions can be painful
[02:45] <Hobbsee> (they pushed a video card update that kept bringing up BSODs for some of the games I was running)
[02:45] <Hobbsee> ajmitch: indeed.
[02:45] <persia> There's also the new "preserve /home" function in the installer.  Maybe there'd a way to leverage that?
[02:45] <andrew_sayers> Hang on, is it just /etc that's the killer to downgrade?
[02:45] <persia> dotfiles could well be mangled, but that's an easier issue to resolve.
[02:45] <ajmitch> persia: apps are generally written with upgrade functionality in mind, but not downgrade
[02:45] <persia> andrew_sayers, /etc, user dotfiles, and possibly some stuff in /var
[02:45] <persia> ajmitch, Yep.
[02:46] <andrew_sayers> I take it that now's not the time to be talking about version-controlling those, in the general case?
[02:46] <persia> ajmitch, The only sane way is wipe&replace, but that doesn't necessarily mean losing 2 weeks of /home.
[02:47] <persia>  /srv, /var/lib/, /var/log, etc. might be interesting for some users, but not others.
[02:48]  * ajmitch would be in deep trouble if /var/lib got rolled back
[02:48] <andrew_sayers> If we wanted to go a la Windows, it wouldn't be that hard to create /var/bzr/foo symlinks that get backed up nightly.
[02:49] <andrew_sayers> That would make downgrading easier, be easy for packages to add to, and avoid the whole "oh no I Just deleted my config" issue.
[02:49] <ajmitch> part of the problem is identifying what needs to be be kept & what can be replaced
[02:49] <andrew_sayers> Yeah, that would have to be done on a per-package basis.
[02:49] <andrew_sayers> Which shouldn't be all that hard if we're just asking packages to add a symlink to a known dir.
[02:51] <persia> Well, conservative retention is /var/games, /var/lib, /var/local, /var/log, /var/opt, /var/spool, /var/www, /etc, /opt, /usr/local, and /home.  The rest should be system managed.
[02:51] <persia> Most of /etc is probably md5sum identical according to dpkg, and can be dropped.
[02:52] <persia> The tricks are 1) performing wipe & restore without breaking things, and 2) having a restore source (e.g. package repo CD for previous install state).
[02:53] <persia> Depending on whether the user recently cleaned their apt-cache, this could be gigabytes of packages to download for the older versions.
[02:54] <andrew_sayers> How wWould the bandwidth for a downgrade be more than the bandwidth for an upgrade?
[02:55]  * andrew_sayers needs to put delete and enter further apart :s
[02:55] <ajmitch> downgrade would most likely entail wiping whole parts of the filesystem & installing the appropriate packages, if I understand persia's suggestion correctly
[02:56] <persia> Yeah, that's the only way I can think of doing it, unless you provide everyone patching any pf the packages with a time machine.
[02:56]  * ajmitch doesn't even want to think about how maintainer scripts would handle it otherwise
[02:57] <andrew_sayers> And VCing the sensitive bits wouldn't cut it?
[02:57] <persia> You can do a store-in-place to local storage, but reconstructing packages from unpacked source is itself inherently risky, so you still probably have download requirements.
[02:58] <persia> Well, sure.  You could e.g. snapshot, try the upgrade, and revert the snapshot, but that takes even more local storage than using packages.
[03:01] <andrew_sayers> Okay, so would it be fair to say this: creating a pervasive VC system for config files isn't worth it for backup alone, but might be a good idea for the general health of your system.  If it is a good general idea, it makes the specific case of downgrades easier.
[03:02] <andrew_sayers> All downgrades actually, since it would in principle be possible to create a snapshot before (un)installing any package.
[03:02] <lifeless> 'etckeeper'
[03:02] <persia> Indeed.  There's a number of people who swear by keeping /etc in VCS.  Large chunks of /var would benefit from it as well.  /home in VCS is reasonably common, although usually with a decently large local folder that hasn't been added.
[03:03] <andrew_sayers> Is there any particular reason it's not done by default?
[03:04] <persia> Keeping that stuff in VCS doesn't make downgrades any less risky unless you're doing a wipe & reinstall, as maintainer scripts aren't idempotent
[03:04] <persia> It's a little slower, a little more complicated, and a little easier to break if you don't know what you're doing.
[03:04] <persia> It's also different than most random Google results on how to perform a given operation.
[03:06] <andrew_sayers> Fair point, although "easier to break" sounds like a fixable UI issue to me.
[03:07] <andrew_sayers> When you say wipe, do you mean uninstalling most packages, or deleting everything outside /usr?
[03:07] <andrew_sayers> Er, /home
[03:17] <andrew_sayers> lifeless: that's excellent.  I shall now become another /etc in VCS zealot ;)
[03:22] <rlaager> I don't want to get sucked into this too much, but I'd like to throw out an idea that may or may not help you... I try my hardest to separate (for lack of a better word) "transient" data from the OS data.
[03:22] <rlaager> So, on client machines, transient data is /home, basically. Everything but /home can be trashed. (I'll get to /etc and /boot in a minute.) On a server, I move everything in /srv. So, for example, /var/lib/mysql gets moved to /srv/mysql.
[03:23] <persia> rlaager, In many cases, that's not so hard.  For things like /etc/hosts, it's a bit tricky.
[03:23] <persia> The reason being that /etc/hosts doesn't belong to a package.
[03:23] <rlaager> How do I deal with /etc and /boot? Well, I maintain that all through the package manager. Everything that I touch there I build into (site-local) configuration packages.
[03:23] <rlaager> persia: /etc/hosts isn't really a good example, as nobody really modifies that much, except for the machine name.
[03:24] <persia> rlaager, Well, except that the system doesn't work well without it.  Plus I only have 10-15 files to choose from if I want one that breaks without backup due to being created by the installer.
[03:25] <rlaager> Completing this idea... Any box should be able to be re-created by 1) re-installing the OS, 2) re-installing the machine configuration packages, and 3) restoring (or maintaining through the re-install) /srv or /home.
[03:25] <persia> Well, plus chunks of /var, but yeah.
[03:26] <rlaager> I never keep anything across installs from /var on either clients or servers. What would you be concerned about?
[03:26] <persia> Still, not so hard to take care of the bits of /etc that aren't md5sum identical with shipped, and set those aside without site-local config packages.
[03:26] <rlaager> Oh, sure.
[03:26] <persia> Or use something like puppet to determine config state from remote VCS.
[03:26] <persia> (well, VCS of rules that generates config, but...)
[03:27] <persia> And site-local packaging is a little extreme for the user that wants to undo an upgrade on an isolated desktop.
[03:29] <hyperair> jdong: did you upload banshee (1.2.1-3ubuntu1.1) to intrepid-proposed? it's not in http://archive.ubuntu.com/ubuntu/pool/universe/b/banshee/
[03:29] <rlaager> persia: Sure. If you want to ship something that Just Works, that's not the way to do it. I wasn't sure of your use case, though. For larger deployments, it makes sense.
[03:30] <jdong> hyperair: yes, it's uploaded. -proposed needs to be manually reviewed by an archive administrator before showing up
[03:30] <jdong> hyperair: an archive admin will comment on the launchpad bug to let you know when that has happened.
[03:30] <rlaager> persia: If I were looking to implement a snapshot-type system, I'd do the dpkg md5sum thing for /etc and grab specific things from elsewhere, e.g. /var (based on a .d directory where packages could drop a file saying, "grab this") and then I'd store in a tree of compressed backwards deltas (ala rdiff-backup) in some place like /restore, which would be left untouched by the installer.
[03:30] <hyperair> jdong: oh i see. forgive my ignorance =)
[03:30] <ScottK> andrew_sayers: I'm here now.
[03:30] <ScottK> NCommander: Pong.
[03:31] <jdong> hyperair: no probs :)
[03:32] <andrew_sayers> ScottK: Hey - rlaager has already summed up everything I've got to say and more :)
[03:33] <ScottK> OK.
[03:34] <ScottK> andrew_sayers: I was up for making the suggestion.  I really don't have time to work on implementation.
[03:34] <ozzilee1> persia: Ah, I see. Thanks. (RE application menu two hours ago)
[03:35] <andrew_sayers> For the VCS part of the equation, I'm quite tempted to put some time into adding the bits that etckeeper would need to be a general thing.
[03:36] <andrew_sayers> A more specific/newbie-friendly UI and a .d.
[03:37] <andrew_sayers> ScottK: Do you have time to help with a blueprint?
[03:38] <ScottK> andrew_sayers: Not particularly.  My main point was that you can't make apt go backwards reliably.  It's really, really not designed for that.
[03:38] <ScottK> andrew_sayers: I do encourage you to work on the problem and I'm glad you're here.  I can try to answer questions.
[03:40] <rlaager> andrew_sayers: Yeah, I think you can easily protect the user against breaking their config files. I don't think you can protect against broken system upgrades very easily. If you want to do that, you need good filesystem snapshotting stuff...
[03:40] <slangasek> "make apt go backwards" --> "downgrades"?
[03:40] <slangasek> apt is moderately indifferent to that; it's the dpkg design that doesn't support it, and can't do sanely
[03:40] <ScottK> slangasek: Yes. And yes, that's a more correct way to put it.
[03:41] <ScottK> slangasek: The request was to be able to upgrade, say to Intrepid, and if it didn't work out due to regressions, revert to Hardy.  My suggestion was good back ups.
[03:41]  * slangasek nods
[03:41] <andrew_sayers> rlaager: the problem with snapshotting the FS is that it's a blunt instrument that can't tell /var/mail from /var/lib
[03:42] <rlaager> andrew_sayers: I'm not sure if you've looked at Nexenta, but from what I've read of their documentation, they have some really sweet apt/ZFS integration which takes advantage of ZFS snapshots. Basically, I think they snapshot before apt starts making changes and even add an entry to the bootloader menu for that snapshot.
[03:42] <rlaager> If you had /home and /srv (and whatever in /var) as a separate filesystem (which is, of course, trivial with ZFS), it'd be perfect.
[03:42] <lifeless> andrew_sayers: thats not really a problem
[03:42] <superm1> slangasek, so as it turns out, fglrx 8.11 resolves the regression that all r3xx hardware is broken.  would you consider an SRU towards it if we let it sit in proposed for a little bit and look for other regressions?
[03:42] <lifeless> andrew_sayers: because *of course* you are backing up separately your user content
[03:42] <rlaager> andrew_sayers: I maintain that the FHS is broken in that regard. ;)
[03:43] <slangasek> superm1: yes, probably
[03:43] <superm1> slangasek, okay i'll tie of with bryce then and get an SRU for it ready tomorrow
[03:43] <slangasek> superm1: fglrx was usable at all at release time?  I should that was one of the broken-with-modern-X ones
[03:44] <superm1> slangasek, yeah it was usable for everything but r3xx
[03:44] <slangasek> ah
[03:44] <andrew_sayers> ScottK: Thanks for the offer - if I'm going to be working on my own, it's more likely to be a "2 hours a week for a year" than "2 days solid hacking" type thing, so you won't hear anything for a good long while.
[03:44] <superm1> AMD came through last minute - like with a week or two to go
[03:44] <slangasek> ah, heh, I don't think I was aware of that
[03:45] <ScottK> andrew_sayers: I suspect you can build a community of interest around this.  You might put it on brainstorm and try to recruit people who are interested to help.
[03:45] <slangasek> I do recall nvidia betas being released the day of the 8.10 release, or some such... :)
[03:48] <andrew_sayers> ScottK: Yeah, I've already got a little project like that.  When I've done the major work on that project, I guess I'd put this next on my list.  In the mean-time, I'd just be scratching my various itches.
[04:36] <StevenK> NCommander: Still here?
[06:13] <dholbach> good morning
[06:35] <persia> We're just looking at outstanding FTBFS in #ubuntu-motu, and notice that a lot of the !{armel,hppa} cases would benefit from just being given back.  Would it be possible to schedule a mass-give-back?
[06:42] <infinity> persia: Yeah, it's about time to do that.
[06:42] <infinity> persia: I'll do it for the arches that aren't backlogged.
[06:43] <infinity> emet: So, !{armel,hppa,ia64,sparc}
[06:43] <infinity> persia: ^^ ... Not sure how that turned into emet..
[06:43] <persia> infinity, Thanks.
[06:43]  * slangasek erases the leading 'e'
[06:44] <NCommander> infinity, thanks :-)
[06:45] <persia> infinity, Should we watch and ask again when sparc and ia64 have caught up?
[06:45] <infinity> persia: Might not be a terrible plan.
[06:45] <infinity> persia: Anyhow, all done.
[06:45] <slangasek> does anyone here have softmac wireless?
[06:46] <NCommander> persia, we shouldn't do sparc until we at least get a second builder, it would take forever
[06:46] <NCommander> hey infinity
[06:46] <infinity> Yeah, sparc needs some hardware love right now.
[06:46] <persia> NCommander, I agree.  ia64 just needs time.  hppa needs manual intervention.  armel needs to finish digesting the elephant.
[06:46] <slangasek> (does the softmac driver still exist, even?)
[06:46] <NCommander> infinity, I dunno if you remember, but we talked about issues w/ Hardy kernel on the powerpc buildds
[06:46] <NCommander> infinity, do you still have those logs?
[06:47] <infinity> NCommander: We totally did.  And I totally don't have 'em lying around right now.
[06:47] <infinity> NCommander: (Note that it's both midnight and a holiday, so I'm just sort of stopping by..)
[06:47] <NCommander> As I said before, no rush. We still have two years until the next LTS
[06:47] <infinity> NCommander: Let me see if I can dig something up.
[07:31] <pitti> Good morning
[07:43] <lool> Hi pitti
[07:43]  * lool tends slowly to the pitti-time
[07:49] <pitti> bonjour lool
[09:21] <ogra> hmm
[09:21] <ogra> do we recently support /etc/modules being a dir instead of a file ?
[09:28]  * ogra glares at bug 297434
[09:29] <ogra> there is definately no code that creates /etc/modules/udftools in the udftools package
[09:29]  * ogra doesnt get where that could come from
[09:53]  * ogra curses .... 
[09:54] <ogra> so if i have a static ethernet interface in intrepid and unplug the cable, the interface goes down ?
[09:54] <ogra> thats just annoying
[09:54] <ogra> asac, ^^^ is that NMs fault ?
[09:55] <ogra> (it doesnt seem to touch the iface otherwise, but my nfs export via crossover cable doesnt work once i rebooted the machine on the other side of the cable)
[10:01] <tjaalton> pitti: duh, the xkeyboard-config cruft that got removed from the update was due to _not_ building this older version first. I was trying the newer debian version which cleans all/most generated files :)
[10:03] <tjaalton> pitti: but I still don't understand why 100_abnt2.diff is referenced on the debdiff, since neither of those packages have it when unpacked
[10:04] <pitti> I just looked at debdiff ~/ubuntu/pool/main/x/xkeyboard-config/xkeyboard-config_1.3-2ubuntu4.dsc xkeyboard-config_1.3-2ubuntu4.1.dsc|view -
[10:04] <tjaalton> well I've got it a lot cleaner, but debdiff still has some "reverted:" chunks
[10:06] <pitti> tjaalton: so those were just cruft from the previous source build?
[10:06] <tjaalton> pitti: the intrepid version doesn't clean up after itself, so the diff has a lot of cruft, yes
[10:08] <tjaalton> pitti: ah, ok.. so the old version also had x-k/patches dir, which doesn't belong there :)
[10:09] <tjaalton> now the diff is sensible
[10:14] <tjaalton> pitti: reuploaded
[10:20] <pitti> tjaalton: ah, indeed that slipped my attention: it's patches/, not debian/patches
[10:21] <pitti> someone forgot to export QUILT_PATCHES or so :)
[10:21] <tjaalton> pitti: yeah, well the new version does patches -> debian/patches IIRC :)
[10:21] <tjaalton> the one that'll soon be in jaunty
[10:40]  * sonicmctails always forget to set QUILT_PATCHES
[10:42]  * ogra doesnt get why quilt cant just default to debian/patches ... let the people using it out of packaging have to fiddle with the env 
[10:44] <cjwatson> quilt started out as a tool for patch maintenance in the kernel, not for Debian patch maintenance
[10:44] <cjwatson> it seems a bit unfair to hijack it
[10:45] <ogra> is it used in debian or ubuntu for kernel patch maintenance still ?
[10:45] <hyperair> ogra: if you're that annoyed, stuff QUILT_PATCHES in your bashrc
[10:45]  * ogra doubts that since everyone doing kernel stuff uses git anyway
[10:45] <cjwatson> the package exists in the archive for more than just what we use
[10:46] <ogra> cjwatson, i know, but is it actually still used in other ways ? :)
[10:46] <cjwatson> yes.
[10:46] <elmo> ogra: there are people who use quilt in addition to git for kernel maintenance
[10:46] <ogra> ah
[10:46] <ogra> elmo, thanks thats what i wanted to know
[10:46] <cjwatson> google for 'kernel quilt 2008'
[10:46] <ogra> then it makes sense to go into bashrc
[10:47] <persia> ogra, linux-rt uses upstream quilt assemblies to build.
[10:47] <cjwatson> and TBH when advocating a change like that the onus is on the advocate of the change to figure out whether it's still being used elsewhere
[10:47] <cjwatson> not for everyone else to have to be paying attention
[10:47] <cjwatson> people are entitled to silently use things :)
[10:48] <ogra> well, it never occured to me personally before it showed up in packages i had to touch ...
[10:48] <ogra> and it still gives me a painful time every time i have to use it
[10:48] <ogra> seeing comments from others i dont seem to be alone :)
[10:49] <cjwatson> I am not arguing with that, but "the people I know have problems" really isn't particularly good support for breaking compatibility
[10:50] <ogra> well, i didnt mean to make the change right now, it was just a question out of interest (and ongoing pain)
[10:51] <NCommander> ogra, just linux-rt ATM.
[10:51] <persia> Could well be less pain as various efforts in Debian to establish a common operating model for different kinds of packages bear fruit.
[10:52] <cjwatson> having people who only ever use it that way set QUILT_PATCHES=debian/patches in .bashrc seems entirely sensible
[10:52] <cjwatson> although they should be careful to unset it for build testing
[12:54] <pitti> cjwatson: (just merging fuse) what's the rationale for having fuse in the initramfs?
[12:54] <pitti> cjwatson: I'd like to give a rationale for forwarding stuff to Debian
[12:59] <cjwatson> pitti: I already did, they rejected it
[12:59] <cjwatson> pitti: the rationale is to support ntfs-3g for wubi
[13:00] <pitti> ah, thanks
[13:00] <cjwatson> pitti: oh, no, the thing they rejected was putting it in / rather than /usr
[13:01] <pitti> that would have been my next question :)
[13:01] <cjwatson> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452412)
[13:01] <cjwatson> pitti: forward it if you like, I just wasn't particularly encouraged by the response I got to the other bit
[13:01] <cjwatson> "It has been discussed with others debian developpers and all agree it's useless for the debian project."
[13:01] <pitti> cjwatson: I set myself a policy to forward all non-Ubuntu specific changes to Debian bugs while merging, so I'll do it
[14:30] <Y2K38> heya fellas. is it normal for a package upgrade to not have changelog? i mean i get all my informations on new features using devel changelogs.. i am quite suprised when i didn't find one!
[14:30] <Y2K38> new features + bug fixes :P
[14:30] <hyperair> Y2K38: no it's not normal, unless you're getting it via ppa
[14:30] <persia> Y2K38, It's not normal at all.  Which upgrade?
[14:31] <persia> hyperair, Even then it's not normal (although behaviour is more variable)
[14:31] <Y2K38> persia: hyperair just had a look at alacarte 0.11.5-0ubuntu1.1
[14:32] <Y2K38> thats just 1 example
[14:32] <hyperair> persia: i've never had changelog entries from any upgrades from ppa before
[14:32] <Y2K38> its not from ppa
[14:33] <Y2K38> right now we have 25 upgrades and only handful of them have dev changelogs
[14:34] <Y2K38> travis watkins O_o!!
[14:34] <Y2K38> wtf is travis watkins!?!!?!
[14:34] <persia> Y2K38, I don't understand.  I see http://launchpadlibrarian.net/18600518/alacarte_0.11.5-0ubuntu1_0.11.5-0ubuntu1.1.diff.gz as the diff, which definitely includes a new changelog entry.
[14:35] <Y2K38> persia: that doesn't say anything
[14:35] <Y2K38> persia: if my local mirror doesn't include changelog what good is it? :P
[14:36] <cjwatson> it's impossible for an upgrade to have no changelog at all; the very process of creating it requires creating a changelog entry
[14:36] <Y2K38> maybe its the adept who's fscking up
[14:36] <cjwatson> it may of course have a minimal or poorly-written changelog
[14:36] <cjwatson> but if you're not seeing anything at all, you generally ought to look to your package management program for the problem, not to the package
[14:37] <Y2K38> cjwatson: thats what i thought as well.. i mean the very fact that adept points me to "Index of /changelogs/pool/main" means sth is broken
[14:38] <cjwatson> oh, if you haven't actually installed the package yet, then adept probably routinely goes to changelogs.ubuntu.com (although technically speaking it would be *possible* to fish it out of your local mirror, it'd just be slow)
[14:38] <Y2K38> cjwatson: persia whats the command line to get changelogs? :P thanks
[14:38] <persia> Y2K38, aptitude changelog $(package) is what I use.
[14:38] <Y2K38> lets see if its me who's PEBKAC or the adept guys
[14:38] <Y2K38> persia: thanks!
[14:39] <cjwatson> neither, the problem here is probably that changelogs.ubuntu.com hasn't extracted that changelog yet
[14:39] <persia> cjwatson, Except it's from May, which makes me think that's not it.  Isn't that usually only a 4 hour delay or so?
[14:40] <cjwatson> six hours or so - you'd expect so
[14:40] <Y2K38> wow! that really looks like a PITA..
[14:40] <cjwatson> Y2K38: ease up for a minute, please!
[14:40] <ScottK> Y2K38: Are you running Intrepid?
[14:40] <Y2K38> cjwatson: sure i will
[14:40] <Y2K38> ScottK: hardy
[14:40] <persia> Unless changelogs don't get copied until things move to -updates, and this was late.
[14:41]  * persia looks up publication date
[14:41] <cjwatson> oh, no, I'm mistaken due to the truncation on changelogs.ubuntu.com's apache directory listings
[14:41] <cjwatson> http://changelogs.ubuntu.com/changelogs/pool/main/a/alacarte/alacarte_0.11.5-0ubuntu1.1/changelog looks fine
[14:41] <persia> But it did sit in -proposed for six months.  Only got published 2008-11-12.
[14:41] <Y2K38> cjwatson: so say i pull packages from archive.ubuntu.com, this should be fixed ya?
[14:42] <cjwatson> persia: the changelog was extracted on changelogs.u.c on 16 Oct, though
[14:42] <Y2K38> doh! 16oct! isn't that really late or what guys?
[14:42]  * persia is extra confused
[14:42] <cjwatson> Y2K38: huh? lay off
[14:43] <cjwatson> Y2K38: investigating a problem is rarely helped by people shouting "this is all crap" in the middle of it
[14:44] <cjwatson> Y2K38: and in fact, that version was published in hardy-proposed on 16 Oct. So in fact, no, it wasn't really late at all.
[14:44] <Y2K38> persia: as i see it, our local mirror is _supposed_ to pull info from changelog.ubuntu.com but since its _behind_ i do not _yet_ see changelog ... thats what i understood from cjwatsons explanation
[14:44] <cjwatson> Y2K38: I don't see why your local mirror would pull from changelogs.ubuntu.com. It would pull from archive.ubuntu.com or one of its mirrors. The extracted changelogs are not mirrored.
[14:44] <cjwatson> Y2K38: of course the packages themselves *also* contain changelogs but adept may or may not look there
[14:45]  * cjwatson looks at adept in hardy
[14:45] <persia> Y2K38, I think it's probably adept specific, or specific to your environment, since I can't reproduce with other tools in hardy.
[14:45] <Y2K38> cjwatson: i take your word since you work for canonical! :) i will try to see the changelogs in couple of days...
[14:46] <cjwatson> ok, so adept is hardcoded to look at changelogs.ubuntu.com
[14:46] <cjwatson> Y2K38: your local mirror is not relevant at all here
[14:47] <cjwatson> I suppose it's possible that adept is confused about the component, although I'm not quite sure how that would happen
[14:47] <cjwatson> but at any rate, yes, this does look like an adept bug
[14:47] <mvo> Y2K38: could you please try update-mangaer?
[14:47] <mvo> Y2K38: just to check if its specifc to adept or not
[14:48] <Y2K38> cjwatson: mvo ok lets give update-manager a whirl
[14:48]  * Y2K38 ISP's is acting weird today
[14:50] <cjwatson> Y2K38: seems like you're suffering from https://bugs.launchpad.net/ubuntu/+source/adept/+bug/136381
[14:52] <mvo> hm, so its not implemented in adept at all?
[14:52] <cjwatson> Y2K38: I've added a comment there with my speculation as to the cause, although how much good that'll be I don't know since Adept 3 doesn't support changelog display at all
[14:53] <Y2K38> mvo: yes its adept specific it seems
[14:53] <cjwatson> mvo: in >=intrepid, no; in <=hardy it worked for some packages but not others
[14:53] <Y2K38> cjwatson: w00t!
[14:53] <cjwatson> mvo: I think it's due to .source() returning empty when binary package == source package
[14:53]  * mvo nods
[14:54] <mvo> cjwatson: I recently make the server side much client friendlier, should be fine to just check the binary packagenames now
[14:54] <pitti> StevenK: there, NBS brought down from 23042420 packages to 14; love, pitti
[14:54] <StevenK> Wheee
[14:54] <StevenK> pitti: Nice work!
[14:54] <StevenK> pitti: Sorry, I've been ignoring NBS :-(
[14:54] <cjwatson> mvo: ah, cool, can you mention that in the bug
[14:54] <cjwatson> ?
[14:54] <cjwatson> mvo: just in case the adept guys reimplement this ...
[14:55] <mvo> cjwatson: will do
[14:55] <pitti> StevenK: no need to be, just done as part of archive day; let's try to not make it so ridiculously large for extended periods of time
[14:55] <Y2K38> ok guys.. till it gets a fix, i might have to refrain from using adept!!!
[14:55] <Y2K38> cjwatson: thanks for pointing this out man.
[14:55] <pitti> StevenK: I didn't do rebuilds, just waded through the dependency circles
[14:55] <StevenK> pitti: Mmmm
[15:03] <lasko> ls
[15:03] <lasko> ls
[15:03] <lasko> quit
[15:03] <Y2K38> see ya fellas..
[15:14] <RainCT> When will bug #291262 be fixed?
[15:51] <cody-somerville> slangasek, I attached a debdiff to your bug re: dput
[16:10] <soren> I forget... How do I find older versions of Debian packages? Like, say, iptables-1.4.1.1-3?
[16:11] <elmo> snapshot.debian.net ?
[16:11] <soren> Using google and hoping for an outdated mirror worked this time, but..
[16:11] <soren> elmo: Oh.
[16:12] <soren> elmo: It doesn't show iptables versions more recent than 1.4.0-3 (date: some time in February).
[16:13] <soren> Does it not keep a record of all versions or has it simply not been updated for a while?
[16:13] <james_w> snapshot.debian.net is not updating
[16:13] <ScottK> Which is rougly when it died.
[16:13]  * soren hugs the outdated mirror he found
[16:13] <james_w> and had also lost older versions last time I looked
[16:13] <elmo> oh, that's a shame
[16:13] <james_w> it's going to become part of the Debian infrastructure
[16:14]  * james_w hopes that will include all the history that it used to have
[16:15] <jcristau> james_w: snapshot.d.n seems to have packages i uploaded a few days ago, so maybe they finally fixed the disk full problem..
[16:15] <james_w> hopefully
[16:15] <cjwatson> LP is also mirroring Debian source on an ongoing basis now
[16:16] <cjwatson> soren: https://launchpad.net/debian/+source/iptables/1.4.1.1-3
[16:16] <cjwatson> only started relatively recently
[16:16] <soren> cjwatson: *blink* Awesome!
[16:16] <cjwatson> as in about two weeks ago
[16:53] <MacSlow> mvo, got a moment?
[17:15] <ogra> heh Keybuk thanks for the boilerplate mail :P
[17:15] <Keybuk> heh, don't mention it %(fullname)s
[17:20] <mvo> MacSlow: yes
[17:21]  * Keybuk tries to work out whether the lecture from ivoks's mail server meant it didn't deliver the mail or not
[17:22] <Keybuk> and I'm fully enjoying the irony that someone with silly characters in their name's mail server complains because the headers weren't 7-bit
[19:04] <blueyed> Can somebody please look at bug 297771, which renders logcheck quite useless on Intrepid?
[19:47] <slangasek> cody-somerville: thanks for the dput fix :)
[19:48] <slangasek> cody-somerville: btw, I should be following through on the grub xen fix today
[19:49] <cody-somerville> Thanks
[21:05] <murdok> hey kees
[21:05] <murdok> I saw that you applied the patch to dosemu and that it had nothing to do with the one I made :S, hehe. But it's fine, I have learnt
[21:05] <murdok> :]
[21:06] <slangasek> curious, gnome-panel doesn't know what the temperature is here today
[21:31] <kees> murdok: heh, yeah, I radically rearranged how it was applied, but we get the same results, and in a way that is more standard.  :)
[22:01] <slangasek> anyone here have broadcom wireless who could check quickly whether bug #47610 still applies?
[22:10] <calc> grr the company my wife is doing an infomercial for is totally inept :\
[22:11] <calc> 6hr into a 3hr session and they haven't even started shotting yet
[22:31] <SOF4LNX> Some issues to solve: http://mange.dynalias.org/linux/misc/Intrepid_Ibex_errors.txt
[22:32] <SOF4LNX> Also, how can i get a trashcan on my desktop in Intrepid ?
[22:33] <joaopinto> SOF4LNX, bugs are reported at launchpad.net ;)
[22:33] <SOF4LNX> Hello dude :)
[22:34] <SOF4LNX> Some have been reported, like https://bugs.launchpad.net/ubuntu/+source/gadmin-proftpd/+bug/276181
[22:34] <SOF4LNX> A solution has been out for half a year but no updates so people fill up my inbox :)
[22:35] <SOF4LNX> Also compile proftpd using "--with_modules=mod_tls"
[22:36] <SOF4LNX> Correction: --with-modules=mod_tls
[22:36] <SOF4LNX> Will this also be done ?
[22:38] <SOF4LNX> Ive also talked to the debian crew about it so maybe it will, i hope.
[22:39] <SOF4LNX> joaopinto: Would you like a console daemon that distributes passwords for users via ssh and scp ?
[22:39] <SOF4LNX> and other configurable files as well...
[22:40] <SOF4LNX> Like, you have one master password server and add some accounts. They will then be distributed to all configured servers you like ...
[22:41] <SOF4LNX> Sure beats that slow microsoft solution using CIFS stuff
[22:41] <joaopinto> SOF4LNX, isn't that what ldap and NIS do :P ?
[22:41] <SOF4LNX> Dont they add extra security issues and slowness ?
[22:42] <SOF4LNX> (As we talked about:)
[22:43] <SOF4LNX> Lets turn it around, can you see why it wouldnt be good ?
[22:43] <joaopinto> I don't see what is good on doing yet another version of something which has been tested for long years :)
[22:45] <SOF4LNX> I watch bugtrack, ldap is alright but its not the best solution by a longshot (i think).
[22:46] <SOF4LNX> Auth-Distributor (AD) will be without any security issues as i see it.
[22:46] <SOF4LNX> Granted, of course that ssh is secure
[22:49] <SOF4LNX> joaopinto: Lets say it could be awesome and easy to admin servers across the worlds. Would it be nice then you think ? :=)
[22:49] <SOF4LNX> "No, its not my kind of consolemio" :P
[22:53] <cjwatson> SOF4LNX: sounds like kerberos to me
[22:54] <slangasek> sounds inferior to kerberos, to me. :)
[22:54] <cjwatson> except kerberos has had proper security design :-)
[22:54] <SOF4LNX> Howq can i make kerberos update and or add new users to remote computers and update other files like samba smbpasswd ?
[22:55] <slangasek> you don't; you do that with other technologies that are coupled with kerberos
[22:55] <SOF4LNX> Such as what ?
[22:55] <slangasek> LDAP is one example.
[22:56] <slangasek> nss-ldap, or userdir-ldap
[22:56] <cjwatson> SOF4LNX: seriously, don't try to do your own security design for this - for example distributing passwords around is a really bad idea which is why kerberos distributes tickets instead that you can't just steal
[22:56] <slangasek> but it's a key feature of kerberos that random servers do *not* get to know the passwords for individual users
[22:56] <SOF4LNX> So LDAP wont add more security issues then not running it ?
[22:57] <cjwatson> it won't add more security issues than distributing passwords around your network
[22:57] <SOF4LNX> cjwatson: will be done irregardless using ssh keys. Not less secure then kerberos
[22:57] <slangasek> false
[22:57] <SOF4LNX> true, what do you mean ?
[22:58] <slangasek> trusting all of your servers with copies of the user passwords *is* less secure than kerberos
[22:58] <wasabi> If the keys are on each machine, then all you need to do is compromise a machine.
[22:58] <wasabi> any machine.
[22:58] <wasabi> and suddenly you have access to every other machine.
[22:59] <wasabi> There are well understood methodologies for this in place. From NIS to LDAP.
[22:59] <SOF4LNX> So then an admin should have different keys for all machines, always, even though theyre on the internal network ? And then kerberos is better, why ?
[22:59] <wasabi> And Microsoft's solution: Active Directory; is pretty much ideal. We can get close with kerberos and LDAP set up by hand.
[22:59] <wasabi> AD is Kerberos and LDAP. Just set up properly by default. heh.
[22:59] <SOF4LNX> Microsofts solution is slow and crappy wasabix
[22:59] <slangasek> wasabi:, NIS and LDAP both still have the problem that the user sends the password to the server for authentication; in Kerberos, the server is *never* sent the password, in any form.
[23:00] <wasabi> slangasek: NIS isn't a solution. I'm just demontstrating that we have already thought about this.
[23:00] <SOF4LNX> yes, ssh is more secure then LDAP and NIS
[23:00] <slangasek> no, it isn't.
[23:00] <wasabi> Dude. It's not.
[23:00] <SOF4LNX> wasaabilnx
[23:01]  * kees pulls up a lawn chair
[23:01] <wasabi> SOF4LNX: You likely do not understand MS's solution.
[23:01] <SOF4LNX> Haha, we will keep the laughs up. But really, in the frekkin winter ? (minus degress over here)
[23:01] <SOF4LNX> wasabi: 15000 clients and i dont ?
[23:02] <SOF4LNX> doesnt scale
[23:02] <wasabi> Yeah. You've run Active Directory?
[23:02] <cjwatson> SOF4LNX: folks here are not exactly short of experience either
[23:02] <wasabi> So you knwo what Kerberos and LDAP is?
[23:02] <SOF4LNX> cjwatson: i know that, so asking around wont be bad
[23:02] <wasabi> SOF4LNX: Folks here have written software for that, and have an extremely intimate understanding of it.
[23:02] <cjwatson> SOF4LNX: but you also have to listen to what people with experience say ...
[23:03] <cjwatson> well, you ought to if you want to get the right answer. Obviously I can't tell you to do anything
[23:03] <wasabi> SOF4LNX: Microsoft's solution is distributed/replicated LDAP with all authentication done using Kerberos. It is the ideal solution.
[23:03] <SOF4LNX> I _always_ do. Hence asking
[23:03] <wasabi> We can approximate it by configuring OpenLDAP and MIT Kerberos, or Heimdal
[23:03] <wasabi> or FDS.
[23:04] <wasabi> But Kerberos and LDAP are the reigning kings when it comes to enterprise authentication.
[23:04] <SOF4LNX> wasabi: Id say its very slow and outdated as a solution but i feel youll try to say its not over any cheese in the worlds
[23:04] <wasabi> SOF4LNX: There's nothing to 'be slow'. It's LDAP.
[23:04] <SOF4LNX> Lol
[23:04] <wasabi> And Kerberos. I suspect you don't know what those are.
[23:04] <SOF4LNX> Its microsoft, anythings slow there
[23:04] <SOF4LNX> Or broken
[23:04] <wasabi> *sigh*
[23:04] <SOF4LNX> Lol
[23:04] <wasabi> LO!L!!@!@
[23:04] <SOF4LNX> Same old vsaabix
[23:04] <wasabi> Off topic now. Bye. :)
[23:04] <cjwatson> SOF4LNX: LDAP and Kerberos are not pure Microsoft technologies
[23:05] <SOF4LNX> I know, its not a property of wasabikind :=)
[23:05] <cjwatson> SOF4LNX: for one thing, both are included in the Ubuntu base system
[23:05] <wasabi> Man I have no idea what you're talking about.
[23:05] <SOF4LNX> They do it over CIFS
[23:05] <wasabi> No, they don't.
[23:05] <SOF4LNX> Windohbind
[23:05] <wasabi> But nice try.
[23:05] <cjwatson> SOF4LNX: please stop throwing around what as far as I can see are personal insults or you will be asked to leave
[23:06] <wasabi> CIFS is for file sharing and RPC.
[23:06] <wasabi> ... man what just hit us?
[23:06] <wasabi> me->real work
[23:07] <kees> troll or high?
[23:07] <cjwatson> no need for insults from us either :-)
[23:07] <cjwatson> just confused, I think
[23:07] <kees> well, true, but I was very confused
[23:07] <slangasek> kees: you need a lawn chair with a built-in drink holder
[23:07] <kees> heh
[23:07] <cjwatson> it's all too easy to get into the rut of judging security based on bugtraq message count rather than careful thinking about the design
[23:08] <kees> I guess, but the CIFS mention really threw me