> SPDX v3 has been published. The biggest change for us is that license
> expression
> allows lowercase operators (and, or, with).
Worth noting is that the spec [0] says thse should be
either all-lowercase or ALL-UPPERCASE:
> License expression operators (AND, and, OR, or, WITH and with)
>
The XDG spec [0] says that, if the env vars are unset,
or set to an empty value, a compliant application
should fall back to the default value given by the spec.
So I guess the answer is that, since we don't need to use
non-standard directories, setting the env vars to the same
value as the
> I have no strong opinion how to process with the case of
> "MIT and BSD and Bitstream Vera and OFL". I think that
> converting it to " MIT and BSD and Bitstream-Vera and OFL"
> is probably best option.
I'll go on a tiny bit of a tangent here: SPDX spec says that
license expression operators
https://doc.rust-lang.org/reference/attributes.html
If I understand this page of The Rust Reference correctly,
then moving the #![no_std] attribute from the first line of the file
shouldn't break anything. So you can try side-stepping the issue
by patching the file and adding "// lol pointless
Hi all,
the pipewalker package [0] has been updated to the latest release, v1.0. [1]
This release includes a re-licensing of the code from GPL-3.0-or-later to MIT.
pipewalker is a leaf package, so this shouldn't affect anyone.
A.FI.
[0] https://src.fedoraproject.org/rpms/pipewalker
[1]
Hi all, the license tag on qmltermwidget [0] has been corrected from:
GPL2+
to
GPL-2.0-or-later AND LGPL-2.0-or-later
The only two consumers of this package in Fedora repos are:
- cool-retro-term
- qmlkonsole
Cheers,
A.FI.
[0] https://src.fedoraproject.org/rpms/qmltermwidget
--
Hi all,
I've been maintaining Fritzing, the electronic design software [0]
for some time now. Currently, the program is split into two packages:
"fritzing", providing the executable; and "fritzing-parts", a noarch
package providing data files, including the parts database.
The parts database is
> Ultimately, appstream-util's output is what matters since we use
> appstream-builder (from appstream-glib) to generate our AppStream
> metadata index. If it doesn't pass that tool, it doesn't show up.
Bit of a tangent, but: is this documented anywhere?
Because if if is, then I can't find it.
> Problem 1: package libblockdev-vdo-2.24-2.fc32.x86_64 from @System requires
> libbd_utils.so.2()(64bit), but none of the providers can be installed
> - libblockdev-utils-2.28-5.fc38.x86_64 from @System does not belong to a
> distupgrade repository
> - problem with installed package
> I just discovered that the fontawesome-fonts package had no commit or
> build either. I wonder if it has something to do with this error I
> just encountered while preparing an update for the package:
>
> $ git push
> Source file '60-%{fontpkgname1}.conf' was neither listed in the
> 'sources'
Hi,
I have updated the license on the "lazpaint" package. [0]
LazPaint is an image editor, and a leaf package with no dependents.
a) LGPLv2 -> LGPL-3.0-only
I missed upstream switching from v2 to v3 at some point.
b) Dropping Boost
The Boost license is only relevant to some test files,
No files
Any more details?
Anything interesting inside /var/log/lightdm?
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
> FTBFS:
> easyrpg-player
Upstream has already updated the program to work with fmt10,
so I just applied the relevant commit to the Fedora package.
Submitted and rebuilt:
https://koji.fedoraproject.org/koji/taskinfo?taskID=102705429
A.FI.
___
devel
> I've taken ownership of libreoffice for the time being, at least to keep the
> lights
> on. Co-maintainers, as always, welcome.
Don't know how much time I'll be able to contribute, but you can count me in.
As Mattia suggested, I think it might be a good idea to set up libreoffice-sig.
A.FI.
> What is the simplest way to get a rawhide i686 VM?
I think that's no longer possible, as it's been many years since Fedora stopped
shipping i686 kernels.
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
I guess you could try creating a VM with some other distro, like Debian,
> Now it uses SPDX identifiers, but lowercase ors, should probably be uppercase
> ORs.
Yea. I've been reading through the spec lately, since I want to add proper SPDX
support to my project,
and it says joiners should be uppercase and parsers should match
case-sensitively.
> License expression
> "dnf repoquery --srpm --whatrequires kiss-fft-static" returns nothing,
That's because there's no "kiss-fft-static" package, only "kiss-fft-devel".
Running "dnf repoquery --releasever=39 --disablerepo='*'
--enablerepo='*-source' --whatrequires kiss-fft-devel" gives me:
-
Tested on three different machines. No problems with transaction conflicts,
just some package downgrades:
- inxi-3.3.25-1.fc37 -> inxi-3.3.24-2.fc38 (version downgrade)
- fwupd-1.8.10-2.fc37 -> fwupd-1.8.10-1.fc38 (lower release number)
A.FI.
___
devel
Hi all,
I intend to un-retire arptools, which is a small collection of Ethernet ARP
tools.
The package used to be in Fedora repos, but was retired somewhere between F31
and F32 due to being orphaned.
https://src.fedoraproject.org/rpms/arptools
I looked through the devel list, but couldn't find
> Should that tutorial work? Is it perhaps obsolete?
I'd say the opposite of obsolete - it's been updated to suggest using
fedpkg all along the way, instead of the old rpmbuild tools. But it
looks like it wasn't tested enough to make sure everything works.
> My newbie understanding is that
> Is there another argument to fedpkg?
fedpkg has a --name argument, you can try using that.
Alternatively, if you're just taking your first steps with packaging, you can
try:
$ rpmbuild -bs path/to/your.spec
$ mock path/to/file-created-by-previous-command.srpm
This will first build an SRPM
Fixing the FTBFS is rather trivial (yet another victim of GCC13 header
shenanigans)
and I've already created a patch for this, but I didn't want to pick up the
package since
upstream activity since rather low. If you're saying that the project isn't
dead yet,
then I'd be willing to pick this up
fpc has a Requires: on the units package, so it should always be installed.
The build failures for packages using FPC, as far as I can see, are all packages
using Lazarus. As far as I can tell, this is because Lazarus seems to quite
tightly
depend on specific FPC versions, and historically,
> cqrlog - Fails for some weird lazbuild issue I don't understand
This is most likely my fault, since Lazarus seems to be quite tightly coupled
to specific FPC versions.
Historically, whenever we updated/rebuilt FPC, we'd also rebuilt Lazarus. This
time, when I rebuilt
FPC as part of the
I wanted to resubmit one of my failed builds, but the buildroot seems to be
broken currently:
> Problem 1: package python3-dnf-4.14.0-2.fc38.noarch requires libmodulemd >=
> 2.9.3, but none of the providers can be installed
> - package libmodulemd-2.14.0-5.fc38.x86_64 requires
>
So I'm sure this question has been asked during previous Mass Rebuilds,
but I can't find the answer in the heaps of messages in my mailbox,
so I'll ask again: if my package failed to build during the Mass Rebuild
and I know how to fix it - I don't have to wait for the rebuilt to end,
right? I can
Haven't planned on this originally, but it seems like a good idea.
Never really used Obsoletes before, so I have to ask:
what's the dnf behaviour when a package is obsoleted by multiple packages?
If it tries to install all of them, then that'd be okay. I'd like to
avoid a situation where dnf
> At least in my workflow, I only do scratch builds before pushing,
> to ensure that what I am about to push builds correctly in Koji.
Same here. Some of my packages are prone to break and in need
of patching on non-x86_64, so that's my main use case as well.
Never used "fedpkg scratch-build"
> So you can do
> $ eval `rpm -E '%set_build_flags'`
> in a script to set the flags that RPM uses.
Another solution could be something like:
$ gcc $(rpm -E '%optflags') ... $(rpm -E '%build_ldflags')
A.FI.
___
devel mailing list --
fpc (the Free Pascal Compiler) also ships with units for developing stuff
with gtk1 - so should we retire gtk+, we'll probably want to patch fpc
so said units are not shipped.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
> eurekaorphan 2 weeks ago
I have a soft spot for classic DOOM, so I took this one.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Hey all,
colorful had a new major release, v2.0, which brought in a licensing change.
I took this as an opportunity to also migrate the License: tags to SPDX.
Old v1.3 license: zlib with acknowledgement
New v2.0 licenses:
- colorful: GPL-3.0-only AND (MPL-2.0 OR Zlib)
- colorful-data:
> b) Instead of using the default config file, ship a custom one that makes
>the compiler always look in /usr/lib64/ on 64-bit arches
>and /usr/lib/ on 32-bit arches.
I took another look into this and contrary to what I wrote in my previous
message, it turns out we *do* already ship a
Hey all,
I've been maintaining the Free Pascal Compiler [0] in Fedora for some time now.
A couple of times I played around with the idea of building and packaging FPC
cross-compilers. Lately I gave it another go and arrived and some quite
workable results. If you're interested, you can check them
> - rpms/fpc
> - rpms/lazarus
I've been a co-admin on those, so I took 'em.
Several of the orphaned packages are dependencies of stuff I currently maintain.
I'll wait a week or two to see if anyone else wants to take them.
A.FI.
___
devel mailing list
Hello, Bojan.
The only way I know is to utilise the "RemovePathPostfixes" tag for this, e.g:
> %package gtk3
> RemovePathPostfixes: .gtk3
>
> %package qt
> RemovePathPostfixes: .qt
>
> %files gtk3
> %{_bindir}/%{name}.gtk3
>
> %files qt5
> %{_bindir}/%{name}.qt5
Then, you just need to rename
> Would that imply I have to add the LGPL license text to the package myself?
The packaging guidelines state that the desired course of action
is to contact upstream and ask them to provide the licence text.
I took a look at epel-rpm-macros. Interestingly, in EPEL9,
the package has "Recommends: fpc-srpm-macros". [0]
Despite this, when I try building in the side tag,
the package isn't pulled in. I guess koji is configured
not to pull in weak deps?
Anyway, I've opened a PR on epel-rpm-macros
to change
Hi all,
some time ago I've built the Free Pascal Compiler [0] for EPEL9,
and recently I got the idea it might be good to do the same with
the Lazarus IDE [1]. Testing things locally with mock,
I realized that Lazarus used a macro from fpc-srpm-macros [2],
which hasn't been built for EPEL9 yet.
Hi, Petr.
I use firejail every now and then, and glancing at the commits,
the package doesn't require much maintenance, so I adopted it.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
> Sounds like you need to clear your browser cache or something
Yeah, looks like it. I refreshed the page via F5 and it didn't help.
Doing a full page reload via Ctrl+R helped.
> According to your description, your browser might be broken,
> perhaps due to some content blocking?
> See this
While I really like the idea, I find the interface to be... how do I put it?
Non-obvious and not very discoverable.
For example, at the top of the page, there's a bunch of numbers. I have no idea
what they mean.
Hovering over each of these displays a tooltip - which is nice - but five
seconds
Hey all,
I have two packages which have been sitting in review for some time now:
https://bugzilla.redhat.com/show_bug.cgi?id=2095732
daniel-wikholm-segment16-fonts - collection of 3 font families.
Bit problematic because of missing license text, not having an official source
website, nor a
> Major version updates often change behaviour of the apps or the system itself
It's also worth mentioning that if some packages are retired, they will not be
available in the new Fedora version. In the old days, this would mean you
might get some old & broken packages stuck on your system;
In the spec, you have this:
> %setup -n %{module_name}-%{version}
The error message looks like this:
> /usr/lib/rpm/rpmuncompress -x -v/builddir/build/SOURCES/m3u8-3.1.0.tar.gz
> rpmuncompress: -v/builddir/build/SOURCES/m3u8-3.1.0.tar.gz: unknown option
On first glance, this looks like a bug in
Adding "#include " to src/timer.cpp fixes this.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
> I would like the bot to stop trying making patches and doing scratch builds
> on all my packages at all.
> Is that possible? How?
Isn't that controlled in Pagure, via the "monitoring" dropdown on the repo page?
There's "no monitoring", "monitoring" and "monitoring with scratch builds"
options.
The docs make it seem like maintaining a spin isn't that much work,
and the kickstart files for spins look rather straightforward.
> ## Maintainer did not respond to pings
> * Games Spin — https://fedoraproject.org/wiki/Games_Spin
Unless someone more experienced comes along, I'd be willing
to
I can join bleachbit as a co-maintainer.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Blueman, the bluetooth manager [0], requires the user to be in the "wheel" group
in order to perform certain functions (like enabling/disabling bluetooth).
This leads to a sub-optimal user experience, where the user is prompted
to authenticate as root in order to perform certain actions. [1]
The
> Too complicated for the average user.
That's debatable. Does the *average user* even care?
We're on the development mailing list, after all,
so there's a lot of bias towards the power user side.
> It should be visible when you click the "Install" button.
I agree that the current placement makes
Some time ago we've had python3.11 land in Rawhide, with a rebuild of dependent
packages.
One of my packages, liquidctl, fails to build with the new Python, and since my
knowledge of the language
stops at "I used it to rewrite some bash scripts", I'd need some help.
Strictly speaking, the
> I'd imagine a single slider (or drop-down menu or whatever)
Once you open the app screen details, there is a drop-down for this,
integrated into the top bar, next to the app name.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To
> Users of RPM-based variants will expect the default package manager to
> install RPMs,
> not Flatpaks, or they would have chosen a Flatpak-based variant.
Agree on that one.
That being said, what about allowing users to set this preference by themselves?
I also think that the repository
I wanted to try building a Fedora Flatpak, so I headed over to the docs and
started with the tutorial.
https://docs.fedoraproject.org/en-US/flatpak/tutorial/
The first step instructed me to install some packaging tools:
$ dnf install flatpak-module-tools fedmod
DNF complained that it could not
Just after sending this message, it occurred to me
that I could just use the developer tools in the browser
to check the URL of the API endpoint being called
and then just send a similar request using curl.
So it is quite possible that it was, indeed, my memory
playing tricks on me, and I used to
When you go to a package's repo on src.fedoraproject.org,
on the top of the page, you get this nice table that lists
active Fedora and EPEL releases, and for each of those,
prints the package version currently in stable and in testing.
Now, I could swear that fedpkg had a similar feature.
Yet,
$ rpmbuild --showrc
The definition for %cmake is quite long, but includes this line:
%{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} \
%__cmake_builddir is defined as:
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
And then %_vpath_builddir is defined
> garmintools orphan 5 weeks ago
I adopted this. The build is now finished.
https://koji.fedoraproject.org/koji/taskinfo?taskID=88328349
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To
SSR is available in RPM Fusion under the name "simplescreenrecorder",
so you may want to coordinate this with the Fusion maintainer - maybe
do something similar to Audacity and Chromium, where the Fedora package
is named "foobar" and the RPM Fusion one is "foobar-freeworld".
A.FI.
This depends on the state of the package.
1. Has an active maintainer? They must go to the package's repo, and in the
settings, grant you commit/admin access. [1]
2. Has a maintainer, but they're inactive? You must fire up the non-responsive
maintainer policy. [2]
3. Package is orphaned, but not
> Are you manually editing the "sources" file?
No, why would I?
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
> I very likely have the files listed in sources
> around from previous attempts
Well, yeah, but it's also likely that someone:
1. Has multiple machines, hadn't done any work on this package on the current
machine, and did a fresh "fedpkg clone"
2. Got fed up with clutter in the directory and
> I somehow don't understand why there should be anything like "unused
> source files". Why is something like this even possible?
1. Grab a package
2. Edit the spec file in a way that changes which sources are used (say, update
to a new version)
3. Do not run "fedpkg new-sources" to upload the
git-up has been retired for over a year now. Packages that have been
retired for over 8 weeks need to go through Package Review again.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
A.FI.
___
devel mailing
For me personally, opt-out would be better, since the logic is right most of
the time.
That being said, how about adding a value for this in
$HOME/.config/rpkg/fedpkg.conf?
That way, you have some default value, which can be overridden by the config,
which in turn can be overridden by the
cpufetch v1.02 has just been released. This new version includes a change in
licensing, from MIT to GPL-2.0-only.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
I'm not sure if I use any i686 executables, but I sure do use
i686 builds of libraries for cross-compiling. By which I mean
both i686-linux and i686-win32.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On my F35 machine, there are no transaction errors, but the following packages
get downgraded:
- binutils-x86_64-linux-gnu and cross-binutils-common - from 2.37-3.fc35 to
2.37-2.fc36 (same version, release downgrade)
- thunderbird and thunderbird-librnp-rnp - from 91.5.0-1.fc35 to 91.4.0-1.fc36
Are you talking about the "nextcloud-client" package? [0]
'cause that one isn't orphaned, and nonamedotc [1] is listed as the maintainer.
Also, v3.4.2 is currently in testing, but has not been pushed to stable
due to reported bugs. [2]
A.FI.
[0]
> error: Unable to open /dev/stdin: No such device or address
How about "/proc/self/fd/0"?
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
You need to generate an SSH key and upload it to
https://accounts.fedoraproject.org
Log in, go to Settings and switch to the "SSH & GPG keys".
If this isn't the only key you're using, you will also need to edit your ssh
config.
A.FI.
___
devel mailing
> file /usr/bin/icat from install of sleuthkit-4.11.1-1.fc36.x86_64 conflicts
> with file from package icat-0.5-10.fc36.x86_64
> file /usr/share/man/man1/icat.1.gz from install of
> sleuthkit-4.11.1-1.fc36.x86_64 conflicts with file from package
> icat-0.5-10.fc36.x86_64
icat is one of my
One of my packages ("blueman") had a new release today, so I updated it.
Despite me committing to the rawhide branch, the build was given the ".f36"
suffix,
so when I pushed to the f36 branch and tried to build the package,
koji berated me that it's been already built.
So what now? Should I just
I contacted Rahul and he made me a co-maintainer on the chocolate-doom package.
I've pushed a commit that fixes the build failures and updates the package from
v3.0.0 to v3.0.1.
The builds for rawhide, f35 and f34 had finished and have been submitted to
bodhi.
A.FI.
> chocolate-doomsundaram
I've managed to get this to build successfully in koji.
I'll try to contact the maintainer, though looking at bugzilla, they haven't
been active since April 2020.
I'm willing to adopt the package should the maintainer drop it or be declared
Bumping this since I have an identical issue with colobot - the compilation
errors out when a C-like string literal is assigned to an std::string, with the
compiler providing the same "memcpy accessing... overlaps lots-of-bytes at
offset -3" error message.
A.FI.
Hi all,
some time ago, Lazarus v2.2.0 came out. I tried to update the package
in Rawhide, but the build failed on ppc64le with a linking error.
Link to failed scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81313575
../units/powerpc64-linux/nogui/project.o: in function
> So far there has been no action on the bug to get it reviewed.
> Does it usually take a while to get the review started?
Well, the thing is - there isn't really anyone obliged to review package
submissions.
Almost every single review is done by volunteers, using their free time.
> Do I need to
I pulled a Rawhide container and tried building there via "fedpkg local".
When I took the g++ command line and replaced "-flto=auto -ffat-lto-objects"
with "-flto=none", the file was compiled without errors.
A.FI.
___
devel mailing list --
I tried compiling colobot with the new gcc, expecting it to break in some
new and fascinating way, and got the following error:
In function 'std::char_traits::copy(char*, char const*, unsigned long)',
inlined from 'std::__cxx11::basic_string,
std::allocator >::_S_copy(char*, char const*,
Hi, Darryl.
> How to clone the GitHub repository in the spec file
RPM packages are build from Source files. You don't clone the repository in the
spec;
rather, you download the repository as a tarball and use that. For GitHub, you
can download
a specific git tag (or commit) by using the
I've got this sad boy waiting for a review since September:
https://bugzilla.redhat.com/show_bug.cgi?id=2006685
pasdoc - Documentation generator for Pascal source code
I can review some C, C++, Pascal or shell stuff in return.
A.FI.
___
devel mailing
Even if it does, it's unlikely to be the culprit,
since in my case, I only use e-mail notifications.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
This is happening to me, too - but it doesn't seem to be limited
to koji notifications. It happens with bugzilla notifications as well.
There isn't any pattern to the delays that I can see.
I regularly receive notification digests during the day,
yet every now and then I receive a digest
> I have created new tool license-validate:
> https://pagure.io/copr/license-validate/
I've written something relatively similar a few years back
(https://github.com/suve/vrms-rpm).
I took a look at the code - using a proper parser is definitely a better
solution than the error-prone,
manual
There's been a (short) discussion about having a wishlist last month:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K3O5WRMT75UCWMRE6PCMBHRGMHMIBM63/
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To
On a related note - could we increase the size limit for FTBFS tickets?
Currently, the when FTBFS bugs are filed, the attachments are limited to 32KiB,
which is often too small to fit the whole build log.
The whole point of attaching these to the bugzilla ticket is that koji deletes
logs after
> The idea here [...] is for our target audience to quickly be made aware
> that something is available in Fedora when they go to a GitHub repository.
> They're really not going to go to repology to search
Repology also offers badges. What I meant is that a single Repology badge
listing all known
Not sure if there's a way to test a conditional by itself, but if it's
somewhere in a spec file,
you can use "rpmspec --parse $FILE" to see what the spec looks like after it's
parsed
and all the conditionals have been evaluated.
A.FI.
___
devel
> Would anyone have an idea of how this works and
> where issues should be filed? On our infra or on shields.io?
Fedora badges are listed on shields.io under the "Version" category:
https://shields.io/category/version
Clicking on the "Fedora" badge brings up a pop-up that allows to specify the
> ./mkinstalldirs /usr/bin
> make: ./mkinstalldirs: Permission denied
This sounds like "mkinstalldirs" is not executable, perhaps a simple "chmod +x
mkinstalldirs" will be enough?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
> SDL2_gfx ignatenkobrain, orphan 1 weeks ago
I'd like to pick this up, but I have next to zero experience working with
autotools,
so I'll defer adopting the package until I have a working fix for the FTBFS.
___
devel
I'm currently working on updating liblcf and easyrpg-player to v0.7.0 [0,1].
As part of this new release, the liblcf library now bundles some header-only
C++ libraries [2,3].
Those are Boost-licensed, which means the package's effective license changes
from "MIT and BSD" to "MIT and BSD and
> In the docs there is a section about Claiming Ownership of an Orphaned Package
You were looking almost in the right place. There's a separate section about
claiming retired packages. [1]
tl;dr: If it was retired for more than 8 weeks, it needs to go through the
Package Review process again.
> section "Chained builds". What about those, what are they useful for?
Chained builds are mostly useful when you have a package B which depends on
package A.
Instead of building package A, waiting for a confirmation that the build
completed
and made it to the buildroot, and then manually
> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on. Is it possible to keep this going,
> or would that require a lot of work?
+1 on this. Having just the minimum, core packages
available in the repo would be good, especially since:
a) It would
Sounds good. I took a look at the "multi builds" page - it describes the
process neatly,
but I think there's one thing that could be added there: what if you already
built a package
in the main tag (but it didn't go through bodhi and get to stable)? Will it be
included in the
newly-created side
> I've created f35-build-side-46123 and tagged fpc-3.2.2-3.fc35 into that.
> Lazarus rebuild is in progress.
Thanks. Lazarus has been built successfully.
> If the maintainers of those packages want to rebuild their package
> (in the side-tag), please do so, it will speed up the process.
I'll go
> I can take care of creating the side-tag,
> tagging the fpc build in it (no need to rebuild it again)
> and trying to rebuild all dependent packages there.
Sure, thanks for the help.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To
1 - 100 of 137 matches
Mail list logo
