Self Introduction: David Muse
Hello all, My name is David Muse. I'm the lead developer of the SQL Relay database connection management system (http://sqlrelay.sourceforge.net) as well as several other software projects (http://www.firstworks.com). I've been developing and integrating open source software for over 15 years. In that time, I've developed all manner of web-based applications, database software, embedded linux applications, and other odds and ends. I'm primarily a C++ developer, but I have experience developing in Perl, Python, PHP, C#, and (of course) SQL. I recently submitted a package-review request (https://bugzilla.redhat.com/show_bug.cgi?id=1259002) for my Rudiments library, which is the base library for SQL Relay and my other projects. If I am successful with it, then I intend to package SQL Relay and my other projects as well. Thanks! David Muse david.m...@firstworks.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction: David Muse
Thanks Kevin! I plan on updating the spec/srpm this week. I'll update the bug as soon as the updates are ready. Dave david.m...@firstworks.com On 9/20/2015 1:00 PM, Kevin Fenzi wrote: On Thu, 10 Sep 2015 14:03:17 -0400 David Muse wrote: Hello all, My name is David Muse. I'm the lead developer of the SQL Relay database connection management system (http://sqlrelay.sourceforge.net) as well as several other software projects (http://www.firstworks.com). I've been developing and integrating open source software for over 15 years. In that time, I've developed all manner of web-based applications, database software, embedded linux applications, and other odds and ends. I'm primarily a C++ developer, but I have experience developing in Perl, Python, PHP, C#, and (of course) SQL. I recently submitted a package-review request (https://bugzilla.redhat.com/show_bug.cgi?id=1259002) for my Rudiments library, which is the base library for SQL Relay and my other projects. If I am successful with it, then I intend to package SQL Relay and my other projects as well. Welcome! I'd be happy to review your package and look at sponsoring you... I've updated the bug to that effect. :) kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
not all that qualified...
Hello all, I have a fairly large package that needs review: https://bugzilla.redhat.com/show_bug.cgi?id=1415612 and I've been offered a few review swaps for it, but the trouble is, I don't really feel well qualified to review packages yet. I only maintain one other package (a pre-requisite for that one above) and it's super simple. Should I just jump in anyway? How is this kind of thing usually resolved? Thanks, David david.m...@firstworks.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: not all that qualified...
Thanks everyone. Good info. I'll put it to good use. Dave david.m...@firstworks.com On 6/1/2017 4:33 AM, Vít Ondruch wrote: Dne 1.6.2017 v 03:03 Susi Lehtola napsal(a): On 05/31/2017 05:19 PM, Christopher wrote: On Wed, May 31, 2017 at 6:44 PM David Muse mailto:david.m...@firstworks.com>> wrote: Hello all, I have a fairly large package that needs review: https://bugzilla.redhat.com/show_bug.cgi?id=1415612 and I've been offered a few review swaps for it, but the trouble is, I don't really feel well qualified to review packages yet. I only maintain one other package (a pre-requisite for that one above) and it's super simple. Should I just jump in anyway? How is this kind of thing usually resolved? At the risk of turning this into a "me too" thread, I want to thank you for asking this question. I'm in the same situation. I'm not comfortable reviewing packages yet. I'm sure there are others as well. So, on behalf of all us in this same situation, thanks for asking. I look forward to the advice that (hopefully) follows, from those more experienced. Sounds like a Catch-22: you can't get experience without reviewing packages, but you don't want to review until you have more experience. However, this is exactly why we have the sponsor system in place. I've found it a good system that the sponsor should ask for a few informal reviews from their sponsoree candidates, and the sponsor then does the formal review, checking if the sponsoree missed anything. Reviewing is nowadays a much simpler task than what it used to be, thanks to the automated fedora-review process. It handles a lot of things for you, but you still do have to go through some checklists by hand. I would suggest you do an informal review, and ask your sponsor, or people on the list to check it for you. These are good suggestions! And I'd like to add that you can't loose anything doing informal reviews for packages of your interest at any time. E.g. if somebody ask for package review on this list and the package catch your interest, then you can take a look how it is done or if you see anything wrong and just add your feedback to the ticket. This does not mean you need to finish the review and approved the package. The review should be IMO collective work anyway. More eyes more see. So my advice is "don't be afraid". Vít ___ 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
noarch package built differently...
Hello, I recently started getting errors like: 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The following noarch package built differently on different architectures: rudiments-doc-1.0.1-1.fc26.noarch.rpm rpmdiff output was: error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm error: cannot open Packages database in /var/lib/rpm ...when doing koji builds. Eg: koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm It's odd because the rpm in question is just docs. Nothing is built per-se, some static files are just installed. I'd expect it to be the same on all platforms. It seems that it always fails when building for arm. I don't have an arm platform available to test on though. Is there any way to get more information about what's different about the rpm on the different platforms? Thanks! David Muse david.m...@firstworks.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: noarch package built differently...
On 12/24/2016 3:49 AM, Michael Schwendt wrote: On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote: Hello, I recently started getting errors like: 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The following noarch package built differently on different architectures: rudiments-doc-1.0.1-1.fc26.noarch.rpm rpmdiff output was: error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm error: cannot open Packages database in /var/lib/rpm ...when doing koji builds. Eg: koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm It's odd because the rpm in question is just docs. Nothing is built per-se, some static files are just installed. I'd expect it to be the same on all platforms. It seems that it always fails when building for arm. I don't have an arm platform available to test on though. Is there any way to get more information about what's different about the rpm on the different platforms? You can submit a separate scratch build for each target arch, then download the built rpms and compare them all. rudiments does something to generate its HTML documentation. It doesn't use Doxygen, but whatever it does to the files may lead to different results depending on what arch the build machine is. I tried building for i686 and x86_64 and the noarch RPM did in fact turn out different for each platform: $ md5sum */* ed58927ce25fa51e3f5e16d81cc195fa i686/rudiments-doc-1.0.1-1.fc26.noarch.rpm 0789684c36ddcaadc4ee5216cfe7037e x86_64/rudiments-doc-1.0.1-1.fc26.noarch.rpm I tried installing them into separate roots using rpm --root and then removing the var directories that rpm creates for its database. After that, a diff -urN of the roots showed no differences. So, the files that are installed by both RPMs appear to be identical. However, a vbindiff of the two rpms shows plenty of differences. At first there are really sparse, like maybe individual numbers are different, but then there are some notable differences include the name of the build machine, and what appear to be build options like: -O2 -g -pipe ... -m64 -mtune=generic.cpio.xz.2.x86_64-redhat-linux-gnu, and then the compressed data is all very different. I would expect the name of the build machine and build options to be very different between systems of different architectures. And I'd think that the different strings would throw off the compressed data further on in the file. Am I doing something wrong that causes this info to be included in the noarch RPM? I tried fiddling with some parameters in my spec file. Eg. I don't have any patches to apply, so I removed the -p1 from the %autosetup, and I removed the Requires from the doc package, but those changes didn't make any difference. Is that info supposed to be included, and maybe there's just a bug in the code that compares noarch rpms? Or something else? Can I safely ignore the error? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: noarch package built differently...
On 12/24/2016 11:12 AM, David Muse wrote: On 12/24/2016 3:49 AM, Michael Schwendt wrote: On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote: Hello, I recently started getting errors like: 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The following noarch package built differently on different architectures: rudiments-doc-1.0.1-1.fc26.noarch.rpm rpmdiff output was: error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm error: cannot open Packages database in /var/lib/rpm ...when doing koji builds. Eg: koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm It's odd because the rpm in question is just docs. Nothing is built per-se, some static files are just installed. I'd expect it to be the same on all platforms. It seems that it always fails when building for arm. I don't have an arm platform available to test on though. Is there any way to get more information about what's different about the rpm on the different platforms? You can submit a separate scratch build for each target arch, then download the built rpms and compare them all. rudiments does something to generate its HTML documentation. It doesn't use Doxygen, but whatever it does to the files may lead to different results depending on what arch the build machine is. I tried building for i686 and x86_64 and the noarch RPM did in fact turn out different for each platform: $ md5sum */* ed58927ce25fa51e3f5e16d81cc195fa i686/rudiments-doc-1.0.1-1.fc26.noarch.rpm 0789684c36ddcaadc4ee5216cfe7037e x86_64/rudiments-doc-1.0.1-1.fc26.noarch.rpm I tried installing them into separate roots using rpm --root and then removing the var directories that rpm creates for its database. After that, a diff -urN of the roots showed no differences. So, the files that are installed by both RPMs appear to be identical. However, a vbindiff of the two rpms shows plenty of differences. At first there are really sparse, like maybe individual numbers are different, but then there are some notable differences include the name of the build machine, and what appear to be build options like: -O2 -g -pipe ... -m64 -mtune=generic.cpio.xz.2.x86_64-redhat-linux-gnu, and then the compressed data is all very different. I would expect the name of the build machine and build options to be very different between systems of different architectures. And I'd think that the different strings would throw off the compressed data further on in the file. Am I doing something wrong that causes this info to be included in the noarch RPM? I tried fiddling with some parameters in my spec file. Eg. I don't have any patches to apply, so I removed the -p1 from the %autosetup, and I removed the Requires from the doc package, but those changes didn't make any difference. Is that info supposed to be included, and maybe there's just a bug in the code that compares noarch rpms? Or something else? Can I safely ignore the error? Oh, I just realized that there's an rpmdiff tool. Well, I tried that, and the only difference it shows is the timestamp for each file, which I would expect to be different. An rpmdiff -iT of the two noarch rpms returns nothing. Strange. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: noarch package built differently...
On 12/24/2016 3:06 PM, David Muse wrote: On 12/24/2016 11:12 AM, David Muse wrote: On 12/24/2016 3:49 AM, Michael Schwendt wrote: On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote: Hello, I recently started getting errors like: 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The following noarch package built differently on different architectures: rudiments-doc-1.0.1-1.fc26.noarch.rpm rpmdiff output was: error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm error: cannot open Packages database in /var/lib/rpm ...when doing koji builds. Eg: koji build --scratch f26 rudiments-1.0.1-1.fc24.src.rpm It's odd because the rpm in question is just docs. Nothing is built per-se, some static files are just installed. I'd expect it to be the same on all platforms. It seems that it always fails when building for arm. I don't have an arm platform available to test on though. Is there any way to get more information about what's different about the rpm on the different platforms? You can submit a separate scratch build for each target arch, then download the built rpms and compare them all. rudiments does something to generate its HTML documentation. It doesn't use Doxygen, but whatever it does to the files may lead to different results depending on what arch the build machine is. I tried building for i686 and x86_64 and the noarch RPM did in fact turn out different for each platform: $ md5sum */* ed58927ce25fa51e3f5e16d81cc195fa i686/rudiments-doc-1.0.1-1.fc26.noarch.rpm 0789684c36ddcaadc4ee5216cfe7037e x86_64/rudiments-doc-1.0.1-1.fc26.noarch.rpm I tried installing them into separate roots using rpm --root and then removing the var directories that rpm creates for its database. After that, a diff -urN of the roots showed no differences. So, the files that are installed by both RPMs appear to be identical. However, a vbindiff of the two rpms shows plenty of differences. At first there are really sparse, like maybe individual numbers are different, but then there are some notable differences include the name of the build machine, and what appear to be build options like: -O2 -g -pipe ... -m64 -mtune=generic.cpio.xz.2.x86_64-redhat-linux-gnu, and then the compressed data is all very different. I would expect the name of the build machine and build options to be very different between systems of different architectures. And I'd think that the different strings would throw off the compressed data further on in the file. Am I doing something wrong that causes this info to be included in the noarch RPM? I tried fiddling with some parameters in my spec file. Eg. I don't have any patches to apply, so I removed the -p1 from the %autosetup, and I removed the Requires from the doc package, but those changes didn't make any difference. Is that info supposed to be included, and maybe there's just a bug in the code that compares noarch rpms? Or something else? Can I safely ignore the error? Oh, I just realized that there's an rpmdiff tool. Well, I tried that, and the only difference it shows is the timestamp for each file, which I would expect to be different. An rpmdiff -iT of the two noarch rpms returns nothing. Strange. Ha! Today the build succeeds with no errors. I guess something was wrong with koji. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: noarch package built differently...
On 12/25/2016 6:41 AM, Michael Schwendt wrote: On Sat, 24 Dec 2016 15:06:03 -0500, David Muse wrote: Oh, I just realized that there's an rpmdiff tool. Mentioned in your original mail. ;-) Well, I tried that, and the only difference it shows is the timestamp for each file, which I would expect to be different. An rpmdiff -iT of the two noarch rpms returns nothing. That's "Architecture independent files": https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Timestamps I eventually figured it out. The doc package had a Requires for the main package, which is arch-specific. At one point, I had commented out the Requires to see if that would fix the problem, but I must have forgotten to regenerate the SRPM before doing the next all-platforms build, and then not forgotten to regenerate it before doing the platform-specific builds that I rpmdiff'ed. Or something... Whatever I did wrong, the dependency on an arch-specific package turned out to be the main problem. I guess noarch packages shouldn't have any arch-specific dependencies. Is that correct? Dave david.m...@firstworks.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
ssl3_get_record:wrong version number
I keep getting "ssl3_get_record:wrong version number" errors when I try to run "fedpkg build", usually during checkout. Searching the archives, it looks like the last time someone reported this, it was during a planned outage, but I don't see anything down on the fedora infrastructure status page. Is this error expected at the moment, or am I doing something wrong? Thanks, David david.m...@firstworks.com ___ 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: ssl3_get_record:wrong version number
On Mon, 6 Jan 2020 15:19:28 -0800 Kevin Fenzi wrote: > On Mon, Jan 06, 2020 at 05:53:53PM -0500, David Muse wrote: > > I keep getting "ssl3_get_record:wrong version number" errors when I try to > > run "fedpkg build", usually during checkout. Searching the archives, it > > looks like the last time someone reported this, it was during a planned > > outage, but I don't see anything down on the fedora infrastructure status > > page. Is this error expected at the moment, or am I doing something wrong? > > > > Since I guess no good deed goes unpunished, I am trying to reinstall > some proxy servers and apparently they didn't properly remove from dns. > :( > > I think it should be all back to normal now, but if not, it should > definitely be back in a bit once I am done with this provisioning. Looks like it's working now. Thanks! > > Sorry again for instability. ;( > > kevin ___ 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
Requires for local install
Hello list, I have a package with many subpackages. Some of the subpackages depend on libraries provided by other subpackages. When downloading with yum/dnf, the rpm's know what they depend on, and the dnf/yum can figure out what to install to satisfy the dependencies. No problem there. But, when doing a yum localinstall or dnf install with a local path, the user has to either install all rpm's or manually resolve dependencies. Is it common to specify inter-subpackage dependencies using Requires to resolve this, or are users just on their own if they're installing packages manually? Thanks! David Muse david.m...@firstworks.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Rawhide arm compiler bug?
Forgive me if I'm pointing out a known issue, but I haven't noticed anything on
the list about this yet...
I keep getting sent rawhide build errors for my project. They only appear to
occur on the avmv7hl platform. It builds fine on all other architectures.
The errors are like:
sha1.cpp: In member function 'sha1::~sha1()':
sha1.cpp:34:1: error: pointer used after 'operator delete(void*, unsigned int)'
[-Werror=use-after-free]
34 | }
| ^
The code for ~sha1() is:
sha1::~sha1() {
delete pvt;
}
Line 34 is that closing bracket.
The code definitely isn't using the pointer after it's been deleted. Could
this be a compiler bug?
Thanks,
David
david.m...@firstworks.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Rawhide arm compiler bug?
On Fri, 11 Feb 2022 21:37:55 +0100
Florian Weimer wrote:
> * David Muse:
>
> > Forgive me if I'm pointing out a known issue, but I haven't noticed
> > anything on the list about this yet...
> >
> > I keep getting sent rawhide build errors for my project. They only appear
> > to occur on the avmv7hl platform. It builds fine on all other
> > architectures.
> >
> >
> > The errors are like:
> >
> > sha1.cpp: In member function 'sha1::~sha1()':
> > sha1.cpp:34:1: error: pointer used after 'operator delete(void*, unsigned
> > int)' [-Werror=use-after-free]
> >34 | }
> > | ^
> >
> >
> > The code for ~sha1() is:
> >
> > sha1::~sha1() {
> > delete pvt;
> > }
> >
> > Line 34 is that closing bracket.
> >
> >
> > The code definitely isn't using the pointer after it's been deleted.
> > Could this be a compiler bug?
>
> It's this bug:
>
> Unexpected [-Werror=use-after-free] warning only on arm7hl build of code
> <https://bugzilla.redhat.com/show_bug.cgi?id=2047316>
>
> It's fixed in gcc-12.0.1-0.4.fc36. Under local mock, you'll have to use
> --enablerepo=local because there hasn't been a compose in a while
> (apparently).
>
> Thanks,
> Florian
>
>
Ahh, ok. Should I mark any buzilla bugs that I get as duplicates of that one?
Dave
david.m...@firstworks.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
