=== [ESphynx] is now known as ESphynx [03:12] hey guys, I have an explicit dependency to 'Depends: fonts-freefont-ttf' ... but installing the i386 package on a 64 bit system says fonts-freefont-ttf:i386 is not installable :( [03:55] ESphynx: that's weird, it's arch all [03:56] micahg: yes I assumed it would be! [03:56] could it be that apt-get is being stupid? [03:56] ESphynx: does apt-cache show fonts-freefont-ttf display it as such [03:57] let me check. on another note VirtualBox guest additions doesn't support Quantal yet in latest version and that's depressing (no copy paste) [03:58] It does say Architecture: all [03:58] i didn't doubt that... it's just that installing an i386 package that depends on an :all package seems to expect it to be :i386 and doesn't recognize an all package as satisfying [03:59] (And there's no way to force an install regardless of a dependency check failing? :() [03:59] hrm [04:00] Depends: fonts-freefont-ttf:any might help (but it really shouldn't be needed) [04:00] micahg: But you can't do that, right? [04:01] had problems with :any before I think :P [04:01] in the archive, no [04:01] You can't depend on specific-arch versions; dpkg doesn't have the syntax. [04:01] I'd rather apt-get be fixed :P [04:01] ESphynx: https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages [04:02] right, so the font needs to be multiarch: allowed :-/ [04:02] micahg: So the problem is that fonts package should have Multi-Arch: foreign or Multi-Arch: allowed. added? [04:03] fix it fix it fix it :P plz [04:03] can't install ecere on Quantal 64 =( [04:04] ESphynx: why are you depending on a font? [04:04] micahg: yeah Ecere will either look very bad or not show any test at all [04:04] any text* [04:04] and I was trying to avoid that. [04:05] ESphynx: it doesn't use the system fonts? [04:05] it uses fontconfig to try to match fonts [04:05] but it's its own GUI toolkit so it's rather low level... [04:05] liberation-sans I think is the one that works nicely [04:06] an IDE depending on a particular font certainly feels wrong [04:06] :P it doesn't depend on a particular font... [04:06] Depends: fonts-freefont-ttf [04:06] but somehow in earlier versions (Of Ubuntu as well I think), fontconfig would bail and return no font at all... [04:06] freefont is a font collection :P [04:07] they're installed by default though :P [04:07] right [04:07] well, even depending on a font collection seems wrong [04:08] (and the collection in installed by default) [04:08] well, at least in Ubuntu [04:08] yes it is... [04:08] in Ubuntu [04:08] but not in sid I think [04:12] ESphynx: well, in theory dropping it to a recommends would fix the issue on Ubuntu [04:12] * micahg wonders how it's installable on sid [04:12] ah, it's in experimental [04:13] still doesn't explain why it's installable [04:14] * micahg guesses piuparts doesn't run on experimental? [04:15] micahg: the font? it probably isn't... but I just tested in 32bit [04:18] ESphynx: arch [04:18] i386 armel armhf powerpc all (from the PTS) [04:19] ah, ok [04:19] hmm? [04:19] was that ecere arch? [04:19] yeah [04:19] nevermind [04:19] some sub packages are all... [04:20] those won't be installable on amd64 either [04:20] * micahg would suggest dropping the font to a recommends and make your arch: all packages Multi-Arch: allowed [04:21] the other packages were fine [04:21] They installed fine on 64bit before , with my PPA. [04:21] (which didn't have the font thing) [04:21] recommends won't automatically install it though, will it? [04:21] oh, I guess they're not dependencies [04:22] recommends are installed by default, but should cause an install to fail [04:22] well they are dependencies [04:22] so I should probably make them Multi-Arch: allowed ... [04:22] that looks stupid to me though... I mean all , is all [04:22] why would it not multi arch [04:22] it's usually for docs and such [04:23] ESphynx: because of dpkg internal magic [04:23] LOL [04:23] you put it nicely ;) [04:23] will do [04:23] ESphynx: also, your packages are dependencies of the sdk so they should fail in the same way the font is [04:23] yeah I see that [04:23] *you arch: all [04:23] but they didn't, at least on Precise [04:24] weird [04:24] I installed them successfully off the PPA on Precise 64 [04:24] weird indeed. [04:24] so I'll do both of your recommendations.. [04:24] but I'm a bit depressed with the state of the whole thing :| especially the lack of copy past in my VM [04:24] ESphynx: 64 bit quantal: http://paste.ubuntu.com/1301805/ [04:25] micahg: ah I guess that's the same thing? [04:25] i got that too.. and then I tried to install ecere-dev:i386 manually [04:25] and I got that font thing [04:25] ESphynx: I'd also suggest dropping the samples and extras to recommends or suggests since I'm assuming the IDE works fine without them [04:25] yes it does [04:25] * micahg has the font since it's pulled in by xubuntu-desktop [04:25] but then they make up the sdk [04:26] one could just install ecere-dev =) [04:26] ah, ok [04:26] or libecere0 to run an Ecere app (which is the dependency for an Ecere ap) [04:27] ESphynx: wait, if it's a [04:27] oops [04:29] if it's a ... ? [04:29] I meant not to send that line :) [04:29] ah =) [04:30] ah well at least I'm not the only one pulling it in :P [04:30] ESphynx: you might want to also check the length of your descriptions, they seem to wrap at around 55 chars [04:30] I have it too installed, but it's just apt-get playing dumb [04:30] 55 chars? [04:30] (that fix wouldn't be good for an SRU, but would be good for raring) [04:31] it's not as wide as a normal terminal (80 characters) [04:31] A description fix you mean? [04:31] yeha [04:31] I was all confused with the description length thing [04:31] and the space or 2 spaces before... [04:31] https://github.com/ecere/sdk/blob/ppa/debian/debian/control [04:31] that's my control file [04:31] I auto wrapped them I think. [04:31] ESphynx: you might want to run wrap-and-sort on it [04:31] k [04:32] If I can get copy/paste in Quantal, I'd like to do a new package and upload it to debian/unstable instead of experimental [04:32] that can get pulled in for a SRU ? i've some bug fixes in there... [04:33] also hoping to get the build further on ARM and PPC [04:33] well, SRU rules are pretty strict, but if the bug fixes are auditable, it might be ok [04:33] How strict are they? [04:34] ESphynx: https://wiki.ubuntu.com/StableReleaseUpdates#When [04:34] "Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)." and potentially FTBFS for ARM/PPC =) [04:35] good to know the process =) thanks. [04:36] also this 64 bit thing is likely the most important reason for a SRU... [04:36] it's currently unusable :| major downer [04:37] yeah, the control file changes (except for the description) should be fine [04:37] K so I shouldn't change the description then? [04:37] not for the SRU [04:38] well, unless some SRU person thinks that's fine [04:38] (since you're not changing any strings) [04:38] I can still upload to debian/unstable first though? [04:38] and file the SRU request as a sync from debian? [04:39] ESphynx: well, if it's just for the control file change, I'd just prepare a debdiff for quantal and focus on the new version in unstable [04:39] no it's for a new minor release with bug fixes [04:40] well, either way, it's not a straight sync from unstable -> quantal, it would be a sync to raring and at best a backport in -proposed from raring [04:41] that's if the minor release meets the SRU criteria [04:41] e.g. https://github.com/ecere/sdk/commit/a0f37656a3f8d216bc42a3a3bcebeb1ac21bcab0 [04:41] k [04:42] * micahg is not an SRU member [04:42] hehe yeah, thanks for the help anyways ;) [04:42] I have to get it in unstable first and then raring first :P [04:43] Note that we're more lenient for SRUs to Universe packages. [04:43] ah... so RAOF is an SRU member =) good to know :P [04:44] Also, it looks like whoever wrote that code needs to be hit with a cluebat. [04:44] when it's not universe it's...? :P [04:44] * ESphynx wrote it [04:44] :P [04:44] One does not simply write() structures to disc ☺ [04:44] * ESphynx dodges [04:45] back in the days when computers performed well you did :P [04:45] Because, as you've found, even when on exactly the same architecture, C does not guarantee the memory layout of your structure. [04:45] ESphynx: No, back in the days when I was programming on *win32* one did :) [04:46] RAOF the whole sturct is __attribute__((packed)) though [04:46] I still don't understand why GCC 4.7 gave me a hard time with that one.. but it sure did [04:47] (that and a bunch of other things) [04:47] ESphynx: So, you run it with 32 bit and it writes out a struct. Then you re-install with 64 bit and read in that struct. And that's bad. [04:47] and the struct is Swap() for big endian :P [04:47] 64 bit? 32 bit/ [04:48] the size of the types are the same [04:48] nothing bad there. just a bug in GCC 4.7 disregarding my attribute(packed), which I worked around :P [05:08] ESphynx: it's a regression over precise [05:08] (the arch: all handling) [05:09] micahg: yeah looks like it [05:09] you could say that of Quantal as well (apart from including ecere of course :P) [05:14] Bug #1070672 [05:14] Launchpad bug 1070672 in apt (Ubuntu Raring) "Architecture: all packages no longer treated as implicitly Multi-Arch: foreign" [High,Triaged] https://launchpad.net/bugs/1070672 [05:16] ESphynx: ^^ so you don't have to worry about an SRU (aside from your bug fixes) [05:19] ah great! :) thanks a lot micahg!! [05:19] ESphynx: thanks goes to pehjota in #multiarch on OFTC [05:20] this is gonna get backported to Quantal soon right? :) [05:21] slangasek: ^^ [05:25] micahg: er, architecture: all packages are *not* implicitly multi-arch: foreign [05:27] they were in Precise? [05:27] no, they were not [05:27] see follow-up to the bug [05:28] slangasek: here I have a package that specifies a dependency on an 'all' package... [05:28] and it fails to satisfy that dependency even though the package is obviously already installed? [05:28] correct [05:29] now I can't install my software because of that :| [05:29] i see that as valid, very annoying bug :P [05:31] well, you're mistaken. This is defined in the multiarch spec. [05:31] the arch: all package needs to be explicitly marked Multi-Arch: foreign if it indeed satisfies cross-dependencies. [05:32] slangasek: but when/why would an all package 'NOT' satisfy cross-dependencies? [05:32] and in that case the bug is that fonts SHOUD specify Multi-Arch: foreign... but that's an annoyance, it should be default? [05:32] no, making it the default is not backwards-compatible, as defined in the spec [05:33] Why wasn't I invited at the multiarch specs meeting :P [05:34] I would have said to copy MS... they got it right before anyone had X64 CPUs!!! [05:34] it has always been a breeze to run 32 bit software on a 64bit Windows [05:35] Mainly because you're expected to bundle all your dependencies on Windows :) [05:36] RAOF : is that the reason? I always wondered. [05:36] So anyways, I guess we're back to I have to switch to a recommends: [05:39] it's legitimate to ask for the dependent package in question to be marked M-A: foreign [05:40] slangasek: package in question is font-freefont-ttf =) [05:40] slangasek: the question though, is why was I getting away with this in Precise? [05:41] my packages didn't have Multi-Arch: foreign either [05:41] i.e. when you apt-get install ecere-sdk [05:41] it depends on ecere-samples which is all, and not marked as Multi-Arch, and it would install on Precise 64 [05:42] I know of no reason that Arch: all dependency handling would've worked any differently in precise [06:55] good morning === almaisan-away is now known as al-maisan [08:46] ESphynx: The canonical example of why Architecture: all must not be considered to imply Multi-Arch: foreign is that of Python extensions. [08:46] (As, I think, is mentioned in the spec.) [08:48] Or possibly that's a slightly different case. Haven't quite had enough coffee yet. [09:28] first use of sponsor-patch fails [09:28] bdrung: it looks like it doesn't consider the target of the upload in the changelog diff when downloading the source package? [10:20] Laney: good question. it downloads the source from the series of the bug report. === al-maisan is now known as almaisan-away [11:18] Hello everybody. [11:19] When I use pbuilder to create minimal environment for Ubuntu Raring I get "Unknown distribution". [11:23] most likely you need an updated debootstrap [11:23] how to do it? [11:24] sudo ln -s gutsy /usr/share/debootstrap/scripts/raring [11:24] for the meantime [11:24] we'll get a backport together at some point [11:31] Would you please explain to me in more details why do I need to do this? [11:32] Because debootstrap needs to know about the specific distribution it's bootstrapping, and we didn't even know the name of raring until too late to include that in 12.10's debootstrap package. [11:44] Ok but as I can see most of Ubuntu versions are links to the gusty file, why? [11:44] Because the same logic works [11:44] obounaim: Those scripts tell debootstrap how the Ubuntu release needs to be constructed, which hasn't changed since Gutsy. [11:47] Indeed. It used to be different, and it still might differ again in the future. [11:47] Ok thank you everybody. [11:48] I once took a look at those old scripts. Annoyingly, most of the divergence appears to be formatting, with the occasional tiny functional change interleaved [11:48] There were real functional changes, but it's probably easier to look at them in git. === almaisan-away is now known as al-maisan [12:50] https://wiki.ubuntu.com/UbuntuOpenWeek starting in 10 minutes in #ubuntu-classroom === dholbach_ is now known as dholbach [13:39] bdrung: culmus> please make sure it's sent upstream [13:39] Laney: it was on my todo list to mail it [13:40] ok [13:49] Laney: fix sent to upstream author [13:50] merci [13:50] worth noting in the bug [13:52] done === dpm__ is now known as dpm [14:39] slangasek: sorry about that, ISTR something about not wanting to update all arch: all packages to be Multi-Arch: foreign, but the outcome of that discussion could've just been to wait until it was needed === al-maisan is now known as almaisan-away [14:58] micahg: effectively, yes :) === yofel_ is now known as yofel === Ursinha-afk is now known as Ursinha === dpm is now known as dpm-afk === gallth is now known as tgall_foo === glebihan_ is now known as glebihan === Quintasan_ is now known as Quintasan === arand is now known as Guest36475 === arand_ is now known as arand