Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Wed, Apr 10, 2019 at 12:00 AM Alexander Larsson wrote: > > On Tue, Apr 9, 2019 at 4:57 PM Alexander Larsson > wrote: > > > > On Thu, Apr 4, 2019 at 1:09 PM Akira TAGOH wrote: > > > > > > Yes. done. hope that works well. > > > > Yes, this now seems to work well. I think this is good to go! > > Oh, and once this lands, any chance we could have a minimal backport > of the changes to fontconfig 2.13.1 for the LTS flatpak runtimes? Thanks for testing. for minimal backport, let me figure it out and apply for Fedora updates. you can pull it in from there. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Apr 4, 2019 at 5:46 PM Alexander Larsson wrote: > There are still some issues though: > * Only flatpak 1.2.0 and later generates the dir-remapping fontconfig > file, so earlier versions of flatpak will regenerate caches for > /run/host/fonts. > * On current distros, with the uuid file generated the host fc-cache > will only generate the uuid style cache files, and these will not be > used by the fontconfig in the sandbox. > > The first I think is fine, just update your flatpak to the latest > stable release and it will be fast. > > However, the second is a problem. It means that the second we update > the flatpak runtime to the latest fontconfig all flatpak apps will get > a slow first startup on all current distros. > > Is it possible that we could make the new fontconfig not generate uuid > cache files, but look for them as fallback? I.e. if the (possibly > salted) regular path checksum doesn't exist, look for a .uuid file in > that dir and use that for lookup? Yes. done. hope that works well. > > On Thu, Apr 4, 2019 at 8:50 AM Akira TAGOH wrote: > > > > Ah, thank you for catching this up. I fixed similar case before but > > missed the case for sub directories. fixed. > > > > On Wed, Apr 3, 2019 at 10:01 PM Alexander Larsson > > wrote: > > > > > > On Tue, Apr 2, 2019 at 2:35 PM Akira TAGOH wrote: > > > > > > > > Thanks for testing, Alex. > > > > > > Doing some more testing, and I think I have found an issue. > > > > > > On the host i regenerate caches with your branch, getting FC_DEBUG=16 > > > output (among other output): > > > > > > cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir: > > > /usr/share/fonts/cantarell, salt: (null)) > > > cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir: > > > /usr/share/fonts/cantarell, salt: (null)) > > > charsets 5 -> 1 leaves 75 -> 15 > > > cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir: > > > /usr/share/fonts/cantarell, salt: (null)) > > > > > > In the flatpak-generated config in the sandbox have: > > > /run/host/fonts > > > /run/host/fonts > > > > > > Then, running fc-list in the sandbox prints: > > > > > > cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir: > > > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell), > > > salt: (null)) > > > cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir: > > > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell), > > > salt: (null)) > > > charsets 5 -> 1 leaves 75 -> 15 > > > cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir: > > > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell), > > > salt: (null)) > > > FcDirCacheWriteDir dir "/run/host/fonts/cantarell" file > > > "/home/alex/.var/app/org.gnome.eog/cache/fontconfig//85bba0c73358da0b93a259c9d2b16b14-le64.cache-7" > > > > > > Note how these get different checksums, meaning that the host cache is > > > not used. I think this is due to the double-slash in "mapped to > > > /usr/share/fonts//cantarell". > > > > > > > > -- > > Akira TAGOH -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Ah, thank you for catching this up. I fixed similar case before but missed the case for sub directories. fixed. On Wed, Apr 3, 2019 at 10:01 PM Alexander Larsson wrote: > > On Tue, Apr 2, 2019 at 2:35 PM Akira TAGOH wrote: > > > > Thanks for testing, Alex. > > Doing some more testing, and I think I have found an issue. > > On the host i regenerate caches with your branch, getting FC_DEBUG=16 > output (among other output): > > cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir: > /usr/share/fonts/cantarell, salt: (null)) > cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir: > /usr/share/fonts/cantarell, salt: (null)) > charsets 5 -> 1 leaves 75 -> 15 > cache: /6ba42aef58711b5caaf10d690066-le64.cache-7 (dir: > /usr/share/fonts/cantarell, salt: (null)) > > In the flatpak-generated config in the sandbox have: > /run/host/fonts > /run/host/fonts > > Then, running fc-list in the sandbox prints: > > cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir: > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell), > salt: (null)) > cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir: > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell), > salt: (null)) > charsets 5 -> 1 leaves 75 -> 15 > cache: /85bba0c73358da0b93a259c9d2b16b14-le64.cache-7 (dir: > /run/host/fonts/cantarell (mapped to /usr/share/fonts//cantarell), > salt: (null)) > FcDirCacheWriteDir dir "/run/host/fonts/cantarell" file > "/home/alex/.var/app/org.gnome.eog/cache/fontconfig//85bba0c73358da0b93a259c9d2b16b14-le64.cache-7" > > Note how these get different checksums, meaning that the host cache is > not used. I think this is due to the double-slash in "mapped to > /usr/share/fonts//cantarell". -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Fixed. thanks. On Wed, Apr 3, 2019 at 9:38 PM Alexander Larsson wrote: > > I noticed this in the FC_DEBUG=16 output: >/run/host/fonts -> /usr/share/fonts (salt: (null)) > > Printf NULL like this is fine in glibc, but can crash in other OSes, > so might be nice to fix. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
There are another problem that salt can't be overwritten by another dir elements coming later. which looks intuitive to me. so I'll fix it. On Tue, Apr 2, 2019 at 9:35 PM Akira TAGOH wrote: > > Thanks for testing, Alex. > > On Mon, Apr 1, 2019 at 11:35 PM Alexander Larsson > wrote: > > I don't understand why its generating cache files with the same > > filenames, even though the salt for /usr/share/fonts is different. > > I've added some debugging output (try FC_DEBUG=16 if you want to see > more) to see how fontconfig determines cache filename with given > config. and I found etc/fonts/conf.d/50-flatpak.conf has: > > > /usr/share/fonts > > and reading config files in ASCII order. so when comparing the name of > "50-flatpak-salted.conf" and "50-flatpak.conf", 50-flatpak-salted.conf > is read first. then it was reset and overwritten (newly added in fact) > by the non unique string in 50-flatpak.conf. > That's the reason why you got same cache names in two runs. > So if you don't need to keep the above two lines in 50-flatpak.conf, > you can drop them from there and add to > 50-flatpak-salted.conf. > > > And why does it think they are invalid after having just generated > > them? (The script that generates the 50-flatpak-salted.conf removes > > all caches, so the claimed to be invalid files are definitely created > > by fc-cache...) > > From the debugging message for consideration: > /usr/cache/fontconfig: cleaning cache directory > FcCacheTimeValid dir "/usr/share/fonts/liberation-fonts" cache > checksum 1554199639.0 dir checksum 155420102 > 3.810342069 > /usr/cache/fontconfig: invalid cache file: > e9b75eee6795385ae3f53a200406b963-le64.cache-7 > > Those sum is coming from mtime of cache and dir. fontconfig detects > that dir has been updated but cache wasn't. so considered it is > outdated... > > > Also, i worry about the fact that it seems to list all the fonts in > > /usr/share/fonts twice, the second time complaining about looping. > > Maybe the reset-dirs is not working in fc-cache, so its picking up the > > first instance of /usr/share/fonts? > > No. that is because scanning paths recursively twice when parsing dir > element in config and generating caches. so that is irrelevant to this > though. > Hmm, maybe good to shutting that message up or stop scanning recursively > either. > > > Also, why is it warning about > > "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf"? Why is > > it even trying to parse this file? It should not be used? > > This isn't actually new. when path can't be converted with > prefix="xdg" (for instance, unable to determine relevant XDG env vars > and even hone dir) and so on, that makes a path empty. but that > message seems accidentally shown. I've reverted this behavior to the > past one. > > -- > Akira TAGOH -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Thanks for testing, Alex. On Mon, Apr 1, 2019 at 11:35 PM Alexander Larsson wrote: > I don't understand why its generating cache files with the same > filenames, even though the salt for /usr/share/fonts is different. I've added some debugging output (try FC_DEBUG=16 if you want to see more) to see how fontconfig determines cache filename with given config. and I found etc/fonts/conf.d/50-flatpak.conf has: /usr/share/fonts and reading config files in ASCII order. so when comparing the name of "50-flatpak-salted.conf" and "50-flatpak.conf", 50-flatpak-salted.conf is read first. then it was reset and overwritten (newly added in fact) by the non unique string in 50-flatpak.conf. That's the reason why you got same cache names in two runs. So if you don't need to keep the above two lines in 50-flatpak.conf, you can drop them from there and add to 50-flatpak-salted.conf. > And why does it think they are invalid after having just generated > them? (The script that generates the 50-flatpak-salted.conf removes > all caches, so the claimed to be invalid files are definitely created > by fc-cache...) >From the debugging message for consideration: /usr/cache/fontconfig: cleaning cache directory FcCacheTimeValid dir "/usr/share/fonts/liberation-fonts" cache checksum 1554199639.0 dir checksum 155420102 3.810342069 /usr/cache/fontconfig: invalid cache file: e9b75eee6795385ae3f53a200406b963-le64.cache-7 Those sum is coming from mtime of cache and dir. fontconfig detects that dir has been updated but cache wasn't. so considered it is outdated... > Also, i worry about the fact that it seems to list all the fonts in > /usr/share/fonts twice, the second time complaining about looping. > Maybe the reset-dirs is not working in fc-cache, so its picking up the > first instance of /usr/share/fonts? No. that is because scanning paths recursively twice when parsing dir element in config and generating caches. so that is irrelevant to this though. Hmm, maybe good to shutting that message up or stop scanning recursively either. > Also, why is it warning about > "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf"? Why is > it even trying to parse this file? It should not be used? This isn't actually new. when path can't be converted with prefix="xdg" (for instance, unable to determine relevant XDG env vars and even hone dir) and so on, that makes a path empty. but that message seems accidentally shown. I've reverted this behavior to the past one. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Hi Alex, Have you tried new implementation yet? I believe it should be reflected our discussion though, I want to see some comment from you because flatpak is only customer for salt thing so far. if it works, I can commit it to master and make a release for them. TIA, On Fri, Feb 8, 2019 at 2:34 PM Akira TAGOH wrote: > > No comments on this (yet) so just opened a merge request here: > https://gitlab.freedesktop.org/fontconfig/fontconfig/merge_requests/30 > > If anyone can review, that would be appreciated. > > On Thu, Jan 31, 2019 at 7:36 PM Akira TAGOH wrote: > > > > I've done implementation for salt: > > https://gitlab.freedesktop.org/tagoh/fontconfig/commits/flatpak-rework > > > > That should works as expected. > > For summary to support this on flatpak side, All of flatpaks needs to have: > > > >/usr/share/fonts > > > > and more if there are any fonts directories on sandbox where has same > > directory names on host. > > or may be better having a salt regardless of it to make them > > differenciated to host perhaps. I'll leave it to you, Alex. > > > > No salt should be needed for remap-dir so far. > > > > Ah, and if you want to manage fonts directories in a single file and > > don't want to modify fonts.conf, you can put prior to > > re-define own fonts directories with dir elements. > > > > Please test it. > > > > On Thu, Jan 31, 2019 at 5:56 PM Alexander Larsson > > wrote: > > > > > > On Thu, Jan 31, 2019 at 9:54 AM Akira TAGOH wrote: > > > > > > > > Also if host dirs are available as is on sandbox like Alex concerned, > > > > we could simply have: > > > > > > > > /opt/fonts > > > > > > Yeah, assuming there is no global default salt that messes this up. > > > > > > > > -- > > Akira TAGOH > > > > -- > Akira TAGOH -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
No comments on this (yet) so just opened a merge request here: https://gitlab.freedesktop.org/fontconfig/fontconfig/merge_requests/30 If anyone can review, that would be appreciated. On Thu, Jan 31, 2019 at 7:36 PM Akira TAGOH wrote: > > I've done implementation for salt: > https://gitlab.freedesktop.org/tagoh/fontconfig/commits/flatpak-rework > > That should works as expected. > For summary to support this on flatpak side, All of flatpaks needs to have: > >/usr/share/fonts > > and more if there are any fonts directories on sandbox where has same > directory names on host. > or may be better having a salt regardless of it to make them > differenciated to host perhaps. I'll leave it to you, Alex. > > No salt should be needed for remap-dir so far. > > Ah, and if you want to manage fonts directories in a single file and > don't want to modify fonts.conf, you can put prior to > re-define own fonts directories with dir elements. > > Please test it. > > On Thu, Jan 31, 2019 at 5:56 PM Alexander Larsson > wrote: > > > > On Thu, Jan 31, 2019 at 9:54 AM Akira TAGOH wrote: > > > > > > Also if host dirs are available as is on sandbox like Alex concerned, > > > we could simply have: > > > > > > /opt/fonts > > > > Yeah, assuming there is no global default salt that messes this up. > > > > -- > Akira TAGOH -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
I've done implementation for salt: https://gitlab.freedesktop.org/tagoh/fontconfig/commits/flatpak-rework That should works as expected. For summary to support this on flatpak side, All of flatpaks needs to have: /usr/share/fonts and more if there are any fonts directories on sandbox where has same directory names on host. or may be better having a salt regardless of it to make them differenciated to host perhaps. I'll leave it to you, Alex. No salt should be needed for remap-dir so far. Ah, and if you want to manage fonts directories in a single file and don't want to modify fonts.conf, you can put prior to re-define own fonts directories with dir elements. Please test it. On Thu, Jan 31, 2019 at 5:56 PM Alexander Larsson wrote: > > On Thu, Jan 31, 2019 at 9:54 AM Akira TAGOH wrote: > > > > Also if host dirs are available as is on sandbox like Alex concerned, > > we could simply have: > > > > /opt/fonts > > Yeah, assuming there is no global default salt that messes this up. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 31, 2019 at 5:35 PM Keith Packard wrote: > > Alexander Larsson writes: > > > As I said in an earlier email, it needs to be in the individual dir > > elements, because a global salt is not right. > > Do you want it in the elements directly? That would be more > straightforward in many ways and could avoid troubles with separate salt > declarations that take effect more broadly than one directory. > > So, one file (generated at flatpak creation time) with > > /usr/share/fonts > /run/host/fonts > > and another (generated at runtime) with > > /run/host/fonts > > Presumably you will mask all host configured font paths somehow? Maybe > you need to be able to inherit the 'salt' value from the host (if set)? > If so, we could have: > > /run/host/fonts Yeah, I agree with it. Having a salt in dir and remap-dir would flexibly works I think. Though, given that there are no salt in host, we just need to have a salt for dirs inside sandbox only. so salt shouldn't be needed for remap-dir in this case. Also if host dirs are available as is on sandbox like Alex concerned, we could simply have: /opt/fonts > > -- > -keith -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 31, 2019 at 8:07 AM Keith Packard wrote: > We may want a command line tool that extracts data from the config > for use by flatpak in building the dynamic configuration, including > things like salt values per directory. Yeah, that might be made to > work with flatpak essentially manually overriding the salt configuration > so that it uses the flatpak-relative names. Aha. yeah, that's a good idea. > > This would avoid collision between one and origins. and assuming that > > flatpaks can load config from host too, we could have: > > > > 10-salt.conf (from host): > > > > I'd leave this out and not have salt in the host. Sure. though implicit thing may breaks something easily like own salt affects 'remap-dir' unexpectedly. that should be documented carefully. or should we have salt attribute in remap-dir and dir elements instead? that would be obvious. > The salt here would need to have CDATA for the target directories, and I > think flatpack wants to split the dynamic from static config bits. > > Dynamic (built at runtime): > > /run/host/fonts > > Static (built in the flatpak): > > /usr/share/fonts Yep, that looks good to me. > I think a dir-reset makes a lot of sense so that the flatpak can control > the set of font paths used. Building a command-line tool that flatpak > can use to discover the relevant fontconfig information seems like a > useful improvement; as I recall, flatpak is currently assuming > /usr/share/fonts and ~/.fonts are used on the host. > > -- > -keith -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Wed, Jan 30, 2019 at 5:02 AM Keith Packard wrote: > Yes, that was the plan. Alexander suggested the following syntax: > > /usr/share/fonts > > I think this will work, although it seems a bit fragile. In particular, > if the host has salt for some directories, those will be defined > relative to the host paths, not the flatpak paths. Right. though this syntax looks primitive. it might manages to be done if one writes everything for what they want. but if we can have easier way - which can be done with minimal effort and inheritance for others from host - that may be better. > Do we need to process the 'salt' elements and 'remap-dir' elements in > order and remap old salt elements as remap-dir elements get loaded? That > also seems fragile to me. Hm, to deal with more complicated cases, I guess we may need to have one global salt to affect everything and a path-specific salt for remapped path. for flatpak case, they want to have a global salt to change a salt in sandbox (for /usr/share/fonts in sandbox etc) and set salt from host in 'remap-dir' to build cache filenames on host (for /run/host/fonts and so on). This would avoid collision between one and origins. and assuming that flatpaks can load config from host too, we could have: 10-salt.conf (from host): 50-flatpak.conf (sandbox specific): /run/host/fonts /usr/share/fonts First salt element affects to 'remap-dir' and second one overrides it for paths and change a salt in sandbox. To make things easier, we may also want to export all of dir elements from fonts.conf to the separate file. flatpak can replace it with 50-flatpak.conf in this case. or the file operation isn't desirable, let's implement dir-reset element or something like that. > > Perhaps some command that the flatpak could run to generate host salt > values so that it could remap them into new salt elements using the > mapped paths? > > Alternatively, we could just assume that only flatpak will use the salt > mechanism and leave this for a future enhancement? > > -- > -keith -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Hi, We are still missing a piece of a salt to deal with a directory name separately where possibly have different fonts in sandbox etc. my tree based on Keith's previous implementation works and passed test cases except this salt thing: https://gitlab.freedesktop.org/tagoh/fontconfig/commits/flatpak-rework So have we got a consensus on letting flatpak provide a separate config file contained a salt? On Fri, Jan 25, 2019 at 9:39 PM Keith Packard wrote: > > Akira TAGOH writes: > > > Sure. I started to implement it based on Keith's branch. > > Awesome. I'll be back home "tomorrow" and able to spend some time on > this next week. > > -- > -keith -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Fri, Jan 25, 2019 at 4:35 PM Alexander Larsson wrote: > > On Fri, Jan 25, 2019 at 5:07 AM Akira TAGOH wrote: > > > > > > > > > > as-path=... ? > > > > That sounds good to me. > > This sounds good to me to. I updated the PR: > https://github.com/flatpak/flatpak/pull/2635#issuecomment-457482239 > > Can I get an ack on this format? Sure. I started to implement it based on Keith's branch. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 24, 2019 at 9:43 PM Alexander Larsson wrote: > > On Thu, Jan 24, 2019 at 1:18 PM Akira TAGOH wrote: > > > > On Thu, Jan 24, 2019 at 8:55 PM Alexander Larsson > > wrote: > > > I agree that cache path is wrong as we have something else by that name. > > > > > > host-path kinda hardcodes the sandbox case for rewriting though. Maybe > > > "remapped-path"? > > > > "remap" looks redundant to the element name. simply "to" or "as" as > > you proposed that earlier? > > as-path=... ? That sounds good to me. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 24, 2019 at 8:55 PM Alexander Larsson wrote: > I agree that cache path is wrong as we have something else by that name. > > host-path kinda hardcodes the sandbox case for rewriting though. Maybe > "remapped-path"? "remap" looks redundant to the element name. simply "to" or "as" as you proposed that earlier? -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 24, 2019 at 8:20 PM Akira TAGOH wrote: > Hmm, that looks not intuitive to me. in fact both are also a font > path. "cache path" are the sort of /var/cache/fontconfig or so. how > about "host-path"? although one can see it is remapping a path to > somewhere but still missing how this actually works in fontconfig. > i.e. to determine a cache filename to read. Actually there are no way to guess how cache filenames are determined without looking at source code. dir element is to add a font path. and "remap-" dir is to remap a font path to somewhere. that is consistent enough at this point. I revoke the last sentence where is starting from "although". -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 24, 2019 at 7:54 PM Keith Packard wrote: > I think we might bike-shed on the names here a bit -- 'real-path' is > pretty ambiguous as both paths are 'real', one is just the file system > path and the other is the cache path. I like using the file system path > as the contents of the element and the cache path as the property, but > perhaps the property name could be 'cache-path' instead? Hmm, that looks not intuitive to me. in fact both are also a font path. "cache path" are the sort of /var/cache/fontconfig or so. how about "host-path"? although one can see it is remapping a path to somewhere but still missing how this actually works in fontconfig. i.e. to determine a cache filename to read. > > -- > -keith -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Keith, I'm fine with it. do you have a time to work on it? or already started working? If not, please let me know. On Tue, Jan 22, 2019 at 12:33 AM Alexander Larsson wrote: > > On Sun, Jan 13, 2019 at 7:21 PM Keith Packard wrote: > > > > Alexander Larsson writes: > > > > Yeah, there will be two files. One static in the runtime > > > (/etc/fonts/conf.d/50-flatpak.xml), and one generated by flatpak > > > (/run/host/fontconf.xml). > > > > Sounds like we've got a plan for this part -- fix my mapping code to use > > config bits separate from the elements, then add a 'salt' > > mechanism in the config bits that stirs in some random data when > > generating the cache keys for specific directory trees. > > Whats the status of this. Can we come up with an agreed upon format > for doing the dir remapping (outside of the dir nodes) soon? I'm about > to do a flatpak 1.2 release and would like to preempt things by > generating the dir mapping dynamic snippet so we can use it when we > update fontconfig in the runtime. (Note: We need not yet finalize the > salt stuff, because that will not be in the dynamic flatpak-generated > part of this.) -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Sun, Jan 13, 2019 at 8:53 PM Alexander Larsson wrote: > Yes:ish. It should not *normally* happen. But you may run into it in > uncommon situations like e.g. chrome using a statically linked version > of fontconfig that has a different fontconfig cache format. > > > > However, flatpak will never parse the entire xml fontconfig file > > > format (which isn't even really stable over time), so such a config > > > would have to be external in a simpler config format. > > > > The fontconfig xml format is quite stable and is designed to be > > manipulated by tools that do not understand the full contents, hence > > using XML and providing a suitable DTD. > > We recently ran into issues with fontconfig xml parsing errors in chrome > when using config files from a newer host fontconfig that were not > parsable by the statically linked chrome copy, so it is not perfect. Right. that is really a pain in the neck. not adding new syntax is hard to improve and grow. that said, just ignoring unknown syntax would makes harder to find an error. we may need to think about measures for that like checking a version of config and library say, but anyway. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Fri, Jan 11, 2019 at 7:06 PM Alexander Larsson wrote: > We would have to turn that into a dynamic snippet. But that would be a > problem for pre-existing flatpak binaries which doesn't do this. > Could we instead have a way to modify a previously added dir element? > Or maybe it could handle duplicate tags such that they keep the > original order, but update the mapping? Then we can have both the > static snippet an a dynamic one for later flatpak versions. There was an idea in the previous discussion to have a new element to reset and split up into a file. that may helps you to have an own desired font directories list instead of modifying entire fonts.conf dynamically. this can be put into /etc/fonts/conf.d. so it can be activated no matter how apps has own modified fonts.conf as long as it contains a line to read config files from conf.d. This would makes easier to have a map. > > > Here's an alternative proposal: > > > > Add a per 'dir' element 'salt' value, which is stirred into the > > path name when generating the cache key. You'd generate this > > randomly when the flatpak was created so that all cache keys > > would not collide with entries using a different (or absent) > > salt value. > > > > With this, and my path->key mapping series, we would be able to access > > the existing cache files for external fonts (via the mapping mechanism), as > > well as avoid collisions between internal and external font paths within > > the cache. And we wouldn't have .uuid files (see above). > > I like this in theory. But i don't want to rewrite the entire runtime > font config xml file (its just to fragile). I much prefer if such a > salt could be added by just dropping a file somewhere. I.e. a > fonts.conf snippet that tweaked the salt of a previously defined dir > element. > > So, counter proposal: > > Flatpak generates at startup a file like this in /run/host/fontconf.xml > > /run/host/fonts> > /run/host/user-fonts> > > In the runtime we create at build-time a /etc/fonts/conf.d/ file: > > /usr/share/fonts > # Duplicate this with static versions for old flatpak versions > /run/host/fonts> > # This will (if it exists) override the above with the live values > /run/host/fontconf.xml > > We are basically in full control of existing flatpak runtimes, so this > could easily be added to all of them an propagated out. However, the > new flatpak version that creates the fontconf.xml file will not reach > distros in a while, so the above duplicates the "most likely to be > right" value for /usr/share/fonts for older flatpak versions to pick > up. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 10, 2019 at 7:54 PM Alexander Larsson wrote: > Here is my proposal: > > Make the uuid *generation* optional and manual. Then, when we create > the flatpak runtime we run fc-cache --make-uuid (or something) to > generate the uuid files. Then fontconfig would never confuse the > sandboxed /usr/share/fonts with any other, and since we would get a > new uuid each time we regenerated the runtime it would correctly pick > up stale caches when we update the runtime (even with no mtime > change). This would requires the root privilege to create uuid file on directories where root own though, are you going to have setuid to flatpak? or can this be done without it? > > This would make the default installation of fontconfig reproducible, > and it would solve the first problem (don't mix up sandboxed and host > font dirs). It would also let you opt-in to the uuid in other cases > where it makes sense. For instance, you could have a uuid file on a > NFS share or USB drive font dir, so that any caches for it will always > be the same no matter how it happens to be mounted. > > We still wouldn't have a way to reuse host caches which were mounted > in a different way, but if we assume all conflicting directories use > uuids (like they would in the flatpak case), then we could solve this > in a pretty simple way by a config file saying "treat all instances of > /run/host/fonts as /usr/share/fonts", and I could make flatpak > generate such a file. -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
On Thu, Jan 10, 2019 at 4:29 AM Keith Packard wrote: > I'm probably forgetting a bunch of context here, but I think the problem > was that flatpaks have /run/host/fonts pointing to the "real" > /usr/share/fonts and then a separate /usr/share/fonts of their own with > a small set of fonts, and so you end up with collisions in the cache > file namespace as both directories end up generating the same cache file > name. That is correct. > Making the build reproducible means having all content generated > deterministically based only on the source package and toolchain. The > current UUID files are generated randomly making them > non-deterministic. Hm, I see. > For the font cache, making it reproducible requires that the keys > mapping directories to cache filenames be the same each time the cache > is built. This means we cannot use the current randomly generated UUID > values and also have a reproducible system. Right. > I considered whether we might provide a mechanism to generate UUID > values deterministically for purposes of packaging. However, this would > mean that we couldn't use these same packages when creating a flatpak as > the deterministic UUID values would collide if those same packages were > used in the outer system. > > Without deterministic UUID values, I'm left with the feeling that > our only available solutions involve changing how flatpaks reference > fonts. > > If we agree that a solution to this involves changing the flatpak > mechanism, I'd like to suggest that the most straightforward fix for the > overall system would be to expose the external fonts using the external > path names -- bind mounting the external /usr/share/fonts as > /usr/share/fonts within the flatpak, and creating a new > /usr/share/fonts-minimal (or whatever) to hold the fonts provided by the > flatpak itself. With this change, we can simply delete the UUID code > from fontconfig and go back to using global font paths as keys to the > font cache database. Indeed, that would be able to accomplish both with the minimal efforts for us at least. though they might came up with this but they didn't do it that way. so there might be some reason why they didn't do so. packaging issue perhaps? > I'd love to hear about alternative ideas which might lead to solutions > that make builds involving fontconfig reproducible. I'd be happy to take > even vague hints at this point; all I've got at this point are a > collection of dead ends. I can't figure out completely but, fontconfig may needs to deal with different namespaces in a cache filename to avoid a collision between host and sandboxes. dunno if we may see different state in the future but it might be represented as a depth in a filename to make it different like 0:-le64.cache- for host and 1:-le64.cache- for a sandbox. we could increase a depth for a child in sandbox as needed, anyway. We can mix up caches that is located at the same place then. the last missing piece would be to map them to the right place. flatpaks should knows where they mounted directories to. they can create a map table with proper parent depth and current depth I think. I may be missing something so this might not work though... > (Also, if I've missed or forgotten something relevant, please let me > know; I've re-read a lot of stuff while writing this, but surely > something escaped my notice). > > -- > -keith -- Akira TAGOH
Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
Thank you for reminding and sorry for late response on this. I was on long holidays. On Fri, Jan 4, 2019 at 9:29 PM Chris Lamb wrote: > Since then, I don't believe there has been any review of this > branch both in the sense of the code itself but also in terms of > the architectural changes that it implies. I might be able to help > on the former front but without knowing the "lore" of Fontconfig I > simply cannot comment on the latter parts. As of the discussion on the list, Keith's changes doesn't address the original purpose - allow sharing caches on bind-mounts in flatpaks. particularly for the case where flatpaks uses same location in sandbox. this is the reason why it can't be merged into master. So just reverting the change that removes .uuid file only when a directory has empty is done in master so far. if you have .uuid file prior to run fc-cache, your issue could be worked around at this moment. for more details, you can check what Alex Larsson said on this list. > > Anyway, I'd love to get this resolved once and for all ideally get > it into Debian buster which is about to start "freezing" very > soon. > > What would be the best way for me to help here? Can I entreat Keith > to merge his branch? I can put some cycles onto this issue if that is > of some assistance. > > > Best wishes, > > -- > Chris Lamb > chris-lamb.co.uk / @lolamby > ___ > Fontconfig mailing list > fontcon...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/fontconfig -- Akira TAGOH
Bug#642520: fontconfig: conf file to fix Ryumin and GothicBBB fonts mojibake
Does the attachment fix your issue right? that looks to me like there are a trick in evince(poppler) to take care of the fallback fonts from property though, then I think evince or poppler should ships it and install at /etc/fonts/conf.d or so. at least property isn't the standard object in fontconfig. On Thu, May 24, 2012 at 11:44 AM, Hideki Yamane henr...@debian.or.jp wrote: Hi, I've put (not Debian specific) bug report to Debian BTS but unfortunately with no response to it, so now I would send it to you as upstream maintainer. Some of Japanese Debian users annoyed to see ～ glyph as □ with Evince and the docs that was created with TeX. I suggest add conf file to fontconfig as http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=30-RyuminGothicBBB.conf;att=1;bug=642520 I want to hear your opinion for this issue. Thanks! -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- Akira TAGOH -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#478884: screen: 40cjk_eastasian.dpatch breaks terminal layout
On Mon, Jun 2, 2008 at 8:13 AM, Jan Christoph Nordholz [EMAIL PROTECTED] wrote: Hi, is the interval structure and the bisearch function necessary? I can't find a code path that calls it. Besides that the patch looks good and I'll include it in the next upload. Probably not. I haven't looked at them carefully. since those has been added in this patch, that would be good to remove them then. Thanks for your response, -- Akira TAGOH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478884: screen: 40cjk_eastasian.dpatch breaks terminal layout
Package: screen
Version: 4.0.3-9
Severity: normal
When I run screen on CJK locale, that shows me the broken
terminal layout on aptitude say. getting rid of the patch or
using wcswidth(3) instead of the own code in utf8_isdouble()
fixes that issue. I'm running with the attached patch for a
while though, that looks good to me.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages screen depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libncursesw5 5.6+20080419-2 Shared libraries for terminal hand
ii libpam0g 0.99.7.1-6 Pluggable Authentication Modules l
screen recommends no packages.
-- debconf information:
screen/old_upgrade_prompt: false
#! /bin/sh /usr/share/dpatch/dpatch-run
## 40cjk_eastasian.dpatch by Yi-Hsuan Hsin [EMAIL PROTECTED]
##
## DP: Fix display of characters with ambiguous width depending on the
## DP: user's display locale. See upstream #1.
@DPATCH@
diff -urNad screen-4.0.3~/ansi.c screen-4.0.3/ansi.c
--- screen-4.0.3~/ansi.c2007-12-03 16:56:26.0 +0900
+++ screen-4.0.3/ansi.c 2007-12-03 16:56:27.0 +0900
@@ -681,7 +681,7 @@
curr-w_rend.font = 0;
}
# ifdef DW_CHARS
- if (curr-w_encoding == UTF8 c = 0x1100 utf8_isdouble(c))
+ if (curr-w_encoding == UTF8 utf8_isdouble(c))
curr-w_mbcs = 0xff;
# endif
if (curr-w_encoding == UTF8 c = 0x0300 utf8_iscomb(c))
diff -urNad screen-4.0.3~/comm.c screen-4.0.3/comm.c
--- screen-4.0.3~/comm.c2007-12-03 16:56:26.0 +0900
+++ screen-4.0.3/comm.c 2007-12-03 16:56:27.0 +0900
@@ -112,6 +112,9 @@
#endif
{ charset, NEED_FORE|ARGS_1 },
{ chdir, ARGS_01 },
+#ifdef DW_CHARS
+ { cjkwidth,ARGS_01 },
+#endif
{ clear, NEED_FORE|ARGS_0 },
{ colon, NEED_LAYER|ARGS_01 },
{ command, NEED_DISPLAY|ARGS_02 },
diff -urNad screen-4.0.3~/encoding.c screen-4.0.3/encoding.c
--- screen-4.0.3~/encoding.c2007-12-03 16:56:26.0 +0900
+++ screen-4.0.3/encoding.c 2007-12-03 17:14:03.0 +0900
@@ -22,6 +22,7 @@
*/
#include sys/types.h
+#include wchar.h
#include config.h
#include screen.h
@@ -35,6 +37,10 @@
extern char *screenencodings;
+#ifdef DW_CHARS
+extern int cjkwidth;
+#endif
+
static int encmatch __P((char *, char *));
# ifdef UTF8
static int recode_char __P((int, int, int));
@@ -845,22 +851,39 @@
}
#ifdef DW_CHARS
+struct interval {
+ int first;
+ int last;
+};
+
+/* auxiliary function for binary search in interval table */
+static int bisearch(int ucs, const struct interval *table, int max) {
+ int min = 0;
+ int mid;
+
+ if (ucs table[0].first || ucs table[max].last)
+return 0;
+ while (max = min) {
+mid = (min + max) / 2;
+if (ucs table[mid].last)
+ min = mid + 1;
+else if (ucs table[mid].first)
+ max = mid - 1;
+else
+ return 1;
+ }
+
+ return 0;
+}
+
int
utf8_isdouble(c)
int c;
{
- return
-(c = 0x1100
- (c = 0x115f ||/* Hangul Jamo init. consonants */
- (c = 0x2e80 c = 0xa4cf (c ~0x0011) != 0x300a
- c != 0x303f) || /* CJK ... Yi */
- (c = 0xac00 c = 0xd7a3) || /* Hangul Syllables */
- (c = 0xdf00 c = 0xdfff) || /* dw combining sequence */
- (c = 0xf900 c = 0xfaff) || /* CJK Compatibility Ideographs */
- (c = 0xfe30 c = 0xfe6f) || /* CJK Compatibility Forms */
- (c = 0xff00 c = 0xff5f) || /* Fullwidth Forms */
- (c = 0xffe0 c = 0xffe6) ||
- (c = 0x2 c = 0x2)));
+ /* convert Unicode to UCS-4 */
+ wchar_t w = c;
+
+ return wcswidth(w, 1) 1;
}
#endif
diff -urNad screen-4.0.3~/process.c screen-4.0.3/process.c
--- screen-4.0.3~/process.c 2007-12-03 16:56:26.0 +0900
+++ screen-4.0.3/process.c 2007-12-03 16:56:27.0 +0900
@@ -103,6 +103,9 @@
#ifdef UTF8
extern char *screenencodings;
#endif
+#ifdef DW_CHARS
+extern int cjkwidth;
+#endif
static int CheckArgNum __P((int, char **));
static void ClearAction __P((struct action *));
@@ -3826,6 +3829,15 @@
Msg(0, idle off);
}
break;
+#ifdef DW_CHARS
+case RC_CJKWIDTH:
+ if(ParseSwitch(act, cjkwidth) == 0)
+ {
+if(msgok)
+ Msg(0, Treat ambiguous width characters as %s width, cjkwidth ?
full : half);
+ }
+ break;
+#endif
default:
#ifdef HAVE_BRAILLE
/* key == -2: input from braille keybord, msgok always 0 */
diff -urNad screen-4.0.3~/screen.c screen-4.0.3/screen.c
--- screen-4.0.3~/screen.c 2007-12-03 16:56:26.0 +0900
+++ screen-4.0.3/screen.c 2007-12-03
Bug#476625: libotf: libotf 0.9.7 is available
Package: libotf Severity: wishlist New upstream release is available: http://www.m17n.org/libotf/libotf-0.9.7.tar.gz Also, copyright file has to be updated. tsukuba.m17n.org is no longer reachable. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash pgp7a8iD8dgHj.pgp Description: PGP signature
Bug#473699: libgtk2.0-0: gtk-im-module-setting.patch is wrongly applied
Package: libgtk2.0-0
Version: 2.12.9-2
Severity: normal
095_gtk-im-module-setting.patch doesn't take any effects
because that's looking into the invalid memory space to get
XSETTINGS name and GtkSettings name. In gdksettings.c,
gdk_settings_map has to point out the proper offset at
gdk_settings_names.
That should be:
@@ -107,5 +108,6 @@
{ 1197, 1206 },
{ 1219, 1227 },
{ 1239, 1261 },
- { 1285, 1305 }
+ { 1285, 1305 },
+ { 1326, 1339 }
};
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgtk2.0-0 depends on:
ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libcairo2 1.5.8-1The Cairo 2D vector graphics libra
ii libcomerr21.40.8-2 common error description library
ii libcupsys21.3.6-3Common UNIX Printing System(tm) -
ii libfontconfig12.5.0-2generic font configuration library
ii libglib2.0-0 2.16.1-2 The GLib library of C routines
ii libgnutls26 2.2.2-1the GNU TLS library - runtime libr
ii libgtk2.0-common 2.12.9-2 Common files for the GTK+ graphica
ii libjpeg62 6b-14 The Independent JPEG Group's JPEG
ii libkrb53 1.6.dfsg.3~beta1-4 MIT Kerberos runtime libraries
ii libpango1.0-0 1.20.0-1 Layout and rendering of internatio
ii libpng12-01.2.15~beta5-3 PNG library - runtime
ii libtiff4 3.8.2-7Tag Image File Format (TIFF) libra
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxcomposite11:0.4.0-1 X11 Composite extension library
ii libxcursor1 1:1.1.9-1 X cursor management library
ii libxdamage1 1:1.1.1-3 X11 damaged region extension libra
ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar
ii libxfixes31:4.0.3-2 X11 miscellaneous 'fixes' extensio
ii libxi62:1.1.3-1 X11 Input extension library
ii libxinerama1 2:1.0.3-1 X11 Xinerama extension library
ii libxrandr22:1.2.2-1 X11 RandR extension library
ii libxrender1 1:0.9.4-1 X Rendering Extension client libra
ii zlib1g1:1.2.3.3.dfsg-11 compression library - runtime
Versions of packages libgtk2.0-0 recommends:
ii hicolor-icon-theme0.10-1 default fallback theme for FreeDes
ii libgtk2.0-bin 2.12.9-2 The programs for the GTK+ graphica
-- no debconf information
pgpYCu3263eg3.pgp
Description: PGP signature
Bug#457136: netbase: Different service name/port to IANA
Package: netbase Version: 4.30 Severity: normal /etc/services currently has: ndtp2010/tcp# Network dictionary transfer protocol but 2010 has been assigned for search by IANA and ndtp is actually assigned to 2882. http://www.iana.org/assignments/port-numbers -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages netbase depends on: ii ifupdown 0.6.8 high level tools to configure netw ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip netbase recommends no packages. -- debconf information: netbase/upgrade-note/etc-network-interfaces-pre-3.17-1: netbase/upgrade-note/init.d-split-pre-3.16-1: netbase/upgrade-note/radius-ports-pre-3.05: netbase/upgrade-note/portmap-restart-pre-3.11-2: pgpurR2sqPQkC.pgp Description: PGP signature
Bug#435372: O: wget-el -- an interface for wget on Emacsen
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgppRY8rwevqs.pgp Description: PGP signature
Bug#435366: O: cmap-adobe-japan1 -- CMaps for Adobe-Japan1
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgpozD6xLv6Ib.pgp Description: PGP signature
Bug#435365: O: cmap-adobe-cns1 -- CMaps for Adobe-CNS1
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgpqVOVy67oYi.pgp Description: PGP signature
Bug#435367: O: cmap-adobe-korea1 -- CMaps for Adobe-Korea1
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgpofjwdn6efV.pgp Description: PGP signature
Bug#435368: O: cmap-adobe-gb1 -- CMaps for Adobe-GB1
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgpsNUq5e1Cqc.pgp Description: PGP signature
Bug#435370: O: cmap-adobe-japan2 -- CMaps for Adobe-Japan2
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgpAxlhDZjJgH.pgp Description: PGP signature
Bug#435371: O: vpim -- vCard and iCalendar library for Ruby
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgpsWS3HKR95T.pgp Description: PGP signature
Bug#435369: O: gs-cjk-resource -- Resource files for gs-cjk, ghostscript CJK-TrueType extension
Package: wnpp Severity: normal Please take up this package if someone is interested in it. Regards, -- Akira TAGOH pgpzFL8myJgD0.pgp Description: PGP signature
Bug#433729: network-manager-vpnc: doesn't support resolvconf
Package: network-manager-vpnc Version: 0.6.4svn2422-1 Severity: normal a vpnc connection can be established through network-manager-vpnc through network-manager. however if resolvconf is installed, it's totally unusable because no resolv.conf is updated. I have spent some times to investigate why it happens, and the reason was, vpnc brings up nm-vpnc-service-vpnc-helper instead of vpnc-script. so nm-vpnc-service-vpnc-helper needs to support resolvconf. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages network-manager-vpnc depends on: ii libart-2.0-2 2.3.19-3 Library of functions for 2D graphi ii libatk1.0-01.18.0-2 The ATK accessibility toolkit ii libbonobo2-0 2.18.0-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.18.0-5 The Bonobo UI library ii libc6 2.6-2 GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libdbus-1-31.1.1-3 simple interprocess messaging syst ii libdbus-glib-1-2 0.74-1simple interprocess messaging syst ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libgconf2-42.19.1-1 GNOME configuration database syste ii libglade2-01:2.6.1-1 library to load .glade files at ru ii libglib2.0-0 2.12.13-1 The GLib library of C routines ii libgnome-keyring0 0.8.1-2 GNOME keyring services library ii libgnome2-02.18.0-4 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-3 A powerful object-oriented display ii libgnomeui-0 2.18.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.18.1-3+b1 GNOME Virtual File System (runtime ii libgtk2.0-02.10.13-1 The GTK+ graphical user interface ii libice61:1.0.3-2 X11 Inter-Client Exchange library ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.17.3-1 Layout and rendering of internatio ii libpopt0 1.10-3lib for parsing cmdline parameters ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor11:1.1.8-2 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.1-1 X11 Input extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxml22.6.29.dfsg-1 GNOME XML library ii libxrandr2 2:1.2.1-1 X11 RandR extension library ii libxrender11:0.9.2-1 X Rendering Extension client libra ii vpnc 0.4.0-3 Cisco-compatible VPN client network-manager-vpnc recommends no packages. -- no debconf information pgpX2qECAsOvr.pgp Description: PGP signature
Bug#402258: cmap-adobe-japan1: [INTL:de] German po-debconf template translation
On Fri, 08 Dec 2006 22:25:21 -0500, MJ == Matthias Julius [EMAIL PROTECTED] wrote: MJ Package: cmap-adobe-japan1 MJ Version: 0+20040605-3 MJ Severity: minor MJ Tags: patch l10n MJ -BEGIN PGP SIGNED MESSAGE- MJ Hash: SHA1 MJ I have prepared a translation of the po-debconf template into German. MJ Please include it in debian/po. Thank you for translating template for German. and I apologize for not getting back to you earlier. MJ During translation I noticed some rough edges on the English text. I MJ would recommend to change it to something like this: MJ String 2 MJ Choose the necessary group(s) of CMaps according to their importance. MJ String 3 MJ The Adobe-Japan1 Character Collection consists of so many CMaps that it takes MJ considerable time to register all, though rarely used ones are also included. MJ By unselecting the extra (and possibly optional) group(s) those rarely used MJ ones are kept from being registered. Those updates makes sense to me. however can you file a bug for that separately? You could update your translation for updated template though, it would be a good idea to follow the translation workflow in debconf template I suppose. otherwise any po files won't be translated in next update and I can't really close this bug as well till I will get the updated de.po from you or someone. Thanks, -- Akira TAGOH pgp4AzanZoK7U.pgp Description: PGP signature
Bug#392783: libupnp: libupnp-1.3.1 is available
Package: libupnp Severity: wishlist New upstream release seems to be available since March. It would be nice if you can update the package with it. TIA, -- Akira TAGOH pgpACUfqe3D24.pgp Description: PGP signature
Bug#390845: O: glib1.2 -- The GLib library of C routines
Package: wnpp Severity: normal I don't have enough time to maintain this package. Thanks, -- Akira TAGOH pgpRR0pW4bbNe.pgp Description: PGP signature
Bug#375974: im-switch: need to be configured earlier
On Fri, 30 Jun 2006 09:24:44 +0900, OA == Osamu Aoki [EMAIL PROTECTED] wrote: OA So I should change to 80im-switch ? That sounds good to me so far. -- Akira TAGOH pgpZeOTCPIJDf.pgp Description: PGP signature
Bug#375974: im-switch: need to be configured earlier
Package: im-switch Version: 1.11 Severity: normal When a gnupg-agent package is installed, gpg-agent will be invoked before im-switch is configured so that it has the same priority and it runs alphabetically. the problem happens when any passphrase is required and pinentry-gtk2 is used as a frontend. so which IM is used on pinentry-gtk2 depends on the order of gtk.immodules and not reflect the im-switch configuration at all. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) im-switch depends on no packages. Versions of packages im-switch recommends: ii x11-common1:7.0.22 X Window System (X.Org) infrastruc -- no debconf information pgpnfHjGVUmnq.pgp Description: PGP signature
Bug#374538: gdb: internal error in printf_command
Package: gdb Version: 6.4.90.dfsg-1 Severity: normal giving %p causes the internal error. $ gdb GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu. (gdb) printf %p, 1 internal error in printf_command -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-mm1 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages gdb depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libncurses5 5.5-2 Shared libraries for terminal hand ii libreadline5 5.1-7 GNU readline and history libraries gdb recommends no packages. -- no debconf information pgpqGPiwcPEzf.pgp Description: PGP signature
Bug#358164: libedit2: adding \n incrementally with read/write history
Package: libedit2
Version: 2.9.cvs.20050518-2.2
Severity: normal
a linefeed is always increased whenever
read_history/write_history is invoked. please try an
attached code. on GNU readline, foo.his has only input
word in the line. but on libedit, three \012 will be added
after input word so that read_history/write_history is
invoked three times intentionally.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.6
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Versions of packages libedit2 depends on:
ii libc6 2.3.6-3GNU C Library: Shared libraries an
ii libncurses5 5.5-1 Shared libraries for terminal hand
libedit2 recommends no packages.
-- no debconf information
#include editline/readline.h
int
main(void)
{
char *foo = NULL;
foo = readline(input something:);
add_history(foo);
write_history(foo.his);
clear_history();
read_history(foo.his);
foo = readline(input ctrl+d:);
write_history(foo.his);
clear_history();
read_history(foo.his);
foo = readline(input ctrl+d:);
write_history(foo.his);
clear_history();
read_history(foo.his);
foo = readline(input ctrl+d:);
write_history(foo.his);
return 0;
}
Bug#356714: [l10n] Updated Czech translation for cmap-adobe-japan debconf
reassign 356714 cmap-adobe-japan1 thanks On Mon, 13 Mar 2006 19:38:17 +, MM == Martin Michlmayr [EMAIL PROTECTED] wrote: MM * Jakub Kasparec [EMAIL PROTECTED] [2006-03-13 19:09]: Package: cmap-adobe-japan Severity: wishlist Please find attached cs.po, updated version of cmap-adobe-japan debconf messages. Please include it with the package. MM Where did you get this package from? It's not in Debian as far as I MM could tell. http://packages.qa.debian.org/c/cmap-adobe-japan1.html is what he was referring to. -- Akira TAGOH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348294: uim-applet-gnome: need a dependency of uim-gtk2.0
Package: uim-applet-gnome Version: 1:1.0.0-1 Severity: normal Though uim-applet-gnome has uim.desktop that is referring to uim-pref-gtk, there are no uim-pref-gtk in this package and are even no dependencies to install the package which contains it. uim-applet-gnome should depends on uim-gtk2.0 to get it working anyway. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages uim-applet-gnome depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6Open-source version of SGI's audio ii libbonobo2-0 2.10.1-1 Bonobo CORBA interfaces library ii libbonoboui2-02.10.1-1 The Bonobo UI library ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libcairo2 1.0.2-3.1 The Cairo 2D vector graphics libra ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared ii libfontconfig12.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgconf2-4 2.12.1-8 GNOME configuration database syste ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libglade2-0 1:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.8.5-1The GLib library of C routines ii libgnome-keyring0 0.4.6-2GNOME keyring services library ii libgnome2-0 2.12.0.1-4 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.12.0-2 A powerful object-oriented display ii libgnomeui-0 2.12.0-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-02.12.2-3 The GNOME virtual file-system libr ii libgnutls11 1.0.16-14 GNU TLS library - runtime library ii libgpg-error0 1.1-4 library for common error values an ii libgtk2.0-0 2.8.10-1 The GTK+ graphical user interface ii libice6 6.9.0.dfsg.1-3 Inter-Client Exchange library ii libjpeg62 6b-11 The Independent JPEG Group's JPEG ii liborbit2 1:2.12.4-1 libraries for ORBit2 - a CORBA ORB ii libpanel-applet2-02.12.2-3 library for GNOME 2 panel applets ii libpango1.0-0 1.10.2-1 Layout and rendering of internatio ii libpng12-01.2.8rel-5 PNG library - runtime ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm66.9.0.dfsg.1-3 X Window System Session Management ii libtasn1-20.2.17-1 Manage ASN.1 structures (runtime) ii libuim0 1:1.0.0-1 Simple and flexible input method c ii libx11-6 6.9.0.dfsg.1-3 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.9.0.dfsg.1-3 X Window System miscellaneous exte ii libxi66.9.0.dfsg.1-3 X Window System Input extension li ii libxinerama1 6.9.0.dfsg.1-3 X Window System multi-head display ii libxml2 2.6.23-1.1 GNOME XML library ii libxrandr26.9.0.dfsg.1-3 X Window System Resize, Rotate and ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii uim-common1:1.0.0-1 Common files for uim ii uim-utils 1:1.0.0-1 Utilities for uim ii zlib1g1:1.2.3-9 compression library - runtime uim-applet-gnome recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345143: gs-cjk-resource: installed package leads to /invalidfileaccess Error in gs
On Thu, 29 Dec 2005 10:51:08 +0100, PJW == Peter J. W. [EMAIL PROTECTED] wrote: PJW Package: gs-cjk-resource PJW Severity: important PJW I had some trouble with displaying or printing some postscript files. PJW Ghostscript - whether invoked by gv or lpr or directly doesn't matter - PJW failed with a message Error: /invalidfileaccess in --file--. PJW The following lines showed the filename /usr/share/ghostscript/CMap/Identity-H PJW which was a symlink to /usr/share/fonts/cmap/gs-cjk-resource/Identity-H which PJW belonged to gs-cjk-resource. After removing (purging) this packages, gv worked fine. PJW Unfortunantly I removed the package before I decided to write a bug report, therefore PJW I do not know the version I had installed for sure, but as aptitude PJW would now install 1.20021122-2, I am pretty sure that this was the PJW version I had trouble with. Which gs are you using? what does update-alternatives --display gs show? possible issues are 1) gs-* 8.x is broken. you can confirm it with update-alternatives --config gs and choose gs-esp for default gs. try it again then. 2) even gs-esp 7.x is broken. please make sure if your document is sane. 3) the document itself is broken. Identity-H is actually the same file what Adobe ships. so if it also happens on any Adobe products, I suspect it is. 4) the font that was determined by your document or is assigned by gs, is broken. gs doesn't maps to the font if it doesn't actually support any glyphs in Identity-H range. please attach full error log from gs. you can get it with running gs directly. Please try above steps anyway. it's necessary to track this problem down. Thanks, -- Akira TAGOH : [EMAIL PROTECTED] / Japan GNOME Users Group [EMAIL PROTECTED] : [EMAIL PROTECTED] / GNOME-DB Project : [EMAIL PROTECTED] / Red Hat, Inc. : [EMAIL PROTECTED] / Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343060: libaspell15: aspell has to be targetted for C++ ABI transition
Package: libaspell15 Version: 0.60.4-1 Severity: grave There is no rebuild of aspell package after the reversion of the mt allocator which was happened at 4.0.2-4. it causes the strange crash when the applications/libraries which was rebuilt against the newer libstdc++, uses libaspell15 which was built against the old libstdc++, but has the same soname. I'm not sure why they didn't change it and why the rebuild package list was missing aspell though, when I input something with scim on gaim, it crashes immediately, and rebuilding aspell got it fixed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages libaspell15 depends on: ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libstdc++64.0.2-5The GNU Standard C++ Library v3 Versions of packages libaspell15 recommends: ii aspell-en [aspell-dictionary] 6.0-0-5English dictionary for GNU Aspell -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309437: Bug#309604: Bug#309437: libpango1.0-common - libpango1.0-0 circular dependencies
On Sun, 2 Oct 2005 11:08:34 +0200, LM == Loïc Minier [EMAIL PROTECTED] wrote: LM Hi Seb, hi Akira Tagoh, LM Do you recall why libgtk2.0-common depends on libgtk2.0-0? LM I could only find a changelog snipset in 2.4.1-1: LM * Akira TAGOH [EMAIL PROTECTED] LM + debian/control: LM - added libgtk2.0-0 to Depends for libgtk2.0-common. (from 2.2.4-6). LM - libgtk2.0-dev requires libxext-dev. (Closes: #247469) LM I didn't find any obvious reason for having a libgtk2.0-common depends LM on libgtk2.0-0 constraint, apart of the fact that libgtk2.0-common is LM useless without libgtk2.0-0. LM Please let me know whether we can break this loop. Well, there was the upgrading issue IIRC. I don't remember the details though.
Bug#309437: Bug#309604: Bug#309437: libpango1.0-common - libpango1.0-0 circular dependencies
On Sun, 2 Oct 2005 16:02:39 +0200, LM == Loïc Minier [EMAIL PROTECTED] wrote: LM On dim, oct 02, 2005, Akira TAGOH wrote: Well, there was the upgrading issue IIRC. I don't remember the details though. LM Since we're done with the woody - sarge upgrade, I think we can break LM the loop again, as dependency loops cause trouble too. Er, I thought it was that libgtk2.0-0 or libgtk2.0-common wasn't updated or either package was only updated on usual dist-upgrade. something like that. Nevertheless you can try it and revert it any time if it causes another trouble. Good luck :) -- Akira TAGOH
Bug#330430: cmap-adobe-cns1: [INTL:sv] Swedish debconf templates translation
On Wed, 28 Sep 2005 03:10:35 +0200, DN == Daniel Nylander [EMAIL PROTECTED] wrote: DN Package: cmap-adobe-cns1 DN Version: 0+20040609-2 DN Severity: wishlist DN Tags: patch l10n Thank you for your contribution. However it looks like the fuzzy item is still there and lintian complains like: W: cmap-adobe-cns1: partially-translated-question cmap-adobe-cns1/level sv.utf-8N: N: If you translate the `Choices:' fields in a template, you should N: translate the 'Description:' field as well So could you fix this then? Thanks, -- Akira TAGOH : [EMAIL PROTECTED] / Japan GNOME Users Group [EMAIL PROTECTED] : [EMAIL PROTECTED] / GNOME-DB Project : [EMAIL PROTECTED] / Red Hat, Inc. : [EMAIL PROTECTED] / Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324956: scim-anthy: xinput script causes X stop-working
Package: scim-anthy Version: 0.6.1-2 Severity: normal When I choose scim-anthy for the default IM by im-switch, X doesn't work anymore due to that script. there was command not found: anthy, in the error log. so DEPENDS=scim, anthy, scim-gtk2-immodule has to be quoted. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-swsusp-2.1.9.5 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages scim-anthy depends on: ii anthy 6724-1 A Japanese input method (backend, ii im-switch 1.2Input method switch framework ii libanthy0 6724-1 Anthy runtime library ii libatk1.0-0 1.10.1-2 The ATK accessibility toolkit ii libc6 2.3.5-4GNU C Library: Shared libraries an ii libgcc1 1:4.0.1-6 GCC support library ii libglib2.0-0 2.8.0-1The GLib library of C routines ii libgtk2.0-0 2.6.9-1The GTK+ graphical user interface ii libpango1.0-0 1.8.2-1Layout and rendering of internatio ii libscim8 1.4.1-1library for SCIM platform ii libstdc++64.0.1-6The GNU Standard C++ Library v3 ii scim 1.4.1-1Smart Common Input Method platform scim-anthy recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318774: ftp.debian.org: request to change the section to oldlibs
Package: ftp.debian.org Severity: normal Hi, I'd propose to change the section of libglib1.2 and libgtk1.2 to oldlibs, because the current released version of gtk+/glib is 2.x and it was about 2 years ago. 2.x series is more stable than 1.2 and upstream has never maintained the older release anymore. For the upstream/packager, there was enough time to have a look how to work gtk+ 2.x properly and which better to use between 1.2 and 2.x. this section changes would speeds up to migrate the applications/libraries, I suppose. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-swsusp-2.1.9.5 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318772: ftp.debian.org: request to remove libgda, gnome-db and gasql
Package: ftp.debian.org Severity: normal As the subject says, these are obsoleted packages and keeping in mind makes no sense at all. please remove them and the sub packages as well. libgda: gda-mysql_0.2.96-6.2 gda-odbc_0..2.96-6.2 gda-postgres_0.2.96-6.2 libgda-common_0.2.96-6.2 libgda-dev_0.2.96-6.2 libgda0_0.2.96-6.2 gnome-db: gnome-db-doc_0.2.96-9 gnome-db_0.2.96-9 libgnomedb-dev_0.2.96-9 libgnomedb0-common_0.2.96-9 libgnomedb0_0.2.96-9 gasql: gasql_0.6+0.2.95-5 Thanks, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-swsusp-2.1.9.5 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300883: riece: Please use emacsen instead of each [x]emacs packages
Package: riece Version: 1.0.8-1 Severity: normal Please use Depends: emacs21 | emacsen instead of emacs21 | xemacs21. I suppose that it was because riece doesn't work on the older version of emacs. However emacs20 say isn't available anymore. so depending on emacsen is sufficient IMHO. -- Akira TAGOH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300709: libvpim-ruby1.8: Actually the new version does not need patching
On Mon, 21 Mar 2005 12:47:20 +0100, SZ == Silvestre Zabala [EMAIL PROTECTED] wrote: SZ Package: libvpim-ruby1.8 SZ Version: 0.13-1 SZ Followup-For: Bug #300709 SZ Hello, SZ the new vpim version doesn't need patching any longer. SZ But maybe you could include a small hint into the README.Debian: SZ If you want to query the GNOME Evolution addressbook from mutt, you SZ should include these two lines into your .muttrc: SZ source /usr/lib/evolution/2.0/evolution-addressbook-export | /usr/share/doc/libvpim-ruby1.8/examples/vcf-to-mutt.rb --aliases| SZ set query_command = /usr/lib/evolution/2.0/evolution-addressbook-export | /usr/share/doc/libvpim-ruby1.8/examples/vcf-to-mutt.rb '%s' SZ Of course you have to adapt the path to evolution-addressbook-export, if SZ you use a version other than 2.0.x SZ That would be great. Thank you for your information. I'll update with it then. -- Akira TAGOH : [EMAIL PROTECTED] / Japan GNOME Users Group [EMAIL PROTECTED] : [EMAIL PROTECTED] / GNOME-DB Project : [EMAIL PROTECTED] / Red Hat, Inc. : [EMAIL PROTECTED] / Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286400: About the Ruby packages split: a concrete proposal
Hi, I think I understand the topic of this proposal. IMHO changing the role of meta package here isn't good idea. and I wonder what you mean by -core. also wonder if we really need a lot of meta package for only Ruby. I disagree your proposal then. However I like an idea of making a meta package like ruby-stdlib. so another proposal from me to solve this problem is: - make a meta package like rubyX.Y-stdlib in rubyX.Y, which has all dependencies of the packages built from Ruby. If you don't want to install some package in them, you can just install the packages you want from them so that you can see which packages are provided from Ruby now. - make a meta package like ruby-stdlib in ruby-defaults, which has a dependency of rubyX.Y-stdlib according to the initial policy of ruby-defaults. I mean it works for providing the current stable version. - add Suggests: ruby-stdlib to ruby meta package. IMHO it should be sufficient since you can see which packages are suggested by the package when you do apt-get install. either Depends or Recommends is annoying to me. Any idea/comments/thoughts are welcome. Regards, -- Akira TAGOH : [EMAIL PROTECTED] / Japan GNOME Users Group [EMAIL PROTECTED] : [EMAIL PROTECTED] / GNOME-DB Project : [EMAIL PROTECTED] / Red Hat, Inc. : [EMAIL PROTECTED] / Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#217897: change RFP to ITP
retitle 217897 ITP: vpim -- vCard and iCalendar library for Ruby thanks I can take care of this package now. -- Akira TAGOH : [EMAIL PROTECTED] / Japan GNOME Users Group [EMAIL PROTECTED] : [EMAIL PROTECTED] / GNOME-DB Project : [EMAIL PROTECTED] / Red Hat, Inc. : [EMAIL PROTECTED] / Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
