Re: Bug#976906: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)
Here is a patch based on this :
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
Tested on a power machine (where the build failed) and it seems to work.
F.
Description: Fix parallel build
This happened here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976906
Solution found here :
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
Author: Frédéric Bonnard
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -8,6 +8,8 @@
AM_YFLAGS = -d -p `${SED} -n 's/.*_\(.*\)/pll_\1_/p' <<<"$*"`
AM_LFLAGS = -P `${SED} -n 's/.*_\(.*\)/pll_\1_/p' <<<"$*"` -o lex.yy.c
+BUILT_SOURCES = parse_rtree.h parse_utree.h
+
libpll_la_SOURCES=\
fasta.c \
gamma.c \
signature.asc
Description: PGP signature
Re: Gathering debug data from buildd's?
Hi Hilmar, > I sent a request 3 days ago, still no response. Do I have to sign my > E-Mail to get the request processed? No. It just takes a bit of time sometimes for people of the team that do this manually but they usually answer, so you'll be informed when it's done. F. pgp5yTbAlpDJ2.pgp Description: PGP signature
Re: Gathering debug data from buildd's?
On Thu, 25 Jul 2019 15:35:31 +0200, Hilmar Preuße wrote: > Am 25.07.2019 um 13:15 teilte Frédéric Bonnard mit: > > Hi *, > > > no I didn't reproduce the issue in a ppc64 vm even after 3 tries. > > > Maybe it was an gcc bug, which has been solved in the meantime? The > builder used gcc-8.3.0-7, meanwhile I (and probably you too) used > gcc-8.3.0-19. That's what I personally thought, a difference in the toolchain or some dep. > Is it possible to force a rebuild after updating build tools on the > builders? yes, see last paragraph here : https://release.debian.org/wanna-build.txt > > Hilmar > -- > #206401 http://counter.li.org > pgpngx1tvOh2Q.pgp Description: PGP signature
Re: Gathering debug data from buildd's?
Hi Hilmar, no I didn't reproduce the issue in a ppc64 vm even after 3 tries. F. On Wed, 24 Jul 2019 19:55:57 +0200, Hilmar Preuße wrote: > On 24.07.19 11:05, Frédéric Bonnard wrote: > > Hi Frédéric, > > > potentially recreate the issue in a ppc64 vm ? > > I may also try to reproduce in a vm I already have. > > > Were you successful in problem reproduction? > > Hilmar > -- > sigfault > #206401 http://counter.li.org > pgpE0iUk0wR90.pgp Description: PGP signature
Re: Gathering debug data from buildd's?
Hi Hilmar, potentially recreate the issue in a ppc64 vm ? I may also try to reproduce in a vm I already have. Regards, F. On Wed, 24 Jul 2019 10:32:59 +0200, Hilmar Preuße wrote: > Hi, > > dumb question: since a few releases we have problems to build a package > on ppc64 [1]. The resulting binary segfaults when generating files. I > reported the problem upstream: they asked me for core dumps/gdb output. > > How to proceed: I could try to get access to a porter box through an RT > request (took last time 2 month to be processed). Are there other/faster > methods, e.g. gathering the data from the buildd itself? > > Thanks! > > Hilmar > > [1] https://buildd.debian.org/status/logs.php?pkg=asymptote&arch=ppc64 > -- > sigfault > #206401 http://counter.li.org > pgp2fgkKeXIG5.pgp Description: PGP signature
Default permissions for possible sensitive information places
Hi, upstream of rear software installs /etc/rear/ /etc/rear/cert/ and /etc/rear/local.conf with no permissions to group and others, because those may contain sensitive information (I guess encryption key for example) ; details here : https://github.com/rear/rear/issues/1666 I'm wondering about this being the good thing to do, by default, given that there's nothing confidential by default and that it diverges by what is suggested by the policy : https://www.debian.org/doc/debian-policy/#permissions-and-owners - /etc/rear/ and /etc/rear/cert/ : I guess maybe it would make sense for a directory targeted to store keys for example and even in that case, only setting correct permission for the key files themselves would be enough. - local.conf : for configuration file that may contain sensitive information but which default version (from the package) doesn't include anything, does that make sense ? the admin putting sensible information should then change the configuration file permission to reflect that. Also rear/backups in general is a sysadmin activity and hiding all /etc/rear to non-root won't be an issue. And I agree that setting by default restrictive permission may be good as the admin backuping won't even need to take care of that. But this does more than just what's needed (atomic, necessary and sufficient based on the actual content) and deviates from Debian defaults. So I'm a bit confused. Do you know of some Debian usage in that case or if I missed some policy point ? F. pgpYf0RurusWS.pgp Description: PGP signature
Re: Change file permissions
On Thu, 18 Jan 2018 17:14:45 +0100, Muri Nicanor wrote: > Hi, > > On 01/18/2018 10:02 AM, Gianfranco Costamagna wrote: > > Hello, > >> they are not 600. should i set the file permissions on package upgrade > >> or should i leave this to the user? > > > >> if i should set them, should i use postinst or is there a better way? > > > > is a dh_fixperms override helpful? > > not really, because if i read its manpage correctly it only lets me > exclude files from dh_fixperms' predefined directory+mode configurations. right, that was my feeling as well. And from my testings, when you install the package for the first time that will help since the install step from upstream will set the permission correctly (if they do so) and dh_fixperms won't change this. But for an upgrade, I had to write a postinst file to fix this on the already existing files (on sources.debian.org, other packages do as well) Still I had this wondering, and I'm always listing to advices. F. > cheers, > muri > pgpa_pyssHZ1c.pgp Description: PGP signature
Bug#870909: RFS: cxlflash/4.3.2493-1 [ITP] -- IBM Data Engine for NoSQL Software Libraries
Hi Rodrigo, I do not intend to sponsor this package but I'm just willing to help. Be careful to target "Package: sponsorship-request*s*" : the bug as been properly re-assigned to "sponsorship-requests", but it didn't reach the mentors audience as I can tell. I didn't check deep but I can see that the packaging is not following the latest policy manual (newer-standards-version) : have a look to this document ( https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt ) to fix this ; https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Standards-Version Also, could you make the debian/watch file work please ? Thanks, F. > Package: sponsorship-request > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "cxlflash" > > * Package name: cxlflash > Version : 4.3.2493-1 > Upstream Author : Mike Vageline > * URL : https://github.com/open-power/capiflash > * License : GPL-2+, Apache-2.0 > Section : utils > > It builds those binary packages: > > cxlflash - IBM Data Engine for NoSQL Software > Libraries : cxlflash > cxlflashimage - IBM Data Engine for NoSQL Software > Libraries : cxlflash afu libra > > To access further information about this package, please visit the following > URL: > https://mentors.debian.net/package/cxlflash > > > Alternatively, one can download the package with dget using this command: > >dget -x > > https://mentors.debian.net/debian/pool/main/c/cxlflash/cxlflash_4.3.2493-1.dsc > > More information about hello can be obtained from > https://github.com/open-power/capiflash. > > > Regards, >Rodrigo R. Galvao pgpvbWQyUKtL2.pgp Description: PGP signature
