Re: DNF: "There are following alternatives to this package"

[Mathieu Bridon]

On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
> We'd like to propose a new functionality for dnf: When a user tries
> to install a package XYZ and dnf doesn't find it, dnf would recommend
> them alternative packages. These offered packages would advertise
> that they are an alternative for XYZ using a specially formatted
> Provides tag.
> 
> For example, packages `python2-requests` and `python3-requests`
> would both have the following tag:
> 
>  Provides: alternative-for(python-requests) = %{version}-
> %{release}
> 
> (Possibly via the already existing and widespread %python_provide
> macro in the Python case.)
> 
> And when the user would try to install `python-requests`, dnf would
> look for packages with the relevant Provides tag and display them:
> 
>  # dnf install python-requests
>* There are following alternatives to this package: 
> python2-requests python3-requests
>  No match for argument: python-requests
>  Error: Unable to find a match
> 
> This would be very similar to an already existing functionality that 
> searches for lowercase package names:
> 
>  # dnf install python3-REQUESTS
>* Maybe you meant: python3-requests
>  No match for argument: python3-REQUESTS
>  Error: Unable to find a match
> 
> (That functionality is broken in some versions—RHBZ#1628514—so you
> might not see this result at the moment.)
> 
> What are your thoughts?

It's neat, but it doesn't help catch typos, which seems like the most
probably case where I'd want such a feature.

How about instead of a scheme based on provides, just quickly check if
a package has a "similar" name?

Basically extend the existing check for lowercase you mention.

  $ git stats
  git: 'stats' is not a git command. See 'git --help'.
  
  The most similar command is
  status


-- 
Mathieu
___
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: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

[Mathieu Bridon]

Hi,

On Tue, 2018-07-10 at 12:14 +0200, Vít Ondruch wrote:
> One question though. I see that this works in Koji, but trying to
> test this locally it does not work.
> 1) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
> --enablerepo=local
> This still installs gcc.
> 2) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
> --disablerepo=* --enablerepo=local
> This fails:
> ~~~
> Warning: Module or Group 'buildsys-build' does not exist.
> Error: Nothing to do.
> ~~~
> Trying to get the latest comps from local repository:
> ~~~
> https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/repoda
> ta/db824c6dd6664943bcec0a8fcd3bda7fc855e5a787623c0da6d49deb79438fc7-
> comps.xml
> ~~~
> This has "build" group which references gcc/gcc-c++ and does not
> reference any buildsys-build group. So where is this file coming
> from? Why does it differ from regular Fedora repos?

The groups in Koji are defined differently from the groups in the
Fedora repos.

In the repos, you can find them defined in the comps.xml file, for
example:

http://dl.fedoraproject.org/pub/fedora/linux/releases/28/Everything/x86
_64/os/repodata/b140b2b55e06b7ba6c765d27dd9dbae905745e788a97a390be8b829
80b8c282e-comps-Everything.x86_64.xml

This contains a `buildsys-build` group, which mock installs when
creating a chroot.

In Koji, the groups can be seen with the command:

$ koji list-groups f29-build
[… snip …]
build  [f29]
  bash: None, mandatory  [f29]
  bzip2: None, mandatory  [f29]
  coreutils: None, mandatory  [f29]
  cpio: None, mandatory  [f29]
  diffutils: None, mandatory  [f29]
  fedora-release: None, mandatory  [f29]
  findutils: None, mandatory  [f29]
  gawk: None, mandatory  [f29]
  grep: None, mandatory  [f29]
  gzip: None, mandatory  [f29]
  info: None, mandatory  [f29]
  make: None, mandatory  [f29]
  patch: None, mandatory  [f29]
  redhat-rpm-config: None, mandatory  [f29]
  rpm-build: None, mandatory  [f29]
  sed: None, mandatory  [f29]
  shadow-utils: None, mandatory  [f29]
  tar: None, mandatory  [f29]
  unzip: None, mandatory  [f29]
  util-linux: None, mandatory  [f29]
  which: None, mandatory  [f29]
  xz: None, mandatory  [f29]
[… snip …]
srpm-build  [f29]
  bash: None, mandatory  [f29]
  fedora-release: None, mandatory  [f29]
  fedpkg-minimal: None, mandatory  [f29]
  gnupg2: None, mandatory  [f29]
  redhat-rpm-config: None, mandatory  [f29]
  rpm-build: None, mandatory  [f29]
  shadow-utils: None, mandatory  [f29]

The `srpm-build` group is what gets installed in the chroot to build
the SRPM (see the buildSRPMFromSCM subtask in any build task) and the
`build` group is what gets installed when building binary RPMs (see the
buildArch subtasks in any build task).

I do not know **why** we have this difference between Koji and the main
repos, I just know that we do have it.

This change needs to be reflected in Comps, so that Mock installs the
same thing in its buildroots as Koji.


-- 
Mathieu
___
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/TB4YLBIHDCNORB4MHSAUVT2HXXN4MNAQ/

Re: How should I coordinate the package updates with you guys?

[Mathieu Bridon]

On Fri, 2018-04-13 at 15:41 -0500, po...@pouar.net wrote:
> Not sure how to interpret the example email `packagename-owner@alias`
> . Would that be like `brotli-po...@fedoraproject.org` or
> `po...@fedoraproject.org` or something else? Is `fedoraproject.org`
> the right domain for `alias`?

It's ${srpmname}-ow...@fedoraproject.org, so in your case:

brotli-ow...@fedoraproject.org


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

Re: Gating packages in Rawhide

[Mathieu Bridon]

On Fri, 2018-03-09 at 10:38 +0100, Pierre-Yves Chibon wrote:
> On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote:
> > We could take a hint from how we make software upstream these days:
> > 
> > 1. submit a pull request for the package in src.fp.o on the master
> >branch
> > 2. a CI automatically builds this package in Koji
> > 3. merge the pull request into master
> > 4. the build (from step 2) is tagged for Rawhide, without a rebuild
> > 
> > Gating is achieved by preventing merges if the build/tests fail.
> 
> This has been discussed but requires a way for koji to "promote"
> scratch builds
> to real builds and this isn't a small task.
> Long term, I do think this is a good idea anyway yes.

It doesn't have to be scratch builds, it could be real builds in a side
tag.


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

Re: Gating packages in Rawhide

[Mathieu Bridon]

On Fri, 2018-03-09 at 10:06 +0100, Pierre-Yves Chibon wrote:
> On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote:
> > On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> > > Randy Barlow wrote:
> > > > It may be possible to automate the process a bit to make it
> > > > less heavy
> > > > for developers, though there is some complication for multi-
> > > > package
> > > > updates
> > > 
> > > Some automation would help, sure. But if we are going to do
> > > things 
> > > automatically, why bother with Bodhi at all?
> > 
> > Well, we don't currently have another tool to show results and
> > allow
> > waving of them. We could come up with another app and have yet a
> > different place and workflow from regular releases, but why not
> > stick to
> > the same workflow and avoid making yet another app.
> > > 
> > > We are already building into a pending tag for the autosigning,
> > > from which 
> > > the packages are moved into the final tag when they are signed.
> > > The same 
> > > process should work for autotesting. Just add it before or after
> > > the 
> > > autosigning in the pipeline, possibly with another intermediate
> > > tag.
> > > 
> > > I think that Bodhi is really the wrong tool for the job here.
> > > What you are 
> > > trying to hit with your shiny hammer may look like a nail to you,
> > > but it is 
> > > really a screw. ;-)
> > 
> > I don't think thats the case here, it's more than we don't want to
> > build
> > another different tool for something that could work with the
> > hammer we
> > have.
> > 
> > To be fair, there was a suggestion that we show results in
> > pagure/src.fedoraproject.org, but to me, that definitely sounds
> > like the
> > wrong place for such things. We want tests tied to a specific
> > update,
> > not the entire package as a whole. (Even thought we could fudge
> > this by
> > having git tags or something to tie results to).
> 
> For regular Fedora releases I definitely agree with you, but for
> rawhide where
> the only time we bundle package together would be via side-tags, I
> think
> reporting test results to src.fp.o would be a valid approach.

We could take a hint from how we make software upstream these days:

1. submit a pull request for the package in src.fp.o on the master
   branch
2. a CI automatically builds this package in Koji
3. merge the pull request into master
4. the build (from step 2) is tagged for Rawhide, without a rebuild

Gating is achieved by preventing merges if the build/tests fail.


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

Re: Wyland is a disaster

[Mathieu Bridon]

On Tue, 2018-02-06 at 08:53 -0800, Howard Howell wrote:
> On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote:
> > On 02/05/2018 01:35 PM, Howard Howell wrote:
> > > My eyes hurt
> > > after a few hours trying to find the smaller and darker default
> > > cursors.
> > 
> > Do you know that you can simply increase the size of the cursors?
> > 
> > dconf write /org/gnome/desktop/interface/cursor-size 48
> > 
> > I swear I saw it in one of GNOME GUI tools but I can't find it now 
> > (doesn't seem to be in Settings or Gnome-tweaks)
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> You are on my hero's list.  Somebody figure out how to make this part
> of gnome-tweak-tool, PLEASE, or on the accessibility menu.

In GNOME Settings 3.26.2, go to "Universal Access" then change the
"Cursor Size" option.


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

Re: What to I have to do....

[Mathieu Bridon]

On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
> On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
> > You're blowing this way out of proportion, as if this was a
> > catastrophe. History shows that it isn't.
> 
> Maybe I am... Would not be the first time! ;-)
> 
> In last couple of months there were a couple of changes
> that were non-critical so I'm getting the feeling
> people are getting a bit embolden... which is worrisome.
> 
> Then on the other hand I get these pull-requests that
> work so well! 
> 
> So I just don't understand why for non-massive changes
> why is it not required to go through the pull-request
> process?

This wasn't a trivial change.

It certainly was trivial for each package it got applied to, but it got
applied to quite a few packages.

That's essentially a similar change to mass-rebuilds, just at a smaller
scale.

It was also announced properly on this list, enough time in advance, so
it shouldn't have taken you by surprise.

If you really want to insist on the maintainers's responsibilities,
start by reading announcements on this list.


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

Re: What to I have to do....

[Mathieu Bridon]

On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
> 
> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Well, I'd say this works great. There's maybe a hundred or two
> > hundred proven packagers and somehow none of them decide to mess up
> > the kernel any day. In fact, the commits which caused this thread
> > are _correct_:
> > so far I haven't heard one word to the contrary. I don't see any
> > point in discussing hypotheticals.
> 
> You are telling me there hundreds of people that have complete
> control over all the packages in fedora with no boundaries???
> They can do anything they what??? Wow...

And it's working just fine, because overall people understand their
responsibilities and don't abuse their powers.

If someone ever does go too far, their probvenpackagers permissions can
be revoked and the bad changes they made can be reverted.

You're blowing this way out of proportion, as if this was a
catastrophe. History shows that it isn't.


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

Re: Call for testing - Firefox CSD/titlebar

[Mathieu Bridon]

On Fri, 2017-09-15 at 18:03 +0200, Vít Ondruch wrote:
> * Why are there the minimize/maximize buttons? They should not be
> there in Gnome.

I filed this one this morning:

https://bugzilla.redhat.com/show_bug.cgi?id=1491981


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

Re: RFC: retiring yum

[Mathieu Bridon]

On Fri, 2017-09-01 at 15:00 -0500, Ian Pilcher wrote:
> On 09/01/2017 02:21 PM, Igor Gnatenko wrote:
> > This is true and we have plans to implement this, but problem is
> > that
> > we don't know how to represent data. When it is about installing
> > some
> > packages -- it's more or less easy to show, but when upgrades /
> > downgrades are involved it becomes way more complicated.
> > 
> > If you have some actual suggestions -- feel free to contact me off
> > list
> > or post them here. ☺
> 
> I won't claim to be a huge fan of the way that yum insisted on
> spewing detailed dependency information, but it did provide the
> information require to answer those "Why does Inkscape require
> mdadm?" type questions.

The old repoquery had a --tree-requires option which was really great
for this.

(along with a few other --tree-* options)


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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Mathieu Bridon]

On Mon, 2017-07-31 at 22:51 -0400, Randy Barlow wrote:
> On Mon, 2017-07-31 at 22:13 -0400, Ben Rosser wrote:
> > 2. If we do implement this, could we consider not batching new
> > package
> > updates in addition to security and "urgent" updates? New package
> > updates wouldn't get downloaded onto users systems upon running
> > "dnf
> > upgrade", so the update process would still *feel* batched from an
> > end-user point of view. But we would simultaneously be able to
> > deliver
> > new software quickly to users, or at least as quickly as we do
> > today.
> > (I find that people rarely test new package updates, or at least
> > rarely test them and give karma, which means that a newpackage
> > request
> > generally sits the full 7 or 14 days in bodhi-- so I don't think we
> > should add up to 7 days to that timetable).
> 
> That's a good suggestion that I hadn't though about. Sure, I think
> that's a good idea - care to propose it on the pull request yourself
> since it was your idea? This is the line where an "or self.type is
> newpackage" would go:
> 
> https://github.com/fedora-infra/bodhi/pull/1678/files#diff-6406e7faaf
> 25263056c68009517cf66dR2376

If a new package needs an updated library from another package, then
the update in Bodhi would contain both a new package and an update.

Should that still go directly to request:stable? Or does the (non-
urgent) update make it go to request:batched?


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

Re: Finalizing Fedora's Switch to Python 3

[Mathieu Bridon]

On Mon, 2017-07-31 at 00:02 +1000, Nick Coghlan wrote:
> On 30 July 2017 at 07:57, Björn Persson <Bjorn@rombobjörn.se> wrote:
> > Mathieu Bridon <boche...@daitauha.fr> wrote:
> > > To be honest, given how much energy is spent on this migration
> > > for a very low gain, it makes me feel like having an unversioned
> > > "python" (whether as package or executable names) was a mistake
> > > we should let disappear with Python 2.
> > 
> > I agree.
> > 
> > From an emotional point of view I fully understand the Python
> > folks' desire to have "Python" mean Python 3, and that's fine in
> > marketing contexts such as websites.
> 
> While I'm a CPython core dev in addition to being a RHEL developer,
> it's mainly the latter role that leads me to consider the status quo
> in Fedora as being rather problematic :)
> 
> > But filenames and package names are technical
> > identifiers. They must be chosen so that they'll fulfil their
> > functions, and with consideration for forward and backward
> > compatibility.
> 
> Right. Unfortunately, the folks saying "just use /usr/bin/python3 in
> your shebang lines" are choosing to ignore systems that don't have,
> and *aren't going to get* a Python 3 installation. Even if Red Hat
> were to start making a native Python 3 stack available, there would
> still be an awful lot of EL6 and EL7 systems around where that stack
> isn't going to be installed.

Sure, but nobody is telling everybody to use /usr/bin/python3 in their
shebang line.

I started this subthread saying everybody should just use the versioned
executable in their shebang line. Whether that's Python 2 or 3 depends
on what's available on their system and what they are targetting.

> So that's effectively a hard design constraint for me: folks
> targeting EL6 and EL7 *are* going to have to use "/usr/bin/python" in
> their shebang lines (since they can't even assume "/usr/bin/python2"
> will be present,

Wait, what?

I see /usr/bin/python2 in the EL7 spec file:

https://git.centos.org/blob/rpms!python.git/c7/SPECS!python.spec#L2041

I'm pretty sure I had /usr/bin/python2 back in the days when I was
using EL6. (but I have no way to check that now)

> let alone "/usr/bin/python3"), so I have to assume that "just tell
> Red Hat's customers to change all their Python shebang lines to
> require Python 3" isn't one of the design options I have available to
> me.

And again, nobody in this subthread suggested moving things to Python
3.

> That means the only degrees of freedom I/we potentially have are
> related to what "/usr/bin/python" means in Fedora. The status quo is
> that by default such scripts simply break, and if you want them to
> work, you have to install the full Python 2.7 stack.

Which, again, is what happens for other shebang lines like /usr/bin/zsh
or /usr/bin/ruby.

Having to install the stack needed by your custom-built tools seem like
a perfectly normal thing to me.

> If you want to do anything else, you have to resort to creating
> symlinks manually, and as soon as you do, your system is in an
> unsupported configuration, so if it breaks, any bugs you file are
> just going to be closed as "not a bug".
> 
> Accordingly, my proposal is that we support *3* admin selectable
> configurations

That seems like a recipe for confusion. How does one know what
/usr/bin/python actually is if it can change from one machine to
another?

> > Providing an unversioned "python" serves only to lure incautious
> > programmers into using it where they should use a versioned name.
> 
> My aim is for folks to start thinking of a "/usr/bin/python" shebang
> as being akin to writing "/bin/sh" instead of "/bin/bash": as the
> author of the script, by deciding not to explicitly qualify your
> shebang line you're saying "I'm not writing in either Python 2 *or*
> Python 3, I'm writing in the hybrid subset of both of them". There
> aren't many good reasons for a script in a distro package to do that
> (they should just depend on the stack they want), but there are
> plenty of good reasons for multi-distro scripts to be written that
> way.
> 
> As time goes by, I'd expect the meaning of the unqualified variant to
> shift slightly such that "/usr/bin/python" is taken to mean "written
> in the oldest Python dialect that is still actively supported by
> upstream and/or commercial vendors (or potentially even older than
> that)" while "/usr/bin/python3" retains its current meaning of "run
> in the default Python 3 stack" (with the two links thus becoming
> functionally equivalent for sy

Re: Finalizing Fedora's Switch to Python 3

[Mathieu Bridon]

On Fri, 2017-07-28 at 21:06 +0200, Till Maas wrote:
> On Fri, Jul 28, 2017 at 10:29:12PM +1000, Nick Coghlan wrote:
> 
> > It's only /usr/bin/python itself that still presents an unsolved
> > problem, since the status quo (not providing it at all) is even
> > more user hostile than pointing it at a modern version of Python 3
> > that
> 
> Why is not providing /usr/bin/python more use hostile? Why is it
> better for any script to use /usr/bin/python instead of
> /usr/bin/python3?

Exactly.

By default, any script using `#!/usr/bin/zsh` won't work on Fedora,
until the admin installs zsh.

We could very well consider that /usr/bin/python remains python2, and
not have it installed by default.

To be honest, given how much energy is spent on this migration for a
very low gain, it makes me feel like having an unversioned "python"
(whether as package or executable names) was a mistake we should let
disappear with Python 2.

If everything is a versioned pythonX in the future, moving to a
hypothetical Python 4 would only imply building new python4-* packages
and changing the (Build)Requires, no gymnastic with unversioned things.


-- 
Mathieu
___
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

[Mathieu Bridon]

On Tue, 2017-07-18 at 15:06 +0100, Tom Hughes wrote:
> Nobody wants to have to resetup their desktop every day

I do.

I actually turn off my computer when I'm not using it, and start it
again in the morning before I start working.


-- 
Mathieu
___
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

[Mathieu Bridon]

On Tue, 2017-07-18 at 13:23 +0200, Dominik 'Rathann' Mierzejewski
wrote:
> By the way, I can't figure out how to look inside a Flatpak and
> review its contents. Could someone provide some pointers?

On the repo all you have is an object store (much like Git's
.git/objects/ folder), but if you install the app you will also get a
checkout:

  $ ls ~/.local/share/flatpak/app/org.gnome.Calendar/current/active/files/
  bin  lib  manifest.json  share

(that's because I installed the app with --user, if you install it
system-wide then it's under /var/lib/flatpak/app/...)

The manifest.json file is a recipe for how the app was built (like a
spec file), which helps reproducing builds.

The contents of that files/ directory are what gets mounted as /app/ in
the sandbox.


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

Re: Xulrunner - intent to remove from Fedora 24

[Mathieu Bridon]

On Tue, 2017-06-27 at 10:23 +0100, Tom Hughes wrote:
> On 27/06/17 10:11, Dominik 'Rathann' Mierzejewski wrote:
> > On Tuesday, 27 June 2017 at 06:40, Truong Anh Tuan wrote:
> > > I have just got updates from upstream developers. A new version
> > > of pencil has been released [1]. I uses Electron, instead of
> > > XULrunner.
> > > 
> > > I am planning to update the package to keep pencil on the next
> > > Fedora releases. However, as I have checked on the wiki, Electron
> > > package [2] has not been officially put into Fedora repo.
> > > What should I do now? Any suggestions?
> > 
> > You can ask Brenton to submit the electron package for review and
> > maintain it in Fedora or you can do it yourself.
> 
> I'm guessing you haven't seen the dependency tree for electron if
> you think it's that easy ;-)
> 
> To be honest I'm struggling to even make sense of what exactly 
> constitutes "electron" as such because the npm module of that name 
> appears to basically be an installer for a prebuilt node and chrome!
> 
> I believe that behind that there are then a zillion other electron-*
> npm modules no doubt each with their own crazy dependency hell.

And it is likely each app will require different versions of all those
modules, those versions being incompatible with each others.

At that point, bundling with something like Flatpak becomes more
interesting than packaging all those separately.


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

Re: F25 Self Contained Change: IBus Emoji Typing

[Mathieu Bridon]

On Tue, 2017-05-09 at 17:17 +0900, Takao Fujiwara wrote:
> As I explained in Fedora 25, now the emoji typing is available in
> IBus panel menu.
> ibus-1.5.15-8.fc26 is now available in koji or copr.
> I moved the emoji function in IBusEngineSimple to a panel component.
> The UI is designed to work as an extended IBus lookup window which
> can commit an emoji without mouse using Space, Enter and Arrow keys
> and expected to be useful for both CLI and GUI users.
> The shortcut key Ctrl-Shift-e is customizable with ibus-setup
> utility.
> If this is comfortable for you, I'd like to implement the similar UI
> for gnome-shell.

Ctrl+shift+e might already be used in applications. (for example in
Gimp it fits the image to the window, in the Firefox Tab Groups
extension itopens the group management page, etc...)

I think for GNOME Shell the shortcuts are usually with the super key,
(e.g super+space to switch input sources), to avoid clashing with
application shortcuts.


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

Re: Emails about new packages

[Mathieu Bridon]

On Thu, 2017-02-16 at 22:48 +, Jeremy Cline wrote:
> On 02/16/2017 09:47 PM, Steve Grubb wrote:
> > The 3.2.1 version is in koji, why was this email sent to bother me?
> > At some time in the past, I tracked it down and found a way to
> > "turn this off". But guess what? Now I get 2 emails. The first is
> > above, and the second one is this:
> > 
> > the-new-hotness saw an update for suricata, but pkgdb says the
> > maintainers are not interested in bugs being filed
> > https://release-monitoring.org/project/10925/
> > 
> > Why? This is really passive aggressive. How do I unsubscribe from
> > this unwanted release monitoring service?
> 
> the-new-hotness subscribes to the messages published by
> release-monitoring.org and files a Bugzilla bug on the package. Many
> packagers find this helpful, but (as you've found) it's possible to
> turn off. If you do this, the-new-hotness publishes a message saying
> it saw the message from release-monitoring.org, but isn't acting on
> it.
> 
> Fedora has a notification system that also subscribes to all these
> messages and sends emails or irc messages to you when certain
> messages are received.

That's not helpful, though.

The email basically says "Something happened, but you asked not to be
notified about it, so don't worry I won't tell you".

Why even send that email in the first place?

Anyone who opted out of the release monitoring notifications (note: I
didn't opt out, I actually find it great) doesn't want any
notification, let alone one that says "I won't notify you".

The default setting for notifications really ought to be changed here.


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

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Mathieu Bridon]

On Tue, 2017-02-07 at 08:40 -0600, Chris Adams wrote:
> However, this is another case where sudo having a different PATH than
> the normal shell comes into play as an irritant... installing modules
> (or gems, etc.) that include executables puts them in /usr/local/bin,
> which works from the shell but not sudo.

Unfortunately:

https://bugzilla.redhat.com/show_bug.cgi?id=1166185
https://pagure.io/fesco/issue/1646


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

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Mathieu Bridon]

On Tue, 2017-02-07 at 13:08 +0100, Vít Ondruch wrote:
> Dne 7.2.2017 v 11:32 Michal Cyprian napsal(a):
> > Ruby on Fedora uses /usr/local/share/gems/ for packages installed
> > as a root via gem tool for many years.
> 
> Since you refer to Ruby, I just want to highlight that
> /usr/local/share/gems/ is for packages installed by *root* via gem
> too (as you correctly said) [1]. We assume that root manages the
> entire system and wants installed packages to be available system
> wide. I don't expect this is widely used practice. Typical user
> installed packages goes into $HOME/.gem. Is there any location
> similar to this?

Yes, under ~/.local/lib/

It's what you get with `pip install --user $module`.

> As far as I know, our users very appreciate the possibility to do
> "gem install" without administrator privileges.

So do Python developers. It's very commonly used.

But even more common is to use virtual environments, one per
application.

---

I strongly feel this feature is a move in the wrong direction. I've
never met a Python developer (and I'm one myself) installing modules
system-wide with Pip. It seems to me the only people doing that are
people who follow bad documentations.

IMHO a much better (and simpler) way to fix the (very real) issue of
unsuspecting users damaging their systems would be for pip to refuse to
run with root permissions.


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

Re: ImportError: No module named kivy, when run make html

[Mathieu Bridon]

On Sun, 2017-01-29 at 09:51 +, Martin Gansser wrote:
> thanks for your answer.
> 
> my question is, should i build for both python version the html files
> ?
> cd doc && make html PYTHONPATH=../build/lib.linux-%{_arch}-
> %{python2_version}
> cd ..
> cd doc && make html PYTHONPATH=../build/lib.linux-%{_arch}-
> %{python3_version}

Up to you.

Is the documentation going to be different between the python2-kivy and
python3-kivy package?

If yes, then having both python2-kivy-doc and python3-kivy-doc makes
sense.

Otherwise, just build it once as python-kivy-doc (bonus points if you
make it noarch) with whichever version of Python (although python3
being the default now, that's probably the one to use).

There's no need to do more work than necessary.


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

Re: ImportError: No module named kivy, when run make html

[Mathieu Bridon]

On Sat, 2017-01-28 at 18:40 +, Martin Gansser wrote:
> thanks for your feedback, i run this from the doc dir of python-kivi
> 
> [martin@fc25 doc]$ PYTHONPATH=.. python autobuild.py silenced=yes
> [INFO   ] [Logger  ] Record log in
> /home/martin/.kivy/logs/kivy_17-01-28_5.txt
> [INFO   ] [Kivy] v1.9.1
> [INFO   ] [Python  ] v2.7.13 (default, Jan 12 2017, 17:59:37) 
> [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)]
>  Traceback (most recent call last):
>    File "autobuild.py", line 25, in 
>  import kivy.app
>    File "/home/martin/rpmbuild/BUILD/kivy-1.9.1/kivy/app.py", line
> 319, in 
>  from kivy.base import runTouchApp, stopTouchApp
>    File "/home/martin/rpmbuild/BUILD/kivy-1.9.1/kivy/base.py", line
> 30, in 
>  from kivy.event import EventDispatcher
>    File "/home/martin/rpmbuild/BUILD/kivy-1.9.1/kivy/event.py", line
> 8, in 
>  import kivy._event
>  ImportError: No module named _event

kivi._event needs to be built with Cython, which means you need to
build the module before building the doc.

If you look at the Makefile at the root of the sources, it uses the
following to build the module:

python setup.py build_ext --inplace

This makes the built files go into the kivi/ folder, instead of the
build/ folder. That's what makes the module available for the docs to
build correctly.

But you probably don't want to build with --inplace, so use this to
build the docs:

cd doc && make html PYTHONPATH=../build/lib.linux-x86_64-2.7

You'll need to adapt the architecture and Python version of course.


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

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Mathieu Bridon]

On Fri, 2017-01-20 at 09:12 -0800, Adam Williamson wrote:
> On Fri, 2017-01-20 at 12:07 +0100, Jan Kurik wrote:
> > = Proposed Self Contained Change: Making sudo pip Safe (Again) =
> > https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
> > 
> > Change owner(s):
> > * Michal Cyprian 
> > * Petr Viktorin 
> > * Tomas Orsava 
> > * Miro Hroncok 
> > 
> > 
> > At the present time, running sudo pip3 in Fedora is not safe. Pip
> > shares its installation directory with dnf, can remove dnf-managed
> > files and generally break the Python 3 interpreter. We propose a
> > series of measures that will make it safe to use.
> > 
> > 
> > == Detailed Description ==
> > The danger of using sudo pip3 stems from the fact that both Python
> > dnf packages and sudo pip3 install modules to the same location,
> > namely /usr/lib/pythonX.Y/site-packages.
> > 
> > We aim to move the working directory for sudo pip3 to a more
> > appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
> > modify the Python 3 interpreter in Fedora to scan both above
> > mentioned locations when importing modules.
> 
> This might also mean that we start using Python modules installed
> from self-compiled applications, which might not be intended (we do
> not include /usr/local/lib(64) in the default ldconfig path, AFAIK).

In addition to that, if someone compiles and installs their own Python,
it goes into /usr/local by default. (with the typical ./configure &&
make && make install)

Which means that its modules would go into
/usr/local/lib/pythonX.Y/site-packages.

The suggested change means that the system Python would use the modules
intended for that local Python. (if they are the same version)


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

Re: New sources format

[Mathieu Bridon]

On Tue, 2016-12-20 at 23:30 +, Pádraig Brady wrote:
> On 20/12/16 22:28, Christopher wrote:
> > 
> > What's with the new sources format?
> > The old format, I could do `md5sum -c sources`
> > Why not make the new format with SHA512 follow the same pattern, so
> > I could do: `shasum -c sources` or `sha512sum -c sources`?
> > 
> > Is there any standard command-line tool to parse this new format,
> > or do I just gotta grep/awk/bash my way through it?
> 
> As far as I can see it's using the BSD tagged format,

It is.

This is a decision we made when moving to sha512, because we wanted the
file to contain the used hash function. (for the future, when we
invariably move again to a new hash function)

We were starting to talk about our own format, then someone (I think it
might have been Peter?) told me about the BSD tagged format, and we
just went with that.

> which the coreutils sha512sum command can parse.
> I.E. the following format is supported since v8.20 (2012-10-23)
> 
>   SHA512 (filename) = ...

Not only can it parse it, it can also generate it:

    $ sha512sum --tag some-file
    SHA512 (some-file) = ...


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

Re: F24 GStreamer zero day

[Mathieu Bridon]

On Thu, 2016-11-24 at 12:09 -0500, Matthew Miller wrote:
> On Thu, Nov 24, 2016 at 11:02:19AM -, Carlos Garnacho wrote:
> > > Question which directories does tracker actually scan / monitor
> > > by default ?
> > 
> > XDG folders recursively, $HOME non-recursively. This is all
> > configurable in the privacy pane in the control-center fwiw.
> 
> It doesn't seem to be -- I see Screen Lock, Location Services, Usage
> & History, Purge Trash, and Problem Reporting. I have to to install
> tracker-preferences to get a GUI for these settings, as far as I can
> see.

It's configurable in the Search panel of the control center.

(the gear icon in the bottom right)


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

Re: upcoming build and release developer flag day December 12 2016

[Mathieu Bridon]

On Sun, 2016-11-20 at 11:14 -0700, Kevin Fenzi wrote:
> On Sun, 20 Nov 2016 11:43:55 +0100
> Mathieu Bridon <boche...@daitauha.fr> wrote:
> > On Sat, 2016-11-19 at 19:11 -0600, Dennis Gilmore wrote:
> > > We are wanting to write to you all about an important date coming
> > > up. On the 12th of December 2016 we will be making some important
> > > changes that will require changes on every developers machine. In
> > > this case developers means every one that interacts with koji
> > > using authentication
> > > 
> > > lookaside cache checksum hash. currently packages are stored in
> > > lookaside cache using md5sum we will be switching to sha256sum.  
> > 
> > I thought the plan was sha512, did that change?
> 
> I thought we ended up on sha256, but it's been so long since this
> work was ready to go, I admit I don't recall. ;) sha512 is fine with
> me too. 

Last time I worked on this we were still talking about sha512, but it's
possible you (the releng team) changed your mind since it's been a long
time indeed and I haven't followed up since.

Note that the server code expects sha512, not sha256:

https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/di
stgit/files/dist-git-upload.cgi#n120

So some more code would need changed to move to sha256, but I'm not
sure it's worth the effort.


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

Re: upcoming build and release developer flag day December 12 2016

[Mathieu Bridon]

Hi,

On Sat, 2016-11-19 at 19:11 -0600, Dennis Gilmore wrote:
> We are wanting to write to you all about an important date coming up.
> On the 12th of December 2016 we will be making some important changes
> that will require changes on every developers machine. In this case
> developers means every one that interacts with koji using
> authentication
> 
> lookaside cache checksum hash. currently packages are stored in
> lookaside cache using md5sum we will be switching to sha256sum.

I thought the plan was sha512, did that change?


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

Re: sudo not looking into /usr/local

[Mathieu Bridon]

On Wed, 2016-11-16 at 14:19 +, Samuel Rakitničan wrote:
> > Am 16.11.2016 08:08, schrieb Samuel Rakitničan:
> > 
> > You can change the default behaviour in "/etc/sudoers" or (better)
> > by adding a file in "/etc/sudoers.d".
> > 
> > If you want to keep the users path, add:
> > 
> > Defaults env_keep += "PATH"
> > Defaults !secure_path
> > 
> > or to change the (default) secure path, just add
> > 
> > Defaults secure_path = /your/path/here:/as/usual
> 
> File in /etc/sudoers.d is neat, thanks. But I am hoping we can came
> up with a new default setting or is there a reason not to include
> anything else?
> 
> I was thinking about it some more, and I think this setting does more
> harm then good. It limits what users can do but it doesn't stop them
> to bypass it with a simple alias sudo="sudo PATH=$PATH". So in my
> opinion the original "If you don't trust the people running sudo to
> have a sane PATH environment variable you may want to use this." kind
> of defeats its purpose.

Note that there's been a ticket in Bugzilla requesting this for two
years:

    https://bugzilla.redhat.com/show_bug.cgi?id=1166185


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

Re: GitPython update blocked by rpkg - how can this be resolved?

[Mathieu Bridon]

On Tue, 2016-11-15 at 16:05 +, Barry wrote:
> I was hoping to find out if there is in fact a patch to rpkg is
> required.

Try, and you'll see?


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

Re: Why GUI software update tool is broken for me

[Mathieu Bridon]

On Thu, 2016-06-16 at 14:44 +, John Florian wrote:
> > From: Jonathan Wakely [mailto:jwak...@fedoraproject.org]
> > PackageKit and DNF use separate caches, which are not updated at
> > the same time. Try "pkcon refresh" first to update its cache.
> 
> Ok, I tried that but it made no difference.

Try: pkcon refresh force

>   Does pkcon use /etc/yum.repos.d/?

Yes.


-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Mathieu Bridon]

On Thu, 2016-05-12 at 20:54 +1000, Dan Callaghan wrote:
> Excerpts from Tom Hughes's message of 2016-05-12 09:15 +01:00:
> > 
> > On 12/05/16 09:07, Tomasz Torcz wrote:
> > > 
> > >    Shouldn't that be /usr/lib/distro.repos.d (for 
> > >    distribution-provided
> > > data) with usual rules for overriding/masking in
> > > /etc/distro.repos.d (for
> > > local administrator)?
> > Well equally isn't the "distro." prefix all wrong if it includes
> > things other than distribution provided repositories...
> Agreed... if end users and third-party repos are expected to also put
> their configs into this directory, then having "distro" in the name 
> doesn't really make sense.
> 
> If the objection to yum.repos.d is that they are not just "yum repos"
> anymore, since clients other than yum can consume them -- then maybe
> we can think of them as "yum-formatted package repos" (that is, 
> "repositories of RPM packages with metadata in the format originated
> by yum").

Agreed.

This change seems like a lot of churn (having to preserve
compatibility, having to change yum, creating tons out of date
documentation, ...) for too little actual benefit.

The "Benefit to Fedora" section just isn't convincing:

> The former default directory path implies that the repositories are
> consumable by Yum only, which is not true. This general path name
> would help us define repository configuration path that would not be
> bound to a specific package manager name and so be more portable
> among package managers. 


-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Checking signatures on package source tarballs

[Mathieu Bridon]

On Tue, 2016-03-22 at 09:12 -0400, Josh Boyer wrote:
> On Tue, Mar 22, 2016 at 9:02 AM, David Woodhouse  > wrote:
> > 
> > The original draft does raise an interesting question — do we need
> > to put the upstream PGP key directly into the package git tree
> > instead of the lookaside cache?
> > 
> > I suppose while the lookaside cache is still only using MD5(!) to
> > validate what it downloads, the answer to that is an unequivocal
> > 'yes'.
> As an aside, I think Till has code written to make the lookaside use
> sha256.  I'm not sure what the next steps are to get that rolled out
> though.

Code-wise, everything is ready, both on the server-side and on the
client-side.

The only thing needed now is to flip the switch from md5 to sha512.

But doing so would mandate an upgrade for every packager, since
enforcing sha512 means older fedpkg versions still using md5 would get
their uploads refused.

As a result, the Releng team collectively decided to hold off the move,
and bundle it with other similarly breaking changes (new Koji
certificates, for example)

All the details are here:

    https://fedorahosted.org/rel-eng/ticket/5846


-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Mathieu Bridon]

On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
> Part of the change is defining the exact subset. The idea is that it
> should be small, to keep cloud images small for apps that don't use
> Python themselves.

Wouldn't it be a better goal to not have Python at all on Cloud images?


-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Mathieu Bridon]

On Mon, 2016-02-08 at 12:47 -0500, Stephen Gallagher wrote:
> On 02/08/2016 12:45 PM, Mathieu Bridon wrote:
> > On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
> > > Part of the change is defining the exact subset. The idea is that
> > > it 
> > > should be small, to keep cloud images small for apps that don't
> > > use 
> > > Python themselves.
> > 
> > Wouldn't it be a better goal to not have Python at all on Cloud
> > images?
> > 
> 
> So... no dnf? That seems a little unlikely to yield a good long-term
> result.

Or maybe dnf shouldn't be written in Python?

I mean, if a goal is to minimize the size of the deliverables, at some
point you need to cut down on dependencies.

And removing a whole language and its ecosystem seems like a pretty
good win dependency-wise.

Lots of dnf deps are already C libs, so it's not like the heavy-lifting 
is not available in C.

And then for plugins, it is certainly possible to have a C apps and let
people write plugins in various languages, among which Python. gedit
does this for example, through libpeas.

So no, I didn't mean to throw dnf out, I meant to consider what is the
minimal features (and dnf strikes me as one), and then radically reduce
what those depend on.

Note that I'm a Python developer by trade as well as by heart. So I'm
certainly not saying Python is terrible and should be eliminated. I
just think that managing to remove it from the minimum images would
lead better results (and much less confusion) than splitting it into
various subpackages.


-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: security of the lookaside cache (was: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf)

[Mathieu Bridon]

On Wed, 2015-12-30 at 20:09 +0100, Pierre-Yves Chibon wrote:
> On Wed, Dec 30, 2015 at 07:38:35PM +0100, Björn Persson wrote:
> > But still, why are we still using MD5?
> 
> For the record bochecha has been leading the move away from md5 to
> sha, making the changes in such a way that it will give us the
> flexibility to later change from sha1 to sha256, sha512 or something
> else.
> 
> The problem being that there are quite a number of places to change
> (dist-git, fedpkg...) which all have different upstreams and release
> cycles.
> So all in all, it's in progress but takes some time.

That's not the problem any more.

All those places have been changed, and should all be ready for the
switch now.

However, switching means breaking old fedpkg clients: people would have
to update their fedpkg as once we switch the old (i.e current) version
would fail to be able to handle anything non-md5.

The Fedora Releng team decided not to do that breakage at the moment,
and instead bundle it with other changes requiring a breakage, so that
we break things only once rather than several times.


-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF could improve messages about package auto-removal

[Mathieu Bridon]

On Fri, 2015-12-04 at 15:43 -0500, DJ Delorie wrote:
> > If the package yumdb entry (now dnfdb) says it was installed as a
> > dependency
> 
> This is the part I assumed was there.
> 
> Is there a separate dnf command to list all installed-as-dependencies
> that nothing depends on any more?

You can use "dnf list autoremove" to list the packages dnf thinks it
can remove (because they were installed as deps and nothing requires
them any more)

Then you can use "dnf mark install $pkg" to mark them as installed, and
they will disappear from the "autoremove" list.

Note that packages installed by PackageKit are not marked as installed,
so dnf always thinks it can remove them.



-- 
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: LibreOffice packaging is a messy dependency graph

[Mathieu Bridon]

On Wed, 2015-12-02 at 15:44 +0100, Roberto Ragusa wrote:
> On 12/02/2015 02:42 PM, David Tardon wrote:
> 
> > On Tue, Dec 01, 2015 at 02:20:34AM -0500, Dan Book wrote:
> > > I have run into this before and it was very confusing, it really
> > > should be
> > > a separate command from remove for when you actually want to
> > > remove what
> > > dnf thinks is now "unused".
> > 
> > Why? Remove is the opposite of install. "dnf install foo" will
> > install
> > package foo _and_ all its dependencies. So it is only logical that
> > "dnf remove foo" should remove package foo _and_ all its (unneeded)
> > dependencies.
> 
> Maybe it is not so simple.
> There are dependencies with no use apart the main tool (tool requires
> tool-libs),
> but in some cases the dependency is useful on its own (e.g. fonts).
> 
> So, I counter your reasoning with this:
> 
> - dnf install foo (also installs bar)
> - dnf install bar (oops, already installed, good)
> - dnf remove foo (wow, why did it remove bar, I explicitly
> "installed" it yesterday!)
> 
> Is dnf able to recognize that bar was "wanted" and not "accidental"?

There's "dnf mark install bar" for that.

And I **think** that it's automatically done when you installed bar in
your second command above. (if it isn't it probably should be)


-- 
Mathieu

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Mathieu Bridon]

On Tue, 2015-11-10 at 12:08 -0600, Adam Miller wrote:
> Hello all,
> In the Fedora 24 timeframe the Fedora Release Engineering group
> is
> aiming to deliver the Layered Image Build Service[0] to allow Fedora
> contributors to build containers images. In the first iteration of
> this we're targeting Docker layered image support. Part of this will
> be to allow Fedora contributors to maintain Dockerfiles much like we
> maintain rpm spec files via DistGit.
> 
> However we need to make a couple of decisions about naming
> conventions
> such that we can distinguish between rpms and container images as
> they
> are stored in Fedora DistGit. Also, alternatively we could setup a
> completely separate DistGit for container images that is disjoint
> from the one used for rpms. I would love feedback on everyone's
> preferences between those two options.

You could set it up in /srv/git/containers, in parallel to the current
/srv/git/rpms ?

That nicely avoids naming collisions.

It also should be quite asy now that dist-git is in ansible, you could
probably just factor out the path in the roles as a variable?

>     Cockpit's Dockerfile repo in DistGit would be stored with a
> leading special character:
> fedpkg clone -cockpit

With the "-" as a leading character, you open yourself to nice errors
with the fact that it could be recognized as options. So you'd want to
type: fedpkg clone -- -cockpit

Alternatively, if you separate the two distgits, you could have a
fedcontainer tool, which would just be fedpkg but with its
configuration pointing to the container distgit, the container build
service, etc...

Or maybe just a: fedpkg --container clone cockpit ?

Most of the code (at least the one handling dist-git) could probably be
reused without any difference.

All in all, separating them seems much simpler to me.

You'd have a bit of work up front (to adapt the Ansible playbooks and
fedpkg slightly), but you pretty much avoid a whole class of issues
with naming collisions, cli options, and future surprises.


-- 
Mathieu
-- 
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: git commits mess up

[Mathieu Bridon]

Hi,

On Fri, 2015-11-06 at 14:01 +0100, Germano Massullo wrote:
> I have done some mistakes in [1]
> 
> 1) I edited the file once to remove 32 bit CPU support, then I have
> done the push to master
> 2) I saw that I have forgotten to add changelog, so I edited the file
> again, I made a new push to master
> 3) I started merging the F21 branch to the master and I got the
> conflict
> 
> I have found a solution like [2], but I am afraid of making things
> get worse...

Assuming you want to have exactly the same thing in F21 and master, and
keep the two branches in sync in the future, here is something that can
get you out of this situation:

First, you need to cleanup the master branch, as you committed some
merge conflict indicators (the << === and >>> lines).

So just remove those lines, as well as the "Release: 2%{?dist}" line
(you bumped the release to 3, you don't want to also keep the line
setting it to 2)

Then commit on master.

At this point, you can do this:

 $ git checkout f21
 $ git merge master                       # this causes a merge conflict
 $ git checkout master -- darktable.spec  # solve the conflict by taking the 
file as it is in master
 $ git commit

At this point, the changes that were in master are now also in f21.

But you're not finished, if you really want to keep the branches in
sync from now on, here's the trick:

 $ git checkout master
 $ git merge f21

Now, both master and f21 are pointing to the exact same commit. So just
push and build.

Next time you make a change in master, just merge it in f21 and you
won't have any conflict any more. :)


-- 
Mathieu
-- 
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: apitrace-libs.i686 missing in x86_64 repos

[Mathieu Bridon]

On Fri, 2015-09-25 at 13:03 +0200, Sandro Mani wrote:
> Is there any other option short of introducing a dummy -devel
> package?

You could ask releng to add apitrace-libs to the multilib whitelist:

https://pagure.io/mash/new_issue

However, I have to wonder, why wouldn't the library have a -devel
package? Is there no way to link against that library?


-- 
Mathieu
-- 
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: apitrace-libs.i686 missing in x86_64 repos

[Mathieu Bridon]

On Fri, 2015-09-25 at 12:02 +0200, Sandro Mani wrote:
> Hello
> 
> Got bug #1266181 filed about apitrace.i686 missing in the x86_64
> repos. 
> The reporter probably meant apitrace-libs.i686, which in the past was
> indeed installable on x86_64. Any ideas what the reasons can be that 
> the package disappeared? Suppose something about the "mash" step, but
> that's as far as I get.

The way multilib works is that mash will get all the *-devel packages
from i686 and add them to the x86_64 repository, along with all their
dependencies.

In your case, you apitrace package doesn't generate any -devel
subpackage.

If it did, mash would include it for multilib, and as the -devel
packages usually depend on the -libs package, the -libs would also get
included.




-- 
Mathieu
-- 
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: python: dropping the .py files [was Re: Fedora 23 cloud image (and, for that matter, minimal anything)] bloat

[Mathieu Bridon]

On Fri, 2015-09-25 at 10:04 -0400, Matthew Miller wrote:
> On Thu, Sep 24, 2015 at 10:10:40AM +0200, Vít Ondruch wrote:
> > Also, you might consider to ship the precompiled bytecode just
> > optionally, using recommends.
> > 
> > On contrary, if you insist on shipping the bytecode, why you don't
> > drop
> > the .py files? I see a lot of duplication all around python
> > packages 
> 
> Wait, we can do that? Why don't we?
> 
> Everything I see in online discussion is centered on, basically,
> transparency. But we wouldn't be doing it for obfuscation. The srpms
> would still be there, and for that matter we could ship the .py files
> in a subpackage.

Or maybe rpm could have a macro a bit like %{_install_langs} (which
controls what language files are installed, even though they are all in
the packages) to control what gets installed for Python stuff, even
though everything is in the packages.

On Workstation, that macro would be set so that both the byte-code and
the code would be installed (it is invaluable for learning and
debugging purposes to be able to read/edit the code).

And on Cloud, that macro would be set to have only the bytecode
installed, so that you'd save the space.


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

Orphaning two packages

[Mathieu Bridon]

Hi everyone,

I'm going to orphan the following packages, as I haven't really been
interested any more in any of them for quite some time, now:

 * bonesi -- The DDoS Botnet Simulator
 (master, f23, f22, f21)

 * libhtp -- Security-aware parser for the HTTP protocol and the
 related bits and pieces
 (master, f23, f22, f21, el6)

Both are up to date and have no known bug reports in Fedora. Nothing
seems to depend on them.

If anybody wants to take over them, I'd be happy to pass them on.

If not, I'm just going to retire both of them in Rawhide.

Cheers,


-- 
Mathieu

-- 
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: Orphaning two packages

[Mathieu Bridon]

On Fri, 2015-09-11 at 18:10 +0800, Christopher Meng wrote:
> I'd be happy to take bonesi.

There, it's yours.


-- 
Mathieu

-- 
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: The DevConf.cz 2016 Call For Participation is now open!

[Mathieu Bridon]

Dear Jan,

On Fri, 2015-09-11 at 07:30 -0400, Jan Bleha wrote:
> Dear Red Hatters, 

We do not all work for Red Hat on the various Fedora mailing-lists you
sent this message to.

Should we, non Red Hatters, ignore this message? I'm asking, because
your email doesn't contain the typical "this email is confidential"
footer that usually accompanies corporate communication. ;)


-- 
Mathieu (ex Red Hatter, if that matters)

-- 
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: Orphaned packages available for new point of contact

[Mathieu Bridon]

On Thu, 2015-09-10 at 11:16 +0200, Matěj Cepl wrote:
> On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote:
> > pytz
> > python-dateutil
> 
> I see these two as too important to let them fall, so I am 
> taking them. However, I would really really like to have some 
> co-maintainers, because I don’t feel like I really understand 
> the matter.

Give acls to the python-sig group?


-- 
Mathieu
-- 
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: Glibc locale subpackaging

[Mathieu Bridon]

On Thu, 2015-08-27 at 16:10 +0200, Florian Festi wrote:
 On 06/22/2015 12:16 PM, Jan Kurik wrote:
  = Proposed System Wide Change: Glibc locale subpackaging  =
 
 We have to revisit this topic as soon as rich dependencies are in 
 place. Rich dependencies offer a way to handle locales on a system 
 wide level. One possible implementation would be having
 
 langsupport-XX meta packages that enable support for a given
 language.
 
 Locales could be in packages like glibc-lang-de, foo-lang-de, ...
 The main package could then have
 Requires: (foo-lang-de if langsupport-de)
 if we want to enforce the locale package to be installed.
 
 Otherwise it might be more elegant to have the language package (e.g.
 glibc-lang-de) have:
 
 Supplements: (glibc and langsupport-de)
 
 As we can assume that glibc is always installed this could already be
 done with:
 
 Supplements: langsupport-de
 
 The benefit of this approach is that installing a new langsupport-XX
 package will bring in the locale packages for all packages making use 
 of this mechanism.

Could that even be done automatically by rpmbuild?

Just like rpmbuild automatically generates a -debuginfo with the right
files in it, could it generated the -lang-xx packages with the .mo
files inside, and add the Supplements dependency you suggest?

Because doing it manually for all the languages supported by an
application (which might vary from release to release) would be pretty
awful. :-/


-- 
Mathieu
-- 
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: bodhi 2 now live

[Mathieu Bridon]

On Sun, 2015-08-23 at 22:23 +0200, Kevin Kofler wrote:
 Mathieu Bridon wrote:
  In the case of Kevin's update, the problem is that markdown lists
  must
  have an empty new line before them, like so:
  
  A paragraph of text:
  
  * first item
  * second item
  
  Kevin, you used the following, which indeed the Markdown parser
  turns
  into a single paragraph:
  
  A paragraph of text:
  * first item
  * second item
 
 Thank you for the analysis (and now I know how to work around this 
 regression), but:
 
  Bodhi 1 was already doing the same thing with such an input.
 
 No, sorry, but that is not true. I wrote those update notes in the 
 Bodhi 1 web interface, so of course I looked at the resulting
 formatting.
 Bodhi 1 interpreted that syntax as a list, not as a single paragraph. 


So it seems I wrote that code so long ago that I misremembered.

You are right, I has indeed added some special handling in Bodhi 1 to
have lists work even without an empty line before them:

https://github.com/fedora-infra/bodhi/blob/bodhi1-develop/bodhi/templat
es/show.kid#L47-L48

 This is a change in Bodhi 2 (and IMHO, for the worse, though if
 there's some official Markdown spec that says it should be that way,
 meh…).

Markdown is extremely under-specified, so a lot is left up to
implementations.

In the case of lists, I can find no mention at all of surrounding text
in the spec, it only talks about lists in complete isolation to other
elements, as far as I can see:

http://daringfireball.net/projects/markdown/syntax#list

Which means that very often, Markdown implementations just do whatever
the original implementation does, bugs and all.

And sure enough, if you try using the online demo:

http://daringfireball.net/projects/markdown/dingus

You'll find it behaves the same way Bodhi 2 does.

CommonMark is trying to improve this situation with a complete
specification, but it isn't what we use in Bodhi 2 (yet?)

If you really feel strongly about that empty newline, open a bug report
asking for it. I guess we could just reuse the one-liner I had for
Bodhi 1, or completely move to CommonMark, as it seems to allow what
you want:

http://spec.commonmark.org/0.21/#example-246

In any case, please open bug reports for anything you want in Bodhi 2,
to make sure your feedback isn't lost in the archives of the mailing
-list.


-- 
Mathieu
-- 
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: bodhi 2 now live

[Mathieu Bridon]

-- 
Mathieu

On Sat, 2015-08-22 at 19:27 -0500, Michael Catanzaro wrote:
 FWIW I think the new version looks much nicer than the old one.
 Hopefully the issues will be ironed out.
 
 On Thu, 2015-08-20 at 17:48 +0200, Kevin Kofler wrote:
  * The formatting of the update notes has changed in some ways (line
  breaks
gone missing?), breaking my nicely formatted notes, e.g.:
https://bodhi.fedoraproject.org/updates/calamares-1.1.2-1.fc23
(The enumerations were turned into one paragraph with bogus
  italics.)
 
 This one's a feature I think: updates are already displayed to the 
 user in markdown -- at least in GNOME Software, and I think even the
 obsolete GNOME Package Updater, and I think Muon as well? not sure
 about Apper -- so users are going to see your updates in italics no
 matter what. You'd be forgiven for not realizing this, since the web
 interface did not show this. That was a serious problem.

Bodhi 1 did interpret the update notes as Markdown already in the web
interface... for at least the past 5 years.

Bodhi 2 does have some extended Markdown features, compared to Bodhi 1,
but lists and italics were there from the start.

In the case of Kevin's update, the problem is that markdown lists must
have an empty new line before them, like so:

A paragraph of text:

* first item
* second item

Kevin, you used the following, which indeed the Markdown parser turns
into a single paragraph:

A paragraph of text:
* first item
* second item

Bodhi 1 was already doing the same thing with such an input.


-- 
Mathieu
-- 
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: Disk quota exceeded

[Mathieu Bridon]

On Thu, 2015-07-23 at 11:39 +0200, gil wrote:
 
 
 Il 23/07/2015 09:00, Marcin Haba ha scritto:
  On 23.07.2015 08:53, gil wrote:
   hi
   any ideas?
   Konsole output
   [gil@localhost SRPMS]$ scp jamm-0.3.1-1.fc22.src.rpm
   fedorapeople.org:~/public_html/
   scp: /home/fedora/gil/public_html//jamm-0.3.1-1.fc22.src.rpm: 
   Disk quota
   exceeded
   regards
   gil
  Hello,
  
  Please look on first point here:
  
  http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Commo
  n_Answers
  
  Each Fedora contributor has 200 KiB (approximately 1954 MiB) 
  of
  quota-controlled space.
  
  Probably you need to remove some files to take place for new upload 
  to
  fedorapeople.org.
  
  Best regards.
  Marcin Haba (gani)
  
 hi
 thanks for your suggestion, but i have already done this operation
 (removed unused src rpm ~ 20). but still the problem remain ...

Then you're probably still using too much space.

To be sure:

$ du -sh ~

If that's over the quota, then you should clean up more stuff.

Alternatively, you can request more space in your Fedora People home,
by asking the Infrastructure team. (which is written in that same page
Marcin sent earlier)


-- 
Mathieu
-- 
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: Proposal: Drop comps

[Mathieu Bridon]

-- 
Mathieu
On Wed, 2015-07-15 at 10:51 +0200, Ralf Corsepius wrote:
 On 07/15/2015 10:20 AM, Vít Ondruch wrote:
 
  Description and Summary can be localized in .spec file [1], where
  supposedly names in comps terminology refers to summary in 
  .spec
  terminology. Including translations is encouraged in guidelines as 
  well
  [2, 3], unfortunately without any further details :/
 
 I don't think localized summaries and descriptions are applicable in 
 distributions like Fedora, where packages are maintained by 
 individuals.
 
 IMO, making localized summaries/descrs. helpful would require a 
 multilingal team of translators/packagers, whose sole task it would 
 have 
 to be to add translations for a predefined set of languages to 
 maintain 
 them.
 
 That said, I don't consider random packagers adding random 
 translations 
 to packages to be useful and to cause more problems than they solve.

One problem with localized summaries/descriptions in packages, is that
you need a new build (and a new update in Bodhi, unless you wait 6
months for the next release) for it to reach users.

That's a lot of churn, and it's a terrible UX for users to keep
receiving updates that only add a translation of the
summary/description of the package (not the app itself!) in a language
they might not even care of.

Comps is much better on this point: we edit comps, and at the next
compose the change is taken into account.

Much less churn, especially for the users.


-- 
Mathieu

-- 
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: Is %autosetup another unwanted baby of Fedora?

[Mathieu Bridon]

On Mon, 2015-07-13 at 15:21 -0500, Dennis Gilmore wrote:
 On Monday, July 13, 2015 09:13:24 PM Richard W.M. Jones wrote:
  Is anyone maintaining fedpkg now?
 
 fedpkg has active maintainership and development.   does not mean 
 that every corner case is know about of gets attention.

fedpkg might sometimes look like it's not getting any development
though, but that's really because most of the work happens in pyrpkg,
the library used by fedpkg (and rhpkg, and a couple others)

And pyrpkg is probably where patch management should end up in fact, so
that it can be shared with other users of pyrpkg.


-- 
Mathieu
-- 
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: yum for mock in RHEL 6?

[Mathieu Bridon]

On Mon, 2015-06-15 at 08:56 +0200, Miroslav Suchý wrote:
 Dne 12.6.2015 v 00:28 Kevin Kofler napsal(a):
  1. The software we ship in Fedora (and that includes EPEL) should 
  work out of the box. If you cannot provide DNF (with the plugins) 
  in EPEL, then defaulting to yum is the only option.
  
  2. The mock previously in EPEL actually worked for Rawhide (using 
  yum there), so you have taken existing user setups that worked and
  broken them, for no practical benefit whatsoever (because all they 
  can do to make it work is to make exactly the settings change you 
  refuse to make by default, and because mock will just work with 
  yum).
 
 So you are suggesting what?
 Let silently use yum on EL hosts?

Kevin didn't say anything about it being silent.

By all means, do warn people that mock is going to use yum instead of
dnf as it should.

But an application should never print an error message telling the user
what they can do to get the error to go away. That's just bad design.

If the application knows what the user should do to get around the
error, then the application should just do it itself.

Finally, you're basically saying that mock requires dnf to build
proper Rawhide packages. You're a package maintainer, it is your
responsibility to maintain the dependencies for your package in all the
Fedora/EPEL branches where your package is.

That means if mock requires dnf (and its plugins) to build Rawhide
packages, and you maintain mock in EPEL, then it is your responsibility
to make sure that dnf (and its plugins) are in EPEL.


-- 
Mathieu

-- 
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: yum for mock in RHEL 6?

[Mathieu Bridon]

On Wed, 2015-06-03 at 14:19 +0200, Miroslav Suchý wrote:
 Dne 2.6.2015 v 06:56 Dave Johansen napsal(a):
  https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_a
  nd_DNF
  
  I just ran into this issue and I was wondering if it's possible for 
  this flag to be add to the default config on RHEL 6/7.
 
 Technically yes.
 
 Politically no.
 
 As stated in refered blog entry:
   http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not
 _work_on_el_6_and_el7_and_how_to_fix_it/index.html
 I decided to go with 3rd option. And you must manually acknowledge 
 that you are creating builds non-standard way and
 they may differ from builds made on Fedora.

Except that builds made on Fedora Koji all use yum to populate the mock
chroot, not dnf.

As a result, it is the mock default configuration of using dnf which is
non-standard.


-- 
Mathieu

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

Orphaning/retiring 2 packages

[Mathieu Bridon]

Hi,

I don't use these 2 packages any more, and don't want to continue
maintaining them.

If someone want to take over, I'll be happy to pass them. But if nobody
express their interest in the next few days, I'll just retire them.

# weighttp

This package hasn't had any upstream release since 2011. Well, upstream
didn't actually release anything, they just tagged the commit with
v0.3, so I was generating the tarball myself.

There have been 6 commits in master since the last release, all in
2013.

So all in all, upstream is dormant, at best.

# docx2txt

Last release was in 2014, I guess it works overall, but like I said I
don't use it myself any more.

Cheers,


-- 
Mathieu

-- 
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: Naming packages when upstream uses dashes in the release version

[Mathieu Bridon]

On Wed, 2015-05-06 at 10:24 +0200, Ralf Corsepius wrote:
 On 05/06/2015 09:21 AM, Petr Pisar wrote:
  On 2015-05-05, Alexander Ploumistos alex.ploumis...@gmail.com wrote:
  What irks me the most, is that the version of the source package is
  3.80-1 and this is reflected in the spec file macros (Version: 3.80,
  Release 1),
 
  It depends on the meaning of the upstream's `-1'. Basically, I would
  interpret it as yet another version level, i.e. as `3.80.1'. If the upstream
  tends to release `3.80.1-1', I'd interpret `3.80-1' as `3.80.0.1'.
 
 This is one common practice. I personally use _ for local packages in 
 such occasions (IIRC, rpm doesn't care whether _ or . is used).

Indeed:

  $ rpmdev-vercmp 1.0-1 1_0-1
  1.0-1 == 1_0-1

Thanks, I had never realized that. :)


-- 
Mathieu

-- 
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: Contact info for FAS user: anishpatil

[Mathieu Bridon]

On Tue, 2015-04-21 at 15:01 +0200, Robert Mayr wrote:
 Maybe his RH address?
 apa...@redhat.com

Anish just left Red Hat.

He is also moving countries, so maybe that's why he hasn't been very
responsive lately?


-- 
Mathieu

-- 
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: dnf replacing yum and dnf-yum

[Mathieu Bridon]

On Mon, 2015-04-13 at 10:43 -0700, Adam Williamson wrote:
 On Mon, 2015-04-13 at 08:47 +0200, Mathieu Bridon wrote:
  Le dimanche 12 avril 2015 à 17:06 -0700, Adam Williamson a écrit :
   
   It's hard to see how you build a perfect dep check other than 
   trying 
   to solve the deps of *every single package in the distro* against 
   every proposed update.
  
  Can't we run repoclosure on (at the same time) the fedora repo, the 
  updates repo, and a temporary repo made of the packages to be pushed?
  
  Repoclosure does check for the deps of every single package in the 
  set 
  of repos it is provided.
 
 Not sure offhand if we've looked into using repoclosure to check this, 
 but one obvious issue I can think of is, what if repoclosure isn't 
 clean *to start with*?

Block all updates push until repoclosure gets cleaned?

Of course, Bodhi admins would need to still be able to force pushes, to
not block security updates or updates which fix repoclosure.

Think of the incentive this would provide to fix broken deps! :)


-- 
Mathieu

-- 
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: dnf replacing yum and dnf-yum

[Mathieu Bridon]

Le dimanche 12 avril 2015 à 17:06 -0700, Adam Williamson a écrit :
 
 It's hard to see how you build a perfect dep check other than trying 
 to solve the deps of *every single package in the distro* against 
 every proposed update.

Can't we run repoclosure on (at the same time) the fedora repo, the 
updates repo, and a temporary repo made of the packages to be pushed?

Repoclosure does check for the deps of every single package in the set 
of repos it is provided.


-- 
Mathieu

-- 
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: dnf replacing yum and dnf-yum

[Mathieu Bridon]

On Thu, 2015-04-02 at 14:23 +0200, Jan Kratochvil wrote:
 On Thu, 02 Apr 2015 09:50:05 +0200, Jiří Konečný wrote:
 rpm/repoquery just do not support wildcards so one has to type:
   repoquery --whatprovides 'libnetapi.so.0()(64bit)'
   dnf repoquery --whatprovides 'libnetapi.so.0()(64bit)'

That's not entirely true:

 $ repoquery --whatprovides 'libnetapi.so.0*64*'
 samba-libs-2:4.1.17-1.fc21.x86_64
 samba-libs-2:4.1.12-5.fc21.x86_64

DNF however:

 $ dnf repoquery --whatprovides 'libnetapi.so.0*64*'
 Using metadata from Thu Apr  2 14:26:05 2015


-- 
Mathieu

-- 
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: [Proposal] Ring-based Packaging Policies

[Mathieu Bridon]

Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit :
 On 02/17/2015 05:18 PM, Petr Pisar wrote:
 
  Why not to create a new repository with reduced policy as
  Stephen proposed with the one-way dependency rule (between current 
  Fedora and the new easy-for-beginners repository)?
 
 Because this would establish a 2-class society, with double 
 standards standards and so on.
 
 Also RH and other distros history repeatedly has told the lesson 
 such will not fly and are doomed to fail.

It seems to have been working just fine in RPMFusion, where the free 
and nonfree repositories have different standards for inclusion, and 
where packages in nonfree can depend on packages in free, but not the 
other way.

At another scale, it seems to not be working too badly already for 
Fedora+RPMFusion, where Fedora and RPMFusion have different standards 
for inclusion, and where packages in RPMFusion can depend on packages 
in Fedora, but not the other way.

If I understand correctly, Ubuntu has a similar setup with main and 
universe, and so does Debian with main, contrib and nonfree.

History doesn't seem to unambiguously prove what you think it does, 
but then I guess you can always argue that those examples just haven't 
failed yet. ;)


-- 
Mathieu
-- 
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: rawhide report: 20150125 changes

[Mathieu Bridon]

Le dimanche 25 janvier 2015 à 08:13 +, Fedora Rawhide Report a écrit :
 [python-pygit2]
 python-pygit2-0.21.4-1.fc22.i686 requires libgit2.so.21
 python3-pygit2-0.21.4-1.fc22.i686 requires libgit2.so.21

I've tried updating pygit2 to the latest 0.22.0 release, which is made 
for libgit2 0.22.0.

However, it fails on i686:

https://github.com/libgit2/pygit2/issues/477


Still trying to figure out what's going on, will update then.

-- 
Mathieu
-- 
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: amending the new package process

[Mathieu Bridon]

On Thu, 2015-01-22 at 14:49 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 Unfortunately review swaps don't work for new packagers, before they are
 sponsored. They are encouraged to do informal reviews, but those reviews
 don't carry formal weight. I propose to change this, and allow non-sponsored
 packagers to do formal reviews, except that an actual packager with review
 rights has to ack the review.

This is exactly what informal reviews are.


-- 
Mathieu

-- 
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: DNF as default package manager

[Mathieu Bridon]

On Thu, 2015-01-22 at 17:00 +0100, Vít Ondruch wrote:
 Dne 21.1.2015 v 17:12 Dennis Gilmore napsal(a):
  On Wed, 21 Jan 2015 11:13:24 +0100
  Mathieu Bridon boche...@fedoraproject.org wrote:
   On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote:
   I am using mock for Fedora development with DNF enabled by default
   and it works just fine. May be you want to share what is troubling
   you?
 
   There is a difference between « it works just fine for me » and « it
   works to build the distro »
 
  and for it works to build the distro it has to work on releases all the
  way back to rhel 5 as we build epel for rhel5 still and need to make
  rhel5 chroots. I have not heard of anybody testing that at all yet.
 
 Actually, the mock configuration might be different for different releases:
 
 https://lists.fedoraproject.org/pipermail/buildsys/2014-December/00.html

Not in Koji.

As Dennis already said, Koji generates its own Mock configs, it doesn't
use the ones shipped with Mock itself.


-- 
Mathieu

-- 
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: DNF as default package manager

[Mathieu Bridon]

On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote:
 Dne 21.1.2015 v 10:35 Peter Robinson napsal(a):
  On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý msu...@redhat.com wrote:
  On 01/21/2015 09:33 AM, Vít Ondruch wrote:
  It is surprising to see so many packges depending on yum. Yes, there is
  stuff like rpm-build and mock,
  And mock can live without yum. If we only had weak deps allowed in Fedora 
  mock.spec would have
Recommends: yum
 
  But I'm really interested in state of DNF as default too. Should I switch 
  mock to use DNF as default?
  For me there is still lot of unfinished tasks. E.g. documenting what 
  --installroot should actually do [BZ 1163028]
  I don't think it's ready, it might be useful to have an option to
  switch it over for local use to enable easier wider testing but I
  certainly don't think it's ready to be default for mock yet.
 
  Peter
 
 I am using mock for Fedora development with DNF enabled by default and
 it works just fine. May be you want to share what is troubling you?

There is a difference between « it works just fine for me » and « it
works to build the distro »

The latter needs much more testing and guarantees than the former,
although the former is certainly encouraging.


-- 
Mathieu

-- 
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: Did I mess up? [dcmtk abi change in stable branches]

[Mathieu Bridon]

Hi,

On Wed, 2014-12-17 at 10:58 +0100, Mario Ceresa wrote:
 Now, simply recompiling them fixes the problem in rawhide, but how can
 I avoid breaking things in stable branches? Is there a way to have all
 three packages hit the repositories at the same time?

They need to be part of the same update in Bodhi.


-- 
Mathieu

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

[EPEL-devel] EPEL-ANNOUNCE Major update of libhtp in EPEL6

[Mathieu Bridon]

Hi,

tl;dr: I just submitted a major update of libhtp to EPEL6 testing,
testing and feedback are more than welcome:

  https://admin.fedoraproject.org/updates/libhtp-0.5.16-1.el6

-

A security bug has been opened today against libhtp in EPEL6:

  https://bugzilla.redhat.com/show_bug.cgi?id=1173610

The bug is fixed in the latest upstream release (0.5.16), but EPEL6
still was using the (very old) 0.3.0.

Preferring not to break libhtp users in EPEL6, I first tried to just
backport the patch for the security issue.

Then I realized that the EPEL6 package wasn't running the unit tests in
%check, so I figured I'd add them, to be a bit more confident in my
backported fix.

This broke the build on PPC64. It seems that libhtp 0.3.0 never actually
worked on PPC64 in EPEL6.

Backporting a simple security fix is one thing, but making the library
work on PPC64 is more than I'm able to do for libhtp on EPEL6 these
days.

As a result, I decided to instead try pushing the update to the latest
and greatest, as it both fixes the security issue and works on PPC64:

  https://admin.fedoraproject.org/updates/libhtp-0.5.16-1.el6

It seems nothing requires libhtp in EPEL6, but I thought I'd still send
an announcement about the bump, for people building their own stuff
against it.

If it really causes too much problem to upgrade it, then I'll welcome
any help to find another solution.

Sorry for the trouble,


-- 
Mathieu

___
epel-announce mailing list
epel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-announce
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Update to Parole 0.6.x stable series - completed port to GTK+3

[Mathieu Bridon]

Hi,

On Mon, 2014-12-01 at 07:39 +0100, poma wrote:
 Gentlemen packagers, resting on your laurels?

You should try being less snarky in your future communications, it
usually leads to better results.

 Update to Parole 0.6.x stable series - completed port to GTK+3
 https://bugzilla.redhat.com/show_bug.cgi?id=1169240

Here is the procedure to report a nonresponsive package maintainer:

http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

You'll notice that it speaks about delays in order of 7 days, not 7
hours.

In addition, here is the procedure to become a packager and help
maintain this package, if you care about it:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Good luck!


-- 
Mathieu

-- 
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: Mozilla enabled ads in Firefox and they're active in Fedora

[Mathieu Bridon]

On Mon, 2014-11-17 at 11:37 +0200, Nikos Roussos wrote:
 I don't consider my IP address a call to home. [...] Even Gnome checks my
 IP's location to fix my timezone.

Not by default, you have to enable this explicitly.

  Second, a user can easily accidentally click on ad, since it is mixed
  among other tiles, with the user's browsing habits. 
 
 And a user may accidentally start searching on the Google search box
 before she realizes that she sends data to Google as she types (that's
 how you get recommendations).

Indeed, this is in Firefox though, which is the application people are
saying they'd like to change, so it stops doing that without explicit
user opt-in.

 Again, this thing we discuss is already happening on Gnome Shell. Type
 twitter on your Gnome's search box.

I'm pretty confident that no network query is done when you search for
that, and that instead GNOME Software searches in its local metadata
cache.

Nothing outside of your own computer knows that you searched for
twitter in the GNOME search box.

 And I don't think there is a way
 currently to disable this. So please get your facts straight before
 start suggesting we change default browser.

All examples you have given of such opt-out network calls are either in
Firefox or incorrect.

So maybe there is a need to change something in the Firefox default
configuration after all? :)


-- 
Mathieu

-- 
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: Improving the offline updates user experience

[Mathieu Bridon]

On Fri, 2014-10-24 at 12:00 +0200, Miroslav Suchý wrote:
 I'm not updating daily. I upgraded my machine IIRC 2-3 weeks ago. So lets 
 benchmark it and provide you real data.
 
 My machine have classic magnetic disk, however in SW RAID1.
   Timing cached reads:   12236 MB in  2.00 seconds = 6124.59 MB/sec
   Timing buffered disk reads: 412 MB in  3.00 seconds = 137.12 MB/sec
 Fedora 21, 16 GB RAM (2GB free), 8 CPU cores, swap available but none used
 
 I run dnf upgrade and I have been offered 853 packages and 1.3 GB to 
 download.
 Download lasted 3mins 20secs.
 Then installation started and since beginning transaction started till the 
 end lasted exactly 53 minutes.
 No specific package is blocking the process, dnf was chewing packages one by 
 one in steady pace. Veryfing phase lasted 
 ~4 minutes, so it means approximately 3 second per package, which is what I 
 am seeing on screen.
 
 And this is nothing exceptional. I see similar times across all machines I 
 maintain. When I'm updating box of my mother 
 (old EeeBox, updating aprox every 3 months) then the time is usually 3 hours 
 (however ~1 hour is just download phase).

More than anything, doesn't this just shows that we simply push way too
many updates in Fedora?


-- 
Mathieu

-- 
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: man-db without cache update (no cron or systemd *.timer)

[Mathieu Bridon]

On Thu, 2014-10-16 at 13:34 +0200, Jan Chaloupka wrote:
 On 10/16/2014 12:56 PM, Vít Ondruch wrote:
  Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a):
  Forwarding Colin's response
[... snip ...]
  Have you considered installing the timer file, but without the
  dependency?  If systemd is there, it could use it, otherwise not.  That
  would make a whole lot more sense to me than creating another package,
  and would be my recommendation.
 
 This did not crossed my mind.
 
  Actually that is good idea IMO. The %post script could silently fail if
  no systemd is no the system.
 
 Agree with Vita, this sound very good to me. Made a test build and it is 
 working fine.

But it's contrary to the guidelines, as you're installing the unit file
in %{_unitdir}, without requiring systemd to own this directory.

Which goes back to the idea of either moving %{_unitdir} to the
filesystem package, or having a systemd-filesystem package...


-- 
Mathieu

-- 
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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)

[Mathieu Bridon]

On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote:
 Hi all,
 
 We seem to have a number of broken dependencies in F21 that have gone
 unfixed for a quite some time. Not sure what's up with them; the
 maintainers are supposed to get daily notifications to make sure these
 don't go unnoticed.
 
 Does anyone have ideas how to deal with these packages?
 
 I wonder if it would make sense to just drop them before F21. Having
 broken dependencies basically means that the packages are completely
 broken and cannot be installed at all. Not much point in shipping those
 in the repositories ...
 
 Any ideas how to deal with this?
 
Here's a quick look at some of them.

Note that I'm not a provenpackager, so I can't actually do anything
about it myself.

## libint soname bump

 [PyQuante]
  PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 
 0:1.1.6-2.fc21

This can just be rebuilt:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881637

 [cp2k]
  cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
  cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
 0:1.1.6-2.fc21
  cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1
  cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
 0:1.1.6-2.fc21
 
This hasn't finished building yet, but it seems ok so far:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881650
  
## json-c soname bump

 [authhub]
  authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
 
This fails to build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881643

## rbtorrent soname bump

 [fatrat]
  1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires 
 libtorrent-rasterbar.so.7

Seems this will need some upstream work:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881660

 [flush]
  flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7

So does this:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881679

## ocaml-camlp4 update

The dep was updated:

  $ repoquery --provides ocaml-camlp4
  ocaml(Camlp4) = 315363230d084ceb1cc5e85bfe2bfd49

 [cduce]
  cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
 0:ebd368022fd2bc7b305a42902efa4c90

This fails to rebuild:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630

 [ocaml-pa-do]
  ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 
 0:ebd368022fd2bc7b305a42902efa4c90

This fails to rebuild:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760

## vala update

 [gedit-valencia]
  gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
 libvala-0.24.so.0

This fails to build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881927

However, there's a new upstream release which might fix the problem.

 [monodevelop-vala]
  monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala  0:0.25.0

This fails to build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881961

However, there's a new upstream release which might fix the problem.

 [valabind]
  valabind-0.7.4-4.fc21.armv7hl requires libvala-0.24.so.0

This fails to build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=7881954

However, there's a new upstream release which might fix the problem.

## Django 1.4 retired

 [django-recaptcha]
  django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
 [openslides]
  openslides-1.3.1-3.fc21.noarch requires python-django  0:1.5
 [pootle]
  pootle-2.1.6-8.fc21.noarch requires python-django14
 [python-coffin]
  python-coffin-0.3.7-3.fc21.noarch requires python-django14
 [python-django-addons]
  python-django-addons-0.6.6-2.fc21.noarch requires python-django14
 [python-django-longerusername]
  python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch 
 requires python-django14
 [transifex]
  transifex-1.2.1-12.fc21.noarch requires python-django14

Django 1.4 has been retired:
  https://lists.fedoraproject.org/pipermail/devel/2014-September/202593.html

 [python-askbot-fedmsg]
  python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot

Askbot was retired in f21 and master:
  https://lists.fedoraproject.org/pipermail/devel/2014-September/202687.html

 [audtty]
  audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
 
Seems libaudclient was part of audacious but has then been removed
upstream:
  http://audacious-media-player.org/download

## Unknown cases

 [edelib]
  edelib-2.1-5.fc21.armv7hl requires libedelib.so
  edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so

This is weird, edelib provides libedelib.so.2.1.0, but somehow it
requires libedelib.so

Could it be the rpmbuild automatic requires generator misbehaved?

 [avro]
  avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
  avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
 [spring-maps-default]
  spring-maps-default-0.1-12.fc21.noarch requires spring
 [freesteam]
  

[perl-EV/f21] Update to 4.18

[Mathieu Bridon]

commit 89cd6ed077a532bec7b4d1a00e4047cdb7d23803
Author: Mathieu Bridon boche...@fedoraproject.org
Date:   Sat Sep 6 23:05:55 2014 +0200

Update to 4.18

 .gitignore   |1 +
 perl-EV.spec |8 +---
 sources  |2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 23d6200..2a892af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 *.swp
 /EV-4.03.tar.gz
 /EV-4.11.tar.gz
+/EV-4.18.tar.gz
diff --git a/perl-EV.spec b/perl-EV.spec
index 82d6e56..66fb843 100644
--- a/perl-EV.spec
+++ b/perl-EV.spec
@@ -1,6 +1,6 @@
 Name:   perl-EV
-Version:4.11
-Release:6%{?dist}
+Version:4.18
+Release:1%{?dist}
 Summary:Wrapper for the libev high-performance event loop library
 
 # Note: The source archive includes a libev/ folder which contents are licensed
@@ -68,11 +68,13 @@ make test
 %{perl_vendorarch}/auto/*
 %{perl_vendorarch}/EV.pm
 %{perl_vendorarch}/EV
-%{perl_vendorarch}/EV/*.h
 %{_mandir}/man3/*.3*
 
 
 %changelog
+* Tue Sep 30 2014 Mathieu Bridon boche...@fedoraproject.org - 4.18-1
+- Update to 4.18
+
 * Sun Aug 17 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 4.11-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
 
diff --git a/sources b/sources
index 3370188..15c851f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-405c6d74f9dff12918b12560c1a57877  EV-4.11.tar.gz
+5931d0ba91f93b95723e80d573da606f  EV-4.18.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-EV] Bump to rebuild against libev-source 4.19

[Mathieu Bridon]

commit c8181db5095920290ff64178c51fa99e55d65686
Author: Mathieu Bridon boche...@fedoraproject.org
Date:   Tue Sep 30 14:44:03 2014 +0200

Bump to rebuild against libev-source 4.19

 perl-EV.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-EV.spec b/perl-EV.spec
index 49f31cc..673e1ba 100644
--- a/perl-EV.spec
+++ b/perl-EV.spec
@@ -1,6 +1,6 @@
 Name:   perl-EV
 Version:4.18
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Wrapper for the libev high-performance event loop library
 
 # Note: The source archive includes a libev/ folder which contents are licensed
@@ -72,6 +72,9 @@ make test
 
 
 %changelog
+* Tue Sep 30 2014 Mathieu Bridon boche...@fedoraproject.org - 4.18-4
+- Bump to rebuild against libev-source 4.19
+
 * Sun Sep 14 2014 Emmanuel Seyman emman...@seyman.fr - 4.18-3
 - Bump to rebuild against libev-source 4.18
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: splitting a subpackage to proper package process

[Mathieu Bridon]

On Thu, 2014-09-11 at 13:54 +0200, Nikos Mavrogiannopoulos wrote:
 On Thu, 2014-09-11 at 12:25 +0200, Michael Schwendt wrote:
  On Thu, 11 Sep 2014 12:15:49 +0200, Nikos Mavrogiannopoulos wrote:
  
   Hello,
There is a package which includes a subpackage that I'd like it split
   as a proper package (possibly with different maintainers). Is there some
   special process for that or does it have to follow the full process for
   new packages as in [0]?
   
   regards,
   Nikos
   
   [0].
   https://fedoraproject.org/wiki/New_package_process_for_existing_contributors
  
  You could/should have given more details, which would make it easier to
  answer.
 
 I'd like to split vpnc-script from vpnc [0], but I don't maintain the
 package, so I omitted the details. Anyway the issue is, that vpnc-script
 which has a different upstream [1] than vpnc, is used by both vpnc and
 openconnect, and is part of the vpnc package. For that I'd like it split
 from vpnc and being a separate package, so I can help maintain it
 without maintaining vpnc which I have no idea about (the issue started
 when vpnc was not in epel7 and that prevented openconnect from being
 there).
 
 [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1128147
 [1].
 http://git.infradead.org/users/dwmw2/vpnc-scripts.git/blob_plain/HEAD:/vpnc-script
 
 Usually, everything from one _source tarball_ is included in a _single_
  src.rpm, so you split the build into subpackages. Once upstream splits off
  something into a separate tarball, it may be time to create another src.rpm
  for it. There is no strict requirement to do so, however, because RPM can
  handle multiple source archives per src.rpm. It may be more convenient to
  create multiple src.rpm packages depending on how often the individual
  pieces are updated/upgraded/rebuilt. And yes, [0] applies to new packages.
 
 Ok, but on this case we have both vpnc and vpnc-script from vpnc.spec.
 If vpnc-script becomes a separate package (with its own repository),
 does it qualify as new package?

In this context, « new package » means any new source package, which is
equivalent to any new spec file, or any new git module, etc...

So yes, that is the very same process.


-- 
Mathieu

-- 
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: Issue during generating header files

[Mathieu Bridon]

Hi,

On Mon, 2014-09-01 at 19:03 +0200, Antonio Trande wrote:
 Hi all.
 
 I don't understand why same code is not compiled with rpmbuild unlike
 when I compile in local.
 
 This is compiled with rpmbuild: http://fpaste.org/130139/

This does: ./configure ... --enable-liblua

 This is compiled in local:  http://fpaste.org/130141/

This does: ./configure ... --enable-libclua

Note liblua vs libclua

Could that be the cause of your problem?


-- 
Mathieu

-- 
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: are compiler flags being honored?

[Mathieu Bridon]

On Tue, 2014-08-12 at 15:26 +0200, Dhiru Kholia wrote:
 Now, I need your feedback and cool ideas to improve this project :-)

So first, this is great!

However, the results.txt is very hard to use in order to check if
maintainers need to do something.

How about instead, splitting the results into one file per srpm?

Also, maybe in the long-term integrate that somehow with Taskotron, so
that the check is run after every build? (or at least for every Bodhi
update)


-- 
Mathieu

-- 
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: Is fedpkg designed to be usable for online only?

[Mathieu Bridon]

On Thu, 2014-07-17 at 10:09 +0800, Christopher Meng wrote:
 Hi,
 
 After using the new pkgdb2 API based fedpkg, I'd like to ask a question here:
 
 Is fedpkg designed to be usable when online only?
 
 
 
 Well..
 
 If I cut disable my connection, fedpkg switch-branch doesn't work:
 
 Could not execute switch_branch: len([]) != len(['ssh: Could not
 resolve hostname pkgs.fedoraproject.org: Name or service not known',
 '', '', 'and the repository exists.'])
 ERROR:rpkg:Could not execute switch_branch: len([]) != len(['ssh:
 Could not resolve hostname pkgs.fedoraproject.org: Name or service not
 known', '', '', 'and the repository exists.'])

Off the top of my head, one thing it needs an online access for, is
determining what Fedora release corresponds to the master branch.

It does that by querying Koji (or maybe pkgdb2 now, not sure)

There are probably many things which won't require an internet
connection, and we could make these work if they don't already.

But for example, how do you propose solving the point I mentioned?


-- 
Mathieu

-- 
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: How to restart dbus service?

[Mathieu Bridon]

On Thu, 2014-07-17 at 16:11 +0200, Miroslav Suchý wrote:
 Hi,
 how can I restart dbus service, registered via systemd unit?
 
 To be specific, I have in system:
 /usr/share/dbus-1/services/org.a11y.atspi.Registry.service
 with:
 [D-BUS Service]
 Name=org.a11y.atspi.Registry
 Exec=/usr/libexec/at-spi2-registryd --use-gnome-session

That service should instead have a SystemdService= key, with the name of
the systemd unit as its value. (then Exec= becomes completely unused)

Without this (and the actual systemd unit), the service is completely
unknown by systemd, so it can't restart it.


-- 
Mathieu

-- 
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: How to restart dbus service?

[Mathieu Bridon]

On Thu, 2014-07-17 at 10:24 -0400, Matthias Clasen wrote:
 On Thu, 2014-07-17 at 16:21 +0200, Mathieu Bridon wrote:
  On Thu, 2014-07-17 at 16:11 +0200, Miroslav Suchý wrote:
   Hi,
   how can I restart dbus service, registered via systemd unit?
   
   To be specific, I have in system:
   /usr/share/dbus-1/services/org.a11y.atspi.Registry.service
   with:
   [D-BUS Service]
   Name=org.a11y.atspi.Registry
   Exec=/usr/libexec/at-spi2-registryd --use-gnome-session
  
  That service should instead have a SystemdService= key, with the name of
  the systemd unit as its value. (then Exec= becomes completely unused)
  
  Without this (and the actual systemd unit), the service is completely
  unknown by systemd, so it can't restart it.
  
 
 This is a session service, so systemd is not in the picture (yet).

Ah, right, I misread and read the path as .../system-services/...


-- 
Mathieu

-- 
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: dnf even allows to uninstall RPM and systemd without warnings

[Mathieu Bridon]

On Mon, 2014-06-23 at 19:07 +0200, drago01 wrote:
 On Mon, Jun 23, 2014 at 7:01 PM, Reindl Harald h.rei...@thelounge.net wrote:
 
 
  Am 23.06.2014 18:47, schrieb Chris Adams:
  Once upon a time, Bruno Wolff III br...@wolff.to said:
  Try yum update when the oldest installed kernel (and the running
  kernel) is the only one that works and there is a new (still broken
  for your system) kernel update available. In that case one really
  wouldn't expect the running kernel be removed. Having to remove a
  specific kernel before doing an update (to make sure the wrong one
  wasn't removed) would be a pain.
 
  I guess I never considered it a pain.  That's exactly what I would do if
  I knew a particular kernel was broken (remove specifically the broken
  kernel).  I never knew yum/a yum plugin/whatever did magic stuff based
  on the running kernel, trying to remove special packages like yum,
  etc.
 
  be glad that you learned something new :-)
 
 
  I have no problem with GUI tools having magic protections built in, but
  I prefer CLI tools that don't try to out-think me.  yum/dnf already asks
  for confirmation (which is more than up2date did); having additional
  layers of protection/confirmation/whatever built-in seems excessive to
  me.
 
  in general - agreed
 
  but not if it comes to destory the complete setup
 
  It looks like there isn't even a way to override this behavior in yum.
  I haven't wanted to remove all the kernels in a while (I guess since
  before this was added); is the only way to bypass yum and use rpm?
 
  yes - simply because the chance that soemone wants to uninstall all
  kernels, yum, dnf and finalyl rpm itself is very low
 
 You still did not give a simple case why someone with some sanity left
 would do yum remove rpm or yum remove yum ...

One thing I've seen a few times at the time Yum didn't have that
protection was « I don't do development, so I can remove Python »

It did lead to a few people not having Yum installed any more.


-- 
Mathieu

-- 
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: EPEL quick epel7 update

[Mathieu Bridon]

On Tue, 2014-06-17 at 16:14 +0200, Simone Caronni wrote:
 Mock is using CentOS:
[... snip ...]
 Don't know for Koji, but probably it's the same. No?

No, Koji uses RHEL as an external repo, and points its mock configs to
it.


-- 
Mathieu

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: F22 System Wide Change: Replace Yum With DNF

[Mathieu Bridon]

On Tue, 2014-06-17 at 16:37 -0400, Peter Jones wrote:
 On Tue, Jun 17, 2014 at 02:40:45PM -0500, Dennis Gilmore wrote:
  I am not away of any work to make mock use dnf. dnf will
  need to be able to make mock chroots going all the way back to rhel5
  since we use mock in the buildsystem and we build epel5 there.
 
 Wait, why will it need to do that?  The chroots appear to be compatible,
 unless I've missed something major.  So creating them with the RHEL 5
 host's yum should work, I hope.  Is there a something I've missed?

The host might not be RHEL 5, it could be Fedora 22.


-- 
Mathieu

-- 
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: Orphaning most of my packages

[Mathieu Bridon]

On Thu, 2014-04-24 at 14:46 +0200, Stanislav Ochotnicky wrote:
 I am doing spring cleanup and getting rid of most of my packages. The
 full list is a bit too long (mizdebsk agreed to take over all of my Maven
 related packages as primary maintainer). Here's the remaining bits that
 need a new home:
 
  * python-gudev

Isn't that obsoleted by the GObject-Introspection bindings?

 from gi.repository import GUdev
 


-- 
Mathieu

-- 
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: libreoffice broken again in updates-testing

[Mathieu Bridon]

On Thu, 2014-04-17 at 16:24 +0200, Reindl Harald wrote:
 and before you tell me now about outdated mirrors - no, see repo-file below
 what you are installing *now* don't matter, *now* 4.2.3.3-4 is in the repo
 starting with tuesday evening until today the broken one was
 
 to make it short: i can handle yum and repos
 
 [root@rh:~]$ cat /etc/yum.repos.d/fedora-updates.repo
 [updates]
 name=Fedora $releasever - $basearch - Updates
 failovermethod=priority
 baseurl=https://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/

Just thought I'd let you know: download.fedoraproject.org is in fact an
alias that redirects you to a mirror.

That doesn't change anything about your main point (that the update
wasn't pushed yet when you were trying but had been before Sergio
replied), but it would still be theoretically possible for you to get
sent to an outdated mirror, just like using mirrorlist.


-- 
Mathieu

-- 
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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Mathieu Bridon]

On Wed, 2014-03-26 at 08:27 +0100, Robert Mayr wrote:
 
 Il 21/mar/2014 12:59 Matthew Miller mat...@fedoraproject.org ha
 scritto:
 
  On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote:
   I agree with Jaroslav. I was looking forward to have a fourth
   product to those three. KDE can help define what is needed for new
   product, what must be done by all teams, how much work it will be
   ... I guess we should speak more about addition of new product and
   don't kill the idea at the start.
 
  Like I said, I'm skeptical, but listening. :)
 
  --
  Matthew Miller--   Fedora Project--
  mat...@fedoraproject.org
 
 I think the same, if all spins become products we can also keep the
 actual way. Fedora.next is a very good idea and I'm sure it will have
 success, but it needs to follow his strategy with three different
 products, not having 2 different ones and *n*
 workstation-similar-products, IMHO.
 
 I don't think spins are not useful, but they could be under the wing
 of Workstation as a sub-product perhaps.

Some spins won't be desktop-related.

Maybe what we'd need is something like AUR where users contribute
packages for Arch Linux which are not supported enough to be in the
main repositories?

We could have the official 3 (for now) products, and a different place
where the wider community can gather to publish different images, each
one with a different focus (e.g a KDE desktop, or a tailor-made cloud
image for a new provider, or an arch-specific image for a
yet-unsupported device, or...)

We could even call that place spins.fedoraproject.org ;)

It could be more open than the current spins process, allowing a wider
community to publish more varied things than we have now (more spins!),
and it would be up to each group to ensure the quality of what they
produce, have their own release cycle, etc...


-- 
Mathieu

-- 
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: Retired update still showing in updates-testing

[Mathieu Bridon]

On Thu, 2014-03-13 at 09:23 +0100, Simone Caronni wrote:
 The packages are these two:

 guacamole-client-0.8.3-5.fc20
 guacamole-client-0.8.3-5.fc19

 Can someone explain what has happened? Should I file a ticket
 somewhere?

The builds are still tagged as testing, which is why they appear in the
repositories:

http://koji.fedoraproject.org/koji/buildinfo?buildID=500690
http://koji.fedoraproject.org/koji/buildinfo?buildID=500691

The solution is for you to untag the builds:

$ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19
$ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20

Then at the next mash, they will be gone.

I have no idea why they are still tagged, though. Maybe you removed the
updates while the builds were being pushed, which tends to trip Bodhi
up.

Or maybe you hit a Bodhi bug.


-- 
Mathieu

-- 
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: Retired update still showing in updates-testing

[Mathieu Bridon]

On Thu, 2014-03-13 at 09:41 +0100, Simone Caronni wrote:
 On 13 March 2014 09:33, Mathieu Bridon boche...@fedoraproject.org
 wrote:
 The solution is for you to untag the builds:
 
 $ koji untag-pkg f19-updates-testing
 guacamole-client-0.8.3-5.fc19
 $ koji untag-pkg f20-updates-testing
 guacamole-client-0.8.3-5.fc20
 
 Then at the next mash, they will be gone.
 
 I have no idea why they are still tagged, though. Maybe you
 removed the
 updates while the builds were being pushed, which tends to
 trip Bodhi
 up.
 
 Or maybe you hit a Bodhi bug.

 Thanks, I've already tried it but I can't tag/untag packages in Bodhi:
 
 $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19
 ActionNotAllowed: tag requires admin permission
 
 I think some admin intervention is needed.

Ah, right... Open a rel-eng ticket, then. :)

  https://fedorahosted.org/rel-eng/newticket

-- 
Mathieu

-- 
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: packages which require the kernel package

[Mathieu Bridon]

On Mon, 2014-03-10 at 15:22 -0400, Matthew Miller wrote:
 ipset

Fixed in Rawhide: ipset-6.21.1-2.fc21


-- 
Mathieu

-- 
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: fedpkg build failing (due to NSS?)

[Mathieu Bridon]

On Mon, 2014-03-03 at 16:06 +0800, Christopher Meng wrote:
 I've left a negative karma there, they forgot to add the new nss-util
 into overrides list.

No, it's been added, but then it was expired:
https://admin.fedoraproject.org/updates/override/edit?build=nss-util-3.15.5-1.fc20
https://admin.fedoraproject.org/updates/override/edit?build=nss-softokn-3.15.5-1.fc20

That's not the problem at all.

The problem is that **some** of these 3 overrides were epired, but not
all.

The three packages need to always be in overrides together, or none of
them.

Leaving a negative karma to the update won't help fix the problem
either.


-- 
Mathieu


-- 
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: fedpkg build failing (due to NSS?)

[Mathieu Bridon]

On Mon, 2014-03-03 at 08:26 +, Peter Robinson wrote:
  I've left a negative karma there, they forgot to add the new nss-util
  into overrides list.
 
  No, it's been added, but then it was expired:
  https://admin.fedoraproject.org/updates/override/edit?build=nss-util-3.15.5-1.fc20
  https://admin.fedoraproject.org/updates/override/edit?build=nss-softokn-3.15.5-1.fc20
 
  That's not the problem at all.
 
  The problem is that **some** of these 3 overrides were epired, but not
  all.
 
  The three packages need to always be in overrides together, or none of
  them.
 
  Leaving a negative karma to the update won't help fix the problem
  either.
 
  At least they can get the news IMO.
 
 That is completely the wrong way to communicate this and it doesn't
 get them the news and in fact often stops people getting critical
 security or stability fixes for a pathetic little game. The way to
 communicate this problem is by the mailing lists/email/IRC etc... IE
 proper communication channels. To try to communicate by putting
 negative karma on updates that have nothing what so ever to do with
 actual update needs to stop.

In addition, we've been talking about it on #fedora-admin for the past
hour, and Remi already notified via email the nss maintainer.

Christopher, remember that you and I are in APAC, which means we are
already awake when the nss maintainer (in the US) is still sleeping, so
he won't get the news instantly.

Finally, Pierre-Yves just extended the two already expired buildroot
overrides, which should fix the problem soon.

This would tell you when it's ready:
$ koji wait-repo f20-build --build=nss-softokn-3.15.5-1.fc20 
--build=nss-util-3.15.5-1.fc20


-- 
Mathieu

-- 
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: Schedule for Wednesday's FESCo Meeting (2014-02-26)

[Mathieu Bridon]

On Tue, 2014-02-25 at 20:13 -0700, Kevin Fenzi wrote:
 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.

If there's still time after the other ones, could you discuss ticket
1238?

#topic ticket #1238 Should Bodhi reset karma to 0 when builds are changed?
.fesco 1238
https://fedorahosted.org/fesco/ticket/1238

Thanks,


-- 
Mathieu


-- 
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: exclude people from giving karma?

[Mathieu Bridon]

On Sun, 2014-02-23 at 18:36 +0100, drago01 wrote:
 On Sun, Feb 23, 2014 at 6:35 PM, Michel Alexandre Salim
 sali...@fedoraproject.org wrote:
  One potential workflow bug with this karmic automatic-push-to-stable: under
  the normal time-delayed path, any editing of the build reverts the package
  set to pending. Yet if the package set is being pushed to stable thanks to
  meeting the karma threshold, editing the build seems to have no effect (from
  the log in the link given, bodhi automatically triggers a push within 4
  seconds, meaning the edited package set is basically never tested)
 
  What would be a good solution here -- invalidate the karma votes?
 
 Yes because obviously the karma has been given based on testing a
 different build.

For what is worth, this is exactly what we do at $dayjob with our own
Bodhi instance.

Which means I already have a patch if we wanted to do that in Fedora
too.

Does this kind of change need to go through FESCo?


-- 
Mathieu

-- 
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: Drawing lessons from fatal SELinux bug #1054350

[Mathieu Bridon]

On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote:
 On Mon, 27 Jan 2014 10:18:56 -0500
 Matthew Miller mat...@fedoraproject.org wrote:
 
 snip
 
  * possibly adding a what should users test? field to the update
  info.
  
I know that there's a notes field in the update, but maybe it'd
  help to explicitly include testing instructions?
  
Each package in the pkgdb (or in git, or wherever) could have
a standard list included in each update as the default (for
  example, for 'calc', it might be to try `calc -q
  read /usr/share/calc/regress.cal`. That would duplicate a likely
  smoke-test, though, so maybe also run interactively and make sure
  basic math works.
  
Then, each update could also optionally (and this would be
  presented in bold if it were used) say something like New release
  adds log() function; please test that it works, or Severe bug where
  1+1=3 corrected; please test that the answer now corresponds with
  consensus reality.
 
 I could have sworn we already had something like this where bodhi would
 add a link to a wiki page for test plan on a package if that wiki page
 existed. I can't seem to find it now, so perhaps it was just something
 we talked about, but never implemented. 

Nope, you're right. :)

https://github.com/fedora-infra/bodhi/blob/develop/bodhi/model.py#L191

For example, the test case pages for the package 'foo' need to be added
to the 'Category:Package foo test cases' category.

There's also an option in the config file which must be switched on for
this to work: 'query_wiki_test_cases'

And here is an update where this is, in fact, actually used:
https://admin.fedoraproject.org/updates/FEDORA-2014-1465/


-- 
Mathieu


-- 
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: Shipping package metadata in a package

[Mathieu Bridon]

Hi,

On Fri, 2014-01-24 at 10:01 +, Richard Hughes wrote:
 There are two ways to fix the jarring UX. We could either ship the
 fedora package metadata pre-prepared in PackageKit, maybe using
 something like %ghost so the new metadata is ignored. The other way is
 to start the metadata downloading in the initial-start wizard thing,
 although in practice the download takes a couple of minutes to
 complete, and the wizard typically takes much less than that before
 the user has configured everything. The downside to shipping prepared
 metadata is that the package size is larger, and that the metadata
 would be *very* out of date after a year or so.

Rather than during the initial setup thing, why not start it at first
boot, much earlier?

Another option would be to have it done as the last step of the
installer.


-- 
Mathieu


-- 
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: EPEL Moving to testing repo?

[Mathieu Bridon]

On Fri, 2014-01-17 at 07:11 +0100, Daniel Pocock wrote:

 I've been trying to do this for a new package, cajun-jsonapi
 
 bodhi refuses to let me request the update, it always gives the
 message:
 
 cajun-jsonapi-2.0.3-1.el6 not tagged as an update candidate
 
  
 It is in the Git repository branch for EPEL6
 
 http://pkgs.fedoraproject.org/cgit/cajun-jsonapi.git/tree/?h=el6
 
 and it is built on EPEL6:
 
 http://koji.fedoraproject.org/koji/buildinfo?buildID=489563
 
 Would anybody know what I am doing wrong?  Or is there some cooling off 
 period before new packages can go to EPEL?

The build is indeed not tagged as an update candidate, it is tagged as
trashcan.

That means is has been (or soon will be, I forgot) removed.

That being said, the build never succeeded:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6385065

It is quite weird though that it is the tagging task which failed,
something seems to have gone wrong here.

What you could do is:
  koji tag-pkg dist-6E-epel-testing-candidate cajun-jsonapi-2.0.3-1.el6

That should put the build back in the proper state, and then Bodhi will
let you create the update.


-- 
Mathieu

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: really stop really commits (really!)

[Mathieu Bridon]

On Mon, 2013-12-16 at 01:47 -0700, T.C. Hollingsworth wrote:
 On Mon, Dec 16, 2013 at 1:11 AM, Martin Stransky stran...@redhat.com wrote:
  There are some cases when we need it (sources taken as a snapshot from
  git/cvs)
 
 Huh?  The sources have to be either in git or in the lookaside cache
 for koji to find them later.  I'm not sure how it could get this
 wrong?
 
  patches applied by different way.
 
 How else can you apply patches listed on PatchN lines?  It already
 covers %patchN, %{patches}, and now %autosetup.  If there's something
 else, I'd really like to know.

The kernel package uses a custom-defined ApplyPatch macro, for example.


-- 
Mathieu


-- 
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: [pkgdb2] call for testers, bug reports and RFE

[Mathieu Bridon]

On Thu, 2013-12-12 at 09:02 +0100, Matthias Runge wrote:
 On 12/12/2013 04:19 AM, Mathieu Bridon wrote:
  On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote:
  The idea behind is:
 
  you have some application with an issue/error. You'll do rpm -qf
  filename and will get a package name, not necessarily the source
  package name.
  When filing a bug against a package, you'll need to know the source
  package name.
  
  rpm -qi gives you the source package.
  
  
 So, why do we hide it this way?
 
 How is a new user or a GUI-only person

Well, you were talking about someone who had just used rpm -qf, so in
that context rpm -qi made a lot of sense.

 able to find the right package to
 file a bug against? A nasty person might even say: this is by purpose ;-)

As far as I know, pkgdb is not targeted at end users but at package
maintainers (as it handles the ACLs on packages).

/packages is more targeted at users, and it does show what is the base
package for a given subpackage.

For example: https://apps.fedoraproject.org/packages/libcangjie-devel

In case you miss the Subpackage of XXX, you can just click on the
Bugzilla link, which will open a bug against the proper base package.

You could argue that the two apps should be only one, but that's a
different discussion. (and the people actually doing the work to
implement and maintain those apps feel that it's better to separate
them)


-- 
Mathieu

-- 
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: [pkgdb2] call for testers, bug reports and RFE

[Mathieu Bridon]

On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote:
 The idea behind is:
 
 you have some application with an issue/error. You'll do rpm -qf
 filename and will get a package name, not necessarily the source
 package name.
 When filing a bug against a package, you'll need to know the source
 package name.

rpm -qi gives you the source package.


-- 
Mathieu


-- 
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: crazy /usr/lib/event.h (was: Packaging changes for libev in Rawhide)

[Mathieu Bridon]

On Tue, 2013-12-03 at 22:13 -0500, Rahul Sundaram wrote:
 Hi

 On Tue, Dec 3, 2013 at 9:47 PM, Gilles J. Seguin  wrote:
 
 OMG
 i do not know what to say here
 /usr/lib/event.h
 -1 should -1,000,000,000
 
 :-)
 i need a list of peoples making such uninspired suggestions
 
 Even with a smiley,  you haven't really added anything useful to the
 discussion.  -1 or -1 million makes no difference whatsoever.  The
 maintainer making the change has listed out his rationale.  If you
 want to present yours, feel free to do so (without breaking the thread
 unnecessarily).   Anything else is just noise.

In addition, I feel it's worth mentioning that nobody in this thread
ever suggested that /usr/lib/event.h would be a good idea... or even an
idea at all.


-- 
Mathieu


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