| cjwatson | slangasek: mind if I sort out bug 1087843 for raring? | 00:00 |
|---|---|---|
| ubottu | bug 1087843 in shim-signed (Ubuntu Raring) "[MIR] secureboot-db" [Undecided,New] https://launchpad.net/bugs/1087843 | 00:00 |
| cjwatson | Just an added Recommends | 00:00 |
| slangasek | cjwatson: be my guest | 00:01 |
| cjwatson | done, thanks | 00:03 |
| === wedgwood is now known as wedgwood_away | ||
| psusi | hrm.. looks like ntfs-3g has ABI upstream ABI breakage | 01:03 |
| * 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:20 |
| psusi | YokoZar1, oh? | 01:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| psusi | I think dpkg syncs like 6 times per package, which is absurd | 01:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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. | 01:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| xnox | psusi: never mind, found your bug. | 02:06 |
| 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 |
| ubottu | bug 1126547 in ntfs-3g (Ubuntu) "ntfs-3g: abi breakage" [High,Triaged] https://launchpad.net/bugs/1126547 | 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| * 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:11 |
| 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:12 |
| cjwatson | Generally upstream ntfs-3g changes its soname basically every release, and reverse-dependencies need to be rebuilt | 02:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:32 |
| * psusi uses one machine and fixes it on the rare occasion things go tits up | 02:33 | |
| 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:35 |
| psusi | cjwatson, wait, you mean because it wouldn't be allowed out of -proposed until the dependency breakage was resolved? | 02:37 |
| psusi | hrm... cool. | 02:38 |
| cjwatson | Correct | 02:40 |
| 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:43 |
| 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 |
| ubottu | Ubuntu bug 535368 in parted (Ubuntu Lucid) "old Conflicts cause libparted0 upgrade problems" [High,Fix released] | 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:44 |
| cjwatson | (There's still a libparted0 dummy package for convenience, but it doesn't interact with upgrades any more) | 02:45 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:55 |
| 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:56 |
| cjwatson | It is necessary to learn how d-i is laid out before proposing modifications to it | 02:57 |
| cjwatson | It does not have the structure you seem to think it has | 02:58 |
| cjwatson | The only possible place I can think of for this would be in-target (and friends) | 02:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| cjwatson | Because I don't deal very well with a full congressional grilling at 3am I'm afraid | 03:06 |
| psusi | lol... I'm just trying to figure out where having libeatmydata set in the environment would be UNdesirable | 03:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| psusi | hrm... ok | 03:11 |
| 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:12 |
| cjwatson | We use the apt cdrom method | 03:13 |
| cjwatson | Which AFAIK doesn't bother copying | 03:13 |
| === fenris is now known as Guest68519 | ||
| === manueljoe is now known as icyjoe | ||
| === icyjoe is now known as manueljoe | ||
| === freeflyi1g is now known as freeflying | ||
| jamespage | !regression-alert | 11:13 |
| ubottu | cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 11:13 |
| jamespage | bug 1125611 | 11:13 |
| ubottu | bug 1125611 in openvswitch (Ubuntu) "Upgrade to 1.4.0-1ubuntu1.4 breaks brcompat support" [Critical,Confirmed] https://launchpad.net/bugs/1125611 | 11:13 |
| 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:14 |
| Malsasa | Hello, how to package .run in Ubuntu? | 11:34 |
| === fisted_ is now known as fisted | ||
| 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:23 |
| Malsasa | JanC: ooooh, i dont know there is a channel named packaging :) Thank you.... | 12:38 |
| === and`_ is now known as and` | ||
| === rsalveti_ is now known as rsalveti | ||
| === zz_jackyalcine is now known as jackyalcine | ||
| === yofel_ is now known as yofel | ||
| bdrung | doko__: i used lintian to verify that the warning are gone. "using debhelper 9 to pass hardening flags" might be more descriptive. | 17:10 |
| * tumbleweed wonders why our nvidia packages now Provide fglrx | 17:41 | |
| infinity | tumbleweed: Overexhuberant copy and paste between Replaces, Conflicts, and Provides, I'd guess. | 17:43 |
| tumbleweed | we also have an nvidia-current transitional binary package, which is fairly useless when all the nvidia-XXX packages conflict with it | 17:45 |
| tumbleweed | or is it still useful to help apt with upgrades? | 17:46 |
| 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:53 |
| 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 | 17:55 |
| ejat | bug 1127404 | 18:25 |
| ubottu | bug 1127404 in qtmultimedia-opensource-src (Ubuntu) "conflict between libqt5multimediaquick5 and libqt5multimediaquick-p5" [Undecided,New] https://launchpad.net/bugs/1127404 | 18:25 |
| ejat | can someone help me on that .. | 18:25 |
| === jackyalcine is now known as zz_jackyalcine | ||
| === zz_jackyalcine is now known as jackyalcine | ||
| 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:07 |
| ejat | slangasek: ok thanks .. there is discussion about this on #ubuntu-phone .. they notice the issues .. | 19:08 |
| === JanC_ is now known as JanC | ||
| 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:24 |
| pavolzetor | and I need to know if notification is sitll on screen (so program will not show next one) | 20:25 |
| pavolzetor | does it emit some sginal that it was hidden from screen? | 20:26 |
| pavolzetor | is there any way to get default timeout or something like this? | 20:47 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| xnox | (start whatever you do to walk all the feeds and get new articles thingy....) | 20:57 |
| 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:10 |
| 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:11 |
| 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:12 |
| pavolzetor | Ahh I see | 21:13 |
| pavolzetor | will go to correct room ;) | 21:13 |
| 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 | 21:14 |
| === Quintasan_ is now known as Quintasan | ||
| === jackyalcine is now known as zz_jackyalcine | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!