from:"Vít Ondruch"

Re: Ruby in Rawhide is broken

2024-06-07 Thread Vít Ondruch


This is resolved now.


Vít


Dne 07. 06. 24 v 12:35 Vít Ondruch napsal(a):
The ruby-3.3.1-8.fc41 was untagged a while ago and now I have pushed 
fix into Ruby 3.3.2 PR:


https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/42b0e43e5a8ef84cfc2a7dcc09b0b39ad924f378 



In short, due to changes in RPM 4.20, the `%{_builddir}` macro expands 
differently on different places of RPM. I have reported this upstream:


https://github.com/rpm-software-management/rpm/issues/3151


Vít


Dne 06. 06. 24 v 20:11 Vít Ondruch napsal(a):

This is the problem:

~~~

... snip ...

Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No 
such file or directory.  Stop.


... snip ...

~~~


Vít


Dne 06. 06. 24 v 19:36 Vít Ondruch napsal(a):
I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and 
we don't have generated `rubygem()` provides in e.g. 
ruby-default-gems. I suspect that this might be related to RPM 4.20, 
because I am not aware of any other changes.


I have asked to untag that build 
https://pagure.io/releng/issue/12150 and investigate tomorrow.


Sorry for inconvenience


Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby in Rawhide is broken

2024-06-07 Thread Vít Ondruch

The ruby-3.3.1-8.fc41 was untagged a while ago and now I have pushed fix 
into Ruby 3.3.2 PR:


https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/42b0e43e5a8ef84cfc2a7dcc09b0b39ad924f378

In short, due to changes in RPM 4.20, the `%{_builddir}` macro expands 
differently on different places of RPM. I have reported this upstream:


https://github.com/rpm-software-management/rpm/issues/3151


Vít


Dne 06. 06. 24 v 20:11 Vít Ondruch napsal(a):

This is the problem:

~~~

... snip ...

Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No such 
file or directory.  Stop.


... snip ...

~~~


Vít


Dne 06. 06. 24 v 19:36 Vít Ondruch napsal(a):
I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and 
we don't have generated `rubygem()` provides in e.g. 
ruby-default-gems. I suspect that this might be related to RPM 4.20, 
because I am not aware of any other changes.


I have asked to untag that build https://pagure.io/releng/issue/12150 
and investigate tomorrow.


Sorry for inconvenience


Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby in Rawhide is broken

2024-06-06 Thread Vít Ondruch


This is the problem:

~~~

... snip ...

Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No such 
file or directory.  Stop.


... snip ...

~~~


Vít


Dne 06. 06. 24 v 19:36 Vít Ondruch napsal(a):
I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and 
we don't have generated `rubygem()` provides in e.g. 
ruby-default-gems. I suspect that this might be related to RPM 4.20, 
because I am not aware of any other changes.


I have asked to untag that build https://pagure.io/releng/issue/12150 
and investigate tomorrow.


Sorry for inconvenience


Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Ruby in Rawhide is broken

2024-06-06 Thread Vít Ondruch

I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and we 
don't have generated `rubygem()` provides in e.g. ruby-default-gems. I 
suspect that this might be related to RPM 4.20, because I am not aware 
of any other changes.


I have asked to untag that build https://pagure.io/releng/issue/12150 
and investigate tomorrow.


Sorry for inconvenience


Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads-up: rpm 4.20 alpha in rawhide + rough waters

2024-05-31 Thread Vít Ondruch

Dne 31. 05. 24 v 4:59 Mamoru TASAKA napsal(a):

Hello, ruby-sig f

Panu Matilainen wrote on 2024/05/29 21:31:

Folks, rpm 4.20 alpha landed in rawhide today, and with the sheer
amount of change that went into the bowels of the build code, this
process is being rougher than usual. Apologies for the disruption and
the late heads-up.

Please file bugs with low bar to entry if you suspect an rpmbuild
regression. It's better to have false positives than silent bugs or
people working around the wrong things etc.

So far we're aware of:

- GenericError: srpm mismatch on subpackage debuginfo (so not any
debuginfo, only subpackage debuginfo), is an rpm regression and we're
working on a fix (see the other thread for more details)

- java/mvn package fail on test-related paths
https://bugzilla.redhat.com/show_bug.cgi?id=2283795, this is not a
regresion but an intended change in the rpm build paths layout where
all builds now have a their own specific build-directory whether they
use %setup or not.

The build directory layout change is something the vast majority of
packages will never notice, but packages manipulating paths relative
to "raw" %{_builddir} *may* need to be adjusted.

So again, if in doubt at all, ask or just file a bug.

So now I tried rebuilding all rubygem-foo packages, and one additional
package

is now FTBFS.

* rubygem-abrt

```
Failures:

1) ABRT #handle_exception logs error into syslog when can't
communicate with ABRT daemon because no-one is listeing on the other side
Failure/Error: expect(syslog).to receive(:err).with("%s", /can't
communicate with ABRT daemon, is it running\? Connection refused -(
connect\(2\) for)? "?#{socket_path}"?/)

# received :err with unexpected arguments
expected: ("%s", /can't communicate with ABRT daemon, is it
running\? Connection refused -( connect\(2\) for)?
"?\/bui...ygem-abrt-0.4.0-build\/abrt-0.4.0\/usr\/share\/gems\/gems\/abrt-0.4.0\/spec\/abrt_handler_spec.rb"?/)
got: ("%s", "can't communicate with ABRT daemon, is it
running? too long unix socket path (114bytes given but 108bytes max)")

Diff:
@@ -1,3 +1,3 @@
["%s",
- /can't communicate with ABRT daemon, is it running\?
Connection refused -( connect\(2\) for)?
"?\/builddir\/build\/BUILD\/rubygem-abrt-0.4.0-build\/abrt-0.4.0\/usr\/share\/gems\/gems\/abrt-0.4.0\/spec\/abrt_handler_spec.rb"?/]
+ "can't communicate with ABRT daemon, is it running? too long
unix socket path (114bytes given but 108bytes max)"]
# ./spec/abrt_handler_spec.rb:140:in `block (5 levels) in (required)>'

```

So looks line %_builddir got longer than before, and the total path
length for socket now exceeds the limitation:

https://man7.org/linux/man-pages/man7/unix.7.html

I had to check the current century in my calendar 臘‍♂️ Thx for
spotting this. I'll try to take a look, although not my highest priority
ATM.

Vít

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

Ruby updates

2024-04-25 Thread Vít Ondruch


Hi everybody,

I have created updates for Ruby in all Fedoras. The Ruby 3.3.1 has 
already landed and here are Bodhi links for the older releases:


https://bodhi.fedoraproject.org/updates/FEDORA-2024-14db7b21a2

https://bodhi.fedoraproject.org/updates/FEDORA-2024-31cac8b8ec

https://bodhi.fedoraproject.org/updates/FEDORA-2024-48bdd3abbf

I am sending heads up here, because yesterday there were complains about 
regressions. There might be issue with 3.3.1 with Bootsnap [1] and some 
complains about Fiddle broken build with 3.1.5 [2]. But the latter lack 
details and the build of Fiddle as shipped with Ruby went just fine.


Please give it and try and provide feedback either via Bohdi or here.


Vít



[1] https://bugs.ruby-lang.org/issues/20450

[2] https://bugs.ruby-lang.org/issues/20451



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Plan to update rubygem-json to 2.7.3

2024-04-19 Thread Vít Ondruch

Thanks for the heads up. I assume you are going to land this just for 
Rawhide, right? And we should also watch Ruby. So far, there is 2.7.2 in 
master and 2.7.1 in Ruby 3.3.



Checking Rails, there seems to be some patches around such as:

https://github.com/rails/rails/pull/51510


For Rspec-rails, these might be the changes:

https://github.com/rspec/rspec-rails/pull/2754

https://github.com/rspec/rspec-rails/pull/2755


Checking Haml / Pundit, they seems to be using OpenStruct just in their 
test suites.



Vít


Dne 19. 04. 24 v 10:31 Mamoru TASAKA napsal(a):

Hello, ruby-sig folks:

I am going to update rubygem-json to 2.7.3 *some day* (when I have 
enough time).


What is preventing me from doing it now is that due to json change 
that now
json makes OpenStruct support (dependency) optional, it causes the 
following

packages FTBFS:

rubygem-actionmailer
rubygem-actionpack
rubygem-actionview
rubygem-haml
rubygem-pundit
rubygem-rspec-rails

c.f.
https://github.com/flori/json/pull/565
https://github.com/flori/json/issues/579

json upstream now requests the each packge to add `require "ostruct"`, so
I am going to apply this change to the above packages (when I have 
enough time).


Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rspec 3.13.0 will hit rawhide

2024-02-12 Thread Vít Ondruch


Thx for the heads up and the updates.


Not sure if you are aware or you just prefer the old way, but it is not 
possible to use side-tag together with `%_with_bootstrap` macro:


https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#_using_macros_in_a_side_tag

https://docs.fedoraproject.org/en-US/fesco/Policy_for_buildroot_macros/


HTH


Vít


Dne 09. 02. 24 v 7:38 Mamoru TASAKA napsal(a):

Hello, ruby-sig folks:

Today I am going to update rspec series to 3.13.0 on F40.
I tried mass rebuild beforehand, and currently it seems this update
causes no additional build failures.

("No additional build failures" means that there are already some
  build failures on some packages, I've excluded the investigation
  on those packages.)

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Minitest 5.22.2 will hit rawhide, with behavior change on empty test

2024-02-08 Thread Vít Ondruch

Thx for heads up. This breakages starts to be new standard it seems, 
because even 5.21.0 broke Railties:


https://src.fedoraproject.org/rpms/rubygem-railties/c/b0803e996eee177c7b1a20255f755aa28522ea01?branch=rawhide

Oh well.


Vít


Dne 08. 02. 24 v 11:23 Mamoru TASAKA napsal(a):

Hello, ruby-sig folks:

I am going to update rubygem-minitest to 5.22.2 on F40.

This version sees some behavior change, perhaps due to:
https://github.com/minitest/minitest/commit/ef839657fe46ecda4f46a6c0fdc670a361374080 



Perviously, if there was no tests actually, Minitest showed the message
like:

```
0 runs, 0 assertions, 0 failures, 0 errors, 0 skips
```

With Minitest 5.22.2, the above message won't be shown.
(Messages like "Run options: --seed 28982" are shown, but the above "0 
errors" messages

 won't appear)

So testsuite which expects this message will going to fail.

At least the following packages are affected by this change:
* rubygem-aruba
* rubygem-railties

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Puma 6.x

2024-01-15 Thread Vít Ondruch



Dne 15. 01. 24 v 11:02 Pavel Valena napsal(a):



On Mon, Jan 15, 2024 at 10:57 AM Pavel Valena  wrote:

On Fri, Jan 12, 2024 at 10:29 AM Vít Ondruch 
wrote:


Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):

On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch
 wrote:

Working on Puma 6.0, I have hit this [1] issue rebuilding
rubygem-shoulda-matchers:

~~~

   1) shoulda-matchers integrates with Rails in a project
that uses Spring
  Failure/Error: run_rake_tasks!('db:drop',
'db:create', 'db:migrate')

  RuntimeError:
    Command

"BUNDLE_GEMFILE=\"/tmp/shoulda-matchers-acceptance/test-project/Gemfile\"

bundle _2.5.3_ exec rake db:drop db:create db:migrate
--trace" exited
with status 1.
    Output:

---START
    bundler: failed to load command: rake (/usr/bin/rake)
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:332:in

`raise_not_found!': Could not find gem 'puma (~> 5.0)' in
locally
installed gems. (Bundler::GemNotFound)

    The source contains the following gems matching
'puma':
  * puma-6.4.2
    from
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:392:in
`block
in prepare_dependencies'
    from
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:377:in
`each'


... snip ...

~~~


The thing is that RoR 7.0 hardcodes `"puma", "~> 5.0"`
dependency. Now
there are two options:

1) Relax the dependency in rubygem-should-matchers.

2) Relax the dependency in RoR in a similar way to RoR
7.1 [3] (and
maybe [4], but I have not hit any issue in anycable 路)


I hope to upgrade to 7.1 soon anyways. I think it's a good
place to fix.









While the former is low impact, I lean towards the
latter, despite
changing the generated application might put some users
into risk. Thoughts?


No severe risk expected; just the test fix [4] you've found.
I'll ideally re-run all RoR test suites which use Puma :). If
you haven't already



I have used MPB, which should rebuild the first level
dependencies. I think this could be enough.


Right.




They've mentioned it (probably) breaks capybara:
https://github.com/puma/puma/blob/master/6.0-Upgrade.md#upgrade



It does break older version of capybara, but the update you
have pushed like two days ago seems to be fine.




Some testing (with the rebuild above) might be worth the
time. Do you have some PR yet, or should I use your COPR
build[5]?

[5]
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885218/



No PR, the Copr build should be fine (as fine and stable Puma
can be ). But I'd like to land this before today EOD to get
rid of this. So please hurry 


Sorry, I couldn't make it. I'm however failing mock build even now:
```

  1) Error:
TestPumaServer#test_form_data_encoding_windows:
NoMethodError: undefined method `split' for nil

/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/test_puma_server.rb:1791:in
`test_form_data_encoding_windows'

/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:91:in
`block (4 levels) in run'
    /usr/share/ruby/timeout.rb:186:in `block in timeout'
    /usr/share/ruby/timeout.rb:193:in `timeout'

/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:89:in
`block (3 levels) in run'

  2) Error:
TestPumaServer#test_form_data_encoding_windows_bom:
NoMethodError: undefined method `split' for nil

/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/test_puma_server.rb:1760:in
`test_form_data_encoding_windows_bom'

/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:91:in
`block (4 levels) in run'
    /usr/share/ruby/timeout.rb:186:in `block in timeout'
    /usr/share/ruby/timeout.rb:193:in `timeout'

/builddir/build/BUILD/puma-6.4.2/usr/share/gems/gems/puma-6.4.2/test/helper.rb:89:in
`block (3 levels) in run'

566 runs, 1523 assertions, 0 failures, 2 errors, 16 skips
error: Bad exit status from /var/tmp/rpm-tmp.pYc1me (%check)

```


Sorry, forgot to check/remove the part about failing build :) before 
submitting. It succeeds a

Re: Puma 6.x

2024-01-12 Thread Vít Ondruch



Dne 11. 01. 24 v 23:10 Pavel Valena napsal(a):

On Thu, Jan 11, 2024 at 4:38 PM Vít Ondruch  wrote:

Working on Puma 6.0, I have hit this [1] issue rebuilding
rubygem-shoulda-matchers:

~~~

   1) shoulda-matchers integrates with Rails in a project that
uses Spring
  Failure/Error: run_rake_tasks!('db:drop', 'db:create',
'db:migrate')

  RuntimeError:
    Command
"BUNDLE_GEMFILE=\"/tmp/shoulda-matchers-acceptance/test-project/Gemfile\"

bundle _2.5.3_ exec rake db:drop db:create db:migrate --trace" exited
with status 1.
    Output:
---START
    bundler: failed to load command: rake (/usr/bin/rake)
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:332:in
`raise_not_found!': Could not find gem 'puma (~> 5.0)' in locally
installed gems. (Bundler::GemNotFound)

    The source contains the following gems matching 'puma':
  * puma-6.4.2
    from
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:392:in
`block
in prepare_dependencies'
    from
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:377:in
`each'


... snip ...

~~~


The thing is that RoR 7.0 hardcodes `"puma", "~> 5.0"` dependency.
Now
there are two options:

1) Relax the dependency in rubygem-should-matchers.

2) Relax the dependency in RoR in a similar way to RoR 7.1 [3] (and
maybe [4], but I have not hit any issue in anycable 路)


I hope to upgrade to 7.1 soon anyways. I think it's a good place to fix.









While the former is low impact, I lean towards the latter, despite
changing the generated application might put some users into risk.
Thoughts?


No severe risk expected; just the test fix [4] you've found. I'll 
ideally re-run all RoR test suites which use Puma :). If you haven't 
already



I have used MPB, which should rebuild the first level dependencies. I 
think this could be enough.





They've mentioned it (probably) breaks capybara:
https://github.com/puma/puma/blob/master/6.0-Upgrade.md#upgrade



It does break older version of capybara, but the update you have pushed 
like two days ago seems to be fine.





Some testing (with the rebuild above) might be worth the time. Do you 
have some PR yet, or should I use your COPR build[5]?


[5] https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885218/



No PR, the Copr build should be fine (as fine and stable Puma can be 
). But I'd like to land this before today EOD to get rid of this. So 
please hurry 



Vít




Thanks for all the work!

Regards,
Pavel



Vít





[1]:
https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885290/

[2]:

https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/railties/lib/rails/generators/app_base.rb#L172

[3]:

https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7f7

[4]: https://github.com/rails/rails/pull/46106


--
___
ruby-sig mailing list --ruby-sig@lists.fedoraproject.org
To unsubscribe send an email toruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Puma 6.x

2024-01-11 Thread Vít Ondruch



Dne 11. 01. 24 v 16:37 Vít Ondruch napsal(a):
Working on Puma 6.0, I have hit this [1] issue rebuilding 
rubygem-shoulda-matchers:


~~~

  1) shoulda-matchers integrates with Rails in a project that uses Spring
 Failure/Error: run_rake_tasks!('db:drop', 'db:create', 'db:migrate')

 RuntimeError:
   Command 
"BUNDLE_GEMFILE=\"/tmp/shoulda-matchers-acceptance/test-project/Gemfile\" 
bundle _2.5.3_ exec rake db:drop db:create db:migrate --trace" exited 
with status 1.

   Output:
---START
   bundler: failed to load command: rake (/usr/bin/rake)
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:332:in 
`raise_not_found!': Could not find gem 'puma (~> 5.0)' in locally 
installed gems. (Bundler::GemNotFound)


   The source contains the following gems matching 'puma':
 * puma-6.4.2
   from 
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:392:in 
`block in prepare_dependencies'
   from 
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:377:in `each'



... snip ...

~~~


The thing is that RoR 7.0 hardcodes `"puma", "~> 5.0"` dependency. Now 
there are two options:


1) Relax the dependency in rubygem-should-matchers.

2) Relax the dependency in RoR in a similar way to RoR 7.1 [3] (and 
maybe [4], but I have not hit any issue in anycable 路)



This is the PR:

https://src.fedoraproject.org/rpms/rubygem-railties/pull-request/3


Vít






While the former is low impact, I lean towards the latter, despite 
changing the generated application might put some users into risk. 
Thoughts?



Vít





[1]: https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885290/

[2]: 
https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/railties/lib/rails/generators/app_base.rb#L172


[3]: 
https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7f7


[4]: https://github.com/rails/rails/pull/46106



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Puma 6.x

2024-01-11 Thread Vít Ondruch

Working on Puma 6.0, I have hit this [1] issue rebuilding 
rubygem-shoulda-matchers:


~~~

  1) shoulda-matchers integrates with Rails in a project that uses Spring
 Failure/Error: run_rake_tasks!('db:drop', 'db:create', 'db:migrate')

 RuntimeError:
   Command 
"BUNDLE_GEMFILE=\"/tmp/shoulda-matchers-acceptance/test-project/Gemfile\" 
bundle _2.5.3_ exec rake db:drop db:create db:migrate --trace" exited 
with status 1.

   Output:
---START
   bundler: failed to load command: rake (/usr/bin/rake)
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:332:in 
`raise_not_found!': Could not find gem 'puma (~> 5.0)' in locally 
installed gems. (Bundler::GemNotFound)


   The source contains the following gems matching 'puma':
 * puma-6.4.2
   from 
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:392:in `block 
in prepare_dependencies'
   from 
/usr/share/gems/gems/bundler-2.5.3/lib/bundler/resolver.rb:377:in `each'



... snip ...

~~~


The thing is that RoR 7.0 hardcodes `"puma", "~> 5.0"` dependency. Now 
there are two options:


1) Relax the dependency in rubygem-should-matchers.

2) Relax the dependency in RoR in a similar way to RoR 7.1 [3] (and 
maybe [4], but I have not hit any issue in anycable 路)



While the former is low impact, I lean towards the latter, despite 
changing the generated application might put some users into risk. Thoughts?



Vít





[1]: https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885290/

[2]: 
https://github.com/rails/rails/blob/fc734f28e65ef8829a1a939ee6702c1f349a1d5a/railties/lib/rails/generators/app_base.rb#L172


[3]: 
https://github.com/rails/rails/commit/545a9908e8f661aa391b5c8e418a5204b1eba7f7


[4]: https://github.com/rails/rails/pull/46106



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

2024-01-04 Thread Vít Ondruch



Dne 04. 01. 24 v 9:39 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 19:43 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of 
all, I'd like to thank to Mamoru for the preparation and lot of 
fixes all around. I really appreciate that.


I think we are well prepared for the rebuild, therefore I have 
requested side-tag:


~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build 
repo to be generated.


~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 



or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 
'ruby-devel' | sort | uniq

~~~


You can take the package and just fire rebuild, but please 
ensure that you are using f40-build-side-80411 build target, 
i.e. the build command should look like:



~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit 
the f40-build-side-80411 target, you'll be building against 
Ruby 3.2 which is not what you want.


If you won't do it by yourself, I'll be rebuilding all packages 
after I am finished with my packages. I'll be using fermig [2] 
to help me with that. If you don't want me to touch your 
packages for whatever reason, please let me know.


As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the 
following:


  1 kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:

for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already 
reported:

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

After libsbml build finishes, I think we can merge ruby33 side 
tag into

F40 build tree.





Thx for the help with rebuilds. I am pondering about a few 
packages, e.g.:



libsolv needs rebuild it seems:

https://github.com/openSUSE/libsolv/issues/548

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


And I think that VIM might fall into the same bucket.



Yep, VIM cannot load vim-command-t and if somebody using the Ruby 
bindings. But I don't think this is major issue and VIM is updated 
quite often. So not a show stopper.


Despite there has been some activity related to the 
kf5-kross-interpreters / openbabel, I'll rather wont wait and merge 
it now. Anybody can rebuild those later.



Vít





Done:

https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d


Vít



CRITPATH update, probably due to DNF. Will look at that tomorrow.



So there actually were some gating failures. I have waved them and the 
update has finally landed. Should there be needed any further fixes, 
please apply them directly in Rawhide, as usually.


Mamoru than you for adding the kf5-kross-interpreters / openbabel in 
the mean time.






Just casually checking Koschei for "ruby" packages, it seems that all of 
them were already rebuilt and I am flattered I can't see any new issue. 
Very nice. Thx all for your great work and your support.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

2024-01-04 Thread Vít Ondruch



Dne 03. 01. 24 v 19:43 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of 
all, I'd like to thank to Mamoru for the preparation and lot of 
fixes all around. I really appreciate that.


I think we are well prepared for the rebuild, therefore I have 
requested side-tag:


~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build 
repo to be generated.


~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 



or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 
'ruby-devel' | sort | uniq

~~~


You can take the package and just fire rebuild, but please 
ensure that you are using f40-build-side-80411 build target, 
i.e. the build command should look like:



~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit 
the f40-build-side-80411 target, you'll be building against Ruby 
3.2 which is not what you want.


If you won't do it by yourself, I'll be rebuilding all packages 
after I am finished with my packages. I'll be using fermig [2] 
to help me with that. If you don't want me to touch your 
packages for whatever reason, please let me know.


As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the 
following:


  1    kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:

for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already 
reported:

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

After libsbml build finishes, I think we can merge ruby33 side 
tag into

F40 build tree.





Thx for the help with rebuilds. I am pondering about a few 
packages, e.g.:



libsolv needs rebuild it seems:

https://github.com/openSUSE/libsolv/issues/548

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


And I think that VIM might fall into the same bucket.



Yep, VIM cannot load vim-command-t and if somebody using the Ruby 
bindings. But I don't think this is major issue and VIM is updated 
quite often. So not a show stopper.


Despite there has been some activity related to the 
kf5-kross-interpreters / openbabel, I'll rather wont wait and merge 
it now. Anybody can rebuild those later.



Vít





Done:

https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d


Vít



CRITPATH update, probably due to DNF. Will look at that tomorrow.



So there actually were some gating failures. I have waved them and the 
update has finally landed. Should there be needed any further fixes, 
please apply them directly in Rawhide, as usually.


Mamoru than you for adding the kf5-kross-interpreters / openbabel in the 
mean time.




Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

2024-01-03 Thread Vít Ondruch



Dne 03. 01. 24 v 18:59 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of 
all, I'd like to thank to Mamoru for the preparation and lot of 
fixes all around. I really appreciate that.


I think we are well prepared for the rebuild, therefore I have 
requested side-tag:


~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build 
repo to be generated.


~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 



or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 
'ruby-devel' | sort | uniq

~~~


You can take the package and just fire rebuild, but please ensure 
that you are using f40-build-side-80411 build target, i.e. the 
build command should look like:



~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit 
the f40-build-side-80411 target, you'll be building against Ruby 
3.2 which is not what you want.


If you won't do it by yourself, I'll be rebuilding all packages 
after I am finished with my packages. I'll be using fermig [2] to 
help me with that. If you don't want me to touch your packages 
for whatever reason, please let me know.


As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the 
following:


  1    kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:

for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already 
reported:

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

After libsbml build finishes, I think we can merge ruby33 side tag 
into

F40 build tree.





Thx for the help with rebuilds. I am pondering about a few packages, 
e.g.:



libsolv needs rebuild it seems:

https://github.com/openSUSE/libsolv/issues/548

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


And I think that VIM might fall into the same bucket.



Yep, VIM cannot load vim-command-t and if somebody using the Ruby 
bindings. But I don't think this is major issue and VIM is updated 
quite often. So not a show stopper.


Despite there has been some activity related to the 
kf5-kross-interpreters / openbabel, I'll rather wont wait and merge 
it now. Anybody can rebuild those later.



Vít





Done:

https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d


Vít



CRITPATH update, probably due to DNF. Will look at that tomorrow.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

2024-01-03 Thread Vít Ondruch



Dne 03. 01. 24 v 18:55 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of 
all, I'd like to thank to Mamoru for the preparation and lot of 
fixes all around. I really appreciate that.


I think we are well prepared for the rebuild, therefore I have 
requested side-tag:


~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build 
repo to be generated.


~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 



or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' 
| sort | uniq

~~~


You can take the package and just fire rebuild, but please ensure 
that you are using f40-build-side-80411 build target, i.e. the 
build command should look like:



~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit 
the f40-build-side-80411 target, you'll be building against Ruby 
3.2 which is not what you want.


If you won't do it by yourself, I'll be rebuilding all packages 
after I am finished with my packages. I'll be using fermig [2] to 
help me with that. If you don't want me to touch your packages for 
whatever reason, please let me know.


As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the 
following:


  1    kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:

for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2255746

After libsbml build finishes, I think we can merge ruby33 side tag 
into

F40 build tree.





Thx for the help with rebuilds. I am pondering about a few packages, 
e.g.:



libsolv needs rebuild it seems:

https://github.com/openSUSE/libsolv/issues/548

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


And I think that VIM might fall into the same bucket.



Yep, VIM cannot load vim-command-t and if somebody using the Ruby 
bindings. But I don't think this is major issue and VIM is updated 
quite often. So not a show stopper.


Despite there has been some activity related to the 
kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it 
now. Anybody can rebuild those later.



Vít





Done:

https://bodhi.fedoraproject.org/updates/FEDORA-2024-d093bd520d


Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

2024-01-03 Thread Vít Ondruch



Dne 03. 01. 24 v 18:00 Vít Ondruch napsal(a):


Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, 
I'd like to thank to Mamoru for the preparation and lot of fixes 
all around. I really appreciate that.


I think we are well prepared for the rebuild, therefore I have 
requested side-tag:


~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build 
repo to be generated.


~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 



or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' 
| sort | uniq

~~~


You can take the package and just fire rebuild, but please ensure 
that you are using f40-build-side-80411 build target, i.e. the 
build command should look like:



~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit 
the f40-build-side-80411 target, you'll be building against Ruby 
3.2 which is not what you want.


If you won't do it by yourself, I'll be rebuilding all packages 
after I am finished with my packages. I'll be using fermig [2] to 
help me with that. If you don't want me to touch your packages for 
whatever reason, please let me know.


As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the 
following:


  1    kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:

for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2255746

After libsbml build finishes, I think we can merge ruby33 side tag into
F40 build tree.





Thx for the help with rebuilds. I am pondering about a few packages, 
e.g.:



libsolv needs rebuild it seems:

https://github.com/openSUSE/libsolv/issues/548

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


And I think that VIM might fall into the same bucket.



Yep, VIM cannot load vim-command-t and if somebody using the Ruby 
bindings. But I don't think this is major issue and VIM is updated quite 
often. So not a show stopper.


Despite there has been some activity related to the 
kf5-kross-interpreters / openbabel, I'll rather wont wait and merge it 
now. Anybody can rebuild those later.



Vít





OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby 3.3 - Mass rebuild

2024-01-03 Thread Vít Ondruch



Dne 03. 01. 24 v 17:18 Mamoru TASAKA napsal(a):

Mamoru TASAKA wrote on 2024/01/04 1:06:

Vít Ondruch wrote on 2024/01/03 19:20:

Hi everybody,

Ruby 3.3 is out and it is time for Ruby mass rebuild. First of all, 
I'd like to thank to Mamoru for the preparation and lot of fixes all 
around. I really appreciate that.


I think we are well prepared for the rebuild, therefore I have 
requested side-tag:


~~~

$ fedpkg request-side-tag
Side tag 'f40-build-side-80411' (id 80411) created.
Use 'fedpkg build --target=f40-build-side-80411' to use it.
Use 'koji wait-repo f40-build-side-80411' to wait for the build repo 
to be generated.


~~~

Ruby 3.3 is already merged [1] and build there:


https://koji.fedoraproject.org/koji/builds?inherited=0=80411=-build_id=1 



or using:

~~~

$ koji list-tagged f40-build-side-80411

~~~

Now this is a list of packages, which very likely needs rebuild:

~~~
$ dnf repoquery --disablerepo=* --enablerepo=rawhide 
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | 
sort | uniq

~~~


You can take the package and just fire rebuild, but please ensure 
that you are using f40-build-side-80411 build target, i.e. the build 
command should look like:



~~~
$ fedpkg build --target f40-build-side-80411
~~~


Please be careful, because if you, by a chance, omit 
the f40-build-side-80411 target, you'll be building against Ruby 3.2 
which is not what you want.


If you won't do it by yourself, I'll be rebuilding all packages 
after I am finished with my packages. I'll be using fermig [2] to 
help me with that. If you don't want me to touch your packages for 
whatever reason, please let me know.


As always, any help/testing/feedback is welcome.


Vít


[1] https://github.com/fedora-ruby/fermig
[2] https://src.fedoraproject.org/rpms/ruby/pull-request/159




Thank you for preparing ruby3.3 for F-40.

Now I think the leftover (not rebuilt against ruby3.3) are the 
following:


  1    kf5-kross-interpreters-22.04.3-5.fc39.src.rpm
  3    openbabel-3.1.1-21.fc39.src.rpm

Umm... looks like redhat-rpm-config-273-1.fc40 change 
(-Wl,-z,pack-relative-relocs) is causing this:

for now reported against redhat-rpm-config:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256645

  2    libsbml-5.20.2-4.fc40.src.rpm
Now building (perhaps will succeed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=111244836


libsbml build successfully finished.



  4    subversion-1.14.2-22.fc40.src.rpm
Build failing, perhaps due to zlib-ng-compat switch, already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2255746

After libsbml build finishes, I think we can merge ruby33 side tag into
F40 build tree.





Thx for the help with rebuilds. I am pondering about a few packages, e.g.:


libsolv needs rebuild it seems:

https://github.com/openSUSE/libsolv/issues/548

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


And I think that VIM might fall into the same bucket.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-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/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

1 2 3 4 5 6 7 8 9 >

1 - 100 of 887 matches

Mail list logo