Re: non-responsive maintainer for python-mimeparse

2017-02-28 Thread Jan Kaluža 

On 02/27/2017 10:29 PM, Carl George wrote:

Per the non-responsive maintainer policy [1], I would like to bring attention 
to a bug for python-mimeparse [2].  Does anyone know how to contact the 
maintainer jkaluza?


Hi, I gave you permissions to work maintain this package. Sorry for long 
delay.


Jan Kaluza


[1]: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1339379

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


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

Re: User Visible Terminology

2016-09-22 Thread Jan Kaluža 

On 09/21/2016 03:08 PM, Honza Silhan wrote:

Hi

On Fri, Sep 16, 2016 at 5:02 PM, Petr Šabata  wrote:

On Thu, Sep 15, 2016 at 10:59:55AM -0400, Matthew Miller wrote:

On Thu, Sep 15, 2016 at 02:25:52PM -, Mary Clarke wrote:

* enable vs install vs select


select is the worst :)


It's what I half-jokingly suggested during the last WG meeting :)

The reason was it's a verb we often use when talking about
modularity -- users "selecting" what modules they want on
their system.

Selecting/enabling/installing a module doesn't necessarily
mean something will get installed on your system.  I don't like
"install" much for that reason.


In the "enable" description is written: "Enable: enables the latest
version and/or release of a module and installs the rpms listed in the
default profile" so does it install something or not? Can you please
provide example when the module prepared for use does not need to be
installed?


There might be modules which contain just shared libraries which other 
modules would depend on. Such modules do not need to have any 
installation profile, so no RPM would be installed when the module is 
installed - the installation of its RPMs would be done as a result of 
dependencies from another module.


Even when there might be modules like that, I would personally vote for 
staying compatible with DNF subcommands as much as we can - so use 
"install". I presume that installation of majority of modules will 
result in some RPM being installed from the module. Modules which do not 
install any RPM during their installation are kind of special (like 
shared dependencies, shared services and so on) and they won't be 
installed by the end users in common cases.


I would personally start with list of DNF commands described here 
http://dnf.readthedocs.io/en/latest/command_ref.html and try to describe 
their Modularity equivalents similarly as Jan did in the last paragraph 
of his email I'm replying to.




Also keep in mind that when modules support is implemented in DNF it
will not be in conflict with the new terminology.  i.e. "dnf install
httpd" == enable httpd module == install rpms of httpd module. So
please reconsider "install" again.


* Install: performs actions to prepare modules to run


Is install a subset of enable, or does enable simply call install as a
convenience if you try to enable something that's not installed?


/me shrugs.

Until very recently, I thought install and enable were just
different verbs for the same action.  I don't really understand
what "install" means now either.  Could someone knowledgable
elaborate?


* Run: run the module


What does that mean? Do I *need* to run a module? Is this like "scl
enable"? And how does this interact with "enable", for that matter?


+1


I would like to also hear what "install" and "run" means in module
terminology. It should be IMO explained before "enable" is decided to
be used as a reference word.

Would it be possible to provide more information about the commands
and in best case provide use cases for commands? Something like:
"Admin has module of version X installed. In the the same stream this
module has a security fix. Admin will use "check-upgrade" which will
..., then he will ... to ...


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



Regards,
Jan Kaluza
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: User Visible Terminology

2016-09-22 Thread Jan Kaluža 

On 09/22/2016 09:04 AM, Garrett Holmstrom wrote:

On 2016-09-16 08:43, Matthew Miller wrote:

On Fri, Sep 16, 2016 at 05:02:04PM +0200, Petr Šabata wrote:

This is for the labeling of, for example, separate PHP 5, 6, and 7
modules?


Yes.  Or even variations of the same upstream version.

I'm really pro-stream here because these identifiers have
nothing to do with upgrade paths and some modules or module
stacks wouldn't even have any concept of numbered, progressive
builds/releases.  It's just a label.

I would save the word "version" to identify updates within
these "streams".


I agree on not using "version" for this. I'm not completely sold on
"stream", partly because we talk about "upstream" and "downstream" so
much, and this is unrelated to that. How about "branch"? That fits with
the idea of "rebase" for switching between them


How about "series", as in "the PHP 7 series"?


Some people around modularity started using "generation" recently, this 
is imho also good word.


Jan Kaluza


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

Orphaning Tremulous

2015-07-20 Thread Jan Kaluža 

Hi,

I'm orphaning tremulous and tremulous-data packages. The upstream is 
dead and it fails to compile against new speex in rawhide. I think the 
package is more or less ready for retirement, but maybe someone else 
would like to fix the speex incompatibility and keep it in Fedora for 
few more releases...


Regards,
Jan Kaluza
--
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: Fedora 23 mass rebuild

2015-06-22 Thread Jan Kaluža 

On 06/19/2015 05:59 PM, Nils Philippsen wrote:

On Tue, 2015-06-16 at 22:58 -0500, Dennis Gilmore wrote:

the list of current failures can be found at
http://alt.fedoraproject.org/pub/alt/mass-rebuild/f23-failures.html


If someone else happens to have their build fail on find-debuginfo.sh
...:

 + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz 
--dwz-low-mem-die-limit 1000 --dwz-max-die-limit 5000 
/builddir/build/BUILD/gimp-help-2.8.2
 RPM build errors:
 error: Bad exit status from /var/tmp/rpm-tmp.vrrhQp (%install)
 Bad exit status from /var/tmp/rpm-tmp.vrrhQp (%install)

... check if you install executable JPEG files into your buildroot:
find-debuginfo.sh runs the file command on all executable files, and
file-5.22-3.fc23 contains a bug causing it to exit with a non-zero exit
code on certain JPEG files, cf.:
https://bugzilla.redhat.com/show_bug.cgi?id=1201630


Hi,

I've just pushed update fixing this File's bug. It is already in 
rawhide, stable Fedora versions have pending update in bodhi.


Regards,
Jan Kaluza


Nils



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

Renaming rubygem-passenger to passenger

2014-10-01 Thread Jan Kaluža 

Hi,

upstream asked us 6 months ago if it would be possible to rename 
rubygem-passenger package to passenger and clean-up the package 
little bit to match the progress Passenger did in last years.


The reason to do this is that Passenger is not real rubygem anymore and 
supports more languages than just Ruby. During the years, 
rubygem-passenger package deviated little bit and in some respects 
does not respect Fedora Guidelines.


I've changed the existing rubygem-passenger package to match the 
Fedora Guidelines and I'm going to rename it to passenger in Fedora 
Rawhide. All other Passenger maintainers are aware of this change.


You can see the rename review here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1074515.


Regards,
Jan Kaluza
--
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: Build lua libraries also for compat-lua?

2014-06-03 Thread Jan Kaluža 

On 05/29/2014 06:31 PM, Tomasz Torcz wrote:

On Tue, May 13, 2014 at 11:17:39AM +0200, Jan Kaluža wrote:

Hi,

I'm playing with an idea of building lua libraries against compat-lua to
allow luajit working with them. My initial motivation for this is that there
are projects which don't work with Lua-5.2 and developers for various
reasons don't want to port it to lua-5.2 yet (for example Prosody package).

I'm OK with creating bugs and patches against some basic lua modules
(basically the ones I need myself for Prosody :) ), but at first I wanted to
ask Lua people here what do they think about it?


   Hi,

   Was there any progress with this?  I'd love to see working Prosody package 
in F20.



I have persuaded one proven packager to do this change in Fedora Rawhide 
and it looks there is no problem with it and Prosody is working in 
Rawhide now. I think I will ask him to backport this into F20, so I can 
rebuild Prosody in F20 too.


Regards,
Jan Kaluza

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

Build lua libraries also for compat-lua?

2014-05-13 Thread Jan Kaluža 

Hi,

I'm playing with an idea of building lua libraries against compat-lua to 
allow luajit working with them. My initial motivation for this is that 
there are projects which don't work with Lua-5.2 and developers for 
various reasons don't want to port it to lua-5.2 yet (for example 
Prosody package).


I would imagine it to work the same way as Python2 vs. Python3 does. It 
means to build the project twice - once against lua (lua-5.2) and once 
against compat-lua (lua-5.1) using single spec file.


I've done some test with lua-expat and I'm attaching patch against 
lua-expat.spec to show how it could be done.


I'm OK with creating bugs and patches against some basic lua modules 
(basically the ones I need myself for Prosody :) ), but at first I 
wanted to ask Lua people here what do they think about it?


Regards,
Jan Kaluza


lua-expat-compat.patch
Description: application/download
-- 
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: Perl autorequires failing for git-svn

2014-01-15 Thread Jan Kaluža 

On 01/15/2014 01:56 AM, Todd Zullinger wrote:

Hi all,

[I posted this to the packaging list a few days ago, but haven't gotten
any responses, so I want to open this to a wider audience in the hope of
getting some pointers to what I'm missing.]

I'm trying to fix a problem with the git-svn package that causes it to
not pull in the proper perl dependencies (filed as rhbz #1026760). (It's
possible I've simply missed an important announcement, but I didn't spot
anything in the guidelines.)

It appears that the file package was changed from 5.11 in f19 to 5.14 in
f20.  With this change, the git-svn script reports a different type and
find-requires does not pass it to perl.req for processing.

f19:

mock-chroot[root@f20-64 /]# file --version
file-5.11
magic file from /etc/magic:/usr/share/misc/magic

mock-chroot[root@f20-64 /]# file
/builddir/build/BUILD/git-1.8.4.2/git-svn
/builddir/build/BUILD/git-1.8.4.2/git-svn: Perl script, ASCII text
executable

mock-chroot[root@f20-64 /]# /usr/lib/rpm/find-requires 
/builddir/build/BUILD/git-1.8.4.2/git-svn

/usr/bin/perl
perl = 0:5.008
perl(Carp)
perl(Digest::MD5)
perl(File::Basename)
perl(File::Find)
perl(File::Path)
perl(File::Spec)
perl(Getopt::Long)
perl(Git)
perl(Git::SVN)
perl(Git::SVN::Editor)
perl(Git::SVN::Fetcher)
perl(Git::SVN::Log)
perl(Git::SVN::Migration)
perl(Git::SVN::Prompt)
perl(Git::SVN::Ra)
perl(Git::SVN::Utils)
perl(IO::File)
perl(IPC::Open3)
perl(lib)
perl(Memoize)
perl(strict)
perl(Term::ReadLine)
perl(vars)
perl(warnings)

f20:

mock-chroot[root@f20-64 /]# file --version
file-5.14
magic file from /etc/magic:/usr/share/misc/magic

mock-chroot[root@f20-64 /]# file
/builddir/build/BUILD/git-1.8.4.2/git-svn
/builddir/build/BUILD/git-1.8.4.2/git-svn: Perl5 module source, ASCII text

mock-chroot[root@f20-64 /]# /usr/lib/rpm/find-requires 
/builddir/build/BUILD/git-1.8.4.2/git-svn

This fails because find-requires only passes the file to perl.req if
it's either a .pm file or it's in the script list, which is defined like
this:

scriptlist=`echo $filelist | xargs -r file | \
grep -E :.* (commands|script)[, ] | cut -d: -f1`


Thanks for this part. I didn't know that. My test-suite for File checks 
only the regexp defined in /usr/lib/rpm/fileattrs, which is following in 
F20:


%__perl_magic   ^.*[Pp]erl .*$

So when testing File-5.14 I didn't think this will cause problems to 
RPM. I can make File to return Perl script again, but I would rather 
stay consistent with upstream in the detection.


There's already bug about this: 
https://bugzilla.redhat.com/show_bug.cgi?id=1051598. I will open 
upstream bug for that.



This is where the change in the file commands output is causing trouble.

Any help would be much appreciated.

Thanks!



Jan Kaluza

--
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: Perl autorequires failing for git-svn

2014-01-15 Thread Jan Kaluža 

On 01/15/2014 08:46 AM, Rahul Sundaram wrote:

Hi


On Wed, Jan 15, 2014 at 2:28 AM, Panu Matilainen wrote:

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


That doesn't appear to be correct.  Can you try again?


It's this one: https://bugzilla.redhat.com/show_bug.cgi?id=1051598


Rahul




Jan Kaluza

--
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: Perl autorequires failing for git-svn

2014-01-15 Thread Jan Kaluža 

On 01/15/2014 08:28 AM, Panu Matilainen wrote:

On 01/15/2014 02:56 AM, Todd Zullinger wrote:

Hi all,

[I posted this to the packaging list a few days ago, but haven't gotten
any responses, so I want to open this to a wider audience in the hope of
getting some pointers to what I'm missing.]

I'm trying to fix a problem with the git-svn package that causes it to
not pull in the proper perl dependencies (filed as rhbz #1026760). (It's
possible I've simply missed an important announcement, but I didn't spot
anything in the guidelines.)

It appears that the file package was changed from 5.11 in f19 to 5.14 in
f20.  With this change, the git-svn script reports a different type and
find-requires does not pass it to perl.req for processing.

f19:

mock-chroot[root@f20-64 /]# file --version
file-5.11
magic file from /etc/magic:/usr/share/misc/magic

mock-chroot[root@f20-64 /]# file
/builddir/build/BUILD/git-1.8.4.2/git-svn
/builddir/build/BUILD/git-1.8.4.2/git-svn: Perl script, ASCII text
executable

mock-chroot[root@f20-64 /]# /usr/lib/rpm/find-requires 
/builddir/build/BUILD/git-1.8.4.2/git-svn

/usr/bin/perl
perl = 0:5.008
perl(Carp)
perl(Digest::MD5)
perl(File::Basename)
perl(File::Find)
perl(File::Path)
perl(File::Spec)
perl(Getopt::Long)
perl(Git)
perl(Git::SVN)
perl(Git::SVN::Editor)
perl(Git::SVN::Fetcher)
perl(Git::SVN::Log)
perl(Git::SVN::Migration)
perl(Git::SVN::Prompt)
perl(Git::SVN::Ra)
perl(Git::SVN::Utils)
perl(IO::File)
perl(IPC::Open3)
perl(lib)
perl(Memoize)
perl(strict)
perl(Term::ReadLine)
perl(vars)
perl(warnings)

f20:

mock-chroot[root@f20-64 /]# file --version
file-5.14
magic file from /etc/magic:/usr/share/misc/magic

mock-chroot[root@f20-64 /]# file
/builddir/build/BUILD/git-1.8.4.2/git-svn
/builddir/build/BUILD/git-1.8.4.2/git-svn: Perl5 module source, ASCII
text

mock-chroot[root@f20-64 /]# /usr/lib/rpm/find-requires 
/builddir/build/BUILD/git-1.8.4.2/git-svn

This fails because find-requires only passes the file to perl.req if
it's either a .pm file or it's in the script list, which is defined like
this:

scriptlist=`echo $filelist | xargs -r file | \
grep -E :.* (commands|script)[, ] | cut -d: -f1`

This is where the change in the file commands output is causing trouble.

Any help would be much appreciated.


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

Also FYI, /usr/lib/rpm/find-requires (or -provides) is not what's used
during rpmbuild unless specifically overridden to use that legacy
mechanism.


Does that mean that my File test-suite based on /usr/lib/rpm/fileattrs 
is correct and that's the only way how RPM currently (by default) parses 
File's output? Are there more places I should be aware of and include 
into my test-suite?



 - Panu -




Jan Kaluza

--
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: [ACTION REQUIRED] Blocking more retired packages in F20+

2013-09-17 Thread Jan Kaluža 

On 09/17/2013 06:15 PM, Till Maas wrote:

Hi,

the package 'xorriso' is retired, but not yet blocked, because 'cdw'
depends on it. Therefore either 'xorriso' needs to be unretired with a
review or 'cdw' needs to be retired or drop the dependency.

I just blocked the following packages in koji for F20+, because they
were retired some time ago, but not yet blocked:

abby
aimage
amide
autobuild-applet
autotrust
bluemodem
cricscore-applet
darkice
gnome-exe-thumbnailer
gnome-shell-extension-mediaplayers
gnome-shell-extension-noim
gnome-shell-extension-presentation-mode
gnome-shell-extension-righthotcorner
gnome-specimen
gnome-xcf-thumbnailer
ifplugd
metagoofil
osutil
php-laconica
python-certifi
ruby-fam
ruby-racc
trustyrc

They might also lack a dead.package, but I will write a separate mail
about this.

I noticed there is the package 'libircclient-qt' which was only retired in
Rawhide but not Branched (F20). Is this really intentional? Since F20 is
not yet released, it is still a good idea to retire it, because it seems
to be renamed.


Done, thanks.


Regards
Till



Regards,
Jan Kaluza

--
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: Why can't ExecStopPre= be used to abort stopping a (broken) service?

2013-07-17 Thread Jan Kaluža 

On 07/15/2013 10:55 PM, Lennart Poettering wrote:

On Mon, 15.07.13 14:18, Paul Wouters (pwout...@redhat.com) wrote:



Hi,

For daemons, it happens that people (or puppet/ansible) makes a config
change that causes the config file to not load and be invalid. When
restarting the service, it will stop but not start. Ideally, the stop
should be aborted.

I was looking at ExecStopPre= (which is mentioned in the systemd.service
man page, although it does not have its own section, so is easilly
missed) but it did not abort the stop on a parse error in the daemon's
config file.

I found this note by Lennart: 
http://osdir.com/ml/fedora-devel-list/2011-05/msg00696.html

No, ExecStopPre= cannot be used for making shutdown of a service
conditional. Even if one of the pre lines fails we will go on with
shutting down the service, however we will store the exit code and the
service will be in failed state once fully shut down.

My question is, why not? Various daemons (libreswan, bind, knot, nsd,
etc) have a check config option that could be used to prevent stopping
a service if the config file got messed up so it would prevent the
service from starting.

I realise that it is not optimal to keep a service running that will fail to
restart on the next machine boot, but is that preferable over failing
immediately? If ExecStopPre= would fail and log a message, sysadmins
would be able to notice the issue and fix it. And there would be 0
downtime. As opposed to the current behaviour, which kills the service.

However, if ExecStopPre= would support this, then every maintainer could
choose for themselves which situation is preferred.


If I grok correctly what you are asking for, you are actually looing for
an ExecRestartPre=, not an ExecStopPre=. You want somthing that is run
before we stop a service when we intend to restart it. But when we
shutdown the system and stop the service for that, or if the user wants
to stop it manually, we shouldn't run it, correct?

If that's what you want, then yes, it is on the TODO list to add
something like this, but ExecStopPre= is not what you want, it would
have very different semantics.


Httpd needs that too for the same use-case. There's open bug on bugzilla 
for that RFE.



Lennart



Jan Kaluza

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

Re: logrotate(8) and copytruncate as default

2013-06-27 Thread Jan Kaluža 

On 06/27/2013 01:54 PM, P J P wrote:

Hi,

Recently I've seen multiple issues related to new file creation by logrotate(8).
A race condition described by [1], between creation of a new file and setting
file permissions and acl(5).  Another I came across in ndjbdns [2], as it 
continued
to write to an open, but rotated log file.


Hi,

This is usually fixed by sending some signal to daemon in postscript 
informing it that logs should be reopened. That way, no messages are 
lost. The worst thing which can happen is that some messages get logged 
in the rotated file for short time (after rename is done by logrotate 
and before daemon reopens the new log).




Wouldn't it be better to make 'copytruncate' as default behaviour for 
logrotate(8)?
Instead of renaming an old file and creating a new one.
[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1098
[2] 
https://github.com/pjps/ndjbdns/commit/be5fd0c90376b5c89e5b5dc3d57f64d905afe519


If you use copytruncate, there is chance that some messages get lost (as 
stated in man logrotate). Making it default could surely make things 
much easier and less error-prone, but I'm afraid we just can't remove 
old behaviour completely right now and therefore it wouldn't save 
anything regarding the problems you have mentioned.


I'm not sure right now if the benefits of the copytruncate usage are 
strong enough in comparison with the possibility to lost the messages 
during rotation.


I will definitely try it and see how bad it is, but I presume for bigger 
logs it could be a problem.


Maybe it's just better to try to fix existing bugs and not abandon the 
rename and reopen way completely?





Thank you.

---
Regards
-Prasad
http://feedmug.com



Regards,
Jan Kaluza

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

Re: boost soname bump

2011-11-23 Thread Jan Kaluža 
On 11/20/2011 05:37 PM, Bruno Wolff III wrote:
 On Sun, Nov 20, 2011 at 08:05:34 -0600,
Bruno Wolff IIIbr...@wolff.to  wrote:
 It looks like there was a soname bump in boost yesterday. Boost affects
 enough stuff, that there really should have been a heads up message posted to
 the devel list about this.

 It looks like there may have been a semantic change in how BOOST_FOREACH
 is used. The upstream docs for it don't seem to have changed, but wesnoth
 isn't rebuilding today. gcc hasn't changed since the last successful
 build of Wesnoth, so it is likely to be due to the boost change.

There's also problem when building Qt apps with boost-1.48 due this bug: 
https://bugreports.qt.nokia.com/browse/QTBUG-22829 .

Regards,
Jan Kaluza
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning Slim

2011-06-09 Thread Jan Kaluža 
Hi,

I'm not using this package and I have not checked its state before 
taking the ownership (which was mistake). It doesn't work for users who 
upgraded from F14 to F15 and I wasn't able to find out why exactly it 
fails. There are also some bugs untouched for long time.

To sum it up, it is probably better to hand it over to someone else who 
has more time and actually still uses it.

Regards,
Jan Kaluza
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel