Re: GetDeb Project
On Wed, Oct 17, 2007 at 01:45:04AM +0200, Krzysztof Lichota wrote: Scott Kitterman napisał(a): Generally I enable backports, install what I want, and the disable it again. That I think most people can do. Maybe they can, but: a) they have to know about it They have to know about GetDeb, too. b) it is very inconvenient c) you do not get updates to installed app (i.e. security fixes) This makes me curious: how do you get security fixes for a package installed from GetDeb? Ming 2007.10.17 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
Hi João Pinto, On Sun, Oct 14, 2007 at 12:46:59PM +0100, João Pinto wrote: Hello, I am the GetDeb project founder and manager, I would like to present GetDeb, current status and planned goals. Thanks for sending this mail to the Ubuntu lists. It's apparent that GetDeb meets the need of quite some users, and it would be nice to see GetDeb and the official repository has more collabrations. Most of this thread is talking about the packages. I would like, however, to talk about something else. Current Status --- [...] One of our important accessibility factors is internationalization, 99% of the site template is translatable and already translated into more than 20 languages. The applications description is also translatable, however that is still a young and not very polished feature, at this moment we have about 1K application descriptions translated to random languages. What are these application descriptions? Are they the same as the package descriptions (i.e., the Description: field in debian/control, also shown in apt-cache show package-name. If yes, is there a way to get all the translations for a particular language? I believe many people would be interested to see them, and incorporate them into Debian and Ubuntu. Also, you can also use the existent translation work of the package descriptions from Debian [1] on GetDeb website if you want. 1. http://www.us.debian.org/intl/l10n/ddtp Internationalization: http://www.getdeb.net/languages.php A side note -- since you are using global.zh-tw.php for traditional Chinese (zh_TW in the locale notation), you probably want to use global.zh-cn.php instead of global.zh.php for simplified Chinese (zh_CN). Ming 2007.10.17 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Gutsy's HAL is broken.
On Thu, Oct 04, 2007 at 06:46:20PM -0700, Scott (angrykeyboarder) wrote: Caroline Ford spake thusly on 328153984 :: On Thu, 2007-10-04 at 05:05 -0700, Scott (angrykeyboarder) wrote: This really belongs on the bug tracker not here. Pardon moi? I never said that I believe Caroline meant that all those information you provided should be sent to the bug tracker instead of this mailing list. Ming 2007.10.06 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
MOTU meeting minutes
On Sat, Jul 07, 2007 at 08:28:27AM +0900, Emmet Hikory wrote: The next MOTU Meeting is scheduled for Saturday, July 14th, 0:00 UTC. The meeting minutes are now available at: https://wiki.ubuntu.com/MOTU/Meetings/2007-07-14 Following is the text version of the minutes: MOTU Meeting on UTC 00:00, July 14th, 2007. Package Merging Policy -- There was discussion about clarifying the merge policy and making it official. Things like flagging merges people don't want others to touch, what is the best way to ping the previous upload, were discussed. The consensus was to defer debates to next MOTU meeting, and LukeYelavich will create a wiki page for the draft proposal. AndyPrice wrote a mail to ubuntu-motu list after the meeting, and the discussion has already started. The Future of QA Sessions -- During discussion of next QA session dates, people started to question if these sessions are useful at all. JeanFrancoisGagnonLaporte proposed that a session with special goals and good timing, such as a QA session about merging at the start of a development cycle (before most merges happen), will be more useful. It was agreed that stopping scheduled QA sessions will be suggested on mailing list and discussed at next MOTU meeting. Upcoming Events --- The meeting also decided the date and time of the following regular events: * Next MOTU meeting Following the practice of shifting 12 hours for each meeting time so that people in different timezones can have a chance to attend, the next MOTU meeting is scheduled on UTC 12:00, July 27th. * Next HUG day The next HUG day will be July 20th. WilliamGrant will be sending announcements to mailing list, UWN, and Fridge. * Next REVU days The next REVU days will be on July 16th and 23rd, both Mondays. StefanPotyra will be sending announcements. * Next QA sessions The next QA sessions will be held on UTC 00:00 and 12:00, July 26th, at #ubuntu-motu. Other Discussed Topics -- The following topics were also discussed during the meeting, but with no clear conclusion drawn or decision made: LukeYelavich suggested to make an effort to clear the remaining outstanding merges before UVF, which also triggered the merge policy discussion. There were concerns that HUG days are not effective, and people discussed ways to attract more participants, as well as coordination with BugSquad. People also discussed whether the current policies and procedures are too many so that they scare away potential contributors. Ming 2007.07.14 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: I'd like to discuss how difficult it is to add a third party repository
On Fri, May 25, 2007 at 03:03:36PM -0700, Scott Ritchie wrote: But what about the GPG key? Do they still need to add that with a terminal command? There are GUI tools for manipulating GPG keys for APT as well, the one I know is gui-apt-key, written in GTK-perl. Ming 2007.05.26 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Thu, May 24, 2007 at 02:59:41PM +0100, Matt Zimmerman wrote:
On Mon, May 21, 2007 at 10:59:42PM -0500, Ming Hua wrote:
I believe the general consensus among Chinese users is that bitmap fonts
are preferred for small font size.
Do the xfonts-* fonts fall into these categories?
Yes, they are the stand-alone bitmap fonts I mentioned, sorry for
being unclear.
So to re-iterate, I believe most, if not all, Chinese users prefer
bitmap fonts for small font sizes. This can be achieved in two ways,
stand-alone BDF/PCF fonts, such as the ones in xfonts-* packages, or
embedded bitmap in TrueType fonts, and the only such TT fonts available
in Debian/Ubuntu are ttf-arphic-{uming,ukai}.
I'm not sure what character set they cover.
That's a question I don't have clear answer either. I know xfonts-wqy
covers quite a wide range of CJK characters, and their most recent
release definitely cover GBK (a.k.a. Windows code page 936), which
should satisfy simplified Chinese (zh_CN) users' need. It should also
cover Big5 (a.k.a. Windows code page 950) for the need of traditional
Chinese users in Taiwan (zh_TW). I think it doesn't cover Big5-HKSCS
yet, which is needed by traditional Chinese users in Hong Kong (zh_HK).
Note Debian/Ubuntu currently haven't packaged the most recent release
though.
The two TrueType fonts, ttf-arphic-{uming,ukai}, should be using the
same set of embedded bitmaps. This set of bitmaps are not the same as
the xfonts-wqy font, but some subset of them may share the same origin.
As the upstream author, Arne, is also participating this discussion, he
should know more details if it's an important piece of information.
Both xfonts-wqy and ttf-arphic-* also have some coverage for Japanese
and Korean characters. But I have no idea about how complete the
coverage is or what quality the glyphs are. I also haven't heard much
about Japanese and Korean users using these fonts, they have their own
preferred TrueType fonts, and maybe bitmap fonts as well.
P.S.: I'm subscribed to all these three lists, so cc: is not necessary. :-)
Ming
2007.05.24
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Mon, May 21, 2007 at 01:13:56AM +0100, Nicolas Spalinger wrote: - Whether we still need all these horrible bitmap fonts You mean the fonts available in the x-fonts* packages? I think the names are xfonts-*. Last time I checked, X server won't start without the fixed bitmap font from xfonts-base. I would suggest a poll on usage and possible demotion to universe or specific langpacks. Might be different for CJK fonts. I believe the general consensus among Chinese users is that bitmap fonts are preferred for small font size. There is a technique called embedded bitmap that can put bitmap fonts of different size into a TrueType font, and libfreetype handles this correctly. There are currently one set of fonts (with two typefaces) in Debian/Ubuntu that has embedded bitmaps. A sad thing, however, is that although there is a group actively working on a set of Chinese bitmap fonts and has improved the quality quite a bit, their work can't be embedded into the existent TrueType font due to licensing restrictions. So I am afraid in the short term stand-alone bitmap fonts are still necessary for Chinese users who are picky about font rendering. Ming 2007.05.21 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Thu, May 10, 2007 at 08:59:19AM -0700, Micah Cowan wrote:
Fergal Daly wrote:
You are also implying that everything in /usr/bin that start with
#! /usr/bin/{perl,python,...}
is wrong and should actually start with
#! {perl,python,...}
That doesn't work. #! requires a path.
For the sake of discussion, I think
#!/usr/bin/env perl
will pick up $PATH and is a valid #! line. I also believe this is widely
used.
Ming
2007.05.10
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: /usr/local/bin in $PATH in system scripts?
On Thu, May 10, 2007 at 08:33:41PM -0700, Micah Cowan wrote: Ming Hua wrote: For the sake of discussion, I think #!/usr/bin/env perl will pick up $PATH and is a valid #! line. I also believe this is widely used. Yes, it will. But isn't that a somewhat silly suggestion considering the context? If /usr/bin/perl were bad then /usr/bin/env would be just as bad, it seems to me... That's not the point. Fergal's argument is, if you think scripts honoring the $PATH variable and use the binaries /usr/local/bin/ is a feature because it respects the user preference, you should also think using #!/usr/bin/env perl instead of #!/usr/bin/perl a feature as well, for the same reason. And I think it's a valid argument. Debian guarantees /usr/bin/perl and /usr/bin/env will work. I think the focus of this discussion is what happens if we have a bad /usr/local/bin/perl, not a bad /usr/bin/perl. Ming 2007.05.10 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: texlive
On Thu, Apr 26, 2007 at 11:36:11AM -0700, Micah Cowan wrote: Matt Zimmerman wrote: On Wed, Apr 25, 2007 at 12:46:25PM -0700, Jordan Mantha wrote: I'll have time to give him a hand). My concern was actually more dealing with the broken deps and invariable upgrade/install issues that people seem to have with a transition like this. I put in a request for an ubuntu-tex mailing list yesterday so that we can coordinate this kind of work better with the Debian TeX people. As always, I think it's best to hold any discussion on ubuntu-devel until it's clear that there is a need for a new list. Otherwise, you risk creating an underactive list which only serves to isolate the discussion from other developers. And it surely would be a low-activity list; however, it is sometimes necessary to discuss things that really don't have a place on the devel list at large: one such thing we need to discuss is a more precise understanding of what does and does not make it into the list of packages that we share responsibility for. I can simply include the membership in my To: headers, but this is cumbersome and isn't very good for handling new members that arrive after the thread begins. My understanding is that Jordan and you are giving two different examples. I feel Jordan's example, discussing TeX-related packages that have broken deps or upgrading/installing problems is a good topic for ubuntu-devel. Your example, discussing what packages should be maintained by -tex team, is probably not. Also, adding a new list have the problem of making interested people subscribe, set up filter, etc., while discussing on ubuntu-devel requires no extra efforts. Ming 2007.04.26 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
