=== asac_ is now known as asac [00:58] 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] pochu, i tracked it down to sqlite3 [00:59] pochu, see http://mxr.mozilla.org/mozilla-central/source/storage/src/mozStorageService.cpp#68 liferea aborts line 82 [01:08] 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] 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] Some flavours (e.g. edubuntu or ubuntustudio) use different locations for customised applications.menu files, but the idea is the same. [02:20] pochu, i just explained all that in bug 295490. please see my last comment. [02:20] Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Confirmed] https://launchpad.net/bugs/295490 [02:25] ScottK, ping? [02:35] ScottK: are you available to talk about the downgrading idea? [02:36] Ewww. [02:37] andrew_sayers: i'd be interested in the discussion [02:37] * Hobbsee is looking at brainstorm, for some stupid reason [02:38] Hobbsee: fair enough, what's your opinion on the matter? [02:38] 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] andrew_sayers: like 'doze does it, with their system backup / system restore stuff. [02:39] 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] i guess you could flush out certain caches [02:40] such as run stuff like 'apt-get clean', etc, first, and that sort of thing, to get it down [02:40] i don't actually know how to get a snapshot of a linux system, i'm afraid. [02:40] but i remember the stuff on backing up had some good info [02:40] trying to downgrade changes made to user configuration files wouldn't be easy [02:40] 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] ajmitch: i don't think any sane person would even attempt that. [02:41] 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] ajmitch: it would be a "backup, and reimage" solution [02:41] 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] andrew_sayers: http://www.psychocats.net/ubuntu/backup is the best thing i've found so far (and related links) [02:42] eg rolling back 2 weeks, you wouldn't want to be losing 2 weeks of stuff in /home [02:42] ajmitch: well, I was assuming that it would be an immediate rollback, or at least, done within the next day or so [02:42] 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] some problems can take a bit longer than that to surface [02:43] 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] iirc, windows does the same thing? [02:43] * ajmitch shrugs [02:43] haven't dealt with windows much :) [02:43] unless you keep the updated ~ [02:44] 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] which may be problematic if config files, etc, got updated. [02:44] and config files do get upgraded in interesting ways [02:44] 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] one reason why sharing /home between different versions can be painful [02:45] (they pushed a video card update that kept bringing up BSODs for some of the games I was running) [02:45] ajmitch: indeed. [02:45] There's also the new "preserve /home" function in the installer. Maybe there'd a way to leverage that? [02:45] Hang on, is it just /etc that's the killer to downgrade? [02:45] dotfiles could well be mangled, but that's an easier issue to resolve. [02:45] persia: apps are generally written with upgrade functionality in mind, but not downgrade [02:45] andrew_sayers, /etc, user dotfiles, and possibly some stuff in /var [02:45] ajmitch, Yep. [02:46] I take it that now's not the time to be talking about version-controlling those, in the general case? [02:46] ajmitch, The only sane way is wipe&replace, but that doesn't necessarily mean losing 2 weeks of /home. [02:47] /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] 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] 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] part of the problem is identifying what needs to be be kept & what can be replaced [02:49] Yeah, that would have to be done on a per-package basis. [02:49] Which shouldn't be all that hard if we're just asking packages to add a symlink to a known dir. [02:51] 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] Most of /etc is probably md5sum identical according to dpkg, and can be dropped. [02:52] 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] Depending on whether the user recently cleaned their apt-cache, this could be gigabytes of packages to download for the older versions. [02:54] 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] downgrade would most likely entail wiping whole parts of the filesystem & installing the appropriate packages, if I understand persia's suggestion correctly [02:56] 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] And VCing the sensitive bits wouldn't cut it? [02:57] 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] 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] 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] All downgrades actually, since it would in principle be possible to create a snapshot before (un)installing any package. [03:02] 'etckeeper' [03:02] 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] Is there any particular reason it's not done by default? [03:04] 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] 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] It's also different than most random Google results on how to perform a given operation. [03:06] Fair point, although "easier to break" sounds like a fixable UI issue to me. [03:07] When you say wipe, do you mean uninstalling most packages, or deleting everything outside /usr? [03:07] Er, /home [03:17] lifeless: that's excellent. I shall now become another /etc in VCS zealot ;) [03:22] 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] 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] rlaager, In many cases, that's not so hard. For things like /etc/hosts, it's a bit tricky. [03:23] The reason being that /etc/hosts doesn't belong to a package. [03:23] 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] persia: /etc/hosts isn't really a good example, as nobody really modifies that much, except for the machine name. [03:24] 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] 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] Well, plus chunks of /var, but yeah. [03:26] I never keep anything across installs from /var on either clients or servers. What would you be concerned about? [03:26] 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] Oh, sure. [03:26] Or use something like puppet to determine config state from remote VCS. [03:26] (well, VCS of rules that generates config, but...) [03:27] And site-local packaging is a little extreme for the user that wants to undo an upgrade on an isolated desktop. [03:29] 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] 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] hyperair: yes, it's uploaded. -proposed needs to be manually reviewed by an archive administrator before showing up [03:30] hyperair: an archive admin will comment on the launchpad bug to let you know when that has happened. [03:30] 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] jdong: oh i see. forgive my ignorance =) [03:30] andrew_sayers: I'm here now. [03:30] NCommander: Pong. [03:31] hyperair: no probs :) [03:32] ScottK: Hey - rlaager has already summed up everything I've got to say and more :) [03:33] OK. [03:34] andrew_sayers: I was up for making the suggestion. I really don't have time to work on implementation. [03:34] persia: Ah, I see. Thanks. (RE application menu two hours ago) [03:35] 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] A more specific/newbie-friendly UI and a .d. [03:37] ScottK: Do you have time to help with a blueprint? [03:38] 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] 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] 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] "make apt go backwards" --> "downgrades"? [03:40] apt is moderately indifferent to that; it's the dpkg design that doesn't support it, and can't do sanely [03:40] slangasek: Yes. And yes, that's a more correct way to put it. [03:41] 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] 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] 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] 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] andrew_sayers: thats not really a problem [03:42] 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] andrew_sayers: because *of course* you are backing up separately your user content [03:42] andrew_sayers: I maintain that the FHS is broken in that regard. ;) [03:43] superm1: yes, probably [03:43] slangasek, okay i'll tie of with bryce then and get an SRU for it ready tomorrow [03:43] superm1: fglrx was usable at all at release time? I should that was one of the broken-with-modern-X ones [03:44] slangasek, yeah it was usable for everything but r3xx [03:44] ah [03:44] 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] AMD came through last minute - like with a week or two to go [03:44] ah, heh, I don't think I was aware of that [03:45] 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] I do recall nvidia betas being released the day of the 8.10 release, or some such... :) [03:48] 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] NCommander: Still here? [06:13] good morning [06:35] 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] persia: Yeah, it's about time to do that. [06:42] persia: I'll do it for the arches that aren't backlogged. [06:43] emet: So, !{armel,hppa,ia64,sparc} [06:43] persia: ^^ ... Not sure how that turned into emet.. [06:43] infinity, Thanks. [06:43] * slangasek erases the leading 'e' [06:44] infinity, thanks :-) [06:45] infinity, Should we watch and ask again when sparc and ia64 have caught up? [06:45] persia: Might not be a terrible plan. [06:45] persia: Anyhow, all done. [06:45] does anyone here have softmac wireless? [06:46] persia, we shouldn't do sparc until we at least get a second builder, it would take forever [06:46] hey infinity [06:46] Yeah, sparc needs some hardware love right now. [06:46] NCommander, I agree. ia64 just needs time. hppa needs manual intervention. armel needs to finish digesting the elephant. [06:46] (does the softmac driver still exist, even?) [06:46] infinity, I dunno if you remember, but we talked about issues w/ Hardy kernel on the powerpc buildds [06:46] infinity, do you still have those logs? [06:47] NCommander: We totally did. And I totally don't have 'em lying around right now. [06:47] NCommander: (Note that it's both midnight and a holiday, so I'm just sort of stopping by..) [06:47] As I said before, no rush. We still have two years until the next LTS [06:47] NCommander: Let me see if I can dig something up. === tkamppeter_ is now known as tkamppeter [07:31] Good morning [07:43] Hi pitti [07:43] * lool tends slowly to the pitti-time [07:49] bonjour lool === doko_ is now known as doko === giskard_ is now known as giskard [09:21] hmm [09:21] do we recently support /etc/modules being a dir instead of a file ? [09:28] * ogra glares at bug 297434 [09:28] Launchpad bug 297434 in fuse "package fuse-utils 2.7.3-4ubuntu2 failed to install/upgrade: subprocess post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/297434 [09:29] 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] so if i have a static ethernet interface in intrepid and unplug the cable, the interface goes down ? [09:54] thats just annoying [09:54] asac, ^^^ is that NMs fault ? [09:55] (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] 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] 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] 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] well I've got it a lot cleaner, but debdiff still has some "reverted:" chunks [10:06] tjaalton: so those were just cruft from the previous source build? [10:06] pitti: the intrepid version doesn't clean up after itself, so the diff has a lot of cruft, yes [10:08] pitti: ah, ok.. so the old version also had x-k/patches dir, which doesn't belong there :) [10:09] now the diff is sensible [10:14] pitti: reuploaded [10:20] tjaalton: ah, indeed that slipped my attention: it's patches/, not debian/patches [10:21] someone forgot to export QUILT_PATCHES or so :) [10:21] pitti: yeah, well the new version does patches -> debian/patches IIRC :) [10:21] the one that'll soon be in jaunty [10:40] * sonicmctails always forget to set QUILT_PATCHES === sonicmctails is now known as NCommander === edson is now known as \e === \e is now known as edson [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] quilt started out as a tool for patch maintenance in the kernel, not for Debian patch maintenance [10:44] it seems a bit unfair to hijack it [10:45] is it used in debian or ubuntu for kernel patch maintenance still ? [10:45] 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] the package exists in the archive for more than just what we use [10:46] cjwatson, i know, but is it actually still used in other ways ? :) [10:46] yes. [10:46] ogra: there are people who use quilt in addition to git for kernel maintenance [10:46] ah [10:46] elmo, thanks thats what i wanted to know [10:46] google for 'kernel quilt 2008' [10:46] then it makes sense to go into bashrc [10:47] ogra, linux-rt uses upstream quilt assemblies to build. [10:47] 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] not for everyone else to have to be paying attention [10:47] people are entitled to silently use things :) [10:48] well, it never occured to me personally before it showed up in packages i had to touch ... [10:48] and it still gives me a painful time every time i have to use it [10:48] seeing comments from others i dont seem to be alone :) [10:49] I am not arguing with that, but "the people I know have problems" really isn't particularly good support for breaking compatibility [10:50] well, i didnt mean to make the change right now, it was just a question out of interest (and ongoing pain) [10:51] ogra, just linux-rt ATM. [10:51] 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] having people who only ever use it that way set QUILT_PATCHES=debian/patches in .bashrc seems entirely sensible [10:52] although they should be careful to unset it for build testing === mcasadevall is now known as NCommander === thekorn_ is now known as thekorn [12:54] cjwatson: (just merging fuse) what's the rationale for having fuse in the initramfs? [12:54] cjwatson: I'd like to give a rationale for forwarding stuff to Debian [12:59] pitti: I already did, they rejected it [12:59] pitti: the rationale is to support ntfs-3g for wubi [13:00] ah, thanks [13:00] pitti: oh, no, the thing they rejected was putting it in / rather than /usr [13:01] that would have been my next question :) [13:01] (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452412) [13:01] Debian bug 452412 in fuse "fuse: install to / rather than /usr" [Wishlist,Open] [13:01] pitti: forward it if you like, I just wasn't particularly encouraged by the response I got to the other bit [13:01] "It has been discussed with others debian developpers and all agree it's useless for the debian project." [13:01] 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] 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] new features + bug fixes :P [14:30] Y2K38: no it's not normal, unless you're getting it via ppa [14:30] Y2K38, It's not normal at all. Which upgrade? [14:31] hyperair, Even then it's not normal (although behaviour is more variable) [14:31] persia: hyperair just had a look at alacarte 0.11.5-0ubuntu1.1 [14:32] thats just 1 example [14:32] persia: i've never had changelog entries from any upgrades from ppa before [14:32] its not from ppa [14:33] right now we have 25 upgrades and only handful of them have dev changelogs [14:34] travis watkins O_o!! [14:34] wtf is travis watkins!?!!?! [14:34] 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] persia: that doesn't say anything [14:35] persia: if my local mirror doesn't include changelog what good is it? :P [14:36] 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] maybe its the adept who's fscking up [14:36] it may of course have a minimal or poorly-written changelog [14:36] 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] 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] 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] cjwatson: persia whats the command line to get changelogs? :P thanks [14:38] Y2K38, aptitude changelog $(package) is what I use. [14:38] lets see if its me who's PEBKAC or the adept guys [14:38] persia: thanks! [14:39] neither, the problem here is probably that changelogs.ubuntu.com hasn't extracted that changelog yet [14:39] 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] six hours or so - you'd expect so [14:40] wow! that really looks like a PITA.. [14:40] Y2K38: ease up for a minute, please! [14:40] Y2K38: Are you running Intrepid? [14:40] cjwatson: sure i will [14:40] ScottK: hardy [14:40] Unless changelogs don't get copied until things move to -updates, and this was late. [14:41] * persia looks up publication date [14:41] oh, no, I'm mistaken due to the truncation on changelogs.ubuntu.com's apache directory listings [14:41] http://changelogs.ubuntu.com/changelogs/pool/main/a/alacarte/alacarte_0.11.5-0ubuntu1.1/changelog looks fine [14:41] But it did sit in -proposed for six months. Only got published 2008-11-12. [14:41] cjwatson: so say i pull packages from archive.ubuntu.com, this should be fixed ya? [14:42] persia: the changelog was extracted on changelogs.u.c on 16 Oct, though [14:42] doh! 16oct! isn't that really late or what guys? [14:42] * persia is extra confused [14:42] Y2K38: huh? lay off [14:43] Y2K38: investigating a problem is rarely helped by people shouting "this is all crap" in the middle of it [14:44] 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] 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] 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] 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] 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] cjwatson: i take your word since you work for canonical! :) i will try to see the changelogs in couple of days... [14:46] ok, so adept is hardcoded to look at changelogs.ubuntu.com [14:46] Y2K38: your local mirror is not relevant at all here [14:47] I suppose it's possible that adept is confused about the component, although I'm not quite sure how that would happen [14:47] but at any rate, yes, this does look like an adept bug [14:47] Y2K38: could you please try update-mangaer? [14:47] Y2K38: just to check if its specifc to adept or not [14:48] cjwatson: mvo ok lets give update-manager a whirl [14:48] * Y2K38 ISP's is acting weird today [14:50] Y2K38: seems like you're suffering from https://bugs.launchpad.net/ubuntu/+source/adept/+bug/136381 [14:50] Launchpad bug 136381 in adeptmgr "Adept doesn't show changelogs." [Unknown,In progress] [14:52] hm, so its not implemented in adept at all? [14:52] 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] mvo: yes its adept specific it seems [14:53] mvo: in >=intrepid, no; in <=hardy it worked for some packages but not others [14:53] cjwatson: w00t! [14:53] mvo: I think it's due to .source() returning empty when binary package == source package [14:53] * mvo nods [14:54] cjwatson: I recently make the server side much client friendlier, should be fine to just check the binary packagenames now [14:54] StevenK: there, NBS brought down from 23042420 packages to 14; love, pitti [14:54] Wheee [14:54] pitti: Nice work! [14:54] pitti: Sorry, I've been ignoring NBS :-( [14:54] mvo: ah, cool, can you mention that in the bug [14:54] ? [14:54] mvo: just in case the adept guys reimplement this ... [14:55] cjwatson: will do [14:55] 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] ok guys.. till it gets a fix, i might have to refrain from using adept!!! [14:55] cjwatson: thanks for pointing this out man. [14:55] StevenK: I didn't do rebuilds, just waded through the dependency circles [14:55] pitti: Mmmm [15:03] ls [15:03] ls [15:03] quit [15:03] see ya fellas.. [15:14] When will bug #291262 be fixed? [15:14] Launchpad bug 291262 in python-central "MASTER - package failed to install/upgrade: pycentral pkginstall: not overwriting local files" [High,Triaged] https://launchpad.net/bugs/291262 [15:51] slangasek, I attached a debdiff to your bug re: dput === wasabi` is now known as wasabi [16:10] I forget... How do I find older versions of Debian packages? Like, say, iptables-1.4.1.1-3? [16:11] snapshot.debian.net ? [16:11] Using google and hoping for an outdated mirror worked this time, but.. [16:11] elmo: Oh. [16:12] elmo: It doesn't show iptables versions more recent than 1.4.0-3 (date: some time in February). [16:13] Does it not keep a record of all versions or has it simply not been updated for a while? [16:13] snapshot.debian.net is not updating [16:13] Which is rougly when it died. [16:13] * soren hugs the outdated mirror he found [16:13] and had also lost older versions last time I looked [16:13] oh, that's a shame [16:13] 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] 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] hopefully [16:15] LP is also mirroring Debian source on an ongoing basis now [16:16] soren: https://launchpad.net/debian/+source/iptables/1.4.1.1-3 [16:16] only started relatively recently [16:16] cjwatson: *blink* Awesome! [16:16] as in about two weeks ago [16:53] mvo, got a moment? [17:15] heh Keybuk thanks for the boilerplate mail :P [17:15] heh, don't mention it %(fullname)s [17:20] 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] 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] Can somebody please look at bug 297771, which renders logcheck quite useless on Intrepid? [19:04] Launchpad bug 297771 in logcheck "logcheck ignores all logs in "server" or "workstation" config" [High,Fix released] https://launchpad.net/bugs/297771 [19:47] cody-somerville: thanks for the dput fix :) [19:48] cody-somerville: btw, I should be following through on the grub xen fix today [19:49] Thanks === ogra_ is now known as ogra === xxx__ is now known as _iron [21:05] hey kees [21:05] 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] :] [21:06] curious, gnome-panel doesn't know what the temperature is here today [21:31] 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] anyone here have broadcom wireless who could check quickly whether bug #47610 still applies? [22:01] Launchpad bug 47610 in wireless-tools "iwlist eth1 rate shows nonsense rates" [Wishlist,Confirmed] https://launchpad.net/bugs/47610 [22:10] grr the company my wife is doing an infomercial for is totally inept :\ [22:11] 6hr into a 3hr session and they haven't even started shotting yet [22:31] Some issues to solve: http://mange.dynalias.org/linux/misc/Intrepid_Ibex_errors.txt [22:32] Also, how can i get a trashcan on my desktop in Intrepid ? [22:33] SOF4LNX, bugs are reported at launchpad.net ;) [22:33] Hello dude :) [22:34] Some have been reported, like https://bugs.launchpad.net/ubuntu/+source/gadmin-proftpd/+bug/276181 [22:34] Launchpad bug 276181 in gadmin-proftpd "gadmin-proftpd crashes on startup" [Medium,Fix committed] [22:34] A solution has been out for half a year but no updates so people fill up my inbox :) [22:35] Also compile proftpd using "--with_modules=mod_tls" [22:36] Correction: --with-modules=mod_tls [22:36] Will this also be done ? [22:38] Ive also talked to the debian crew about it so maybe it will, i hope. [22:39] joaopinto: Would you like a console daemon that distributes passwords for users via ssh and scp ? [22:39] and other configurable files as well... [22:40] Like, you have one master password server and add some accounts. They will then be distributed to all configured servers you like ... [22:41] Sure beats that slow microsoft solution using CIFS stuff [22:41] SOF4LNX, isn't that what ldap and NIS do :P ? [22:41] Dont they add extra security issues and slowness ? [22:42] (As we talked about:) [22:43] Lets turn it around, can you see why it wouldnt be good ? [22:43] I don't see what is good on doing yet another version of something which has been tested for long years :) [22:45] I watch bugtrack, ldap is alright but its not the best solution by a longshot (i think). [22:46] Auth-Distributor (AD) will be without any security issues as i see it. [22:46] Granted, of course that ssh is secure [22:49] joaopinto: Lets say it could be awesome and easy to admin servers across the worlds. Would it be nice then you think ? :=) [22:49] "No, its not my kind of consolemio" :P [22:53] SOF4LNX: sounds like kerberos to me [22:54] sounds inferior to kerberos, to me. :) [22:54] except kerberos has had proper security design :-) [22:54] Howq can i make kerberos update and or add new users to remote computers and update other files like samba smbpasswd ? [22:55] you don't; you do that with other technologies that are coupled with kerberos [22:55] Such as what ? [22:55] LDAP is one example. [22:56] nss-ldap, or userdir-ldap [22:56] 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] but it's a key feature of kerberos that random servers do *not* get to know the passwords for individual users [22:56] So LDAP wont add more security issues then not running it ? [22:57] it won't add more security issues than distributing passwords around your network [22:57] cjwatson: will be done irregardless using ssh keys. Not less secure then kerberos [22:57] false [22:57] true, what do you mean ? [22:58] trusting all of your servers with copies of the user passwords *is* less secure than kerberos [22:58] If the keys are on each machine, then all you need to do is compromise a machine. [22:58] any machine. [22:58] and suddenly you have access to every other machine. [22:59] There are well understood methodologies for this in place. From NIS to LDAP. [22:59] 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] And Microsoft's solution: Active Directory; is pretty much ideal. We can get close with kerberos and LDAP set up by hand. [22:59] AD is Kerberos and LDAP. Just set up properly by default. heh. [22:59] Microsofts solution is slow and crappy wasabix [22:59] 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] slangasek: NIS isn't a solution. I'm just demontstrating that we have already thought about this. [23:00] yes, ssh is more secure then LDAP and NIS [23:00] no, it isn't. [23:00] Dude. It's not. [23:00] wasaabilnx [23:01] * kees pulls up a lawn chair [23:01] SOF4LNX: You likely do not understand MS's solution. [23:01] Haha, we will keep the laughs up. But really, in the frekkin winter ? (minus degress over here) [23:01] wasabi: 15000 clients and i dont ? [23:02] doesnt scale [23:02] Yeah. You've run Active Directory? [23:02]