tags are not up to date now.
On Tue 27 Oct 2020 11:21:05 AM -04 James Cassell wrote:
> Latest still points to 32, but you can say 33 explicitly and get GA bits.
>
> On Tue, Oct 27, 2020, at 11:15 AM, Stanislav Ochotnicky wrote:
>> On Tue 27 Oct 2020 09:57:40 AM -04 Matthew Miller wrot
ignatures
[root@fb0f4ab6985f /]# cat /etc/fedora-release
Fedora release 32 (Thirty Two)
--
Stanislav Ochotnicky
Software Engineer, Red Hat Product Security DevOps
PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241
___
devel mailing list -- devel@lists
changing. But the module that contains them uses
different strategy that allows maintainers more flexibility. And there
does not have to be exact match between module/stream etc name and NVRs
of rpms inside as others have mentioned.
--
Stanislav Ochotnicky
Software Engineer, PnT DevOps - Br
t means no
"main rpm" will get created.
And explanation:
It's not about allowing something - if you are not packaging something
you installed in the buildroot then rpmbuild will yell. Either put it in
that python-swift package *or* do not put it in the buildroot.
--
Stanislav
echeck is a glorified grep
oslc (and https://pagure.io/muster) use proper algorithms and a
"database" of full license texts and headers to provide much better
matching accuracy.
--
Stanislav Ochotnicky
Business System Analyst, PnT DevOps - Brno
PGP: 7B087241
Red Hat Inc.
On Thu 25 Feb 2016 08:04:44 PM CET "Richard W.M. Jones"
wrote:
> On Thu, Feb 25, 2016 at 07:54:57PM +0100, Stanislav Ochotnicky wrote:
>> On Thu 25 Feb 2016 06:22:26 PM CET Kevin Fenzi wrote:
>> > On Thu, 25 Feb 2016 18:00:09 +0100
>> > Stanislav Ochotn
On Thu 25 Feb 2016 06:22:26 PM CET Kevin Fenzi wrote:
> On Thu, 25 Feb 2016 18:00:09 +0100
> Stanislav Ochotnicky wrote:
>
>> On Thu 25 Feb 2016 04:42:34 PM CET Kevin Fenzi wrote:
>> > On Thu, 25 Feb 2016 15:35:55 +
>> > "Richard W.M. Jones" wrote
e bug to get
>> rid of the unwanted group.
>
> I'll mail you privately. They closed my ticket wontfix. ;(
Well it wasn't exactly won't fix - seems like a misunderstanding/lost in
translation thing. I'll escalate and get it resolved ASAP
--
Stanislav Ochotnicky
Busin
ing like this?
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-/compose/metadata/
See the files in the directory for details, be aware the rpm one is huge
though :-)
--
Stanislav Ochotnicky
Business System Analyst, PnT DevOps PMO Team - Brno
PGP: 7B087241
Red Hat Inc.
changing it (I'm way too old to get involved in THAT again),
> just explaining where this particular offense in case of rpm probably
> originates from. Feel free to consider it as an apology for setting a
> bad example.
Meh, you are not the first nor the last. It's just that
ed of involving
Kubernetes or similar technologies.
--
Stanislav Ochotnicky
Business System Analyst, PnT DevOps PMO Team - Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailm
stream server.
> The proxy server could not handle the request POST /show_bug.cgi.
>
> Reason: Error reading from remote server
>
> Apache Server at bugzilla.redhat.com Port 443
>
>
> Ralf
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
&
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Cond
different from what we'd consider MIT in
Fedora? One difference I can see is that SPDX defines "canonical" text
of the license where Fedora lumps several texts[1] into 1 short name.
Without looking too much into SPDX license list - would some of the
licenses we currently consi
qa |grep -i fedora-review
> fedora-review-0.5.2-1.fc21.noarch
>
> [empateinfinito@localhost review]$ rpm -qa |grep -i mock
> mock-1.2.4-1.fc21.noarch
> [empateinfinito@localhost review]$
>
>
> I hope this info can be usefull,
>
> Regards
> --
> devel mailing lis
entation language).
Yes good idea. I worked on Java packages. Let's put Maven in minimal
buildroot. I am sure everyone will enjoy it.
Sorry for the sarcasm. Couldn't resist :-)
Seriously though what's a problem with listing your package's real build
requires?
--
Stanislav O
On Fri 24 Oct 2014 05:35:00 PM CEST Matthew Miller wrote:
> On Fri, Oct 24, 2014 at 04:56:20PM +0200, Stanislav Ochotnicky wrote:
>> Thought we should really switch to actually use dnf api instead. Things
>> get complicated for us when we want to support EL6 then...Maybe we shou
On Fri 24 Oct 2014 04:27:37 PM CEST Tim Lauridsen wrote:
> On Fri Oct 24 2014 at 4:01:20 PM Stanislav Ochotnicky <
> sochotni...@redhat.com> wrote:
>
>> On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:
>>
>> > Hi
>> >
>> &
C_2.2.5)(64bit)
libutil.so.1()(64bit)
libpython2.7.so.1.0()(64bit)
python-libs(x86-64) = 2.7.5-14.fc20
No idea why it's this way though.
--
Stanislav Ochotnicky
Business System Analyst, Hosted and Shared Services
PGP: 7B087241
Red Hat Inc. http://cz.redhat.c
ly, you would be the only one subscribed to it and
> thus the question is simple(r) to answer.
> But for the case of an existing list, I wonder if we can do better than what
> you
> describe.
> @Kevin any thoughts on this?
This is normally done by sending an email to
bugzilla-reque.
Fedora is a community
>> project.
>
> And much like anyone else, people come and go. The difference is that here,
> when
> they leave, we know about it before emails start to bounce.
Indeed. I have forwarded this thread to colleagues working on processes
when people are leavi
maintains the list of packages based on the
>> finished package reviews, why are you trying to add a package?
>>
>>
>> Dan
> because that a package is required (gstreamer1-rtsp-server version
> =>1.4.0) for build gnome-dvb-daemon version 0.2.90 . Ha
ing devconf but basically this is
the best thing since sliced bread. Thank you Ralph, Pierre & whoever else
was involved in making it a reality.
It's one of those things that just makes me thing: Why the hell haven't
we done this ages ago? :-)
--
Stanislav Ochotnicky
Business Syste
talking about doing whole package reviews in
fossology, just hooking up the license checking part there.
It's likely we'd need to clean up fossology a bit to be universally
usable for this use case, but it should be doable. Opinions,
suggestions...all welcome.
[1] http://fossology.org/
--
ches
> -m64 -mtune=generic -c -o helpparse.o helpparse.c
> helpparse.c:18:20: fatal error: config.h: No such file or directory
> #include "config.h"
Another (relatively common) problem is the parallelization (-j4)
tripping the makefile up. I.e. dependencies for some targets are
i
l dnf-utils containing ported versions of these tools.
Unless you aim to provide dnf-compatible tools from yum-utils please
rename the project.
(not a DNF dev, but it seems quite obvious this is a bad idea long-term)
--
Stanislav Ochotnicky
Software Engineer - Developer
ython-webdav-library
* freemind
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
pgpos11L87hEO.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
On Mon 14 Apr 2014 10:24:46 AM CEST Mat Booth wrote:
> On 14 April 2014 08:44, Stanislav Ochotnicky wrote:
>
>> On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
>> > [snip] I know little to nothing about java bindings so if it is
>> > substantial work I will ju
tead
of 0, but of course it doesn't hurt anything...
pgp5kMEDIZEET.pgp
Description: PGP signature
>From ef5fd12e46974858b25c2aa032e943514a0bf921 Mon Sep 17 00:00:00 2001
From: Stanislav Ochotnicky
Date: Mon, 14 Apr 2014 09:42:19 +0200
Subject: [PATCH] Use OpenJDK instead of GCJ for java bind
internal implementation
details or some *really* weird approaches.
For building, you can still generate code for older JVMs with JDK8. Of
course those JVMs will likely not be able to run at least part of our
Java stack but that's another thing...
If Atlassian suite breaks: it's most like
rofile package which doesn't
receive security updates upstream and there is nobody in Fedora willing
and capable of doing that.
What's the big deal with using '--target 1.7' anyway? That covers 99% of
use cases, and any possible problems will have to be caught by CI
runni
t;> Release Notes
>> Javadoc subpackages have been made optional.
> "Made optional" is true from the packaging guidelines' point of view; for
> the users, some subpackages have simply been *removed*, and there's nothing
> optional about that.
You have a poi
body actually
noticed. We also ship API for end-user applications (freemind) which
really *doesn't* make sense.
This change really has two goals:
* Give maintainers option to decide if javadocs make sense (from their
POV) for their package
* Communicate this change to users
--
Stanislav Ochot
seless on servers or
other headless machines).
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
pgpbAUvYY9l2j.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.
On Wed 05 Mar 2014 03:57:17 PM CET Alexander Todorov wrote:
> На 5.03.2014 14:12, Stanislav Ochotnicky написа:
>>
>> Why are you filing bugs (with patches) you don't understand then?
>
> This is a foolish statement to make without knowing what I do and don't know
n their
respective SIG what's happening there.
> A small comment makes it much more clear and straight forward.
I want my packages to run tests. If there are tests upstream but I am
not running them, sure there should be a comment or even better a
FutureFeature bug to fix the test
On Wed 26 Feb 2014 01:41:36 PM CET Colin Walters wrote:
> On Wed, Feb 26, 2014 at 5:01 AM, Stanislav Ochotnicky
> wrote:
>>
>> Because unit tests are designed to be run as part of the build
>> process. It's not impossible to run them *after* the build, but good
&g
work reliably across all packages without manual work.
As I see it:
* %check (or equivalent) is for unit testing
* taskotron (or equivalent) is integration testing
Each has its own value
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc.
Ville Skyttä writes:
> On Tue, Feb 25, 2014 at 10:59 AM, Stanislav Ochotnicky
> wrote:
>>
>> Since javadoc subpackages put files in /usr/share/javadoc they must
>> require package that provides this directory.
>
> In my opinion all javadocs should be crosslink
ackaging:Guidelines#File_and_Directory_Ownership
Quoting:
"Packages must own all directories they put files in, except for:[snip]"
Since javadoc subpackages put files in /usr/share/javadoc they must
require package that provides this directory. I guess it wouldn't hurt
to repeat t
ails. We try to point out
potential improvements/fixes and sometimes the suggestions might be
incorrect. For example if you wanted to keep the same package on EPEL6
and Fedora where EPEL6 wouldn't generate the jpackage-utils requires.
Hope this clears up everything, if not drop by #fedora-j
aybe out-dated localization. I can see the text at welcome screen in
> cs_CZ.UTF-8 locale in Fedora, although there is nothing like that in
> en_US.UTF-8 locale.
It's actually a bit more fun. Part of welcome screen is randomized :-)
Alternating text:
1. Become a registered Vim user!
2.
fixed...
Generally filing those 42 (yay, what a nice number) bugs would have been
better IMO, but if you are willing to re-run that repoquery in a few
months and file bugs for remaining packages I see no harm.
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat
Ville Skyttä writes:
> sochotni javapackages-tools java-sig,mizdebsk,msimacek,msrb
Fixed in upstream git, will be in next release
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
pgpf3tZnV3NGT.
uraging for us. There are *a ton* of compilation
failures, mostly in javadocs.
I am not saying this is not doable, but it will involve *a lot* of
work in any case. One blasphemous suggestion was to just get rid of
javadoc generation :-)
--
Stanislav Ochotnicky
Software Engineer - Developer Expe
sed the dnf-0.4.12-1 will be
higher than those older nightlies. By that time the nightlies should
have higher version so no problems there either.
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.
gt;= 2.0" so the resolver pull in Package B.
Now you have both installed even though only Package B is needed.
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
pgp9SmqDrr7UP.pgp
Description: PGP signature
ill likely depend on EOLed Fedora
repos. Do we keep *those* around? I guess the answer will be different
for each mirror. Some will keep those repos for longer, some shorter.
But as you say, source RPMs might be nice to have at least.
--
Stanislav Ochotnicky
Software Engineer - D
tem for binaries that would be broken by updating to
that repo. With my Fedora hat on, I personally don't care much about software
that is not packaged (at least in RPM if not Fedora)
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc.
ill make the problem worse, not better
> We do not want to get to the state when packages being committed are
> automatically being built in koji (using git hooks). Because what you
> recommend here effectively leads to this "happy" ending - you might
> unintentionally s
[1] https://admin.fedoraproject.org/updates/FEDORA-2013-23402 (F18)
[2] https://admin.fedoraproject.org/updates/FEDORA-2013-23423 (F19)
[3] https://admin.fedoraproject.org/updates/FEDORA-2013-23340 (F20)
[4] https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12371 (EL6)
--
Stanislav Ochotn
t;
> > Please don't.
>
> Sorry about the unintended breakage. I'm pushing a fix back to 5.2 in
> rawhide now. In the future, how would you like to coordinate future papi
> releases when the so version does need to be bumped?
Generally, following Updates Policy[1
16 spike
16 omajid
16 huwang
14 caolanm
13 mmorsi
13 madsa
11 akurtakov
9 ricardo
8 fnasser
7 pahuang
Funnily enough none of these people complain about current change proposal. And
these people own ~550 packages out of those 800.
e to say if your software uses them due to nature of Java/JVM
itself. There's too many ways to use parts of JVM. Interfaces, intermediate
libraries, various classloading tricks.
Nobody is going to write a reliable detection if it should be headless requires
or not. Much less integrate it into all di
to mass filing bug,
waiting a bit for maintainers to either look themselves or fix it up
automatically. *That* kind of input was constructive and helped flesh out the
process for rolling out the change for users/maintainers.
--
Stanislav Ochotnicky
Software Engineer - Developer Experienc
this. Otherwise autorequires generator is going
to
waste a lot of developer time in by doing bytecode analysis on each single class
file.
Regardless..what I meant to say: Nobody - as in I don't see anyone jumping up
and down and volunteering to do the work and maintain the code, p
se packaging from getting in in the
first place (or have a comment in the spec file why it's needed - if it's not
obvious)
[1] https://bugzilla.redhat.com/show_bug.cgi?id=FE-JAVASIG
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc.
Quoting Nicolas Mailhot (2013-11-20 16:20:34)
>
> Le Mer 20 novembre 2013 15:04, Stanislav Ochotnicky a écrit :
>
> > Can we actually list good reasons to have a metapackage or x11 subpackage
> > that
> > would outweight the inevitable disadvantages? If you *reall
y change to either headless or x11
version. I am not entirely sure what we'd achieve with this though (besides
making sure someone has looked at the spec and modified it). If we migrate all
packages to either java-x11 or java-headless those RPMs lose compatibility with
older Fedoras, RHELs et
Quoting Toshio Kuratomi (2013-11-19 10:49:57)
> On Tue, Nov 19, 2013 at 09:29:40AM +0100, Stanislav Ochotnicky wrote:
> > Quoting Toshio Kuratomi (2013-11-18 17:08:12)
> > > On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky"
> > > wrote:
> > > >
>
Quoting Jerry James (2013-11-18 16:54:28)
> On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky
> wrote:
> > I believe OpenJDK maintainers will agree that automatically detecting if
> > java or
> > java-headless is supposed to be required is not really feasible. There&
Quoting Toshio Kuratomi (2013-11-18 17:08:12)
> On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky"
> wrote:
> >
> > Quoting Jaroslav Reznik (2013-11-15 12:28:11)
> > > * (optional) Mass-change spec files that have "Requires: java" to
> "Requ
Quoting Ville Skyttä (2013-11-15 18:30:33)
> On Fri, Nov 15, 2013 at 3:22 PM, Stanislav Ochotnicky
> wrote:
> >> http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b
> >
> > Ugh. Why did you have to do that?
>
>
ge
alone
However I am worried some maintainers will close those bugs without even
glancing at their packages. And it takes just one screwed up package which pulls
in full java and we're back at square one. I am open to suggestions on how to
allow maintainers to opt-out if they feel conf
Quoting Ville Skyttä (2013-11-15 14:11:37)
> On Fri, Nov 15, 2013 at 2:09 PM, Stanislav Ochotnicky
> wrote:
> > Quoting Jaroslav Reznik (2013-11-15 12:28:11)
> >> * (optional) Mass-change spec files that have "Requires: java" to
> >> "Requires:
&
e similar change when we migrated packages from "BuildRequires: maven"
to "BuildRequires: maven-local" and it worked without issues. It will save
precious developer/rel-eng time and ultimately will only break minimal amount of
packages (with simple workarounds and fixes).
message appears whenever there is a change in ssh host key for given
address. On Fedora as well. If you can't reproduce, you didn't change the
host key or you are really connecting to a different host
--
Stanislav Ochotnicky
Software Engineer - Deve
y are dependencies of following packages:
* Tomcat
* Maven
* Eclipse
* WildFly
* (new) Big Data SIG stuff
* and of course a few more apps here and there
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc.
all open source to avoid
> restrictions imposed by their government? The first is a joke, the
> second is high enough to keep this restriction in the same contempt
> as the Syrian government's ban on "proxy".
You are walking on thin ice and should stop immediately
"You may
Quoting Florian Weimer (2013-10-28 14:42:47)
> On 10/24/2013 04:19 PM, Stanislav Ochotnicky wrote:
> > Quoting Fernando Nasser (2013-10-24 16:06:27)
> >> Also, will this change be ackported into the Java packages of RHEL_5 and
> >> RHEL-6?
> >
> > Doesn&#
them).
Well then you can still require "java" and not make use of this split in your
products. You will be pulling in a lot of unneeded cruft but it's going to work
just like it has worked for years...
--
Stanislav Ochotnicky
Software Engineer - Developer
Btw - the update above is now somehow stuck - it not in testing, nor in
> updates. Maybe the relengs
> can help.
If you need to get in touch with rel-engs file a ticket[1], don't CC their ML or
it's going to get lost
[1] https://fedorahosted.org/rel-eng/
--
Stanislav Ochot
tained by people who are actually using them
in some application. But it's up to you after all said and done if you want to
keep maintaining it.
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz
quires
> mvn(org.bouncycastle:bcprov-jdk16:1.46)
> tika-parsers-1.4-2.fc21.noarch requires
> mvn(org.bouncycastle:bcmail-jdk16:1.46)
> Please resolve this as soon as possible.
This is a bug in bouncycastle, it should not have versioned jar symlinks unless
it's a compat pack
on't screw up too badly :-) Now I am wondering how dnf is going to
approach testing, regressions etc. It sure would be nice to have a big
testuite for such a component.
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc.
ython-urlgrabber.git/
[2]
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Post-Release_packages
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
pecific action taken by specific Red Hat employees: point it out! Do not
be generic or people will most likely write you off as another troll.
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
deve
cking desktop-file-validate w bash variabLe (#223).
+ Handle upstream rpm bug making %check test in ruby hard (#225).
- Fix URL for gtk-query-immodules (bz 980308).
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. h
r
> > - jibx
> > - xpp3
> >
> Ok, so I am going to orphan the remaining packages:
> - SimplyHTML
> - freemind
>
> Perhaps someone is willing to pick them up.
I don't have that much time to spend on them at the moment, but I took
freemind and simplyHTML. Co-mainta
some commands in
an SCL within spec file:
%{?scl:scl enable %{scl} "}
# this is a shell
command 1
command 2
...
%{?scl:"}
This way you can use the same spec file as SCL and out of SCL.
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc.
rsioned files (also
discovered by f-r). Some of them are files that should be in -devel
subpackage, some are "plugins" that should be in private subdirectory...and
some are weird exceptions that no tool can automatically know about.
--
Stanislav Ochotnicky
Software Engineer -
df
application/pdf
And then you can do:
$ xdg-mime query default application/pdf
evince.desktop
xdg-mime can be used to change the default as well. Then it just depends on
applications if they honor xdg or not.
--
Stanislav Ochotnicky
Software Engineer - Develop
ject.org/updates/FEDORA-2013-9207/xmvn-0.5.0-2.fc19
[2] http://pkgs.fedoraproject.org/cgit/xmvn.git/tree/xmvn.spec#n117
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
->orphan, orphan->B correct?
I would probably say daily reports would be overkill. Weekly could be perhaps
too long? If I think about it I'd probably invent some crazy complicated stuff
so...just pick some schedule and be prepared to change if people complain :-)
--
Stanislav Ochotnicky
dmin.fedoraproject.org/updates/fedora-review-0.4.1-1.el6
Authors of changes for this release (commits):
- Jakub Filak (1)
- Ralph Bean (1)
- Alec Leamas (15)
- Stanislav Ochotnicky (23 because of Java stuff and merge commits :-))
Enjoy,
--
Stanislav Ochotnicky
Software Engineer - Developer Exp
Quoting Dan Mashal (2013-03-12 18:11:06)
> On Tue, Mar 12, 2013 at 10:06 AM, yersinia wrote:
> > On Tue, Mar 12, 2013 at 6:05 PM, devzero2000 wrote:
> >>
> >> On Tue, Mar 12, 2013 at 4:28 PM, Stanislav Ochotnicky
> >> wrote:
> >>>
> >>&
Quoting Kevin Fenzi (2013-03-12 15:53:56)
> On Tue, 12 Mar 2013 13:49:22 +0100
> Stanislav Ochotnicky wrote:
>
> > Tomcat6 package in Fedora is old, has several problematic bugs
> > (including 4 security) and most importantly there's a replacement:
> > tomcat-7.x
show_bug.cgi?id=819505
[4]
http://fedoraproject.org/wiki/Package_maintainer_policy#What_to_do_if_a_maintainer_is_absent
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://www.redhat.com
--
devel mailing list
devel@list
your
BuildRequires.
[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=400964
--
Stanislav Ochotnicky
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: signature
--
devel mailing list
devel
I could file those bugs myself, but I don't want to step on
anyone's toes :-)
[1] https://fedorahosted.org/rel-eng/ticket/5474
--
Stanislav Ochotnicky
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
signa
; Will do. I'm currently packaging a tonne of deps for buddycloud, so
> many review swaps may be imminent!
Ah, buddycloud in Fedora? Cool. I'll have to try it out one day :-)
--
Stanislav Ochotnicky
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
eamer owners as well.
--
Stanislav Ochotnicky
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/ma
Quoting Stephen Gallagher (2013-02-04 16:26:40)
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon 04 Feb 2013 04:56:23 AM EST, Stanislav Ochotnicky wrote:
> > Now that I have your attention...
> >
> > Fedora Maven package is currently a mix of upstream rel
row/Wednesday so that F19 is even more awesome :-) Is there anyone who
feels strongly against this change? I realize this is very short-notice, but
I believe disruption this change will cause is nil.
--
Stanislav Ochotnicky
Software Engineer - Base Operating Systems Brno
PGP: 7B08724
elines update doesn't look
> like it will be too hard or controversial.
Yes that is part of the plan. I just need to think of nice way to do it so we
don't create unnecessary mess of current guidelines and allow for transition
period. I don't want to force anyone to migrate who i
Quoting Bill Nottingham (2013-01-28 20:51:04)
> Stanislav Ochotnicky (sochotni...@redhat.com) said:
> > > I would assume that, even with approval, there's no way to stage these
> > > changes before the mass rebuild?
> >
> > There's too many packag
Quoting Bill Nottingham (2013-01-28 20:21:21)
> Jaroslav Reznik (jrez...@redhat.com) said:
> > = Features/XMvn =
> > https://fedoraproject.org/wiki/Features/XMvn
> >
> > Feature owner(s): Stanislav Ochotnicky
> >
> > Introduce new Maven packaging too
ry so he
can continue doing fast-forward merges again. I've cross-merged branches so that
they are now again on the same hash. Content of all branches (f16+) was the same
so they were all without conflicts.
For future, please do everything in master first :-)
Enjoy,
--
Stanis
change at all and only
changes if there are good reasons for it -- so no "hey, there is a new
version, it builds, let's ship it" mentality.
So I'd say: don't rebase fop at all. It's against the guidelines in the first
place
[1]
http://fedoraproject.o
venting of wheel (tens of XML libraries still being used)
3. Going backwards - gradle build system which takes worst things from ant,
and scons and combines them in one ugly package
I am quite optimistic though,
--
Stanislav Ochotnicky
Software Engineer - Base Oper
1 - 100 of 208 matches
Mail list logo
