Orphaned emacs-htmlize

Hello everybody, I have orphaned the emacs-htmlize [1,2] package. In its current state, the RPM doesn't work with any non-ancient version of GNU Emacs. This needs to be fixed by updating it to a non-ancient upstream release of emacs-htmlize [3]. I haven't used it for more than a decade, and

Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)

Hey Neal, On Mon, 2023-11-06 at 22:33 -0500, Neal Gompa wrote: > On Thu, Nov 2, 2023 at 9:43 PM Neal Gompa wrote: > > > > Hey folks, > > > > As part of the work to upgrade to KDE Plasma 6, appstream is being > > upgraded to a snapshot release as 1.0.0 is arriving soon. There are > > some

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

Hey, I wanted to wrap up this sub-thread on-list, after Owen and I chatted about it off-list. I am fine with having the fedora-toolbox OCI images being defined as kickstart files in the Fedora infrastructure and built by ImageFactory and published as another base image, just like the fedora base

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

Hey Owen, On Mon, 2023-05-29 at 12:39 -0400, Owen Taylor wrote: > On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel > wrote: > > > > My main concern, which I had brought up in the Release Engineering > > tickets before [1,2] is whether the fedora-toolbox i

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

Hey Owen, On Wed, 2023-05-24 at 13:50 -0400, Owen Taylor wrote: > > What if we made the Toolbox container image just one more base image > and built it with ImageFactory? > >  - Integrated into the compose process >  - Across all architectures >  - No OSBS dependency >   > The main disadvantage

Orphaned gnome-valgrind-session

Hello everybody, I have orphaned the gnome-valgrind-session [1, 2] package. It's last release was in 2006, and it doesn't know about Wayland sessions. I haven't used it for more than a decade, and don't have any time or motivation to give it the attention that it needs. Feel free to pick it up

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On Wed, 2023-05-10 at 21:35 +0200, Clement Verna wrote: > > On Tue, 9 May 2023, 15:42 Debarshi Ray via devel, > wrote: > > > > On Tue, 2023-05-09 at 09:45 +0200, Clement Verna wrote: > > > > > > If we do this, we should also make the container base im

Re: disabling yum modular repos by default?

Hey Jens, On Tue, 2023-05-09 at 12:31 +0800, Jens-Ulrik Petersen wrote: > ps I think it would be a good idea to disable the cisco-h264 repo too > by default in the fedora container image, and maybe also for headless > Fedora editions. If we do decide to disable the fedora-cisco-openh264

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

Hey Kevin, On Mon, 2023-05-08 at 09:24 -0700, Kevin Fenzi wrote: > I'm broadly in favor here, some comments in line... > > ...snip... > > It will be beneficial to consider the > > [https://src.fedoraproject.org/container/fedora-toolbox > > fedora-toolbox] images as release-blocking deliverables

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

Hey Zbigniew, On Mon, 2023-05-08 at 19:57 +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: > > I'm broadly in favor here, some comments in line... > > > > ...snip... > > > First, we want to ensure that there are up to date > > >

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

Hey Clement, On Tue, 2023-05-09 at 09:45 +0200, Clement Verna wrote: > > > On Mon, 8 May 2023 at 22:11, Kevin Fenzi wrote: > > On Mon, May 08, 2023 at 07:57:30PM +, Zbigniew Jędrzejewski- > > Szmek wrote: > > > > > > I think we need some clarity wrt. to the dependency order here. > > >

Orphaned GNOME Online Accounts and some related packages

Hello everybody, Due to lack of time and interest, I have orphaned these packages: * gfbgraph * gnome-online-accounts * gnome-online-miners * libzapojit Feel free to pick them up. Thanks, Rishi ___ devel mailing list --

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

Hey, I wanted to respond earlier, but it totally slipped my mind. We'd totally use releasestream in Toolbox for mapping the string "rawhide" to a numeric version: https://github.com/containers/toolbox/issues/646 Cheers, Rishi ___ devel mailing list --

Re: Recommending proprietary software in Fedora

On Mon, Oct 14, 2019 at 07:19:02AM -0700, John M. Harris Jr wrote: > On Monday, October 14, 2019 6:12:18 AM MST mcatanz...@gnome.org wrote: > > On Mon, Oct 14, 2019 at 11:49 AM, John M. Harris Jr > > > > wrote: > > > It's good that we can > > > reference external repositories such as

Re: Fedora in GNOME Online Accountes

Hey, Speaking as someone who understands a little bit of all the pieces involved here, but without claiming to be an expert in anything ... I would expect Flatpak containers to consume Kerberos in roughly the same way as Toolbox [1] containers do. First, the host must be configured to use KCM

Re: libexempi SONAME bump in rawhide

On Mon, Sep 02, 2019 at 04:08:03PM +0200, Nikola Forr? wrote: > On Fri, 2019-08-30 at 20:09 +0000, Debarshi Ray wrote: > > Were you looking for a go ahead to rebuild the affected packages in > > Fedora proper? In that case, you have my whole hearted appreciation > > for t

Re: libexempi SONAME bump in rawhide

Hey, On Fri, Aug 30, 2019 at 03:21:43PM +0200, Nikola Forr? wrote: > I'm planning to update exempi to version 2.5.1 in rawhide, and it > includes a SONAME change from "libexempi.so.3" to "libexempi.so.8". > > Affected packages are: > > caja > eog > eom > equalx > nemo > tellico > tracker-miners

Re: Intent to orphan "tracker"

Hey Igor, On Sun, Jul 28, 2019 at 04:35:49PM +0200, Igor Gnatenko wrote: > I'm getting hundreds of ABRT bugs from tracker which I simply have no > time to go through. Would anybody like to take over that package from > me? In the worst case, I am happy to take it over because I care about some

Re: What does delaying F31 mean for packagers/users?

On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote: > One of the key parts of making a decision to delay/skip F31 is > figuring out, ahead of the decision, what the expected experience is > for users and packagers. Does F30 have normal stability, or do we try > to keep users happy by

Re: Orphaned bouml

On Thu, Aug 09, 2018 at 03:32:35PM +, Debarshi Ray wrote: > I have orphaned the bouml [1, 2] package. I haven't used this > application for almost a decade, and don't have any time or motivation > to give it the attention that it needs. And also its sibling bouml-doc packa

Orphaned bouml

Hello everybody, I have orphaned the bouml [1, 2] package. I haven't used this application for almost a decade, and don't have any time or motivation to give it the attention that it needs. Feel free to pick it up if you want to. If you do, you might want to update it to one of the more recent

Welcome Christopher King!

Hello everybody, I have just sponsored Christopher King (IRC, FAS: bunnyapocalypse) into the 'packager' group. He has been doing some great work getting the WPE port of WebKit into Fedora: * https://bugzilla.redhat.com/show_bug.cgi?id=1601058 *

Re: Non-responsive maintainer process for caillon, and retiring xchat

Hey, On Mon, Sep 04, 2017 at 12:32:38PM +0200, V??t Ondruch wrote: > Unfortunately, you have missed this dependency: > > https://bugzilla.redhat.com/show_bug.cgi?id=1486752 Yes, sorry for missing it initially. However, I emailed konr...@fedoraproject.org last Thursday after you pinged me on

Re: Non-responsive maintainer process for caillon, and retiring xchat

On Mon, Jun 26, 2017 at 11:06:16AM +, Debarshi Ray wrote: > On Wed, Jun 14, 2017 at 03:19:52PM +0000, Debarshi Ray wrote: > > I would like to initiate the non-responsive maintainer process [1] for > > Christopher Aillon [2]. A long time ago, he used to be part of the > &g

Re: F27 System Wide Change: Graphical Applications as Flatpaks

On Sun, Jul 16, 2017 at 11:56:26AM +0100, Richard W.M. Jones wrote: > On Fri, Jul 14, 2017 at 10:04:37PM +0100, Richard Hughes wrote: > > On 14 July 2017 at 20:28, Andreas Tunek wrote: > > > Is this really more reliable than using dnf (for graphical packages > > > like

Re: F27 System Wide Change: Graphical Applications as Flatpaks

On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote: > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote: > > F29: packagers (of graphical applications) must create Flatpaks of > > their applications if possible. They *may* keep standard RPM > > packaging. >

Re: F27 System Wide Change: Graphical Applications as Flatpaks

On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote: > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote: > > F29: packagers (of graphical applications) must create Flatpaks of > > their applications if possible. They *may* keep standard RPM > > packaging. >

Re: Non-responsive maintainer process for caillon, and retiring xchat

On Wed, Jun 14, 2017 at 03:19:52PM +, Debarshi Ray wrote: > I would like to initiate the non-responsive maintainer process [1] for > Christopher Aillon [2]. A long time ago, he used to be part of the > Fedora and Red Hat desktop teams. He is no longer around. He left > software

Re: F27 System Wide Change: Kerberos KCM credential cache by default

Hey, On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote: > = System Wide Change: Kerberos KCM credential cache by default = > https://fedoraproject.org/wiki/Changes/KerberosKCMCache > > Change owner(s): > * Jakub Hrozek > > Default to a new Kerberos credential cache type called KCM

Non-responsive maintainer process for caillon, and retiring xchat

Hello everybody, I would like to initiate the non-responsive maintainer process [1] for Christopher Aillon [2]. A long time ago, he used to be part of the Fedora and Red Hat desktop teams. He is no longer around. He left software development and was last seen living off the grid in Hawaii [3].

Re: Orphaning packages

On Thu, Sep 15, 2016 at 11:39:20AM -0400, Bastien Nocera wrote: > - gnome-web-photo > Requires porting to a newer version of WebKit: > https://bugzilla.redhat.com/show_bug.cgi?id=1375837 > I don't think the maintainer (chpe) is still maintaining it upstream It is just Vincent now because

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

On Wed, Sep 14, 2016 at 02:53:54PM -0700, Thomas Daede wrote: > On 09/14/2016 12:50 PM, Richard Hughes wrote: > > Although, perhaps given upstream has not had a release since 2006 and > > we've acquired 14 out-of-tree security patches (and countless others > > for various fixes) perhaps we should

Re: F24, small backward steps

On Tue, Sep 13, 2016 at 04:24:02PM -0400, Stephen John Smoogen wrote: > OK this is the most frustrating of a TON of frustrating parts of this > conversation. > > 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED? > 2. Why are people 'maintainers' of such packages if they know upstream >

Orphaned gnome-password-generator

Hey, I have orphaned gnome-password-generator [1] in rawhide. It is a Python application written with GTK+ 2.x. I don't think it is actively developed anymore - the last upstream release was in 2008. Feel free to pick it up. Happy hacking, Rishi [1] http://gnome-password.sourceforge.net/

libsoup 2.54.0 accidental ABI break fixed in 2.54.1

A heads-up for those owning packages linking against libsoup. It might be safer to just rebuild all such packages against 2.54.1. - Forwarded message from Dan Winship - Date: Tue, 26 Apr 2016 08:45:54 -0400 From: Dan Winship To:

Re: GNOME 3.19.92 megaupdate

On Tue, Mar 15, 2016 at 10:20:51AM +0100, V?t Ondruch wrote: > IOW some of Gnome developers don't care about sonames, "because it is > just development version". I find your repeated use of phrases like "don't care" to be insulting. Cheers, Rishi pgpEt91WTzy99.pgp Description: PGP signature --

Orphaned starplot and related packages

Hey, I have orphaned the following packages in rawhide: * starplot * starplot-contrib * starplot-gliese3 * starplot-yale5 StarPlot is a 3-dimensional star chart viewer [1]. I don't think it is actively developed anymore - the last upstream release was in 2008. I haven't touched it for 6

Re: Gnome in Rawhide broken

On Thu, Mar 03, 2016 at 12:58:16PM -0600, Michael Catanzaro wrote: > Of course, but surely we can still do soname bumps when removing > previously-released API, to detect such breakage before it reaches > rawhide users. No, we cannot. If we did, then changes to any new API added to gtk+ during

Re: F24 System Wide Change: Default Local DNS Resolver

On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote: > On 04.12.2015 15:57, Lennart Poettering wrote: > > How do other popular desktop/consumer OSes deal with this? Windows, > > MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC > > validation by default and how are they

Summary/Minutes from today's FESCo Meeting (2015-11-18)

=== #fedora-meeting: FESCo (2015-11-18) === Meeting started by rishi` at 18:03:44 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-11-18/fesco.2015-11-18-18.03.log.html . Meeting summary

Schedule for Wednesday's FESCo Meeting (2015-11-18)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-11-18 18:00 UTC' Links to all tickets

Schedule for Wednesday's FESCo Meeting (2015-10-28)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-10-28 18:00 UTC' Links to all tickets

Summary/Minutes from today's FESCo Meeting (2015-10-28)

=== #fedora-meeting: FESCo (2015-10-28) === Meeting started by rishi at 18:01:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-10-28/fesco.2015-10-28-18.01.log.html . Meeting summary

Summary/Minutes from today's FESCo Meeting (2015-10-21)

=== #fedora-meeting: FESCo (2015-10-21) === Meeting started by rishi at 18:00:41 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-10-21/fesco.2015-10-21-18.00.log.html . Meeting summary

Schedule for Wednesday's FESCo Meeting (2015-10-21)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-10-21 18:00 UTC' Links to all tickets

Re: F24 System Wide Change: NetworkManager 1.2

On Mon, Oct 05, 2015 at 12:51:32PM +0200, Jan Kurik wrote: > == Detailed Description == > NetworkManager 1.2 will include significant changes and improvements: > * Port to GDBus /me claps pgp_R7fGPRhMv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org

Schedule for Wednesday's FESCo Meeting (2015-09-16)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-09-16 18:00 UTC' Links to all tickets

Summary/Minutes from today's FESCo Meeting (2015-09-16)

=== #fedora-meeting: FESCO (2015-09-16) === Meeting started by rishi at 18:00:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-09-16/fesco.2015-09-16-18.00.log.html . Meeting summary

Re: Summary/Minutes from yesterday's FESCo Meeting (2015-08-26)

This was missing from the minutes: On Thu, Aug 27, 2015 at 09:01:46AM +, Debarshi Ray wrote: * #1469 i686 as a non-blocking architecture (nirik, 18:37:47) * LINK: https://fedorahosted.org/fesco/ticket/1469 (nirik, 18:37:48) * AGREED: Fedora will ship no i686/32-bit x86 install

Summary/Minutes from yesterday's FESCo Meeting (2015-08-26)

=== #fedora-meeting: FESCO (2015-08-26) === Meeting started by nirik at 18:06:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-08-26/fesco.2015-08-26-18.06.log.html . Meeting summary

Schedule for Wednesday's FESCo Meeting (2015-08-26)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-08-26 18:00 UTC' Links to all tickets

Re: F23 Self Contained Change: Netizen Spin

On Thu, Jun 04, 2015 at 10:45:20AM -0600, Kevin Fenzi wrote: Ideally it would not only install those packages, but configure them to a default to privacy setup. Additionally making some other changes from default desktop settings to do that as well. This is something that could be done in the

Summary/Minutes from today's FESCo Meeting (2015-06-03)

=== #fedora-meeting: FESCo (2015-06-03) === Meeting started by rishi at 18:00:08 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-06-03/fesco.2015-06-03-18.00.log.html . Meeting summary

Schedule for Wednesday's FESCo meeting (2015-06-03)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-06-03 18:00 UTC' Links to all tickets

Re: libgdata-0.17.1 soname bump

On Fri, Apr 24, 2015 at 08:45:50AM +, Debarshi Ray wrote: The recently released libgdata-0.17.1 has bumped its soname. The highlights are support for version 3 of the YouTube API, and an initial port to version 2 of the Drive API. We are going to push the new soname breaking libgdata

Re: F23 System Wide Change: Disable SSL3 and RC4 by default

On Tue, Apr 28, 2015 at 04:51:32PM +0200, Nikos Mavrogiannopoulos wrote: The plan is to allow re-enabling by switching the system to legacy crypto policy. That would work for RC4. For SSL 3.0, since OpenSSL doesn't provide knobs to enable or disable on runtime, that will not be possible.

libgdata-0.17.1 soname bump

Hello everybody, The recently released libgdata-0.17.1 has bumped its soname. The highlights are support for version 3 of the YouTube API, and an initial port to version 2 of the Drive API. This is only for rawhide. I will be rebuilding affected packages. Cheers, Debarshi pgpl6YVdn6arI.pgp

Summary/Minutes from today's FESCo Meeting (2015-04-15)

=== #fedora-meeting: FESCo (2015-04-15) === Meeting started by rishi at 17:59:54 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-04-15/fesco.2015-04-15-17.59.log.html . Meeting summary

Schedule for Wednesday's FESCo Meeting (2015-04-15)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-04-15 18:00 UTC' Links to all tickets

Giving up freetalk, redet and redet-doc

Hello everybody, I am going to give up ownership of the following packages: - freetalk - redet - redet-doc I don't have any interest in them these days and even less time to look after them. Please pick them up if you want to. Thanks, Debarshi -- It has its possibilities but I am bound by

Re: Unannounced soname bump: tracker

On Fri, Dec 27, 2013 at 05:50:18PM -0800, Adam Williamson wrote: Sigh. Yes, another of these. On 2013-12-18, tracker was bumped to 0.7.0: http://koji.fedoraproject.org/koji/buildinfo?buildID=485698 the sonames of libtracker-extract, libtracker-miner and libtracker-sparql were bumped to

Re: Unhelpful update descriptions

RHEL. We're a distribution with First as one of its main objectives. Our users do not want to wait up to a month for updates! It is interesting how you redefine the meaning of First. At the DevConf you were blaming NetworkManager for breaking KDE when they changed API and KDE could not keep

Re: Unhelpful update descriptions

First even if broken is a pretty extreme interpretation of First. First working is much better - and it fits with the purpose of a distribution, to make sure that the various pieces are integrated together (and to help upstream make it happen if necessary). There is no way you can test a

Re: Unhelpful update descriptions

I see one problem with this approach: we're bound to have some update slipping into stable which breaks something that isn't caught in testing. If we do something like that, there needs to be a fast lane for updates fixing such broken updates so people don't have to wait a month for the fix.

Re: Unhelpful update descriptions

unlike other major distros, other updates have less helpful descriptions: * Update to latest upstream version * No update information available * Here is where you give an explanation of your update. Here is where you give an explanation of your update. Perhaps the update policy should

Re: Unhelpful update descriptions

I think it would be a much better use of our time to audit and test updates than writing %changelogs that can be understood by laymen. Spot had a plan related to this. basically bundle up monthly updates to all critpath (non security) stuff, QA it, and then push it out as a bundle. Yes, I

Re: Proposed F19 Feature: Cinnamon as Default Desktop

The FOSDEM poll was stacked ??? no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do [...] So don't overplay the GNOME 3 FOSDEM session, it was an awkward

Re: Proposed F19 Feature: Apache OpenOffice

I'm an Ambassador and this proposal is confusing me. We have LibreOffice in our repositories; I think that bring back Apache OpenOffice generates only confusion between users, not freedom of choice. The confusion is already there in Windows world, linux user should be more capable of

Re: Proposed F19 Feature: Apache OpenOffice

Unlike pulseaudio (in the above linked thread), AOO is end-user GUI application, not a library/daemon/sound-server/whatever used to get the wanted sound to your headphones (that by design interferes with anything else trying to do the same) ;-) By adding AOO we're not breaking some third app,

Re: Proposed F19 Feature: Apache OpenOffice

There are multiple alternative office suites already in Linux. Adding one more isn't really going to aggravate the problem too much for users We suck. So lets suck a little bit more. Is that what you are saying? :-) especially since there is a default installed already. The first time I ran

Re: Proposed F19 Feature: Cinnamon as Default Desktop

I know this applies, but installing gnome-shell pulls in gdm. I.e. removing gdm without removing gnone-shell is not possible. Because gnome-shell (running in a special mode) is nowadays the greeter used by GDM. That does not mean GDM won't let you log into KDE if you have it installed. As

Re: Proposed F19 Feature: Cinnamon as Default Desktop

Keep in mind that to get to the point of installing an alternative-only DE, in current Fedora, you normally first have a full blown Gnome3 installed, which is close to impossible to get rid of. [citation needed] Cheers, Debarshi -- If computers are going to revolutionize education, then

Re: Proposed F19 Feature: Apache OpenOffice

There are multiple alternative office suites already in Linux. Adding one more isn't really going to aggravate the problem too much for users We suck. So lets suck a little bit more. Is that what you are saying? :-) If you want to build a distribution with a single default for everything

Re: Proposed F19 Feature: Apache OpenOffice

sarcasm So what is the next step? Offering another kernel? Or allowing us to choose a different package manager or packing format? Oh, wait, using multiple different depsolvers has already been frowned upon. Now why did *that* happen? It is Fedora, isn't it? /sarcasm Sarcasm isn't

Re: Proposed F19 Feature: Apache OpenOffice

sarcasm So what is the next step? Offering another kernel? Or allowing us to choose a different package manager or packing format? Oh, wait, using multiple different depsolvers has already been frowned upon. deadpan On an F18 system yum info smart yum info dpkg /deadpan You do know the

Re: Proposed F19 Feature: Apache OpenOffice

We empower interested programmers to work on AOO within the Fedora ecosystem. That's all. How is packaging AOO a requirement for that? They can compile AOO and work on it just fine. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and

Re: Proposed F19 Feature: Apache OpenOffice

There are better ways to highlight that not to mention the examples you used already exist in Fedora. So do we have multiple kernels in Fedora? We offer .deb variants of Fedora? That doesn't solve the existing problem at all. There is no reason why we should have say Epiphany but exclude

Re: Proposed F19 Feature: Apache OpenOffice

Reductio ad absurdum. To me this is as absurd as the others. Right. When we moved from Openoffice.org to Libreoffice by default, AOO We could have kept the openoffice.org packages instead of replacing them with LO, but we did not. (I guess, at this point, it is quite clear that I am losing

Re: Proposed F19 Feature: Apache OpenOffice

Let me say one thing: if you're going by examples, go with proper ones. There is vast difference of work needed to support two kernels and work needed to support two office suites. You know kernel is the base upon everything runs, right? Please, don't make the most basic component that cannot

Re: LibRaw: possible license issues

OK, so there are some proprietary or otherwise encumbered plugins that might not be GPLv3-compatible but might be compatible with GPLv2. You again missed the GPLv2 with exceptions part. Plus, this practice of either using LGPLv2+ or GPLv2+ with exceptions for applications is so widespread in

Re: LibRaw: possible license issues

Again, if they are doing this then they are already violating the GPL by shipping GPLv2 code that links to non-free software. The v2 versus v3 thing is a red herring. And yet again, you forgot about the GPLv2+ with exceptions. I think the both of us can keep doing this dance for ever, but

LibRaw: possible license issues

I came across what looks like a possible licensing issue with LibRaw and applications that link to it. I am not totally sure that there is a problem, but I have enough reason to have doubts. I welcome any clarifications and advice. LibRaw's License tag was changed from LGPLv2 or CDDL to GPLv3

Re: LibRaw: possible license issues

If that is the case, then has Yorba been notified of that? I doubt they would suddenly want their code to become GPLv3 instead of LGPLv2+. Why does it matter? Their code hasn't changed, and has not become GPLv3. The package is GPLv3+. It matters because Shotwell links to GStreamer.

Re: LibRaw: possible license issues

Why does it matter? Their code hasn't changed, and has not become GPLv3. The package is GPLv3+. It matters because Shotwell links to GStreamer. GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions because they might end up using proprietary or otherwise unfavourably

Re: Developing for Fedora Operating System

I am seriously considering developing for the Fedora Linux Operating System. I would suggest that you try to get involved in more upstream (eg., GNOME) projects instead of a distribution. That way you are higher up the food chain and effect change on a wider and deeper scale. Best of luck.

guile-2.x: what is the way forward

The update to guile-2.x has been blocked for almost 1.5 years now: https://bugzilla.redhat.com/show_bug.cgi?id=678238 Long story short, existing programs are not ready to use guile-2.x, while newer versions of aiselriot (part of GNOME) need it. Creating a compat-guile or a guile2 package can be

Re: grive open source client for google drive

For example if you configure empathy you *will* use it regardless if you want it or not which makes one wonder how much of Gnome is truly integrated with that stuff. You will use what? How will Empathy or any other GNOME component suddenly start using it (not sure what it is) if you have not

Re: *countable infinities only

Based on the comments of this thread can a working group or sig be set up to build on MG and Co's work to find the most workable solution that preserves the reputation of the project. If you had read the thread carefully, then people (Matthew, Peter, Tom) have made it abundantly clear that if

Re: *countable infinities only

When I create a fork, respin, or remix of Fedora and distribute it to people it will not run for them like Fedora does without a level of fiddling which the people advocating this have made clear is entirely unacceptable. This is because Fedora will be cryptographically signing the

Re: *countable infinities only

My point was to be practical and attempt to get from base 1 to base 2 with the aim of getting to base 4 down the road... Is this not a sensible way forward? It is not clear to me what base N stands for. Happy hacking, Debarshi -- KR is like the Bible. The fervent read it from end to end,

Re: *countable infinities only

By the way, I am assuming that you know that one can't modify Firefox and redistribute it as Firefox without certification. I've been pointing out this issue in several threads. That's exactly why Fedora should finally follow Debian's lead and just rename Firefox. Cool. Why not? But then,

Re: *countable infinities only

They just work as long as you don't try to actually exercise one of the freedoms we stand for. Which one? The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). The freedom to distribute copies of your modified versions to others

Re: *countable infinities only

What if anaconda was change to a license which required forks to certify and pay a one time $99 fee to some shell company, would anyone call Fedora still a free software distribution with a straight face? Yes, if after paying $99 you are free to redistribute your own modified versions. By the

Re: *countable infinities only

This will exclude a whole class of usages that are currently available to Fedora users, such as the ReSpin projects that Fedora Unity used to produce from stock Fedora packages as well as any other downstream projects that build on Fedora. This is not something affecting only a limit set of

Re: Building the GNOME 3.4.1 Release

If you're maintaining a GNOMEish package and you want it included in the 3.4.1 release, please build the package like normal and then add the build ID to: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc Can we not find a way to coordinate GNOME

Re: Looking for co-maintainers for all my packages

I'm not going to orphan these packages, but I would like to find co-maintainers for any and all of them as I find myself with less and less time to give them the full attention they need. [...] * dbus-cxx With the addition of GDbus in Glib, is dbus-cxx still needed? People should directly

Orphaning Decibel Audio Player

I am orphaning decibel-audio-player. It is a audio player written in Python and uses Gtk+ and GStreamer. Rakesh Pandit is already the co-maintainer, so if any one is interested in helping him then please apply for co-maintainership. Regards, Debarshi pgpdqB8TY0qjX.pgp Description: PGP signature

Orphaning some GNOME C++ packages

I am orphaning the following GNOME C++ related packages: + atkmm + glibmm24 + gtkmm24 + gtkmm30 + libsigc++ + libsigc++20 Kalev Lember (kalev) and hguemar have been taking good care of them, so I am more than happy to leave them in their hands. I would also like to release the following Clutter

Re: Unresponsive maintainer for libical

I see [1] the libical is not orphaned yet, neither in devel, nor in F14, as I only can add myself to the package, but not take ownership as with other orphaned packages. I think what happens is when the owner orphans a package one of the co-maintainers automatically get promoted. Cheers,

Re: Unresponsive maintainer for libical

I know I'm not following the NonResponsiveMaintainer policy closely, but I believe, in this particular case, it would be with no gain. I'm fine to take ownership of the libical package and do releases for it. I am orphaning it in PackageDB. Please take up ownership. Thanks, Debarshi --

  1   2   >