Orphaned emacs-htmlize

[Debarshi Ray via devel]

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 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.

Cheers,
Rishi

[1] https://www.emacswiki.org/emacs/Htmlize
[2] https://src.fedoraproject.org/rpms/emacs-htmlize
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2270140
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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 consequences for this change:
> > 
> > [...]
> >
> > I've built appstream in a side-tag, and I'd appreciate it if folks
> > could help by adapting their packages and submitting builds into
> > it.
> > 
> > This can be done with the following command: fedpkg build
> > --target=f40-build-side-76936
> > 
> > My simple query of the consumers of the libraries in question
> > resulted in this:
> > ngompa@fedora ~> sudo dnf repoquery -q --whatrequires
> > "libappstream.so.4()(64bit)" --qf "%{SOURCE_NAME}"
> > appstream
> > appstream-generator
> > flatpak
> > gnome-software
> > libadwaita
> > malcontent
> 
> I've handled appstream, appstream-generator, and appstream-data
> already.
> 
> * Flatpak has an upstream change that needs backporting[1] or a new
> release.

I am working on the Flatpak backport.

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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 image
currently is.

This means that the downstream sources of the images in Fedora that are
actually used to make them available to users will differ from the
upstream sources that are used for testing and CI and are currently
represented as Containerfiles.  If we can't use ImageFactory for
upstream testing and CI, we will have to carefully keep them
synchronized whenever there are changes.  If this is the price to pay
for making the fedora-toolbox images release-blocking deliverables,
then so be it.  :)

That said, my understanding is that Owen is still not settled on all
the tooling changes for building Fedora Flatpaks.  So, we may or may
not end up using ImageFactory for the fedora-toolbox images in the end.

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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 images would
> > continue to be defined as a Docker/Containerfile.  I am asking
> > because the fedora base images are defined as kickstart files [3].
> > 
> > There's some value in continuing to use a Docker/Containerfile
> > because it's widely known and leads to a common workflow.  It is
> > used for the official Toolbx images for other distributions like
> > Arch Linux, RHEL and Ubuntu, and a growing list of third-party
> > Toolbx images [4].  A Docker/Containerfile is easy to use with
> > 'podman build' as part of the upstream CI, which makes it easier to
> > test all the different parts.
> 
> Unfortunately, if we switched to using ImageFactory or pretty much
> anything other than OSBS, we'd no longer be able to define the Fedora
> toolbox image as a Dockerfile. It certainly is a disadvantage that
> it's no longer connected to the way that the other toolbox images are
> defined,

It's an advantage to have the Fedora images be defined in the same
source language as the Arch Linux and Ubuntu images, and certainly the
RHEL images.  However, ultimately, I see it only as a convenience. 
Folks can take the Fedora images as a reference and tweak them to fit
their own distribution, or copy paste the files across Git
repositories, etc..  If we lose that, then I would learn to live with
it.  :)

If we do move away from Container/Dockerfiles, then my main question
would be whether it'll still be easy to locally build the images.  Will
we need something a lot more elaborate than the simplicity of a 'podman
build'?

Toolbx has two parts.  A somewhat distro-agnostic toolbox(1) binary,
and an OCI image for a distribution.  Both work together to provide an
interactive CLI environment, and hence both should be tested together.

If a contributor attempts to change one or both of those two, then it
should be easy for them to verify whether both would continue to work
together.  Currently, they can do that by doing a local 'podman build'
on the image definitions in toolbox.git and try to use them with their
modified toolbox(1) binary.  I want to formalize this by making the
upstream CI run against both:
  (a) images that are currently published on the OCI registries and 
  (b) images that are built on-the-fly from the sources in toolbox.git

... so that it will validate any changes to the image sources in
toolbox.git, and alert us to any changes in the underlying distribution
(eg., packages, dependencies, base images, etc.) that could break
future image rebuilds.

Currently, the upstream CI runs only against (a).

If we lose the simplicity of a 'podman build' then we lose the testing.
That's my main worry.

If the new set-up offers a similarly simple way of building the images
from source, then I am happy.

> but maybe that's bearable if we can substantially improve the
> workflow?

The phrase "we can substantially improve the workflow" makes me
curious.  Any details or pointers?

> With some refactoring of the kickstarts for Fedora containers, we
> could also remove some of the hackiness in the Dockerfile where it is
> undoing choices in the base image.

*nod*

> When I ask this question, I do have a hidden agenda - I'm thinking
> that it might be possible to move Flatpak generation to a Koji plugin
> that runs directly on the builders, but that would leave the toolbox
> as the sole user of the OSBS cluster, which seems dubiously
> sustainable. So maybe we can take Toolbox off of OSBS as well and
> retire OSBS?

Yes, I saw you mention this elsewhere.  I totally understand and agree
with your motivation.  Trying to consolidate the infrastructure does
sound like a good idea.

> Now, if we could instead move to OSBS 2 and have that actively
> maintained and across architecture, that could be better, but I don't
> really see where the resources are going to come from to do that. 

*nod*

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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 is that it is no longer layered, so *if* you
> happen to have the exact same Fedora image version around for some
> other reason (a big if), you save a fraction of space:
>                       
> Fedora 38 container - 71M compressed, 201M uncompressed      
> Toolbox add-on layer -  232M compressed, 753M uncompressed
> Toolbox squashed  - 291M compressed, 884M uncompressed

I am not too attached to the bandwidth or space savings due to the
fedora-toolbox image being a layered image.

[ In future, I would like to  explore if we can ship the fedora-toolbox
image as part of the Silverblue and Workstation ISOs, to avoid the need
for a sizable download just to set up the default Toolbx.  That could
unlock things like defaulting to a Toolbx shell or generally help
promoting Toolbx as a primary interactive CLI environment.  Anyway,
that's a big 'if'.  ]

My main concern, which I had brought up in the Release Engineering
tickets before [1,2] is whether the fedora-toolbox images would
continue to be defined as a Docker/Containerfile.  I am asking because
the fedora base images are defined as kickstart files [3].

There's some value in continuing to use a Docker/Containerfile because
it's widely known and leads to a common workflow.  It is used for the
official Toolbx images for other distributions like Arch Linux, RHEL
and Ubuntu, and a growing list of third-party Toolbx images [4].  A
Docker/Containerfile is easy to use with 'podman build' as part of the
upstream CI, which makes it easier to test all the different parts.

Currently the Fedora and RHEL images that are shipped to users aren't
built straight from the upstream Git repository, but from the separate
copies on Fedora and Red Hat dist-git.  Even then, it's a lot easier to
manage two copies of the sources in the same format, as opposed to one
using Docker/Containerfiles and the other something else like kickstart
files.

Cheers,
Rishi

[1] https://pagure.io/releng/issue/11399#comment-853047
Attached to this Change proposal

[2] https://pagure.io/releng/issue/11189#comment-840689
Past discussion that led to this Change

[3] https://pagure.io/fedora-kickstarts

[4] https://github.com/toolbx-images/images
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaned gnome-valgrind-session

[Debarshi Ray via devel]

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 if you want to.

Cheers,
Rishi

[1] http://hp.cl.no/proj/gnome-valgrind-session/
[2] https://src.fedoraproject.org/rpms/gnome-valgrind-session
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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 images
> > > release blocking since AFAIK they are currently not release
> > > blocking. 
> > 
> > Yes, that's a good point.
> > 
> > The OCI base images aren't currently listed as release-blocking
> > deliverables:
> > https://docs.fedoraproject.org/en-US/releases/f39/blocking/
> > 
> > ... but if this Change goes through, then they will implicitly
> > become release-blocking deliverables because the fedora-toolbox
> > images are based on them.
> > 
> > Should we explicitly mention this in the Change?  Or, something
> > else?  Or, is it fine as it is?
> 
> I think mentioning explicitly in this change is good enough :)
> 

Okay!  I add a note to the Detailed Description section of the Change.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: disabling yum modular repos by default?

[Debarshi Ray via devel]

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 repository on the
base fedora OCI image, then we might have to enable it separately for
the fedora-toolbox images, because the OpenH264 codec is something that
applications running inside the container might want to use.

Coincidentally, changes like these is one of the motivations for:
https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker  :)

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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 because
> > Fedora's [https://opencontainers.org/ OCI] infrastructure is often
> > broken.  Here are [https://pagure.io/releng/issue/11092 two]
> > [https://pagure.io/releng/issue/11367 recent] examples of
> > fedpkg
> > container-build not working.  In the second case, it was
> > preventing the images from being rebuilt to pull in an
> > [https://bugzilla.redhat.com/show_bug.cgi?id=2170878 important]
> > bug-fix.  The broken infrastructure prevents regular Fedora
> > contributors from jumping in to rebuild and publish the images at
> > critical points in the development schedule.  Making them
> > release-blocking deliverables would attract greater attention and
> > scrutiny from release engineering and ensure that a Fedora
> > development
> > cycle does not proceed with broken or outdated or missing
> > fedora-toolbox images.
> 
> I'd like to note that making this blocking doesn't waive any kind of
> magic wand that makes our infrastructure more reliable. ;) 
> The container build pipeline is a long collection of fragile things. 
> It may well result in us slipping more based on things not working.
> ;( 

Yes, I understand.

Currently, what happens is that someone (very often Jens) jumps in to
update the fedora-toolbox images from time to time, sometimes because
users started to complain about missing images after branching or some
other problem, then it turns out that Fedora's OCI infrastructure is
broken, then it leads to a pagure.io/releng issue, and then someone
(very often you, Kevin) jumps in to frantically debug and get things
going again.

I was hoping that by making the fedora-toolbox images release-blocking
deliverables, we will avoid some of the ad-hoc frantic last-minute
fire-fighting and get more eye balls on this part of the Fedora
infrastructure.  Most importantly, Fedora users would get a more robust
and smoother user experience because they won't have to scream and yell
on bug trackers to get new images pushed out the door.

Also, it's not really possible to test the toolbox(1) binary unless the
corresponding fedora-toolbox images are updated and published reliably.

In practical terms, if this means that the Toolbx developers need to
get involved to help out with Fedora's OCI infrastructure, then so be
it.  :)

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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
> > > [https://src.fedoraproject.org/container/fedora-toolbox
> > > fedora-toolbox] OCI images published on
> > > [https://registry.fedoraproject.org/ registry.fedoraproject.org]
> > > as
> > > release-blocking deliverables at critical points in the
> > > development
> > > schedule, just like the installation ISOs for the Editions from
> > > [https://download.fedoraproject.org/pub/fedora/linux/releases/
> > > download.fedoraproject.org].  This must at least happen when an
> > > upcoming Fedora release is branched from Rawhide, and for the
> > > Beta and
> > > Final release candidates.  If possible, they should be updated
> > > more
> > > frequently as part of the nightly composes.  We do not expect
> > > this to
> > > happen after a Fedora release has gone GA.
> 
> I think we need some clarity wrt. to the dependency order here.
> Let's say we:
> > In order to do this at branch point, we will need to move building
> > this
> > image into the compose process and mark it blocking.
> OK, so we build things, but then we need to publish to registry.fp.o,
> which is asynchrounous (?). When we test the newly built ISOs, do
> we test them also with the latest image that we get from
> registry.fp.o?
> And if we find a bug anywhere in this pipeline, we respin everything?

That's our expectation, yes.

When we apply the test criteria to a compose, if the freshly composed
fedora-toolbox OCI images don't meet the test criteria on hosts running
the freshly composed Fedora ISOs, then we track down the bugs, get them
fixed, re-compose, and try again.  Currently, this will happen for the
Beta and Final release candidates.

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Debarshi Ray via devel]

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.
> > > Let's say we:
> > > > In order to do this at branch point, we will need to move
> > > > building this
> > > > image into the compose process and mark it blocking.
> > > OK, so we build things, but then we need to publish to
> > > registry.fp.o,
> > > which is asynchrounous (?). When we test the newly built ISOs, do
> > 
> > No, it happens at the end of the compose (if no blocking
> > deliverables failed causing the compose to fail)
> 
> If we do this, we should also make the container base images release
> blocking since AFAIK they are currently not release blocking. 

Yes, that's a good point.

The OCI base images aren't currently listed as release-blocking
deliverables:
https://docs.fedoraproject.org/en-US/releases/f39/blocking/

... but if this Change goes through, then they will implicitly become
release-blocking deliverables because the fedora-toolbox images are
based on them.

Should we explicitly mention this in the Change?  Or, something else? 
Or, is it fine as it is?

Thanks,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaned GNOME Online Accounts and some related packages

[Debarshi Ray via devel]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Debarshi Ray]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Recommending proprietary software in Fedora

[Debarshi Ray]

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 rpmfusion-free, in my opinion.
> > 
> > We actually cannot do that. It is prohibited because it would entail
> > significant risk.
> 
> And proprietary software, in your opinion, does not?

Depends. The answer to that question lies in the differences between
how copyright and patent laws work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora in GNOME Online Accountes

[Debarshi Ray]

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 credential caches
[2]. That's been the case since Fedora 27.

The container should similarly be configured to use KCM. Then you bind
mount the KCM socket into the container, and things (eg., klist,
kinit, other libkrb5 consumers, etc.) should work.

On Fedora, you can see the path to the socket with:
$ systemctl show --value --property Listen sssd-kcm.socket

There's also libkrb5 API to do the same.

The socket usually lives at /var/run/.heim_org.h5l.kcm-socket

Now, since this is Flatpak, we may eventually want to have a desktop
portal to gate access to the socket instead of giving the application
blanket access. I vaguely recall these old mockups from pre-Flatpak
days, but they very likely need to be revisited:
https://wiki.gnome.org/Design/Whiteboards/EnterpriseLogin

I hope that makes sense.

Cheers,
Rishi

[1] https://github.com/debarshiray/toolbox
[2] https://fedoraproject.org/wiki/Changes/KerberosKCMCache
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libexempi SONAME bump in rawhide

[Debarshi Ray]

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 taking care of the eog and tracker-miners rebuilds. :)
> 
> I would like to do that, but it would require help of a provenpackager,
> since I'm not one myself.

You could apply to become a provenpackager:
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

I will vote for you. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libexempi SONAME bump in rawhide

[Debarshi Ray]

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
> 
> I've rebuilt all of them in Copr [1] without issues, except tellico,
> which failed due to an unrelated bug [2].

Thanks for the heads-up!

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 taking care of the eog and tracker-miners rebuilds. :)

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Intent to orphan "tracker"

[Debarshi Ray]

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
of the packages that use Tracker. My FAS ID is 'rishi'.

Carlos Garnacho is the upstream maintainer and does most of the heavy
lifting, so maybe he is interested in owning it in Fedora too?

Thanks for all your work over the years - much appreciated!

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Debarshi Ray]

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 moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?
> 
> I tend to think about this in terms of GNOME - would we rebase to
> GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> pieces of software where similar considerations apply: container
> tools, cockpit, NetworkManager, etc.
> 
> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?

Umm... can't we treat it the same as the Fedora 20/21 situation?
Skipping a GNOME release can be a bit painful for the upstream GNOME
community, which is overwhelmingly tilted towards Fedora, but it's not
the end of the world either. After all, I don't think the longer
Fedora 21 cycle had any negative long-term effect on that group at
all. :)

The Desktop Team could more aggressively backport bug-fixes to GNOME
3.34 upstream, and if needed backport selected features to Fedora 30
downstream. We have done this during the usual six month Fedora
releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
have done this for RHEL too, so there's some precedence in this area.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned bouml

[Debarshi Ray]

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 package:
https://src.fedoraproject.org/rpms/bouml-doc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MCTVVQ2S4KUV54RWZQUTC2I6MSXLCZEL/

Orphaned bouml

[Debarshi Ray]

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 upstream releases [3].

Someone could also create a Flatpak and submit it to Flathub!

Cheers,
Rishi

[1] http://bouml.free.fr/
[2] https://src.fedoraproject.org/rpms/bouml
[3] https://bugzilla.redhat.com/show_bug.cgi?id=592893
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5DOFEA4O2XEF77VKGU6H7OLD3K6VCEBZ/

Welcome Christopher King!

[Debarshi Ray]

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
  * https://bugzilla.redhat.com/show_bug.cgi?id=1601186
  * https://bugzilla.redhat.com/show_bug.cgi?id=1602078

Also, thanks to Michael Catanzaro and Robert-Andre Mauchin, who have
been reviewing the bulk of his contributions.

Welcome to Fedora, Chris!

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FXTHJN4X3GGYYRYGW5RFIQGB3SH4XXME/

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

[Debarshi Ray]

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 IRC.

Thanks for catching this!

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Debarshi Ray]

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
> > 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]. Therefore I have jumped straight to the fourth step in the
> > aforementioned process.
> > 
> > Here is a list of his packages:
> > https://admin.fedoraproject.org/pkgdb/packager/caillon/
> > 
> > I am particularly interested in xchat, which I want to retire right
> > after removing Chris as the point of contact for his packages.
> 
> Filed: https://pagure.io/fesco/issue/1721

This is done - caillon has been removed as the point-of-contact for
his packages, and xchat has been retired from the f27 and master
branches.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Debarshi Ray]

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 Recepies and Builder)?
> > 
> > It's hugely more reliable. You can't actually trust rpm to do anything
> > atomically,
> 
> Which could be fixed and the fix would benefit everyone ...
> 
> > and this is the main reason we force upgrade to be offline
> > in the workstation product.
> 
> No, that's a workaround for not fixing it properly.

No, that's not true.

(I love one-liners.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Debarshi Ray]

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.
> 
> At least we see where this is going.
> 
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.

How about reliable online updates of running applications as a
benefit?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Debarshi Ray]

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.
> 
> At least we see where this is going.
> 
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.

Huh? How would you get sandboxing without Flatpaks? Unless you are
proposing a different sandboxing technology.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Debarshi Ray]

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 development and was last seen living off the grid in Hawaii
> [3]. Therefore I have jumped straight to the fourth step in the
> aforementioned process.
> 
> Here is a list of his packages:
> https://admin.fedoraproject.org/pkgdb/packager/caillon/
> 
> I am particularly interested in xchat, which I want to retire right
> after removing Chris as the point of contact for his packages.

Filed: https://pagure.io/fesco/issue/1721
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Debarshi Ray]

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 which is
> better suited for containerized environments and provides a better
> user experience in the general case as well.
>
> [...]
> 
> == Scope ==
> * Proposal owners:
> SSSD developers will implement a KCM server. The deamon along with a
> krb5.conf snippet will be packaged in a subpackage called `sssd-krb5`.
> The interested variants of Fedora that would wish to opt in would add
> the `sssd-krb5` subpackage to their compose.
> 
> * Other developers:
> None required

Based on my past conversations with the Identity Management folks, I
think we want this in Workstation. So we also need to support KCM
caches in gnome-online-accounts for the GNOME integration. The
upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=779140
Maybe we should also track it in Fedora?

(One problem with the existing KEYRING caches is the lack of a
notification API. The Kerberos integration in GNOME through
gnome-online-accounts ends up having to poll the kernel's keyring
every few seconds to find out about the state of credentials.

In contrast, KCM is supposed to use D-Bus signals for notification,
and in the past one could use inotify watches with FILE and DIR
caches.)

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Non-responsive maintainer process for caillon, and retiring xchat

[Debarshi Ray]

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]. Therefore I have jumped straight to the fourth step in the
aforementioned process.

Here is a list of his packages:
https://admin.fedoraproject.org/pkgdb/packager/caillon/

I am particularly interested in xchat, which I want to retire right
after removing Chris as the point of contact for his packages.

HexChat [5] is the natural replacement of XChat these days. XChat is
dead [6] - the last upstream release was seven years ago [7]. On the
other hand, HexChat has been a part of Fedora for the last four years,
upstream [4] is involved in both the Fedora [8] and GNOME communities,
and I learnt that the MATE spin already ships it by default.

For what it is worth, this was already discussed and approved on
desk...@lists.fedoraproject.org [9].

Cheers,
Rishi

[1] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
[2] https://admin.fedoraproject.org/accounts/user/view/caillon
[3] 
https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/message/II4EBLEYPDMYVACNWWEK7GQ7Q644LFQK/
[4] https://admin.fedoraproject.org/pkgdb/package/rpms/xchat/
[5] https://hexchat.github.io/
[6] https://en.wikipedia.org/wiki/XChat
[7] http://xchat.org/
[8] https://fedoraproject.org/wiki/User:Tingping
[9] 
https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/thread/KLH6FNU5WW253TKQXZS3CCICUID25X6Q/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning packages

[Debarshi Ray]

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 chpe removed himself in commit
d738f13028a3512f6f7650dbc91c524b23dc25c8. :) Since Vincent
moved on to other projects in 2012, and the last real code commit
was in early 2011, I think it is safe to call it dead.

> - xchat-gnome
>   I started using Polari for IRC

I think we should drop xchat-gnome since hexchat is a worthy
replacement.

pgpQBNtgHPbIf.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Debarshi Ray]

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 drop dep this from applications
> > completely?
> 
> OpenJPEG has long replaced Jasper as the implementation of choice for
> JPEG2000. I think it would be reasonable to drop Jasper and ask
> upstreams to port to a different implementation if they still want
> JPEG2000 support.

That's right. Bugs exist to port gdk-pixbuf and gegl to OpenJPEG, but,
sadly, progress is slow:
 * https://bugzilla.gnome.org/show_bug.cgi?id=739392
 * https://bugzilla.gnome.org/show_bug.cgi?id=764746

pgpKL5YnQJoO3.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Debarshi Ray]

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
> is dead and they aren't going to maintain things.
> 3. If someone isn't going to read the bugzillas why do we even have
> them in bugzilla or the distribution?

Because:

(a) The maintenance status of a package is not a binary variable. It
is easy to imagine a third state - weakly maintained.

(b) The maintenance activity can ebb and flow.

(c) Just because a package is unmaintained and has unattended bugs, it
doesn't mean that it isn't working in the majority of cases.

Sometimes I own a package (let's say) FOO simply because it is in the
dependency chain of something else that I am actively interested
in. At some point in the past, FOO was actively maintained, but that
changed over time. Now, I see the bugs accumulate, and every once in a
couple of cycles when I get some free time I try to go through some of
them. Sometimes somebody else steps up. And if we are lucky, then
things might again pick up in the future.

Yes, strictly speaking, we should remove FOO but that is often not
practical unless the functionality offered by FOO is not interesting
anymore, or there is a suitable replacement. Even if there is a
replacement, it might take a while to do the port (webkitgtk3/WebKit1
comes to mind).


pgpYkf9BBLaUb.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Orphaned gnome-password-generator

[Debarshi Ray]

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/


pgpkI0Cvu2n3G.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

libsoup 2.54.0 accidental ABI break fixed in 2.54.1

[Debarshi Ray]

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: distributor-l...@gnome.org
Subject: libsoup 2.54.0 accidental ABI break fixed in 2.54.1

libsoup 2.54.0 accidentally broke ABI (by adding a member to a class
struct and not removing a corresponding padding member). libsoup 2.54.1
(just released now) fixes this again; any packages that were built
against 2.54.0 (or 2.53.92) will need to be rebuilt against 2.54.1
(though packages built against 2.53.90 or earlier are fine).

(Just to clarify on the versions: this is a stable release in the GNOME
3.20 series, but there has not yet been a release in the 3.21 series, so
libsoup 2.54.1 is now also the latest "unstable" release.)

-- Dan


pgpcvJQxdDHo2.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GNOME 3.19.92 megaupdate

[Debarshi Ray]

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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Orphaned starplot and related packages

[Debarshi Ray]

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 years, if you ignore the GCC 6 FTBFS that I
just fixed today.

Feel free to pick it up.

Happy hacking,
Rishi

[1] http://www.starplot.org/


pgpO_1KzEJaDx.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Gnome in Rawhide broken

[Debarshi Ray]

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 the unstable cycle would require soname bumps. That would
defeat the point of having unstable releases.

Cheers,
Rishi

pgp16cHLlstjP.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Debarshi Ray]

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 dealing with this issue?
> 
> I'm not able to answer this question.

That is troubling. :(

Since this is likely to break networking on a lot of client-side
systems, I would have expected you to do this research before
submitting it as a System Wide Change.

Cheers,
Rishi

pgptg7jbhfzba.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Debarshi Ray]

===
#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
---
* init process  (rishi`, 18:06:48)

* Make (packager) sponsorship slightly easier  (rishi`, 18:07:29)
  * AGREED: Accept proposal to make (packager) sponsorship slightly
easier (+8)  (rishi`, 18:12:41)

* Open Floor  (rishi`, 18:13:09)

* next week's chair  (rishi`, 18:21:21)
  * ACTION: thozza to chair next week  (rishi`, 18:22:06)
  * jwb will be unavailable for the next meeting  (rishi`, 18:22:29)

Meeting ended at 18:22:59 UTC.




Action Items

* thozza to chair next week




Action Items, by person
---
* thozza
  * thozza to chair next week
  * **UNASSIGNED**
* (none)




People Present (lines said)
---
* rishi` (31)
* zodbot (11)
* tibbs|w (10)
* nirik (9)
* dgilmore (9)
* irina__ (5)
* number80 (4)
* sgallagh (3)
* paragan (3)
* thozza (3)
* ajax (2)
* jwb (2)
* rishi (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

pgpgRtZOiPGIY.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 below can be found at:
https://fedorahosted.org/fesco/report/9

= New business =

#topic Make (packager) sponsorship slightly easier
.fesco 1499
https://fedorahosted.org/fesco/ticket/1499

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.

pgp2J6s3Ziqvj.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic Strategy for services that do not have systemd native unit files
.fesco 615
https://fedorahosted.org/fesco/ticket/615

= New business =

#topic Nonresponsive maintainer, ownership transfer request
.fesco 1492
https://fedorahosted.org/fesco/ticket/1492

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

pgp7C64U7kkoW.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

===
#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
---
* init process  (rishi, 18:01:30)

* Strategy for services that do not have systemd native unit files
  (rishi, 18:06:57)
* ACTION: sgallagh will email the decision to devel-announce  (rishi,
18:12:09)

* Nonresponsive maintainer, ownership transfer request  (rishi,
  18:12:28)
  * AGREED: Since there is still some activity from TC, vjancik should
"follow the process" and try to contact TC before proceeding
further. We suggest that they work out a way to update the Node.js
stack in Fedora ? (+7)  (rishi, 18:25:03)

* next weeks chair  (rishi, 18:25:25)
  * ACTION: ajax to chair next week  (rishi, 18:27:04)

* Open Floor  (rishi, 18:27:13)
  * ACTION: sgallagh will discuss bug 1227379 with the systemd
developers at systemd.conf  (rishi, 18:39:01)

Meeting ended at 18:47:13 UTC.




Action Items

* sgallagh will email the decision to devel-announce
* ajax to chair next week
* sgallagh will discuss bug 1227379 with the systemd developers at
  systemd.conf




Action Items, by person
---
* ajax
  * ajax to chair next week
* sgallagh
  * sgallagh will email the decision to devel-announce
  * sgallagh will discuss bug 1227379 with the systemd developers at
systemd.conf
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* rishi (46)
* sgallagh (27)
* nirik (27)
* zodbot (11)
* ajax (9)
* dgilmore (8)
* jwb (5)
* linuxmodder (2)
* smdeep (2)
* Mohamed_Fawzy (1)
* mattdm (1)
* stickster (1)
* paragn (0)
* number80 (0)
* thozza (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

pgpj3iOamEkQs.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

===
#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
---
* init process  (rishi, 18:01:03)

* establish Fedora Bat-Signal for ultra-critical security updates
  (rishi, 18:07:44)
  * LINK:
https://fedoraproject.org/wiki/User:Pfrields/Critical_security_update_SOP
(mattdm, 18:09:09)
  * ACTION: mattdm to contact security team about this  (mattdm,
18:15:03)
  * AGREED: Defer voting until mattdm 's starts a conversation with the
security team. (+5)  (rishi, 18:18:35)

* clarifications/improvements for new bundling policy  (rishi, 18:18:57)
  * AGREED: Postpone this since neither nirik nor sgallagh are here
today. (+6)  (rishi, 18:22:05)

* Package esound was retired without approval of package maintainer
  (rishi, 18:22:23)
  * ACTION: jwb and dgilmore will take care of restoring esound  (rishi,
18:25:56)
  * AGREED: Restore esound to Fedora proper. (+6)  (rishi, 18:26:23)

* next week's chair  (rishi, 18:26:50)
  * ACTION: rishi to chair next week  (rishi, 18:27:59)
  * esound unretired  (dgilmore, 18:28:02)

* Open Floor  (rishi, 18:28:15)
  * paragan is not available for next 2 meetings.  (paragan, 18:28:25)
  * LINK:
https://fedorapeople.org/groups/schedule/f-23/f-23-elections.html
(jkurik, 18:29:35)
  * number80 will be unavailable for the next two meetings too
(number80, 18:30:53)
  * LINK:

https://fedoraproject.org/wiki/Extras/SteeringCommitteeHistory#Members_of_February_2015_-_June_2015
(paragan, 18:31:18)
  * Fedora 23 RC2 is building right now.  (rishi, 18:34:42)

Meeting ended at 18:39:29 UTC.




Action Items

* mattdm to contact security team about this
* jwb and dgilmore will take care of restoring esound
* rishi to chair next week




Action Items, by person
---
* dgilmore
  * jwb and dgilmore will take care of restoring esound
* jwb
  * jwb and dgilmore will take care of restoring esound
* mattdm
  * mattdm to contact security team about this
* rishi
  * rishi to chair next week
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* rishi (62)
* dgilmore (23)
* mattdm (18)
* ajax (10)
* zodbot (9)
* jwb (9)
* paragan (7)
* jkurik (4)
* thozza1 (3)
* number80 (1)
* thozza (1)
* sgallagh (0)
* nirik (0)
* ( (0)
* paragn) (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

pgpusRO_uheGk.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic establish Fedora Bat-Signal for ultra-critical security updates
.fesco 1278
https://fedorahosted.org/fesco/ticket/1278

#topic clarifications/improvements for new bundling policy
.fesco 1491
https://fedorahosted.org/fesco/ticket/1491

= New business =

#topic Package esound was retired without approval of package maintainer
.fesco 1488
https://fedorahosted.org/fesco/ticket/1488

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.


pgphEqq1OO4FM.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F24 System Wide Change: NetworkManager 1.2

[Debarshi Ray]

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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1465 dreamweb is in fedora with a license that does not allow
modification
.fesco 1465
https://fedorahosted.org/fesco/ticket/1465

= New business =

#topic #1473 Changes approval process should reflect the existence of WGs
.fesco 1473
https://fedorahosted.org/fesco/ticket/1473

#topic #1478 F24 Self Contained Changes
.fesco 1478
https://fedorahosted.org/fesco/ticket/1478

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

pgpJiUXSyspug.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

===
#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
---
* init process  (rishi, 18:00:36)

* dreamweb is in fedora with a license that does not allow modification
  (rishi, 18:04:11)
* AGREED: Close the ticket because the legal issue is solved and
  ignore the space problem for mirrors. (+7)  (rishi, 18:09:10)

* F24 Self Contained Changes  (rishi, 18:09:19)
  * AGREED: Approved - Anaconda Using LVM DBus API (+8)  (rishi,
18:10:48)

* Changes approval process should reflect the existence of WGs  (rishi,
  18:11:13)
* AGREED: The WG liason is there for the exact purpose of making sure
  they raise concerns over issues or concerns that the WG may have. It
  covers concerns with the Changes also so there is nothing that needs
  changed here. However the liasons should with changes. (+6)  (rishi,
  18:36:25)

* next weeks chair  (rishi, 18:36:43)
  * ACTION: dgilmore to chair next week  (rishi, 18:37:45)

* Open Floor  (rishi, 18:37:50)
  * sgallagh will table the bundling discussion in 2 weeks  (rishi,
18:42:46)

Meeting ended at 18:44:58 UTC.




Action Items

* dgilmore to chair next week




Action Items, by person
---
* dgilmore
  * dgilmore to chair next week
  * **UNASSIGNED**
* (none)




People Present (lines said)
---
* rishi (74)
* sgallagh (36)
* dgilmore (32)
* jwb (31)
* thozza (24)
* nirik (20)
* zodbot (10)
* jkurik (8)
* paragan (5)
* Southern_Gentlem (4)
* ajax (3)
* stickster (2)
* nyazdani (1)
* hguemar (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

pgpyQaUCPIBME.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 media in Fedora
24 as a primary/blocking deliverable. (+7,0,0)

pgpx9DgbpecAg.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

===
#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
---
* init process  (nirik, 18:06:03)
  * LINK: https://freenode.net/faq.shtml#fst :)  (nirik, 18:07:35)

* #1444 updates deliverables  (nirik, 18:10:34)
  * LINK: https://fedorahosted.org/fesco/ticket/1444   (nirik, 18:10:34)
* AGREED: will defer a week and revisit (+6,0,0)  (nirik, 18:17:46)

* #1466 non-responsive maintainer exception process for skottler
  (nirik, 18:17:54)
* LINK: https://fedorahosted.org/fesco/ticket/1466   (nirik, 18:17:55)
  * AGREED: if no status update from maintainer by 2015-08-31 12UTC, all
  their packages will be orphaned (+6,0,0)  (nirik, 18:30:43)

* #1467 Progress at Change Checkpoint: Completion deadline (testable)
  (nirik, 18:31:16)
* LINK: https://fedorahosted.org/fesco/ticket/1467   (nirik, 18:31:16)
  * will follow these last changes closely and visit next week  (nirik,
  18:37:32)

* #1469 i686 as a non-blocking architecture  (nirik, 18:37:47)
  * LINK: https://fedorahosted.org/fesco/ticket/1469   (nirik, 18:37:48)

* #1472 Investigate mysterious enabled systemd presets  (nirik,
  18:56:09)
* LINK: https://fedorahosted.org/fesco/ticket/1472   (nirik, 18:56:09)
  * AGREED: We will use the policy proposal in comment 2 of ticket 1472
  moving foward for presets. (+6,0,0)  (nirik, 19:06:14)
* ACTION: sgallagh number80 and paragan will review sevices and we
will revist list next week.  (nirik, 19:07:40)

* next weeks chair  (nirik, 19:09:21)
  * ACTION: jwb to chair next week  (nirik, 19:10:05)

* Open Floor  (nirik, 19:10:11)

Meeting ended at 19:13:05 UTC.




Action Items

* sgallagh number80 and paragan will review sevices and we will revist
  list next week.
  * jwb to chair next week




Action Items, by person
---
* jwb
  * jwb to chair next week
  * number80
* sgallagh number80 and paragan will review sevices and we will revist
list next week.
* paragan
  * sgallagh number80 and paragan will review sevices and we will revist
  list next week.
  * sgallagh
* sgallagh number80 and paragan will review sevices and we will 
revist
list next week.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nirik (100)
* sgallagh (52)
* number80 (44)
* jwb (42)
* dgilmore (24)
* debarshi (22)
* thozza (14)
* zodbot (11)
* paragan (8)
* adamw (1)
* rishi (0)
* ajax (0)
* hguemar (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

pgpmYTBOIKVYm.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1444 updates deliverables
.fesco 1444
https://fedorahosted.org/fesco/ticket/1444

#topic #1466 non-responsive maintainer exception process for skottler
.fesco 1466
https://fedorahosted.org/fesco/ticket/1466

#topic #1467 Progress at Change Checkpoint: Completion deadline (testable)
.fesco 1467
https://fedorahosted.org/fesco/ticket/1467

#topic #1469 i686 as a non-blocking architecture
.fesco 1469
https://fedorahosted.org/fesco/ticket/1469

= New business =

#topic #1472 Investigate mysterious enabled systemd presets
.fesco 1472
https://fedorahosted.org/fesco/ticket/1472

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

pgpuw2yAomazj.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 Self Contained Change: Netizen Spin

[Debarshi Ray]

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 spin %post or the like (all the other spins setup
 various config there), or perhaps in a seperate package like a
 'netizen-privacy' that makes those changes. 

But, but ...

 So, you not only include say tor, but you setup the browser to use it
 by default, etc. 

... then there is the issue of choice. I am paranoid, but I also have
strong opinions on how my desktop should look and behave. Will we be
offering different variants of the Netizen spin, then?

Or have we finally given up on this choice thing? ;)

You could take that as a general criticism of most of the non-DE spins
out there.

I would be happier if someone did the hard work of making things more
secure, in the products and spins that we already have.  I don't think
our users should have to choose between a more secure and a less
secure Fedora. eg., just because someone wants to use Tor, doesn't
mean that she should have to install a different flavour of
Fedora. She should be able to configure it in any of the flavours or
products that she is already using.

Other than that, I have found it hard to comprehend the text on the
Wiki.  It spends a lot of time talking about a paper from 1943 and
physiological needs. I don't understand why citizens are considered
alternative users of Fedora.

Cheers,
Debarshi

pgpEJiT6i1NZK.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

===
#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
---
* init process  (rishi, 18:01:08)

* #1442 Admin and Commits privileges for Puppet package  (rishi,
  18:02:01)
* AGREED: Grant ACLs to gchamoul (+6)  (rishi, 18:05:32)

* #1444 updates deliverables  (rishi, 18:05:46)
  * AGREED: Postpone and wait for dgilmore to return from the FAD. (+7)
  (rishi, 18:10:39)

* #1445 F23 Self Contained Changes  (rishi, 18:10:55)
  * AGREED: Let's explicitly ask things this week, and postpone taking a
  decision to next week (+7)  (rishi, 18:24:56)

* Next week's chair  (rishi, 18:25:52)
  * paragan will chair next week's meeting  (rishi, 18:26:52)

* Open Floor  (rishi, 18:26:58)
  * LINK:
  https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
  suggests grepping the RPM scripts should work. But then there are
  the kickstarts.  (mitr, 18:34:03)

Meeting ended at 19:00:12 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* rishi (57)
* sgallagh (47)
* nirik (24)
* thozza (24)
* mitr (15)
* gholms (10)
* jkurik (10)
* dgilmore (10)
* zodbot (9)
* jwb (9)
* paragan (7)
* ajax (4)
* paragn (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

pgp_IsekaP2Lw.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1442 Admin and Commits privileges for Puppet package
.fesco 1442
https://fedorahosted.org/fesco/ticket/1442

#topic #1444 updates deliverables
.fesco 1444
https://fedorahosted.org/fesco/ticket/1444

#topic #1445 F23 Self Contained Changes
.fesco 1445
https://fedorahosted.org/fesco/ticket/1445

= New business =

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.

pgpmak0NM6pBJ.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: libgdata-0.17.1 soname bump

[Debarshi Ray]

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-0.17.1 into
Fedora 22 now [1], because various applications that interact with Google
Drive and YouTube are broken.

Kalev has introduced a compat-libgdata19 package that provides the
older ABI, but this one doesn't have any headers because the API is
unchanged and (non-Fedora) software should just move to the new
version as they are rebuilt and updated.

I have rebuilt all F22 packages that require libgdata - even the ones
that use Google services other than Drive and YouTube to prevent two
different sets of symbols from accidentally entering into the same
process.

I will now go ahead test the applications that I am familiar with. In the
meantime, karma [1] and feedback welcome.

Thanks,
Debarshi

[1] 
https://admin.fedoraproject.org/updates/claws-mail-3.11.1-7.fc22,ffgtk-0.8.6-13.fc22,california-0.4.0-2.fc22,eog-plugins-3.16.0-2.fc22,gnome-photos-3.16.2-2.fc22,evolution-3.16.2.1-2.fc22,evolution-data-server-3.16.2-3.fc22,grilo-plugins-0.2.14-3.fc22,gnome-documents-3.16.2-2.fc22,gnome-online-miners-3.14.3-2.fc22,compat-libgdata19-0.16.1-1.fc22,libgdata-0.17.1-1.fc22

 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


-- 


pgpyK2Gw3kysM.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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. However, according to Tomas Mraz openssl already disables SSL
 3.0 in F22, and there were no major issues reported so that would be no
 issue.

Could you please clarify it in the Upgrade/compatibility impact part
of the change proposal? The current text is cryptic and having some
clear information about this plan will be useful.

Thanks,
Debarshi

pgpSG0s5Y8fB_.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

libgdata-0.17.1 soname bump

[Debarshi Ray]

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
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

===
#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
---
* init process  (rishi, 18:00:26)

* #1416 F22 Changes - Progress at Change Checkpoint: Change Checkpoint:
  100% Code Complete Deadline  (rishi, 18:03:12)
* AGREED: Close the ticket, it's done (+7)  (rishi, 18:08:37)

* #1428 cloud vagrant box  (rishi, 18:10:25)
  * AGREED: Push it to F23 (-6)  (rishi, 18:19:48)

* #1427 List of release blocking deliverables  (rishi, 18:20:08)
  * AGREED: Have a list of release deliverables for F23 at least two
  weeks before the Alpha Freeze with release blocking deliverables
  marked.  (rishi, 18:28:02)

* Open Floor  (rishi, 18:28:55)

* Next week's chair  (rishi, 18:30:30)
  * jwb will chair next week's meeting  (rishi, 18:31:03)
* jreznik and jkurik will propose the F23 schedule next week  (rishi,
18:33:33)

Meeting ended at 18:33:45 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* rishi (46)
* nirik (22)
* dgilmore (18)
* jreznik (16)
* ajax (14)
* jwb (13)
* mitr (12)
* sgallagh (8)
* zodbot (8)
* thozza (7)
* paragan (5)
* walters (3)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

pgpjEGSlibIwB.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Debarshi Ray]

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 below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1416 F22 Changes - Progress at Change Checkpoint: Change
Checkpoint: 100% Code Complete Deadline
.fesco 1416
https://fedorahosted.org/fesco/ticket/1416

= New business =

#topic #1427 List of release blocking deliverables
.fesco 1427
https://fedorahosted.org/fesco/ticket/1427

#topic #1428 cloud vagrant box
.fesco 1428
https://fedorahosted.org/fesco/ticket/1428

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.

pgpHkpdVd4LNI.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Giving up freetalk, redet and redet-doc

[Debarshi Ray]

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 my limitations.  -- Vivek Shah

pgpIW1lwhnScD.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unannounced soname bump: tracker

[Debarshi Ray]

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 0.18.so.0 (from 0.16.so.0) without
 announcement, and without all dependent packages being successfully
 rebuilt. At least the following still depend on the old sparql library:

The thing with Tracker is that they bump the bump the soname and their
pkgconfig file version somewhat gratuitously every six months.

I built a new tracker because some applications (eg., gnome-photos)
specifically want the features in the 0.17/0.18 series.

I thought I had rebuilt all the affected packages, but obviously I
missed some.

 bijiben-0:3.11.1-1.fc21.x86_64
 brasero-0:3.11.3-1.fc21.x86_64

I thought the round of builds for 3.11.3 would take care of these two, but
it looks like bijiben was not built by mclazy and brasero got built before
the new tracker hit the trees. :-/

 grilo-plugins-0:0.2.9-2.fc21.x86_64
 media-explorer-0:0.4.4-5.fc21.x86_64

These two need new upstream releases, but the patches are already in
Git.

 What does it take for people to handle soname bumps properly?

Barring media-explorer, everything else is part of the GNOME stack so
chances of other spins being broken by this was low.

My assumption was that sooner or later this would be sorted by the
GNOME builds during the 3.11.x cycle. Given that the Fedora and GNOME
schedules are quite a bit out of sync these days, I was hoping for
some transient rawhide breakage during the Christmas break to go
largely unnoticed. I mean if this is the only thing broken in Rawhide
at the moment, then I would be more than happy. :)

Anyway. Thanks for taking care of this, and sorry for the trouble.

Cheers,
Debarshi

-- 
Wearing non-prescription glasses and embracing obscurity doesn't
necessarily make you a hipster.  -- Anonymous

pgpVCqzvqJGyZ.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unhelpful update descriptions

[Debarshi Ray]

 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 up, while GNOME did.

So maybe we should just ship code right from the Git masters of all upstreams?

 I also don't think such 
 huge batches can realistically be tested.

So piecemeal updates to random packages pushed out at random points in time
can be tested better?

Cheers,
Debarshi


-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpH76gJyleNb.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unhelpful update descriptions

[Debarshi Ray]

 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 constantly changing pool of software
packages.  As a tester or developer you test a combination X, but you
have no way of knowing that an end-user will get the same combination
because some other packager somewhere else has pushed an update to
another package which might completely invalidate your test.

Then again different mirrors in different parts of the world can be
syncing at different rates or at different points of time. Which means
that different people are being fed randomly different sets of
packages.

How do I know that the webkitgtk3 that was pushed works with the
version of libsoup or gtk3 that is in the repository? I can't because
a new libsoup or gtk3 package might have been built while my
webkitgtk3 package was still building. Hence this combination of
libsoup, gtk3 and webkitgtk3 that we feed the user is totally untested
Rawhide quality code.

This is why we have freezes.

So that we can let things settle down. So that we are reasonably sure
that all testers and developers are testing the same set of
packages. So that we have sufficient time for testing the whole
system. So that we are sure that all users are fed the same set of
packages that we tested.

It is a bit strange that we freeze before the release, and then move
on to a Rawhide like environment where anything can be pushed by
anybody at any point in time.

We have been working around this by semi-formally co-ordinating all
GNOME updates to stable releases. Like all workarounds it is not
ideal. We still get bitten by random packager pushing random update
that broke a stable distro, or by an update to a package much lower
down the stack (say gnutls) that ended up breaking things elsewhere
(say telepathy-gabble).


Happy hacking,
Debarshi


-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpHl_HLeElQH.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unhelpful update descriptions

[Debarshi Ray]

 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. Unless...

Yes, ofcourse.

To me the idea is loosely analogous to having freezes before a release, and
there is always the possibility of freeze breaks, exceptions and what not.

 I don't know about Spot's plan you mentioned, where
 can I find information about it?

https://www.youtube.com/watch?v=xCE4dBCowRk

Cheers,
Debarshi


-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpqK6FBAxruy.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unhelpful update descriptions

[Debarshi Ray]

 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 have a guideline on the minimum amount

Or maybe the question should be: should we be pushing this many
updates for stable releases? I was running Fedora 17 on a laptop till
a couple weeks back and I kept getting nagged by PackageKit every
other evening. Atleast twice a week.

A meaningful update message makes sense if we want each user to read
them through. And if you want each user to do so, then you better
write a %changelog that is much more understandable than the upstream
ChangeLog because every random user will not be able to make sense of
the jargon. I am sure most developers won't be able to understand,
unless they are initimately familiar with the project. So you will
have to spend significant time writing the text.

I would suggest that we keep updates to a minimum, that we audit them
so that random version bumps don't get pushed to stable releases, and
we ship them in time based batches (eg., monthly or bi-monthly,
etc.). Once we do that we will be able to ensure that they are of
sufficient quality.

At that point one will not want to read the %changelog for each
package to satisfy herself of the need to update it. You get batches
of well tested updates at specified intervals of time, and you just
apply them without getting annoyed or being suspicious.

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.


Cheers,
Debarshi


-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpDG2M3g0vCO.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unhelpful update descriptions

[Debarshi Ray]

 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 attended his talk at devconf.cz where he mentioned this. :-)

I had often mentioned this in person to others, and was really glad that Spot
brought it up.

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgp9hv8jZ9UcY.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Debarshi Ray]

 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 moment for
 everyone involved (and certainly not representative of the positive energy
 that permeated other presentations).

Sounds like bitterness to me.

First we had the rabid hordes of hatred mongers running surveys, polls and
what not to support their claims of how GNOME 3 sucks and no one uses it
anymore and so on and so forth.

Now that the other side of the argument is coming to light, you are trying to
cling on to your vociferous claims at all costs.

For what it is worth, I have been using GNOME since 2004 and absolutely loved
the move to GNOME3.

Cheers,
Debarshi


-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpw1I3aTrmeb.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 treating it as freedom of choice instead of confusion.

Only if you think free software is meant only for those who spend all their
time crawling the Internet to keep track of every little drama going on in
the technology world.

If you consider that free software is meant for everybody, irrespective of
their technical abilities, then, yes, it creates too much confusion.

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpyXoNXblZQX.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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, we might break LO and that's exactly
 what I consider critical not to do. Is it doable? Are there people
 willing and able to do that? If yes, sure, let them.

It is irrelevant whether it is a daemon or a GUI application. The main
point is that you are confusing users and also developers. Why the hell
should a random user have to choose from half a dozen seemingly similar
programs when the information for making an educated choice is so hard
to obtain, if at all it can be obtained?

Whether it is editing a document or listening to audio, it is all about
using some piece of software to get something done. It is not about
spending loads of time to make the choice.

As for developers, why would they have to deal with bug reports filed
against the wrong component (AOO vs LO)?

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgp2aqAa3l5ic.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 an installer 10 years ago, I remember staring at a screen
which gave me 2 options: GNOME and KDE, and the description for both of them
were exactly the same except those 2 words.

I don't want an user staring at yum or gnome-packagekit or whatever and
seeing 2 office suites which appear to be identical except for their names,
and wondering what the hell is going on.

 The real weakness
 in Fedora is that our package manager GUI has no way for users to figure
 out which one is more popular or recommended.

And how exactly are you going to explain all the nuances of how OpenOffice
and LibreOffice are different? Don't forget the little bit about Go-oo. :-)

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpN6rhz25Mi3.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Debarshi Ray]

 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 for GDM requiring gnome-shell, I don't think it should come across as
surprising because GDM is GNOME's display manager. If you dislike GNOME so
much then get yourself a different display manager.

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpeO6FmBx7O0.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Debarshi Ray]

 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 steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpCXShvAfgaH.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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
 and nothing else, Fedora is simply not that distribution.   That is a lost
 cause and fighting against Apache Openoffice is not going to win you
 anything.  Given what we have, I think addressing the potential confusion
 by improving the GUI is the only realistic answer.

Ok.

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
 
 Go-oo is entirely irrelevant to Fedora.

No, it is not. It is an important part of where LO came from.

  I don't see any reason to drag it
 in.  Since Libreoffice will be installed by default, regular users will
 just use it.  No need to explain any nuances.

I see. So how will you empower users to make an informed decision to choose
LO over AOO or the other way around? 

And it will be the default until someone gets the bright idea of creating
an AOO spin, and that idea has already started floating around.

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgp5agW1apeJJ.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 going to resolve the problems.

But it might highlight the problem with this lets have some more choices
madness.

 If you have a proposal,
 let's hear it.  Removing all the alternatives isn't an option.  Is it?

You already heard it: don't make it worse than it already is.

 Users don't care where LO comes from at all.

Then how will you empower them to make a choice between LO and AOO? How will
you ensure that bugs don't get misfiled?

Every now and then I get bugs arising out of forks and downstream patches that
get misfiled by confused users.

Cheers,
Debarshi


-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpUeu24n3QCZ.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 difference between frowned upon and banned, right?

For starters:
https://fedorahosted.org/fesco/ticket/669

If you dig you will atleast one more.
 
 Please don't confuse the discussion concerning default choices with
 a discussion as to what is allowable to include for end-users to
 choose from.

The point was to refute the this is Fedora, so we want more choices
argument.

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpy3ByJRPSYR.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 electricity would have done it too.  -- Arjun Shankar


pgphhOGQaudSg.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 Apache Openoffice.

Because we moved away from OpenOffice.org towards LibreOffice, and then AOO
appeared on the horizon.

Epiphany or Firefox do not share such a history. For what it is worth, I would
very much like to streamline things there too, which is why I said initially:
lets not make it any worse than it already is.

(Once upon a time Epiphany had multiple backends, before it adopted WebKit as
the only one [1]. So we atleast gave up on some choice there.)

Cheers,
Debarshi

[1] https://mail.gnome.org/archives/epiphany-list/2008-April/msg0.html

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpiNYHQ9ABiP.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 faith in the way
 Fedora functions.)

Cheers,
Debarshi


-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpkXvC7ApCrL.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Debarshi Ray]

 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 be even switched without a whole lot of work as an example
 for choices.

Why not? We have ConnMan and upstart in the repos already.

The way things are going I won't be surprised if someone sincerely proposed it.
In fact a feature page was written which turned out to be a hoax.

 You just cannot support two kernels in one distribution.

Such distros do exist.

I don't think that the guiding principle should be: here is some FOSS code,
lets package it.

Cheers,
Debarshi

-- 
If computers are going to revolutionize education, then steam engines and cars
and electricity would have done it too.  -- Arjun Shankar


pgpN__9QeYnD8.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: LibRaw: possible license issues

[Debarshi Ray]

 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 GStreamer land (Totem, PiTiVi, Rhythmbox,
 Transmageddon, etc.) that I was not comfortable with having a situation
 where the application silently ends up under a different license due to
 another library.
 
 I don't think that's a problem because the whole purpose of the
 or any later version of the GPL, at your choice is to allow
 the GPL to be updated.

You don't think that it is a problem that our downstreams might inadvertently
end up violating the GPL by shipping GPLv3 code that links to non-free
software? I am not saying they are, but the chances are too high for me to
take this lightly.

Cheers,
Debarshi

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


pgpbVo91rMhrs.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: LibRaw: possible license issues

[Debarshi Ray]

 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 that won't be
the best use of our time.

I am pursuing this via other means.

Thanks,
Debarshi

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


pgplgf2tt43Kd.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

LibRaw: possible license issues

[Debarshi Ray]

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 when the two
demosaic packs were added [1]. One of the demosaic packs is GPLv2+ and the
other is GPLv3+.

However, http://www.libraw.org/ mentions LibRaw's license as GPLv2+, while the
source files continue to claim that they are under LGPLv2 or CDDL.

Shotwell, which uses LibRaw, is LGPLv2+. By my reading of the compatibility
matrix [2], it means that Shotwell is now effectively GPLv3. 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+.

Thanks,
Debarshi

[1] https://bugzilla.redhat.com/show_bug.cgi?id=760638
[2] https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


pgp0ULzwyL5CX.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: LibRaw: possible license issues

[Debarshi Ray]

 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.

GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions because
they might end up using proprietary or otherwise unfavourably licensed
GStreamer plugins .

Cheers,
Debarshi

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


pgpSJICnivgZi.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: LibRaw: possible license issues

[Debarshi Ray]

 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
 licensed GStreamer plugins .
 
 Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+.

You missed the proprietary or otherwise unfavourably licensed
part. :-) There are proprietary GStreamer plugins for patent
encumbered formats. eg., the MP3 codecs from Fluendo.

Granted that Fedora does not ship such GStreamer plugins, but some of
our downstreams do. (I don't think I am allowed to get into specifics here.)

Plus, this practice of either using LGPLv2+ or GPLv2+ with exceptions
for applications is so widespread in GStreamer land (Totem, PiTiVi,
Rhythmbox, Transmageddon, etc.) that I was not comfortable with having
a situation where the application silently ends up under a different
license due to another library.

Happy hacking,
Debarshi

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


pgpJXo6ElrKJH.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Developing for Fedora Operating System

[Debarshi Ray]

 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.

Happy hacking,
Debarshi


-- 
http://i.imgur.com/Z7jjX.jpg


pgpTb4N5yyEip.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

guile-2.x: what is the way forward

[Debarshi Ray]

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 one way forward.

What do you think? Would be good to get this resolved finally.

Thanks,
Debarshi


-- 
If you break down the amazement with some simple rules it's only
disappointment which is underneath.  -- Vivek Shah


pgpHP2Jlp7XSE.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grive open source client for google drive

[Debarshi Ray]

 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 explicitly given
permission?

 Fortunately pidgin exist and I use it =)

And how is Pidgin different in this regard?

 To give you an example of how much big pile of mess these online 
 accounts have come to be, now after my mobile phone upgrade to IOS 4.0.3 

Irrelevant. Last time I checked, we don't ship IOS.

Happy hacking,
Debarshi

-- 
KR is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar


pgpDxl6cJwq6n.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Debarshi Ray]

 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 someone has a better solution then they are
willing to hear.

Till now the only alternative people have proposed is to not support Secure
Boot, and ask users to turn it off on their systems.

Forming a working group or SIG won't automatically start generating better
ideas.

Happy hacking,
Debarshi

-- 
KR is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar


pgpe5EBpU0EWb.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Debarshi Ray]

 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 distribution with keys these systems require and not
 sharing the keys with me.  Fedora be doing this even with software
 that I wrote, enhancing it with a signing key only they have access
 too, making it much more useful on hardware where it is not otherwise,
 and not allowing me and or downstream recipients to enjoy the same
 improvements for their modified versions.
 
 What is unclear about this?

2 things:

+ Forks, respins and remixes require a level of technical expertise which
  all the consumers of the Fedora binaries might not have.

+ Running a large-scale fork, respin or remix will require money. Inability to
  pay $99 is not a very strong reason.

Free software says nothing about price. This is somewhat like the Tivoization
problem, where even though you have free software you can not modify and run
it on your computer. I used the term somewhat because Microsoft might still
sign your bootloader, or you can enroll your own key, or turn Secure Boot
off.

One of the things that you (or we) could lobby for is the possibility of a
non-Microsoft CA. However, Peter already explained one of the reasons why it
did not work out. Maybe someone can try again.

It has also been pointed out that Secure Boot does add some security, even
though the situation where Microsoft is the sole CA sucks. So, merely saying
turn it off, turn it off is not a very strong technical argument. Not that it
is a bad one, but not the best, either.

Happy hacking,
Debarshi

-- 
KR is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar


pgpuUs7oeZ8Sc.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Debarshi Ray]

 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, the religious
keep a copy.  -- Arjun Shankar


pgpXVQjmuWRcV.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Debarshi Ray]

 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, you also know that trademarks have no bearing on software freedom.
Right? ;-)

Happy hacking,
Debarshi

-- 
KR is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar


pgpXt4GEE8zCj.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Debarshi Ray]

 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 
 (freedom 3).
 http://www.gnu.org/philosophy/free-sw.en.html

No.

If anything, this is close to Tivoization, but that too not entirely:
http://en.wikipedia.org/wiki/Tivoization

Happy hacking,
Debarshi

-- 
KR is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar


pgp7ihPijjE0E.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Debarshi Ray]

 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 way, I am assuming that you know that one can't modify Firefox and
redistribute it as Firefox without certification.

Happy hacking,
Debarshi

-- 
KR is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar


pgpoWpydyfXBP.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Debarshi Ray]

 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 cases.  It's a major change to the ecosystem around Fedora.

So are you saying that Fedora Unity can not afford to pay $99? Or did I
misunderstand something?

 I'm not in a position at this point to provide a specific solution to
 this, but Windows 8 is not even out yet.  Fedora, Red Hat, and others

Unless you mention who others is/are, what you said means only Red Hat. :-)

Happy hacking,
Debarshi


-- 
KR is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar


pgphIWbmQjblI.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Building the GNOME 3.4.1 Release

[Debarshi Ray]

 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 updates which does not rely on a
proprietary web application? The workflow of a Free Software project should
not rely on proprietary software.
 
 Presumably updating that document requires a gmail account which not
 everyone wants.

What about using a page on https://fedoraproject.org/wiki/ ?

Cheers,
Debarshi

-- 
Give a man ssh access, he'll still need computer. Give him a computer, he'll
give ssh access to you.  -- Ashish Shukla


pgp82juYrfvmd.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Looking for co-maintainers for all my packages

[Debarshi Ray]

 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 use the C++ bindings from glibmm, shouldn't they?

Regards,
Debarshi

pgpkLjfQQeRPt.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning Decibel Audio Player

[Debarshi Ray]

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning some GNOME C++ packages

[Debarshi Ray]

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 bindings if someone steps
up to take care of them:
+ clutter-gktmm
+ cluttermm

Happy hacking,
Debarshi


pgpAwp7d3dP8H.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unresponsive maintainer for libical

[Debarshi Ray]

 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,
Debarshi

-- 
The camera is to the brush what Java is to assembly.
   -- Sougata Santra
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Unresponsive maintainer for libical

[Debarshi Ray]

 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


-- 
The camera is to the brush what Java is to assembly.
   -- Sougata Santra
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel