Re: Putting security-based applications as a separate menu entry rather than in Accessories
On May 17, 2007, at 7:19 AM, shirish wrote: ... What do you guys think of putting things like keyring manager, GPA (GNU Privacy Assistant), Seahorse, and other security-based softwares in a separate menu entry titled Security Seahorse is on track to replace gnome-keyring-manager http://lwn.net/Articles/218548/, and seems to do most (if not all) of the same stuff as GPA too. If you need to have more than one of those programs installed, that's a problem with the programs, not with the default menu layout. where all security-based tools including tools for SELinux are there. ... If SELinux needs any GUI outside of Nautilus's Properties windows, that's probably a flaw in SELinux. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ PGP.sig Description: This is a digitally signed message part -- 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: Broken Packages Dependencies
On Sat, 2007-05-19 at 12:58 +0200, Thilo Six wrote: Tell me the bug number then i will set to confirmed. Bug 115,754: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/115754 -- Alec Wright -- 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: ReadyBoost Technology for Ubuntu and Linux
Il giorno sab, 19/05/2007 alle 12.29 +1000, Chris Jones ha scritto: I am rather impressed with the ReadyBoost technology that has been implemented into Windows Vista. And providing you get an appropriate and compatible memory stick to make good use of the technology, it actually works. Vista's boot is anything but fast :) On every pc (vendor preinstalled) i tested it, it kept at least two minutes. -- Davide Coriodavide.corioatredomino.com Redomino S.r.l. Largo Valgioie 14 - 10146 Torino - Italy Tel: +39 011 7499875 - Fax: +39 011 3716911 http://www.redomino.com/ -- 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: we should set a grub password by default
* [Sven] Iam allready averted from the request of setting it by default. My proposal is: Making grub password an optional but easy to configure feature. The setup of the grub password should assist people, inform them about the additional step of bios-boot configuration, inform them about the remaining risk of physical access. I claim bike shed discussion on this thread. That is, lots of discussion about an issue because it's unimportant and easy to understand, so everyone sees a chance to state their opinion with little risk of having to defend a bad decision later. As has been stated in the thread, people who care either way can easily change the default after install. For home users, grub passwords are likely to be confusing, and I'd personally forget it after a while since it's unlikely to be automatically changed when I change the user password. Support for adding grub passwords when scripting the installer for large deployments would be useful. And the bike shed should be red, I think. Goes well with my coat. Øystein -- ssh -c rot13 otherhost -- 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 Sat, 2007-05-19 at 12:34 +0100, Matt Zimmerman wrote: - Exactly which pieces are used by GTK, Qt, XUL, etc. and how applications using those APIs ask for a font specification You forgot the following, which is what GTK+ uses ... - Pango, a text layout and rendering engine with an emphasis on Internationalisation. Given a string of UTF-8 text, and a preference of fonts, it selects appropriate fonts to cover the characters being written and renders them to the screen. Uses combination of fontconfig, freetype, Xft and Cairo (some languages have native non-font renderers) Also another question: - Why are there so many differences of opinion about how much hinting fonts require, which method of hinting to use, and which of the results looks better Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -- 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: xmms into universe?
Op woensdag 16-05-2007 om 11:27 uur [tijdzone +0100], schreef Matt Zimmerman: On Tue, May 15, 2007 at 10:07:59PM +0200, Jan Claeys wrote: ... isn't it possible to change the FLAC dependency on XMMS to a dependency on/from Beep (or Audacious?) and get that patch accepted upstream (in either FLAC, Beep or Audacious)? (The XMMS plugin is also the Beep plugin now...) I didn't realize that XMMS and Beep plugins were interchangeable. Doing this in FLAC would require moving beep-media-player to main, but it would be worth talking to Beep and FLAC upstreams to see if they would be interested in moving the plugin to the Beep tree. To be clear, I was talking about the classic Beep Media Player. It seems like there is a new Beep Media Player that isn't a WinAmp clone anymore--I have no idea if this BMPx still uses the same plugins. Audacious is a fork of the BMP Classic, seems to be actively maintained, and I think it already comes with a FLAC plugin? So, currently we have packages for 3 programs with the same roots, but judging from their respective websites only the newest fork (Audacity) is really actively maintained... -- Jan Claeys -- 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: xmms into universe?
Op zondag 20-05-2007 om 21:54 uur [tijdzone +], schreef William Tracy: On 5/20/07, Jan Claeys [EMAIL PROTECTED] wrote: So, currently we have packages for 3 programs with the same roots, but judging from their respective websites only the newest fork (Audacity) is really actively maintained... I assume that was just a typo, but just to be clear, Audacious and Audacity are two different programs. :-) Of course. (And it should be forbidden to name 2 audio-related programs with such similar names! ;-) ) -- Jan Claeys -- 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: RFC: alias tar=tar --backup ?
On 5/20/07, Jan Claeys [EMAIL PROTECTED] wrote: http://fuse.sourceforge.net/wiki/index.php/FileSystems Includes at least 3 versioned filesystems... Ooh, somebody's implementing ZFS over Fuse as well! http://www.wizy.org/wiki/ZFS_on_FUSE -- William Tracy [EMAIL PROTECTED] -- [EMAIL PROTECTED] Whatever the missing mass of the universe is, I hope it's not cockroaches! -- Mom -- 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: RFC: alias tar=tar --backup ?
Op vrijdag 18-05-2007 om 04:42 uur [tijdzone +], schreef William Tracy: Of course a completely different approach would be a file system capable of roll-back, and in doing that, a user may well benefit from the backup services such a solution offers. [...] Actually, I off and on wonder if it would be possible to implement a filesystem over Subversion, and then just mount /home on that. I'm sure there's all kinds of gotchas with that idea, but it would be really cool. http://fuse.sourceforge.net/wiki/index.php/FileSystems Includes at least 3 versioned filesystems... -- Jan Claeys -- 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
There has been some confusion and dissatisfaction over the treatment of fonts in Ubuntu for a some time now, and no common understanding of how to improve the situation. I spent a little time thinking about this today, and would like to present some questions whose answers I hope will help us to make some progress. Please correct me where I've misunderstood, as I've only done some cursory research here. Hi Matt and everyone, Thanks for raising these key issues. Here are some initial thoughts and pointers from my perspective. We seem to have: - Loads of fonts, in various formats (TrueType, Type-1/PostScript, PCF bitmap, Metafont, others?) supporting various character sets, of varying quality - fontconfig, a font management framework which seems to be used by of the applications we care about in one way or another. It catalogues the fonts on the system and is independent of any window system, font rasterizer, etc. It just knows about fonts and provides an API to find a font based on complicated matching criteria. - DeFoMa, which attempts to allow packages to register fonts with whatever font management frameworks might exist. - TeX. Enough said. It's worth pointing out that with the new texlive2007 in Debian unstable, it's also possible to access TrueType/OpenType fonts from TeX (including smart fonts) via extensions like Xetex: http://packages.debian.org/unstable/tex/texlive-xetex (hats off to the Debian Tex task force!) - freetype, a font rasterization engine which also has some font management capabilities, also used by most applications we care about. Knows how to take fonts and strings and create bitmaps. - Xfont, which provides font services (including selection and rendering) through the X server. This is basically obsolete in favour of client-side fonts. - Xft, a font API for X applications which uses freetype and supports Xrender or plain X drawing to put text on a display. I don't know: - Exactly which pieces are used by GTK, Qt, XUL, etc. and how applications using those APIs ask for a font specification - Which applications ask for which font specifications, and where that's configured (sometimes in the application itself, as in Firefox) There's unification happening via the TextLayout summits bringing together the key font experts in the community: http://www.freedesktop.org/wiki/TextLayout http://live.gnome.org/Boston2006/TextLayout Some blog entries on these meetings: http://labs.trolltech.com/blogs/2007/03/30/working-towards-a-unified-text-layout-engine-for-the-free-desktop-software-stack/ http://rants.scribus.net/2006/10/31/boston-text-layout-summit/ http://mces.blogspot.com/2007/04/metrics-hinting-and-kerning-do-mix.html The next one will be hosted by Akademy 2007 and there will be a report during GUADEC 2007: http://www.guadec.org/node/659 - Which fonts are any good, and for which languages (no easy answer here) Yes, we need an ongoing review and it's no easy task. Some initial work has been started here: http://www.freedesktop.org/wiki/Software/Fonts http://wiki.debian.org/DebianInstaller/GUIFonts http://unifont.org/fontguide/ And there are various ITPs underway for these fonts. I really think the current selection of fonts in a default install needs some serious fixing. Certain packages need to be split, renamed, others need to be moved back to universe as they are more decorative. The way they tie in with langpacks probably also needs review. - Which criteria are important for selecting which font to use in which context (language, character set, ...) I'd say license freeness, unicode coverage, glyph quality, availability of smarts. We probably need a large-scale poll among translators, LocoTeams and users. Although at this stage - but I hope everything is getting in place for a change - for some locales a less than beautiful and feature-rich font is always better than nothing. This is why engaging (funding?) more artists and script experts to design fonts for Debian/Ubuntu is important. The more fonts are available the better the various font-related elements in the free desktop stack can get tested. At the LGM (Libre Graphics Meeting in Montréal) at the beginning of the month there was discussion about setting up a common font QA website between projects like scribus, OOo, OFLB, fontconfig and fontforge. A central place to report troubles with fonts. - Whether fontconfig requires adjustments in order to respect those criteria One key aspect is having a saner font menu by default along with the ability to do more granular font management based on the font metadata. Some of the thinking on this is available on https://wiki.ubuntu.com/FontManagement This fontconfig bug on glyph blacklisting is probably relevant to the language contexts: https://bugs.freedesktop.org/show_bug.cgi?id=7528 Also the fontconfig snippets should go upstream to reduce the deltas with other
