[00:00] <cjwatson> slangasek: mind if I sort out bug 1087843 for raring?
[00:00] <cjwatson> Just an added Recommends
[00:01] <slangasek> cjwatson: be my guest
[00:03] <cjwatson> done, thanks
[01:03] <psusi> hrm.. looks like ntfs-3g has ABI upstream ABI breakage
[01:20]  * YokoZar1 has been finding a lot of edge cases where apt's resolver is wrong
[01:20] <YokoZar1> This is slightly blowing my mind
[01:35] <psusi> YokoZar1, oh?
[01:36] <psusi> I spent today getting pissed at dpkg and it's slowness and trying to figure out debootstrap, and cdebootstrap, and patching them to use libeatmydata to get around the dpkg brokenness that the dpkg maintainers refuse to fix
[01:37] <psusi> drives me nuts to see installs and upgrades spend several seconds on each of many very small packages, and constantly rebuilding initramfses and other things, many times over and over
[01:38] <TheMuso> I thought initramfs rebuilding was taken care of by a trigger...
[01:38] <sarnold> heh, at first I thought, "go try rpm for a change", but I'm pretty sure I've seen rebuilding initramfs twice in an upgrade before too...
[01:39] <psusi> TheMuso, yea. and you would think that the introduction of triggers would have fixed it so it only gets rebuilt once, but it doesn't!
[01:40] <psusi> I must normally see it 6 or 8 or 10 times in a dist-upgrade, I swear
[01:40] <penguin42> yeh that really annoys me when doing cleanups - like removing 20 old kernels and seeing it rebuild for each damn one
[01:41] <psusi> I found today that using libeatmydata makes a bare bones debootstrap time drop from 9m to 1m
[01:41] <penguin42> psusi: That on spinning rust or ssd?
[01:41] <psusi> raid5 array of spinning rust
[01:41] <penguin42> yeh, it's a heck of a lot different on SSD
[01:42] <psusi> dpkg really abuses the hell out of fsync and friends these days and it's absurd to watch it spend 1+ second on each of two dozen packages that are each under 100k in size
[01:42] <penguin42> psusi: Conversely it's a heck of a lot worse on something like an SD card
[01:42] <penguin42> yeh
[01:42] <psusi> yea, but it's also putting a lot of wear and tear on your ssd which has limited write cycles
[01:42] <penguin42> yeh, on an ssd it's not too bad, on the simpler SD cards they don't last a year
[01:43] <psusi> I think dpkg syncs like 6 times per package, which is absurd
[01:44] <penguin42> nod
[01:44] <sarnold> a full sync(2)?
[01:44] <sarnold> or fsync()?
[01:44] <penguin42> psusi: It's not the only thing though; firefox is insane as well - try running a live slow-write USB stick image and firefox, it crawls because of it's sync's
[01:44] <psusi> no, it tries to keep it limited with fsync or sync_memory_range, but still, it blocks until disk buffers, stripe caches, journals, hardware write caches, etc are all flushed
[01:45] <psusi> oh yea.. that also keeps laptop drives from sleeping
[01:45] <penguin42> which ends up blocking some entirely irrelevant read that means your GUI grinds to a crawl
[01:46] <cjwatson> You should get mad at the filesystems that made all this necessary; dpkg didn't introduce any of this until compelled
[01:46] <cjwatson> This is all pretty clear if you check the history
[01:46] <psusi> that's not quite true.. it got worse because of the issue uncovered in ext4
[01:46] <psusi> but it was always fairly bad
[01:46] <cjwatson> If that was so, it wasn't due to sync
[01:47] <sarnold> cjwatson: that's tytso's fault, right? :)
[01:47] <psusi> iirc, it always fsynced the status file after every package status change, so for each package, it unpacks, writes unpacked status, fsyncs status file, then configures, writes status, fsyncs status again
[01:48] <psusi> but it got worse with ext4 because it was using rename to atomically replace the old file with the new on upgrade, and in the case of ext4, it can commit the rename prior to the new file actually hitting the disk
[01:48] <psusi> and ttyso thinks this is not a bug and told dpkg maintainers to fsync the new file prior to the rename...
[01:49] <psusi> imo, that was bullshit.. ext4 should make the journal commit for the rename dependant on the flush of the original file to maintain proper atomic replace semantics
[01:49] <psusi> but even without the fsync on the new data file, dpkg still has multiple syncs per package
[01:50] <psusi> just for the status file
[01:50] <cjwatson> the status file is important :)
[01:50] <YokoZar1> psusi: I remember slangasek mentioning that either the dpkg or apt maintainer wouldn't accept any Ubuntu-originated patch of any kind, I can't remember which one.
[01:50] <cjwatson> YokoZar1: nonsense
[01:50] <cjwatson> there's some of that elsewhere but it's not in dpkg or apt.
[01:51] <YokoZar1> *by that I mean "ubuntu-committed before filed upstream"
[01:51] <YokoZar1> I think
[01:51] <cjwatson> I know who you mean but he maintains neither dpkg nor apt and never has.
[01:51] <penguin42> it strikes me the problem is a lack of API for dpkg or anything else to state the ordering requirements it actually needs, and so is left with a rather blunt weapon of fsync
[01:51] <psusi> dpkg should have the brains to unpack multiple new packages to temp files, update the status file with *multiple* updates, then fsycn it once, then do the atomic renames all in one batch
[01:52] <psusi> that is to say, if the filesystem is too brain damaged to just make the rename journal commit depend on flushing the new file
[01:52] <YokoZar1> cjwatson: ? I'm not saying slangasek maintains those packages, rather that I think he was making a statement about the maintainer of them
[01:52] <cjwatson> YokoZar1: And you've misattributed it.  He quite probably made that statement because Joey has said such a thing, but it was not about the maintainer of either dpkg or apt.
[01:52] <YokoZar1> ahh ok
[01:53] <YokoZar1> I don't actually know the people involved, to my detriment
[01:53] <cjwatson> There have been many, many Ubuntu-originated patches in both dpkg and apt, many of which have been in Ubuntu first.
[01:53] <psusi> penguin42, that has been the general concensus... but nobody has put forward such an api... and it seems to me that the big thing dpkg needs, aside from batching commits to the status file, is for atomic renames to work properly, which means ext4 needs to make the journal commit depend on flushing the new temp file, which ttyso doesn't seem to think it should
[01:53] <YokoZar1> So I wouldn't have to worry about stepping on some political minefield were I to decide to fix this particular problem
[01:53] <cjwatson> No
[01:54] <penguin42> psusi: What does Posix say?
[01:54] <psusi> posix doesn't say anything about journals... it only says that the rename is atomic, so you should either get the old file or the new file
[01:55] <penguin42> psusi: well there you go, until someone defines an API with a stronger constraint he's right - but annoying, but right
[01:55] <psusi> ttyso seems to think that ext4 satisfies this because you do either get the old file or the new file thanks to the journal transaction... the problem is that the new file might be empty because it wasn't flushed first
[01:56] <psusi> imho, it goes with the "spirit" of the concept that you either the old or new to make sure that you don't get new until after any pending writes to new are themselves flushed
[01:56] <cjwatson> YokoZar1: but if you're going to do so, you get to read through the several hundred pages' worth of bug reports that have led to the current state first, to avoid reinventing previous mistakes :)
[01:56] <cjwatson> shouldn't be too hard to track them down through the dpkg changelog
[01:57] <psusi> the ext4 file thing won't be solved unless ext4 is patched to make the rename transaction depend on flushing the writes to the new file first
[01:57] <psusi> but dpkg damn well can and should batch up multiple packages into one status file flush
[01:58] <psusi> instead of flushing the status file twice per package
[01:58] <cjwatson> Please take this somewhere more appropriate
[01:58] <cjwatson> You've made your point :)
[01:58] <cjwatson> I can't say I agree with you but the dpkg developers would be much better people to respond
[01:59] <cjwatson> So if you want to press this, -> bug report on dpkg in Debian
[01:59] <psusi> at this point I'm trying to just patch debootstrap to use libeatmydata to bypass the dpkg stupidity, at least for new installs ;)
[01:59] <psusi> since that is what the dpkg devs suggested last time I brought this up to them
[01:59] <penguin42> psusi: Yeh that makes a lot of sense; you just don't care about the state of your debootstrap'd world until it's complete
[01:59] <YokoZar1> cjwatson: I'm more poking at the apt resolver rather than dpkg here.  I dont' think we have a lot of automated test cases for that.
[02:00] <psusi> yea... if a new install is interrupted, who gives a shit?  it's trash anyhow... ;)
[02:00] <cjwatson> New installs (at least via d-i) already use --force-unsafe-io, which deals with most of it
[02:00] <psusi> that only deals with part of it, and actually, I'm pretty sure it DOESN'T do that because I was just adding that switch to it today
[02:01] <cjwatson> Feel free to look in base-installer for yourself if you don't believe me.  Note that I said via d-i, not specifically debootstrap.
[02:01] <psusi> specifically, that deals with the part where it now flushes each individual file before the rename due to the ext4 bug
[02:01] <psusi> still a lot of fsyncs to the status file
[02:01] <psusi> d-i uses cdebootstrap doesn't it?
[02:01] <cjwatson> Hell no.
[02:01] <psusi> oh?
[02:01] <cjwatson> We're not insane.
[02:02] <psusi> I read today that cdebootstrap is what d-i uses so I was looking into patching that to use libeatmydata too after making debootstrap do it
[02:02] <cjwatson> You read wrong.
[02:02] <cjwatson> cdebootstrap is essentially a playground and its only useful differential feature was obsoleted by debootstrap something like eight years ago
[02:02] <psusi> so... d-i uses regular deboostrap?
[02:02] <cjwatson> And it's never been configured properly for Ubuntu as far as I know
[02:03] <cjwatson> Yes
[02:03] <cjwatson> I don't expect that to change
[02:03] <psusi> that explains some things.. I was wondering why I kept getting errors running cdebootstrap
[02:03] <cjwatson> Given that the d-i team maintains debootstrap
[02:03] <cjwatson> I mean, base-installer will prefer cdebootstrap if it's available, but it basically never is in the d-i context :)
[02:04] <psusi> not sure what the error was for sid, but for ubuntu, it was that initramfs-tools uses awk in its preinst, and at the time, mawk has not been configured so the awk -> mawk alternate symlink has not been set up
[02:04] <cjwatson> So that's basically just so that you can add cdebootstrap-udeb to your image if you're strange
[02:04] <psusi> debootstrap seems to have a hack to manually create that symlink but cdebootstrap doesn't
[02:04] <cjwatson> Yes, because debootstrap understands that hacks are needed sometimes
[02:04] <xnox> psusi: "<psusi> [01:03:13] hrm.. looks like ntfs-3g has ABI upstream ABI breakage" care to elaborate? =)
[02:06] <xnox> psusi: never mind, found your bug.
[02:07] <cjwatson> That's not the only place where cdebootstrap is wrong - it has insufficient handling of base-files/base-passwd too, last I checked
[02:07] <psusi> xnox, see bug #1126547 for details... basically it looks like upstream went from major lib rev 835 to 84, so they aren't doing lib versioning right
[02:07] <psusi> cjwatson, well, that's good to know that patching debootstrap is sufficient to speed up installs
[02:07] <cjwatson> Eh, nothing says sonames have to be ordered
[02:07] <psusi> debian policy re lib versions
[02:08] <cjwatson> exact citation please
[02:08] <psusi> there is quite a lot of material I don't happen to remember eactly where it is now, but i know it's the reason that libparted has a -debian0 in its version
[02:09] <cjwatson> No, that was a special case
[02:09] <psusi> and I think it was you that tried to explain that one to me
[02:09] <cjwatson> I introduced that and I know why it was, and it's not the same situation
[02:09] <cjwatson> It was because of a soname *clash*
[02:09] <psusi> special case because upstream libparted versioning was broken.. i.e. they didn't maintain ABI comatability for each SONAME
[02:09] <cjwatson> Well, no, it was more complex than that
[02:09] <cjwatson> Anyway, it's different
[02:09] <cjwatson> We don't need to consider it
[02:10] <cjwatson> There's nothing wrong with upstream deciding to go from 835 to 84, as long as there wasn't previously an 84
[02:10] <cjwatson> Debian policy only says that the soname must change
[02:10] <cjwatson> If you think otherwise the burden's on you to provide an exact quote
[02:10] <psusi> sure there is... libtool specifications... major number means ABI compatability... same major number means backward compatabile
[02:10] <xnox> and the soname was changed.
[02:11]  * xnox looks at depends generated.
[02:11] <cjwatson> libtool specifications aren't policy
[02:11] <cjwatson> they're one particular implementation that happens to satisfy policy when used correctly
[02:11] <xnox> (but something  to bash upstreams with, as far as I recall correctly)
[02:11] <slangasek> libtool specifications are a special sort of madness
[02:12] <cjwatson> what matters is that the soname changes; anything that is doing any kind of ordering comparisons on sonames other than equality is ipso facto broken
[02:12] <cjwatson> and I am not aware of any such thing other than in package-local build systems
[02:12] <psusi> well, I suppose it is theoretically possible to go backwards, but obviously upstream meant for 84 to be a greater but backward compatible to 835
[02:13] <cjwatson> Generally upstream ntfs-3g changes its soname basically every release, and reverse-dependencies need to be rebuilt
[02:14] <cjwatson> I don't think it's at all obvious that they intended backward compatibility at the binary level; in fact I think it's just false
[02:14] <psusi> ohh... hrm... so let me see... ok.. so the major/SONAME has changed it looks like... so why does the package satisfy the dependancy of testdisk?
[02:14] <cjwatson> Now, ntfs-3g used to have a libntfs-3g-blah package
[02:15] <cjwatson>   * Removing libntfs-3g library package and folding it into ntfs-3g
[02:15] <cjwatson>     itself as there's not much point in micro-packaging here (nobody
[02:15] <cjwatson>     except ntfs-3g uses the shlib anyway, upstream bumps soname with
[02:15] <cjwatson>     almost every release and going through NEW is annoying).
[02:15] <cjwatson> ntfs-3g 1:2011.4.12AR.3-2
[02:15] <cjwatson> So I think the claim there is essentially that the reverse-dependencies are broken
[02:15] <cjwatson> This has absolutely zero to do with upstream ABI handling
[02:15] <psusi> ok, so it *is* a packaging error in ntfs3g?
[02:16] <cjwatson> Either it's an argument to be had with the Debian maintainer of ntfs-3g to reintroduce the separate library package for the benefit of testdisk, or testdisk needs to stop using what is currently being treated as a private library
[02:17] <psusi> I could have sworn I read somewhere that this is basically upstream being stupid and debian has to deal with it by carefully packaging it with a -debianX version in its SONAME to make sure that packages depending on it don't think that they can be satisified with a new upstream release
[02:17] <xnox> or .shlibs should be much tighter to generate tigher reverse-depends
[02:17] <cjwatson> psusi: No, entirely wrong.
[02:17] <psusi> what you said seems to be the same thing that I did in different words? ;)
[02:17] <cjwatson> -debianX SONAMEs are for extremely specialised and fraught cases and are very much not a good idea if you can possibly avoid it.
[02:18] <cjwatson> I didn't say at all the same thing as you.
[02:18] <slangasek> well, it's at least an ntfs3g bug for providing a .shlibs if the intent is that the library be internal
[02:18] <cjwatson> And note that libparted does *not* have a debianX SONAME
[02:19] <cjwatson> So that's not a valid example
[02:19] <slangasek> shlibs is a declaration that "if you link against this library, you should use this dependency"
[02:19] <slangasek> this is incompatible with "if you link against this library, go jump in a lake of molten lava"
[02:19] <cjwatson> slangasek: Yeah, that much is an ntfs-3g bug one way or the other
[02:19] <cjwatson> It could be improved slightly by making the shlibs have tight versioning, as a compromise
[02:19] <cjwatson> I don't know that it's what I'd do, but it would at least have caused this to be caught by proposed-migratio
[02:19] <cjwatson> n
[02:20] <psusi> right, so ntfs-3g should have a .shlibs so that testdisk can link to the proper version, even if that means it needs to change with every new ntfs-3g release
[02:20]  * xnox wants to use dh_makeshlibs -V
[02:20] <cjwatson> -V isn't quite right; it also needs << next-upstream
[02:21] <cjwatson> Or something
[02:21] <cjwatson> Actually, I don't know why ntfs-3g doesn't just use Provides for this
[02:21] <psusi> though really, ntfs-3g /shouldn't/ be breaking ABI on every release, but if it is going to do that sillyness, the packaging should at least make sure testdisk requires that specific version of testdisk, and not a newer, not backward compatible one
[02:21]  * xnox building to see what it will generate and weather that will help or not....
[02:21] <cjwatson> It won't, it'll be >= current-upstream
[02:22] <cjwatson> Provides: libntfs-3g84; .shlibs => libntfs-3g 84 libntfs-3g84
[02:22] <cjwatson> Would make this work, perhaps with some extra care to avoid a self-dependency via the new virtual package
[02:22] <psusi> right... and that should cover it as long as the major number is part of the debian package version, which it seems it used to be, and then they removed it
[02:22] <cjwatson> And that way it would also avoid Daniel's concern about going through NEW
[02:23] <xnox> Oh, that's neat.
[02:23] <cjwatson> It's a bit curious and it doesn't permit coinstallation of different version
[02:23] <cjwatson> But maybe it's a workable compromise that Debian would take
[02:24] <cjwatson> Ah, testdisk depends on the old libntfs in Debian
[02:24] <cjwatson> That's probably why Daniel hasn't noticed the problem
[02:24] <cjwatson> I changed it to build against ntfs-3g so that we could drop the deprecated libntfs-dev
[02:25] <cjwatson> I'm pretty sure Daniel wants to kill libntfs with fire, so I can see him being receptive to this plan
[02:25] <psusi> basically ntfs-3g should ship the libs in a binary package named for example, libntfs-3g-835, and that is what testdisk or other dependencies should depend on, thus it is coinstallable and not backward compatbile from libntfs-3g-40
[02:26] <cjwatson> I quoted the reason in the changelog why it doesn't; I don't necessarily find it productive to go head-on against a Debian maintainer's convenience-to-self argument when there's another workable possibility available
[02:26] <psusi> if it really is supposed to be a private library, then it should be statically linked to by ntfs-3g and not provided in /usr/lib shouldn't it?
[02:26] <cjwatson> It's not ideal for various reasons (well, one, mostly) but it would do well enough given that it doesn't matter desperately if testdisk doesn't work at all points during an upgrade - it doesn't have to behave as if it's Essential
[02:27] <cjwatson> And I can understand Daniel's wish to not have to deal with frequent NEW processing for a library that changes SONAME a lot
[02:28] <cjwatson> So offering him something that will improve matters without making things much less convenient for him seems likely to be a good approach at least for the time being
[02:28] <cjwatson> You are correct from a purist point of view but it isn't vitally critical to be purist here
[02:32] <Atlantic777> I'm reading ubuntu packaging guide and other wiki pages for beginners in ubuntu development and I'm not sure how (actually) where you do development. I mean, I don't want to ruin my system for everyday work. Do you use virtual machines, chroot or separate physical machines for development?
[02:32] <Atlantic777> Or it is safe to start playing on my system for everyday work? :)
[02:32] <psusi> so you are saying there is a way for ntfs-3g to export a shilbs such that testdisk will require == that version of ntfs-3g rather than >=, so that at least if there is temporary breakge that requires rebuilding testdisk, it will show up as a dependancy that can't be resolved, rather than a lib that can't be found at runtime?
[02:33]  * psusi uses one machine and fixes it on the rare occasion things go tits up
[02:35] <sarnold> Atlantic777: chroots for building are superb, they help prevent unintented dependencies from creeping in
[02:35] <cjwatson> psusi: I'm following up to the Debian bug
[02:35] <sarnold> Atlantic777: and virtual machines for testing are superb, you can roll them back to a known pristine state without much hassle, do what you want, then blow them away again, without any consequences
[02:35] <cjwatson> And yes - furthermore doing it that way would have kept the new ntfs-3g in raring-proposed out of users' sight until it was resolved
[02:37] <psusi> cjwatson, wait, you mean because it wouldn't be allowed out of -proposed until the dependency breakage was resolved?
[02:38] <psusi> hrm... cool.
[02:40] <cjwatson> Correct
[02:43] <cjwatson> For the record: the issue with libparted was that upstream switched to libtool's versioning system and thereby reused a SONAME that was used for a few months back in 2000.  In practice I think it is unlikely that that would cause any real problems, and I can certainly see why upstream was entirely unbothered by the possibility (if they even realised).
[02:43] <cjwatson> However, because that SONAME had been around ages ago, some of parted's binary packages had a historical Conflicts: libparted0 lying around
[02:44] <cjwatson> And it turned out to be extremely difficult to deal with that in a way that didn't cause upgrade problems: https://bugs.launchpad.net/ubuntu/+source/parted/+bug/535368
[02:44] <cjwatson> So I renamed the binary package from libparted0 to libparted0debian1, WITHOUT changing the upstream SONAME which would have been a dangerously incorrect thing to do, purely in order to resolve the upgrade problem
[02:45] <cjwatson> (There's still a libparted0 dummy package for convenience, but it doesn't interact with upgrades any more)
[02:47] <cjwatson> If there hadn't been Conflicts against libparted0 still lying around, it really wouldn't have mattered a jot that upstream decided to go from 2.1 to 0
[02:48] <psusi> cjwatson, so I'm glad cdebootstrap isn't actually used by the installer, because it means it just requires libeatmydata to be MIR, which I filed a bug for and got approval of today, and a two line patch to debootstrap to make use of it.. but... that just covers part of the install doesn't it?  it d-i uses debootstrap to install required, and important packages, but then invokes dpkg to install the standard seed separately right?
[02:48] <cjwatson> Sure
[02:49] <cjwatson> In lots of different places which I'm not at all wild about patching independently
[02:49] <psusi> so somewhere in d-i it needs to set up the LD_PRELOAD for libeatmydata for all of those dpkg invocations... hrm...
[02:49] <cjwatson> Yeah, that's not happening.  Get a --force-foo option in dpkg for it instead
[02:49] <psusi> ohh?  why?  I tried that two years ago and it was rejected
[02:49] <cjwatson> That way it can be set in dpkg.cfg
[02:50] <psusi> the dpkg maintainers didn't like the idea of another --force option that could be set in dpkg.cfg
[02:50] <cjwatson> And this d-i maintainer doesn't like the idea of patching dozens of dpkg calls separately
[02:51] <psusi> should be sufficient to just make sure the LD_PRELOAD environment variable is set in whatever process invokes dpkg... or somewhere up the hierarchy
[02:51] <cjwatson> There are many and they are not in a strict hierarchy
[02:51] <cjwatson> It's not practical in d-i AFAICS
[02:51] <psusi> whatever the highest process is then ;)
[02:51] <psusi> should be inherited by all children without harm
[02:51] <cjwatson> That would be actively harmful because of chroots
[02:51] <cjwatson> So no, please trust me that I have some clue what I'm talking about here ...
[02:52] <psusi> eh?
[02:52] <cjwatson> The highest process is operating in the installer environment where libeatmydata wouldn't exist
[02:52] <psusi> that's fine... then no harm
[02:52] <cjwatson> And in any case the highest process is a generic menu process which has absolutely no business knowing about this
[02:52] <cjwatson> So no
[02:52] <psusi> listing a non existing library in LD_PRELOAD doesn't seem to cause any harm
[02:53] <psusi> it's just silently ignored
[02:53] <cjwatson> I'm not complicating main-menu for this
[02:53] <cjwatson> It's simply the wrong place
[02:53] <psusi> that's why wrapping debootstrap in eatmydata wasn't enoguh, because it runs dpkg in a chroot and in the chroot, it didn't have the lib, so it was ignored
[02:55] <psusi> one of the problems they mentioned on dpkg-devel with adding it as a --force option is that it would only affect dpkg, not any of the scripts it calls... so they said it should just be added to the caller of dpkg... and rather than patch every dpkg call, it seems easy enough to just add it to one place, high up in the call tree
[02:55] <cjwatson> It's not easy.
[02:55] <psusi> why?
[02:55] <cjwatson> I give up.
[02:56] <cjwatson> Sorry, don't have the energy for this.
[02:56] <psusi> it's just setting an environment variable that all children will inherit... if the installing environment doesn't have the lib, it just gets ignored
[02:57] <cjwatson> It is necessary to learn how d-i is laid out before proposing modifications to it
[02:58] <cjwatson> It does not have the structure you seem to think it has
[02:59] <cjwatson> The only possible place I can think of for this would be in-target (and friends)
[03:00] <psusi> afaiui, the structure is that there are a bunch of scripts that run in the installer, and eventually chroot into /target and run dpkg... at that point is where you want the LD_PRELOAD set.. but if it is also set in the calling environment, it will just be ignored
[03:00] <cjwatson> In debian-installer-utils
[03:01] <cjwatson> It's still pretty delicate though; that doesn't use debconf and probably can't without breaking hand-rolled preseed scripts, so some alternate means of configuring it would need to be devised
[03:01] <psusi> configuring it?
[03:02] <cjwatson> You need a much better understanding than "a bunch of scripts" - it has a fairly clear architecture and there's documentation on it and everything
[03:02] <cjwatson> Configuring in-target to use eatmydata where appropriate
[03:02] <psusi> I'd love to read documentation on it, but what's the harm in setting the variable as high as you can unconditionally, and letting it trickle down to where it matters?
[03:03] <cjwatson> It's not going in main-menu, end of story
[03:03] <psusi> why?
[03:03] <cjwatson> But it's possible that it could go in in-target, which would probably cover most of the requirements
[03:04] <cjwatson> There'll probably still be some things that chroot manually
[03:04] <cjwatson> But a distinct minority
[03:04] <psusi> chroot into /target you mean?
[03:04] <cjwatson> Yes
[03:04] <psusi> and?
[03:05] <cjwatson> Since in-target is what deals with such things as debconf passthrough and lots of stuff ends up caring about that
[03:05] <cjwatson> So in practice the big bulk package installations happen via in-target
[03:05] <psusi> you think there may be other cases that chroot into /target that should NOT use libeatmydata?
[03:05] <cjwatson> I don't think it matters
[03:05] <cjwatson> I mention it merely for completeness
[03:05] <cjwatson> Now I wish I hadn't
[03:06] <cjwatson> Because I don't deal very well with a full congressional grilling at 3am I'm afraid
[03:07] <psusi> lol... I'm just trying to figure out where having libeatmydata set in the environment would be UNdesirable
[03:08] <cjwatson> It would probably be OK in in-target and that would deal with enough of your cases that I'm confident you wouldn't care about the odd leftover
[03:08] <psusi> I"m sure it would too.. I'm not not sure why you object to setting in in the environment in a broader sense
[03:09] <cjwatson> I object to putting anything at all in a small and simple program like main-menu that doesn't absolutely have to be there
[03:10] <cjwatson> This doesn't absolutely have to be there
[03:10] <sarnold> psusi: could you set it _before_ calling main-menu?
[03:10] <psusi> I suppose it doesn't, it just seems a hell of a lot easier to set an environment varible one time, there, rather than every time in-target is called
[03:10] <cjwatson> Er, no - in-target is a script
[03:10] <cjwatson> I'm suggesting you put the variable setting in that one script
[03:11] <psusi> hrm... ok
[03:12] <psusi> for that matter, I was wondering... are the packages copied from the cd to /target first, then chroot into /target to run dpkg to install them?  it looks like that may be the case and that seems wasteful
[03:12] <psusi> rather than just running dpkg with --root=/target from the install cd
[03:13] <cjwatson> We use the apt cdrom method
[03:13] <cjwatson> Which AFAIK doesn't bother copying
[11:13] <jamespage> !regression-alert
[11:13] <jamespage> bug 1125611
[11:14] <jamespage> SRU for openvswitch for 3.5 kernel in 12.04.2 breaks brcompat module for 3.2 kernel
[11:14] <jamespage> confirmed; looking into fix now
[11:14] <jamespage> brcompat: module license 'unspecified' taints kernel.
[11:34] <Malsasa> Hello, how to package .run in Ubuntu?
[12:23] <JanC> Malsasa: maybe #ubuntu-packaging is a better place to ask that (but if by .run you mean an install script, that's probably not the best source to make a package from if there is another choice)
[12:38] <Malsasa> JanC: ooooh, i dont know there is a channel named packaging :) Thank you....
[17:10] <bdrung> doko__: i used lintian to verify that the warning are gone. "using debhelper 9 to pass hardening flags" might be more descriptive.
[17:41]  * tumbleweed wonders why our nvidia packages now Provide fglrx
[17:43] <infinity> tumbleweed: Overexhuberant copy and paste between Replaces, Conflicts, and Provides, I'd guess.
[17:45] <tumbleweed> we also have an nvidia-current transitional binary package, which is fairly useless when all the nvidia-XXX packages conflict with it
[17:46] <tumbleweed> or is it still useful to help apt with upgrades?
[17:53] <infinity> tumbleweed: Yeah, I haven't looked into how it all works (or doesn't).  Feel free to tackle tseliot at some point and refine his packaging, though.
[17:55] <tumbleweed> heh. the breakage of the cuda stack because of incompatibilites between Debian & Ubuntu's approach to nvidia drivers has annoyed me for a while, but it seems that we are still on divergent paths
[18:25] <ejat> bug 1127404
[18:25] <ejat> can someone help me on that ..
[19:07] <slangasek> ejat: only one of these packages is in Ubuntu.  Whatever your libqt5multimediaquick5 package is, you'll want to remove it by hand from your system.
[19:08] <ejat> slangasek: ok thanks .. there is discussion about this on #ubuntu-phone .. they notice the issues ..
[20:24] <pavolzetor> hi guys, how do I know that notification is being displayed?
[20:24] <pavolzetor> so I do
[20:24] <pavolzetor> not = Notify.Notification.new('test', '', '')
[20:24] <pavolzetor> not.show()
[20:25] <pavolzetor> and I need to know if notification is sitll on screen (so program will not show next one)
[20:26] <pavolzetor> does it emit some sginal that it was hidden from screen?
[20:47] <pavolzetor> is there any way to get default timeout or something like this?
[20:50] <xnox> folks on #ubuntu-app-devel or #ubuntu-unity might now the api better. As far as I understand there is no way to query if it's on the screen or off the screen. as it could be queued behind other notifications
[20:51] <xnox> and a user can be fading it in and out by hovering over it, and thus preventing it from timing out
[20:51] <xnox> pavolzetor: better question is why do you need to know if it's displayed or not?
[20:51] <xnox> and what are you trying to achieve
[20:52] <pavolzetor> xnox: I am updating my feed reader
[20:52] <pavolzetor> so when new articles arrives
[20:52] <pavolzetor> model updated -> notification object listens and display notification
[20:52] <pavolzetor> but it can update many times
[20:52] <pavolzetor> but I want to show only one notification for 100 items
[20:53] <xnox> one can set the ID on the notification (or something like that) and if you push a new notification with the same ID it will either update the existing bubble, or create/show a new one.
[20:54] <pavolzetor> ahh, cool ;)
[20:54] <xnox> thus fire all 100 items and users will get a popup with grown numbers of "28 new items"
[20:54] <pavolzetor> I will do that
[20:54] <xnox> pavolzetor: check the API docs.
[20:54] <pavolzetor> but when does the notification disappears
[20:54] <pavolzetor> ?
[20:54] <xnox> "after some time"
[20:54] <pavolzetor> I mean if it disappears, you might want start from 0
[20:55] <xnox> fire notifications every time you have new items.
[20:55] <pavolzetor> I do not want to show count there (it will be on badge), okay
[20:55] <xnox> you will be rate limitted if it's too much, and generate the new ID for each batch.
[20:56] <pavolzetor> I see
[20:56] <pavolzetor> okay, thanks ;)
[20:56] <xnox> e.g start poll -> generate notification id -> push out notifications -> stop
[20:56] <pavolzetor> start poll?
[20:57] <xnox> (start whatever you do to walk all the feeds and get new articles thingy....)
[21:10] <pavolzetor> "0
[21:10] <pavolzetor> :)
[21:10] <pavolzetor> cheers
[21:10] <pavolzetor> also
[21:10] <pavolzetor> one thing
[21:10] <pavolzetor> why does not badge show up ?
[21:11] <xnox> pavolzetor: check with #ubuntu-unity or #ubuntu-app-devel
[21:11] <pavolzetor> okay ;)
[21:11]  * xnox never coded against notification api, btw =)
[21:11] <pavolzetor> me neither ;)
[21:12] <pavolzetor> I got it, but I rewrote it using MVC
[21:12] <pavolzetor> and fixed a lot things
[21:12] <xnox> and also this channel is not fully appopriate to discuss these things. Folks here are mostly devel ubuntu core operating system.
[21:12] <pavolzetor> and now I am splitting code to classes
[21:12] <xnox> refactoring is always good
[21:12] <pavolzetor> http://bazaar.launchpad.net/~floaty-devs/floaty/trunk/revision/92
[21:12] <pavolzetor> this commit
[21:13] <pavolzetor> Ahh I see
[21:13] <pavolzetor> will go to correct room ;)
[21:14] <xnox> #ubuntu-app-devel is for developing on/for/against ubuntu
[21:14] <pavolzetor> what I miss are some guidelines and help with gnome stack development, like that my MVC, I am not sure if I did it right way
[21:14] <pavolzetor> cool
[21:14] <pavolzetor> thanks for your time


[10:33] <Chipaca> hi everybody
[10:34] <Chipaca> my touchpad's stopped scrolling a couple of days ago
[10:34] <Chipaca> known issue, or should i report it?
[10:35] <Chipaca> ah! chrisccoulson refers me to bug #1041594
[10:35] <Chipaca> thanks
[11:17] <shadeslayer> what was the command that allowed me to check what was using up alot of X's memory?
[11:29] <jcristau> xrestop
[11:43] <tjaalton> Chipaca: thanks, was wondering about that myself..
[11:53]  * shadeslayer installs to check what's hogging all his memory again
[11:54] <shadeslayer> bleh, kwin taking 5220256K
[14:04] <tjaalton> seb128: you tagged bug 1031784 with regression-proposed, because of the irrelevant comment by bluedream?
[14:05] <seb128> tjaalton, I didn't tag it regression-proposed? I just dropped the rls-q-incoming tag because it's dealt with
[14:05] <tjaalton> ah
[14:05] <tjaalton> hum, well I closed it for quantal too, it's done :)
[14:06] <tjaalton> maybe that tag is automatic for updates
[17:26] <tjaalton> someone has not pushed the ubuntu-precise branch of -synaptics
[17:26] <tjaalton> and that someone is on vacation :)
[17:27] <bryce> heh
[17:27] <tjaalton> I'll add a patch that fixes bug 956071
[17:31] <tjaalton> only s/UNRELEASED/precise-proposed/ missing, so not an issue really
[17:52] <tjaalton> yeah.. the patch works
[20:23] <tjaalton> RAOF: unless -synaptics for precise-proposed has passed the queue once you start your day, could you give it a gentle nudge so people can have less crashes :)


[09:27] <rmg51> Morning
[12:18] <teddy-dbear> Morning peoples, critters, dumb birds and everything else
[12:19] <teddy-dbear> and a special shout out to all the "workship" peoples :-D
[12:27] <waltman> workship?
[12:29] <teddy-dbear> read jedijf email
[12:31] <waltman> ah!
[14:12] <jedijf> i corrected in reply
[14:12] <jedijf> all this fosscon at sea talk
[18:00] <JonathanD> Hi.


[01:57] <KGB-2> epiphany-browser ubuntu/jammy 8c95209 Jeremy Bicha . * branch deleted
[01:57] <KGB-2> epiphany-browser tags ffb36cf Jeremy Bicha ubuntu/42.0-2ubuntu1 * tag deleted
[06:21] <jpnurmi> good morning
[06:21] <duflu> Hi jpnurmi
[06:21] <jpnurmi> hey duflu
[06:42] <KGB-0> gnome-control-center signed tags 6d5b902 Marco Trevisan ubuntu/1%41.4-1ubuntu12 * gnome-control-center Debian release 1:41.4-1ubuntu12 * https://deb.li/ilLvs
[07:27] <oSoMoN> good morning desktoppers
[07:29] <jpnurmi> hey oSoMoN
[07:29] <oSoMoN> hey jpnurmi
[07:33] <didrocks> salut oSoMoN
[07:34] <didrocks> hey jpnurmi, duflu
[07:34] <jpnurmi> hey didrocks
[07:34] <duflu> Hi oSoMoN and didrocks
[07:35] <oSoMoN> salut didrocks, hey duflu
[10:31] <ricotz> hello everyone
[10:34] <oSoMoN> hi ricotz
[11:59] <KGB-2> mutter pristine-tar 58ad81e Simon McVittie mutter_41.4.orig.tar.xz.delta mutter_41.4.orig.tar.xz.id * pristine-tar data for mutter_41.4.orig.tar.xz * https://deb.li/iiR7j
[11:59] <KGB-2> mutter pristine-tar e8ef9d0 Simon McVittie (8 files) * Merge remote-tracking branch 'origin/pristine-tar' into pristine-tar * https://deb.li/jpNA
[12:14] <jbicha> good morning
[12:17] <KGB-2> gnome-connections upstream/latest d07973b Felipe Borges subprojects/gtk-frdp * rdp: Handle non-char keyboard input * https://deb.li/3lp1I
[12:17] <KGB-2> gnome-connections upstream/latest 6ce30d5 Felipe Borges NEWS meson.build * Release 42.1.2 * https://deb.li/GoFE
[12:17] <KGB-0> gnome-connections pristine-tar 8e6f0eb Jeremy Bicha gnome-connections_42.1.2.orig.tar.xz.delta gnome-connections_42.1.2.orig.tar.xz.id * pristine-tar data for gnome-connections_42.1.2.orig.tar.xz * https://deb.li/nRdR
[12:18] <KGB-2> gnome-connections upstream/latest c60044f Jeremy Bicha (5 files in 2 dirs) * New upstream version 42.1.2 * https://deb.li/35tNe
[15:27] <KGB-2> gnome-shell Gunnar Hjalmarsson 305037 * commented merge request !61 * https://deb.li/3tpyA
[15:45] <GunnarHj> jbicha: Are we agreed that it would be too late to mess with translations for the updated sharing-desktop.page?
[15:52] <jbicha> GunnarHj: I'm ok with whatever you decide
[15:56] <GunnarHj> jbicha: Ack.
[16:27] <ricotz> schopin, hello :), did you have a chance to look into https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1968345 yet?
[16:27] <schopin> not yet, that'll be for tomorrow.
[16:28] <ricotz> schopin, ok, great, note that rustc needs to include a copy of the required llvm source, otherwise it won't be possible to backport it
[16:28] <ricotz> currently rustc in jammy isn't packaged like that yet
[16:28] <schopin> ricotz: don't we already backport LLVM for mesa ?
[16:28] <schopin> And kernel?
[16:29] <ricotz> schopin, not the one which is required by rustc afaik
[16:30] <ricotz> it might even include some custom patches, maybe contact mw_hudson for this
[16:30] <ricotz> schopin, e.g. bionic won't get llvm-14
[16:30] <schopin> nope, no patches
[16:31] <ricotz> schopin, https://github.com/rust-lang/llvm-project
[16:32] <schopin> I know, but as of 1 month ago they didn't need any specific patch.
[16:33] <ricotz> ok, I see
[16:33] <schopin> Technically the lowest LLVM needed right now is 12
[16:34] <schopin> They "just" default to vendoring 14.
[16:38] <ricotz> schopin, ok, still please include the llvm copy as done before, I am still building firefox for xenial on several requests
[17:06] <schopin> ricotz: dumb question: why do we need the updated version in jammy?
[17:08] <ricotz> schopin, thunderbird (and "custom" firefox deb ppa builds (trunk, esr, ...))
[20:22] <jbicha> tjaalton: hi, how are things going with the mesa egl fix?
[20:33] <tjaalton> jbicha: the review has stalled?
[20:34] <jbicha> tjaalton: should we cherrypick the proposed fix for jammy now anyway?
[20:34] <tjaalton> can do


[12:53] <mike00> hi all. How can I get the week day in a QML qmake app?
[12:59] <mike00> and I have a problem with qmake. it seems every project I create is corrupted: in the desktop file there is an underscore before the Name property (examples: "_Name=App") and when I execute the project on the phone a message saying "could not find Desktop file" appears... what can I do?
[13:00] <mike00> and I can't use image: I can see image on the pc but on the phone a message says me the image link isn't correct...
[13:01] <mike00> now I copy the desktop file in the "build-App-Ubuntu_Device_GCC_armhf_ubuntu_sdk_15_04_vivid-Debug/App" directory and it seems work
[13:01] <mike00> but if I copy image I can't see them
[13:35] <mike00> is there anybody that can help me please?
[14:22] <mike00> why in this channel there isn't anybody?
[14:23]  * ogra_ sees 133 people
[14:30] <mike00> 133 people in this channel and nobody can answer me???
[14:33] <ogra_> not everyone is looking at IRC all day :)
[14:33] <ogra_> (also ... see the channnel topic)
[14:40] <mike00> I'm trying to develop some app for ubuntu touch...
[14:40] <mike00> but the ubuntu sdk doesn't seems working very well
[14:42] <mike00> does the topic says to make apps? I'm trying to do it
[14:45] <kalikiana> mike00: It does. I think it was a hint to use appdevs to highlight folks
[14:47] <mike00> sorry kalikiana, I don't understand. I don't speak english very well...
[14:49] <kalikiana> If you use "appdevs" when asking for help, developers see that
[14:49] <kalikiana> It's like using a nickname, but for all who have enabled that word
[14:49] <ogra_> right, that is why i pointed to the channel topic :)
[14:49] <mike00> ok thanks
[14:50] <ogra_> ..."Use keyword "appdevs" to highlight developers if they're around."...
[14:52] <popey> mike00: maybe push a branch somewhere that we can see
[14:52] <popey> or zip it up or something
[14:54] <mike00> where can I upload a zip?
[14:56] <mike00> popey?
[15:02] <JanC> mike00: do you have web space provided by your ISP, or a service like Google Drive/Dropbox/similar?
[15:02] <mike00> Yes, I didn't think it. thanks
[15:04] <mike00> https://drive.google.com/open?id=0B2ohkzUDkoDRbVZYUUJ0S2p4QzA
[15:06] <mike00> appdevs, here is a new project I just create. as you can see, the untiled.desktop file as an underscore before _Name=untitled
[15:09] <popey> that _Name seems normal to me
[15:09] <popey> other apps do that
[15:13] <DanChapman> mike00, the _ is for translations.
[15:14] <mike00> ah thanks
[15:14] <mike00> but when I try to execute on the phone that project it says there is no desktop file...
[15:19] <mike00> appdevs, how can I do? there is the desktop file and on the pc the app run perfectly, but not on the phone...
[15:24] <mike00> appdevs: I copy the desktop file in build-untiled-Ubuntu_Device_GCC_armhf_ubuntu_sdk_15_04_vivid-Debug/untiled and now I can run the project on the phone. I don't think that's the right way to run the app..
[15:24] <popey> strange
[15:24] <popey> maybe bzoltan or zbenjamin can help?
[15:25] <bzoltan> mike00: I can help... but let me first figure out few things about your setup
[15:26] <bzoltan> mike00: 1) apt-cache policy ubuntu-sdk-ide
[15:26] <bzoltan> mike00: 2) what is the selected Kit
[15:26] <mike00> bzoltan: what can I tell you of the output?
[15:27] <mike00> http://pastebin.ubuntu.com/17145365/ the output of apt-cache policy ubuntu-sdk-ide
[15:28] <bzoltan> mike00:  3) what is the project type? cmake, qmake .pro or qmlproject?
[15:28] <mike00> bzoltan: qmake. I preffered qmlproject but it isn't supported...
[15:28] <bzoltan> mike00: 1) you have the right IDE installed :) first checkbox checked
[15:29] <mike00> bzoltan: I use Ubuntu Device (GCC armhf-ubuntu-sdk-15.04-vivid)
[15:29] <mike00> I reinstalled today the SDK...
[15:35] <mike00> bzoltan: the kit I use was created automatically when I connected the phone the first time...
[15:36] <bzoltan> mike00: That is fine
[15:37] <mike00> ok
[15:37] <bzoltan> mike00:  and you have the device plugged in, right?
[15:37] <mike00> yes
[15:37] <bzoltan> mike00:  and you have opened a template?
[15:38] <mike00> template?
[15:38] <mike00> sorry I didn't understand
[15:42] <mike00> I have the ubuntu SDK opened with a project opened
[15:43] <bzoltan> mike00:  I see the project... it is a clean template project you have created from the IDE. Is that correct?
[15:43] <mike00> bzoltan: what do you mean with template? I'm not English so I can't understand some things...
[15:44] <mike00> yeah. I create the project and then I published it, without editing it
[15:44] <bzoltan> mike00:  i am not English eaither :) no worries. So you have created the project with the IDE, right?
[15:44] <mike00> bzoltan: yes
[15:45] <bzoltan> mike00:  okey
[15:47] <mike00> bzoltan: but it isn't a big problem if I have to copy the desktop file. the  biggest problem is that the link to image that works on the pc, doesn't work on the phone: so I can't see images
[15:49] <bzoltan> mike00:  the desktop file should be placed by the build and package creation
[15:49] <bzoltan> mike00:  what image you do not see?
[15:50] <mike00> bzoltan: not in this project
[15:50] <bzoltan> mike00:  If you add a file to the project you need to make sure that the file is listed in the .pro
[15:51] <bzoltan> mike00:  like
[15:51] <bzoltan> CONF_FILES +=  untitled.apparmor \
[15:51] <bzoltan>                untitled.png
[15:51] <mike00> I didn't know it
[15:51] <mike00> bzoltan: where should I write it?
[15:52] <bzoltan> mike00:  open the .pro in the IDE and simple add the image file to the list
[15:53] <mike00> which list?
[15:53] <bzoltan> mike00: http://pastebin.ubuntu.com/17146084/
[15:54] <bzoltan> mike00:  hold on... correction comes :)
[15:54] <mike00> bzoltan: ok. I was looking into the wrong .pro file...
[15:54] <bzoltan> mike00:  like this http://pastebin.ubuntu.com/17146125/
[15:55] <mike00> Thanks very much bzoltan !!!
[15:58] <mike00> bzoltan but Now I have another problem with another project: when I click "run" on the sdk to run the project on the phone, the phone seems restart the system and the project isn't executed
[15:58] <mike00> https://drive.google.com/open?id=0B2ohkzUDkoDRVnZWeU1LRkhmeUE
[16:01] <mike00> bzoltan: i get this in the application output http://pastebin.ubuntu.com/17146309/
[16:02] <mike00> when the output arrive at "Sdk-Launcher> Communication directory: /home/phablet/.local/share/school.mymike/" on the phone appears the screen when it is switching on (the word ubuntu with the 5 points)
[16:03] <bzoltan> mike00:  Wow... that is a bug in the shell
[16:03] <bzoltan> mike00:  is that project what you uploaded?
[16:04] <mike00> it happend with both the projects
[16:05] <mike00> the untiled project was only an example
[16:06] <mike00> but I'm working on the school project, bzoltan
[16:07] <mike00> When I started working this afternoon I can execute the apps perfectly (copying the desktop file) but it's only now that the phone has started restarting itself, bzoltan
[16:08] <bzoltan> mike00:  let me check that app
[16:09] <mike00> ok
[16:11] <bzoltan> mike00:  I could start the application without problem.  But I am on a fairly new release of the Ubuntu touch
[16:11] <bzoltan> mike00:  I would suggest to update the phone and reboot. No idea what the trouble is. I am sorry for your experience
[16:13] <mike00> bzoltan: how can I update the phone? I have OTA 11
[16:13] <mike00> and I tried restarting the phone
[16:14] <aldrog> mike00, I had similar problem, solved by changing _Name to just Name in .desktop file
[16:14] <aldrog> not sure why it happened and what is the proper solution
[16:14] <aldrog> but it worked
[16:15] <mike00> thanks aldrog, I'll try
[16:16] <mike00> It works. thanks very much aldrog
[16:20] <aldrog> mike00, np :)
[16:21] <mike00> :-)
[16:27] <mike00> thanks to all (in particular aldrog and bzoltan). now my app work well with images :)
[18:24] <dpm> popey, quick question if you're around: do we have a fat package of Terminal, so that it can be installed on the unity8 desktop via the apps scope?
[18:25] <dpm> (if you're still around)
[18:33] <dpm> nm, I figured it out looking at the store: it seems we dropped the multi-arch package in the last 2 uploads, but the older click with amd64/x86 build should be available for desktop systems


[00:06] <JC-MythTV> I have a question... I'm a very long time mythTV (since version 0.6) user and currently run Ubuntu Hardy. I'd like to have mythbuntu manage things for me instead of having to keep on top of all the updates constantly. How difficult is it to convert an already installed myth to mythbuntu?
[00:14] <foxbuntu> JC-MythTV, very easy
[00:14] <foxbuntu> :)
[00:15] <foxbuntu> JC-MythTV, http://www.mythbuntu.org/existing-ubuntu
[00:15] <tgm4883_laptop> JC-MythTV, note that you still have to do updates, mythbuntu doesn't do updates for you
[00:18] <JC-MythTV> thats fine, what will that do with the existing database and configurations?
[00:18] <foxbuntu> JC-MythTV, upgrade if needed
[00:18] <a1fa_> hey adding gnome to mythbuntu wont screw anything up, will it?
[00:18] <a1fa_> ~gnome
[00:19] <foxbuntu> a1fa, nope, you may have to edit your session but it should still work
[00:19] <a1fa_> so apt-get install gnome?
[00:19] <foxbuntu> a1fa, actually there is an easier way
[00:19] <a1fa_> whats that?
[00:19] <JC-MythTV> ok, except for maybe some .21 fixes it should be up to date.
[00:20] <foxbuntu> JC-MythTV, nothing really then, its just going to add our stuff to your system
[00:20] <foxbuntu> a1fa, just one sec
[00:20] <JC-MythTV> ok, I've prepared the wife... just in case there's problems
[00:21] <tgm4883_laptop> a1fa, use MCC
[00:21] <tgm4883_laptop> well
[00:21] <tgm4883_laptop> unless you want just plain gnome
[00:21] <foxbuntu> a1fa, yeah, in System Roles just click Ubuntu desktop
[00:21] <tgm4883_laptop> ubuntu-desktop would install everything from a default ubuntu install
[00:21] <a1fa_> ok.. i want mythtv session to stay the same
[00:22] <tgm4883_laptop> if you don't want that then you need to install gnome by itself
[00:22] <foxbuntu> a1fa_, thats ok, just use MCC and select the Ubuntu Desktop role and apply, it will take care of everything then
[00:22] <tgm4883_laptop> either way, shouldn't mess up your session
[00:22] <a1fa_> cool
[00:22] <a1fa_> i see it
[00:22] <a1fa_> i knew i saw that somewhere
[00:22] <a1fa_> i am going to use xdmcp
[00:23] <a1fa_> computer is just idling 90% of time
[00:23] <a1fa_> if i enable diskless server it will allow me to connect thin clients?
[00:25] <foxbuntu> a1fa, yeah.... there is a little more setup to it than that, but yes
[00:25] <a1fa_> cool
[00:25] <a1fa_> :p
[00:28] <a1fa_> i have a 233mhz pos terminal i wanted to use
[00:29] <foxbuntu> haha
[00:29] <foxbuntu> you would be lucky to make that thing play standard video
[00:29] <a1fa_> i will use it to terminal to another box
[00:29] <a1fa_> :P
[00:31] <foxbuntu> oh...you should know that the diskless server is a modfied version of the LTSP project that is setup for Mythbuntu Thin clients only
[00:31] <a1fa_> i can revert it
[00:31] <a1fa_> can i ?
[00:31] <foxbuntu> it can be changed but that is what MCC is going to setup
[00:31] <JC-MythTV> it does PXE correct?
[00:31] <a1fa_> cool
[00:31] <foxbuntu> JC-MythTV, yes
[00:37] <JC-MythTV> are x64 diskless images supported yet?
[00:38] <tgm4883_laptop> JC-MythTV, yes
[00:38] <tgm4883_laptop> but not from 32-bit machines
[00:39] <JC-MythTV> ah
[00:40] <JC-MythTV> since I haven't done it before, how difficult is it to convert a machine to x64?
[00:40] <tgm4883_laptop> JC-MythTV, reinstall
[00:40] <JC-MythTV> thats what I was afraid of :(
[00:56] <a1fa_> ok
[00:57] <a1fa_> what does "capitalize" expense mean?
[00:57] <a1fa_> kind of unrelated :P
[00:58] <superm1> well there's other ways to do it
[00:58] <superm1> but they are quite crazy
[01:24] <tanstaafl32> good evening all--anyone have time for a question?
[01:24] <JC-MythTV> are you using atftp for PXE loading?
[01:42] <tanstaafl32> hey dustybin
[01:43] <dustybin> hey
[01:43] <dustybin> ive never used mythbuntu and ive never used your pvr card
[01:43] <dustybin> so its difficult for me to diognise your problem
[01:44] <tanstaafl32> i really think that i have an overall myth issue...but thanks for trying...
[01:44] <tanstaafl32> the recording files ought to be growing
[01:44] <dustybin> yes
[01:45] <tanstaafl32> hmm...i think i'll kill my detected myth cards and video sources and start again...i wasn't getting video at all when i first installed
[01:46] <dustybin> yes that might be a good idea
[01:47] <tanstaafl32> know anything about storage groups?  beyond being in /var and chmoding, is there any good guidance?
[01:50] <JC-MythTV> For PXE booting, what should the /etc/inetd.conf file look like?
[02:00] <dustybin> tanstaafl32: storage groups should be setup in mythtv-setup
[02:01] <dustybin> they are the locations of recordings, they can be anything you want
[02:01] <dustybin> JC-MythTV: http://www.mythtv.org/wiki/index.php/Diskless_Frontend
[02:03] <tgm4883_laptop> tanstaafl32, yea, don't stick them in /var
[02:07] <tgm4883_laptop> bah, where does mytharchive stick the iso it makes?
[02:09] <JC-MythTV> I need to rebuild the ramfs boot image that was built to include my network card driver. Do I just need to edit the modules in /opt/ltsp/i386/etc/initramfs-tools and run some script to rebuild it?
[02:11] <JC-MythTV> or is the image built from some other source and script
[02:17] <tgm4883_laptop> JC-MythTV, what do you mean to include your network card driver?
[02:18] <JC-MythTV> I need the sky2 driver in the ramfs or the kernel panics going to NBD or NFS
[02:18] <JC-MythTV> the initramfs
[02:20] <JC-MythTV> usually in the /etc/initramfs-tools directory you can add them in modules before you build the image
[02:21] <JC-MythTV> But I'm not sure which directory you are using and if you might have a script to rebuild the image
[02:36] <JC-MythTV> ok, I found the proper scripts... I had the correct file, just need to run: sudo chroot /opt/ltsp/i386 update-initramfs -u
[02:36] <JC-MythTV> and then ltsp-update-kernels
[02:37] <JC-MythTV> now onto the next roadblock ;)
[02:37] <tanstaafl32> anyone have a pvr-350?  i can get video in mplayer but nothing in myth
[05:09] <mungewell2> hi. I have an issue where starting an xterm from the xfce menu restarts X, I can start one by double click /etc/X11/bin/xterm in thunar....
[05:10] <mungewell2> any suggestion as to what might be screwed up?
[05:10] <hads> Interesting.
[05:11] <hads> Sounds like whatever is holding your X session open might be crashing.
[05:13] <mungewell2> hads: why would starting via thunar work in that case?
[05:13] <mungewell2> where the output from update-menus stored... I can't find it
[05:13] <hads> I don't use xfce sorry.
[05:14] <hads> I was thinking that maybe the action of clicking on the menu was crashing something that's holding your X session - just a guess though.
[05:15] <mungewell2> update-menus is a debian '1 size fits all' system for all of the window managers. Define apps once and it magically creates menus for different type of session...... somewhere.
[05:15] <mungewell2> only seems to xterm, other item open OK
[05:15] <hads> OK, well I don't use that either :)
[05:16] <hads> man update-menus shows some locations
[05:17] <mungewell2> only seem to the source locations. There is a xfce-method which does the final stage, but I don't know where it puts the result.
[06:17] <zippytech_> when i select media library then,watch recordings ,select recording options, then job options select begin transcoding, how do i know when it's done and where is the file so i can burn it to disk
[08:59] <RockHound> hi everyone ... anyone else experiencing mythtv-status segfaults?
[08:59] <RockHound> with weeklybuild on hardy?
[09:05] <laga> what's segfaulting?
[09:31] <laga> RockHound: ^^
[09:37] <craigyboytaz> Hello, I am trying to choose a HDMI motherboard, can anyone reccomend a mATX one with enough grunt to do 1080p x264 mkv's?
[09:42] <craigyboytaz> looking @ http://www.ebuyer.com/product/132274
[09:43] <craigyboytaz> and that http://www.ebuyer.com/product/140304
[09:44] <craigyboytaz> leaning towards the inno3d intel one for the cpu as dont think the 8200 will make any difference over the 7100, am i correct?
[09:50] <RockHound> laga: /usr/bin/mythtv-status gives me a segault
[09:50] <RockHound> how do I debug this perl script?
[09:50] <RockHound> to see exactly what is causing it?
[09:50] <laga> perl scripts shouldn't segfault...
[09:50] <RockHound> well, then it is something that it induces
[09:51] <laga> i dont have mythtv-status here right now, but i'm currently upgrading my backend to hardy
[09:52] <RockHound> it started when I turned on ubuntu weeklybuilds yesterday ...
[09:52] <RockHound> so it is my fault I guess but I would love to help fix this
[09:54] <RockHound> anyone else have weeklybuilds enabled on hardy? and running into this issue? or not?
[09:54] <laga> i'll take a look at the script
[09:56] <RockHound> i am running in perldebug now ...
[09:57] <laga> god, this is full of crack. we doesn't it use the perl bindings to learn about the database?
[09:57] <laga> ah, i can dpkg-reconfigure it
[09:58] <RockHound> ;-)
[10:00] <laga> it doesn't seg fault here. ;)
[10:00] <laga> i run my "own" weekly builds
[10:01] <laga> RockHound: where do you see the segfault?
[10:02] <RockHound> running via perl -d it hangs after line 411 ...
[10:02] <RockHound> root@ht1:~# /usr/bin/mythtv-status
[10:02] <RockHound> Segmentation fault
[10:03] <laga> /etc/init.d/mythtv-status
[10:04] <laga> oops
[10:04] <laga> line 411:
[10:04] <laga>  $xml ||= load_xml();
[10:04] <laga> seems like it's waiting for the xml to load?
[10:05] <laga> indeed, it also uses the mythtv perl api, it's just a bit hidden in the code..
[10:16] <RockHound> well when running directly it segfaults instantly .. but this waiting for load_xml was just the last output that I saw ... I am new to perldebug so if someone has a hint ... I was just progressing with
[10:16] <RockHound> n
[10:17] <laga> i have never used perldebug
[10:17] <laga> i might take a closer look later once my backend is up and running again.
[10:18] <laga> the upgrade to gutsy went really smooth. i only had to download 300M and it took about 20 minutes or so
[10:20] <RockHound> laga: thx ... and good look on further upgrading
[10:22] <laga> RockHound: if you look in dmesg, is there a line telling you what segfaulted?
[10:23] <RockHound> oops ... missed that ...  [58689.221807] mythtv-status[14689]: segfault at 00000000 eip b7b5a5f0 esp bfefaa64 error 4
[10:23] <laga> heh, it really was the perl script
[10:24] <laga> RockHound: can you show me the xml file your backend gives you?
[10:43] <RockHound> for anyone else interessted, we took this in to a seperate chat ... it seems to have nothing to do with the xml file ...
[11:25]  * laga goes to kick his master backend
[11:26] <laga> ok, i can ssh in now :)
[11:33] <laga> yay, mythweb seems a bit faster, too
[11:35] <laga> or i was just missing some recordings because the device node for my hard disk changed ;)
[11:52] <RockHound> laga: what was causing the ssh login failure?
[11:53] <laga> RockHound: i don't know. i just reset the box and it came back up.
[11:53] <RockHound> ah ... top
[11:54] <laga> now i just need to verify my tv-card is still working
[11:54] <laga> as well as /proc/acpi/alarm ;)
[11:55] <wand> I have a problem with the initial channel searching. My Terratec Cinergy DT somewhat seem to deliver strange tuning parameters which then fail to be added to the database (DTVParamHelper::toString out of bound error) anyone had same or similar experience?
[11:56] <laga> yay, tv still works
[12:02] <RockHound> proc acpi alarm is a thing that I wanted to get working for while now ... never had it wake up though ;-)
[12:06] <laga> heh+
[12:06] <laga> i used to use nvram-wakeup on another box..
[12:07] <laga> maybe that works better for you, although it's a bit scarier.
[12:07] <laga>  /proc/acpi/alarm is the old interface. current kernels use a different one, but ubuntu seems to prefer the legacy one
[12:22] <RockHound> the new interface is under /sys
[12:22] <RockHound> fiddled with that aswell
[12:23] <laga> yay
[12:23] <RockHound> but first off ... mythtv-status ;)
[12:23] <laga> it has come online
[12:23] <laga> so, hardy seems to work well.
[13:06] <baalsgate> hmm im getting a few lockups since moving to 8.04
[13:12] <baalsgate> geees quite in hete
[15:55] <rockhound> laga: after a reboot, mythtv-status works like a charm ... pfft
[15:57] <laga> rockhound: heh. odd.
[15:57] <laga> so let's consider it fixed then :)
[15:57] <rockhound> ohh yeah
[15:58] <laga> do you know about the german mythtv channel? #mythtv-de
[15:58] <rockhound> now yes
[18:49] <Ace2016> hi all
[18:49] <Ace2016> where can i find info on firmware
[19:20] <tgm4883_laptop> Ace2016, um, from the manufacture?
[19:20] <Ace2016> ok i think it was included
[19:20] <Ace2016> for a nexus-s dvb-s card
[22:40] <Ramzi> does anyone knows if mythtv supports ATI All in wonder usb 2.0 tv tuner?
[22:42] <Ramzi> anyone?
[23:48] <driedsponge> hey
[23:57] <prodigel> hi all. I've just set up mythtv and i'm having difficulties watching tv. when selecting 'watch tv' all I get is a black screen for 1 second or so and then reverts to the menu.