Re: List of long term FTBFS packages to be retired in August

[Till Hofmann]

Hi,

On 6/28/23 09:43, Miro Hrončok wrote:


If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval 
for that.


If you see a package that can be rebuilt, please do so. 



openni is now fixed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=102844216

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

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Till Hofmann]

On 6/16/23 09:47, Miro Hrončok wrote:

On 16. 06. 23 9:41, Bastien Nocera wrote:
Scolding people that haven't seen your original message for 
limitations in the build system isn't nice.


Apologies for not being nice enough. However, we need to notify the 
folks who do that and ask them to stop, because as you say, the system 
is not perfect.


If you have specific suggestions, please speak up.


Just an idea: If you also directly send the email to the package 
maintainers ( via -maintain...@fedoraproject.org ) of all 
affected packages, the chance of missing the email may be much lower 
(this would certainly be the case for me).


That would be a lot of people in the initial email, but if you do that 
at least in the follow-up where you mention the packages that were 
rebuilt on accident, you could CC the affected maintainers.


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

Re: libdc1394 soname bump

[Till Hofmann]

Hi all,

On 6/5/23 23:13, Till Hofmann wrote:

Hi all,

I have updated libdc1394 to 2.2.7, which bumps the soname to 
libdc1394.so.26. I created the side tag f39-build-side-68587 and built 
the updated libdc1394 in the side tag.


If my query was correct, the following packages need to be rebuilt:
ffmpeg
libdc1394
mrpt
opencv
player
vxl


ffmpeg and vxl have already been rebuilt. I can rebuild player and mrpt, 
but they both require opencv, which has not been rebuilt yet.


Could a proven packager rebuild opencv in side tag f39-build-side-68587?

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

libdc1394 soname bump

[Till Hofmann]

Hi all,

I have updated libdc1394 to 2.2.7, which bumps the soname to 
libdc1394.so.26. I created the side tag f39-build-side-68587 and built 
the updated libdc1394 in the side tag.


If my query was correct, the following packages need to be rebuilt:
ffmpeg
libdc1394
mrpt
opencv
player
vxl

You can rebuild your packages with
fedpkg build --target=f39-build-side-68587

I'll merge the side tag after 7 days.

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

How to build two flavors of the same package?

[Till Hofmann]

Hi all,

Someone (rightfully) suggested that we should build glfw twice, once 
with wayland support and once without:

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

Is there any best practice how to build the same package in two 
different flavors, in this case cmake-based? I vaguely remember seeing a 
spec file that did that, but I don't remember where.


Thanks for any pointers!

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

Review swaps for 3 nagios plugins

[Till Hofmann]

Hi all,

I'm looking for reviews or review swaps for 3 nagios plugins:

python-nagios-plugins-check_systemd
https://bugzilla.redhat.com/show_bug.cgi?id=2082886

nagios-plugins-check_ssl_cert
https://bugzilla.redhat.com/show_bug.cgi?id=2131602

nagios-plugins-check_newest_file_age
https://bugzilla.redhat.com/show_bug.cgi?id=2131603

All those packages are trivial to review. I'd be happy to review 
packages in exchange!


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

Orphaning rofi

[Till Hofmann]

Hi all,

I've just orphaned rofi [1], as I don't use it anymore and use wofi instead.

The package is in a good shape, Dan (CCed) has already taken care of it 
in the past.


Dan, please take the package if you want! If not, everyone else feel 
free to take it!


Kind regards,
Till

[1] https://src.fedoraproject.org/rpms/rofi
___
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

librealsense soname bump 2.39

[Till Hofmann]

Hi all,

I'm updating librealsense to 2.39.0, which bumps the soname to 2.39. 
I'll take care of rebuilding its only dependency (fawkes).


Kind regards,
Till
___
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

log4cxx soname bump

[Till Hofmann]

Hi all,

I'll upgrade log4cxx to 0.11.0, which bumps the soname.

The only dependency is fawkes, which I will rebuild.

Kind regards,
Till
___
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: fawkes

[Till Hofmann]

On 10/11/20 1:51 PM, Till Hofmann wrote:



On 10/11/20 1:56 AM, Rich Mattes wrote:

On 10/10/20 5:27 PM, Till Hofmann wrote:



On 10/10/20 6:24 PM, Kevin Fenzi wrote:

On Sat, Oct 10, 2020 at 10:59:12AM +0200, Till Hofmann wrote:



On 10/10/20 10:54 AM, Till Hofmann wrote:



On 10/9/20 11:46 PM, Till Hofmann wrote:



On 10/9/20 9:19 PM, Kevin Fenzi wrote:




I think this might be that we need a newer ignition-msgs package?
Or something in gazebo?


I think it's the other way around: ignition-msgs needs protobuf 3.13
because that contains a patch that renamed 
AuxillaryParseTableField to

AuxiliaryParseTableField:
https://github.com/protocolbuffers/protobuf/commit/2ae7cf0e03c3469973e592e812565e4ee2470e0b 




After some digging: This commit is in 3.12.3 but not in 3.12.4. I 
guess
they noticed this requires a rebuild of dependent packages and 
they thus
reverted it. Gazebo is also currently FTBFS with the same error 
message.
After rebuilding ignition-msgs, I was able to rebuild gazebo and 
fawkes.


I'm pushing my changes and I'll push updates soon.


Awesome. We can propose the update as a Freeze break to get robotics
working. ;)


Now I'm hitting:
fatal: repository 
'https://src.fedoraproject.org/tmp/ignition-msgs.git/'

not found
https://koji.fedoraproject.org/koji/taskinfo?taskID=53134273

Not sure what's going on, can somebody help? Am I missing 
permissions to

build? I was able to push.


weird. The /tmp/ in there is completely wrong... it should be /rpms/

did you just do 'fedpkg build' ? or something else?
Any odd changes you made to fedpkg there?

If you like I can try it from here...



I found the issue, I had a second git remote that was something 
ending in /tmp/ignition-msgs, so it expected this to be the path. 
Funny bug. Anyway, after changing the remote tracking branch, it 
worked and building now!


Till


Thanks for working through all of this.  I got the buildroot overrides 
in place to rebuild ignition-transport and gazebo against 
ignition-msgs, gazebo is currently building.  Once it's done I'll 
submit a buildroot override so fawkes can be rebuilt in f33.




Thank you! Yeah I'd forgotten the buildroot override. I saw that you 
created one for gazebo already, so I just triggered a new build for fawkes:

https://koji.fedoraproject.org/koji/taskinfo?taskID=53208800



The build succeeded, here is the update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-10d819f69d

Please give karma if you can!

Kind regards,
Till
___
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: fawkes

[Till Hofmann]

On 10/11/20 1:56 AM, Rich Mattes wrote:

On 10/10/20 5:27 PM, Till Hofmann wrote:



On 10/10/20 6:24 PM, Kevin Fenzi wrote:

On Sat, Oct 10, 2020 at 10:59:12AM +0200, Till Hofmann wrote:



On 10/10/20 10:54 AM, Till Hofmann wrote:



On 10/9/20 11:46 PM, Till Hofmann wrote:



On 10/9/20 9:19 PM, Kevin Fenzi wrote:




I think this might be that we need a newer ignition-msgs package?
Or something in gazebo?


I think it's the other way around: ignition-msgs needs protobuf 3.13
because that contains a patch that renamed 
AuxillaryParseTableField to

AuxiliaryParseTableField:
https://github.com/protocolbuffers/protobuf/commit/2ae7cf0e03c3469973e592e812565e4ee2470e0b 




After some digging: This commit is in 3.12.3 but not in 3.12.4. I 
guess
they noticed this requires a rebuild of dependent packages and they 
thus
reverted it. Gazebo is also currently FTBFS with the same error 
message.
After rebuilding ignition-msgs, I was able to rebuild gazebo and 
fawkes.


I'm pushing my changes and I'll push updates soon.


Awesome. We can propose the update as a Freeze break to get robotics
working. ;)


Now I'm hitting:
fatal: repository 
'https://src.fedoraproject.org/tmp/ignition-msgs.git/'

not found
https://koji.fedoraproject.org/koji/taskinfo?taskID=53134273

Not sure what's going on, can somebody help? Am I missing 
permissions to

build? I was able to push.


weird. The /tmp/ in there is completely wrong... it should be /rpms/

did you just do 'fedpkg build' ? or something else?
Any odd changes you made to fedpkg there?

If you like I can try it from here...



I found the issue, I had a second git remote that was something ending 
in /tmp/ignition-msgs, so it expected this to be the path. Funny bug. 
Anyway, after changing the remote tracking branch, it worked and 
building now!


Till


Thanks for working through all of this.  I got the buildroot overrides 
in place to rebuild ignition-transport and gazebo against ignition-msgs, 
gazebo is currently building.  Once it's done I'll submit a buildroot 
override so fawkes can be rebuilt in f33.




Thank you! Yeah I'd forgotten the buildroot override. I saw that you 
created one for gazebo already, so I just triggered a new build for fawkes:

https://koji.fedoraproject.org/koji/taskinfo?taskID=53208800

Let's see how it goes!

Till
___
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: fawkes

[Till Hofmann]

On 10/10/20 6:24 PM, Kevin Fenzi wrote:

On Sat, Oct 10, 2020 at 10:59:12AM +0200, Till Hofmann wrote:



On 10/10/20 10:54 AM, Till Hofmann wrote:



On 10/9/20 11:46 PM, Till Hofmann wrote:



On 10/9/20 9:19 PM, Kevin Fenzi wrote:




I think this might be that we need a newer ignition-msgs package?
Or something in gazebo?


I think it's the other way around: ignition-msgs needs protobuf 3.13
because that contains a patch that renamed AuxillaryParseTableField to
AuxiliaryParseTableField:
https://github.com/protocolbuffers/protobuf/commit/2ae7cf0e03c3469973e592e812565e4ee2470e0b



After some digging: This commit is in 3.12.3 but not in 3.12.4. I guess
they noticed this requires a rebuild of dependent packages and they thus
reverted it. Gazebo is also currently FTBFS with the same error message.
After rebuilding ignition-msgs, I was able to rebuild gazebo and fawkes.

I'm pushing my changes and I'll push updates soon.


Awesome. We can propose the update as a Freeze break to get robotics
working. ;)


Now I'm hitting:
fatal: repository 'https://src.fedoraproject.org/tmp/ignition-msgs.git/'
not found
https://koji.fedoraproject.org/koji/taskinfo?taskID=53134273

Not sure what's going on, can somebody help? Am I missing permissions to
build? I was able to push.


weird. The /tmp/ in there is completely wrong... it should be /rpms/

did you just do 'fedpkg build' ? or something else?
Any odd changes you made to fedpkg there?

If you like I can try it from here...



I found the issue, I had a second git remote that was something ending 
in /tmp/ignition-msgs, so it expected this to be the path. Funny bug. 
Anyway, after changing the remote tracking branch, it worked and 
building now!


Till
___
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: fawkes

[Till Hofmann]

On 10/10/20 10:54 AM, Till Hofmann wrote:
> 
> 
> On 10/9/20 11:46 PM, Till Hofmann wrote:
> 
>>
>> On 10/9/20 9:19 PM, Kevin Fenzi wrote:
> 
>>>
>>> I think this might be that we need a newer ignition-msgs package? 
>>> Or something in gazebo?
>>
>> I think it's the other way around: ignition-msgs needs protobuf 3.13
>> because that contains a patch that renamed AuxillaryParseTableField to
>> AuxiliaryParseTableField:
>> https://github.com/protocolbuffers/protobuf/commit/2ae7cf0e03c3469973e592e812565e4ee2470e0b
> 
> 
> After some digging: This commit is in 3.12.3 but not in 3.12.4. I guess
> they noticed this requires a rebuild of dependent packages and they thus
> reverted it. Gazebo is also currently FTBFS with the same error message.
> After rebuilding ignition-msgs, I was able to rebuild gazebo and fawkes.
> 
> I'm pushing my changes and I'll push updates soon.
> 


Now I'm hitting:
fatal: repository 'https://src.fedoraproject.org/tmp/ignition-msgs.git/'
not found
https://koji.fedoraproject.org/koji/taskinfo?taskID=53134273

Not sure what's going on, can somebody help? Am I missing permissions to
build? I was able to push.


Kind regards,
Till
___
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: fawkes

[Till Hofmann]

On 10/9/20 11:46 PM, Till Hofmann wrote:

> 
> On 10/9/20 9:19 PM, Kevin Fenzi wrote:

>>
>> I think this might be that we need a newer ignition-msgs package? 
>> Or something in gazebo?
> 
> I think it's the other way around: ignition-msgs needs protobuf 3.13
> because that contains a patch that renamed AuxillaryParseTableField to
> AuxiliaryParseTableField:
> https://github.com/protocolbuffers/protobuf/commit/2ae7cf0e03c3469973e592e812565e4ee2470e0b


After some digging: This commit is in 3.12.3 but not in 3.12.4. I guess
they noticed this requires a rebuild of dependent packages and they thus
reverted it. Gazebo is also currently FTBFS with the same error message.
After rebuilding ignition-msgs, I was able to rebuild gazebo and fawkes.

I'm pushing my changes and I'll push updates soon.

I guess this issue could also occur with other packages depending on
protobuf, but I'll stop here.

Kind regards,
Till
___
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: fawkes

[Till Hofmann]

Hi Kevin,


On 10/9/20 9:19 PM, Kevin Fenzi wrote:
> Hey folks. 
> 
> The fawkes package FTBFS and is not installable in F33/rawhide. 
> This breaks the robotics spin compose, and since it's the _last_ failing
> thing in f33 composes, I'd love to fix it. :) 
> 
> We don't have a listed post of contact for the robotics spin. :( 
> If we did perhaps we could just remove fawkes for now and fix it that
> way? Or is it too essential to the spin? I don't know. ;(
> 
> So, I went part way down the rabbit hole, and I wonder if someone else
> can figure out the rest. 

Thanks for looking into this!

Rawhide should hopefully build now (it succeeded locally):
https://koji.fedoraproject.org/koji/taskinfo?taskID=53107361

> 
> First we need: 
> https://patch-diff.githubusercontent.com/raw/fawkesrobotics/fawkes/pull/228.patch
> to fix the boost placeholder change in the recent boost update. 
> 
> Then, 
> https://github.com/fawkesrobotics/fawkes/compare/tviehmann/microhttpd-temp-fix.patch
> gets it past the updated microhttpd that we have. 
> 
> But then it hits:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=53038092
> 
> ...
>  [PLUGIN] src/plugins/clips-navgraph/: plugins/clips-navgraph
> <-- Leaving src/plugins/gazebo/msgs
> In file included from 
> /usr/include/ignition/msgs1/ignition/msgs/header.pb.h:35,
>  from /usr/include/ignition/msgs1/ignition/msgs/color.pb.h:35,
>  from /usr/include/gazebo-10/gazebo/msgs/msgs.hh:32,
>  from 
> /usr/include/gazebo-10/gazebo/transport/TopicManager.hh:30,
>  from /usr/include/gazebo-10/gazebo/transport/Node.hh:32,
>  from 
> /builddir/build/BUILD/fawkes-1.3.0/src/plugins/gazebo/aspect/gazebo.h:30,
>  from 
> /builddir/build/BUILD/fawkes-1.3.0/src/plugins/gazebo/aspect/gazebo_inifin.h:28,
>  from 
> /builddir/build/BUILD/fawkes-1.3.0/src/plugins/gazebo/aspect/gazebo_inifin.cpp:25:
> /usr/include/ignition/msgs1/ignition/msgs/time.pb.h:56:51: error: 
> 'AuxiliaryParseTableField' in namespace 'google::protobuf::internal' does not 
> name a type; did you mean 'AuxillaryParseTableField'?
>56 |   static const 
> ::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField aux[]
>   |   
> ^~~~
>   |   
> AuxillaryParseTableField
> ...
> 
> I think this might be that we need a newer ignition-msgs package? 
> Or something in gazebo?

I think it's the other way around: ignition-msgs needs protobuf 3.13
because that contains a patch that renamed AuxillaryParseTableField to
AuxiliaryParseTableField:
https://github.com/protocolbuffers/protobuf/commit/2ae7cf0e03c3469973e592e812565e4ee2470e0b

I don't think we can do anything from the fawkes side.

Kind regards
Till
___
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: BZ + Firefox: browser freezes when choosing close reason?

[Till Hofmann]

On 9/5/20 3:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Sep 05, 2020 at 02:50:28PM +0200, Till Hofmann wrote:
>> Hi all,
>>
>> I'm having a weird problem with Bugzilla: Whenever I want to close an
>> issue and I click on the reason menu (the one that shows NOTABUG,
>> NEXTRELEASE etc.), my browser freezes. Is anyone else seeing this issue?
> 
> Yep, I usually see this. It seemed fairly consistent over I'd say a few
> months, but for the last few days I haven't seen it.

Good to know that it's not only me!
> 
>> I've tried to search for similar bug reports, but searching for
>> "bugzilla firefox bug status" obviously doesn't result in anything useful.
>>
>> I've seen this for a couple of weeks now. This is on Fedora 32 with
>> Firefox 80.0.1.
> 
> I have firefox-80.0.1-1.fc32.x86_64, and right now I don't see this.
> So there must be some other factor involved.

Yes, sometimes it's working for me, too. Today it doesn't work at all.
Chrome does not have the same issue.

Kind regards,
Till
___
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

BZ + Firefox: browser freezes when choosing close reason?

[Till Hofmann]

Hi all,

I'm having a weird problem with Bugzilla: Whenever I want to close an
issue and I click on the reason menu (the one that shows NOTABUG,
NEXTRELEASE etc.), my browser freezes. Is anyone else seeing this issue?

I've tried to search for similar bug reports, but searching for
"bugzilla firefox bug status" obviously doesn't result in anything useful.

I've seen this for a couple of weeks now. This is on Fedora 32 with
Firefox 80.0.1.

Kind regards,
Till
___
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

What to do about FTBFS because auf cmake change?

[Till Hofmann]

Hi all,

I have a number of packages that are FTBFS due to
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds.

None of my packages has seen any commits for that change. I've read on
the list that packages that are considered "a complete mess" are not
touched. Are all my packages "a complete mess"?

More seriously, are we expected to fix this ourselves? What happened to
"proposal owners will fix as many Fedora packages as possible"? Should I
just re-assign the bug to cmake?

I don't generally mind fixing my packages, but I'm confused by the lack
of communication here.

Kind regards,
Till
___
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

librealsense soname bump to 2.38

[Till Hofmann]

Hi all,

I'm updating librealsense to 2.38.0 in the next few days, which includes
an soname bump.

The only dependency is fawkes, which I also maintain (and which is
currently FTBFS for other reasons).

Kind regards,
Till
___
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: libdc1394: Unannounced soname bump?

[Till Hofmann]

On 7/27/20 2:28 PM, Richard Shaw wrote:
> I just got a BZ on OpenImageIO due to inability to install the -devel
> package,
> 
> Upon inspection it looks like the soname was bumped but a rebuild of
> OIIO was not performed.
> 
> libdc1394-2.2.2-14.fc32 -> libdc1394-2.2.6-1.fc33
> 
> libdc1394.so.22()(64bit) -> libdc1394.so.25()(64bit)
> 

That's my mistake, I did
$ dnf repoquery --repo=rawhide --source --whatrequires libdc1394-devel
instead of
$ dnf repoquery --repo=rawhide --source --whatrequires libdc1394

[Frankly, I don't understand why I need to do the latter]

Also, I didn't realize that the minor bump changed the soversion (I
don't usually glob shared libs in %files, I just took over this package).

This should not happen again in the future:
https://src.fedoraproject.org/rpms/libdc1394/c/20e3515e3f80876ff24a3cb3e07b2a51f78d3fdd?branch=master

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

Re: Fedora Packager Dashboard available for testing

[Till Hofmann]

On 6/23/20 6:28 PM, Josef Skladanka wrote:
> Hi,
> 
> We'd like to announce public testing of the Packager Dashboard - a new
> service for Fedora package maintainers aiming to provide all relevant
> data: FTBFS/FTI status (from both Bugzilla, Koschei and health check),
> orphan warnings, bugzillas, pull requests, active overrides and
> updates - at a single place in an easy to read and filter way.
> 
> The Dashboard is now available: https://packager.fedorainfracloud.org/

This is incredibly useful, thank you!

One very small grammar issue I've noticed: The text for a package that
depends on an orphaned package says (waybar in my example):
"will have trouble 7 hours ago"

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Till Hofmann]

On 6/16/20 9:56 AM, Vít Ondruch wrote:
> Also, I wonder what is wrong with "dnf autoremove", which is supposed to
> remove unused leaf packages, which were not explicitly installed?

On my system, it removed grub2-efi and made the system unbootable. So
I'm not sure running this as part of the system upgrade would be a good
idea.

[I'll dig into this and see if I need to file a bug]

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Till Hofmann]

On 6/16/20 1:16 AM, Miroslav Suchý wrote:
> Dne 16. 06. 20 v 0:37 James Cassell napsal(a):
>> Please not using mechanism. Make it easy to opt out, or better yet opt-in.
> 
> On package level, there is likely no other way. DNF team will have no 
> time/resources to implement this on DNF level.
> I can only thing of /usr/sbin/remove-retired-package which would be a wrapper 
> for
>   dnf remove $list $of $retired $package
> Does that sounds better?
> 
> Is there some way how to get this information from PDC?
> 
>> Probably better to just advertise `yum list extras` which has existed since 
>> at least Fedora 12.
> 
> Will be my mom able to write something like:
>  dnf remove $(dnf list extras | awk '{print $1} | grep -v 
> "package-I-still-want")
> ?

FTR,
  dnf remove $(dnf repoquery --extras --exclude=package-I-still-want)
is the canonical way to do this (taken from dnf's manpage).

I agree that this is still not suitable for a regular user.
___
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

soname bump: librealsense

[Till Hofmann]

Hi all,

I'm updating librealsense to 2.35.2 in Rawhide. The only dependency is
fawkes, which is currently FTBFS because gazebo fails to install.

Kind regards,
Till
___
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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

[Till Hofmann]

On 6/3/20 4:50 PM, Jonathan Wakely wrote:
> On 03/06/20 13:36 +0200, Miro Hrončok wrote:
>> On 03. 06. 20 13:32, Till Hofmann wrote:
>>> Yes, that's what I meant. I'm not going to test patches by submitting
>>> builds over and over again, that's not really time efficient. I'll just
>>> wait until it shows up in mock.
>>
>> $ mock -r fedora-rawhide-x86_64 --enablerepo=local install boost-devel
>> ...
>> Installed:
>> boost-devel-1.73.0-3.fc33.x86_64
>> ...
> 
> Right. Using --enablerepo=local means your mock build will use the
> buildroot, so you don't have to wait for it to be in the next compose.
> 
> You do not need to wait, it's there now. I've ben building against it
> locally for the past two days.
> 

Thanks, I forgot about the local repo.

Kind regards,
Till
___
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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

[Till Hofmann]

On 6/3/20 1:01 PM, Frantisek Zatloukal wrote:
> 
> 
> On Wed, Jun 3, 2020 at 12:46 PM Jonathan Wakely
> mailto:jwak...@fedoraproject.org>> wrote:
> 
> On 03/06/20 12:35 +0200, Till Hofmann wrote:
> >
> >
> >On 6/2/20 5:24 PM, Jonathan Wakely wrote:
> >> ### C++  includes
> >>
> >> Several packages failed to build because they couldn't find C++
> >> Standard Library algorithms:
> >
> >> freeopcua: error: 'for_each' is not a member of 'std'
> >
> >I don't see a changelog entry (or a commit), did you only update the
> >changelog if the build was successful?
> 
> Yes.
> 
> >I'll fix this as soon as boost 1.73 shows up in rawhide.
> 
> It's already there.
> 
> 
> Just note that it is in Rawhide, but you might not get it in mock and/or
> system update before next Rawhide compose. It is in buildroot however as
> can be seen by: "koji wait-repo f33-build --build=boost-1.73.0-3.fc33"
> 

Yes, that's what I meant. I'm not going to test patches by submitting
builds over and over again, that's not really time efficient. I'll just
wait until it shows up in mock.

Kind regards,
Till
___
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: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

[Till Hofmann]

On 6/2/20 5:24 PM, Jonathan Wakely wrote:
> ### C++  includes
> 
> Several packages failed to build because they couldn't find C++
> Standard Library algorithms:

> freeopcua: error: 'for_each' is not a member of 'std'

I don't see a changelog entry (or a commit), did you only update the
changelog if the build was successful?

I'll fix this as soon as boost 1.73 shows up in rawhide.

Kind regards,
Till
___
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: i3 new SIG

[Till Hofmann]

Hi Eduard,

On 5/15/20 12:21 AM, Eduard Lucena wrote:
> 
> As others have already mentioned in the thread: we should look into
> joining forces with the sway SIG (which I am also a member of).
> 
> 
> It's not a bad idea, but TBH, I still want to stay away from Wayland.
> 
> While a lot of the packages of interest are not really shared, the
> general
> similarity would allow us to save a lot of time when it comes to QA and
> the creation of a spin. Maybe we should merge into the tilling window
> manager SIG? (with a better name of course).
> 
> 
> Well, we can join effort for packaging but produce different Spins, why
> not? wdyt?
>  

It's nice to see more interest in i3! But I'm not sure that joining
efforts is such a good idea. While sway and i3 may be very similar from
a user perspective, they are not from a packager's perspective. Also,
while you don't really care about sway, I don't have much interest in
i3. So what exactly would a joined SIG do? All the work would be either
towards i3 or sway, I don't see any synergetic effects of a joint SIG.

Kind regards,
Till
___
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

Review swap: freeopcua

[Till Hofmann]

Hi all,

I'm looking for a review for freeopuca, a C++ OPC-UA library:
https://bugzilla.redhat.com/show_bug.cgi?id=1824467

The package should be rather easy to review. I'm willing to do a review
in return.

Kind regards,
Till
___
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: Updated review trackers pages

[Till Hofmann]

On 4/7/20 9:21 AM, Mattia Verga via devel wrote:
> we have updated the script which provides the cached review trackers 
> pages at https://fedoraproject.org/PackageReviewStatus/ (thanks to 
> cverna for the assistance).

It looks like 1821497 [1] is displayed incorrectly (currently at the
bottom of the page), maybe bccause of the unusual title ("Review
Request:  - ")?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1821497
___
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: Packages looking for new (co)maintainers

[Till Hofmann]

Hi Peter,

On 3/8/20 12:04 PM, Peter Robinson wrote:
> A list of packages that I still have an interest in but would
> appreciate a co-maintainer:
> dotconf
> festival-freebsoft-utils
> speech-dispatcher
> flite
> csound

I can help out with flite, although I can't promise I'll put a lot of
time into it. My FAS is thofmann.

Kind regards,
Till
___
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: Unannounced SONAME bump: librealsense

[Till Hofmann]

Hi Fabio,

On 3/6/20 9:13 PM, Fabio Valentini wrote:
> Hi everybody,
> 
> librealsense (maintainers in CC) bumped the SONAME of its shipped
> library with the latest update, and (at least some) dependent packages
> have not been rebuilt (including fawkes, maintainers in CC).

Thanks for the reminder, I happen to be maintainer of both. Fawkes is
the only package depending on librealsense, announcing an SONAME bump to
myself didn't seem like something particularly useful. I've rebuilt fawkes.

Kind regards,
Till
___
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: mock build failures for f32/33

[Till Hofmann]

Hi Richard,

On 2/18/20 3:44 PM, Richard Shaw wrote:
> I am unable to build packages using mock for either f32 or f33 which is
> very problematic.

Afaik you need mock from updates-testing for the new config/keys.

Kind regards,
Till
___
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: Disabling Fedora 29 chroots in Copr

[Till Hofmann]

On 2/18/20 12:15 PM, Jakub Kadlcik wrote:
> I would like to ask you, can anyone with non Red Hat email confirm,
> that they get the notifications? The subject is
> 
>> [Copr] upcoming deletion of outdated chroots in your projects
> 

I received the notification. I have a posteo.de email.

Kind regards,
Till
___
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: Packaging of github cli?

[Till Hofmann]

On 2/14/20 7:36 PM, Joe Doss wrote:
> On 2/14/20 10:23 AM, Joe Doss wrote:
>> On 2/14/20 9:56 AM, Richard Shaw wrote:
>>> Anyone working on packaging github's CLI?
>>>
>>> https://github.com/cli/cli 
>>>
>>> I've never packaged a GO application before...
>>
>> I have a spec I am working on right now. I will try to get it up on my
>> Copr this weekend.
> 
> Well that was easier than I thought.
> 
> https://copr.fedorainfracloud.org/coprs/jdoss/github
> 
> $ dnf copr enable jdoss/github
> $ dnf install github-cli
> 

Would you mind submitting builds for F30? Some people (me) are still on
F30...

Thanks!
Till
___
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: Proxies for Copr repositories

[Till Hofmann]

On 2/4/20 2:58 PM, Miroslav Suchý wrote:
> Dne 04. 02. 20 v 13:18 Till Hofmann napsal(a):
>> Does COPR itself also use the CDN for builds? I usually build dependency
> 
> Yes. Since today.
> 
>> chains, and since this morning, I see a lot of build failures due to a
>> newly built package not being available. One example:
>> - The newly built dependency:
>> https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220759/
>> - failed build, it cannot find the previously built package:
>> https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220790/
> 
> I find the hard way, that repodata was cached too aggressively (with TTL 
> 86400).
> 
> repodata are now sent with
>   Cache-Control: no-cache
> and log files (*log) with:
>   Cache-Control: no-store
> 
> and it seems to fix this issue.
> 
> 

Yes, that explains what I'm seeing. Thanks for the fix!

I guess we need to wait 24h until the wrongly cached files expire? I'm
still seeing the issue.

Kind regards,
Till
___
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: Proxies for Copr repositories

[Till Hofmann]

On 2/4/20 10:03 AM, Miroslav Suchý wrote:
> Hi,
> I just enabled the content delivery network (CDN) for Copr repositories.
> It is provided by CloudFront from AWS. And it is provided for free by Amazon 
> to Fedora.
> [...]
> 
> If you experience any problem with CDN, please let me know.
> 

First of all, great to see faster COPR mirrors!

Does COPR itself also use the CDN for builds? I usually build dependency
chains, and since this morning, I see a lot of build failures due to a
newly built package not being available. One example:
- The newly built dependency:
https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220759/
- failed build, it cannot find the previously built package:
https://copr.fedorainfracloud.org/coprs/thofmann/ros/build/1220790/

Kind regards,
Till
___
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: undefined symbol from OpenColorIO prevents Blender from running

[Till Hofmann]

On 11/20/19 1:32 PM, Till Hofmann wrote:



On 11/20/19 4:49 AM, Richard Shaw wrote:
On Tue, Nov 19, 2019 at 9:27 PM Luya Tshimbalanga 
mailto:l...@fedoraproject.org>> wrote:


    Some users reported Blender which I maintain failed to start due to
    this issue:

    blender: symbol lookup error: /lib64/libOpenColorIO.so.1: 
undefined symbol: _ZN4YAML6detail9node_data12empty_scalarB5cxx11E



    Accordingly, the problem is caused by OpenColorIO from which Blender
    depends. A bug is already filed [1] and it would be nice to fix it.
    Currently,the latest build of OpenColorIO on Fedora 31 is 1.1.1-2
    while Rawhide is on 1.1.1-4[2]


I'm all for fixing bugs quickly but it was only assigned to OCIO in BZ 
on 11/20 (UTC) and it's still November 19th for me :)


It would hopefully be fixed by a simple rebuild which any 
provenpackager can do, but digging a little deeper:


$ c++filt _ZN4YAML6detail9node_data12empty_scalarB5cxx11E
YAML::detail::node_data::empty_scalar[abi:cxx11]

So the problem is really with YAML. It looks like Till Hofmann built 
yaml-cpp 0.6.3 for Fedora 30 and 31 (I only built it for Rawhide) and 
did not rebuild OCIO.




Yes I did. There was no soname bump and the abidiff warnings looked like 
false positives. There was also no announcement on the devel list or 
rebuilds of the dependent packages in rawhide for yaml-cpp 0.6.3, so I 
assumed pulling the update into old releases was safe.




Also, this most likely means that rawhide packages are also affected, 
but nobody has noticed it yet.


Basically, upstream removed function symbols without bumping the soname.

Kind regards,
Till
___
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: undefined symbol from OpenColorIO prevents Blender from running

[Till Hofmann]

On 11/20/19 4:49 AM, Richard Shaw wrote:
On Tue, Nov 19, 2019 at 9:27 PM Luya Tshimbalanga 
mailto:l...@fedoraproject.org>> wrote:


Some users reported Blender which I maintain failed to start due to
this issue:

blender: symbol lookup error: /lib64/libOpenColorIO.so.1: undefined symbol: 
_ZN4YAML6detail9node_data12empty_scalarB5cxx11E


Accordingly, the problem is caused by OpenColorIO from which Blender
depends. A bug is already filed [1] and it would be nice to fix it.
Currently,the latest build of OpenColorIO on Fedora 31 is 1.1.1-2
while Rawhide is on 1.1.1-4[2]


I'm all for fixing bugs quickly but it was only assigned to OCIO in BZ 
on 11/20 (UTC) and it's still November 19th for me :)


It would hopefully be fixed by a simple rebuild which any provenpackager 
can do, but digging a little deeper:


$ c++filt _ZN4YAML6detail9node_data12empty_scalarB5cxx11E
YAML::detail::node_data::empty_scalar[abi:cxx11]

So the problem is really with YAML. It looks like Till Hofmann built 
yaml-cpp 0.6.3 for Fedora 30 and 31 (I only built it for Rawhide) and 
did not rebuild OCIO.




Yes I did. There was no soname bump and the abidiff warnings looked like 
false positives. There was also no announcement on the devel list or 
rebuilds of the dependent packages in rawhide for yaml-cpp 0.6.3, so I 
assumed pulling the update into old releases was safe.


I have a patch that reverts the removal of the symbol, as explained here:
https://bugzilla.redhat.com/show_bug.cgi?id=1773331

However, blender still fails to start, even with the patch. I haven't 
had the time to dig deeper. I may find time tomorrow.


Note that F30 is not affected, I unpushed the update.

Kind regards,
Till
___
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: CGAL soname "bump" in rawhide

[Till Hofmann]

On 10/13/19 4:39 PM, Ankur Sinha wrote:

Hello,

I'm building a new package, graph-tools. The scratch build fails on rawhide 
with:

```
annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection -Wno-register -fopenmp -O3 
-fvisibility=default -fvisibility-inlines-hidden -Wno-deprecated -Wall -Wextra 
-ftemplate-backtrace-limit=0 -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wno-register -c graph_triangulation.cc  -fPIC -DPIC -o 
.libs/graph_triangulation.o
In file included from /usr/include/CGAL/basic.h:30,
  from /usr/include/CGAL/Cartesian/Cartesian_base.h:29,
  from /usr/include/CGAL/Simple_cartesian.h:29,
  from 
/usr/include/CGAL/Exact_predicates_inexact_constructions_kernel.h:29,
  from graph_triangulation.cc:37:
/usr/include/CGAL/config.h:161:12: fatal error: CGAL/compiler_config.h: No such 
file or directory
   161 | #  include 
   |^~~~
compilation terminated.
make[4]: *** [Makefile:598: graph_triangulation.lo] Error 1
make[4]: Leaving directory 
'/builddir/build/BUILD/graph-tool-2.29/src/graph/generation'
make[4]: *** Waiting for unfinished jobs
make[4]: Entering directory 
'/builddir/build/BUILD/graph-tool-2.29/src/graph/generation'

```

CGAL in rawhide does not include this file from the looks of it.

The spec + patch for graph-tools are here:
https://pagure.io/neuro-sig/graph-tool/tree/master

The scratch build is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=38265834

I've filed a bug upstream, but not gotten a reply yet:
https://git.skewed.de/count0/graph-tool/issues/613

Any ideas please?



You probably need to compile with `-DCGAL_HEADER_ONLY`, we had the same 
problem in fawkes. Here is the fawkes patch that fixed it:

https://src.fedoraproject.org/rpms/fawkes/blob/master/f/fawkes.cgal-header-only.patch

Kind regards,
Till
___
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: Problem with F30 module packages that are built in F32 buildroot (?)

[Till Hofmann]

On 9/23/19 1:42 PM, Petr Pisar wrote:

On 2019-09-22, Till Hofmann  wrote:

We have an odd issue with a module build of sway for F30: It looks like
the module was actually built with a F32 buildroot.

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1754167
Here's the build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1376355

The modulemd file contains:
dependencies:
- buildrequires:
platform: [f30]
  requires:
platform: [f30]

But then, it built packages with f32 in the package version:
artifacts:
  rpms:
  - mako-0:1.4-1.module_f32+6140+eb754d2b.src
  - mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64
  - mako-debuginfo-0:1.4-1.module_f32+6140+eb754d2b.x86_64
  - mako-debugsource-0:1.4-1.module_f32+6140+eb754d2b.x86_64


There was a bug in Module Build Service that added F32 packages into
non-f32 platform build roots. The bug was fixed and owners of two
affected builds notified that the build will be retired in MBS and they
will have to rebuild them again.

Maybe the sway module slipped through the craks. Or the bug reoccurred.
I cannot find the ticket where this issue was resolved.

Since the build is already in a stable repository, the only option is
probably bumping Release numbers in the spec files and building the
module again.



Thanks for the hint!

Do I really need to bump releases for all the packages in the module or 
is it enough to just rebuild the module itself?


Kind regards,
Till
___
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: Automation ignores FTBFS guidelines

[Till Hofmann]

On 9/22/19 4:08 PM, Miro Hrončok wrote:

On 22. 09. 19 16:01, Till Hofmann wrote:
So the guidelines allow package retirement without any announcement on 
devel. That's certainly unexpected, at least to me. I also don't think 
this is a good idea, because maintainers of packages that depend on 
the retired package are still clueless until it's too late. Or do they 
get a separate notification?


I still find it somewhat inconsistent that basically every rule in the 
FTBFS guidelines is about notifying people, but (7) allows retirement 
without any prequisites other than being FTBFS for 2 releases -- no 
announcement, no orphaning.



Yes, I agree. That's why I've started:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/ 





Ah yes, I now remember reading this. I'll add to if I have anything to add.

Apologies for blaming this on the scripts!

Kind regards,
Till
___
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: Automation ignores FTBFS guidelines

[Till Hofmann]

On 9/22/19 3:40 PM, Miro Hrončok wrote:

On 22. 09. 19 14:37, Till Hofmann wrote:

Hi all,

So I've just been notified that tolua++ has been retired, which is a 
dependency of one of my packages (fawkes). BZ: 
https://bugzilla.redhat.com/show_bug.cgi?id=1736911


I've closed this bug because it "was already retired", not because of 
that bug.


The package was actually retired more than a month ago in here:

https://bugzilla.redhat.com/show_bug.cgi?id=1676145#c12

Based on this rule:

"7. A week before the mass branching, any packages which still have open 
FTBFS bugs from the previous release will be retired."


I see, so the package was already FTBFS in F30. So the F31 FTBFS was 
actually a duplicate. It would have helped if it was marked as such, but 
I understand that's easier said than done.




To put it differently, the guidelines were completely ignored. The 
package was retired 6 days after the initial FTBFS bug, without any 
announcement.


No, they were not ignored at all.

The comment "your package has not been built successfully in 31. 
Action is required from you" isn't helping either, as the package has 
long been retired at that time.


Yes, that's why I closed the bugzilla. See 
https://pagure.io/releng/issue/8478


So can we please make sure that guidelines apply to everybody, also 
and especially to scripts?


They do.




You're right, as this was FTBFS in F30 already, it's all good.

So the guidelines allow package retirement without any announcement on 
devel. That's certainly unexpected, at least to me. I also don't think 
this is a good idea, because maintainers of packages that depend on the 
retired package are still clueless until it's too late. Or do they get a 
separate notification?


I still find it somewhat inconsistent that basically every rule in the 
FTBFS guidelines is about notifying people, but (7) allows retirement 
without any prequisites other than being FTBFS for 2 releases -- no 
announcement, no orphaning.



Kind regards,
Till
___
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: Automation ignores FTBFS guidelines

[Till Hofmann]

On 9/22/19 3:01 PM, Hans de Goede wrote:


But I do have something to say about the specific example used. tolua++ 
being retired
is not a problem for fawkes, as fawkes depends on compat-tolua++, which 
is maintained

by me and has NOT been retired.



Thanks for pointing this out! I assumed compat-tolua++ was a subpackage 
of tolua++ (I hadn't actually looked at the spec file yet).

___
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

Automation ignores FTBFS guidelines

[Till Hofmann]

Hi all,

So I've just been notified that tolua++ has been retired, which is a 
dependency of one of my packages (fawkes). BZ: 
https://bugzilla.redhat.com/show_bug.cgi?id=1736911


This would have been fine (as no action has been taken), if the 
automation had actually followed the FTBFS guidelines [1]. But it 
hasn't, in many ways:
1. "If an FTBFS or FTI bug remains in the NEW state for at least 1 week, 
any concerned party can set a NEEDINFO for the maintainer to respond and 
send an e-mail reminder with the Bugzilla link to 
-maintain...@fedoraproject.org, cc’ing the devel mailing 
list (so there is a public record) and commenting on the bug about doing 
so."
I did not see such an email on devel. Also NEEDINFO was set on Sep 22, 
~10 weeks after retirement.
2. "If the bug remains in NEW state for at least another 4 weeks after 
the second e-mail and comment (= at least 8 weeks in total), the package 
will be orphaned. Orphaning can be requested via a releng issue."
There was no email at all, at least not to devel, or the maintainers of 
the dependencies of tolua++.
3. "The normal Orphaned package that needs new maintainers procedure 
will be followed for the packages orphaned in this way, leading to their 
retirement if nobody adopts them."
This did not happen either. In particular, it was never announced that 
the package was orphaned.
4. In fact, as far as I can tell, the package was never orphaned, but 
directly retired.


To put it differently, the guidelines were completely ignored. The 
package was retired 6 days after the initial FTBFS bug, without any 
announcement. This is in stark contrast to the 14 weeks mentioned in the 
guidelines. To add to this, the retirement isn't even mentioned in the 
bug report. It just silently happened.


The comment "your package has not been built successfully in 31. Action 
is required from you" isn't helping either, as the package has long been 
retired at that time.


I understand and support that FTBFS packages are retired, but this is 
not the way this should work. There was no way I could have heard about 
the issue in time. It effectively requires me to become co-maintainer on 
every package that I depend on. Clearly not something I want to do.


So can we please make sure that guidelines apply to everybody, also and 
especially to scripts?


Thanks,
Till


[1] 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

___
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

Problem with F30 module packages that are built in F32 buildroot (?)

[Till Hofmann]

Hi all,

We have an odd issue with a module build of sway for F30: It looks like 
the module was actually built with a F32 buildroot.


BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1754167
Here's the build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1376355

The modulemd file contains:
  dependencies:
  - buildrequires:
  platform: [f30]
requires:
  platform: [f30]

But then, it built packages with f32 in the package version:
  artifacts:
rpms:
- mako-0:1.4-1.module_f32+6140+eb754d2b.src
- mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64
- mako-debuginfo-0:1.4-1.module_f32+6140+eb754d2b.x86_64
- mako-debugsource-0:1.4-1.module_f32+6140+eb754d2b.x86_64
[and more packages]

The package shows up in a F30 repoquery:
$ dnf repoquery --releasever=30 mako
Last metadata expiration check: 0:08:32 ago on Sun 22 Sep 2019 11:25:43 
CEST.

mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64

But it requires systemd-libs from F32:
$ dnf repoquery --releasever=30 --requires \
  mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64 | grep SYSTEMD
libsystemd.so.0(LIBSYSTEMD_221)(64bit)
libsystemd.so.0(LIBSYSTEMD_222)(64bit)
libsystemd.so.0(LIBSYSTEMD_243)(64bit)


Can someone tell me what's going on here?

Thanks!
Till
___
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: Upcoming change for adopting orphaned packages and anitya integration

[Till Hofmann]

On 9/13/19 12:32 PM, Pierre-Yves Chibon wrote:
> ## Anitya integration
> 
> Currently if you want to tweak the setting for the anitya integration, you 
> need
> to open a pull-request on the fedora-scm-requests project at
> https://pagure.io/releng/fedora-scm-requests/
> That git repo is pretty big and once your pull-request is finally open, you
> still have to wait for someone to merge it.
> 
> This is also going to change, new versions of pagure and pagure-dist-git 
> offer a
> drop-down menu on the left hand side menu to see and adjust the monitoring
> status of the project.
> 
> This is also live in staging and you can see an example of a project who has 
> set
> its monitoring status to "monitoring":
> https://src.stg.fedoraproject.org/rpms/0ad
> 
> (The status in staging have been imported from the fedora-scm-requests repo)


This is great to here! Would it be possible to have a page that shows
the monitoring status of all my packages? Does that even exist already?
I find myself repeatedly going through all my packages one-by-one to
check the monitoring status, and I still miss a package once in a while.
(This will already get easier with the new buttons, though).

Kind regards,
Till
___
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

mongo-cxx-driver 3.4.0 is available (was: RH Account of package maintainer disabled)

[Till Hofmann]

On 7/10/19 8:01 AM, Petr Kubat wrote:
> Hi Till,
> 
> On 7/10/19 7:39 AM, Till Hofmann wrote:
>> Hi all,
>>
>> I'm trying to contact the maintainer (Marek Skalický) of
>> mongo-cxx-driver, which has a pending update:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1723810
>>
>> However, if I try to select "Need additional information", I get an
>> error:
>>   You can't ask Marek Skalický  because that account
>> is disabled.
>>
>> Should the package have been orphaned?
> 
> No, as the package still has active maintainers (see pagure).
> 
> What should have happened I guess is the transfer of ownership to the
> new maintainers (in CC)
> 

So far nothing has happened, can someone please update the package?

Thanks!
Till
___
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

Cannot build with mock for rawhide on Fedora 30

[Till Hofmann]

Hi all,

I'm facing an issue with the package signatures on Fedora when trying to
build in rawhide chroot:
$ mock -r fedora-rawhide-x86_64 --shell
[...]
Public key for zstd-1.4.2-1.fc31.x86_64.rpm is not installed. Failing
package is: zstd-1.4.2-1.fc31.x86_64
 GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-31-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-30-primary
Error: GPG check FAILED

I cleaned the mock cache, deleted the old chroot and also checked that
my mock config is up-to-date (no .rpmnew files), to no avail.

Any idea what's causing this?

Thanks!
Till
___
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: friday roundup of failing images in rawhide

[Till Hofmann]

On 7/20/19 3:16 AM, Kevin Fenzi wrote:
> 6. Fedora Robotics lab:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=36353237
> 
> fawkes broken deps:
> 
>  Problem 1: conflicting requests
>   - nothing provides fawkes-plugin-clips-webview needed by
> fawkes-1.2.0-6.fc31.x86_64
>   - nothing provides fawkes-plugin-rrdweb needed by
> fawkes-1.2.0-6.fc31.x86_64
>  Problem 2: conflicting requests
>   - package fawkes-doc-1.2.0-6.fc31.noarch requires fawkes =
> 1.2.0-6.fc31, but none of the providers can be installed
>   - nothing provides fawkes-plugin-clips-webview needed by
> fawkes-1.2.0-6.fc31.x86_64
>   - nothing provides fawkes-plugin-rrdweb needed by
> fawkes-1.2.0-6.fc31.x86_64

Should be fixed now.

Kind regards,
Till
___
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: Vim and spec template

[Till Hofmann]

On 7/19/19 11:33 AM, Elliott Sales de Andrade wrote:
> On Fri, 19 Jul 2019 at 05:09, Zdenek Dohnal  wrote:
>>
>>
>> On 7/18/19 9:47 PM, Jason L Tibbitts III wrote:
 "ZD" == Zdenek Dohnal  writes:
>>> ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful
>>> ZD> for Vim to do:
>>>
>>> ZD> - when you open new file with .spec suffix, Vim will get you basic
>>> ZD> spec file structure?
>>>
>>> Personally I have always found that behavior annoying.  If I open a new
>>> file, I expect that the file would be empty.  If I want a template, I
>>> can copy one.  Editing a new HTML file doesn't bring up a template for
>>> HTML files, for example.
>>>
>>> The spec template used isn't something I ever want anyway.  It uses tabs
>>> instead of spaces and uses them in a way that implies that indentation
>>> is somehow required.
>> Converted to spaces now.
>>>   And it includes a default release tag of
>>> "0%{?dist}" which isn't permitted by the packaging guidelines.
>> Expected. It is designed for user to run rpmdev-bumpspec .spec,
>> so the tool will supply correct format of changelog entry and increment
>> the release.
> 
> Why would you use rpmdev-bumpspec for a file created in vim when you
> can use c in vim directly?

It also creates a changelog entry for you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Vim and spec template

[Till Hofmann]

On 7/18/19 6:44 PM, Steven A. Falco wrote:
> On 7/18/19 10:28 AM, Zdenek Dohnal wrote:
>>
>> On 7/18/19 4:10 PM, Vitaly Zaitsev via devel wrote:
>>> Hello, Zdenek Dohnal.
>>>
>>> Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
>>>
 Even the new .spec files, which do not have to be RPM spec files?
 Because Vim provides spec template for such cases.
>>> I never used this feature, so I think it can be disabled by default.
>> That's the thing which I asked for opinion on, not about syntax
>> highlighting.
> 
> Ah - now I understand.  I thought you were asking about syntax highlighting.
> 
> I had never noticed the feature of creating a new spec file from a template, 
> because I have my own .vimrc file, so the /etc/vimrc file has no effect for 
> me.

That's not true (at least on my machine). I have my own .vimrc and yet
the template is loaded when I create a new spec.

> 
> I think having a template for just this single file type is kind of 
> "strange".  I'd personally be fine with removing that line from /etc/vimrc.  
> I'd expect users who want templates to set them up for themselves, rather 
> than forcing users to disable templates they don't want.
> 

Yes, that's exactly what I thought. We also have rpmdev-newspec, which I
typically use if I create a spec file for a Fedora package. It's
irritating that they're different.

Kind regards,
Till
___
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: Vim and spec template

[Till Hofmann]

On 7/18/19 1:44 PM, Zdenek Dohnal wrote:
> Hi all,
> 
> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
> 
> - when you open new file with .spec suffix, Vim will get you basic spec
> file structure?
> 
> Recently I found out someone can find it as bad behavior
> https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider
> changing the default vimrc to tell Vim 'Don't do it'.
> 
> What's your opinion? Is it useful feature of Vim and it should stay as
> default, or it needs to be disabled?
> 

Generally, I find templates very useful, but I use the vim-template
plugin for that, and I was surprised to see that vim ships its own
template just for SPECs. Imo, everyone who wants a template should use a
plugin. Shipping one by default just for SPECs is somewhat inconsistent.

Kind regards,
Till
___
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

RH Account of package maintainer disabled

[Till Hofmann]

Hi all,

I'm trying to contact the maintainer (Marek Skalický) of
mongo-cxx-driver, which has a pending update:
https://bugzilla.redhat.com/show_bug.cgi?id=1723810

However, if I try to select "Need additional information", I get an error:
 You can't ask Marek Skalický  because that account
is disabled.

Should the package have been orphaned?

Kind regards,
Till
___
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

Nonresponsive maintainer: bioinfornatics

[Till Hofmann]

Hi all,

I'm trying to reach bioinfornatics. According to fedora_active_user,
their last login was on 2019-03-27.

Open tickets:
https://bugzilla.redhat.com/show_bug.cgi?id=1700141
https://bugzilla.redhat.com/show_bug.cgi?id=1674976

Does anyone know how to reach bioinfornatics?

Kind regards,
Till
___
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

Should I always create a dedicated stream branch for my module?

[Till Hofmann]

Hi all,

I'm currently working on a module for sway. We basically just want to
have a stream that always contains the latest version of sway (including
all its dependencies), the same version that is also in rawhide (this
stream should be named 'rolling' if I understand the guidelines
correctly). In that case, is it better to just use the master branch of
the package git, or should I create a dedicated stream branch nevertheless?

Thanks,
Till
___
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: sway SIG

[Till Hofmann]

On 3/18/19 4:22 PM, Till Hofmann wrote:
> There's been ongoing discussions on BZ [1] with some people showing
> interest in a SIG. The main purpose of this email is to see who else
> would be interested in contributing to sway. If we can find enough
> people, I'd continue with the SIG, as outlined in [2].

Hi all,

the SIG is now set up and all people who showed interest should be part
of it. The mailing list is here:
https://lists.fedoraproject.org/admin/lists/sway.lists.fedoraproject.org/
The Wiki page here:
https://fedoraproject.org/wiki/SIGs/Sway

Please let me know if I missed someone.

Kind regards,
Till
___
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

sway SIG

[Till Hofmann]

Hi all,

there's been a rising number of people interested in sway, the
i3-compatible Wayland compositor. At the same time, with the recent sway
1.0 release, the packaging work is also increasing, as more and more
components are split into separate projects.

For this reason, we thought about creating a sway SIG. The goal of the
SIG is simple: package all components of sway and make sure that Fedora
provides a good user experience with sway. Creating a SIG would allow us
to coordinate better and also take care of the packages as a team (with
easier ACLs without proven packager status etc).

There's been ongoing discussions on BZ [1] with some people showing
interest in a SIG. The main purpose of this email is to see who else
would be interested in contributing to sway. If we can find enough
people, I'd continue with the SIG, as outlined in [2].

I've never been involved in creating a SIG before, so please let me know
if I forgot anything.

Kind regards,
Till


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1672268
[2] https://fedoraproject.org/wiki/Creating_a_Fedora_SIG
___
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: Self-Introduction: Michael Zhang

[Till Hofmann]

On 1/20/19 2:27 PM, Zbigniew Jędrzejewski-Szmek wrote:

> Also, please attach your spec file and srpm to the bug. Don't use url
> obfuscators and don't use external hosting (people want to see where
> the links go without following them, and we want those files to be
> available infinitely, and external file hosting goes against this).
> 

I did not know that we shouldn't use external hosting, the wiki [1] also
doesn't require that, it only says:

> Put your spec file and SRPM somewhere on the Internet where it can be 
> directly downloaded (just HTTP(s), no registration pages or special download 
> methods, please).


While I see that having them available infinitely has a benefit, it's
not enforced anywhere (and actually uncommon for the reviews I've seen).

Maybe the guidelines need an update, if that's actually something we
want to have?

Kind regards
Till

[1] https://fedoraproject.org/wiki/Package_Review_Process
___
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: ONGOING PROBLEM: Buildsystem degradation

[Till Hofmann]

On 1/4/19 6:38 PM, Kevin Fenzi wrote:
> On 12/24/18 4:24 AM, Till Hofmann wrote:
> 
>> OK, I was actually wondering exactly that, I remembered that COPR is
>> maintained/run by someone else. But on the Fedora Infrastructure Status
>> page [1], there is also a COPR status, and the link for outages directly
>> leads to the fedora-infrastructure tracker, that's why I thought that's
>> the right place. I guess it may already help if the status page linked
>> to the right trackers for each component?
> 
> Yes, or (as we have planned but not yet done, reorganize status to note
> different sections of things based on their SLE).
> 
>> Is status.fp.o still actually used? There is at least one commit from
>> April 2017 that still hasn't been deployed.
> 
> It is. Where are you seeing that?
> 
> The repo is:
> 
> https://github.com/fedora-infra/statusfpo/commits/master
> 
> last commit dec 18th, 2018.
> 
> kevin

Ah, I was looking at the pagure repo. status.fp.o still points to
fedorahosted.org in the "Open Source" link at the bottom. It seems like
this commit didn't make it into GitHub:
https://pagure.io/fedora-status/c/e4009d65586f9ebe8573a6148acd7f4f1816959e?branch=master

Kind regards
Till
> 
> 
> ___
> 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
> 
___
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: ONGOING PROBLEM: Buildsystem degradation

[Till Hofmann]

On 12/23/18 7:20 PM, Kevin Fenzi wrote:
> On 12/23/18 3:37 AM, Till Hofmann wrote:
>>
>>
>> On 12/21/18 4:03 PM, Stephen John Smoogen wrote:
>>> There is currently a problem with the networking of various systems in
>>> our Phoenix data-center which houses most of our build systems. The
>>> problem has knocked off most of our x86_64 build systems and several
>>> of our aarch64/arm systems. Builds will take longer to process during
>>> this time and may queue up for the remaining builders.
>>>
>>> There is currently no ETA for when recovery will happen but due to end
>>> of the year schedules, it will not happen until early January. If
>>> things worsen we will see what escalation paths or changes can be
>>> done.
>>>
>>
>> Not sure if this is related, but COPR repositories seem to be
>> inaccessible. I filed https://pagure.io/fedora-infrastructure/issue/7460
>> (I hope this is the right place for the issue)
> 
> Nope, unrelated completely... you can file copr tickets there, but we
> don't maintain copr. Since it was just a unresponsive node this time I
> was able to bring it back up

Thanks for fixing it so quickly!

> but if it was anything more complex you
> would need to let the copr folks know, probibly at:
> 
> https://bugzilla.redhat.com/enter_bug.cgi?product=Copr
> 
> I realize this is all confusing and hopefully we can come up with a
> better way for people to know where to report things for which service
> and what to expect. It's not an easy problem however. ;(
> 

OK, I was actually wondering exactly that, I remembered that COPR is
maintained/run by someone else. But on the Fedora Infrastructure Status
page [1], there is also a COPR status, and the link for outages directly
leads to the fedora-infrastructure tracker, that's why I thought that's
the right place. I guess it may already help if the status page linked
to the right trackers for each component?

Is status.fp.o still actually used? There is at least one commit from
April 2017 that still hasn't been deployed.

Kind regards,
Till

[1] https://status.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
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: ONGOING PROBLEM: Buildsystem degradation

[Till Hofmann]

On 12/21/18 4:03 PM, Stephen John Smoogen wrote:
> There is currently a problem with the networking of various systems in
> our Phoenix data-center which houses most of our build systems. The
> problem has knocked off most of our x86_64 build systems and several
> of our aarch64/arm systems. Builds will take longer to process during
> this time and may queue up for the remaining builders.
> 
> There is currently no ETA for when recovery will happen but due to end
> of the year schedules, it will not happen until early January. If
> things worsen we will see what escalation paths or changes can be
> done.
> 

Not sure if this is related, but COPR repositories seem to be
inaccessible. I filed https://pagure.io/fedora-infrastructure/issue/7460
(I hope this is the right place for the issue)

Kind regards & happy holidays
Till
___
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] Latest protobuf is coming into Rawhide

[Till Hofmann]

On 11/23/18 12:55 PM, Igor Gnatenko wrote:
> I've built it and dependent packages in side tag and it's going to be
> merged back soon.
> 
> Only 4 problematic packages:
> * gazebo (not related to protobuf, FTBFS for long time)
> /builddir/build/BUILD/gazebo-8.3.0/gazebo/msgs/generator/GazeboGenerator.cc:51:5:
> error: 'scoped_ptr' was not declared in this scope
>  scoped_ptr output(

I've pushed a fix for gazebo into rawhide. Can you please rebuild gazebo
and then fawkes in your side tag? Thanks!

Till
___
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: Issues with Google Chrome, PyCharm, Steam and other third-party repos in Fedora 29 prereleases

[Till Hofmann]

On 10/25/18 4:02 PM, Stephen Gallagher wrote:
> It was discovered[1] a short while ago that, due to a packaging
> mistake in the fedora-workstation-repos package, upgrades from Fedora
> 28->Fedora 29 would replace the /etc/yum.repos.d/*.repo files provided
> from that package with their default configuration.
> 
> What this meant in practice is that anyone who was using those
> repositories in Fedora 28 would find them silently disabled in Fedora
> 29. In particular, this would mean that they might not notice that
> they were not receiving updates, particularly (in the case of Chrome)
> security updates.
> 
> This has been fixed for F29 Final, but if you have upgraded from
> F28->F29 prior to today (such as at the Beta release), you should
> check and verify that your expected repos are correctly enabled.
> 

Is it possible that this also happened on F28? I haven't upgraded to F29
yet, but surprisingly my google-chrome repo is disabled and I'm using
Chrome 68.0.3440.84 from 2 months ago. I'm pretty sure I never disabled
the repo manually.

Kind regards
Till
___
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: bottlenecks that case my machine to freeze

[Till Hofmann]

On 10/25/18 4:47 PM, mcatanz...@gnome.org wrote:
> On Thu, Oct 25, 2018 at 6:50 AM, Nicolas Mailhot
>  wrote:
>> I get the same thing without any special load. System would work fine
>> for hours and then input would start bugging.
>>
>> It translates into floods of keystrokes, or eaten keystrokes, or
>> keystrokes being fed to apps out of order. Requires a system reboot to
>> fix.
>>
>> There is a serious bug somewhere in libinput WRT input queue
>> management (priorization, ordering, and press/release detection).
>>
>> I use Logitech wireless keyboards and mice with the bluetooth usb
>> dongle. Don't know if that's your case too.
>>
>> Regards,
> 
> I don't think it's a libinput problem. I was talking with Alex about
> this a while back, and if I remember correctly, he thinks it's a Wayland
> protocol flaw: basically there's no way for the compositor to tell the
> difference between "the key is being pressed for a long time" and "the
> computer is under such heavy load that the keypress end event hasn't
> arrived from the client yet". Of course it's a bit more complicated than
> that, but the end result is too many keystrokes, or eaten keystrokes.
> Something changed in F28 (or was it F27? recently at any rate) to make
> this bug occur way more often than it used to, and we're not quite sure
> what, but anyway, the problem is known to the relevant developers so
> hopefully might get fixed soonish.
> 
> Hardware details aren't needed because it occurs for many developers on
> diverse hardware.
> 

Where is this tracked so we can follow along?

Kind regards
Till
___
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: @fedoraproject.org email in Bugzilla

[Till Hofmann]

On 10/24/18 1:54 PM, Christopher wrote:
> On Wed, Oct 24, 2018, 06:19 Till Hofmann  <mailto:thofm...@fedoraproject.org>> wrote:
> 
> Hi all,
> 
> I've been using my @fedoraproject.org <http://fedoraproject.org>
> email alias in Bugzilla for a
> while. I regularly get those complaining emails that I should fix my
> account, specifically it says:
> 
> > If you recently changed the email address associated with your
> > Fedora account in the Fedora Account System, it is now out of sync
> > with your bugzilla.redhat.com <http://bugzilla.redhat.com>
> account. This leads to problems
> > with Fedora packages you own or are CC'ed on bug reports for.
> 
> 
> However, I don't see any of those issues. New bug reports on my packages
> are assigned to me properly, and CC'ing also seems to work fine.
> 
> Is there still a reason I should *not* use my @fedoraproject.org
> <http://fedoraproject.org> email
> alias in Bugzilla?
> 
> 
> I do the same thing. I think somebody had to manually add me to some
> whitelist to stop getting those spammy notices. Other Fedora services,
> like pagure and discourse also have issues forcing the use of your
> forwarding email address instead of your @fedoraproject.org
> <http://fedoraproject.org> email alias, because that's the email
> provided by Fedora auth service. It's quite annoying. If you change your
> forwarding email, you've got to fix it in multiple places, defeating the
> whole purpose of a centralized Fedora id.

Good to know. So I assume if I don't care about the e-mails, I don't
need to do anything.

Thanks!
Till
___
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

@fedoraproject.org email in Bugzilla

[Till Hofmann]

Hi all,

I've been using my @fedoraproject.org email alias in Bugzilla for a
while. I regularly get those complaining emails that I should fix my
account, specifically it says:

> If you recently changed the email address associated with your
> Fedora account in the Fedora Account System, it is now out of sync
> with your bugzilla.redhat.com account. This leads to problems
> with Fedora packages you own or are CC'ed on bug reports for.


However, I don't see any of those issues. New bug reports on my packages
are assigned to me properly, and CC'ing also seems to work fine.

Is there still a reason I should *not* use my @fedoraproject.org email
alias in Bugzilla?

Thanks,
Till
___
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: Yet another gargantuan mathematical software update

[Till Hofmann]

On 10/12/18 9:14 PM, Jerry James wrote:
> On Sun, Oct 7, 2018 at 7:33 AM Till Hofmann  
> wrote:
>> FYI: gazebo is currently FTBFS because player is FTBFS. I looked into
>> player and fixed two smaller issues [1], but it's still FTBFS [2]. It
>> looks like it's still requiring python2 but uses the default python3
>> during build and then fails. So it needs to be migrated to python3...
> 
> Okay, I will skip gazebo ... and fawkes too, then, right?  Thanks,
> 

Yes, I'm afraid so.

Thanks,
Till
___
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: Yet another gargantuan mathematical software update

[Till Hofmann]

On 10/7/18 2:17 AM, Jerry James wrote:
> Hi folks,
> 
> It's about time for another "update the world" moment for some of the
> mathematical software we have in Fedora.  I'm going to try to clear
> away a big chunk of my backlogged package work with this update, so it
> will be even bigger than usual.  Primary goals are to switch from
> atlas or the reference blas to openblas, and to drop python 2
> packages.
> 
> I plan to do all of the necessary rebuilds myself.  Package
> maintainers, if you would rather that I did not rebuild your package
> for you, please let me know.  Otherwise, I will do all of these builds
> in approximately 1 week from today.  I plan to build for Rawhide only.
> 
> As usual with this package set, the rebuilds will take a few days, so
> expect broken dependencies in the middle.
> 
> gazebo: rebuild for tbb

FYI: gazebo is currently FTBFS because player is FTBFS. I looked into
player and fixed two smaller issues [1], but it's still FTBFS [2]. It
looks like it's still requiring python2 but uses the default python3
during build and then fails. So it needs to be migrated to python3...


Regards,
Till

[1] https://src.fedoraproject.org/rpms/player/pull-request/3
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=30098425
___
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: SONAME bump for armadillo

[Till Hofmann]

b

On 08/18/2018 01:58 AM, José Abílio Matos wrote:
> On Friday, 17 August 2018 16.53.37 WEST José Abílio Matos wrote:
>> reveals that the only packages that require armadillo are:
>>  * gdal
>>  * mlpack
>>  * mmseq
> 
> OK, after following the prescribed procedure for rawhide I had only a problem 
> with gdal, that was already failing before so no change here.
> 
> The build fails with an error that I have never saw before:
> 
> libtool: link: unable to infer tagged configuration
> libtool:   error: specify a tag with '--tag'
> 
> 
> Comparing this equivalent part of the build log between 2.3.1-2 and 2.2.4-7 
> (the last version that builds from 2018-07-03) by converting all empty spaces 
> to a white line we get and ignoring the version we get (only the first chunk 
> seems relevant):
> 
> $ diff -u 2.2.4 2.3.1
> --- 2.2.4   2018-08-17 18:55:36.580545048 +0100
> +++ 2.3.1   2018-08-17 18:55:39.704555254 +0100
> @@ -1,10 +1,14 @@
>  /usr/bin/libtool
> ---mode=linkg++
> +--mode=link
> +--silent
> +g++
>  -Wl,-z,relro
> +-Wl,--as-needed
> 
>  -Wl,-z,now
>  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> 
> +-lcrypto
>  -larmadillo
>  -lpoppler
>  -ljson-c
> 
> Does this rings a bell to anyone about what is wrong with this libtool call?
> 


There is an ongoing discussion here:
https://bugzilla.redhat.com/show_bug.cgi?id=1606875


Kind regards,
Till
___
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/FODIBMUXFFLRV3Q4PJ7FBAG7TIGCU4KW/

Re: Packages with scriptlets which call ldconfig

[Till Hofmann]

On 06/28/2018 03:30 AM, Jason L Tibbitts III wrote:
> In Fedora 28 and newer, it is no longer necessary for most packages
> which install shared libraries to have scriptlets which call ldconfig:
> https://fedoraproject.org/wiki/Packaging:Scriptlets#Shared_Libraries
> 
> For your convenience, I ran the find-ldconfig-calls script from
> https://pagure.io/fedora-misc-package-utilities to find all source
> packages in rawhide which produce binary packages with scriptlets that
> call ldconfig.  I found 2239 packages.  Due to the length of this list,
> I only did spot checks for correctness, so please accept my apologies if
> some packages are misidentified (but let me know so that I can correct
> the script).

Not strictly a script error: I already updated most of my packages
without rebuilding them, so they are all false positives. I guess I'm
not the only one who updated the Spec without a rebuild, so I'm not sure
checking the source packages is the best approach. Is it possible to
directly check the Spec?

Kind regards
Till
___
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/7NEVZG7PXTBAOUYJ72R7LJIGMIYVZXQ2/

Re: Nonresponsive maintainer: guidograzioli

[Till Hofmann]

On 06/04/2018 10:14 AM, Till Hofmann wrote:
> Hi all,
> 
> I'm trying to get in contact with Guido Graizoli (FAS guidograzioli). He
> has not responded to a bug report requesting an update of bibtex2html
> [1]. The package is currently also FTBFS [2], where he did not respond
> either. I also tried contacting him privately by e-mail, but I did not
> get a response.

I reached Guido through his private e-mail. He'll reassign/orphan some
of his packages and take care of the rest.

Kind regards,
Till
___
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/MUWMT2SCNSNPG2EMZ6B6OBNBGXRHDHB3/

Nonresponsive maintainer: guidograzioli

[Till Hofmann]

Hi all,

I'm trying to get in contact with Guido Graizoli (FAS guidograzioli). He
has not responded to a bug report requesting an update of bibtex2html
[1]. The package is currently also FTBFS [2], where he did not respond
either. I also tried contacting him privately by e-mail, but I did not
get a response.

According to fedora-active-user, he was last active last year. There are
other open bugzilla tickets [3].

Does anyone know how to get in contact with Guido?

Thanks!
Till

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1425075
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1555634
[3]
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=%20guido.grazioli%40gmail.com&emailassigned_to1=1&emailtype1=substring&list_id=8924876&query_format=advanced
___
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/QL5BSLX7PUHSB4XTYDU27MUZKP7JZWE7/

Re: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Till Hofmann]

On 03/08/2018 03:54 PM, Kevin Kofler wrote:
> I wrote:
>> Fedora:
>>> Beta and Final freezes are in effect from 00:00 UTC of the freeze day.
>>
>> KDE:
>>> All deadlines are due 23:59 UTC, but if you need a few more hours, notify
>>> someone from the release team.
> 
> PS: The deadlines I encountered for academic CfPs were also KDE style (23:59 
> in a specified time zone), or in very rare occasions at a specified time 
> during the say, e.g., noon (12:00), but never Fedora style (00:00).

Academic deadlines are often even 23:59 UTC-12, so you can always submit
on the day of the deadline at any time of your local time, no matter
where you live.

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

Re: News in opencv package

[Till Hofmann]

On 03/02/2018 08:31 PM, Sérgio Basto wrote:
> On Fri, 2018-03-02 at 10:55 -0800, Adam Williamson wrote:
>> On Fri, 2018-03-02 at 18:39 +, Sérgio Basto wrote:
>>>
>>> player will fail due a glibc problem 
>>
>> Can you elaborate? You've tried a build and it blew up?
>>
>> I am starting to get rather worried about this new glibc that landed
>> yesterday. I think it might be breaking several things.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1533278#c1
> 
> player is FTBFS since glibc 2.27, is not new . 
> 
> 

I was just going to take a look, but it seems like Rich already fixed
player last week:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1036515
https://src.fedoraproject.org/rpms/player/c/d9eb02da8958a22915a6fd0b24f99397b0ac84e4?branch=master

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

Re: News in opencv package

[Till Hofmann]

On 03/02/2018 12:24 PM, Josef Ridky wrote:
> Hi folks,
> 
> I would like to inform you, that new version of opencv package (3.4.1) will 
> be available in rawhide and Fedora 28.
> All packages, that requires opencv should be rebuild.
> 

It would be nice if the announcement would have been made a week in
advance, as stated in the guidelines, and as currently discussed in the
other thread.
https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

For completeness' sake, here's the list of packages:

$ dnf repoquery --disablerepo='*' --enablerepo='fedora'
--releasever=rawhide --alldeps --whatrequires 'libopencv*'
OpenImageIO-0:1.8.8-2.fc28.i686
OpenImageIO-0:1.8.8-2.fc28.x86_64
OpenImageIO-iv-0:1.8.8-2.fc28.x86_64
OpenImageIO-utils-0:1.8.8-2.fc28.x86_64
YafaRay-0:3.3.0-7.fc28.x86_64
YafaRay-lib-0:3.3.0-7.fc28.x86_64
digikam-0:5.8.0-4.fc28.x86_64
digikam-libs-0:5.8.0-4.fc28.i686
digikam-libs-0:5.8.0-4.fc28.x86_64
fawkes-firevision-0:1.0.1-13.fc28.i686
fawkes-firevision-0:1.0.1-13.fc28.x86_64
fawkes-guis-0:1.0.1-13.fc28.i686
fawkes-guis-0:1.0.1-13.fc28.x86_64
frei0r-plugins-opencv-0:1.6.1-4.fc28.x86_64
gmic-0:2.1.8-2.fc28.i686
gmic-0:2.1.8-2.fc28.x86_64
libfreenect-opencv-0:0.5.5-4.fc28.i686
libfreenect-opencv-0:0.5.5-4.fc28.x86_64
mlt-0:6.6.0-3.fc28.i686
mlt-0:6.6.0-3.fc28.x86_64
mrpt-2d-slam-0:1.4.0-6.fc28.x86_64
mrpt-apps-0:1.4.0-6.fc28.x86_64
mrpt-base-0:1.4.0-6.fc28.i686
mrpt-base-0:1.4.0-6.fc28.x86_64
mrpt-camera-calibration-0:1.4.0-6.fc28.x86_64
mrpt-gridmap-navigation-0:1.4.0-6.fc28.x86_64
mrpt-libs-0:1.4.0-6.fc28.i686
mrpt-libs-0:1.4.0-6.fc28.x86_64
mrpt-navlog-viewer-0:1.4.0-6.fc28.x86_64
mrpt-rawlog-viewer-0:1.4.0-6.fc28.x86_64
mrpt-reactive-navigation-0:1.4.0-6.fc28.x86_64
mrpt-robotic-arm-kinematics-0:1.4.0-6.fc28.x86_64
mrpt-scene-viewer-0:1.4.0-6.fc28.x86_64
mrpt-stereo-camera-calibration-0:1.4.0-6.fc28.x86_64
nomacs-0:3.8.0-1.fc28.i686
nomacs-0:3.8.0-1.fc28.x86_64
opencv-0:3.3.1-4.fc28.i686
opencv-0:3.3.1-4.fc28.x86_64
opencv-contrib-0:3.3.1-4.fc28.i686
opencv-contrib-0:3.3.1-4.fc28.x86_64
opencv-core-0:3.3.1-4.fc28.i686
opencv-core-0:3.3.1-4.fc28.x86_64
opencv-devel-0:3.3.1-4.fc28.i686
opencv-devel-0:3.3.1-4.fc28.x86_64
os-autoinst-0:4.5-4.20180208gitab8eeda.fc28.x86_64
php-facedetect-0:1.1.0-10.fc28.x86_64
player-0:3.1.0-4.fc27.i686
player-0:3.1.0-4.fc27.x86_64
python2-opencv-0:3.3.1-4.fc28.x86_64
python2-openimageio-0:1.8.8-2.fc28.x86_64
python3-opencv-0:3.3.1-4.fc28.x86_64
simarrange-0:0.0-16.20170316git8238ce5.fc28.x86_64
simon-0:0.4.1-15.fc28.x86_64
simon-libs-0:0.4.1-15.fc28.i686
simon-libs-0:0.4.1-15.fc28.x86_64
siril-0:0.9.8-1.fc28.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Exclude paths for elfdeps dependency generator

[Till Hofmann]

On 02/20/2018 05:33 PM, Till Hofmann wrote:
> Hi all,
> 
> I have a question regarding the the RPM dependency generator scripts.
> I'm working on packaging the ROS stack [1,2] and I'm currently dealing
> with the dependency generation. My goal is to wrap all Provides and
> Requires for sonames because ROS does not use proper sonames (and
> therefore they shouldn't be in the ld cache), but I still want to use
> the information for ROS packages. This means I want to replace:
> 
> Provides: librosconsole.so()(64bit)
> =>
> Provides: ros(librosconsole.so()(64bit))
> [or possibly ros-kinetic(librosconsole.so()(64bit))]
> 
> and similarly for Requires.
> 
> I have a working solution [3] that wraps all ROS Provides and Requires
> and generates other Provides and Requirest just as elfdeps does, but it
> uses an (imho ugly) hack: As I don't want to have the normal Provides
> generated by elfdeps, I have:
> 
> %__ros_path ^/usr/lib.*/ros/.*$
> %__elf_exclude_path %__ros_path
> 
> 
> in /usr/lib/rpm/fileattrs/ros.attr. I see two problems: If
> %__elf_exclude_path is set by something else, it is overridden, because
> I couldn't figure out how to append to the exclude path. Second,
> %__elf_exclude_path should not be set at all in ros.attr, the doc [4] says:
> "NAME needs to be replaced by the name choosen for the file attribute
> and needs to be the same as the file name of the macro file itself"
> 
> It still works, but shouldn't according to the documentation.
> 
> So my question: Is there any other way to exclude the ROS dir to be
> checked by elfdeps? I cannot just use %__requires_exclude_from because I
> want my dependency generator to run on the directory.


Bump.
This is the current content of the ros.attr file, if it helps:

%__ros_provides %{_rpmconfigdir}/ros.prov
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__ros_requires %{_rpmconfigdir}/ros.req
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__ros_path ^/usr/lib.*/ros/.*$
%__ros_magic ^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$
%__ros_flags exeonly,magic_and_path
%__elf_exclude_path %__ros_path

Is the last line acceptable? If not, how else can I exclude the ROS
directory (%__ros_path) from being scanned by the ELF dependency generator?

Thanks,
Till

> 
> Thanks for any hints.
> 
> Kind regards,
> Till
> 
> [1] https://pagure.io/ros
> [2] https://copr.fedorainfracloud.org/coprs/thofmann/ros/
> [3] https://pagure.io/ros-rpm-macros
> [4] http://rpm.org/user_doc/dependency_generators.html
> ___
> 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: Lazarus vs. FPC updates

[Till Hofmann]

On 02/26/2018 12:53 PM, Artur Iwicki wrote:
> Is there a way I can automatically do something like "BuildRequires: fpc 
> (whatever version); Requires: fpc = version-used-during-build", or would I 
> have to control this manually?

You can define an RPM macro for the version in fpc, e.g., by adding a
file /usr/lib/rpm/macros.d/macros.fpc with the line

%_fpc_version X.Y.Z

and then use

Requires: fpc = %_fpc_version

in the Lazarus spec.

You will still need to update the macro definition on every FPC update.


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

Exclude paths for elfdeps dependency generator

[Till Hofmann]

Hi all,

I have a question regarding the the RPM dependency generator scripts.
I'm working on packaging the ROS stack [1,2] and I'm currently dealing
with the dependency generation. My goal is to wrap all Provides and
Requires for sonames because ROS does not use proper sonames (and
therefore they shouldn't be in the ld cache), but I still want to use
the information for ROS packages. This means I want to replace:

Provides: librosconsole.so()(64bit)
=>
Provides: ros(librosconsole.so()(64bit))
[or possibly ros-kinetic(librosconsole.so()(64bit))]

and similarly for Requires.

I have a working solution [3] that wraps all ROS Provides and Requires
and generates other Provides and Requirest just as elfdeps does, but it
uses an (imho ugly) hack: As I don't want to have the normal Provides
generated by elfdeps, I have:

%__ros_path ^/usr/lib.*/ros/.*$
%__elf_exclude_path %__ros_path


in /usr/lib/rpm/fileattrs/ros.attr. I see two problems: If
%__elf_exclude_path is set by something else, it is overridden, because
I couldn't figure out how to append to the exclude path. Second,
%__elf_exclude_path should not be set at all in ros.attr, the doc [4] says:
"NAME needs to be replaced by the name choosen for the file attribute
and needs to be the same as the file name of the macro file itself"

It still works, but shouldn't according to the documentation.

So my question: Is there any other way to exclude the ROS dir to be
checked by elfdeps? I cannot just use %__requires_exclude_from because I
want my dependency generator to run on the directory.

Thanks for any hints.

Kind regards,
Till

[1] https://pagure.io/ros
[2] https://copr.fedorainfracloud.org/coprs/thofmann/ros/
[3] https://pagure.io/ros-rpm-macros
[4] http://rpm.org/user_doc/dependency_generators.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: package conflict with source package but not with binary package

[Till Hofmann]

On 12/30/2017 09:44 PM, Dominik 'Rathann' Mierzejewski wrote:
> Hi, Till.
> 
> On Saturday, 30 December 2017 at 17:27, Till Hofmann wrote:
> [...]
>> So, I'm wondering:
>> 1. Can I add "Provides: bear = %{version}-%{release}", as bear does not
>> provide a bear binary package? To me, this seems risky and confusing,
>> but it would solve the issue.
>> 2. If not, would it make sense to rename the current bear (source)
>> package into something else, e.g., bear-factory, so we can use 'bear'
>> for the compilation database?
> 
> Option 2 makes most sense in light of what you wrote. Thank you for
> the thorough research on this matter. If I were the current bear
> package maintainer, I'd agree with your reasoning.
> 

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1539207.

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

non-responsive maintainer: radford

[Till Hofmann]

Hi all,

I'm trying to contact Jim Radford (radford) per non-responsive
maintainer policy [1]. I contacted Jim several times on bz#1505463 [2]
and also sent a private e-mail to his email account shown in FAS.

If you know how to get in touch with Jim, please let me know.

Kind regards,
Till


[1]
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1505463
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

[Till Hofmann]

On 01/09/2018 05:53 PM, Sérgio Basto wrote:
> Packages remaining to rebuild:
> digikam
> fawkes
> kf5-libkface
> nomacs
> player
> simon
> 
> Provenpackager request for: 
> Do fedpkg build in fawkes master [3] 

> [3]
> https://src.fedoraproject.org/rpms/fawkes/commits/master
>


That won't help because fawkes ist still FTBFS after the last protobuf
bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093

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

package conflict with source package but not with binary package

[Till Hofmann]

Hi all,

I'm preparing Bear [1] as a Fedora package. Unfortunately, the package
name bear is already taken by the bear engine [2], so I'm considering
the best way to resolve this. Ubuntu [3], Debian [4], Arch (AUR) [5],
and Mint [6] all package the compilation database (i.e., the package I'm
working on) as bear, while the game engine (the current bear in Fedora)
is usually packaged as bear-factory. IMHO, providing the compilation
database as bear would be very beneficial, and anything else might be
confusing for the users.

I noticed that bear does not actually provide a bear package, but only
bear-engine, bear-devel, and bear-factory.

So, I'm wondering:
1. Can I add "Provides: bear = %{version}-%{release}", as bear does not
provide a bear binary package? To me, this seems risky and confusing,
but it would solve the issue.
2. If not, would it make sense to rename the current bear (source)
package into something else, e.g., bear-factory, so we can use 'bear'
for the compilation database?

I also asked upstream about possible alternatives [7], and the best
answer seems to be buildear, but imho that's far from ideal.

Kind regards,
Till

[1] https://github.com/rizsotto/Bear
[2] https://src.fedoraproject.org/rpms/bear
[3] https://packages.ubuntu.com/trusty/devel/bear
[4] https://packages.debian.org/sid/bear
[5] https://aur.archlinux.org/packages/bear/
[6] https://community.linuxmint.com/software/view/bear
[7] https://github.com/rizsotto/Bear/issues/198
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "shield"

[Till Hofmann]

On 12/17/2017 01:11 AM, Benjamin Kreuter wrote:
> Sorry if this was discussed already, but it looks like Firefox 57 on
> Fedora 26 (and I assume 27 but have not checked) in the Fedora repo has
> "extension.shield-recipe-client.enabled = true".
> 
> 1)  Is there a reason this is not turned off by default?  This is being
> used to install extensions without notifying users.

I wonder if this is related to Mr. Robot extension that was
automatically installed without user's consent:
https://www.cnet.com/news/mozilla-backpedals-after-mr-robot-firefox-misstep/

> 
> 2)  At what point will it be appropriate to consider changing the
> default browser?  This is just the latest in a series of questionable
> things Mozilla has done.
> 
> -- Ben
> 
> 
> 
> ___
> 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: Wiki search?

[Till Hofmann]

On 12/10/2017 02:21 PM, Radka Janekova wrote:
> Hi,
> 
> is it just me or there is no way to search the new wiki? Could we pretty
> please have easily accessible search bar, or have a search button under
> the obvious "Navigation" drop down? Anything would do the trick really...
> 

Should be back soon:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EUF3FPRKSJ6MNEDDCFMZ6OTYBSOS6OMT/

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

Re: Do I need Epoch: for downgrades in rawhide?

[Till Hofmann]

On 10/15/2017 08:08 PM, Randy Barlow wrote:
> On 10/15/2017 12:34 PM, Neal Gompa wrote:
>> I would suggest that you submit librealsense1 as a separate package,
>> instead. The applications that use the older versions should probably
>> be linked to the older one, but things should progressively migrate to
>> the newer one.
> 
> This sounds like a reasonable suggestion to me, but I'll add that it
> would be good to file a Change Request for this too, so that users and
> other developers have a heads up about the change:
> 
> https://fedoraproject.org/wiki/Changes/Policy
> 

Thanks for the suggestions. I'll submit librealsense1 as a separate
package and file a Change Request.

Just to be clear on the order: I should probably submit the Change
Request first and then submit the package, right?

Kind regards,
Till



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Do I need Epoch: for downgrades in rawhide?

[Till Hofmann]

Hi all,

if I want to downgrade a package in rawhide only (I only pushed the
update to rawhide), do I need to add an Epoch?

background:
I updated librealsense to librealsense2 and afterwards realized that the
new library is a major rewrite that does not support older camera
models. After consulting with upstream, I came to the conclusion that we
should stay with version 1 for the librealsense package and submit
librealsense2 as a separate package. I think Debian is planning to do
the same thing. Therefore, I need to downgrade librealsense in rawhide
to version 1.

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

Re: Why is Fx 57 in Updates Testing?

[Till Hofmann]

On 10/12/2017 11:32 AM, Pierre-Yves Chibon wrote:

On Thu, Oct 12, 2017 at 11:22:52AM +0200, Till Hofmann wrote:

Actually, as a regular desktop user, I'd be surprised if I got the FF57 with
a regular update without upgrading to the latest Fedora release. I don't
think FF57 should be in F26 at all.


Looking at the updates in bodhi, F26 was release with firefox-52, so you already
upgraded a few times :)


Yes, but that wasn't branded as all-new, better-than-ever Firefox (which 
it is), that intentionally breaks stuff which is directly visible by the 
end-user. An update that breaks the majority of extensions is very hard 
to sell for a stable release, as much as I love the new Firefox.


From an admin POV, this will result in lots of users complaining about 
their broken browsers, and probably at the wrong time, because not 
scheduled by the admin.


Also, as someone else has already mentioned in this thread, this is not 
really in line with the updates policy. I'm not saying we shouldn't 
receive updates for Firefox, but I think it should get an exception, so 
everyone actually knows when and why Firefox gets (or doesn't get) updates.




On my side, I do like having the latest firefox, also on my old F25.


Me too, but I don't like my boss complaining about his broken web browser.

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

Re: Why is Fx 57 in Updates Testing?

[Till Hofmann]

On 10/11/2017 10:58 PM, Zbigniew Jędrzejewski-Szmek wrote:


I don't get the whole kerfuffle about FF57 being beta: F27 is in beta
now too, and it's the time to test what will be in the relased version,
and using a pre-release of a package seems to be a better way to do
this than using some old version that will be soon replaced.
If we had a different updates policy for Firefox in Fedora, things
would be different, but we don't.



FF57 was also pushed to F26 updates-testing. F26 is not beta but a 
stable release. I have updates-testing enabled on my main machine to 
find unexpected package breakages and give feedback about them, which is 
the whole purpose of updates-testing. If this breaks my main web browser 
(which could have been expected), I'll just disable updates-testing 
again. This means less testing of updates, which a lot of people 
(rightfully) complain about anyway. That's why I think such an update 
should not go into a stable release's updates-testing.


Actually, as a regular desktop user, I'd be surprised if I got the FF57 
with a regular update without upgrading to the latest Fedora release. I 
don't think FF57 should be in F26 at all.


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

Re: Why is Fx 57 in Updates Testing?

[Till Hofmann]

On 10/11/2017 04:00 PM, Martin Stransky wrote:

On 10/11/2017 03:52 PM, Tomasz Torcz wrote:

On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose?  Fx 57 is BETA, and  I was under the impression 
that

BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to test
software planned for Fedora thus I don't see any problem here.


   It's *updates*-testing repo and software in it should not be 
'planned',

but basically 'ready' for Fedora.
   If you want testing repo for experienced users, use COPR.


I don't see it that way. Is that your personal statement or is that 
written in any Fedora rules? I don't see that at Fedora page [1].



The very first sentence of the page you linked above:

The updates-testing repository, also referred to as Test Updates, contains 
updates scheduled to be released for Branched pre-releases (after the Bodhi 
enabling point) and stable releases of Fedora


The point is that your update is not intended to ever make it to the 
stable update, i.e., it is not "scheduled to be released" for anything. 
If I understood correctly, you want people to test the beta version and 
then eventually submit the final release (i.e., not this update) to 
stable. I don't think that's how the updates-testing repository is 
supposed to be used. Instead, it should only contain updates that will 
eventually make it into stable.


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

Re: Self Introduction: David Hendricks

[Till Hofmann]

On 10/02/2017 12:10 PM, Igor Gnatenko wrote:

On Mon, 2017-10-02 at 05:39 -0400, Charalampos Stratakis wrote:

Hello and welcome!

Please, avoid using top posting..

See: https://fedoraproject.org/wiki/Mailing_list_guidelines#Proper_post
ing_style


From the same section:
"Please, remove the irrelevant part of the previous communication (in 
case of more than a single correspondence)".


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

Re: Packages giveaway

[Till Hofmann]

On 09/20/2017 09:57 AM, Fabio Alessandro Locati wrote:
Clearly this is not working very well, so I'm giving up all my Point of 
Contacts position on packages.
I will try to work on them, even if I'm not th PoC anymore, but I don't 
want to keep those packages stuck due to my (un)availability.



Those are the list of packages I just orphanated:


sway -- i3-compatible window manager for Wayland


I'm interested in taking sway, but it seems to be broken atm, it 
segfaults right after login (F26). Is that a known issue? Have you had a 
look at it?


If not, I'll give it a try.

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

Re: How to chainbuild in a build override?

[Till Hofmann]

On 09/23/2017 02:05 AM, Kevin Kofler wrote:

Petr Pisar wrote:

In rawhide, if you want a longer time isolation, you ask relengs for
a sige tag, you do all builds there without affecting others and then
you ask relengs to merge the builds back to rawhide. Of course this has
same races and one needs to reaply all rawhide changes into the side tag
otherwise a mismatches can happen after the merge.

I don't know if this procedure is acceptable for f27.


It is possible to do this (request a side tag) in a release. The KDE SIG
frequently does this for larger updates, the GNOME team sometimes does too.

That said, side tags do put a strain on the infrastructure and thus should
only be used where it makes sense.



Why is that? Asking purely out of curiosity.

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

Re: How to use COPR + Tito + dist-git?

[Till Hofmann]

On 28.03.2017 14:23, Miroslav Suchý wrote:
> Dne 28.3.2017 v 10:40 Till Hofmann napsal(a):
>> I'm playing around with Tito and COPR following [1,2]. It works great so
>> far, but I'm still having problems with loading the sources to a
>> lookaside cache. I've found a blog post that uses git-annex [3], but the
>> COPR builders do not have git-annex installed. According to another blog
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1426033

That would certainly help.

> 
>> post [4], I should be able to use COPR with dist-git. Unfortunately, I
>> couldn't find any further information on COPR + dist-git. Is there some
>> documentation that I missed? In particular, does anyone have a sample
>> configuration for using COPR + Tito + dist-git?
> 
> This is little bit vague. Can you elaborate more what you are trying to 
> achive? Where you have sources? Where you have
> spec? Are you upstream? Or you just packaging it?
> 

I'm just packaging it, upstream sources are in a separate repository.
I'm basically trying to follow the same workflow as with regular Fedora
packages: Spec file in my repository, and a reference to an upstream
tarball in the repository (although just fetching Source0 would be fine
too). I just want to avoid adding SRPMs or upstream tarballs to the
repository. Ideally, Tito would fetch the upstream tarball and build the
package with the Spec file in my repository. In order to do this, I need
to upload the source to some lookaside cache, which is then used by Tito
(which would already work if the builders had git-annex installed).

Ultimately, I want to manage a number of related packages in a single
repository and build all the packages with COPR.

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

How to use COPR + Tito + dist-git?

[Till Hofmann]

Hi all,

I'm playing around with Tito and COPR following [1,2]. It works great so
far, but I'm still having problems with loading the sources to a
lookaside cache. I've found a blog post that uses git-annex [3], but the
COPR builders do not have git-annex installed. According to another blog
post [4], I should be able to use COPR with dist-git. Unfortunately, I
couldn't find any further information on COPR + dist-git. Is there some
documentation that I missed? In particular, does anyone have a sample
configuration for using COPR + Tito + dist-git?

Thanks for any pointers!
Till

[1] http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr/
[2]
http://miroslav.suchy.cz/blog/archives/2013/12/17/how_to_create_new_release_of_rpm_package_in_5_seconds/
[3]
https://m0dlx.com/blog/Reproducible_builds_on_Copr_with_tito_and_git_annex.html
[4] http://blog.samalik.com/copr-dist-git-and-patternfly/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Taking orphaned package ctemplate

[Till Hofmann]

Hi all,

I'm taking the ctemplate package. The package was unretired about a year
ago but it was never built after unretirement. After I filed a ticket
about the missing builds [1], the package was orphaned without further
comments.

The package is still functional and (somewhat) maintained upstream, so I
don't see a reason for retirement.

Regards,
Till

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1433290
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring yap (Prolog interpreter)

[Till Hofmann]

On 23.02.2017 17:18, Petr Pisar wrote:
> I'm deeply sorry I will have to retire yap package because:
> 
> It crashes on i686 after updating GCC to 7
> .
> Last stable version is 7 years old (we have it in Fedora).
> Last development version is 4 years old (Jerry James tried to update
> but it does not work with non-lazy linking) and it fails on i686 too 
> .
> Upstream does not respond
>  and playing
> with the code reveals other bugs like signed interger overflows or
> linkage failure with disabled optimizations because of wrong inlining.
> Finally I don't understand the code especially the stack-based
> interpreter.

Just another piece of information which may be relevant for anyone
interested in taking care of the package: It looks like the project was
pretty active until Feb 11, 2016, but there are no commits after that. I
don't know if you've tried building the latest git version or only the
latest development release.

As an update would bring major changes, a re-review would probably a
good idea anyway.


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

Re: unheeded ACL requests

[Till Hofmann]

On 02/12/2017 04:05 AM, Globe Trotter wrote:
> Hello,
> 
> For a long time (almost 2 years), dilo (and a number of packages) have
> not been updated. So, I decided to request commit privileges. But the
> request has sat unheeded for the last several months. Unfortunately,
> this is not true only for dillo, but also for a bunch of other packages
> (eg: revelation, xplanet, spacefm, etc). Is there a way to get things to
> move at all? 

This should help:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers


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

Re: rpmlint: wrong-script-interpreter

[Till Hofmann]

On 02/06/2017 04:39 AM, Pranav Kant wrote:
> Hi Michael,
> 
> On Mon, Feb 6, 2017 at 3:31 AM, Michael Catanzaro  > wrote:
> 
> Dude it looks like you have a tracking pixel in your mail:
> 
> http://405n.mj.am/oo/AEUAHWjyTGwAAC8AAAMA
> AAQnNwBYl01S75wFdcYGRwyu2D_3puuyegAD-So/0b56895f/e.gif
>  AAQnNwBYl01S75wFdcYGRwyu2D_3puuyegAD-So/0b56895f/e.gif>" height="1"
> width="1" alt="" border="0" style="height:1px;width:1px;border:0;"/>
> 
> Is that intentional? What's up with that!
> 
> 
> No, its not intentional at all.

I also see multiple tracking pixels. Even worse, the bodhi link in your
email is not actually a link to bodhi, but a link to the domain
405n.mj.am (maybe a redirect?). The same holds for the link in your
signature.

(My) Thunderbird also warns me that your email is scam. You should
really check your email.


Regards,
Till

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

Re: Request for review swap

[Till Hofmann]

On 18.01.2017 13:09, Mamoru TASAKA wrote:
> Hello, all:
> 
> I have one review request for a package for LXDE:
> https://bugzilla.redhat.com/show_bug.cgi?id=1409243 lxhotkey
> 
> Review swap is appreciated.

I'll take it. Can you please review librealsense:
https://bugzilla.redhat.com/show_bug.cgi?id=1413646

Thank you!

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