[EPEL-devel] A CenOS Stream package missing during EPEL9 build: unresponsive CentOS Stream @redhat maintainers

[Marcin Dulak]

Hi,

I have a bugzilla opened about a CenOS Stream package missing during EPEL9 
builds
https://bugzilla.redhat.com/show_bug.cgi?id=2182460, for over a month with no 
response.

Can something be done about this, apart from trying to reach the maintainers on 
their corporate emails?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Runtime failures with gfortran-12 on f36 at default (%optflags) compilation optimization levels

[Marcin Dulak]

Thanks for the %global macros.

How common in f36, and in general in fedora is the need for reducing the 
optimization levels? 
I don't have small examples to reproduce the failures, but both issues have a 
Dockerfile that can be used to compile the programs and trigger the failures 
(it takes 10 - 30 minutes). They include the original FTBFS bugzilla links too, 
in case they should be reassigned as gcc bugs instead.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Runtime failures with gfortran-12 on f36 at default (%optflags) compilation optimization levels

[Marcin Dulak]

I have two packages where a workaround of reducing the compilation optimization 
level avoids runtime failures:

1 Use of -O1 to avoid a numerical test error "zdot wrong"  
https://github.com/GlobalArrays/ga/issues/249

2 Use of -fno-lto to avoid segmentation faults 
https://gitlab.com/QEF/q-e/-/issues/460

It seems like the above problems are specific to gfortran-12 on f36.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Failure on the koji f36-rebuild target: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note...: No such file or directory

[Marcin Dulak]

Thanks, performing the builds inside of the %build section instead of %prep 
makes the "/builddir/build/BUILD/.package_note...: No such file or directory" 
error go away. I updated https://bugzilla.redhat.com/show_bug.cgi?id=2044028 
accordingly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Failure on the koji f36-rebuild target: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note...: No such file or directory

[Marcin Dulak]

Thanks for the link.

The linked issue mentions "package-notes-srpm-macros-0.4-11.fc36" 
https://bugzilla.redhat.com/show_bug.cgi?id=2043178#c18.

The above version is present now in my latest build of ga 
https://koji.fedoraproject.org/koji/taskinfo?taskID=81699099, but the 
"/usr/bin/ld: cannot open linker script file
/builddir/build/BUILD/.package_note-ga-5.7.2-8.fc36.x86_64.ld: No such file or 
directory
collect2: error: ld returned 1 exit status" error persist.

A workaround of setting "%undefine _package_note_file" in a spec file helps.
I opened another issue https://bugzilla.redhat.com/show_bug.cgi?id=2044028 in 
case the "No such file or directory" issue is different from 
https://bugzilla.redhat.com/show_bug.cgi?id=2043178.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Failure on the koji f36-rebuild target: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note...: No such file or directory

[Marcin Dulak]

Initially the ga package (https://src.fedoraproject.org/rpms/ga) failed during 
the f36 mass rebuild,
by failing on some numerical tests "zdot wrong".
The failed build is here 
http://koji.fedoraproject.org/koji/buildinfo?buildID=1882845

However, when trying to reproduce the failure on koji with `koji build --nowait 
--scratch --arch-override x86_64 f36-rebuild`
(see https://koji.fedoraproject.org/koji/taskinfo?taskID=8198) the 
compilation does not start now, due to an error
"checking whether the C compiler works... no".

This "checking whether the C compiler works... no" seems to appear also on 
other architectures and on rawhide,
for example on x86_64 
https://koji.fedoraproject.org/koji/taskinfo?taskID=81667977 aarch64 
https://koji.fedoraproject.org/koji/taskinfo?taskID=81667999
or i686 https://koji.fedoraproject.org/koji/taskinfo?taskID=81668008

The ga package still builds and passes tests on f35 
https://koji.fedoraproject.org/koji/taskinfo?taskID=8191

Further debugging the f36-rebuild x86_64 target on koji with `cat config.log`, 
shows (see https://koji.fedoraproject.org/koji/taskinfo?taskID=81670300)
```
...
configure:4773: checking for mpicc
configure:4789: found /usr/lib64/mpich/bin/mpicc
configure:4800: result: mpicc
configure:4831: checking for C compiler version
configure:4840: mpicc --version >&5
gcc (GCC) 12.0.1 20220118 (Red Hat 12.0.1-0)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:4851: $? = 0
configure:4840: mpicc -v >&5
mpicc for MPICH version 3.4.1
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap 
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin 
--enable-initfini-array 
--with-isl=/builddir/build/BUILD/gcc-12.0.1-20220118/obj-x86_64-redhat-linux/isl-install
 --enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet 
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux 
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220118 (Red Hat 12.0.1-0) (GCC) 
... rest of stderr output deleted ...
configure:4851: $? = 0
configure:4840: mpicc -V >&5
gcc: error: unrecognized command-line option '-V'
configure:4851: $? = 1
configure:4840: mpicc -qversion >&5
gcc: error: unrecognized command-line option '-qversion'; did you mean 
'--version'?
configure:4851: $? = 1
configure:4871: checking whether the C compiler works
configure:4893: mpicc  -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 
-Wl,-dT,/builddir/build/BUILD/.package_note-ga-5.7.2-8.fc36.x86_64.ld 
conftest.c -lscalapack -lflexiblas >&5
/usr/bin/ld: cannot open linker script file 
/builddir/build/BUILD/.package_note-ga-5.7.2-8.fc36.x86_64.ld: No such file or 
directory
collect2: error: ld returned 1 exit status
configure:4897: $? = 1
configure:4935: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Global Arrays (GA)"
| #define PACKAGE_TARNAME "ga"
| #define PACKAGE_VERSION "5.7.1"
| #define PACKAGE_STRING "Global Arrays (GA) 5.7.1"
| #define PACKAGE_BUGREPORT "hpcto...@pnl.gov"
| #define PACKAGE_URL "http://hpc.pnl.gov/globalarrays/;
| #define LINUX 1
| #define SYSV 1
| #define PACKAGE "ga"
| #define VERSION "5.7.1"
| #define MSG_COMMS_MPI 1
| #define ENABLE_PEIGS 0
| #define ENABLE_EISPACK 0
| #define ENABLE_PROFILING 0
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:4940: error: in `/builddir/build/BUILD/ga-5.7.2/ga-5.7.2-mpich':
configure:4942: error: C compiler cannot create executables
See `config.log' for more details
...
```
___
devel mailing list -- devel@lists.fedoraproject.org
To 

How is the list of emails used for "Email sent to" on bugzilla.redhat.com generated?

[Marcin Dulak]

I noticed several, surprising to me email addresses, listed under "Email sent 
to" when making changes to my bugzilla.redhat.com bugs.
For example this bug https://bugzilla.redhat.com/show_bug.cgi?id=1900680

The individual email recipients used for "Email sent to" are not included in 
the given bug "CC list", and the only other email in the bug settings seems to 
be "extras...@fedoraproject.org".
I don't see anybody "watching" the spec repository 
https://src.fedoraproject.org/rpms/nwchem.

The situation is similar to https://bugzilla.redhat.com/show_bug.cgi?id=680247, 
except my bug and comments are public.

How/why are those additional email addresses added?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Another libxc soname bump...

[Marcin Dulak]

FYI: elk developers have been informed about the upcoming libxc bugfix
release, and elk is tracked here
https://bugzilla.redhat.com/show_bug.cgi?id=1831479
GPAW is tracked here https://bugzilla.redhat.com/show_bug.cgi?id=1830675
I've orphaned exciting, since there was not much collaboration from the
developers.

On Fri, May 15, 2020 at 11:44 AM Susi Lehtola <
jussileht...@fedoraproject.org> wrote:

> On Fri, 15 May 2020 12:15:05 +0300
> Susi Lehtola  wrote:
> > Hello,
> >
> >
> > unfortunately there's going to be *another* soname bump to libxc.
> > Libxc 5 replaced the ancient "Fortran '90" interface with the Fortran
> > 2003 version based on iso_c_binding. However, this included
> > *renaming* the Fortran 2003 module and functions, which is obviously
> > inconvenient for downstream projects and has caused a lot of hassle.
> >
> > This change is reverted in the upcoming libxc release, resulting in
> > another soname bump, but a more backwards compatible API... It appears
> > that the Fortran codes elk and exciting have not yet been compiled
> > against libxc 5; the next release will be easier to compile against.
>
> Nevermind, there's not going to be a soname bump; a copy of the
> erroneously renamed library will also be shipped in the next release...
> the main point being that libxcf03 will be there as well and stay there.
> --
> Susi Lehtola
> Fedora Project Contributor
> jussileht...@fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning exciting

[Marcin Dulak]

https://apps.fedoraproject.org/packages/exciting

Have not received upstream response about build problems: 
https://bugzilla.redhat.com/show_bug.cgi?id=1741509
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning htmlcleaner

[Marcin Dulak]

https://apps.fedoraproject.org/packages/htmlcleaner

Have not maintained it for a time long enough.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Attempting to contact unresponsive maintainers: dkaspar flaper87

[Marcin Dulak]

Nobody took tcsh until now.
___
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: ga (global arrays) package maintainer needed

[Marcin Dulak]

What is the current policy about bundling in Fedora?

It turns out that the global arrays package, apart from being outdated, and no 
response from the maintainer has been compiled with incompatible options
to the ones required by nwchem: 
https://bugzilla.redhat.com/show_bug.cgi?id=1514542

If I don't receive any response I'll start bundling ga (in the sense of using 
the required ga version during the nwchem build).

Marcin
___
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/GV6AAI4DZOYFLBAZSE5YPVBZERKBJGKW/

orphaning openmx

[Marcin Dulak]

https://src.fedoraproject.org/rpms/openmx
No collaboration from developers requires constant adjusting of patches.
___
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/POQPJIW5NGZGZRI7RKPLBO7K64ROCGCZ/

ga (global arrays) package maintainer needed

[Marcin Dulak]

Hi,

I have a problem with an unmaintained https://src.fedoraproject.org/rpms/ga, a 
dependency for https://src.fedoraproject.org/rpms/nwchem.
Recently nwchem unbundled ga from its sources 
https://github.com/nwchemgit/nwchem/issues/28, but that requires a recent ga 
version, built
in a way that makes `${EXTERNAL_GA_PATH}/bin/ga-config` available.
ga seems unmaintaned https://bugzilla.redhat.com/show_bug.cgi?id=1432661, and 
therefore I'm looking for someone who can take it over.

I believe I'm not allowed to bundle ga in nwchem 
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries,
and in this case if ga (in Fedora and EPEL) does not follow closely the nwchem 
development cycle I'll need to retire nwchem.
ga seems to be used only as nwchem dependency on Fedora/EPEL as seen from 
`repoquery --whatrequires ga-openmpi` 

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

How to get qtpass RPM into EPEL7?

[Marcin Dulak]

Hi,

I would like qtpass is built for EPEL7, but the maintainer is not interested.
I provided a patch for EPEL7 build 
https://bugzilla.redhat.com/show_bug.cgi?id=1541439
How to proceed further?

Best regards,

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

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Marcin Dulak]

On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa  wrote:

> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>  wrote:
> >> I really do like this. There are only two issues I have with it:
> >>
> >> 1. This seems to mandate that all packages must be named by their
> >> import path. My golang package (snapd) is not, intentionally so. I
> >> don't want to change this.
> >>
> >> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> >> people who release Go code as tarballs (it's rare, but it happens).
> >> How do you deal with that?
> >
> > By not using the macros for packages not fitting the model?
> >
>
> The issue is that the new Go macros are tightly wound into the forge
> macros. I just want to be sure that we can leverage things like the
> dependency generators without all the other stuff.
>
> > I think this is very helpful especially when it's the common practice,
> > and I certainly won't blame anyone doing proper releases and not
> > just a git tag with github releases notes ;)
> >
> > Regarding naming, I think python packages must be prefixed with
> > python[23]- and can Provides: the upstream project name.


I'm not sure if this matters in this discussion but an example Python3 part
of a spec file https://fedoraproject.org/wiki/Packaging:Python
to accommodate also EPEL (which on CentOS7 prefixes Python3 packages with
python34 and not python3) would look like:

%package -n python%{python3_pkgversion}-%{pname}
%{?python_provide:%python_provide python%{python3_pkgversion}-%{pname}}

Macin


> On the
> > other hand we have packages like docker that are clearly named
> > after upstream's name, so I don't think that would be a problem for
> > snapd. (and maybe an exception needs to be granted?)
> >
>
> This rule only applies to Python packages that have modules that are
> designed to be imported by other Python code. Otherwise, this is not
> necessary.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

review swap

[Marcin Dulak]

Hi,

I have this small Python package for review 
https://bugzilla.redhat.com/show_bug.cgi?id=1398369
I'm not sure about the latest Python packaging guidelines (python34 vs python3 
on EL7/Fedora) concerning scripts,
so the review will require a couple of iterations.

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

review swap

[Marcin Dulak]

Hi,

I have this package waiting for review: 
https://bugzilla.redhat.com/show_bug.cgi?id=1394502

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

Re: Review swap: openmx

[Marcin Dulak]

Thanks, I take yours gil.

On Sun, Nov 8, 2015 at 3:41 PM, Marcin Dulak <marcin.du...@gmail.com> wrote:

> Hi,
>
> I have this review for exchange
> https://bugzilla.redhat.com/show_bug.cgi?id=1156086
>
> Best regards,
>
> Marcin
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review swap: openmx

[Marcin Dulak]

Hi,

I have this review for exchange
https://bugzilla.redhat.com/show_bug.cgi?id=1156086

Best regards,

Marcin
-- 
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: Removing packages that have broken dependencies in F21 tree

[Marcin Dulak]

On 11/13/2014 02:20 PM, Kalev Lember wrote:

Hi,

I would like to remove the packages that still have broken dependencies
in the F21 tree.

This is a followup to
https://lists.fedoraproject.org/pipermail/devel/2014-October/203411.html

It makes little sense to ship something that cannot even be installed.
We're about to enter the final freeze next week in order to wrap up F21;
after the gold release is done, fixes can no longer be pushed to the
base repo. This means that anything that shipped with broken
dependencies would stay that way in the base repo throughout the F21
lifetime.

To avoid that, I'll file a FESCo ticket next Monday to approve dropping
the following packages, unless they get fixed first:

audtty
authhub
deltacloud-core
django-recaptcha
dragonegg
edelib
fatrat
flush
gdesklet-SlideShow
gdesklets-citation
gedit-valencia
gofer
gorm
juffed
leiningen
libghemical
libopensync-plugin-irmc
ltsp
meshmagick
monodevelop-vala
netdisco
nwchem
i have submitted nwchem update: 
https://admin.fedoraproject.org/updates/nwchem-6.5.26243-13.fc21


Best regards,

Marcin

ocaml-pa-do
openslides
openvas-client
pootle
python-askbot-fedmsg
python-coffin
python-django-addons
python-django-longerusername
rubygem-linecache19
rubygem-rubigen
rubygem-ruby-debug-base19
sugar-tamtam
totpcgi
transifex
valabind
why
zyGrib

Please note that Fedora policies allow adding new packages in the 
updates repo, so even if something gets dropped now, it can always be 
fixed and shipped in the updates repo at a later date.




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

Self Introduction

[Marcin Dulak]

Hi,

Marcin Dulak: working with RedHat/Fedora systems for 6 years, and a 
Linux user for about 10.

Here is my fist package: https://bugzilla.redhat.com/show_bug.cgi?id=973084

I have packaged several software for internal use, mostly python and 
science oriented:

https://build.opensuse.org/project/show?project=home%3Adtufys

I'm interested in getting some of these packages into Fedora and EPEL 
(if needed),

and becoming co-maintainer of other packages, especially non-python ones,
so can learn a bit about other parts of Fedora.

Best regards,

Marcin







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