From loupgaroublond at gmail.com Wed Jul 2 15:42:42 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 2 Jul 2008 17:42:42 +0200 Subject: [Fedora-packaging] Submission of Haskell Packaging Guidelines for Review Message-ID: <7f692fec0807020842u5d3a6199r82d3e7bd19a67b79@mail.gmail.com> Hi Lists, I would like to submit the current draft of the Haskell Packaging Guidelines for a formal review. I have the packages listed on the DraftsToDo site, and everything you need should be contained within the wiki. The guidelines can be found here: https://fedoraproject.org/wiki/PackagingDrafts/Haskell There are still a few outstanding questions, but I think they could be better answered by the Packaging Committee rather than myself. Please let me know if there are to be any official meetings to discuss details about this, so I can be present. -Yaakov From tibbs at math.uh.edu Wed Jul 2 16:33:04 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jul 2008 11:33:04 -0500 Subject: [Fedora-packaging] Submission of Haskell Packaging Guidelines for Review In-Reply-To: <7f692fec0807020842u5d3a6199r82d3e7bd19a67b79@mail.gmail.com> References: <7f692fec0807020842u5d3a6199r82d3e7bd19a67b79@mail.gmail.com> Message-ID: >>>>> "YN" == Yaakov Nemoy writes: YN> There are still a few outstanding questions, but I think they YN> could be better answered by the Packaging Committee rather than YN> myself. Could you perhaps post the outstanding questions? It's a bit tough to figure out what's what, and wiki conversion has flattened any nested lists so the comments section just looks like a bunch of bullets.. Also, the new wiki has a proper discussion page; it might be simpler to use that and keep the main page for just the stuff that's actually guidelines. I see the last thing on the page is a request for FPC to comment on the casing of package names. I note that unfortuantely there is little concensus; Perl packages keep the upstream casing, but Perl package naming is relatively consistent. Python packages are generally, but not consistently, downcased. Personally I'd prefer just downcasing things, especially if there's no upstream consistency and the tools employed already downcase things. YN> Please let me know if there are to be any official meetings to YN> discuss details about this, so I can be present. Next meeting is July 15th, 17:00UTC. Is it possible to get a couple of packages made according to these guidelines? I know there are a few in the queue, but I'm not sure how they jibe with the proposed guidelines. - J< From loupgaroublond at gmail.com Wed Jul 2 18:00:46 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 2 Jul 2008 20:00:46 +0200 Subject: [Fedora-packaging] Submission of Haskell Packaging Guidelines for Review In-Reply-To: References: <7f692fec0807020842u5d3a6199r82d3e7bd19a67b79@mail.gmail.com> Message-ID: <7f692fec0807021100m1615a113tee6c2a2a519ddc2a@mail.gmail.com> On Wed, Jul 2, 2008 at 6:33 PM, Jason L Tibbitts III wrote: >>>>>> "YN" == Yaakov Nemoy writes: > > YN> There are still a few outstanding questions, but I think they > YN> could be better answered by the Packaging Committee rather than > YN> myself. > > Could you perhaps post the outstanding questions? It's a bit tough to > figure out what's what, and wiki conversion has flattened any nested > lists so the comments section just looks like a bunch of bullets.. > Also, the new wiki has a proper discussion page; it might be simpler > to use that and keep the main page for just the stuff that's actually > guidelines. > > I see the last thing on the page is a request for FPC to comment on > the casing of package names. I note that unfortuantely there is > little concensus; Perl packages keep the upstream casing, but Perl > package naming is relatively consistent. Python packages are > generally, but not consistently, downcased. For now, i'm leaving it set as downcased, just for sanity. If there is enough drive to make it mixed case, I'll change it, but only if there is some overwhelming majority or executive decision. > Personally I'd prefer just downcasing things, especially if there's no > upstream consistency and the tools employed already downcase things. > > YN> Please let me know if there are to be any official meetings to > YN> discuss details about this, so I can be present. > > Next meeting is July 15th, 17:00UTC. I'll try to be there. > Is it possible to get a couple of packages made according to these > guidelines? I know there are a few in the queue, but I'm not sure how > they jibe with the proposed guidelines. I need to update the ones sitting for package review. The latest version can be found at: http://ynemoy.fedorapeople.org/repo/ It's also a repo, so if you want to install them, yum will be able to track them. The haskell packages are: ghc-x11 ghc-xmonad ghc-xmonad-contrib xmobar xmonad The spec files used to build these packages are the ones also in the guidelines on the wiki (with the notable exception of xmonad-contrib.) Anyhow, I'll fix up the comments in a bit. -Yaakov From nicolas.mailhot at laposte.net Fri Jul 4 09:56:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 04 Jul 2008 11:56:26 +0200 Subject: [Fedora-packaging] Fonts packaging amendment Message-ID: <1215165386.3777.6.camel@rousalka.okg> Hi, I'm proposing the following amendment: http://fedoraproject.org/wiki/PackagingDrafts/Packaging_font_bundles to our fonts packaging policy: http://fedoraproject.org/wiki/Packaging/FontsPolicy (official page, broken by the wiki migration) http://fedoraproject.org/wiki/Fonts_packaging_policy (unofficial cleaned-up font page ; I hope someone will the right accesses picks it up) Nothing earth-shattering, just a write-up of our current unwritten rules Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From green at redhat.com Sun Jul 6 13:26:01 2008 From: green at redhat.com (Anthony Green) Date: Sun, 06 Jul 2008 06:26:01 -0700 Subject: [Fedora-packaging] New Lisp packaging guidelines draft Message-ID: <4870C7E9.6000100@redhat.com> I've rewritten the Lisp guidelines based on feedback from the first time around: http://fedoraproject.org/wiki/PackagingDrafts/Lisp I've also subscribed to this list, so I can collect feedback here. Thanks, AG From rdieter at math.unl.edu Mon Jul 7 13:51:33 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 07 Jul 2008 08:51:33 -0500 Subject: [Fedora-packaging] Re: Fonts packaging amendment References: <1215165386.3777.6.camel@rousalka.okg> Message-ID: Nicolas Mailhot wrote: > I'm proposing the following amendment: > http://fedoraproject.org/wiki/PackagingDrafts/Packaging_font_bundles shrug, putting common sense into policy usually rubs me the wrong way, but no objections. -- Rex From nicolas.mailhot at laposte.net Mon Jul 7 19:20:06 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jul 2008 21:20:06 +0200 (CEST) Subject: [Fedora-packaging] Re: Fonts packaging amendment In-Reply-To: References: <1215165386.3777.6.camel@rousalka.okg> Message-ID: <48067.192.54.193.58.1215458406.squirrel@rousalka.dyndns.org> Le Lun 7 juillet 2008 15:51, Rex Dieter a ?crit : > > Nicolas Mailhot wrote: > >> I'm proposing the following amendment: >> http://fedoraproject.org/wiki/PackagingDrafts/Packaging_font_bundles > > shrug, putting common sense into policy usually rubs me the wrong way, > but no objections. Well, I had actual would be packagers ask this, and pointing to guidelines is easier than trying to convince them they're doing something stupid. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Jul 7 19:43:50 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jul 2008 21:43:50 +0200 (CEST) Subject: [Fedora-packaging] Re: Fonts packaging amendment In-Reply-To: <48067.192.54.193.58.1215458406.squirrel@rousalka.dyndns.org> References: <1215165386.3777.6.camel@rousalka.okg> <48067.192.54.193.58.1215458406.squirrel@rousalka.dyndns.org> Message-ID: <51908.192.54.193.58.1215459830.squirrel@rousalka.dyndns.org> BTW this point was raised in a review lately https://bugzilla.redhat.com/show_bug.cgi?id=454148#c9 I don't care about it much, and the review went nowhere, but if someone cares... -- Nicolas Mailhot From petersen at redhat.com Tue Jul 8 00:47:21 2008 From: petersen at redhat.com (Jens Petersen) Date: Tue, 8 Jul 2008 10:47:21 +1000 Subject: [Fedora-packaging] Fonts packaging amendment In-Reply-To: <1215165386.3777.6.camel@rousalka.okg> References: <1215165386.3777.6.camel@rousalka.okg> Message-ID: <20080708104721.40527c7e@dhcp-0-235.bne.redhat.com> On Fri, 04 Jul 2008 11:56:26 +0200 Nicolas Mailhot wrote: > I'm proposing the following amendment: > http://fedoraproject.org/wiki/PackagingDrafts/Packaging_font_bundles It looks good to me and makes sense: there is plenty of confusion in this area for fonts. Jens From cra at WPI.EDU Tue Jul 8 01:45:55 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 7 Jul 2008 21:45:55 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations Message-ID: <20080708014555.GH32483@angus.ind.WPI.EDU> Where should icons for desktop files be stored? Some packages use /usr/share/pixmaps. Others use subdirectories under /usr/share/pixmaps (some directories are unowned too). Some use a private directory under /usr/share/. Still others use /usr/share/icons/. Icon=/usr/share/sane/xsane/xsane-logo.xpm >rpm -ql gnome-utils | grep /usr/share/pixmaps /usr/share/pixmaps/gsearchtool/thumbnail_frame.png file /usr/share/pixmaps/gsearchtool is not owned by any package How should the icon be referred to in a desktop file? Some use absolute paths, others no path at all. desktop-file-install complains if there is a relative or partial path. Icon=/usr/share/system-config-lvm/pixmaps/lv_icon.png Icon=/usr/share/system-config-selinux/system-config-selinux.png Some desktop file icons don't use an extention, but some do: Icon=accessories-calculator Icon=accessories-dictionary.png It looks like the majority of the desktop files on my F9 system are using the form without an extension. All of this is confusing. For new applications, what should they use? What are the semantics for the various syntaxes that are used? What should be done for upstream packages that have icons? What if they are in xpm format rather than png? Thanks. From tgl at redhat.com Tue Jul 8 02:06:28 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 07 Jul 2008 22:06:28 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <20080708014555.GH32483@angus.ind.WPI.EDU> References: <20080708014555.GH32483@angus.ind.WPI.EDU> Message-ID: <27770.1215482788@sss.pgh.pa.us> Chuck Anderson writes: > Where should icons for desktop files be stored? Some packages use > /usr/share/pixmaps. Others use subdirectories under > /usr/share/pixmaps (some directories are unowned too). Some use a > private directory under /usr/share/. Still others use > /usr/share/icons/. Red Hat's rpmdiff tool has recently started to complain if desktop icon files are not underneath /usr/share/pixmaps/, so apparently there is policy to that effect somewhere. Unowned directories are certainly verboten too. I have no idea if there's any existing policy about your other questions. One point: I'd suggest that we *not* require conversion of upstream icon files to a uniform file format, so long as what upstream supplies will work (ie, please no "thou shalt convert xpm to png" in the guidelines). Doing that would require BuildRequire'ing some image conversion package or other, which seems like a pretty heavyweight build dependency for hardly any real gain. regards, tom lane From tcallawa at redhat.com Tue Jul 8 02:11:34 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 Jul 2008 22:11:34 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <27770.1215482788@sss.pgh.pa.us> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> Message-ID: <1215483094.31483.3.camel@localhost.localdomain> On Mon, 2008-07-07 at 22:06 -0400, Tom Lane wrote: > One point: I'd suggest that we *not* require conversion of upstream > icon files to a uniform file format, so long as what upstream supplies > will work (ie, please no "thou shalt convert xpm to png" in the > guidelines). I'm pretty sure that png and xpm are supported at a minimum, possibly other formats as well. ~spot From cra at WPI.EDU Tue Jul 8 02:33:14 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 7 Jul 2008 22:33:14 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <27770.1215482788@sss.pgh.pa.us> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> Message-ID: <20080708023314.GI32483@angus.ind.WPI.EDU> On Mon, Jul 07, 2008 at 10:06:28PM -0400, Tom Lane wrote: > Chuck Anderson writes: > > Where should icons for desktop files be stored? Some packages use > > /usr/share/pixmaps. Others use subdirectories under > > /usr/share/pixmaps (some directories are unowned too). Some use a > > private directory under /usr/share/. Still others use > > /usr/share/icons/. > > Red Hat's rpmdiff tool has recently started to complain if desktop > icon files are not underneath /usr/share/pixmaps/, so apparently there > is policy to that effect somewhere. Unowned directories are certainly > verboten too. I have no idea if there's any existing policy about your > other questions. Do you mean rpmlint? It seems most are under /usr/share/icons, so the tool should probably be updated if that's true. > One point: I'd suggest that we *not* require conversion of upstream > icon files to a uniform file format, so long as what upstream supplies > will work (ie, please no "thou shalt convert xpm to png" in the > guidelines). Doing that would require BuildRequire'ing some image > conversion package or other, which seems like a pretty heavyweight > build dependency for hardly any real gain. Ok, some more mystery behind this. There are several sets of utilities to deal with icons and desktop files: gtk2: /usr/bin/gtk-update-icon-cache desktop-file-utils: Summary : Utilities for manipulating .desktop files Description : .desktop files are used to describe an application for inclusion in GNOME or KDE menus. This package contains desktop-file-validate which checks whether a .desktop file complies with the specification at http://www.freedesktop.org/standards/, and desktop-file-install which installs a desktop file to the standard directory, optionally fixing it up in the process. xdg-utils: Summary : Basic desktop integration functions Description : The xdg-utils package is a set of simple scripts that provide basic desktop integration functions for any Free Desktop, such as Linux. They are intended to provide a set of defacto standards. This means that: * Third party software developers can rely on these xdg-utils for all of their simple integration needs. * Developers of desktop environments can make sure that their environments are well supported * Distribution vendors can provide custom versions of these utilities The following scripts are provided at this time: * xdg-desktop-menu Install desktop menu items * xdg-desktop-icon Install icons to the desktop * xdg-icon-resource Install icon resources * xdg-mime Query information about file type handling and install descriptions for new file types * xdg-open Open a file or URL in the user's preferred application * xdg-email Send mail using the user's preferred e-mail composer * xdg-screensaver Control the screensaver I was about to think "oh, xdg-utils must be the replacement/superset of desktop-file-utils + gtk-update-icon-cache". It seems xdg-utils is being used by KDE[1] but not GNOME[2]. And Oo.org isn't using desktop-file-install but it is using gtk-update-icon-cache[3]. So my question is, in what direction is all of this stuff going, and what should I use for my package[4] which just has two simple .xpm icons, one of which is referenced by a relative path in the .desktop file? I need to fix the relative path becuase desktop-file-install doesn't like it, but the question is, how should I fix it? [1] http://cvs.fedoraproject.org/viewcvs/devel/kdebase/kdebase.spec?rev=1.333&view=auto [2] http://cvs.fedoraproject.org/viewcvs/devel/gnome-applets/gnome-applets.spec?rev=1.288&view=auto http://cvs.fedoraproject.org/viewcvs/devel/gedit/gedit.spec?rev=1.157&view=auto [3] http://cvs.fedoraproject.org/viewcvs/devel/openoffice.org/openoffice.org.spec?rev=1.1567&view=auto [4] https://bugzilla.redhat.com/show_bug.cgi?id=452749 From tgl at redhat.com Tue Jul 8 02:44:40 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 07 Jul 2008 22:44:40 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <1215483094.31483.3.camel@localhost.localdomain> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> <1215483094.31483.3.camel@localhost.localdomain> Message-ID: <28405.1215485080@sss.pgh.pa.us> "Tom \"spot\" Callaway" writes: > On Mon, 2008-07-07 at 22:06 -0400, Tom Lane wrote: >> One point: I'd suggest that we *not* require conversion of upstream >> icon files to a uniform file format, so long as what upstream supplies >> will work (ie, please no "thou shalt convert xpm to png" in the >> guidelines). > I'm pretty sure that png and xpm are supported at a minimum, possibly > other formats as well. Hmmm ... using file(1) on an F-8 workstation I find this under /usr/share/pixmaps and /usr/share/icons: 141 ASCII text (.theme and .icon extensions) 229 GLS_BINARY_LSB_FIRST (no idea what these are) 19 JPEG 8890 PNG 1 TIFF 12 TrueType font data (icon-theme.cache files) 16 X (.xpm) 686 XML (.svg) 236 gzip (.svgz) How many of these icons actually work as expected is an interesting question, but clearly there's a variety of formats that packages *think* are supported. PNG is by far the majority though, and it looks like the usages of the stranger formats are confined to a few packages each. Maybe we *should* standardize on PNG here --- it appears that only a few packages would be affected by a conversion requirement. regards, tom lane From katzj at redhat.com Tue Jul 8 02:49:52 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 07 Jul 2008 22:49:52 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <28405.1215485080@sss.pgh.pa.us> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> <1215483094.31483.3.camel@localhost.localdomain> <28405.1215485080@sss.pgh.pa.us> Message-ID: <1215485392.13098.9.camel@aglarond.local> On Mon, 2008-07-07 at 22:44 -0400, Tom Lane wrote: > "Tom \"spot\" Callaway" writes: > > On Mon, 2008-07-07 at 22:06 -0400, Tom Lane wrote: > >> One point: I'd suggest that we *not* require conversion of upstream > >> icon files to a uniform file format, so long as what upstream supplies > >> will work (ie, please no "thou shalt convert xpm to png" in the > >> guidelines). > > > I'm pretty sure that png and xpm are supported at a minimum, possibly > > other formats as well. > > Hmmm ... using file(1) on an F-8 workstation I find this under > /usr/share/pixmaps and /usr/share/icons: [snip] > How many of these icons actually work as expected is an interesting > question, but clearly there's a variety of formats that packages *think* > are supported. PNG is by far the majority though, and it looks like the > usages of the stranger formats are confined to a few packages each. > Maybe we *should* standardize on PNG here --- it appears that only a few > packages would be affected by a conversion requirement. SVG is also definitely a reasonable alternative to png -- it gives scalable icons which will be more important as we begin to get devices with resolutions on both the high and the low end of the spectrum Jeremy From tgl at redhat.com Tue Jul 8 02:57:52 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 07 Jul 2008 22:57:52 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <20080708023314.GI32483@angus.ind.WPI.EDU> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> <20080708023314.GI32483@angus.ind.WPI.EDU> Message-ID: <28601.1215485872@sss.pgh.pa.us> Chuck Anderson writes: > On Mon, Jul 07, 2008 at 10:06:28PM -0400, Tom Lane wrote: >> Red Hat's rpmdiff tool has recently started to complain if desktop >> icon files are not underneath /usr/share/pixmaps/, so apparently there >> is policy to that effect somewhere. > Do you mean rpmlint? No, I meant rpmdiff, which is an internal tool that vets RPMs in various ways (principally, but not solely, by comparison to the previous release of the package --- hence the name). I got blindsided by the /pixmaps check recently while rebuilding unixODBC for RHEL-5, so I'm quite sure this is a new policy ... regards, tom lane From mclasen at redhat.com Tue Jul 8 03:11:39 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 07 Jul 2008 23:11:39 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <20080708023314.GI32483@angus.ind.WPI.EDU> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> <20080708023314.GI32483@angus.ind.WPI.EDU> Message-ID: <1215486699.3293.10.camel@localhost.localdomain> On Mon, 2008-07-07 at 22:33 -0400, Chuck Anderson wrote: > > One point: I'd suggest that we *not* require conversion of upstream > > icon files to a uniform file format, so long as what upstream supplies > > will work (ie, please no "thou shalt convert xpm to png" in the > > guidelines). Doing that would require BuildRequire'ing some image > > conversion package or other, which seems like a pretty heavyweight > > build dependency for hardly any real gain. Supported formats for themed icons are xpm, png and svg. Thus, if you install the icon below /usr/share/icons/hicolor/ it should be in one of those formats. If you install it in /usr/share/pixmaps, it can really be anything, but traditionally, that directory is for xpms. In the desktop file, the icon should be either specified as a full path (including extension) or as an icon name (without extension), the latter being preferred. From tgl at redhat.com Tue Jul 8 03:43:37 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 07 Jul 2008 23:43:37 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <1215486699.3293.10.camel@localhost.localdomain> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> <20080708023314.GI32483@angus.ind.WPI.EDU> <1215486699.3293.10.camel@localhost.localdomain> Message-ID: <29328.1215488617@sss.pgh.pa.us> Matthias Clasen writes: > Supported formats for themed icons are xpm, png and svg. Thus, if you > install the icon below /usr/share/icons/hicolor/ it should be in one of > those formats. If you install it in /usr/share/pixmaps, it can really be > anything, but traditionally, that directory is for xpms. In the desktop > file, the icon should be either specified as a full path (including > extension) or as an icon name (without extension), the latter being > preferred. I guess the appropriate question for this list is "where is all that documented?" regards, tom lane From mclasen at redhat.com Tue Jul 8 04:29:15 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 08 Jul 2008 00:29:15 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <29328.1215488617@sss.pgh.pa.us> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> <20080708023314.GI32483@angus.ind.WPI.EDU> <1215486699.3293.10.camel@localhost.localdomain> <29328.1215488617@sss.pgh.pa.us> Message-ID: <1215491355.3293.12.camel@localhost.localdomain> On Mon, 2008-07-07 at 23:43 -0400, Tom Lane wrote: > Matthias Clasen writes: > > Supported formats for themed icons are xpm, png and svg. Thus, if you > > install the icon below /usr/share/icons/hicolor/ it should be in one of > > those formats. If you install it in /usr/share/pixmaps, it can really be > > anything, but traditionally, that directory is for xpms. In the desktop > > file, the icon should be either specified as a full path (including > > extension) or as an icon name (without extension), the latter being > > preferred. > > I guess the appropriate question for this list is "where is all that > documented?" http://standards.freedesktop.org/desktop-entry-spec/latest/ is the spec describing .desktop files http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html is the spec describing icon themes From cra at WPI.EDU Tue Jul 8 05:05:55 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 8 Jul 2008 01:05:55 -0400 Subject: [Fedora-packaging] desktop file icon/pixmap locations In-Reply-To: <1215491355.3293.12.camel@localhost.localdomain> References: <20080708014555.GH32483@angus.ind.WPI.EDU> <27770.1215482788@sss.pgh.pa.us> <20080708023314.GI32483@angus.ind.WPI.EDU> <1215486699.3293.10.camel@localhost.localdomain> <29328.1215488617@sss.pgh.pa.us> <1215491355.3293.12.camel@localhost.localdomain> Message-ID: <20080708050555.GJ32483@angus.ind.WPI.EDU> On Tue, Jul 08, 2008 at 12:29:15AM -0400, Matthias Clasen wrote: > On Mon, 2008-07-07 at 23:43 -0400, Tom Lane wrote: > > Matthias Clasen writes: > > > Supported formats for themed icons are xpm, png and svg. Thus, if you > > > install the icon below /usr/share/icons/hicolor/ it should be in one of > > > those formats. If you install it in /usr/share/pixmaps, it can really be > > > anything, but traditionally, that directory is for xpms. In the desktop > > > file, the icon should be either specified as a full path (including > > > extension) or as an icon name (without extension), the latter being > > > preferred. > > > > I guess the appropriate question for this list is "where is all that > > documented?" > > http://standards.freedesktop.org/desktop-entry-spec/latest/ > is the spec describing .desktop files > > http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html > is the spec describing icon themes Thanks for the pointer. I've decided to follow this spec for installing upstream's xpm icons into /usr/share/icons/hicolor/{16x16,48x48}/apps. From rjones at redhat.com Tue Jul 8 15:58:20 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Jul 2008 16:58:20 +0100 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft Message-ID: <20080708155820.GA17077@amd.home.annexia.org> https://fedoraproject.org/wiki/PackagingDrafts/MinGW Comments welcome. It's at a rather early stage at the moment. There are some packages already if you'd like to take a look at them: http://hg.et.redhat.com/misc/fedora-mingw--devel I have some misgivings (actually a lot of misgivings) about the use of the /usr/i686-pc-mingw32 directory. See Ralf's reply to my email here for some justification: http://sourceware.org/ml/binutils/2008-07/msg00105.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rc040203 at freenet.de Tue Jul 8 16:20:27 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 Jul 2008 18:20:27 +0200 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft In-Reply-To: <20080708155820.GA17077@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> Message-ID: <1215534027.2809.388.camel@beck.corsepiu.local> On Tue, 2008-07-08 at 16:58 +0100, Richard W.M. Jones wrote: > https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > Comments welcome. It's at a rather early stage at the moment. > > There are some packages already if you'd like to take a look at them: > > http://hg.et.redhat.com/misc/fedora-mingw--devel Just one remark based on hastly browsing your draft (I haven't read the details yet): The name mingw32 is related to 2 items: - It's the historic name mingw had inherited from its past. Technically it is required to make config.sub working when being fed with mingw-related target triplets. [try /usr/share/automake-1.10/config.sub i686-mingw rsp. i686-mingw32] - There seem to be efforts related to implementing a 64bit mingw, addressing 64bit Windows. (I don't know if they made progress, I only saw patches related to an x86_64/64bit mingw being submitted to different toolchain mailing-lists) > I have some misgivings (actually a lot of misgivings) about the use of > the /usr/i686-pc-mingw32 directory. See Ralf's reply to my email here > for some justification: > > http://sourceware.org/ml/binutils/2008-07/msg00105.html FWIW: Any cross-toolchain uses a similar directory. Ralf From rakesh.pandit at gmail.com Wed Jul 9 16:06:12 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Wed, 9 Jul 2008 21:36:12 +0530 Subject: [Fedora-packaging] Regarding PHP guidelines -- pear packages Message-ID: Hello all, I had a confusion regarding PHP libraries which have a pending draft at pear.php.net but haven't been yet included in pear. May we go ahead packaging them as pear? Or package them as non pear PHP libraries and wait for proposal to pass? Or it is upto packager? For example php-openid[1] or php-oauth[2] has a proposed status for pear. OpenID review is already going on and i am a bit impatient getting oauth also in ;-) Suggestions? May be PHP Packaging wiki page[3] requires some update regarding this. Thanks. [1] http://pear.php.net/pepr/pepr-proposal-show.php?id=500 [2] http://pear.php.net/pepr/pepr-proposal-show.php?id=512 [3] https://fedoraproject.org/wiki/Packaging/PHP -- Regards, Rakesh Pandit From Axel.Thimm at ATrpms.net Wed Jul 9 21:26:29 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 Jul 2008 00:26:29 +0300 Subject: [Fedora-packaging] Re: Regarding PHP guidelines -- pear packages In-Reply-To: References: Message-ID: <20080709212629.GA3755@victor.nirvana> On Wed, Jul 09, 2008 at 09:36:12PM +0530, Rakesh Pandit wrote: > Hello all, > > I had a confusion regarding PHP libraries which have a pending > draft at pear.php.net but haven't been yet included in pear. May we go > ahead packaging them as pear? Or package them as non pear PHP > libraries and wait for proposal to pass? Or it is upto packager? > For example php-openid[1] or php-oauth[2] has a proposed status > for pear. FWIW when php-openid was first packaged the then actual version was in pear. I don't know why it was removed, but one of the TODO items upstream was to get it back in officially. > OpenID review is already going on and i am a bit impatient > getting oauth also in ;-) > > Suggestions? I'm interpreting "pear" as used within the FP guidelines as a packaging technology and not as a name of a collection. Otherwise we would have to rename packages back and forth everytime there is a change in the pear collection. > May be PHP Packaging wiki page[3] requires some update regarding this. If the FPC agrees, then the technology vs collection nomenclature should be added to clarify. > Thanks. > > [1] http://pear.php.net/pepr/pepr-proposal-show.php?id=500 > [2] http://pear.php.net/pepr/pepr-proposal-show.php?id=512 > [3] https://fedoraproject.org/wiki/Packaging/PHP > -- Axel.Thimm at ATrpms.net From Axel.Thimm at ATrpms.net Wed Jul 9 21:30:02 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 Jul 2008 00:30:02 +0300 Subject: [Fedora-packaging] Re: Early MinGW packaging guidelines draft In-Reply-To: <20080708155820.GA17077@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> Message-ID: <20080709213002.GB3755@victor.nirvana> On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote: > I have some misgivings (actually a lot of misgivings) about the use of > the /usr/i686-pc-mingw32 directory. Is this maybe something that needs to be taken to the FHS? We could be setting into stone paths that maybe the next FHS will be placing elsewhere. Although my personal experience with the FHS showed me that it is very difficult for an outsider to get anything discussed on the FHS table. But I think Red Hat has someone in FHS, so if you ping him, maybe there will be some reaction. -- Axel.Thimm at ATrpms.net From Axel.Thimm at ATrpms.net Wed Jul 9 21:57:57 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 Jul 2008 00:57:57 +0300 Subject: [Fedora-packaging] supporting closed source operating systems? (was: Early MinGW packaging guidelines draft) In-Reply-To: <20080708155820.GA17077@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> Message-ID: <20080709215757.GC3755@victor.nirvana> On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote: > https://fedoraproject.org/wiki/PackagingDrafts/MinGW What is Fedora's motivation is promoting using Open Source on a closed source operating system? This is beyond the FPC to decide as this is a technical committee, but still a valid question and maybe one that the board should be investigating. F/LOSS often had and has to compromise on its base principles to get a lift-off, and so does Fedora (the current exception for firmwares is such a compromise). Before there was a Linux kernel, the GNU project was "supporting" closed source Unices and by design still does so. But we're beyond the age of this kind of symbiosis, Linux (or GNU/Linux ...) and Fedora in particular doesn't need this anymore. In fact when a patch in a Fedora package is made it often doesn't matter if it works on other Unices, sometimes not even for the Free ones. In this case I don't see the benefits for Fedora. I just see more Open Source being hijacked for a non Open Source operating system. -- Axel.Thimm at ATrpms.net From green at redhat.com Wed Jul 9 22:40:54 2008 From: green at redhat.com (Anthony Green) Date: Wed, 09 Jul 2008 15:40:54 -0700 Subject: [Fedora-packaging] supporting closed source operating systems? (was: Early MinGW packaging guidelines draft) In-Reply-To: <20080709215757.GC3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> Message-ID: <48753E76.5040109@redhat.com> Regarding the packaging for mingw tools in Fedora, Axel Thimm wrote: > In this case I don't see the benefits for Fedora. I just see more Open > Source being hijacked for a non Open Source operating system. > It's an interesting question, but here's my two part counter-argument: 1. Our goal should be to benefit users of Fedora, and not just Fedora itself. In this case, the packager is simply proposing to include tools that will benefit developers who have the misfortune of needing to target the windows operating system. If I found myself in that unfortunate position, I would be very happy to find that Fedora packaged a nice set of fully FOSS tools for me to use. 2. The Open Source definition talks about discrimination against fields of endeavor. Strictly speaking, it's talking about discrimination encoded into software licenses. However, I like to think that the Fedora Project should adopt this principal in a more general way, since it is in keeping with the Open Source philosophy of freedom. But you're asking that Fedora not include a collection of fully FOSS tools because you don't like what people are going to use them for. Do we really want to set this precedent? I hope not. AG From smooge at gmail.com Wed Jul 9 22:45:26 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 9 Jul 2008 16:45:26 -0600 Subject: [Fedora-packaging] supporting closed source operating systems? (was: Early MinGW packaging guidelines draft) In-Reply-To: <20080709215757.GC3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> Message-ID: <80d7e4090807091545h59d0cd07s574f5439cd70840a@mail.gmail.com> On Wed, Jul 9, 2008 at 3:57 PM, Axel Thimm wrote: > On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote: >> https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > What is Fedora's motivation is promoting using Open Source on a closed > source operating system? This is beyond the FPC to decide as this is a > technical committee, but still a valid question and maybe one that the > board should be investigating. > Because people have to live in a world of compromise and have to install windows, solaris, etc in virtual environments, etc.. and if they can't well the company can go buy a closed source solution that will. Usually when that happens you can pack up all those Fedora, CentOS, etc systems on your way out :(. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From rich at annexia.org Wed Jul 9 22:51:51 2008 From: rich at annexia.org (Richard Jones) Date: Wed, 9 Jul 2008 23:51:51 +0100 Subject: [Fedora-packaging] supporting closed source operating systems? (was: Early MinGW packaging guidelines draft) In-Reply-To: <20080709215757.GC3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> Message-ID: <20080709225151.GB26746@annexia.org> On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote: > But we're beyond the age of this kind of symbiosis, Linux (or > GNU/Linux ...) and Fedora in particular doesn't need this anymore. The actual reality, real stuff in the real world, is that 90%+ of users of desktop computer systems run Windows, another 5%+ are running Mac OS X, and almost nobody (perhaps 10, 100 people in the whole world?) are running a completely free operating system (inc. BIOS etc). Rich. -- Richard Jones Red Hat From Axel.Thimm at ATrpms.net Wed Jul 9 23:06:50 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 Jul 2008 02:06:50 +0300 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080709225151.GB26746@annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> Message-ID: <20080709230650.GE3755@victor.nirvana> On Wed, Jul 09, 2008 at 11:51:51PM +0100, Richard Jones wrote: > On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote: > > But we're beyond the age of this kind of symbiosis, Linux (or > > GNU/Linux ...) and Fedora in particular doesn't need this anymore. > > The actual reality, real stuff in the real world, is that 90%+ of > users of desktop computer systems run Windows, another 5%+ are running > Mac OS X, and almost nobody (perhaps 10, 100 people in the whole > world?) are running a completely free operating system (inc. BIOS > etc). No one denies that, but don't we want to keep the fruits of F/LOSS to encourage more F/LOSS usage? Hijacking F/LOSS solutions back to closed source will not change the percentages above, on the contrary, you remove some of the good reasons to go Linux. -- Axel.Thimm at ATrpms.net From rdieter at math.unl.edu Wed Jul 9 23:17:30 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 Jul 2008 18:17:30 -0500 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080709215757.GC3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> Message-ID: <4875470A.5050500@math.unl.edu> Axel Thimm wrote: > On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote: >> https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > What is Fedora's motivation is promoting using Open Source on a closed > source operating system? Imo, motives don't matter here. If it's license-wise (and otherwise policy-wise) ok with fedora, then end of story. -- Rex From rjones at redhat.com Thu Jul 10 09:42:13 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 10 Jul 2008 10:42:13 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080709230650.GE3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> Message-ID: <20080710094213.GA27458@amd.home.annexia.org> On Thu, Jul 10, 2008 at 02:06:50AM +0300, Axel Thimm wrote: > On Wed, Jul 09, 2008 at 11:51:51PM +0100, Richard Jones wrote: > > On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote: > > > But we're beyond the age of this kind of symbiosis, Linux (or > > > GNU/Linux ...) and Fedora in particular doesn't need this anymore. > > > > The actual reality, real stuff in the real world, is that 90%+ of > > users of desktop computer systems run Windows, another 5%+ are running > > Mac OS X, and almost nobody (perhaps 10, 100 people in the whole > > world?) are running a completely free operating system (inc. BIOS > > etc). > > No one denies that, but don't we want to keep the fruits of F/LOSS to > encourage more F/LOSS usage? Hijacking F/LOSS solutions back to closed > source will not change the percentages above, on the contrary, you > remove some of the good reasons to go Linux. For what we're proposing -- libraries, not programs -- it's good to encourage programmers on closed systems to use open libraries. Take libvirt as an example. There are plenty of proprietary / encumbered competitors to libvirt which run on Windows -- eg. you can program directly to VMWare's APIs, or XenAPI. It's better though if we can encourage Windows programmers to program to the libvirt API instead of those proprietary competitors. It's one less piece of proprietary lock-in for those programmers, and one less thing to unscrew when they want to port their software to Linux. However, actually maintaining the libvirt port to Windows is currently a huge pain in the nether regions. It involves me having a Windows box (not a virtual machine, mind you, because Windows really doesn't run very well when virtualized), and because Windows doesn't adhere to any sort of standard, I have to copy all the libvirt code by hand to the Windows box, try to build it using a mix of tools (which have to be installed and upgraded by hand because there's no reasonable packaging system for Windows), then fix the libvirt code which has usually broken (because no one ever routinely compiles it for Windows), then hand copy the patches back to Linux, check they don't break anything on the Linux side, and then submit them upstream. As you can imagine, this is unpleasant, time-consuming, requires me to use a horrible proprietary system, etc. What we're proposing is a way to do this entirely within Fedora, so we use Fedora packages, on a Fedora host, with a Fedora command line, and Fedora tools. We can do nightly autobuilds to catch problems with the Windows port early, and automatically generate Windows packages. No actual use of Windows or other non-free software in sight. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From berrange at redhat.com Thu Jul 10 10:26:24 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 Jul 2008 11:26:24 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080709230650.GE3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> Message-ID: <20080710102624.GA5806@redhat.com> On Thu, Jul 10, 2008 at 02:06:50AM +0300, Axel Thimm wrote: > On Wed, Jul 09, 2008 at 11:51:51PM +0100, Richard Jones wrote: > > On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote: > > > But we're beyond the age of this kind of symbiosis, Linux (or > > > GNU/Linux ...) and Fedora in particular doesn't need this anymore. > > > > The actual reality, real stuff in the real world, is that 90%+ of > > users of desktop computer systems run Windows, another 5%+ are running > > Mac OS X, and almost nobody (perhaps 10, 100 people in the whole > > world?) are running a completely free operating system (inc. BIOS > > etc). > > No one denies that, but don't we want to keep the fruits of F/LOSS to > encourage more F/LOSS usage? Hijacking F/LOSS solutions back to closed > source will not change the percentages above, on the contrary, you > remove some of the good reasons to go Linux. On the contrary - we are providing a viable migration path to Linux which does not currently exist, due to combined vendor lockin of VMWare & Windows. You can't switch one without the other & that's not something that it viable for people to do. Our motivation here is not to hijack or sabotage Fedora or F/LOSS, but to promote its use and expand the userbase of Fedora. Fedora provides an excellant platform for hosting virtual machines either with Xen or KVM. The libvirt API provides a vendor-independant managment API which helps users avoid vendor lockin to both the hypervisor, and their management tools that you see when using VMWare & other commercial virtalization projects. Fedora has been leading the entire open source distro field in its virtualization capabilities since Fedora Core 6, and feeds into many other distros - RHEL or course, but also Ubuntu , SUSE and Solaris are following our lead in management tools. The main competition is obviously VMWare and they have been dominant in all areas for years - every company which has a virtualization management product/application supports VMWare. We've slowly been trying to get these people to support libvirt, so that they can easily manage virtual machines hosted on Fedora. The sad reality is that most commercial management products use Windows as their base and so unless we can provide libvirt for Windows they'll not use it and thus not have any support for managing Fedora hosts, and just stick with VMWare. Having people ignore Fedora as a virtualization platform in favour of VMWare is not what anyone wants. Hence we want to provide the cross compiler toolchain in Fedora, so that we can build libvirt client & client tools for Windows. This will allow people with Windows desktops & management tools to make use of Fedora virtualization. This will increase the userbase of Fedora, and Linux based virtualization platforms. It will also fully establish libvirt as the primary cross-platform, vendor neutral management API for virtualzation. This is a huge step for F/LOSS over the total dominence of VMWare in this area. I can see further use cases where providing a MinGW toolchain will benefit Fedora and F/LOSS. The FreeIPA project is providing state of the art authentication & directory services based on F/LOSS in Fedora, to rival the dominence of propriety ActiveDirectory services. This is already a huge step forward in a homogeneous environment of Linux servers and Linux desktops. Unless they can also support Windows desktops as clients though, it will forever be a niche player in the authentication/directory services arena. This is not good for F/LOSS or Fedora. A MinGW toolchain will facilitate the support of Windows clients and directly benefit the uptake of Fedora and F/LOSS in this area. The current situation where people have to use VMWare for virt if they use Windows on the desktop does not provide an easy migration path to Fedora, because they have to replace both their management infrastructure and their desktop infrastructure at the same time. By providing a libvirt client enabled for Windows, we provide a viable migration path from a Windows world to a Fedora world. They can start off using Fedora for hosting their virtual machines, and as they discover the benefits of Fedora & F/LOSS they're more likely to also switch their desktop to Fedora. So far from hijacking / sabotaging Fedora's principles, we're re-inforcing the value of Fedora and what it stands for and introducing it to a group of user who have never had any option to use it in the past. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Thu Jul 10 10:40:04 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 10 Jul 2008 11:40:04 +0100 Subject: [Fedora-packaging] supporting closed source operating systems? (was: Early MinGW packaging guidelines draft) In-Reply-To: <20080709215757.GC3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> Message-ID: <20080710104004.GC5806@redhat.com> On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote: > On Tue, Jul 08, 2008 at 04:58:20PM +0100, Richard W.M. Jones wrote: > > https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > What is Fedora's motivation is promoting using Open Source on a closed > source operating system? This is beyond the FPC to decide as this is a > technical committee, but still a valid question and maybe one that the > board should be investigating. > > F/LOSS often had and has to compromise on its base principles to get a > lift-off, and so does Fedora (the current exception for firmwares is > such a compromise). Before there was a Linux kernel, the GNU project > was "supporting" closed source Unices and by design still does so. > > But we're beyond the age of this kind of symbiosis, Linux (or > GNU/Linux ...) and Fedora in particular doesn't need this anymore. In > fact when a patch in a Fedora package is made it often doesn't matter > if it works on other Unices, sometimes not even for the Free ones. If we're beyond the age of symbiosis, we can remove SAMBA from Fedora then, because that's only needed for interoperability with closed source products. I'd love to believe that Fedora and F/LOSS had achieved world domination but sadly we're still fighting the battle, though unquestionably further along than we were just a few years ago. One of the best things about F/LOSS is that there are soo many projects breaking down proprietry walled gardens, but providing interoperability with closed source produts/platforms. This is providing users an escape path, allowing them to migrate to Fedora. SAMBA is a great example of this. We want Fedora+libvirt to provide the escape path for people running VMWare + Windows, and for this to work we need to provide the libirt clients for Windows platforms. This enables them to switch out VMWare in favour of Fedora + Xen/KVM, without having to migrate their entire desktop environment from Windows to Linux at the same time. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From rjones at redhat.com Thu Jul 10 10:44:54 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 10 Jul 2008 11:44:54 +0100 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft In-Reply-To: <20080708155820.GA17077@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> Message-ID: <20080710104454.GA27648@amd.home.annexia.org> https://fedoraproject.org/wiki/PackagingDrafts/MinGW I'd like to get this discussed at FPC next Tuesday. If anyone has any technical points on the draft, can you let me know or edit the page. (I've taken on board Ralf's point about mingw vs mingw32, although I'm not sure what is the correct course of action at the moment ...) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From dominik at greysector.net Thu Jul 10 19:50:30 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 10 Jul 2008 21:50:30 +0200 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft In-Reply-To: <20080710104454.GA27648@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080710104454.GA27648@amd.home.annexia.org> Message-ID: <20080710195030.GB22144@mokona.greysector.net> On Thursday, 10 July 2008 at 12:44, Richard W.M. Jones wrote: > https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > I'd like to get this discussed at FPC next Tuesday. If anyone has any > technical points on the draft, can you let me know or edit the page. > > (I've taken on board Ralf's point about mingw vs mingw32, although I'm > not sure what is the correct course of action at the moment ...) Looks mostly fine to me, although I don't like the length of %{_prefix}/i686-pc-mingw32/sys-root/mingw Could this be shortened to, say, %{_prefix}/i686-pc-mingw32/(sys)root/ ? Are there going to be any files in %{_prefix}/i686-pc-mingw32/sys-root that you need the additional /mingw there? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Thu Jul 10 21:23:52 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 11 Jul 2008 00:23:52 +0300 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080709215757.GC3755@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> Message-ID: <20080710212352.GA21234@victor.nirvana> On Thu, Jul 10, 2008 at 12:57:57AM +0300, Axel Thimm wrote: > What is Fedora's motivation is promoting using Open Source on a closed > source operating system? Thanks all for enlightening this. Jeff Spaleta more or less outlined the background thoughts I was having about it - envisioning building all of our fruits for consumption on the enemy territory was a bit scary. Daniel Berrange and Richard Jones explained the libvirt background which more than justifies this move, thanks for explaining. But what I'd like to still see addressed is whether there will be a policy of what other tools/apps are acceptable for Fedora. mingw, libvirt etc. do have their justification as a means to an end, but what happens when Joe Random Packager discovers the mingw package and thinks this is an invitation to rebuild all of Fedora for Windows (where possible) and submit as a new package? Do we want this? If not how do we prevent this or communicate it properly to the packager base? -- Axel.Thimm at ATrpms.net From jspaleta at gmail.com Thu Jul 10 21:53:18 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Jul 2008 13:53:18 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080710212352.GA21234@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080710212352.GA21234@victor.nirvana> Message-ID: <604aa7910807101453l189c20c3v82d1da9b818f5349@mail.gmail.com> On Thu, Jul 10, 2008 at 1:23 PM, Axel Thimm wrote: > But what I'd like to still see addressed is whether there will be a > policy of what other tools/apps are acceptable for Fedora. mingw, > libvirt etc. do have their justification as a means to an end, but > what happens when Joe Random Packager discovers the mingw package and > thinks this is an invitation to rebuild all of Fedora for Windows > (where possible) and submit as a new package? Do we want this? If not > how do we prevent this or communicate it properly to the packager > base? So basically the question is.. how much of our existing set of software is appropriate to rebuild with the mingw chain and make available as binary packages in the project itself in the form of packages? If I'm following the technical discussion correctly.. then we are talking about packaging some set library binaries meant to be used with mingw. It's not just about making mingw available as a tool..but its also about building some library binaries with mingw and packaging them as part of Fedora as part of a mingw development environment. Or am I wrong about that? For the sake of this discussion lets just limit ourselves to libraries and development packages..that's still a big space. How many libraries should we rebuild and package as part of a functional mingw development environment as windows DLL? Is it appropriate to rebuild all of our libraries such that they can be used with mingw? Saving people the necessary effort to rebuild the libraries themselves? Is this really an appropriate use of our Project mirroring and repository resources? How much bigger would the repository end up being if all our existing libraries were repackaged as windows DLLs? Is that potential resource burn worth the trade off of making it turnkey for people to mingw to build windows executables on Fedora? The base package definitions at http://fedoraproject.org/wiki/PackagingDrafts/MinGW may make obvious sense as a way to get the mingw tool into the distribution. But do the concepts of packaging Windows DLL and Windows EXEs make sense for us? Do we want to be distributing a full range of Windows DLLs and Windows EXEs in our repository? Or do we want to distribute the absolute minimum set of base packages to get mingw into the hands of users and let them rebuild the DLLs they need from source? I'm not sure I'm okay with rebuilding our entire collection of libraries as Windows DLLs and packaging them as part of our distribution, taking up project repository and mirror space. -jef From jspaleta at gmail.com Thu Jul 10 22:20:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Jul 2008 14:20:29 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080710102624.GA5806@redhat.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> Message-ID: <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> On Thu, Jul 10, 2008 at 2:26 AM, Daniel P. Berrange wrote: > I can see further use cases where providing a MinGW toolchain will > benefit Fedora and F/LOSS. The question is.. what is the appropriate size of the "toolchain" that we provide as part of our distribution. If we stop at just getting MinGW into the distro as a useful tool...that's one thing. But if we are then talking about allowing the use of MinGW or any other cross compiler in our build process to generate a full range of new packages and subpackages which contain windows DLLs variants of general purpose libraries contained in separate packages that can be installed on Fedora systems pulled from the Fedora repositories... that is something else entirely. I'm not sure this is something we want to allow in our build system nor in our packaging. If we have a specific need to build windows executables, like migration aids or virtualization clients, then perhaps all of that should be done outside of our traditional build and packaging system, so that we are not pressured to rebuild and provide any and all libraries as Windows DLLs. Let me sum up where I'm leaning as to a policy statement: * Building MinGW from sources as part of Fedora's repository offerings seems acceptable to me. I have no problem seeing cross compiler tools packaged as linux executables. * Using MinGW to rebuild anything else, so that we can make Windows DLLs available in our base repository in binary packages..seems inappropriate and sets a bad precedent. How do we draw the line as to what library source (which is distinct from the MinGW sources) we allow or do not not rebuild and ship as DLLs? Paint me a bright line, because without a bright line the alternative is to allow all libraries to be rebuilt and packages as part of the repository in this way...and I just don't see how that is appropriate. I don't want to get suckered into a case by case basis where we weight the intended reason for making a certain library available as a DLL. If we have to weigh intent, then it should be done outside the repository. There's nothing stopping us from creating whatever sort of DLLs we need for Fedora Project window applications as part of our infrastructure project for specific application needs..outside of the build system meant to feed the general use repository. *Having a 3rd party provide MinGW built library packages, and doing the work necessary to make sure the depresolving actually works with DLLs and EXEs rpm payloads seems very wise to me. -jef From rc040203 at freenet.de Fri Jul 11 10:27:00 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 11 Jul 2008 12:27:00 +0200 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft In-Reply-To: <20080710195030.GB22144@mokona.greysector.net> References: <20080708155820.GA17077@amd.home.annexia.org> <20080710104454.GA27648@amd.home.annexia.org> <20080710195030.GB22144@mokona.greysector.net> Message-ID: <1215772020.2809.644.camel@beck.corsepiu.local> On Thu, 2008-07-10 at 21:50 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 10 July 2008 at 12:44, Richard W.M. Jones wrote: > > https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > > > I'd like to get this discussed at FPC next Tuesday. If anyone has any > > technical points on the draft, can you let me know or edit the page. > > > > (I've taken on board Ralf's point about mingw vs mingw32, although I'm > > not sure what is the correct course of action at the moment ...) > > Looks mostly fine to me, although I don't like the length of > %{_prefix}/i686-pc-mingw32/sys-root/mingw > Could this be shortened to, say, > %{_prefix}/i686-pc-mingw32/(sys)root/ ? No. .../sys-root/ is a foreign system's mapping onto the host system, i.e. what is "/" under a native MinGW is /usr/i686-pc-ming32/sys-root/ under Fedora. The "mingw" directory in ../sys-root/mingw is the standard directory mingw uses natively to install in Windows and can't easily be remove. > Are there going to be any files in %{_prefix}/i686-pc-mingw32/sys-root > that you need the additional /mingw there? Hardly, but ... that's how things are supposed to be installed ;) You could network mount this mingw/-directory under Windows, should this be possible :) Ralf From dominik at greysector.net Fri Jul 11 14:01:16 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 11 Jul 2008 16:01:16 +0200 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft In-Reply-To: <1215772020.2809.644.camel@beck.corsepiu.local> References: <20080708155820.GA17077@amd.home.annexia.org> <20080710104454.GA27648@amd.home.annexia.org> <20080710195030.GB22144@mokona.greysector.net> <1215772020.2809.644.camel@beck.corsepiu.local> Message-ID: <20080711140116.GB27952@mokona.greysector.net> On Friday, 11 July 2008 at 12:27, Ralf Corsepius wrote: [...] OK, thanks for the explanations. I don't have any more technical issues right now. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Fedora at FamilleCollet.com Sun Jul 13 08:33:59 2008 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sun, 13 Jul 2008 10:33:59 +0200 Subject: [Fedora-packaging] Re: Regarding PHP guidelines -- pear packages In-Reply-To: <20080709212629.GA3755@victor.nirvana> References: <20080709212629.GA3755@victor.nirvana> Message-ID: <4879BDF7.80205@FamilleCollet.com> Axel Thimm a ?crit : > On Wed, Jul 09, 2008 at 09:36:12PM +0530, Rakesh Pandit wrote: >> Hello all, >> >> I had a confusion regarding PHP libraries which have a pending >> draft at pear.php.net but haven't been yet included in pear. May we go >> ahead packaging them as pear? Or package them as non pear PHP >> libraries and wait for proposal to pass? Or it is upto packager? >> For example php-openid[1] or php-oauth[2] has a proposed status >> for pear. > > I'm interpreting "pear" as used within the FP guidelines as a > packaging technology and not as a name of a collection. Otherwise we > would have to rename packages back and forth everytime there is a > change in the pear collection. > I agree with Axel. We already have some package php-pear-* which doesn't come from pear.php.net, but from other Channel (well php-channel-* guidelines is missing) which follow the PEAR convention. I've just have a quick look to oauth - no package.xml... - no versionning... So, i don't see this extension as a Pear package. Upstream have a lot a work to do, i think. Regards From rakesh.pandit at gmail.com Sun Jul 13 08:56:43 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Sun, 13 Jul 2008 14:26:43 +0530 Subject: [Fedora-packaging] Re: Regarding PHP guidelines -- pear packages In-Reply-To: <4879BDF7.80205@FamilleCollet.com> References: <20080709212629.GA3755@victor.nirvana> <4879BDF7.80205@FamilleCollet.com> Message-ID: On 13/07/2008, Remi Collet wrote: [..] > > I agree with Axel. > > We already have some package php-pear-* which doesn't come from > pear.php.net, but from other Channel (well php-channel-* guidelines is > missing) which follow the PEAR convention. > Yes. If FPC agrees I think it is important that Packaging/PHP wiki has a small entry to clarify this point. -- Regards, Rakesh Pandit From rjones at redhat.com Sun Jul 13 15:29:57 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 13 Jul 2008 16:29:57 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> Message-ID: <20080713152957.GA1120@amd.home.annexia.org> On Thu, Jul 10, 2008 at 02:20:29PM -0800, Jeff Spaleta wrote: > On Thu, Jul 10, 2008 at 2:26 AM, Daniel P. Berrange wrote: > > I can see further use cases where providing a MinGW toolchain will > > benefit Fedora and F/LOSS. > > The question is.. what is the appropriate size of the "toolchain" that > we provide as part of our distribution. [...] Your argument seems to be that either just the MinGW compiler goes in, or everything in the world goes in, and there is no middle ground. > [...] Paint me a bright line, OK, as with ordinary Fedora packages, a MinGW library would only go in if there was somebody willing to maintain it. It's highly unlikely that someone would be willing to maintain a MinGW cross-compile of every library currently in Fedora (it would certainly take all hours god gives and more to accomplish such a feat). For libvirt the required libraries are: - gnutls - libgcrypt - libgpg-error - libxml2 - portablexdr (*) - zlib (*) not part of Fedora at the moment and because having libvirt on Windows is a highly desirable outcome for us, we would be prepared to do the work either with maintainers, or ourselves, to maintain MinGW subpackages of these packages. If at some point in the future we aren't able to continue that work, then as with any other Fedora package they would eventually be removed from Fedora by standard processes. The same would apply on a case-by-case basis to any other library. I should stress again that this is no different from how Fedora packages currently get into and remain in Fedora: 'libbarquux' doesn't get into Fedora unless there is someone willing to maintain it, and if no one is willing to maintain it any more, then it becomes orphaned and eventually gets removed. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Sun Jul 13 15:34:01 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 13 Jul 2008 16:34:01 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080710212352.GA21234@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080710212352.GA21234@victor.nirvana> Message-ID: <20080713153401.GB1120@amd.home.annexia.org> On Fri, Jul 11, 2008 at 12:23:52AM +0300, Axel Thimm wrote: > but > what happens when Joe Random Packager discovers the mingw package and > thinks this is an invitation to rebuild all of Fedora for Windows > (where possible) and submit as a new package? Do we want this? If not > how do we prevent this or communicate it properly to the packager > base? Joe Random would certainly have a lot of time on his hands to do this. MinGW cross-compiles are *not* straightforward, and will require a great deal of care and maintenance, dealing with upstream to fix newly introduced bugs and so on. As with other Fedora packages, they only go in if someone is willing to maintain them, and come out if no one is willing to continue maintaining them. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Sun Jul 13 16:02:07 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 13 Jul 2008 17:02:07 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <604aa7910807101453l189c20c3v82d1da9b818f5349@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080710212352.GA21234@victor.nirvana> <604aa7910807101453l189c20c3v82d1da9b818f5349@mail.gmail.com> Message-ID: <20080713160207.GC1120@amd.home.annexia.org> I would just like to direct people on the fedora-advisory-board list to my previous reply here, which should address all of Jeff's questions: https://www.redhat.com/archives/fedora-packaging/2008-July/msg00043.html except for this one: On Thu, Jul 10, 2008 at 01:53:18PM -0800, Jeff Spaleta wrote: > Is this really an appropriate use of our Project mirroring and > repository resources? How much bigger would the repository end up > being if all our existing libraries were repackaged as windows DLLs? Leaving aside the fact that it's completely unrealistic to think anyone could recompile every Fedora library, and no one is proposing to do this anyway (see my answer above), I do have some figures on how big the MinGW RPMs are on my (32 bit) machine compared to the ordinary Fedora RPMs [0]: 4.1M mingw-libxml2-2.6.32-1.fc10.i386.rpm 847K libxml2-2.6.32-3.fc10.i386.rpm 1.4M libxml2-devel-2.6.32-3.fc10.i386.rpm 108K mingw-zlib-1.2.3-1.fc10.i386.rpm 75K zlib-1.2.3-18.fc9.i386.rpm 43K zlib-devel-1.2.3-18.fc9.i386.rpm 3.3M mingw-gnutls-2.4.1-2.fc10.i386.rpm 390K gnutls-2.4.1-2.fc10.i386.rpm 2.5M gnutls-devel-2.4.1-2.fc10.i386.rpm 128K gnutls-utils-2.4.1-2.fc10.i386.rpm [1] If we carry out a plan of building from the same SRPM then there shouldn't be any significant increase there. There are no debuginfo packages for MinGW. Rich. [0] Note that there is no foo / foo-devel split in the mingw packages. [1] Windows utilities (certtool.exe etc) are included in the mingw-gnutls package at present. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From Axel.Thimm at ATrpms.net Sun Jul 13 16:30:12 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 13 Jul 2008 19:30:12 +0300 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080713153401.GB1120@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080710212352.GA21234@victor.nirvana> <20080713153401.GB1120@amd.home.annexia.org> Message-ID: <20080713163012.GB18161@victor.nirvana> On Sun, Jul 13, 2008 at 04:34:01PM +0100, Richard W.M. Jones wrote: > On Fri, Jul 11, 2008 at 12:23:52AM +0300, Axel Thimm wrote: > > but what happens when Joe Random Packager discovers the mingw > > package and thinks this is an invitation to rebuild all of Fedora > > for Windows (where possible) and submit as a new package? Do we > > want this? If not how do we prevent this or communicate it > > properly to the packager base? > > Joe Random would certainly have a lot of time on his hands to do this. > > MinGW cross-compiles are *not* straightforward, and will require a > great deal of care and maintenance, dealing with upstream to fix newly > introduced bugs and so on. As with other Fedora packages, they only > go in if someone is willing to maintain them, and come out if no one > is willing to continue maintaining them. Hi, Joe Random's (in)finite time resources and (in)finite reviewing pals are not the problem, I'm not addressing this from a technical/organisational POV, but from principles. Just to present a real life example: I was arguing on the merits of having Fedora at schools as it comes with openoffice, gimp and so on, and a teacher took out a portable drive with portableapps.com and demostrated that he already has all of this on Windows now. And indeed the systems are now still running Windows ... So, when Joe Random starts preparing to use Fedora as a platform for building gimp or some other interesting F/LOSS bits for a proprietary system that is harming Fedora *Linux* are we really open to this? Maybe we are, I'm just posing the question. Maybe Fedora is about promoting free/open software in general whether that runs on a Linux kernel or whether that runs on *BSD, a proprieray Unix/Windows system etc. Maybe its is narrowing down to promoting fuller F/LOSS solutions including the OS, e.g. Linux and *BSD. Or it is (what I thought until now) a Linux based F/LOSS model (which doesn't preclude good relation with *BSD camps, or willing to help people on the Windows side of the earth to make the step to Linux). I think this is a rephrasing of Jeff's brigth line that he seeks to draw and wants to know what it will include and what not. So the issue is a political one, not a technical one. Supporting libvirt for running Fedora under Windows is one thing, supporting increased productivity on Windows another. Personally I would discourage the second model, or at least outsource it away from the Fedora brand. And we should decide on it now, that mingw is entering Fedora, rather than dealing with it when the Joe Randoms come in. Just to trigger some related thoughts: I wonder what would happen if someone submitted a cross-compiler and cross-built libs/tools for SCO Unix. Would we lay back and discuss it on technical points and whether there are enough maintainers etc? -- Axel.Thimm at ATrpms.net From green at redhat.com Sun Jul 13 19:28:33 2008 From: green at redhat.com (Anthony Green) Date: Sun, 13 Jul 2008 12:28:33 -0700 Subject: [Fedora-packaging] Fedora Common Lisp update Message-ID: <487A5761.7000507@redhat.com> While I'm waiting for my Lisp packaging guidelines to be reviewed again, I've taken the liberty of updating sbcl, cmucl and clisp to take advantage of the new common-lisp-controller package (which, I believe is approved, but the reviewer needs to flip the bit, or do I do that? https://bugzilla.redhat.com/show_bug.cgi?id=427411). I've also uploaded a collection of popular Common Lisp library packages for eventual submission here: http://people.redhat.com/green/Fedora. If you, for instance, install this new sbcl as well as a library like cl-clsql, you should be able to just run execute (require 'clsql-sqlite3) and the compiler will populate /var/cache/common-lisp-controller/sbcl/$USER/clsql with .fasl files. The sbcl package is working really well. I'm still having a little trouble with cmucl and clisp, but I thought I'd let people know what I was up to anyway. So, bottom line... I need some forward motion on my Lisp packaging draft. http://fedoraproject.org/wiki/PackagingDrafts/Lisp Thanks! AG From rjones at redhat.com Sun Jul 13 20:10:46 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 13 Jul 2008 21:10:46 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080713163012.GB18161@victor.nirvana> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080710212352.GA21234@victor.nirvana> <20080713153401.GB1120@amd.home.annexia.org> <20080713163012.GB18161@victor.nirvana> Message-ID: <20080713201046.GA1752@amd.home.annexia.org> On Sun, Jul 13, 2008 at 07:30:12PM +0300, Axel Thimm wrote: > So, when Joe Random starts preparing to use Fedora as a platform for > building gimp or some other interesting F/LOSS bits for a proprietary > system that is harming Fedora *Linux* are we really open to this? It's not at all clear that being able to build Gimp (as an example) is harming Fedora. There are at least three cases: (1) User switches from Photoshop to Gimp (and other free apps) and eventually, much later asks themselves 'why am I bothering to pay for this Windows stuff when Linux runs all the same apps I'm now using?' and they are then able to easily switch to Linux. (2) User switches from Photoshop to Gimp, but continues using Windows forever because they simply prefer the 'Start' menu and other Windows desktop features. (3) Because the fedora-packaging mailing list has successfully prevented any free apps from being available for Windows, user is forced to switch their entire system (all their apps, operating system, document formats) all at once from proprietary to free. Which is likely to happen? No idea. You could, I guess, devise a study to see what typical users do. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From aoliva at redhat.com Sun Jul 13 20:19:03 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 13 Jul 2008 17:19:03 -0300 Subject: [Fedora-packaging] supporting closed source operating systems? In-Reply-To: <20080709225151.GB26746@annexia.org> (Richard Jones's message of "Wed\, 9 Jul 2008 23\:51\:51 +0100") References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> Message-ID: On Jul 9, 2008, Richard Jones wrote: > almost nobody (perhaps 10, 100 people in the whole world?) are > running a completely free operating system (inc. BIOS etc). Err... When did BIOS become part of the operating system? :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From rjones at redhat.com Sun Jul 13 20:14:30 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 13 Jul 2008 21:14:30 +0100 Subject: [Fedora-packaging] supporting closed source operating systems? In-Reply-To: References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> Message-ID: <20080713201430.GB1752@amd.home.annexia.org> On Sun, Jul 13, 2008 at 05:19:03PM -0300, Alexandre Oliva wrote: > On Jul 9, 2008, Richard Jones wrote: > > > almost nobody (perhaps 10, 100 people in the whole world?) are > > running a completely free operating system (inc. BIOS etc). > > Err... When did BIOS become part of the operating system? :-) Heh, since CP/M of course. You're one of the 100 people :-) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From Axel.Thimm at ATrpms.net Sun Jul 13 21:43:10 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 14 Jul 2008 00:43:10 +0300 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080713201046.GA1752@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080710212352.GA21234@victor.nirvana> <20080713153401.GB1120@amd.home.annexia.org> <20080713163012.GB18161@victor.nirvana> <20080713201046.GA1752@amd.home.annexia.org> Message-ID: <20080713214310.GA24420@victor.nirvana> On Sun, Jul 13, 2008 at 09:10:46PM +0100, Richard W.M. Jones wrote: > On Sun, Jul 13, 2008 at 07:30:12PM +0300, Axel Thimm wrote: > > So, when Joe Random starts preparing to use Fedora as a platform for > > building gimp or some other interesting F/LOSS bits for a proprietary > > system that is harming Fedora *Linux* are we really open to this? > > It's not at all clear that being able to build Gimp (as an example) is > harming Fedora. > > There are at least three cases: > > (1) User switches from Photoshop to Gimp (and other free apps) and > eventually, much later asks themselves 'why am I bothering to pay for > this Windows stuff when Linux runs all the same apps I'm now using?' > and they are then able to easily switch to Linux. Does this include the typical user that had a proprietary OS preinstalled (and prepaid whether he liked it or not) on his system, or does he propably not care now to make the switch since his needs are fulfilled? And any other user that had a legitimate Windows license is in great pain to even sell it if he's allowed to at all. > (2) User switches from Photoshop to Gimp, but continues using Windows > forever because they simply prefer the 'Start' menu and other Windows > desktop features. > > (3) Because the fedora-packaging mailing list has successfully > prevented any free apps from being available for Windows, user is > forced to switch their entire system (all their apps, operating > system, document formats) all at once from proprietary to free. I thought the libvirt on Windows project was there to create a middle-step for this, or not? > Which is likely to happen? No idea. You could, I guess, devise a > study to see what typical users do. Please check my full post, it actually contained a recent real life example from a school that was about to switch to Fedora until it was discovered that one can use gimp and other free software on Windows XP. And if it counts as a study, I certainly did have the argument of Windows vs Linux about a million times, and I'm sure everyone on this list and his cat had it as well. We don't really need a study on the oldest question in the Computer Age. ;) Very few people run Windows for the pleasure of it - applications, be that an Office suite, graphics, internet, and even games define the true stack. -- Axel.Thimm at ATrpms.net From jspaleta at gmail.com Mon Jul 14 15:39:40 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 07:39:40 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080713152957.GA1120@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> Message-ID: <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> On Sun, Jul 13, 2008 at 7:29 AM, Richard W.M. Jones wrote: > and because having libvirt on Windows is a highly desirable outcome > for us, we would be prepared to do the work either with maintainers, > or ourselves, to maintain MinGW subpackages of these packages. If at > some point in the future we aren't able to continue that work, then as > with any other Fedora package they would eventually be removed from > Fedora by standard processes. > > The same would apply on a case-by-case basis to any other library. I abhor case by case restrictions.. especially ones where we are trying to judge whether or not a single person as the time to actually maintain the package. We sure as hell don't do that for the rest of the packaging space. You have to do much better than "highly unlikely due to time commitment". I don't consider that a bright line at all. I need something as a policy statement which we block on at the time of package review. And speaking of review... since you are doing this as a subpackage to existing packages we don't even have a requirement that this sort of thing goes through a peer review process because they aren't new packages. A bright line judgment process MUST involve peer review before... not after...the changes to the spec file are sitting in our cvs. I suggest you draft a policy statement as to how the review of mingw subpackages is suppose to work... and exactly what a reviewer is suppose to block on or how a reviewer is even suppose to test that the libraries work as expected. What I still don't have an answer for is why does this need to be in the main repo? Why can't we spin off a mingw compiled repo as a separate addon repository inside our infrastructure? And then the minGW SIG can deal with library inclusions into that addon repo however they want..with their own submission and review policy..separate from the main repository policy. > > I should stress again that this is no different from how Fedora > packages currently get into and remain in Fedora: 'libbarquux' doesn't > get into Fedora unless there is someone willing to maintain it, and if > no one is willing to maintain it any more, then it becomes orphaned > and eventually gets removed. New packages go through a peer review step before we let them in. At a minimum mingw cross-compiled crap is going to need its own submission review..which isn't going to happen if we allow this in as subpackages because our existing review process doesn't extend to subpackage creation. -jef From rjones at redhat.com Mon Jul 14 15:50:59 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Jul 2008 16:50:59 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> Message-ID: <20080714155059.GA5546@amd.home.annexia.org> On Mon, Jul 14, 2008 at 07:39:40AM -0800, Jeff Spaleta wrote: > On Sun, Jul 13, 2008 at 7:29 AM, Richard W.M. Jones wrote: > > and because having libvirt on Windows is a highly desirable outcome > > for us, we would be prepared to do the work either with maintainers, > > or ourselves, to maintain MinGW subpackages of these packages. If at > > some point in the future we aren't able to continue that work, then as > > with any other Fedora package they would eventually be removed from > > Fedora by standard processes. > > > > The same would apply on a case-by-case basis to any other library. > > I abhor case by case restrictions.. especially ones where we are > trying to judge whether or not a single person as the time to actually > maintain the package. We sure as hell don't do that for the rest of > the packaging space. You have to do much better than "highly unlikely > due to time commitment". I don't consider that a bright line at all. > I need something as a policy statement which we block on at the time > of package review. On the contrary, this is exactly how Fedora packaging works right now. https://fedoraproject.org/wiki/Package_Review_Process "A Contributor is defined as someone who wants to submit (and maintain) a package in Fedora." https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages "When Fedora maintainers do not want or are not able to maintain a package any longer, they can orphan or retire the package." > And speaking of review... since you are doing this as a subpackage to > existing packages we don't even have a requirement that this sort of > thing goes through a peer review process because they aren't new > packages. Well, with respect this is a problem with the Fedora process. Coming myself from a Debian background, I was always very surprised by the fact that once a package is in Fedora, it's virtually a free-for-all as to how that package is maintained. In Debian, things are quite different - large numbers of automated tests run continuously over existing packages, and any which don't conform to policy have an escalating scale of sanctions against them. We can have a separate discussion about fixing the Fedora process. > What I still don't have an answer for is why does this need to be in > the main repo? Why can't we spin off a mingw compiled repo as a > separate addon repository inside our infrastructure? And then the > minGW SIG can deal with library inclusions into that addon repo > however they want..with their own submission and review > policy..separate from the main repository policy. Same could apply to, eg., Perl packages (no offence to perl maintainers :-). It is much more useful if these packages are part of Fedora, rather than unnecessarily cordoned off in a separate infrastructure. > New packages go through a peer review step before we let them in. At > a minimum mingw cross-compiled crap is going to need its own > submission review..which isn't going to happen if we allow this in as > subpackages because our existing review process doesn't extend to > subpackage creation. With your use of phrases such as "mingw cross-compiled crap", I suggest you are not taking a level-headed approach to this. This is entirely free software, just that maybe it's not being used for purposes which you approve of. Fedora software is also used in the manufacture of tobacco products, cluster bombs and SUVs. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From a.badger at gmail.com Mon Jul 14 17:25:51 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Jul 2008 10:25:51 -0700 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080714155059.GA5546@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> Message-ID: <487B8C1F.5080705@gmail.com> Richard W.M. Jones wrote: > On Mon, Jul 14, 2008 at 07:39:40AM -0800, Jeff Spaleta wrote: >> On Sun, Jul 13, 2008 at 7:29 AM, Richard W.M. Jones wrote: >>> and because having libvirt on Windows is a highly desirable outcome >>> for us, we would be prepared to do the work either with maintainers, >>> or ourselves, to maintain MinGW subpackages of these packages. If at >>> some point in the future we aren't able to continue that work, then as >>> with any other Fedora package they would eventually be removed from >>> Fedora by standard processes. >>> >>> The same would apply on a case-by-case basis to any other library. >> I abhor case by case restrictions.. especially ones where we are >> trying to judge whether or not a single person as the time to actually >> maintain the package. We sure as hell don't do that for the rest of >> the packaging space. You have to do much better than "highly unlikely >> due to time commitment". I don't consider that a bright line at all. >> I need something as a policy statement which we block on at the time >> of package review. > > On the contrary, this is exactly how Fedora packaging works right now. > > https://fedoraproject.org/wiki/Package_Review_Process > "A Contributor is defined as someone who wants to submit (and > maintain) a package in Fedora." > > https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > "When Fedora maintainers do not want or are not able to maintain a > package any longer, they can orphan or retire the package." > So are we talking subpackage or wholly new package for the mingw packages? These policies assume wholly new packages. I think that wholly new packages might be easier to manage in this respect. >> And speaking of review... since you are doing this as a subpackage to >> existing packages we don't even have a requirement that this sort of >> thing goes through a peer review process because they aren't new >> packages. > > Well, with respect this is a problem with the Fedora process. Coming > myself from a Debian background, I was always very surprised by the > fact that once a package is in Fedora, it's virtually a free-for-all > as to how that package is maintained. In Debian, things are quite > different - large numbers of automated tests run continuously over > existing packages, and any which don't conform to policy have an > escalating scale of sanctions against them. > > We can have a separate discussion about fixing the Fedora process. > That would be very very nice. >> What I still don't have an answer for is why does this need to be in >> the main repo? Why can't we spin off a mingw compiled repo as a >> separate addon repository inside our infrastructure? And then the >> minGW SIG can deal with library inclusions into that addon repo >> however they want..with their own submission and review >> policy..separate from the main repository policy. > > Same could apply to, eg., Perl packages (no offence to perl > maintainers :-). It is much more useful if these packages are part of > Fedora, rather than unnecessarily cordoned off in a separate > infrastructure. > This is a flase comparison, though. Perl packages allow end-user perl programs to run on Fedora. The proposals I see for mingw are aimed at allowing developers to work with building programs that will run on Windows. This is a big difference in focus. OTOH, do we want to open the door to people running mingw-compiled binaries under wine? That seems like it might be a whole 'nother can of worms, though. >> New packages go through a peer review step before we let them in. At >> a minimum mingw cross-compiled crap is going to need its own >> submission review..which isn't going to happen if we allow this in as >> subpackages because our existing review process doesn't extend to >> subpackage creation. > > With your use of phrases such as "mingw cross-compiled crap", I > suggest you are not taking a level-headed approach to this. This is > entirely free software, just that maybe it's not being used for > purposes which you approve of. Fedora software is also used in the > manufacture of tobacco products, cluster bombs and SUVs. > Heh, from anyone else but Jef :-) One question for you guys. Have you touched base with the Embedded SIG guys? (I saw Ralf replied to the packaging-list thread but nothing more official than that). They're doing work on cross compilers and seem to have more similarity to your work than most of the other models I've seen brought up here. Looking at their wiki page, I also see that they have a stub entry for mingw: https://fedoraproject.org/wiki/SIGs/Embedded -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Mon Jul 14 17:33:41 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 09:33:41 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080714155059.GA5546@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> Message-ID: <604aa7910807141033u5502771dkcd16b88c1119840@mail.gmail.com> On Mon, Jul 14, 2008 at 7:50 AM, Richard W.M. Jones wrote: > With your use of phrases such as "mingw cross-compiled crap", I I have to apologize.. i use the word "crap" quite liberally as a synonym for "stuff". I need to stop doing that. Just wanted to say that first. >On the contrary, this is exactly how Fedora packaging works right now. > >https://fedoraproject.org/wiki/Package_Review_Process > "A Contributor is defined as someone who wants to submit (and > maintain) a package in Fedora." > >https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > "When Fedora maintainers do not want or are not able to maintain a > package any longer, they can orphan or retire the package." > All of these definitions speak to my original concern. If we let you package up mingw built libraries.. there is nothing in our policy which would keep any one else from doing exactly the same with other libraries. The "highly unlikely" argument doesn't hold water. There is no bright line between you or any other contributor. If you can add a subpackage.. then anyone else can..and we could quite easily in 2 releases end up with a large collection of cross-compiled paylods in the main repository..that we expect all our mirrors to digest. I'd rather plan for that sort of future, instead of pretending that you and a few other contributors are special compared to other library maintainers. If you can't stand up a reason any better than "most package maintainers won't be able to do it" then I have to assume that other library maintainers will do it, because you will enable them to do it. The stuff that is being drafted right now for the mingw SIG is going to lower the bar significantly for the next group of maintainers who want to get a dll compiled. > Well, with respect this is a problem with the Fedora process. Coming > myself from a Debian background, I was always very surprised by the > fact that once a package is in Fedora, it's virtually a free-for-all > as to how that package is maintained. In Debian, things are quite > different - large numbers of automated tests run continuously over > existing packages, and any which don't conform to policy have an > escalating scale of sanctions against them. > > We can have a separate discussion about fixing the Fedora process. No we are going to have a discussion in the context of dealing with cross-compiled content. You have to present how you expect cross-compiled content to be reviewed for submission or I'm going to push back really hard, harder than I am right now, about seeing any cross-compiled content into the main repository. This stuff is so different than are regular workflow, that it requires some care concerning how to fit in the review into our existence submission and review model. These are exactly the sort of questions I expect the mingw SIG to have some initial answers for. You can't just throw a few of these subpackages over the wall and call the work of the SIG done. You must, you absolutely must propose how these things are to be reviewed. >Same could apply to, eg., Perl packages (no offence to perl >maintainers :-). It is much more useful if these packages are part of >Fedora, rather than unnecessarily cordoned off in a separate >infrastructure. Are you saying that enabling an additional repository in your package manager is in fact too burdensome for a developer who is looking to cross-compile? C'mon. I don't understand why its much more useful in the main repo. The repo definition would exist in the default configs and it could either be enabled or disable by default. Hell you could enable it by default in the developer spin, but disable it by default in the Desktop spin. Isn't the target market for this stuff developers? The point however is that we do not demand that all the main mirrors host this material. They would be given a choice to pick this up and if you are wrong and this becomes popular and a lot of people want to rebuild libraries against mingw..we will have the structure in place to support it without burdening the main repository with 2x the library binaries. Stop dogging the question by holding up other sorts of payloads as strawmen. If you continue to do that, I'm going to stop asking the question hoping for a defensable answer. First..these mingw libraries do not directly benefit Fedora users. Perl, python, native libraries are directly provided to be used as part of the users of the Fedora Linux distribution. There is a clear distinction between what we provide currently and anything that is cross-compiled. Yes the mingw compiled dlls are useful to a subset of developers. I'm not questioning that. But I am less and less sure that the value there is worth opening up the main repository to this sort of cross-compiled content. And I am becoming more sure that the value that is there is maximized by having an expansive set of such dlls.. not limited to the immediate needs of libvirt. By setting this up as a separate repo but still inside the Fedora project, we can move forward and give you want you need but also start a process by which we can maximize the community value of these builds. In a lot of ways, this would almost be its own distribution that was built on Fedora. Second..we don't even ship all possible arches of the libraries that we do have. We have this concept called secondary arches so that individual contributors who want to extend Fedora onto new hardware platforms can do so, by bring resources to the table to do it, without asking the main mirrors to take on the distribution of that additional compiled material. A collection mingw compiled dlls feels very much like a cross between a distribution and secondary arch. Which sort of makes sense..since we are talking about cross-comppiling. Why shouldn't we ask you or anyone else who wants to cross-compile for another platform to be treated similarly from a policy perspective to how we ask our secondary arch developers to be treated? Why can't we make mingw a virtualized arch, and ask that the mingw payloads be ifarch'd in the spec file and built only for a specific arch target so that it can be treated as a secondary arch for a hosting and distribution point of view? Would you call secondary arches like sparc or arm "cordoned off" in our current policy. You aren't going to dodge the review burden on mingw payloads by waving your hands and saying the Fedora process is broken. If you feel our process needs fixing, then we fix it first before the mingw payloads are allowed in... not the other way around. -jef From rjones at redhat.com Mon Jul 14 17:30:42 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Jul 2008 18:30:42 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <487B8C1F.5080705@gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> Message-ID: <20080714173042.GA5868@amd.home.annexia.org> On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote: > OTOH, do we want to open the door to people running mingw-compiled > binaries under wine? That seems like it might be a whole 'nother can of > worms, though. You can actually run the executables under wine directly. In fact you just run them. Assuming you've set up the ~/.wine/config file so that paths to any non-standard DLLs can be found, then ./virsh.exe does the right thing. Setting up DLL paths correctly when mingw-runtime is installed was one thing I was going to look at. > One question for you guys. Have you touched base with the Embedded SIG > guys? (I saw Ralf replied to the packaging-list thread but nothing more > official than that). They're doing work on cross compilers and seem to > have more similarity to your work than most of the other models I've > seen brought up here. > > Looking at their wiki page, I also see that they have a stub entry for > mingw: > > https://fedoraproject.org/wiki/SIGs/Embedded [To Ralf] Is there a mailing list for embedded work? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Mon Jul 14 17:45:11 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Jul 2008 18:45:11 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <487B8C1F.5080705@gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> Message-ID: <20080714174511.GB5868@amd.home.annexia.org> On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote: > So are we talking subpackage or wholly new package for the mingw > packages? These policies assume wholly new packages. I think that > wholly new packages might be easier to manage in this respect. Four packages are mingw-specific. They are: mingw-runtime Runtime libs mingw-binutils Binutils tools mingw-gcc GCC cross-compiler mingw-w32api Win32 API header files However these alone are not really useful, because if you want to compile anything which isn't just a bare C program, you'll be needing dependent libraries too. How libraries are packaged is an open issue. Libraries are compiled from the latest source. Usually it's just a matter of doing %configure --host=i686-pc-mingw32 but of course because these libraries aren't routinely compiled for MinGW by upstream, I expect there will be a lot more bugs/regressions which the maintainer will need to handle. Taking GnuTLS purely as an example ... Dan Berrange wanted libraries to be built as a subpackage of existing libraries. Thus we'd have a subpackage of the current Fedora gnutls package. I have shown how this would work here: https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00435.html http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=91a808c59de63589367c7bd9750da1fca342c529;path=/gnutls-fragment/ The advantage is that we stay in step with upstream GnuTLS, including things like bug/security fixes. Also we're building from a single SRPM which is possibly more efficient. The disadvantages include the fact that the library maintainer may not be interested in maintaining the mingw subpackage, it's the first thing that'll be turned off when problems arise, no Fedora review, .. We can also do libraries as independent packages. For example, for GnuTLS I did this independent package: http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=2b4ca8a081d8;file=gnutls/mingw-gnutls.spec My opinion would be to allow _both_ approaches, depending on what the existing Fedora maintainer of a library was happy doing. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jspaleta at gmail.com Mon Jul 14 17:54:06 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 09:54:06 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <487B8C1F.5080705@gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> Message-ID: <604aa7910807141054k4a567ee5tf7916176dbd7a9f9@mail.gmail.com> On Mon, Jul 14, 2008 at 9:25 AM, Toshio Kuratomi wrote: > OTOH, do we want to open the door to people running mingw-compiled binaries > under wine? That seems like it might be a whole 'nother can of worms, > though. All the more reason to move ALL mingw compiled dlls into a separate repo tree. If its got libraries and applications.. its almost a completely separate distribution in and of itself. And I'm okay with that, but let's set it up that way from the beginning so it can grow into that sort of potential smoothly. -jef From a.badger at gmail.com Mon Jul 14 17:55:01 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Jul 2008 10:55:01 -0700 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080714173042.GA5868@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> Message-ID: <487B92F5.3050703@gmail.com> Richard W.M. Jones wrote: > On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote: >> OTOH, do we want to open the door to people running mingw-compiled >> binaries under wine? That seems like it might be a whole 'nother can of >> worms, though. > > You can actually run the executables under wine directly. In fact you > just run them. Assuming you've set up the ~/.wine/config file so that > paths to any non-standard DLLs can be found, then ./virsh.exe does the > right thing. > Yeah. I'm just wondering if widespread use of that would be a desirable or undesirable outcome. Here's a hypothetical: Let's say that Google opensources Picasa. Do we want to build and run that Windows app under wine using a cross compiler or do we want to wait/start a project to port the program to native Linux APIs? I can see benefits to both sides. > Setting up DLL paths correctly when mingw-runtime is installed was one > thing I was going to look at. > Cool. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rjones at redhat.com Mon Jul 14 17:55:31 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Jul 2008 18:55:31 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <604aa7910807141054k4a567ee5tf7916176dbd7a9f9@mail.gmail.com> References: <20080709215757.GC3755@victor.nirvana> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <604aa7910807141054k4a567ee5tf7916176dbd7a9f9@mail.gmail.com> Message-ID: <20080714175531.GC5868@amd.home.annexia.org> On Mon, Jul 14, 2008 at 09:54:06AM -0800, Jeff Spaleta wrote: > All the more reason to move ALL mingw compiled dlls into a separate > repo tree. If its got libraries and applications.. its almost a > completely separate distribution in and of itself. I think I don't understand what you mean by a separate Fedora repository. Do you mean as in the way that 'sources', 'debuginfo' and 'updates' are separate? How would I go about requesting such a repo? - - You mentioned the similarity to secondary archs in your other email. Obviously this does sort of look like a secondary arch, but I think there are significant differences -- eg. this work isn't self-hosting, unless you involve an actual Windows host (or perhaps some really complicated Wine configuration??) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jspaleta at gmail.com Mon Jul 14 18:05:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 10:05:34 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <487B92F5.3050703@gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <487B92F5.3050703@gmail.com> Message-ID: <604aa7910807141105l7d8a0329n7e2524471621c926@mail.gmail.com> On Mon, Jul 14, 2008 at 9:55 AM, Toshio Kuratomi wrote: > Yeah. I'm just wondering if widespread use of that would be a desirable or > undesirable outcome. Here's a hypothetical: > > Let's say that Google opensources Picasa. Do we want to build and run that > Windows app under wine using a cross compiler or do we want to wait/start a > project to port the program to native Linux APIs? I can see benefits to > both sides. I'm going to be deadly serious for a moment. If it builds from source, then Fedora must demand that it does so natively as a precondition to consider building the binary that works under wine. The compiled binary version that works inside wine...would be optional if and only if the native version is up and available already. The native version must be available first in Fedora. -jef From jspaleta at gmail.com Mon Jul 14 18:15:58 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 10:15:58 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080714175531.GC5868@amd.home.annexia.org> References: <20080709215757.GC3755@victor.nirvana> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <604aa7910807141054k4a567ee5tf7916176dbd7a9f9@mail.gmail.com> <20080714175531.GC5868@amd.home.annexia.org> Message-ID: <604aa7910807141115t27213963y36388ea8c88b8964@mail.gmail.com> On Mon, Jul 14, 2008 at 9:55 AM, Richard W.M. Jones wrote: > On Mon, Jul 14, 2008 at 09:54:06AM -0800, Jeff Spaleta wrote: >> All the more reason to move ALL mingw compiled dlls into a separate >> repo tree. If its got libraries and applications.. its almost a >> completely separate distribution in and of itself. > > I think I don't understand what you mean by a separate Fedora > repository. Do you mean as in the way that 'sources', 'debuginfo' and > 'updates' are separate? How would I go about requesting such a repo? We don't know yet...cross compiling is new. So we need to figure out how best to support it. > You mentioned the similarity to secondary archs in your other email. > Obviously this does sort of look like a secondary arch, but I think > there are significant differences -- eg. this work isn't self-hosting, > unless you involve an actual Windows host (or perhaps some really > complicated Wine configuration??) Right its not completely self-hosting. Everything about cross-compiling is wonky. Its mixes things up. But basically..for the purposes of my strawman. we'd set up a virtual arch in our build system, but when building in our build system for it pulls from the i386 tree as its build environment. Someone needs to tell me if this is possible to do through nested arch definitions. So for the sake of argument, can we teach rpm to understand an arch called "mingw-ix86" such that it inherits the ix86 packages? We then construct a build environment definition in mock which includes the mingw-ix86 and ix86 branches that will run on ix86 hardware and compile the mingw dll subpackages which are ifarch conditioned? I would need a more technical person to tell me how bad my strawman is. And yes I realize, its going to take some amount of technical work to do. And yes..I know I'm not the one who is going to be doing it. But I think we need to get this right and make a space for this sort of cross-compiled content in a way that lets it grow organically. I just don't think we can do that if we shove these payloads into the main tree. -jef From loupgaroublond at gmail.com Mon Jul 14 20:06:49 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 14 Jul 2008 22:06:49 +0200 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080714173042.GA5868@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709225151.GB26746@annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> Message-ID: <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> On Mon, Jul 14, 2008 at 7:30 PM, Richard W.M. Jones wrote: > On Mon, Jul 14, 2008 at 10:25:51AM -0700, Toshio Kuratomi wrote: >> OTOH, do we want to open the door to people running mingw-compiled >> binaries under wine? That seems like it might be a whole 'nother can of >> worms, though. > > You can actually run the executables under wine directly. In fact you > just run them. Assuming you've set up the ~/.wine/config file so that > paths to any non-standard DLLs can be found, then ./virsh.exe does the > right thing. > > Setting up DLL paths correctly when mingw-runtime is installed was one > thing I was going to look at. If you can show a demo of compiling certain open source windows apps so that they can work on Fedora via wine, then I can definitely argue that this is no longer secondary architecture. I have a couple of VJ programs some friends asked about getting into Fedora, all open source, but some run on windows. Being able to build them on Fedora easily will make it very easy for them to create a Fedora based VJ station. Just my 0.02 USD. -Yaakov From jspaleta at gmail.com Mon Jul 14 20:11:20 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 12:11:20 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> Message-ID: <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy wrote: > If you can show a demo of compiling certain open source windows apps > so that they can work on Fedora via wine, then I can definitely argue > that this is no longer secondary architecture. > > I have a couple of VJ programs some friends asked about getting into > Fedora, all open source, but some run on windows. Being able to build > them on Fedora easily will make it very easy for them to create a > Fedora based VJ station. I will fight you tooth and nail on this. It might even come down to a Dance Dance Revolution Dance off. If we can distribute it under the Fedora brand, we must have a version that runs natively before we consider a windows cross-compiled binary that runs under wine. I personally draw the line there. Native first, emulated second. If native doesnt work, get it fixed, or its not going to be part of Fedora. -jef From loupgaroublond at gmail.com Mon Jul 14 20:30:32 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 14 Jul 2008 22:30:32 +0200 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> Message-ID: <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta wrote: > On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy wrote: >> If you can show a demo of compiling certain open source windows apps >> so that they can work on Fedora via wine, then I can definitely argue >> that this is no longer secondary architecture. >> >> I have a couple of VJ programs some friends asked about getting into >> Fedora, all open source, but some run on windows. Being able to build >> them on Fedora easily will make it very easy for them to create a >> Fedora based VJ station. > > I will fight you tooth and nail on this. It might even come down to a > Dance Dance Revolution Dance off. If we can distribute it under the > Fedora brand, we must have a version that runs natively before we > consider a windows cross-compiled binary that runs under wine. I > personally draw the line there. Native first, emulated second. If > native doesnt work, get it fixed, or its not going to be part of > Fedora. Frets on Fire. Seriously, we might as well write the program over from scratch, cannabalizing the algorithms from it as we go along. Doing that would probably mean making a free-codec and nonfree-codec version too. Currently, it's supported by searching in all the usual windows places to see if codecs are installed. Now that wine is 1.0, I think it really deserves the same pariah status that Mono should get. It's an API controlled by a single corporation that is not 100% documented, complex, and been reimplemented from the inside out. Where do we draw the line between Mono compiling EXEs and DLLs that work under .Net on Windows and a cross compiler compiling EXEs and DLLs that work on windows without .Net? If you really want to make this argument, why don't we draw the line at Mono?. (Before anyone brings it up, Gstreamer's latency is too high for some of the things these guys are doing, which is a shame because it's just modular enough to make things like this less messy.) -Yaakov From jspaleta at gmail.com Mon Jul 14 20:38:00 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 12:38:00 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> Message-ID: <604aa7910807141338l752a1b90qb92d60fb31d5679a@mail.gmail.com> On Mon, Jul 14, 2008 at 12:30 PM, Yaakov Nemoy wrote: > Now that wine is 1.0, I think it really deserves the same pariah > status that Mono should get. It's an API controlled by a single > corporation that is not 100% documented, complex, and been > reimplemented from the inside out. Where do we draw the line between > Mono compiling EXEs and DLLs that work under .Net on Windows and a > cross compiler compiling EXEs and DLLs that work on windows without > .Net? If you really want to make this argument, why don't we draw the > line at Mono?. Did you miss what happened in the runup to F9? We actually pulled pre-compiled stuff out of some mono packages...and it really pissed a few people off...but we did it. -jef From a.badger at gmail.com Mon Jul 14 20:35:38 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Jul 2008 13:35:38 -0700 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> Message-ID: <487BB89A.5060507@gmail.com> Yaakov Nemoy wrote: > On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta wrote: >> On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy wrote: >>> If you can show a demo of compiling certain open source windows apps >>> so that they can work on Fedora via wine, then I can definitely argue >>> that this is no longer secondary architecture. >>> >>> I have a couple of VJ programs some friends asked about getting into >>> Fedora, all open source, but some run on windows. Being able to build >>> them on Fedora easily will make it very easy for them to create a >>> Fedora based VJ station. >> I will fight you tooth and nail on this. It might even come down to a >> Dance Dance Revolution Dance off. If we can distribute it under the >> Fedora brand, we must have a version that runs natively before we >> consider a windows cross-compiled binary that runs under wine. I >> personally draw the line there. Native first, emulated second. If >> native doesnt work, get it fixed, or its not going to be part of >> Fedora. > > Frets on Fire. > > Seriously, we might as well write the program over from scratch, > cannabalizing the algorithms from it as we go along. Doing that would > probably mean making a free-codec and nonfree-codec version too. > Currently, it's supported by searching in all the usual windows places > to see if codecs are installed. > > Now that wine is 1.0, I think it really deserves the same pariah > status that Mono should get. It's an API controlled by a single > corporation that is not 100% documented, complex, and been > reimplemented from the inside out. Where do we draw the line between > Mono compiling EXEs and DLLs that work under .Net on Windows and a > cross compiler compiling EXEs and DLLs that work on windows without > .Net? If you really want to make this argument, why don't we draw the > line at Mono?. > If I understand your question correctly, the big difference that I see is that .Net EXE's and DLLs (assemblies) run on any platform. AFAIK, windows .DLLs and .EXEs will only run on wine on x86. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From loupgaroublond at gmail.com Mon Jul 14 20:44:03 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 14 Jul 2008 22:44:03 +0200 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <487BB89A.5060507@gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> <487BB89A.5060507@gmail.com> Message-ID: <7f692fec0807141344x33bd9d35n57c1f473f3950b42@mail.gmail.com> On Mon, Jul 14, 2008 at 10:35 PM, Toshio Kuratomi wrote: > Yaakov Nemoy wrote: >> >> On Mon, Jul 14, 2008 at 10:11 PM, Jeff Spaleta wrote: >>> >>> On Mon, Jul 14, 2008 at 12:06 PM, Yaakov Nemoy >>> wrote: >>>> >>>> If you can show a demo of compiling certain open source windows apps >>>> so that they can work on Fedora via wine, then I can definitely argue >>>> that this is no longer secondary architecture. >>>> >>>> I have a couple of VJ programs some friends asked about getting into >>>> Fedora, all open source, but some run on windows. Being able to build >>>> them on Fedora easily will make it very easy for them to create a >>>> Fedora based VJ station. >>> >>> I will fight you tooth and nail on this. It might even come down to a >>> Dance Dance Revolution Dance off. If we can distribute it under the >>> Fedora brand, we must have a version that runs natively before we >>> consider a windows cross-compiled binary that runs under wine. I >>> personally draw the line there. Native first, emulated second. If >>> native doesnt work, get it fixed, or its not going to be part of >>> Fedora. >> >> Frets on Fire. >> >> Seriously, we might as well write the program over from scratch, >> cannabalizing the algorithms from it as we go along. Doing that would >> probably mean making a free-codec and nonfree-codec version too. >> Currently, it's supported by searching in all the usual windows places >> to see if codecs are installed. >> >> Now that wine is 1.0, I think it really deserves the same pariah >> status that Mono should get. It's an API controlled by a single >> corporation that is not 100% documented, complex, and been >> reimplemented from the inside out. Where do we draw the line between >> Mono compiling EXEs and DLLs that work under .Net on Windows and a >> cross compiler compiling EXEs and DLLs that work on windows without >> .Net? If you really want to make this argument, why don't we draw the >> line at Mono?. >> > If I understand your question correctly, the big difference that I see is > that .Net EXE's and DLLs (assemblies) run on any platform. AFAIK, windows > .DLLs and .EXEs will only run on wine on x86. Correction, .Net EXEs and DLLs will run on any platform only on top of .Net or Mono. But otherwise yes. True, we are limited to a single architecture, but then wine doesn't run on anything else, AFAIK, anyways. -Yaakov From jspaleta at gmail.com Mon Jul 14 20:52:31 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 12:52:31 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <7f692fec0807141344x33bd9d35n57c1f473f3950b42@mail.gmail.com> References: <20080708155820.GA17077@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> <487BB89A.5060507@gmail.com> <7f692fec0807141344x33bd9d35n57c1f473f3950b42@mail.gmail.com> Message-ID: <604aa7910807141352h528e2d8akee4ea7bd70ed5634@mail.gmail.com> On Mon, Jul 14, 2008 at 12:44 PM, Yaakov Nemoy wrote: > Correction, .Net EXEs and DLLs will run on any platform only on top of > .Net or Mono. > > But otherwise yes. > > True, we are limited to a single architecture, but then wine doesn't > run on anything else, AFAIK, anyways. And does mono run on the other arches? -jef From rjones at redhat.com Mon Jul 14 20:50:59 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Jul 2008 21:50:59 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <604aa7910807141338l752a1b90qb92d60fb31d5679a@mail.gmail.com> References: <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> <604aa7910807141338l752a1b90qb92d60fb31d5679a@mail.gmail.com> Message-ID: <20080714205059.GA6495@amd.home.annexia.org> On Mon, Jul 14, 2008 at 12:38:00PM -0800, Jeff Spaleta wrote: > On Mon, Jul 14, 2008 at 12:30 PM, Yaakov Nemoy wrote: > > Now that wine is 1.0, I think it really deserves the same pariah > > status that Mono should get. It's an API controlled by a single > > corporation that is not 100% documented, complex, and been > > reimplemented from the inside out. Where do we draw the line between > > Mono compiling EXEs and DLLs that work under .Net on Windows and a > > cross compiler compiling EXEs and DLLs that work on windows without > > .Net? If you really want to make this argument, why don't we draw the > > line at Mono?. > > Did you miss what happened in the runup to F9? We actually pulled > pre-compiled stuff out of some mono packages...and it really pissed a > few people off...but we did it. But that was stuff where there either wasn't source or there was no clear chain from the source to the binary. Please be clear that the MinGW cross-compiler is 100% free software built from source. If it turns out that any parts aren't, then they will be removed. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From jspaleta at gmail.com Mon Jul 14 21:20:02 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 13:20:02 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080714205059.GA6495@amd.home.annexia.org> References: <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <20080714173042.GA5868@amd.home.annexia.org> <7f692fec0807141306h521fdc86v6f15b0bf9d0cbdbe@mail.gmail.com> <604aa7910807141311u5ff5249ci4f619815e7b17a81@mail.gmail.com> <7f692fec0807141330y4a397550h6d53498004d4314e@mail.gmail.com> <604aa7910807141338l752a1b90qb92d60fb31d5679a@mail.gmail.com> <20080714205059.GA6495@amd.home.annexia.org> Message-ID: <604aa7910807141420k2d22c719p1de76ac359511d85@mail.gmail.com> On Mon, Jul 14, 2008 at 12:50 PM, Richard W.M. Jones wrote: > But that was stuff where there either wasn't source or there was no > clear chain from the source to the binary. > > Please be clear that the MinGW cross-compiler is 100% free software > built from source. If it turns out that any parts aren't, then they > will be removed. Sorry, I didn't mean to confuse the issue. I think Toshio is saying better what I am trying to say. There is a difference between cross-compiling code that is inherently arch-adependent in how its compiled and writing code in a language that is meant to be managed by a arch-independent virtual machine layer. I have a very difficult time seeing wine as similar to any virtual machine based language such as mono unless wine can be built and run on multiple arches. So as such I would have a very hard time seeing any code be branded as Fedora that had to be run under wine to be useful at all. I'm okay with optionally building a varient that runs under wine as part of the Fedora project if and only if there is a native version of that code already available for Fedora Linux. if wine as a project gets to the point where it can usefully run on ppc, then i would feel a lot better letting application code inside Fedora need it. But I'd still want to have it as a side-repo. -jef From rjones at redhat.com Mon Jul 14 22:57:59 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 14 Jul 2008 23:57:59 +0100 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <604aa7910807141115t27213963y36388ea8c88b8964@mail.gmail.com> References: <20080709230650.GE3755@victor.nirvana> <20080710102624.GA5806@redhat.com> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <604aa7910807141054k4a567ee5tf7916176dbd7a9f9@mail.gmail.com> <20080714175531.GC5868@amd.home.annexia.org> <604aa7910807141115t27213963y36388ea8c88b8964@mail.gmail.com> Message-ID: <20080714225759.GA6826@amd.home.annexia.org> On Mon, Jul 14, 2008 at 10:15:58AM -0800, Jeff Spaleta wrote: > So for the sake of argument, can we teach rpm to understand an arch > called "mingw-ix86" > such that it inherits the ix86 packages? We then construct a build > environment definition in mock which includes the mingw-ix86 and ix86 > branches that will run on ix86 hardware and compile the mingw dll > subpackages which are ifarch conditioned? Jeff, you're not offering anything constructive here. There's talk of mysterious extra repositories, and invasive changes to RPM & mock, but I'm no closer to understanding what purpose this achieves, or indeed _how_ to achieve it. I've presented a plan which involves adding 4 base packages to Fedora (already built[*]) and some number of additional packages for libraries (where 'some number' is approximately 7, also already built[*]). And I've found people who are willing to maintain these packages in the long term. Now, it's not perfect -- there are some things we need to resolve such as the precise naming convention and how to stop the strip command from damaging DLLs -- but it is nevertheless a plan that one can see how to finish. It doesn't violate any existing Fedora policy that I can see, and I've even provided my arguments that it increases the overall value of Fedora. So unless you wish to provide a detailed plan -- not hand-wavey stuff about Fedora providing 'extra infrastructure' or 'teaching RPM to understand' things -- I really don't think I can sensibly continue this discussion. Rich. [*] http://hg.et.redhat.com/misc/fedora-mingw--devel/ -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jspaleta at gmail.com Mon Jul 14 23:44:23 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 14 Jul 2008 15:44:23 -0800 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080714225759.GA6826@amd.home.annexia.org> References: <20080709230650.GE3755@victor.nirvana> <604aa7910807101520g240a88e7l89ad9dc54a1fab84@mail.gmail.com> <20080713152957.GA1120@amd.home.annexia.org> <604aa7910807140839s79be6f7bne89993c13d1a8291@mail.gmail.com> <20080714155059.GA5546@amd.home.annexia.org> <487B8C1F.5080705@gmail.com> <604aa7910807141054k4a567ee5tf7916176dbd7a9f9@mail.gmail.com> <20080714175531.GC5868@amd.home.annexia.org> <604aa7910807141115t27213963y36388ea8c88b8964@mail.gmail.com> <20080714225759.GA6826@amd.home.annexia.org> Message-ID: <604aa7910807141644y49f8d5cfy70788b20a11b7d8a@mail.gmail.com> On Mon, Jul 14, 2008 at 2:57 PM, Richard W.M. Jones wrote: > So unless you wish to provide a detailed plan -- not hand-wavey stuff > about Fedora providing 'extra infrastructure' or 'teaching RPM to > understand' things -- I really don't think I can sensibly continue > this discussion. I plan to talk to more people about whether we can set this up in the same was as a secondary arch works. Failing that however... running this as an addon repo is possible with known technical knowledge. EPEL is an existing implementation of an addon repository... it just doesn't target Fedora as its base repo. But we certainly know how to do an addon repo this way that does not invoke any new tricks. The question main question remains, what's a reasonable way to handle the inclusion of cross-compiled libraries into the project. I don't think I've seen consensus expressed. There is a consensus that the immediate aim of building libvirt related cross compiled libraries has significant value, but its not clear what we want to do beyond that. If we end up deciding that the dlls are generally not appropriate in the main repository (and that is something I plan to discuss more at tomorrow's board meeting) than we can certainly implement the technical details to open a mingw addon repo constructed like EPEL.. if we want to allow it at all. We don't have existing policy with regard to cross-compiling because its a new capability with the introduction of the mingw tool into are distro. But just because the tool exists, does not mean packaging and distributing binaries built with it makes sense for the distribution nor for the project in a broader sense. I would hope that no subpackages with mingw built payloads will find their way into rawhide until we have a defensible policy statement in place that sets the bounds on what we really want to see that we can point to as more people look to replicate what you are doing with the libvirt libraries. Holding off on their introduction, will suck marginally less than if we put a handful of libs in and then the 6 months from now we end up deciding on a policy which does not allow them in at all. -jef From rjones at redhat.com Tue Jul 15 07:38:02 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Jul 2008 08:38:02 +0100 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft In-Reply-To: <20080710104454.GA27648@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080710104454.GA27648@amd.home.annexia.org> Message-ID: <20080715073802.GA8680@amd.home.annexia.org> On Thu, Jul 10, 2008 at 11:44:54AM +0100, Richard W.M. Jones wrote: > https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > I'd like to get this discussed at FPC next Tuesday. If anyone has any > technical points on the draft, can you let me know or edit the page. Unfortunately I'm double-booked so I can't be at the meeting today. Also these packages really need more work on them before presenting them to FPC. So I'll punt until +2 weeks. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From tcallawa at redhat.com Tue Jul 15 17:25:09 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 15 Jul 2008 13:25:09 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) Message-ID: <1216142709.17003.66.camel@localhost.localdomain> The next Fedora Packaging Committee Meeting will be held on Tuesday, July 22, 2008. (Note: Normally, the FPC meets every other week, but this meeting was scheduled since we did not have quorum on July 15, 2008) Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as the Fedora Board meets at 18:00 UTC. Items scheduled to be discussed: Python virtual Provides: PackagingDrafts/Python Haskell: PackagingDrafts/Haskell Font bundles amendement to Fonts policy: PackagingDrafts/Packaging_font_bundles Lisp: PackagingDrafts/Lisp As a reminder, the process for getting items onto the FPC's agenda is documented here: http://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure Thanks, ~spot From a.badger at gmail.com Wed Jul 16 15:01:43 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Jul 2008 08:01:43 -0700 Subject: [Fedora-packaging] Early MinGW packaging guidelines draft In-Reply-To: <20080715073802.GA8680@amd.home.annexia.org> References: <20080708155820.GA17077@amd.home.annexia.org> <20080710104454.GA27648@amd.home.annexia.org> <20080715073802.GA8680@amd.home.annexia.org> Message-ID: <487E0D57.4090706@gmail.com> Richard W.M. Jones wrote: > On Thu, Jul 10, 2008 at 11:44:54AM +0100, Richard W.M. Jones wrote: >> https://fedoraproject.org/wiki/PackagingDrafts/MinGW >> >> I'd like to get this discussed at FPC next Tuesday. If anyone has any >> technical points on the draft, can you let me know or edit the page. > > Unfortunately I'm double-booked so I can't be at the meeting today. > > Also these packages really need more work on them before presenting > them to FPC. > > So I'll punt until +2 weeks. > We didn't have enough people for quorum this week. We'll hold a meeting next week (July 22) to see if we can get quorum to pass things. We did a little talking about cross compiling in general at our meeting. Those who were there thought that having a separate source rpm per-package-per-library makes more sense than subpackages (likely different maintainers, having to maintain two sets of build instructions in the spec, some cross-compilers require more invasive changes, and simply not scaling in a general way when we have multiple cross-compilers.) I'll note that neither Hans nor Ralf were present (both on the embedded SIG) and their input could definitely change this but the present thinking is that separate packages are the way to go. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Fri Jul 18 03:20:00 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 Jul 2008 23:20:00 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216142709.17003.66.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> Message-ID: <1216351200.6118.61.camel@localhost.localdomain> On Tue, 2008-07-15 at 13:25 -0400, Tom "spot" Callaway wrote: > The next Fedora Packaging Committee Meeting will be held on Tuesday, > July 22, 2008. (Note: Normally, the FPC meets every other week, but this > meeting was scheduled since we did not have quorum on July 15, 2008) In case it wasn't clear to everyone already, sometimes, I'm an idiot. I'll be in route to OLS during the time I scheduled for this meeting. You guys are welcomed to have it without me, but if not, we'll push out to next Tuesday... or we could try for Monday. FPC members, please chime in. ~spot From rc040203 at freenet.de Fri Jul 18 04:07:42 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 Jul 2008 06:07:42 +0200 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216351200.6118.61.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> <1216351200.6118.61.camel@localhost.localdomain> Message-ID: <1216354062.4313.521.camel@beck.corsepiu.local> On Thu, 2008-07-17 at 23:20 -0400, Tom "spot" Callaway wrote: > On Tue, 2008-07-15 at 13:25 -0400, Tom "spot" Callaway wrote: > > The next Fedora Packaging Committee Meeting will be held on Tuesday, > > July 22, 2008. (Note: Normally, the FPC meets every other week, but this > > meeting was scheduled since we did not have quorum on July 15, 2008) > > In case it wasn't clear to everyone already, sometimes, I'm an idiot. > I'll be in route to OLS during the time I scheduled for this meeting. > You guys are welcomed to have it without me, but if not, we'll push out > to next Tuesday... or we could try for Monday. FPC members, please chime > in. FYI: I am not sure, whether I'll be able to attend any meeting throughout the next 4 weeks, because other higher commitments are likely to interfere[1]. I.e. whether it'll be Monday or Tuesday doesn't really matter much to me. Though I'll try to join whenever meetings will be scheduled, it's impossible for me to promise to be able to do so. Ralf [1] This already had happened this week. I had planned to attend, but something "urgent" demanding "immediate action" had driven me AFK shortly before the "scheduled meeting". From green at redhat.com Mon Jul 21 13:28:44 2008 From: green at redhat.com (Anthony Green) Date: Mon, 21 Jul 2008 06:28:44 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216142709.17003.66.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> Message-ID: <48848F0C.9020409@redhat.com> Tom "spot" Callaway wrote: > Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as > the Fedora Board meets at 18:00 UTC. > > Items scheduled to be discussed: > > > Lisp: PackagingDrafts/Lisp > I'm going to be without internet connectivity today and tomorrow, but I'll likely have it tonight. If anybody has questions or comments about the Lisp packaging draft, today would be a really great day to send them to me, so I can respond tonight before the meeting. Thanks! AG From dtimms at iinet.net.au Tue Jul 22 00:56:40 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 22 Jul 2008 10:56:40 +1000 Subject: [Fedora-packaging] Re: rakarrack - alternative desktop categories In-Reply-To: <1216557315.6668.42.camel@cage.kgw.TU-Berlin.DE> References: <487FBDC4.2070004@iinet.net.au> <1216557315.6668.42.camel@cage.kgw.TU-Berlin.DE> Message-ID: <48853048.3080407@iinet.net.au> Fernando Lopez-Lezcano wrote: > 0.2.x is now in Planet CCRMA thanks to Arnaud from IRCAM. Great if you > can/want to migrate it to Fedora! I did submit a package review that I think meets the Fedora guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=455953 > I would appreciate it if you could > keep the extra categories in the desktop file, they are used to classify > audio apps in an extra menu I added to Planet CCRMA (and rakarrack would > drop out of it if they were ommited). The question you ask is a good one, and I understand where you are coming from: {ccrma .spec} ===== # desktop file categories BASE="X-Fedora Application AudioVideo" XTRA="X-Digital_Processing X-Jack" %{__mkdir} -p %{buildroot}%{_datadir}/applications desktop-file-install --vendor fedora \ --dir %{buildroot}%{_datadir}/applications \ `for c in ${BASE} ${XTRA} ; do echo "--add-category $c " ; done` \ %{SOURCE1} ===== As I understand it, a Fedora package can use only the categories present in the freedesktop.org spec: http://fedoraproject.org/wiki/Packaging/Guidelines#.desktop_file_creation http://standards.freedesktop.org/menu-spec/latest/apa.html Can a package use it's own categories, or must they meet the standards ? If there will be many audio apps {aka ccrma} packages, it would be best to have them grouped in the same menu; the AudioVideo menu on my machine is already overflowing more than a screenful, so I think it would be good if these audio {only} apps get their own menu ? DaveT. From rjones at redhat.com Mon Jul 21 14:54:48 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Jul 2008 15:54:48 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216142709.17003.66.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> Message-ID: <20080721145448.GA29618@amd.home.annexia.org> On Tue, Jul 15, 2008 at 01:25:09PM -0400, Tom spot Callaway wrote: > Items scheduled to be discussed: [list not including MinGW] > As a reminder, the process for getting items onto the FPC's agenda is > documented here: > http://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure I edited this page a couple of week ago: http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo but the MinGW stuff doesn't appear in the list? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From tcallawa at redhat.com Mon Jul 21 15:05:34 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 21 Jul 2008 11:05:34 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <20080721145448.GA29618@amd.home.annexia.org> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> Message-ID: <1216652734.3603.3.camel@localhost.localdomain> On Mon, 2008-07-21 at 15:54 +0100, Richard W.M. Jones wrote: > [list not including MinGW] MinGW is blocked at FESCo at the moment (I think). ~spot From rjones at redhat.com Mon Jul 21 15:39:56 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Jul 2008 16:39:56 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216652734.3603.3.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> Message-ID: <20080721153956.GA29765@amd.home.annexia.org> On Mon, Jul 21, 2008 at 11:05:34AM -0400, Tom spot Callaway wrote: > On Mon, 2008-07-21 at 15:54 +0100, Richard W.M. Jones wrote: > > [list not including MinGW] > > MinGW is blocked at FESCo at the moment (I think). Don't things go to FPC first? How do I find out its status at FESCo & how to unblock it? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From tcallawa at redhat.com Mon Jul 21 16:01:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 21 Jul 2008 12:01:36 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <20080721153956.GA29765@amd.home.annexia.org> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> Message-ID: <1216656096.3419.2.camel@localhost.localdomain> On Mon, 2008-07-21 at 16:39 +0100, Richard W.M. Jones wrote: > On Mon, Jul 21, 2008 at 11:05:34AM -0400, Tom spot Callaway wrote: > > On Mon, 2008-07-21 at 15:54 +0100, Richard W.M. Jones wrote: > > > [list not including MinGW] > > > > MinGW is blocked at FESCo at the moment (I think). > > Don't things go to FPC first? How do I find out its status at FESCo & > how to unblock it? Well, in this case, I think the workflow is: The Fedora Board was asked to determine whether including MinGW bits was a good idea. They said that it was, but that it should be separated from the main Fedora repository, and that FESCo should determine the specifics. (see: https://fedoraproject.org/wiki/Board/Meetings/2008-07-15) Once FESCo does this, the FPC will review the specific packaging bits and approve the guidelines. ~spot From rjones at redhat.com Mon Jul 21 16:45:21 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Jul 2008 17:45:21 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216656096.3419.2.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> Message-ID: <20080721164521.GA29941@amd.home.annexia.org> On Mon, Jul 21, 2008 at 12:01:36PM -0400, Tom spot Callaway wrote: > The Fedora Board was asked to determine whether including MinGW bits was > a good idea. They said that it was, but that it should be separated from > the main Fedora repository, and that FESCo should determine the > specifics. (see: > https://fedoraproject.org/wiki/Board/Meetings/2008-07-15) This meeting wasn't announced in the normal way (by a posting "Plan for tomorrows (DATE) ..." on fedora-devel-list), there are no IRC logs anywhere, no one asked anyone in the MinGW SIG to attend (and so they weren't there) and all we have is this fait-accompli message after the fact ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From tcallawa at redhat.com Mon Jul 21 16:58:39 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 21 Jul 2008 12:58:39 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <20080721164521.GA29941@amd.home.annexia.org> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> Message-ID: <1216659519.3419.7.camel@localhost.localdomain> On Mon, 2008-07-21 at 17:45 +0100, Richard W.M. Jones wrote: > On Mon, Jul 21, 2008 at 12:01:36PM -0400, Tom spot Callaway wrote: > > The Fedora Board was asked to determine whether including MinGW bits was > > a good idea. They said that it was, but that it should be separated from > > the main Fedora repository, and that FESCo should determine the > > specifics. (see: > > https://fedoraproject.org/wiki/Board/Meetings/2008-07-15) > > This meeting wasn't announced in the normal way (by a posting "Plan > for tomorrows (DATE) ..." on fedora-devel-list), there are no IRC logs > anywhere, no one asked anyone in the MinGW SIG to attend (and so they > weren't there) and all we have is this fait-accompli message after the > fact ... The Board meets (usually) every week on Tuesday. One meeting a month, that meeting is public (IRC): https://fedoraproject.org/wiki/Board/ This particular meeting was not public, thus, no one other than Board members were invited. ~spot From rjones at redhat.com Mon Jul 21 16:54:07 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Jul 2008 17:54:07 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216659519.3419.7.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> <1216659519.3419.7.camel@localhost.localdomain> Message-ID: <20080721165407.GB29941@amd.home.annexia.org> On Mon, Jul 21, 2008 at 12:58:39PM -0400, Tom spot Callaway wrote: > On Mon, 2008-07-21 at 17:45 +0100, Richard W.M. Jones wrote: > > On Mon, Jul 21, 2008 at 12:01:36PM -0400, Tom spot Callaway wrote: > > > The Fedora Board was asked to determine whether including MinGW bits was > > > a good idea. They said that it was, but that it should be separated from > > > the main Fedora repository, and that FESCo should determine the > > > specifics. (see: > > > https://fedoraproject.org/wiki/Board/Meetings/2008-07-15) > > > > This meeting wasn't announced in the normal way (by a posting "Plan > > for tomorrows (DATE) ..." on fedora-devel-list), there are no IRC logs > > anywhere, no one asked anyone in the MinGW SIG to attend (and so they > > weren't there) and all we have is this fait-accompli message after the > > fact ... > > The Board meets (usually) every week on Tuesday. One meeting a month, > that meeting is public (IRC): > > https://fedoraproject.org/wiki/Board/ > > This particular meeting was not public, thus, no one other than Board > members were invited. And IRC logs of this meeting ...? I notice people were at the meeting who aren't in FESCo. OK, maybe technically they just happened to be there and weren't "invited", but I think it's in the interests of everyone to find out who said what, in the open. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 59 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From tcallawa at redhat.com Mon Jul 21 17:22:09 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 21 Jul 2008 13:22:09 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <20080721165407.GB29941@amd.home.annexia.org> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> <1216659519.3419.7.camel@localhost.localdomain> <20080721165407.GB29941@amd.home.annexia.org> Message-ID: <1216660929.3419.15.camel@localhost.localdomain> On Mon, 2008-07-21 at 17:54 +0100, Richard W.M. Jones wrote: > On Mon, Jul 21, 2008 at 12:58:39PM -0400, Tom spot Callaway wrote: > > On Mon, 2008-07-21 at 17:45 +0100, Richard W.M. Jones wrote: > > > On Mon, Jul 21, 2008 at 12:01:36PM -0400, Tom spot Callaway wrote: > > > > The Fedora Board was asked to determine whether including MinGW bits was > > > > a good idea. They said that it was, but that it should be separated from > > > > the main Fedora repository, and that FESCo should determine the > > > > specifics. (see: > > > > https://fedoraproject.org/wiki/Board/Meetings/2008-07-15) > > > > > > This meeting wasn't announced in the normal way (by a posting "Plan > > > for tomorrows (DATE) ..." on fedora-devel-list), there are no IRC logs > > > anywhere, no one asked anyone in the MinGW SIG to attend (and so they > > > weren't there) and all we have is this fait-accompli message after the > > > fact ... > > > > The Board meets (usually) every week on Tuesday. One meeting a month, > > that meeting is public (IRC): > > > > https://fedoraproject.org/wiki/Board/ > > > > This particular meeting was not public, thus, no one other than Board > > members were invited. > > And IRC logs of this meeting ...? > > I notice people were at the meeting who aren't in FESCo. OK, maybe > technically they just happened to be there and weren't "invited", but > I think it's in the interests of everyone to find out who said what, > in the open. The Fedora Board is different from FESCo. The Fedora Board holds its meetings over the telephone (except for the one monthly open IRC meeting). Again, to reiterate, the Board simply said that it was in support of MinGW in Fedora, but it should be separated, and that FESCo should handle the technical specifics. ~spot From tibbs at math.uh.edu Mon Jul 21 22:54:39 2008 From: tibbs at math.uh.edu (Jason Tibbitts) Date: Mon, 21 Jul 2008 17:54:39 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <48848F0C.9020409@redhat.com> References: <1216142709.17003.66.camel@localhost.localdomain> <48848F0C.9020409@redhat.com> Message-ID: <488513AF.1050009@math.uh.edu> Anthony Green wrote: > If anybody has questions or comments about the Lisp packaging > draft, today would be a really great day to send them > to me, so I can respond tonight before the meeting. I am on vacation so I haven't had all that much time to review things properly, but one thing I noticed is that, as someone not familiar with Lisp who might be reviewing packages, some of the guidelines don't really enlighten me as to how I might actually tell if a particular package meets them. For example, I see that libraries should be managed by "asdf" and that they should be able to load asdf with some specific lisp code. The guidelines, however, don't inform me as to how I might tell if the package does those things. Also, a specfile template would really be appreciated. As it is, if these guidelines were passed, I'd have no idea how to actually review lisp packages. - J< From j.w.r.degoede at hhs.nl Tue Jul 22 05:19:38 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 22 Jul 2008 07:19:38 +0200 Subject: [Fedora-packaging] Re: Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216142709.17003.66.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> Message-ID: <48856DEA.3000700@hhs.nl> Tom "spot" Callaway wrote: > The next Fedora Packaging Committee Meeting will be held on Tuesday, > July 22, 2008. (Note: Normally, the FPC meets every other week, but this > meeting was scheduled since we did not have quorum on July 15, 2008) > > Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as > the Fedora Board meets at 18:00 UTC. > > Items scheduled to be discussed: > > Python virtual Provides: PackagingDrafts/Python > Haskell: PackagingDrafts/Haskell > Font bundles amendement to Fonts policy: > PackagingDrafts/Packaging_font_bundles > Lisp: PackagingDrafts/Lisp > > As a reminder, the process for getting items onto the FPC's agenda is > documented here: > http://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure > Wat is the plan with this meeting, is it going through ? I'm asking because there have been some cancellations so I wonder how usefull it is to get together. I'll be there this time, sorry for missing the last few times. Regards, Hans From berrange at redhat.com Tue Jul 22 09:29:35 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 22 Jul 2008 10:29:35 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216660929.3419.15.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> <1216659519.3419.7.camel@localhost.localdomain> <20080721165407.GB29941@amd.home.annexia.org> <1216660929.3419.15.camel@localhost.localdomain> Message-ID: <20080722092935.GB5192@redhat.com> On Mon, Jul 21, 2008 at 01:22:09PM -0400, Tom spot Callaway wrote: > Again, to reiterate, the Board simply said that it was in support of > MinGW in Fedora, but it should be separated, and that FESCo should > handle the technical specifics. What is the board's rationale for putting MinGW packages in a separate repository, when other cross-compiler toolchain (eg ARM) are in the main Fedora repository. Seems to me like we're penalizing MinGW just because it happens to be related to Windows, even though MinGW's code is still just as open source as anything else in our repos. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jkeating at redhat.com Tue Jul 22 12:06:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Jul 2008 08:06:59 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <20080722092935.GB5192@redhat.com> References: <1216142709.17003.66.camel@localhost.localdomain> <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> <1216659519.3419.7.camel@localhost.localdomain> <20080721165407.GB29941@amd.home.annexia.org> <1216660929.3419.15.camel@localhost.localdomain> <20080722092935.GB5192@redhat.com> Message-ID: <1216728419.12190.61.camel@localhost.localdomain> On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote: > What is the board's rationale for putting MinGW packages in a separate > repository, when other cross-compiler toolchain (eg ARM) are in the main > Fedora repository. Seems to me like we're penalizing MinGW just > because it happens to be related to Windows, even though MinGW's code > is still just as open source as anything else in our repos. Actually I think the prevailing thought that the Board has (although it's up to FESCo to really nail it down) is that the mingw tools themselves are absolutely suitable for Fedora. The libraries compiled against it for windows use are what should be in another repo. My personal opinion is that if you're going to need to munge spec files in order to produce packages built against mingw, those munges need to be done outside our cvs repo as well. However that's just my opinion, and since the board has asked FESCo to sort out the technical details, and I'm not in FESCo anymore, that opinion doesn't amount to much (: -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Tue Jul 22 16:22:32 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 22 Jul 2008 17:22:32 +0100 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216728419.12190.61.camel@localhost.localdomain> References: <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> <1216659519.3419.7.camel@localhost.localdomain> <20080721165407.GB29941@amd.home.annexia.org> <1216660929.3419.15.camel@localhost.localdomain> <20080722092935.GB5192@redhat.com> <1216728419.12190.61.camel@localhost.localdomain> Message-ID: <20080722162232.GA1754@amd.home.annexia.org> On Tue, Jul 22, 2008 at 08:06:59AM -0400, Jesse Keating wrote: > On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote: > > What is the board's rationale for putting MinGW packages in a separate > > repository, when other cross-compiler toolchain (eg ARM) are in the main > > Fedora repository. Seems to me like we're penalizing MinGW just > > because it happens to be related to Windows, even though MinGW's code > > is still just as open source as anything else in our repos. > > Actually I think the prevailing thought that the Board has (although > it's up to FESCo to really nail it down) is that the mingw tools > themselves are absolutely suitable for Fedora. The libraries compiled > against it for windows use are what should be in another repo. [I'm going to prepare something more detailed, hopefully integrating efforts with the cross-compiler folks, but just on these two points ...] If we ship only the four base packages (mingw-gcc, mingw-binutils, mingw-w32api and mingw-runtime) then the only software that can be compiled is software which doesn't use any libraries. That's pretty restrictive. To compile, for example, libvirt, one needs six other libraries. As with Linux, you need the library around (foo-0.dll) in order to link. Anyone compiling libvirt would need to download the source for each of these six libraries and './configure --host=i686-pc-mingw32 ; make ; make install' before they could start on libvirt, and of course it isn't really that simple since those libraries don't all just cross-compile without needing tweaks and patches. Tweaks and patches are what spec files are for. This is why we'd like to ship pre-compiled DLLs (only) of those six libs. I think people have somehow got the impression we want to (a) ship FIREFOX.EXE and/or (b) cross-compile every library in Fedora. I'd like to say that (a) is not our intention, ever, and (b) isn't even technically possible, nevermind that it is completely undesirable. > My personal opinion is that if you're going to need to munge spec files > in order to produce packages built against mingw, those munges need to > be done outside our cvs repo as well. There are two ways that we've proposed that one could build 'mingw-gnutls'. One is as a completely separate package, another is as a subpackage of the ordinary gnutls. I investigated and built packages both ways (see links below) just to see what was technically feasible. It turns out that both methods are *technically* feasible. Which is better from technical, organizational or political points of view is a completely different question. http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=91a808c59de63589367c7bd9750da1fca342c529;path=/gnutls/ http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=91a808c59de63589367c7bd9750da1fca342c529;path=/gnutls-fragment/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From a.badger at gmail.com Tue Jul 22 17:55:16 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Jul 2008 10:55:16 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <20080722162232.GA1754@amd.home.annexia.org> References: <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> <1216659519.3419.7.camel@localhost.localdomain> <20080721165407.GB29941@amd.home.annexia.org> <1216660929.3419.15.camel@localhost.localdomain> <20080722092935.GB5192@redhat.com> <1216728419.12190.61.camel@localhost.localdomain> <20080722162232.GA1754@amd.home.annexia.org> Message-ID: <48861F04.6000501@gmail.com> Richard W.M. Jones wrote: > On Tue, Jul 22, 2008 at 08:06:59AM -0400, Jesse Keating wrote: >> On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote: >>> What is the board's rationale for putting MinGW packages in a separate >>> repository, when other cross-compiler toolchain (eg ARM) are in the main >>> Fedora repository. Seems to me like we're penalizing MinGW just >>> because it happens to be related to Windows, even though MinGW's code >>> is still just as open source as anything else in our repos. >> Actually I think the prevailing thought that the Board has (although >> it's up to FESCo to really nail it down) is that the mingw tools >> themselves are absolutely suitable for Fedora. The libraries compiled >> against it for windows use are what should be in another repo. > > [I'm going to prepare something more detailed, hopefully integrating > efforts with the cross-compiler folks, but just on these two points ...] > > If we ship only the four base packages (mingw-gcc, mingw-binutils, > mingw-w32api and mingw-runtime) then the only software that can be > compiled is software which doesn't use any libraries. That's pretty > restrictive. > > To compile, for example, libvirt, one needs six other libraries. As > with Linux, you need the library around (foo-0.dll) in order to link. > Anyone compiling libvirt would need to download the source for each of > these six libraries and './configure --host=i686-pc-mingw32 ; make ; > make install' before they could start on libvirt, and of course it > isn't really that simple since those libraries don't all just > cross-compile without needing tweaks and patches. Tweaks and patches > are what spec files are for. This is why we'd like to ship > pre-compiled DLLs (only) of those six libs. > When people talk about a separate repo, it's something that would still allow this workflow to happen. The separate repo exists on the Fedora master mirror but mirrors of us have the option to include or exclude these other repos depending on their ability to carry the extra packages. This separate repo will have a yum configuration file that I think should be shipped by default. I think it should also be turned on by default. This would make the fact that there is a different repo for the packages transparent to end users. (However, this portion is something that FESCo decides, not FPC... this case would need to be argued in front of FESCo). > I think people have somehow got the impression we want to (a) ship > FIREFOX.EXE and/or (b) cross-compile every library in Fedora. I'd > like to say that (a) is not our intention, ever, and (b) isn't even > technically possible, nevermind that it is completely undesirable. > Who is "we"? That is the crux of your statements. If a group of Fedora contributors who are not the libvirt team decide that they want to have a complete cross-compilation environment to be able to build firefox.exe for windows under Fedora at some point in the future, I'd like us to not stand in their way. OTOH, even if that never happens, there is still the issue that MingW is not the only crosscompilation system that we want in Fedora. To scale across architectures as well as in depth on one os-architecture also has an impact on mirrors which can be mitigated by having a separate repo. >> My personal opinion is that if you're going to need to munge spec files >> in order to produce packages built against mingw, those munges need to >> be done outside our cvs repo as well. > > There are two ways that we've proposed that one could build > 'mingw-gnutls'. One is as a completely separate package, another is > as a subpackage of the ordinary gnutls. I investigated and built > packages both ways (see links below) just to see what was technically > feasible. It turns out that both methods are *technically* feasible. > Which is better from technical, organizational or political points of > view is a completely different question. > This is partially a FPC issue and partially a FESCo/Board issue. The four people present for the FPC meeting last week discussed this informally and there was consensus that separate packging made more sense. However, FESCo will need to decide how having a separate download repository maps to our cvs repository. The two options I see are separate packages (as discussed by FPC) and separate branches within CVS. Which one is decided will have some influence over any eventual Guidelines that the FPC writes and/or approves. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From vpivaini at cs.helsinki.fi Tue Jul 22 18:36:13 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 22 Jul 2008 21:36:13 +0300 Subject: [Fedora-packaging] Packaging xulrunner extensions: dependencies Message-ID: <200807222136.14999.vpivaini@cs.helsinki.fi> Hi, I recently posted an email about Firefox/xulrunner extensions and dependencies to fedora-devel, but I got no answers, so I'll try this list as well. Here's what I wrote: > As we just saw with nspluginwrapper, packaging things dependening on > xulrunner/Firefox is a bit problematic. My Mozvoikko package was recently > approved by Ville Skytt? > (https://bugzilla.redhat.com/show_bug.cgi?id=448215) but he had a good > question about the dependencies: > > "If I understand correctly, using xulrunner-unstable makes this prone to > breakage on updates - is there some versioned dependency towards some > package that could be used so that it would be easier to notice such > cases?" > > I think the answer here is no. Or is there? We just saw what happens if you > hardcode a xulrunner version as a dependency, there will be breakage as > soon as xulrunner is updated. I had the Mozvoikko package from that review > installed as well and it worked fine after the update of Firefox and > xulrunner. So I think I should just leave the xulrunner dependency > unversioned and rebuild the mozvoikko package if I notice the extension > being broken after a xulrunner update. > > I also noticed something interesting about xulrunner-devel and > xulrunner-devel-unstable. Mozvoikko can't be built just with the stable > headers which apparently are in /usr/include/xulrunner-sdk-1.9/stable/. For > example it needs mozISpellCheckingEngine.h. This file can be found from two > locations, however. The xulrunner-devel package puts it > in /usr/include/xulrunner-sdk-1.9/spellchecker/mozISpellCheckingEngine.h > and the xulrunner-devel-unstable package puts it > in /usr/include/xulrunner-sdk-1.9/unstable/mozISpellCheckingEngine.h. Why > are there two copies and is it considered stable or unstable? I'm thinking > it's "classified" as unstable, but why is it in the "stable devel package" > then as well? If anyone has any answers or ideas on packaging the extension, I would really appreciate the feedback. -- Ville-Pekka Vainio From rc040203 at freenet.de Wed Jul 23 04:10:36 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 23 Jul 2008 06:10:36 +0200 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <20080722162232.GA1754@amd.home.annexia.org> References: <20080721145448.GA29618@amd.home.annexia.org> <1216652734.3603.3.camel@localhost.localdomain> <20080721153956.GA29765@amd.home.annexia.org> <1216656096.3419.2.camel@localhost.localdomain> <20080721164521.GA29941@amd.home.annexia.org> <1216659519.3419.7.camel@localhost.localdomain> <20080721165407.GB29941@amd.home.annexia.org> <1216660929.3419.15.camel@localhost.localdomain> <20080722092935.GB5192@redhat.com> <1216728419.12190.61.camel@localhost.localdomain> <20080722162232.GA1754@amd.home.annexia.org> Message-ID: <1216786236.3042.73.camel@beck.corsepiu.local> On Tue, 2008-07-22 at 17:22 +0100, Richard W.M. Jones wrote: > On Tue, Jul 22, 2008 at 08:06:59AM -0400, Jesse Keating wrote: > > On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote: > > > What is the board's rationale for putting MinGW packages in a separate > > > repository, when other cross-compiler toolchain (eg ARM) are in the main > > > Fedora repository. Seems to me like we're penalizing MinGW just > > > because it happens to be related to Windows, even though MinGW's code > > > is still just as open source as anything else in our repos. > > > > Actually I think the prevailing thought that the Board has (although > > it's up to FESCo to really nail it down) is that the mingw tools > > themselves are absolutely suitable for Fedora. The libraries compiled > > against it for windows use are what should be in another repo. > > [I'm going to prepare something more detailed, hopefully integrating > efforts with the cross-compiler folks, but just on these two points ...] > > If we ship only the four base packages (mingw-gcc, mingw-binutils, > mingw-w32api and mingw-runtime) then the only software that can be > compiled is software which doesn't use any libraries. That's pretty > restrictive. This is way too restrictive. In fact, such a restriction closes out any cross-toolchain from Fedora. > > My personal opinion is that if you're going to need to munge spec files > > in order to produce packages built against mingw, those munges need to > > be done outside our cvs repo as well. Building cross-toolchains inevitably needs some target-libraries. If you want to see cross-toolchain packages in Fedora, these target-libraries must be shipped as part of Fedora. Ralf From dominik at greysector.net Wed Jul 23 19:37:53 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 23 Jul 2008 21:37:53 +0200 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <1216142709.17003.66.camel@localhost.localdomain> References: <1216142709.17003.66.camel@localhost.localdomain> Message-ID: <20080723193753.GA25136@mokona.greysector.net> On Tuesday, 15 July 2008 at 19:25, Tom spot Callaway wrote: > The next Fedora Packaging Committee Meeting will be held on Tuesday, > July 22, 2008. (Note: Normally, the FPC meets every other week, but this > meeting was scheduled since we did not have quorum on July 15, 2008) > > Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as > the Fedora Board meets at 18:00 UTC. I couldn't make it, again, and I'm sorry. The current meeting time is consistently overlapping with my sport activities which can't be rescheduled. That time might change after the vacations are over, but I won't know until then. I'd very much like to change that meeting time or step down from FPC if that's not possible. I don't see any point in being on the Committee if I can't attend the meetings. Moreover, I'm on vacation for the most of August and will only have Internet connectivity via a cellphone, if at all, and that's expensive, so I'll be limiting it as much as possible. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From green at redhat.com Thu Jul 24 16:59:11 2008 From: green at redhat.com (Anthony Green) Date: Thu, 24 Jul 2008 09:59:11 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <488513AF.1050009@math.uh.edu> References: <1216142709.17003.66.camel@localhost.localdomain> <48848F0C.9020409@redhat.com> <488513AF.1050009@math.uh.edu> Message-ID: <4888B4DF.7080904@redhat.com> Jason Tibbitts wrote: > I am on vacation so I haven't had all that much time to review things > properly, but one thing I noticed is that, as someone not familiar > with Lisp who might be reviewing packages, some of the guidelines > don't really enlighten me as to how I might actually tell if a > particular package meets them. For example, I see that libraries > should be managed by "asdf" and that they should be able to load asdf > with some specific lisp code. The guidelines, however, don't inform > me as to how I might tell if the package does those things. Well, it does say where asdf system definition (.asd) files need to be installed. I guess I'm assuming that the packager would realize that the library isn't managed by asdf if no .asd file is present upstream. I've small changes to clarify this. I've also clarified that you should type "(require 'asdf)" at the REPL in order to test if the Lisp implementation is capable of loading asdf. I think that if a package reviewer doesn't know what a REPL is, then they aren't qualified to review a Common Lisp implementation package (although Lisp libraries should be easily reviewable without any Lisp domain knowledge). > Also, a specfile template would really be appreciated. As it is, if > these guidelines were passed, I'd have no idea how to actually review > lisp packages. I'll post a spec template for Lisp libraries. I agree that this would be helpful. But the current draft as written already says where things need to be installed and what the required dependencies are. How can you say it gives you no idea how to review lisp packages? Thanks, AG > > - J< > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From green at redhat.com Thu Jul 24 17:37:43 2008 From: green at redhat.com (Anthony Green) Date: Thu, 24 Jul 2008 10:37:43 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <488513AF.1050009@math.uh.edu> References: <1216142709.17003.66.camel@localhost.localdomain> <48848F0C.9020409@redhat.com> <488513AF.1050009@math.uh.edu> Message-ID: <4888BDE7.4060002@redhat.com> Jason Tibbitts wrote: > Also, a specfile template would really be appreciated. As it is, if > these guidelines were passed, I'd have no idea how to actually review > lisp packages. Ok, done. https://fedoraproject.org/wiki/PackagingDrafts/Lisp When is the next meeting on this subject? Thanks, AG From nicolas.mailhot at laposte.net Thu Jul 24 21:10:39 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jul 2008 23:10:39 +0200 (CEST) Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages Message-ID: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> Hi, Given what happened there: https://bugzilla.redhat.com/show_bug.cgi?id=456580 I'm proposing the following guidelines amendment: https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages Regards, -- Nicolas Mailhot From dominik at greysector.net Thu Jul 24 22:47:55 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 25 Jul 2008 00:47:55 +0200 Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages In-Reply-To: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> References: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> Message-ID: <20080724224755.GB2000@mokona.greysector.net> On Thursday, 24 July 2008 at 23:10, Nicolas Mailhot wrote: > Hi, > > Given what happened there: > https://bugzilla.redhat.com/show_bug.cgi?id=456580 That's a real mess. > I'm proposing the following guidelines amendment: > https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages I'm generally in favour, but ... [...] 1. any package that makes use of fonts in a modern format like OpenType TT (TTF) or OpenType CFF (OTF) MUST have them packaged separately [...] ... what about fonts in other formats which happen to be included in a given package? I don't have any specific examples, just asking. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From cjb at laptop.org Fri Jul 25 03:32:45 2008 From: cjb at laptop.org (Chris Ball) Date: Thu, 24 Jul 2008 23:32:45 -0400 Subject: [Fedora-packaging] Case-insensitive "yum install"? Message-ID: Hi, [Looks like this has been discussed previously, though perhaps not here. Sorry if it's annoying to have it brought up again.] I'd like to make "yum install" case-insensitive (for occasions where there is only one useful interpretation of case), so that I can do e.g. "yum install wxgtk" without first doing "yum search wxgtk" and finding that the required case is "yum install wxGTK". In the unlikely event of repositories containing two packages with the same case-insensitive interpretation (would this meet packaging rules, and is it used by anyone?) we can refuse to operate on anything but the correct case. There is no potential for damage here -- we don't proceed if you might have meant something else. What do people here think? Is there anything I've missed? Thanks, - Chris. -- Chris Ball From tcallawa at redhat.com Fri Jul 25 04:00:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 25 Jul 2008 00:00:36 -0400 Subject: [Fedora-packaging] Case-insensitive "yum install"? In-Reply-To: References: Message-ID: <1216958436.3871.2.camel@localhost.localdomain> On Thu, 2008-07-24 at 23:32 -0400, Chris Ball wrote: > What do people here think? Is there anything I've missed? Only the first several hundred times this has been brought up. :/ I suggest that you submit a patch for review to the yum maintainers, and see what they say. You may have better luck structuring this as a plugin. ~spot From skvidal at fedoraproject.org Fri Jul 25 04:08:52 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jul 2008 00:08:52 -0400 Subject: [Fedora-packaging] Case-insensitive "yum install"? In-Reply-To: <1216958436.3871.2.camel@localhost.localdomain> References: <1216958436.3871.2.camel@localhost.localdomain> Message-ID: <1216958932.10981.63.camel@rosebud> On Fri, 2008-07-25 at 00:00 -0400, Tom "spot" Callaway wrote: > On Thu, 2008-07-24 at 23:32 -0400, Chris Ball wrote: > > > What do people here think? Is there anything I've missed? > > Only the first several hundred times this has been brought up. :/ > > I suggest that you submit a patch for review to the yum maintainers, and > see what they say. You may have better luck structuring this as a > plugin. > it's like 3 lines to make it that way. -sv From tibbs at math.uh.edu Fri Jul 25 09:11:47 2008 From: tibbs at math.uh.edu (Jason Tibbitts) Date: Fri, 25 Jul 2008 04:11:47 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <4888B4DF.7080904@redhat.com> References: <1216142709.17003.66.camel@localhost.localdomain> <48848F0C.9020409@redhat.com> <488513AF.1050009@math.uh.edu> <4888B4DF.7080904@redhat.com> Message-ID: <488998D3.9000507@math.uh.edu> Anthony Green wrote: > I think that if a package > reviewer doesn't know what a REPL is, then they aren't qualified to > review a Common Lisp implementation package (although Lisp libraries > should be easily reviewable without any Lisp domain knowledge). Wow, really? I guess that in that case all I can do is wish you luck in getting any packages reviewed at all. Well, that and that I'm inclined to vote against guidelines which don't explain things sufficiently so that the available reviewer pool is capable of understanding them. - J< From nicolas.mailhot at laposte.net Fri Jul 25 10:25:18 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 12:25:18 +0200 Subject: [Fedora-packaging] Case-insensitive "yum install"? In-Reply-To: References: Message-ID: <1216981518.22751.25.camel@rousalka.okg> On Thu, 2008-07-24 at 23:32 -0400, Chris Ball wrote: > Hi, > > [Looks like this has been discussed previously, though perhaps not here. > Sorry if it's annoying to have it brought up again.] > > I'd like to make "yum install" case-insensitive (for occasions where > there is only one useful interpretation of case), so that I can do > e.g. "yum install wxgtk" without first doing "yum search wxgtk" and > finding that the required case is "yum install wxGTK". This won't work with UTF-8 unless you want to continuously update your code to all the scripts of the world. FESCO explicitely authorized UTF-8 in Provides, and it'll probably spread further mid-term. If you want to fix this use case properly (as in, solid technical solution) you need to change the guidelines for mandatory package name lowercasing (as some other distros are already sane enough to do). Last time this was discussed in FPC/FESCO mandatory lowercasing was rejected. But you can try again. > What do people here think? Is there anything I've missed? You're workarounding bad naming guidelines with a brittle solution. Don't workaround the guidelines, have them fixed. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Fri Jul 25 10:36:40 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 12:36:40 +0200 Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages In-Reply-To: <20080724224755.GB2000@mokona.greysector.net> References: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> <20080724224755.GB2000@mokona.greysector.net> Message-ID: <1216982200.22751.32.camel@rousalka.okg> On Fri, 2008-07-25 at 00:47 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 24 July 2008 at 23:10, Nicolas Mailhot wrote: > > I'm proposing the following guidelines amendment: > > https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages > > I'm generally in favour, but ... > [...] > 1. any package that makes use of fonts in a modern format like OpenType TT > (TTF) or OpenType CFF (OTF) MUST have them packaged separately > [...] > > ... what about fonts in other formats which happen to be included in a given > package? I don't have any specific examples, just asking. Frankly, the other font formats are so much less useful than modern font formats, the probability someone did creative legal restructuring is much lower. The big exception are Type1 fonts but I just hope they can die die die (and if the Tex-Gyre situation is fixed and we can use OTF Tex-Gyre fonts instead of all ther URW font variants we currently ship I'll propose Type1 purging from the repository). In the meanwhile, it may make sense to add Type1 to the list. For other formats, the sad truth is no one so far has volunteered writing doc on how they should be packaged, so I'm afraid no one knows how to review them. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Fri Jul 25 11:03:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jul 2008 13:03:53 +0200 Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages In-Reply-To: <1216982200.22751.32.camel@rousalka.okg> References: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> <20080724224755.GB2000@mokona.greysector.net> <1216982200.22751.32.camel@rousalka.okg> Message-ID: <20080725110353.GB4862@free.fr> On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote: > > Frankly, the other font formats are so much less useful than modern font > formats, the probability someone did creative legal restructuring is > much lower. The big exception are Type1 fonts but I just hope they can > die die die (and if the Tex-Gyre situation is fixed and we can use OTF I don't think this may happen in a while because some very interesting apps (though not mainstream desktop apps, fortunately) uses type1 fonts, mostly using t1lib, like xfig, xdvi, grace. But in general they don't use directly the t1lib way to find fonts, only to render them but most of the time either use a specific way (like grace) or the tex kpathsea way (if I recall well it is what xdvi does). It is quite painfull for packaging not to have something normalized, but I think it should stay as long as those packages are still in fedora, since I don't think that upstream will use *tf fonts, still these are very useful packages, especially for old-timers. > In the meanwhile, it may make sense to add Type1 to the list. For tex I believe that it will be too complicated to use the system fonts. grace don't use embedded fonts anymore. I don't know for other packages, but indeed trying to use system fonts instead of duplicating them is a worth goal. It always seemed to me that it was a must fix even if it was not ain the guidelines, though. -- Pat From nicolas.mailhot at laposte.net Fri Jul 25 11:33:01 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 13:33:01 +0200 Subject: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages In-Reply-To: <20080725110353.GB4862@free.fr> References: <1865.81.64.155.27.1216933839.squirrel@rousalka.dyndns.org> <20080724224755.GB2000@mokona.greysector.net> <1216982200.22751.32.camel@rousalka.okg> <20080725110353.GB4862@free.fr> Message-ID: <1216985581.22751.49.camel@rousalka.okg> On Fri, 2008-07-25 at 13:03 +0200, Patrice Dumas wrote: > On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote: > > > > Frankly, the other font formats are so much less useful than modern font > > formats, the probability someone did creative legal restructuring is > > much lower. Anyway, I've amended the proposal in a less format-oriented version https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages > > The big exception are Type1 fonts but I just hope they can > > die die die (and if the Tex-Gyre situation is fixed and we can use OTF > I don't think this may happen in a while because some very interesting > apps (though not mainstream desktop apps, fortunately) uses type1 > fonts, mostly using t1lib, like xfig, xdvi, grace. Our TEX can use TTF (OpenType TT) and OTF (OpenType CFF) now. Given that OTF (OpenType CFF) embeds something very close to what PDF uses, I'd be surprised if Ghostscript could not use the OTF TEX-Gyre fonts directly. Do we really have so much interecting stuff that depends on Type1 once TEX and GS are out of the way? > > In the meanwhile, it may make sense to add Type1 to the list. > > For tex I believe that it will be too complicated to use the system > fonts. TEX now uses the same formats as everyone else (TTF and OTF). I frankly do not think we can afford (or have the resources) to duplicate megs of fonts in TEX-specific packages. If TEX can not use the fonts in fontconfig directories, it just has to symlink them somewhere it can. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From vgaburici at gmail.com Fri Jul 25 12:04:46 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 25 Jul 2008 15:04:46 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] Message-ID: I did not have time finish writing all the details below, I'll write some more tonight, but before this Type 1 bashing gets out of hand, read the stuff below. If you don't want the gory details, the bottom line is that the mainstream TeX still works best with type-1 fonts. And it isn't likely to go away soon. So I would not rush to deprecate type 1 fonts, unless you want TeX users to stop using Fedora. This isn't likely to change anytime soon. XeTeX is not as robust as the old TeX, and still lacks some features next to pdftex. XeTeX's acceptance with academic publishers is virtually nil today. And they, the publishers dictate what most academics use to write papers, books etc. The mainstream TeX (and by that I mean dvips, dvipdfm and pdftex) cannot currently use OpenType/CFF, but only Type 1 (and some TeX font specialties that are irrelevant in this discussion). CFF fonts need to be converted to Type 1 using otftotfm. Several tools exist to automate the CFF to Type 1 conversion for large font families because this can be a LOT of work using otfotfm directly for fonts that have optical sizes (like the Adobe Pro series). The most notable automation tools are, in order of how complete they are: autoinst from fontools, otfinst, and otftofd. Each has some features the other lacks, however. Most notably fontools lacks optical size support. Some LaTeX packages, like MinionPro, have their own otfotfm wrapper scripts, which are a lot easier to use because some files (enc, fd) come pre-generated. Furthermore, dvips and dvipdfm cannot use TrueType fonts directly (regardless whether they have OpenType features), but can convert them to bitmap PK fonts, which print ok, but may look bad on screen. In contrast pdftex can embed TrueType as outlines in the pdf using \DeclareTruetypeFont. Unfortunately, generating the TeX infrastructure (tfm font metrics, encodings) for TrueType fonts requires MORE work than generating the Type 1 from a CFF. This happens because a different, less featured tool must be used: ttf2tfm. There are some wrappers like ttf2tex (no longer maintained), and fontinst, which is rather outdated. Autoinst (from fontools) is the only tool that handles both OpenType CFF and TrueType. Most tutorials for using TrueType with pdftex recommend using ttf2tfm directly. FYI: XeTeX uses dvipdfmx as backend, which supports all flavors of OpenType, but this requires xdv input that is not the same as the traditional dvi produced by TeX. pdftex does not produce any intermediate format. For some simple usage examples see (note - first one is XeTeX): http://existentialtype.net/2008/07/12/fonts-in-latex-part-one-xelatex/ http://existentialtype.net/2008/07/12/fonts-in-latex-part-two-pdftex-and-opentype/ http://existentialtype.net/2008/07/19/fonts-in-latex-part-three-pdftex-and-truetype/ A complex example using Gentium via ttf2tfm: http://tclab.kaist.ac.kr/ipe/pdftex_3.html To be continued... On Fri, Jul 25, 2008 at 2:33 PM, Nicolas Mailhot wrote: > On Fri, 2008-07-25 at 13:03 +0200, Patrice Dumas wrote: >> On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote: >> > >> > Frankly, the other font formats are so much less useful than modern font >> > formats, the probability someone did creative legal restructuring is >> > much lower. > > Anyway, I've amended the proposal in a less format-oriented version > https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_other_packages > >> > The big exception are Type1 fonts but I just hope they can >> > die die die (and if the Tex-Gyre situation is fixed and we can use OTF > >> I don't think this may happen in a while because some very interesting >> apps (though not mainstream desktop apps, fortunately) uses type1 >> fonts, mostly using t1lib, like xfig, xdvi, grace. > > Our TEX can use TTF (OpenType TT) and OTF (OpenType CFF) now. Given that > OTF (OpenType CFF) embeds something very close to what PDF uses, I'd be > surprised if Ghostscript could not use the OTF TEX-Gyre fonts directly. > > Do we really have so much interecting stuff that depends on Type1 once > TEX and GS are out of the way? > >> > In the meanwhile, it may make sense to add Type1 to the list. >> >> For tex I believe that it will be too complicated to use the system >> fonts. > > TEX now uses the same formats as everyone else (TTF and OTF). I frankly > do not think we can afford (or have the resources) to duplicate megs of > fonts in TEX-specific packages. If TEX can not use the fonts in > fontconfig directories, it just has to symlink them somewhere it can. > > Regards, > > -- > Nicolas Mailhot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From nicolas.mailhot at laposte.net Fri Jul 25 13:18:51 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 15:18:51 +0200 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: References: Message-ID: <1216991931.3502.5.camel@rousalka.okg> On Fri, 2008-07-25 at 15:04 +0300, Vasile Gaburici wrote: > I did not have time finish writing all the details below, I'll write > some more tonight, but before this Type 1 bashing gets out of hand, > read the stuff below. If you don't want the gory details, the bottom > line is that the mainstream TeX still works best with type-1 fonts. > And it isn't likely to go away soon. Drat, and I was so happy to get rid of them :( All my other points still stand, though. ? We should not ship X versions of the same URW fonts. We should consolidate on the most recent one in OTF format. ? We should not hide general-purpose fonts in app-specific directories. TEX should use system fonts directly. ? We should no ship font collections in a single package when the legal context is so dangerous, but audit each font separately. Every time someone has tried the font collection way it has finished badly. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From green at redhat.com Fri Jul 25 13:20:25 2008 From: green at redhat.com (Anthony Green) Date: Fri, 25 Jul 2008 06:20:25 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting (Tuesday July 22) In-Reply-To: <488998D3.9000507@math.uh.edu> References: <1216142709.17003.66.camel@localhost.localdomain> <48848F0C.9020409@redhat.com> <488513AF.1050009@math.uh.edu> <4888B4DF.7080904@redhat.com> <488998D3.9000507@math.uh.edu> Message-ID: <4889D319.4030302@redhat.com> Jason Tibbitts wrote: > Anthony Green wrote: >> I think that if a package reviewer doesn't know what a REPL is, then >> they aren't qualified to review a Common Lisp implementation package >> (although Lisp libraries should be easily reviewable without any Lisp >> domain knowledge). > > Wow, really? I guess that in that case all I can do is wish you luck > in getting any packages reviewed at all. Remember that I'm making a distinction between Lisp implementations and Lisp libraries. The Common Lisp situation is similar to that of Java, in that there are multiple implementations of the language runtime, and many library packages that are designed to work with any of the implementations. Fedora's Java packaging guidelines only cover java libraries, and ignore the implementation side. I think that packaging a Java implementation, much like packaging a Lisp implementation, requires a certain amount of specialized domain knowledge. That's probably why it was omitted from the Java packaging guidelines. > Well, that and that I'm inclined to vote against guidelines which > don't explain things sufficiently so that the available reviewer pool > is capable of understanding them. I could simply drop the Lisp implementation packaging guidelines from my draft (to mirror our Java guidelines), but I'd rather not since what I have is better than nothing. All of the major FOSS Common Lisp implementations are already in Fedora, so it's not like we'll need many reviewers with the rudimentary Lisp knowledge necessary to deal with them. AG From vgaburici at gmail.com Fri Jul 25 19:42:32 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 25 Jul 2008 22:42:32 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <1216991931.3502.5.camel@rousalka.okg> References: <1216991931.3502.5.camel@rousalka.okg> Message-ID: On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot wrote: > ? We should not hide general-purpose fonts in app-specific directories. > TEX should use system fonts directly. XeTeX can do that. TeX probably NEVER will because that violates TDS. If you don't what that means, then don't take on the subject of TeX fonts. From vgaburici at gmail.com Fri Jul 25 20:18:01 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 25 Jul 2008 23:18:01 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <2285a9d20807251250y22d13d78p77bd27bfaa338e3a@mail.gmail.com> References: <1216991931.3502.5.camel@rousalka.okg> <2285a9d20807251250y22d13d78p77bd27bfaa338e3a@mail.gmail.com> Message-ID: On Fri, Jul 25, 2008 at 10:50 PM, Dave Crossland wrote: > 2008/7/25 Vasile Gaburici : > I second the idea that TeX ought to be an exception to the guideline > "not hide general-purpose fonts in app-specific directories"; TeX > predates all other programs in a GNU/Linux system, and TeX users have > hardended expectations about how it works; if Fedora's TeX package > fiddles with things, that will be a loss for users. If Fedora ships a screwed-up TeX, it would incur a loss of users, mostly of PAYING academic ones that buy RHEL through their departments, like UMD's CS dept., which just finished a big upgrade of all the CS RHEL machines... FYI: Macs are already the preferred choice for laptops amongst my colleagues, because the can run both Unix apps and Powerpoint hassle-free (OOo is still pathetic for presentations, and not everyone has the patience that Beamer requires, especially for graphics). Back to the technical side, a font for TeX requires a tfm file (TeX font metrics). To use it with LaTeX you also need a fd file, an sometimes a sty with macros is provided, especially if the font has features. These files don't really belong the the system fonts directory because nothing but TeX can use them... So, for fubu-fonts, you'd need an extra fubu-fonts-tex, or possible even a fubu-fonts-latex package to hold the extra files (you need the latter if you consider that latex is not required to use plain tex). What I would like to see system fonts installing themselves for TeX use, say via an autoinst postinst script. Like I said my "draft" email, that's a lot of hassle for the users to do manually. That's why I'm trying to get fontools resurected... Also, the current texlive package has inconsistent rules for font formats. The Gyre fonts are included as OTF, while the LM (Latin Modern) are not, even though XeTeX needs them that way if you wan to select them as non-default fonts. I suspect this didn't originate from upstream. From nicolas.mailhot at laposte.net Fri Jul 25 21:20:34 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 23:20:34 +0200 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <2285a9d20807251250y22d13d78p77bd27bfaa338e3a@mail.gmail.com> References: <1216991931.3502.5.camel@rousalka.okg> <2285a9d20807251250y22d13d78p77bd27bfaa338e3a@mail.gmail.com> Message-ID: <1217020834.11706.5.camel@rousalka.okg> On Fri, 2008-07-25 at 20:50 +0100, Dave Crossland wrote: > 2008/7/25 Vasile Gaburici : > > On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot > > wrote: > >> ? We should not hide general-purpose fonts in app-specific directories. > >> TEX should use system fonts directly. > > > > XeTeX can do that. TeX probably NEVER will because that violates TDS. > > If you don't what that means, then don't take on the subject of TeX > > fonts. > > I second the idea that TeX ought to be an exception to the guideline > "not hide general-purpose fonts in app-specific directories"; TeX > predates all other programs in a GNU/Linux system, and TeX users have > hardended expectations about how it works; if Fedora's TeX package > fiddles with things, that will be a loss for users. We're under a *nix. The TEX packagers can symlink the files to TEX internal directories if that makes TEX users feel better. Though we've been resorbing various private font repositories in the past years (starting with the xorg ones) and mid term I don't see how TEX can escape the trend. That's the bad thing of switching to a common font format. (The good thing being of course that you get access to the fonts other groups provide) > (I'm still not getting Nicolas' emails :-( I'm routing lab6.com through another smtp now. Of course that won't change mails sent directly to the list. Someone is blackholing me between Red Hat servers and yours. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Fri Jul 25 21:33:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jul 2008 23:33:08 +0200 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: References: <1216991931.3502.5.camel@rousalka.okg> <2285a9d20807251250y22d13d78p77bd27bfaa338e3a@mail.gmail.com> Message-ID: <1217021588.11706.17.camel@rousalka.okg> On Fri, 2008-07-25 at 23:18 +0300, Vasile Gaburici wrote: > On Fri, Jul 25, 2008 at 10:50 PM, Dave Crossland wrote: > > 2008/7/25 Vasile Gaburici : > > I second the idea that TeX ought to be an exception to the guideline > > "not hide general-purpose fonts in app-specific directories"; TeX > > predates all other programs in a GNU/Linux system, and TeX users have > > hardended expectations about how it works; if Fedora's TeX package > > fiddles with things, that will be a loss for users. > > If Fedora ships a screwed-up TeX, it would incur a loss of users, > mostly of PAYING academic ones that buy RHEL through their > departments, like UMD's CS dept., which just finished a big upgrade of > all the CS RHEL machines... Oh, please, I heard the same bogus arguments from Java people when we started integrating Java under Linux at JPackage. I was not the "Java way" (the "Java way" being whatever screwed up setup SUN historically used). There would be a loss of users. Etc, etc A few year forward SUN was quoting JPackage in all its Linux press releases and trying to catch up with us. There is no reason to fear changes when those changes are sound engineering. > Back to the technical side, a font for TeX requires a tfm file (TeX > font metrics). To use it with LaTeX you also need a fd file, an > sometimes a sty with macros is provided, especially if the font has > features. These files don't really belong the the system fonts > directory because nothing but TeX can use them... And thus TEX can keep them. But the common resources (OpenType fonts), it gets to share them with the rest of the system, which means installation in system dirs. > What I would like to see system fonts installing themselves for TeX > use, say via an autoinst postinst script. You're welcome to propose amendments to our current font packaging policy. We have no TEX rules right now because no TEX user was interested in writing them and other people obviously couldn't. The main requirements are: 1. The font specs must be kept simple (ie no complex in-spec scripting) 2. A font package can not require any specific font system on install. It's only allowed to use one if already present, and it's the font system responsability to discover resources that were installed before it was on system. (same proposal to bitmap users that complain of anti-bitmap ostracism) > Like I said my "draft" > email, that's a lot of hassle for the users to do manually. That's why > I'm trying to get fontools resurected... > > Also, the current texlive package has inconsistent rules for font > formats. The Gyre fonts are included as OTF, while the LM (Latin > Modern) are not, even though XeTeX needs them that way if you wan to > select them as non-default fonts. I suspect this didn't originate from > upstream. I can't comment on this part. For me they're all wrong. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From vgaburici at gmail.com Sun Jul 27 10:40:52 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 27 Jul 2008 13:40:52 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <1217090970.28047.7.camel@behdad.behdad.org> References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> Message-ID: I had a look the TDS (http://www.ctan.org/get/tds/tds.pdf). Nothing written there prevents the use of symlinks. In fact their not even mentioned because TDS is supposed work even on MSDOS. The question is if it will actually work if we do that. I guess Jindrich Novy, the texlive packaged owner knows better than any of us, so I'm cc-ing him. So, Jindrich, the question is whether ripping out the TeX fonts formats that are usable by the system at large (via freetype etc.), and replacing them with symlinks in the TDS is going to work? A potential problem that I see is that if texlive gets installed after some fonts it needs to figure out and link to them... On Sat, Jul 26, 2008 at 7:49 PM, Behdad Esfahbod wrote: > On Fri, 2008-07-25 at 22:42 +0300, Vasile Gaburici wrote: >> >> XeTeX can do that. TeX probably NEVER will because that violates TDS. >> If you don't what that means, then don't take on the subject of TeX >> fonts. > > Symlinks? > > -- > behdad > http://behdad.org/ > > "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > -- Benjamin Franklin, 1759 > > From nicolas.mailhot at laposte.net Sun Jul 27 11:08:12 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 Jul 2008 13:08:12 +0200 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> Message-ID: <1217156892.25486.8.camel@rousalka.okg> On Sun, 2008-07-27 at 13:40 +0300, Vasile Gaburici wrote: > I had a look the TDS (http://www.ctan.org/get/tds/tds.pdf). Nothing > written there prevents the use of symlinks. In fact their not even > mentioned because TDS is supposed work even on MSDOS. The question is > if it will actually work if we do that. I guess Jindrich Novy, the > texlive packaged owner knows better than any of us, so I'm cc-ing him. It seems the tex-fonts-hebrew at least provides TEX context for some system fonts http://cvs.fedoraproject.org/viewcvs/devel/tex-fonts-hebrew/tex-fonts-hebrew.spec So proper packaging of Type1, TTF and OTF fonts would probably be something like this 1. normal foo-fonts system package that can be used by any font system, including TEX 2. tex-foo-fonts or foo-texfonts package that depends on foo-fonts and adds additionnal TEX files (without duplicating the font files themselves), with symlinks or references or whatever works in TEX 3. master TEX comps group or package that assembles all the foo-texfonts packages. Of course I know next to nothing about TEX so I'd be a lot happier if people like Jonathan Underwood wrote the whole TEX font packaging rules in my stead. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From vgaburici at gmail.com Sun Jul 27 11:45:06 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 27 Jul 2008 14:45:06 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <1217156892.25486.8.camel@rousalka.okg> References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> Message-ID: The TeXNaming draft guidelines [https://fedoraproject.org/wiki/PackagingDrafts/TeXNaming] seem to indicate that "tex" should go before the package name. E.g. tex-foo-fonts, and perhaps latex-foo-fonts as well. I don't know if ConTeXt needs any special bits for fonts, but in Fedora it gets packaged separately as texlive-context. The only bit that surely doesn't need anything special is texlive-xetex, which can use the system fonts. A minor issue: dvipdfm and dvipdfmx don't have a tex prefix in their package names, even though both put files in the system texmf tree. I don't know if they're usable without TeX installed, but I kinda doubt it... There draft guidelines say that there are several ways to specify the "Requires:" for TeX. But on a recent review, I got this: ? MUST: The package must meet the Packaging Guidelines . The Requires for texlive-latex should be replaced with Requires: tex(latex) The sooner this gets sorted out the better... On Sun, Jul 27, 2008 at 2:08 PM, Nicolas Mailhot wrote: > On Sun, 2008-07-27 at 13:40 +0300, Vasile Gaburici wrote: >> I had a look the TDS (http://www.ctan.org/get/tds/tds.pdf). Nothing >> written there prevents the use of symlinks. In fact their not even >> mentioned because TDS is supposed work even on MSDOS. The question is >> if it will actually work if we do that. I guess Jindrich Novy, the >> texlive packaged owner knows better than any of us, so I'm cc-ing him. > > It seems the tex-fonts-hebrew at least provides TEX context for some > system fonts > http://cvs.fedoraproject.org/viewcvs/devel/tex-fonts-hebrew/tex-fonts-hebrew.spec > > So proper packaging of Type1, TTF and OTF fonts would probably be > something like this > 1. normal foo-fonts system package that can be used by any font system, > including TEX > 2. tex-foo-fonts or foo-texfonts package that depends on foo-fonts and > adds additionnal TEX files (without duplicating the font files > themselves), with symlinks or references or whatever works in TEX > 3. master TEX comps group or package that assembles all the foo-texfonts > packages. > > Of course I know next to nothing about TEX so I'd be a lot happier if > people like Jonathan Underwood wrote the whole TEX font packaging rules > in my stead. > > -- > Nicolas Mailhot > From cmorve69 at yahoo.es Sun Jul 27 12:29:31 2008 From: cmorve69 at yahoo.es (Christian Morales Vega) Date: Sun, 27 Jul 2008 14:29:31 +0200 Subject: [Fedora-packaging] Remakes legality question Message-ID: <8235e6f40807270529s16987787n93a4910894114cf2@mail.gmail.com> I was trying to package a Road Fighter (http://en.wikipedia.org/wiki/Road_Fighter) remake: http://roadfighter.jorito.net/ - http://www.braingames.getput.com/roadf/default.asp in the openSUSE Build Service for openSUSE and Fedora. Since looks like Fedora has more experience and looks deeper at legal questions I'm asking here. The problem is nobody is very sure about the legal questions (http://www.braingames.getput.com/forum/forum_posts.asp?TID=678&PN=1). - Can the remake be named "Road Fighter"? - If isn't just also a "cars game", but even the tracks are made thinking in being the same than in the original game... it's a problem? (if it's a copy of the full game the "full game copyright" applies?) - I suppose the tracks can't have "ads" with "Konami" name, true? - Should any mention to Konami be removed, or things like this one (http://img360.imageshack.us/my.php?image=roadfighterscreenwi0.jpg) aren't a problem? Thanks. From jonathan.underwood at gmail.com Sun Jul 27 13:20:11 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 27 Jul 2008 14:20:11 +0100 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> Message-ID: <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> 2008/7/27 Vasile Gaburici : > The TeXNaming draft guidelines > [https://fedoraproject.org/wiki/PackagingDrafts/TeXNaming] seem to > indicate that "tex" should go before the package name. E.g. > tex-foo-fonts, and perhaps latex-foo-fonts as well. I don't know if > ConTeXt needs any special bits for fonts, but in Fedora it gets > packaged separately as texlive-context. The only bit that surely > doesn't need anything special is texlive-xetex, which can use the > system fonts. > > A minor issue: dvipdfm and dvipdfmx don't have a tex prefix in their > package names, even though both put files in the system texmf tree. I > don't know if they're usable without TeX installed, but I kinda doubt > it... > Yes, that should maybe be fixed up, and one could also make the same argument for xdvik, I suppose. The notion of prefixing with tex- was really meant for addon class file packages for tex, rather than binary programs. But I see your point entirely. > There draft guidelines say that there are several ways to specify the > "Requires:" for TeX. But on a recent review, I got this: > ? MUST: The package must meet the Packaging Guidelines . > The Requires for texlive-latex should be replaced with Requires: tex(latex) > > The sooner this gets sorted out the better... > Yes, it's a mess, and now it's starting to impact progress with resolving the font issues. I had started to make some headway with packaging guidelines a while back, and Patrice had also tackled it, but between us we've dropped the ball. In actual fact, the reason that I had made little headway is that when you start to look at the problem carefully you start to realize that it's a bit of a mistake for Fedora to be repackaging the texlive distribution rather than packaging the individual upstream projects. However, texlive does provide some really handy package integration that we rely on, so we need to make use of that work. We've slowly been making some progress splitting things out, but there's not many packagers who seem to care much about TeX, alas. Anyway, here's some things I see as a bit of a priority: 1) Form a TeX SIG. 2) Get some TeX packaging guidelines in place 3) Work with the fonts SIG to resolve the fonts mess. Regarding 3, it seems to me that there's in principle nothing technically stopping us moving in the direction that Nicholas paints as desireable regarding proper system integration of the fonts (and Nicholas is right to push for this). The approach I could imagine working is roughly this: For each font, create a standalone package which installs the font in the system fonts directory, foo-fonts. During package building that package would create and install the necessary symlinks and auxillary files needed by tex (font metric files etc) and package them in a subpackage, tex-foo-fonts (or maybe foo-fonts-tex). The texlive-texmf-fonts package would then just require all of these tex-foo-fonts packages. The tex-fontools will be really usefully for taking care of this at package build time, so I am really glad that Vasile Gaburici is moving that forward (and the lcdf-typetools packaging). I think this is a better approach than using scriplets to do the same thing at font install time if tex is installed. Of course, until we actually try implementing such an approach, it'll not become clear what the complications are. I have to admit, I'm not massively familiar with the font packaging process in Fedora, but have been reading through the wiki pages and looking at packages this weekend - in fact I hadn't really wanted to raise a proposal until I had a better and more complete understanding of the problem space, but Nicholas' email has spurred me on a bit. What do folks think? And I guess, more importantly, who's up for some work? :) Jonathan. From vgaburici at gmail.com Sun Jul 27 13:31:27 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 27 Jul 2008 16:31:27 +0300 Subject: [Fedora-packaging] Are debuginfos packaged for F9 updates? Message-ID: I can find the debuginfo packages for the F9 release and for the rawhide, but the ones for the F9 updates seem nowhere to be found. Am I missing something obvious? From ville.skytta at iki.fi Sun Jul 27 14:11:32 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 27 Jul 2008 17:11:32 +0300 Subject: [Fedora-packaging] Are debuginfos packaged for F9 updates? In-Reply-To: References: Message-ID: <200807271711.32947.ville.skytta@iki.fi> On Sunday 27 July 2008, Vasile Gaburici wrote: > I can find the debuginfo packages for the F9 release and for the > rawhide, but the ones for the F9 updates seem nowhere to be found. Am > I missing something obvious? http://download.fedora.redhat.com/pub/fedora/linux/updates/9/i386/debug/ From vgaburici at gmail.com Sun Jul 27 14:54:31 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 27 Jul 2008 17:54:31 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> Message-ID: I need to digest this a bit more, but a quick note regarding the (in)abilities of the automated TeX font tools is in order. Some important TeX fonts like Latin Modern (also from GUST), cannot be be currently correctly installed by autoinst. There are two obstacles: - lack of optical size info in the Latin Modern OTFs (no OpenType 'size' tag) - lack of support for optical sizes in autoinst. There's another tool called otfinst (also a wrapper for lcdf-typetools) that can handle optical size info if it is present in the OTF. But otfinst lacks a bunch of other features that autoinst has (no .fd generation, no TTF flavor of OpenType support). At some point I hope to port the opical size support to autoinst, but these tools are written in different languages, so it will take a while. So, Fedora would still have to ship TeX font files separately (for some fonts) until the tool set and upstream OTF packaging matures. But for mundane OTF fonts, which don't have optical sizes, I don't see serious show stoppers for the proposal to (i) generate their .tfm TeX metrics automatically, and (ii) convert them to type 1 on the user's machine. These to jobs could be handled by a simple invocation of autoinst (with some parameters, like telling it if the font is serif or not). So, for most fonts the foo-font-tex package could be just some emtpy dirs and a %post invocation of autoinst. This method needs some testing with various fonts before we commit to it. TrueType fonts can be used used without conversion by pdftex, but TeX metrics still have to be generated. Other TeX drivers, like dvips and dvipdfm, can use TrueType fonts only if they are converted to bitmaps; I don't think this is worth the hassle since the output would suck on screen. Btw, if you've never heard of Latin Modern -- it is the Computer Modern extension to non-English western alphabets. XeTeX, since it supports only UTF-8 input, uses Latin Modern as default font. There's another package, called cm-super, that attempts the same feat, but it uses autotraced fonts, so it's generally considered of inferior quality. The guys from GUST wrote a tool called METATYPE1 which allows them to compile METAPOST into type 1 fonts without autotracing. Latin Modern is written in METATYPE1. Don't ask me if they had permission from Knuth to do this... On Sun, Jul 27, 2008 at 4:20 PM, Jonathan Underwood wrote: > 2008/7/27 Vasile Gaburici : >> The TeXNaming draft guidelines >> [https://fedoraproject.org/wiki/PackagingDrafts/TeXNaming] seem to >> indicate that "tex" should go before the package name. E.g. >> tex-foo-fonts, and perhaps latex-foo-fonts as well. I don't know if >> ConTeXt needs any special bits for fonts, but in Fedora it gets >> packaged separately as texlive-context. The only bit that surely >> doesn't need anything special is texlive-xetex, which can use the >> system fonts. >> >> A minor issue: dvipdfm and dvipdfmx don't have a tex prefix in their >> package names, even though both put files in the system texmf tree. I >> don't know if they're usable without TeX installed, but I kinda doubt >> it... >> > > Yes, that should maybe be fixed up, and one could also make the same > argument for xdvik, I suppose. The notion of prefixing with tex- was > really meant for addon class file packages for tex, rather than binary > programs. But I see your point entirely. > >> There draft guidelines say that there are several ways to specify the >> "Requires:" for TeX. But on a recent review, I got this: >> ? MUST: The package must meet the Packaging Guidelines . >> The Requires for texlive-latex should be replaced with Requires: tex(latex) >> >> The sooner this gets sorted out the better... >> > > Yes, it's a mess, and now it's starting to impact progress with > resolving the font issues. I had started to make some headway with > packaging guidelines a while back, and Patrice had also tackled it, > but between us we've dropped the ball. > > In actual fact, the reason that I had made little headway is that when > you start to look at the problem carefully you start to realize that > it's a bit of a mistake for Fedora to be repackaging the texlive > distribution rather than packaging the individual upstream projects. > However, texlive does provide some really handy package integration > that we rely on, so we need to make use of that work. We've slowly > been making some progress splitting things out, but there's not many > packagers who seem to care much about TeX, alas. > > Anyway, here's some things I see as a bit of a priority: > > 1) Form a TeX SIG. > 2) Get some TeX packaging guidelines in place > 3) Work with the fonts SIG to resolve the fonts mess. > > > Regarding 3, it seems to me that there's in principle nothing > technically stopping us moving in the direction that Nicholas paints > as desireable regarding proper system integration of the fonts (and > Nicholas is right to push for this). The approach I could imagine > working is roughly this: > > For each font, create a standalone package which installs the font in > the system fonts directory, foo-fonts. During package building that > package would create and install the necessary symlinks and auxillary > files needed by tex (font metric files etc) and package them in a > subpackage, tex-foo-fonts (or maybe foo-fonts-tex). The > texlive-texmf-fonts package would then just require all of these > tex-foo-fonts packages. The tex-fontools will be really usefully for > taking care of this at package build time, so I am really glad that > Vasile Gaburici is moving that forward (and the lcdf-typetools > packaging). I think this is a better approach than using scriplets to > do the same thing at font install time if tex is installed. > > Of course, until we actually try implementing such an approach, it'll > not become clear what the complications are. I have to admit, I'm not > massively familiar with the font packaging process in Fedora, but have > been reading through the wiki pages and looking at packages this > weekend - in fact I hadn't really wanted to raise a proposal until I > had a better and more complete understanding of the problem space, but > Nicholas' email has spurred me on a bit. > > What do folks think? And I guess, more importantly, who's up for some work? :) > > Jonathan. > > From vgaburici at gmail.com Sun Jul 27 14:59:23 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 27 Jul 2008 17:59:23 +0300 Subject: [Fedora-packaging] Are debuginfos packaged for F9 updates? In-Reply-To: <200807271711.32947.ville.skytta@iki.fi> References: <200807271711.32947.ville.skytta@iki.fi> Message-ID: Thanks. I was hard to spot in a web browser because the dir above it is full of RPMs... On Sun, Jul 27, 2008 at 5:11 PM, Ville Skytt? wrote: > On Sunday 27 July 2008, Vasile Gaburici wrote: >> I can find the debuginfo packages for the F9 release and for the >> rawhide, but the ones for the F9 updates seem nowhere to be found. Am >> I missing something obvious? > > http://download.fedora.redhat.com/pub/fedora/linux/updates/9/i386/debug/ > > From j.w.r.degoede at hhs.nl Sun Jul 27 15:38:35 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 27 Jul 2008 17:38:35 +0200 Subject: [Fedora-packaging] Remakes legality question In-Reply-To: <8235e6f40807270529s16987787n93a4910894114cf2@mail.gmail.com> References: <8235e6f40807270529s16987787n93a4910894114cf2@mail.gmail.com> Message-ID: <488C967B.608@hhs.nl> Christian Morales Vega wrote: > I was trying to package a Road Fighter > (http://en.wikipedia.org/wiki/Road_Fighter) remake: > http://roadfighter.jorito.net/ - > http://www.braingames.getput.com/roadf/default.asp in the openSUSE > Build Service for openSUSE and Fedora. Since looks like Fedora has > more experience and looks deeper at legal questions I'm asking here. > > The problem is nobody is very sure about the legal questions > (http://www.braingames.getput.com/forum/forum_posts.asp?TID=678&PN=1). > - Can the remake be named "Road Fighter"? If the original was also name "Road Fighter" or something sounding simular: no! > - If isn't just also a "cars game", but even the tracks are made > thinking in being the same than in the original game... it's a > problem? (if it's a copy of the full game the "full game copyright" > applies?) The same concept is okay, so start with an oval then something with more curves etc, exactly the same track layout is copying of probably copyrightable artistic expression and thus is not ok. > - I suppose the tracks can't have "ads" with "Konami" name, true? No, that is a trademark and may not be used without permission > - Should any mention to Konami be removed, or things like this one > (http://img360.imageshack.us/my.php?image=roadfighterscreenwi0.jpg) > aren't a problem? > All references to trademarks, esp. trademarks which relate to the original must be removed. Game clones are allowed with regards to the concept, copying or getting close to copying copyrightable artistic works like graphics, logos, level outlays, music, sounds, etc. is not ok! Using / refering other peoples trademarks also is not ok. Regards, Hans From nicolas.mailhot at laposte.net Sun Jul 27 16:08:29 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 Jul 2008 18:08:29 +0200 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> Message-ID: <1217174909.1480.11.camel@rousalka.okg> On Sun, 2008-07-27 at 14:20 +0100, Jonathan Underwood wrote: > In actual fact, the reason that I had made little headway is that when > you start to look at the problem carefully you start to realize that > it's a bit of a mistake for Fedora to be repackaging the texlive > distribution rather than packaging the individual upstream projects. I totally agree with this assessment > Anyway, here's some things I see as a bit of a priority: > > 1) Form a TeX SIG. > 2) Get some TeX packaging guidelines in place > 3) Work with the fonts SIG to resolve the fonts mess. As long as what you do is text and font-related, you're welcome to work within the Fonts SIG IMHO. Because in case you have noticed, setting up a SIG and making it visible enough to influence upstreams is a lot of work. [OT We're listened to because we have a internet wiki presence so please everyone do take care to fill and update the wiki pages associated to your font packages. I know it's no fun stuff but it helps a lot.] Of course that shouldn't stop you for setting a separate SIG if you feel like it and have the necessary manpower. SIGs are fun. > Of course, until we actually try implementing such an approach, it'll > not become clear what the complications are. That's usually the case. It's an incrementatal ooops-brownpaper-bag-decision process. :p > I have to admit, I'm not > massively familiar with the font packaging process in Fedora, but have > been reading through the wiki pages and looking at packages this > weekend - in fact I hadn't really wanted to raise a proposal until I > had a better and more complete understanding of the problem space, but > Nicholas' email has spurred me on a bit. > > What do folks think? And I guess, more importantly, who's up for some work? :) I obviously am already taken by other stuff, and I'll be away for a month starting tomorrow, but I can offer the Fonts SIG infrastructure. I do think TUG has the potential to be a big font provider, and there's a lot of crossover between the Fonts SIG and what you want to do, so that would be good for everyone. Of course I don't speak for everyone in the SIG, so, people, if you don't want TEX messages to crowd the list, please speak up now. Best regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From vgaburici at gmail.com Sun Jul 27 16:25:10 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 27 Jul 2008 19:25:10 +0300 Subject: Fwd: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: References: <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> <645d17210807270759h6d383a44o654d86b011e586a4@mail.gmail.com> Message-ID: Forwarding to the lists what I've just sent Jonathan... ---------- Forwarded message ---------- From: Vasile Gaburici Date: Sun, Jul 27, 2008 at 7:23 PM To: Jonathan Underwood On Sun, Jul 27, 2008 at 5:59 PM, Jonathan Underwood wrote: > 2008/7/27 Vasile Gaburici : >> So, Fedora would still have to ship TeX font files separately (for >> some fonts) until the tool set and upstream OTF packaging matures. But >> for mundane OTF fonts, which don't have optical sizes, I don't see >> serious show stoppers for the proposal to (i) generate their .tfm TeX >> metrics automatically, and (ii) convert them to type 1 on the user's >> machine. > > Why do (ii) on the users machine instead of at package build time? Nicolas had some concerns on the size of font packages we ship, especially when duplication is involved. I agree that doing the work on the user's machine is somewhat contrary to the idea of RPM... BTW, generating the tfm takes far more time and space. An extreme example is MinionPro (full commercial set, from Adobe): - OTFs: 10Mb - PFBs: 20Mb - TFMs: 180Mb A single type 1 pfb file can contain more than 256 glyphs, but these are addressable only by AGL (Adobe Glyph List) name. Traditinoal TeX encodings (T1, LY1) are limited to 256 glyphs per font, so in order to access all glyphs (e.g. small caps, lining figures) multiple tfm files are generated for the same pfb. This wouldn't be much of a problem if the tfm files didn't ALSO have to contain the kerning info! Take the class-based kerning info from the OTF and make it pairwise, then put overlapping subsets in multiple encodings and the disk usage explodes... Sadly TeX cannot use Adobe's afm file format which could at least store all the kerning pairs without duplication. Btw, Linux Libertine or DejaVu have more glyphs than MinionPro... > These to jobs could be handled by a simple invocation of >> autoinst (with some parameters, like telling it if the font is serif >> or not). So, for most fonts the foo-font-tex package could be just >> some emtpy dirs and a %post invocation of autoinst. This method needs >> some testing with various fonts before we commit to it. >> > > Again - why not use autoinst during package build time? If Nicholas doesn't object, I surely don't. It would be a lot easier to control what happens. >> TrueType fonts can be used used without conversion by pdftex, but TeX >> metrics still have to be generated. Other TeX drivers, like dvips and >> dvipdfm, can use TrueType fonts only if they are converted to bitmaps; >> I don't think this is worth the hassle since the output would suck on >> screen. > > I agree they suck.. but, not doing so would be a problem for legacy > users, I fear... I doubt any legacy user uses ?TrueType? fonts while generating PostScript from TeX. Most legacy users that still rely on PostScript output stick with Type 1 fonts, usually those that come with TeX (Computer Modern, standard 35 PostScript fonts), because these can be embedded as outlines in PostScript. Using TrueType fonts in TeX for PostSript output is no different than using METAFONT fonts: PK bitmaps have to be generated at the output resolution. Now, TeX doesn't ship any bitmap PK fonts when METAFONT sources are available. TeX generates (and caches) them as needed. Remember the old days when you had to wait for "kpathsea: Running mktexpk --mfmode ..." I'm not aware of any program that can do the magic for TrueType fonts, but I haven't used TrueType fonts for PostScript output either. My point is that PK bitmap generation is not something we want to do at packaging time! -- Vasile From vgaburici at gmail.com Sun Jul 27 16:57:50 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 27 Jul 2008 19:57:50 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: <1217174909.1480.11.camel@rousalka.okg> References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> <1217174909.1480.11.camel@rousalka.okg> Message-ID: On Sun, Jul 27, 2008 at 7:08 PM, Nicolas Mailhot wrote: > On Sun, 2008-07-27 at 14:20 +0100, Jonathan Underwood wrote: > >> In actual fact, the reason that I had made little headway is that when >> you start to look at the problem carefully you start to realize that >> it's a bit of a mistake for Fedora to be repackaging the texlive >> distribution rather than packaging the individual upstream projects. > > I totally agree with this assessment Well, the trouble is that there's no Linux/Unix TeX distro like MiKTeX, which has a nice *modular* packaging system. I'd rather have a Fedora-style TeX distro with frequent updates that TeXLive's once a year monolithic disk image. There's a beta version of MiKTeX's packaging tool (mpm) for Linux [http://blog.miktex.org/post/2005/08/mpmunix.aspx], but so far nobody made a Linux TeX distro using it. And that's a lot of work, so I'm not signing up for it on my current schedule... From petersen at redhat.com Mon Jul 28 04:09:20 2008 From: petersen at redhat.com (Jens Petersen) Date: Mon, 28 Jul 2008 14:09:20 +1000 Subject: [Fedora-packaging] broken links in Packaging/SourceURL Message-ID: <488D4670.5080305@redhat.com> Can someone with packaging pages wiki priveleges please fix the broken links on https://fedoraproject.org/wiki/Packaging/SourceURL: [wiki:Self:Packaging/NamingGuidelines#PackageVersion Version] [wiki:Self:Packaging/NamingGuidelines#PackageRelease Release] [wiki:Self:Packaging/NamingGuidelines#SnapshotPackages Naming Snapshots] in the section "Using Revision Control". Thanks, Jens From tcallawa at redhat.com Mon Jul 28 14:54:15 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 28 Jul 2008 10:54:15 -0400 Subject: [Fedora-packaging] broken links in Packaging/SourceURL In-Reply-To: <488D4670.5080305@redhat.com> References: <488D4670.5080305@redhat.com> Message-ID: <1217256855.3863.16.camel@localhost.localdomain> On Mon, 2008-07-28 at 14:09 +1000, Jens Petersen wrote: > Can someone with packaging pages wiki priveleges please fix the broken > links on https://fedoraproject.org/wiki/Packaging/SourceURL: > > [wiki:Self:Packaging/NamingGuidelines#PackageVersion Version] > [wiki:Self:Packaging/NamingGuidelines#PackageRelease Release] > [wiki:Self:Packaging/NamingGuidelines#SnapshotPackages Naming Snapshots] > > in the section "Using Revision Control". Thanks! It should be all fixed now. ~spot From vgaburici at gmail.com Tue Jul 29 08:32:49 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Tue, 29 Jul 2008 11:32:49 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: References: <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> <645d17210807270759h6d383a44o654d86b011e586a4@mail.gmail.com> Message-ID: On Sun, Jul 27, 2008 at 7:25 PM, Vasile Gaburici wrote: > On Sun, Jul 27, 2008 at 5:59 PM, Jonathan Underwood >>> TrueType fonts can be used used without conversion by pdftex, but TeX >>> metrics still have to be generated. Other TeX drivers, like dvips and >>> dvipdfm, can use TrueType fonts only if they are converted to bitmaps; >>> I don't think this is worth the hassle since the output would suck on >>> screen. >> >> I agree they suck.. but, not doing so would be a problem for legacy >> users, I fear... > > I doubt any legacy user uses ?TrueType? fonts while generating > PostScript from TeX. Most legacy users that still rely on PostScript > output stick with Type 1 fonts, usually those that come with TeX > (Computer Modern, standard 35 PostScript fonts), because these can be > embedded as outlines in PostScript. Using TrueType fonts in TeX for > PostSript output is no different than using METAFONT fonts: PK bitmaps > have to be generated at the output resolution. Now, TeX doesn't ship > any bitmap PK fonts when METAFONT sources are available. TeX generates > (and caches) them as needed. Remember the old days when you had to > wait for "kpathsea: Running mktexpk --mfmode ..." I'm not aware of any > program that can do the magic for TrueType fonts, but I haven't used > TrueType fonts for PostScript output either. My point is that PK > bitmap generation is not something we want to do at packaging time! There is actually a way to embed TrueType fonts in PostScript as outlines: Type 42 is a container that gets sent to the printer as-is; the printer's PS interpreter needs to be able to handle Type 42 fonts though. AFAICT ghostscript supports type 42. There are even some FOSS tools to covert between TrueType and Type 42. It seems nobody bothered to automate the process for dvips though. http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/printing.html http://cg.scs.carleton.ca/~luc/type42.html From vgaburici at gmail.com Tue Jul 29 12:27:03 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Tue, 29 Jul 2008 15:27:03 +0300 Subject: [Fedora-packaging] Libtool 2.x? Message-ID: I can't find libtool 2.x in Fedora. Any good reason for this? I need it build freetype (2.3.8pre) from CVS. From mclasen at redhat.com Tue Jul 29 13:26:44 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Jul 2008 09:26:44 -0400 Subject: [Fedora-packaging] Libtool 2.x? In-Reply-To: References: Message-ID: <1217338004.3734.0.camel@localhost.localdomain> On Tue, 2008-07-29 at 15:27 +0300, Vasile Gaburici wrote: > I can't find libtool 2.x in Fedora. Any good reason for this? I need > it build freetype (2.3.8pre) from CVS. This question is better suited for fedora-devel-list. To answer it anyway, you want to CC to the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=435737 From vgaburici at gmail.com Wed Jul 30 15:24:37 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Wed, 30 Jul 2008 18:24:37 +0300 Subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages] In-Reply-To: References: <1216991931.3502.5.camel@rousalka.okg> <1217090970.28047.7.camel@behdad.behdad.org> <1217156892.25486.8.camel@rousalka.okg> <645d17210807270620q3703583bj3f3272fcb17807b2@mail.gmail.com> <1217174909.1480.11.camel@rousalka.okg> Message-ID: Just in time, TeXLive now has a modular installer. Can even install off the net: http://www.river-valley.tv/conferences/bachotex2008/#0104-Reinhard_Kotucha On Sun, Jul 27, 2008 at 7:57 PM, Vasile Gaburici wrote: > On Sun, Jul 27, 2008 at 7:08 PM, Nicolas Mailhot > wrote: >> On Sun, 2008-07-27 at 14:20 +0100, Jonathan Underwood wrote: >> >>> In actual fact, the reason that I had made little headway is that when >>> you start to look at the problem carefully you start to realize that >>> it's a bit of a mistake for Fedora to be repackaging the texlive >>> distribution rather than packaging the individual upstream projects. >> >> I totally agree with this assessment > > Well, the trouble is that there's no Linux/Unix TeX distro like > MiKTeX, which has a nice *modular* packaging system. I'd rather have a > Fedora-style TeX distro with frequent updates that TeXLive's once a > year monolithic disk image. There's a beta version of MiKTeX's > packaging tool (mpm) for Linux > [http://blog.miktex.org/post/2005/08/mpmunix.aspx], but so far nobody > made a Linux TeX distro using it. And that's a lot of work, so I'm not > signing up for it on my current schedule... > From philipp_subx at redfish-solutions.com Wed Jul 30 17:14:10 2008 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 30 Jul 2008 10:14:10 -0700 Subject: [Fedora-packaging] Adding mod_ban to proftpd? Message-ID: <4890A162.2060504@redfish-solutions.com> Matthias et al, Could mod_ban be added to the built packages under Fedora? I run an FTP server, and mod_ban is very handy for protecting against attacks. It doesn't need to be made part of the base package. It could be handled the same way proftpd-ldap or proftpd-postgres is... Thanks, -Philip From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 30 17:20:20 2008 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 30 Jul 2008 19:20:20 +0200 Subject: [Fedora-packaging] Adding mod_ban to proftpd? In-Reply-To: <4890A162.2060504@redfish-solutions.com> References: <4890A162.2060504@redfish-solutions.com> Message-ID: <20080730192020.79f2ac05@python3.es.egwn.lan> Philip Prindeville wrote : > Could mod_ban be added to the built packages under Fedora? I run an FTP > server, and mod_ban is very handy for protecting against attacks. > > It doesn't need to be made part of the base package. It could be > handled the same way proftpd-ldap or proftpd-postgres is... If it's included in the proftpd sources, then sure, please file a bugzilla entry to track the change. If it's an external module, then I'd really prefer if it got merged upstream. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 9 (Sulphur) - Linux kernel 2.6.25.6-55.fc9.x86_64 Load : 0.31 0.25 0.25 From philipp_subx at redfish-solutions.com Wed Jul 30 17:40:43 2008 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 30 Jul 2008 10:40:43 -0700 Subject: [Fedora-packaging] Adding mod_ban to proftpd? In-Reply-To: <20080730192020.79f2ac05@python3.es.egwn.lan> References: <4890A162.2060504@redfish-solutions.com> <20080730192020.79f2ac05@python3.es.egwn.lan> Message-ID: <4890A79B.90508@redfish-solutions.com> Matthias Saou wrote: > Philip Prindeville wrote : > > >> Could mod_ban be added to the built packages under Fedora? I run an FTP >> server, and mod_ban is very handy for protecting against attacks. >> >> It doesn't need to be made part of the base package. It could be >> handled the same way proftpd-ldap or proftpd-postgres is... >> > > If it's included in the proftpd sources, then sure, please file a > bugzilla entry to track the change. > If it's an external module, then I'd really prefer if it got merged > upstream. > > Matthias > It's part of the tarball. I've filed a bug, and submitted a fix. I'd commit it myself, but I've not yet gotten sponsored. https://bugzilla.redhat.com/show_bug.cgi?id=457289 -Philip