Bug#835087: ITP: r-cran-cairo -- GNU R graphics device using cairo graphics library
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-cairo Version : 1.5-9 Upstream Author : Simon Urbanek * URL : http://cran.r-project.org/web/packages/Cairo * License : GPL Programming Lang: GNU R Description : GNU R graphics device using cairo graphics library GNUR R graphics device using cairo graphics library for creating high- quality bitmap (PNG, JPEG, TIFF), vector (PDF, SVG, PostScript) and display (X11 and Win32) output . Cairo graphics device that can be use to create high-quality vector (PDF, PostScript and SVG) and bitmap output (PNG,JPEG,TIFF), and high- quality rendering in displays (X11 and Win32). Since it uses the same back-end for all output, copying across formats is WYSIWYG. Files are created without the dependence on X11 or other external programs. This device supports alpha channel (semi-transparent drawing) and resulting images can contain transparent and semi-transparent regions. It is ideal for use in server environments (file output) and as a replacement for other devices that don't have Cairo's capabilities such as alpha support or anti-aliasing. Backends are modular such that any subset of backends is supported. Remark: This package will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-cairo/
Re: Computing Build-Depends at build time (and other updates to debian/control)?
Josh Triplett writes ("Re: Computing Build-Depends at build time (and other
updates to debian/control)?"):
> Christoph Egger wrote:
> > Several packages create their control file from control.in during
> > maintainer build. You can have debian/control as a make dependency for
> > the package build target so it gets generated if it's not already
> > up-to-date. You just need to check it's correct and building on the
> > buildds does not generate a new/different controlfile.
>
> That last part seems like exactly the problem. If I can only run the
> process as part of a maintainer build, then I might as well just run the
> packaging tool and have it update the hardcoded Build-Depends in
> debian/control. I don't want the rebuild of debian/control to occur in
> advance and show up in the Debian diff; build and clean should never
> leave the package source changed. (For that matter, generated files
> shouldn't appear in version control.) Hence wanting to compute control
> (or just Build-Depends) at package build time, and define a subset
> Build-Depends for the tools needed for that computation.
You're effectively asking for the interface to a Debian source package
to be redefined so that every package must be built twice: once to
discover its control file, and then again to actually build the
binaries.
Just thinking about the amount of software that would have to be
updated should persuade you that this is a bad idea.
But even worse is that it would no longer be possible to sensibly
compute build orders without pre-building every package in a source
archive, because it would not be possible to statically determine
which binary packages are supposed to come from which sources.
Furthermore, once such a system was put in place, the
prebuild-dependencies would gradually grow.
All of this is a really bad direction to go in.
The right approach is the one we have now: we precompute this
information, and store and distribute it via the archive. When it is
necessary to update it, the maintainer can do so manually.
If you want to catch failures of the maintainer to do the update, you
can run your autogenerator in some kind of checking mode during
debian/rules. The result will be that your package FTBFS when the
control file is out of date. This is only a reasonable thing to do if
the control file depends only on other things in the same source
package.
If your control file depends on anything else, such a check would
probably be an inconvenience (or worse) to anyone trying to backport
your package, and might hinder security updates too.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Computing Build-Depends at build time (and other updates to debian/control)?
Ian Jackson writes ("Re: Computing Build-Depends at build time (and other
updates to debian/control)?"):
> If you want to catch failures of the maintainer to do the update, you
> can run your autogenerator in some kind of checking mode during
> debian/rules. The result will be that your package FTBFS when the
> control file is out of date. This is only a reasonable thing to do if
> the control file depends only on other things in the same source
> package.
Here is an example from one of my own packages. It concerns
debian/tests/control but the same principles apply:
https://browse.dgit.debian.org/dgit.git/tree/tests/tests/test-list-uptodate
https://browse.dgit.debian.org/dgit.git/tree/debian/tests/control.in
https://browse.dgit.debian.org/dgit.git/tree/debian/tests/control
https://browse.dgit.debian.org/dgit.git/tree/tests/enumerate-tests
> If your control file depends on anything else, such a check would
> probably be an inconvenience (or worse) to anyone trying to backport
> your package, and might hinder security updates too.
I have quoted that again because I think it's important and don't want
it overlooked.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: How to distinguish .udeb files from regular .deb files?
On Fri, Aug 19, 2016 at 01:47:15PM +0200, Philipp Hahn wrote: > Is there some other (preferred) way to identify .udeb packages? > > 1. "Section: debian-installer"? > > 2. Some pages use the suffix "-udeb" or "-di" in their package names. > > 3. If the control file contains a "isinstallable" script. > > dpkg -I 'potential.udeb' | grep -q isinstallable > > 4. If the control files has a "Installer-Menu-Item" field: > > grep -I 'potential.udeb' | grep -q Installer-Menu-Item > > Other ideas? Maybe: Lack of /usr/share/doc. > Or is there a definitive answer hidden somewhere? There is no spoon. AFAIK, udebs are just like regular debs but with less strict policy requirements, so in theory, you will never be able to tell for sure, based solely on its contents and not the filename, whether a given package is an udeb or just a deb which does not follow debian policy. Thanks.
Re: Computing Build-Depends at build time (and other updates to debian/control)?
On Mon, Aug 22, 2016 at 6:55 PM, Ian Jackson wrote: > You're effectively asking for the interface to a Debian source package > to be redefined so that every package must be built twice: once to > discover its control file, and then again to actually build the > binaries. This would be incredibly useful for moving towards a world of automatic packaging based on whatever metadata upstream is already providing for other package management formats. https://summit.debconf.org/debconf14/meeting/25/debdry-debian-dont-repeat-yourself/ http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debdry_Debian_Dont_Repeat_Yourself.webm https://wiki.debian.org/AutomaticPackagingTools -- bye, pabs https://wiki.debian.org/PaulWise
Mount namespaces
I recently noticed that schroot could no longer tidy up chroots it had finished with. Much investigation with the help of debian Bug #749897 revealed that there is a problem with the combination of schroot, systemd and demons that use the 'private mount namespace' feature. (PrivateTmp=yes in the systemd unit definition). If the system has any daemons that use this feature (e.g cups, colord, rtkit-daemon), then mount can no longer unmount at the end when tidying up the chroot. The daemons are nothing to do with the chroots - they are running in the main machine, but because of this namespace feature umount no longer works the way it used to. You get EBUSY on attempting to unmount. I'm bringing to this to debian devel as this is a major regression and I really don't understand how this new namespace thing is expected to work. Why does the use of this featuer confuse umount? Shouldn umount know about the namespaces and DTRT? Why can't it tell that these daemons are nothing to do with the chroots that are being cleaned-up? I'm fine with shiny new features, that I presume are useful for something (containers?), but it seems to me that they shouldn't be breaking longstanding behaviour, like the ability to unmount bind-mounts in a chroot. Currently anyone wanting to clean up an schroot chroot on a machine runing systemd, has to shut down the unrelated daemons: cups, colord and rtkit first, tidy the chroot and then restart them. This seems like madness, and cannot be how this was intended to work. So, where is the right place to discuss this? How exactly is this expected to work? Oh, and why does kdevtmpfs appear in the list of daemons with a private mount namespace, but it _doesn't_ need to be stopped to do the unmount? What is special about that one? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
We cannot always know which source package to build to satisfy a given dependency (was: Re: Computing Build-Depends at build time (and other updates to debian/control)?)
Hi, Quoting Ian Jackson (2016-08-22 12:55:48) > But even worse is that it would no longer be possible to sensibly > compute build orders without pre-building every package in a source > archive, because it would not be possible to statically determine > which binary packages are supposed to come from which sources. since you are talking about computing build orders and avoiding having to pre-build every source package, I have bad news for you. It is currently already impossible to know which source package to build to satisfy a given dependency if that source package hasn't been built before for the architecture that you are building for. This is not only because source package metadata does not tell you: - anything about in which version the source package will build its binary packages - which (possibly versioned and architecture qualified) virtual packages a real binary package will provide once built - whether they will build a binary package that is Essential:yes So if you start with only source package information (from a Sources file) as you would for example if you want to bootstrap a new architecture, then there is currently no way to reliably auto-compute the order in which you need to build source packages. You can only reliably carry out this computation for re-bootstrapping an already existing architecture where you already built the binary packages of all source packages. So tools like rebootstrap which attempt to bootstrap Debian from zero currently start with a manually maintained set of source packages that is to be built, figure out which source packages have their build dependencies satisfied already, build those and then check again for more source packages that can be built given the newly built binary packages. The only way to currently precompute the build order just from the metadata would be to make some assumptions which do not hold in some cases like: - source packages build binary packages that have the same version as the source package they build from - the installation set of all Essential:yes packages is the same on all architectures - there is no dependency on virtual packages - source packages build all their binary packages for architectures listed in the Architectures field Rebootstrap currently works around this using lots of heuristics and manually set assumptions and manual interventions during the bootstrap progress. But this is something that should be encoded in the source package metadata so that build orders can be computed upfront. There is work into the direction of fixing this. For example the architectures a source package will build each binary for is already encoded in the Packages-List field. This has topic been extensively discussed during the bootstrap sprint and you can read more about it in section 1 of the sprint results at [1] Thanks! cheers, josch [1] https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results signature.asc Description: signature
Bug#835099: ITP: skales -- Boot image creation tools for qualcomm boards
Package: wnpp Severity: wishlist Owner: Riku Voipio * Package name: skales Version : 0.20160202 Upstream Author : Stephen Boyd * URL : git://codeaurora.org/quic/kernel/skales * License : BSD (3 clause) Programming Lang: Python and POSIX shel Description : Boot image creation tools for qualcomm boards Scripts and tools used to build kernel images for some Qualcomm SoC based boards, such as DB410c. Tools included in the package - dtbTool for building a QCDT table - mkbootimg, replacement for android's mkbootimg
We cannot always know which source package to build to satisfy a given dependency (was: Re: Computing Build-Depends at build time (and other updates to debian/control)?)
Johannes Schauer writes ("We cannot always know which source package to build
to satisfy a given dependency (was: Re: Computing Build-Depends at build time
(and other updates to debian/control)?)"):
> since you are talking about computing build orders and avoiding
> having to pre-build every source package, I have bad news for you.
> It is currently already impossible to know which source package to
> build to satisfy a given dependency if that source package hasn't
> been built before for the architecture that you are building for.
>
> This is not only because source package metadata does not tell you:
Thanks for the info. I'm sure all of this is very annoying.
But, do you think that my original point, which is that this pre-build
requirement would make matters worse, is right ?
ISTM from a quick read of the wiki page you mention that most of these
problems might be solved or mitigated by relatively small (but perhaps
broad) changes to our existing practices, or by use of new features
like build profiles. (Of course I don't mean that the work to agree
and implement such changes is trivial.)
Regards,
Ian.
Re: We cannot always know which source package to build to satisfy a given dependency (was: Re: Computing Build-Depends at build time (and other updates to debian/control)?)
Hi, Quoting Johannes Schauer (2016-08-22 14:58:36) > Quoting Ian Jackson (2016-08-22 12:55:48) > > But even worse is that it would no longer be possible to sensibly > > compute build orders without pre-building every package in a source > > archive, because it would not be possible to statically determine > > which binary packages are supposed to come from which sources. > > since you are talking about computing build orders and avoiding having to > pre-build every source package, I have bad news for you. It is currently > already impossible to know which source package to build to satisfy a given > dependency if that source package hasn't been built before for the > architecture > that you are building for. since I was told that my message could easily be misunderstood, let me clarify. I did not intend to give arguments for why computing Build-Depends at build time would be a good idea. I'm much of the opposite opinion myself *especially* for the purposes of being able to auto-generate a build order in a reliable way at some point in the future. Instead, I just wanted to debunk Iain's claim that it would "no longer be possible to sensibly compute build orders without pre-building every package" as this has never been possible (without heuristics and a manually maintained set of assumptions). > This is not only because source package metadata does not tell you: [...] - > whether they will build a binary package that is Essential:yes in fact this information is already present in the Sources index if a package was rebuilt with dpkg 1.18.2 or newer. It is represented as essential=yes in the Packages-List field. Rebootstrap already makes use of this field for its purposes. (thanks guillem for correcting me!) Some good documentation of the capabilities of the Packages-List field can be found in the man page dsc(5). Thanks! cheers, josch signature.asc Description: signature
Re: Computing Build-Depends at build time (and other updates to debian/control)?
On Mon, Aug 22, 2016 at 08:10:40PM +0800, Paul Wise wrote: > On Mon, Aug 22, 2016 at 6:55 PM, Ian Jackson wrote: > > You're effectively asking for the interface to a Debian source package > > to be redefined so that every package must be built twice: once to > > discover its control file, and then again to actually build the > > binaries. > This would be incredibly useful for moving towards a world of > automatic packaging based on whatever metadata upstream is already > providing for other package management formats. Not really. This information is already available while building the source, aka before the source reaches the archive. So it can be used at this stage. It have nothing to do with recalculating the build dependency while building binaries. Bastian -- A woman should have compassion. -- Kirk, "Catspaw", stardate 3018.2
Re: Porter roll call for Debian Stretch
Hi Guillem, 2016-08-21 14:02 GMT+02:00 Guillem Jover : > Hi! > > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote: >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for >> all >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu. >> >> My assumption was that this set of architectures need the least amount of >> additional work since they are tested already in Ubuntu, but I would be happy >> if more ports would opt in for PIE. >> >> I plan filing wishlist bugs against dpkg and gcc with the patches >> after I rebuilt a >> few packages with the defaults. > > TBH I think PIE should in fact be safer to enable globally than > bindnow, because the latter changes the run-time behavior and things > might break (perhaps even silently) when failing to load plugins > or similar. Yes, in that sense enabling PIE is safer indeed. Regarding bindnow I don't expect too many surprises either, since other distributions already tested enabling bindnow and probably they found most issues. > > From dpkg PoV enabling both, would at least require a full-archive > rebuild, for bindnow ideally also a full autopkgtest run (as the > updated dpkg FAQ states now, after Lucas Nussbaum approached me some > weeks ago mentioning he was willing to do such archive-wide rebuild). The patches at [2] seem to work well and since you expressed that you would prefer changing both toolchain and dpkg, too, I would like to suggest running the rebuild with those patches. I think Matthias would be OK with the patch since it is very small and brings Debian's gcc closer to Ubuntu's. Lucas, could you please run the rebuild with the three patches? I'll attach the patches to the bug reports. Cheers, Balint [2] https://people.debian.org/~rbalint/ppa/pie-bindnow/
Re: Computing Build-Depends at build time (and other updates to debian/control)?
Hi, On 21.08.2016 11:03, Josh Triplett wrote: > Mechanisms like shlibdeps, dh_perl, and other substvars allow packages > to compute their Depends at build time. This avoids hard-coding > dependencies, simplifies upgrading the package to new versions, and > makes transitions much easier. Package builds typically happen in environments where the network is unavailable, so any information that could influence this decision must be contained in the source package itself (in which case the maintainer can update the control file as well), or in a build dependency (in which case that package could pull in the required other package). Simon signature.asc Description: OpenPGP digital signature
Bug#835135: ITP: r-bioc-metagenomeseq -- GNU R statistical analysis for sparse high-throughput sequencing
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-metagenomeseq Version : 1.14.2 Upstream Author : Joseph N. Paulson * URL : http://www.bioconductor.org/packages/release/bioc/html/metagenomeSeq.html * License : Artistic-2.0 Programming Lang: GNU R Description : GNU R statistical analysis for sparse high-throughput sequencing MetagenomeSeq is designed to determine features (be it Operational Taxanomic Unit (OTU), species, etc.) that are differentially abundant between two or more groups of multiple samples. metagenomeSeq is designed to address the effects of both normalization and under-sampling of microbial communities on disease association detection and the testing of feature correlations. Remark: This package will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-metagenomeseq/trunk/
Re: How to distinguish .udeb files from regular .deb files?
(Cc's welcome.)
Hi,
Philipp Hahn (2016-08-19):
> Looking inside dpkg-name, it tries to evaluate "Package-Type" [1], but
> that is not contained in the control file of the binary package, so
> always evaluates to "deb":
> > 123 my $type = $fields->{'Package-Type'} || 'deb';
This field is only for binary stanzas in source package's control files,
and it doesn't appear in binary packages.
> Is there some other (preferred) way to identify .udeb packages?
>
> 1. "Section: debian-installer"?
Looking at an amd64 sid chroot with:
deb file:///srv/mirrors/debian sid main main/debian-installer non-free
this seems to be something that works. Only hits in /var/lib/apt/lists
are in:
_srv_mirrors_debian_dists_sid_main_debian-installer_binary-amd64_Packages
_srv_mirrors_debian_dists_sid_main_source_Sources
This is likely your best bet here (besides the extension).
> 2. Some pages use the suffix "-udeb" or "-di" in their package names.
Nope, you would miss a lot of packages (list below my signature).
> 3. If the control file contains a "isinstallable" script.
> > dpkg -I 'potential.udeb' | grep -q isinstallable
Almost no udebs come with such a script; in sid, those who do are:
bootstrap-base
console-setup-udeb
debian-edu-install-udeb
debian-edu-profile-udeb
grub-installer
kbd-chooser
lilo-installer
live-installer
localechooser
lvmcfg
network-console
partman-base
pkgsel
file-preseed
network-preseed
rescue-mode
user-setup-udeb
> 4. If the control files has a "Installer-Menu-Item" field:
> > grep -I 'potential.udeb' | grep -q Installer-Menu-Item
Not all udebs insert themselves through Installer-Menu-Item (only 52 out
of 426).
> Other ideas?
> Or is there a definitive answer hidden somewhere?
I don't think so.
KiBi.
Non-udeb and non-di packages:
-
anna
apt-cdrom-setup
apt-mirror-setup
archdetect
base-installer
bootstrap-base
bterm-unifont
cdebconf-gtk-entropy
cdebconf-gtk-terminal
cdebconf-newt-entropy
cdebconf-newt-terminal
cdebconf-priority
cdebconf-text-entropy
cdrom-checker
cdrom-detect
cdrom-retriever
choose-mirror
choose-mirror-bin
clock-setup
console-keymaps-acorn
console-keymaps-amiga
console-keymaps-at
console-keymaps-atari
console-keymaps-dec
console-keymaps-mac
console-keymaps-sun
console-keymaps-usb
console-setup-amiga-ekmap
console-setup-ataritt-ekmap
console-setup-macintoshold-ekmap
console-setup-pc-ekbd
console-setup-pc-ekmap
console-setup-sun4-ekmap
console-setup-sun5-ekmap
disk-detect
di-utils
di-utils-exit-installer
di-utils-mapdevfs
di-utils-reboot
di-utils-shell
di-utils-terminfo
download-installer
driver-injection-disk-detect
efi-reader
env-preseed
ethdetect
file-preseed
finish-install
grub-installer
hw-detect
initrd-kickseed
initrd-preseed
installation-locale
iso-scan
kbd-chooser
kickseed-common
lilo-installer
live-installer
load-cdrom
load-iso
load-media
localechooser
lowmem
lowmemcheck
ltsp-client-builder
lvmcfg
lvmcfg-utils
main-menu
mdcfg
mdcfg-utils
media-retriever
mountmedia
netcfg
netcfg-static
net-retriever
network-console
network-preseed
nobootloader
oldsys-preseed
partconf-find-partitions
partconf-mkfstab
partman-auto
partman-auto-crypto
partman-auto-lvm
partman-auto-raid
partman-base
partman-basicfilesystems
partman-basicmethods
partman-btrfs
partman-crypto
partman-crypto-dm
partman-efi
partman-ext3
partman-iscsi
partman-jfs
partman-lvm
partman-md
partman-multipath
partman-nbd
partman-partitioning
partman-target
partman-utils
partman-xfs
pkgsel
preseed-common
rescue-check
rescue-mode
rootskel
rootskel-gtk
save-logs
simple-cdd-profiles
udpkg
usb-discover
signature.asc
Description: Digital signature
Re: Mount namespaces
On Mon, 2016-08-22 at 13:26 +0100, Wookey wrote: > I recently noticed that schroot could no longer tidy up chroots it had > finished with. Much investigation with the help of debian Bug #749897 > revealed that there is a problem with the combination of schroot, > systemd and demons that use the 'private mount namespace' > feature. (PrivateTmp=yes in the systemd unit definition). > > If the system has any daemons that use this feature (e.g cups, colord, > rtkit-daemon), then mount can no longer unmount at the end when > tidying up the chroot. The daemons are nothing to do with the chroots > - they are running in the main machine, but because of this namespace > feature umount no longer works the way it used to. You get EBUSY on > attempting to unmount. > > I'm bringing to this to debian devel as this is a major regression and > I really don't understand how this new namespace thing is expected to > > work. Mount namespaces are now quite an old feature; they were introduced in Linux 2.4.19. However, systemd changes the default propagation mode for mount namespaces to "shared", i.e. new mounts are propagated to peer namespaces by default. The section "Shared Subtrees" in mount_namespaces(7) explains the different propagation modes and the reasons for wanting propagation by default. . Unfortunately, some applications that manipulate mount namespaces expect the old default, "private" (no propagation) but do not explicitly request it. > Why does the use of this featuer confuse umount? Shouldn umount > know about the namespaces and DTRT? Why can't it tell that these > daemons are nothing to do with the chroots that are being cleaned-up? I don't know what's going on there. [...] > Oh, and why does kdevtmpfs appear in the list of daemons with a > private mount namespace, but it _doesn't_ need to be stopped to do the > unmount? What is special about that one? Perhaps its unit file includes MountFlags=private. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
Repeated Upgrade of Package
Howdy! First off, the usual- if this is not the correct list for an inquiry like this, I sincerely apologize, and would greatly appreciate a pointer to the correct list. On top my problem- The situation we're encountering is that apt-get (and aptitude, fwiw) continuously want to upgrade an installed package that we maintain, even when the version, hash, etc., is not changed. This output demonstrates the issue: pdbogen@srcclr-mbp-pbogen:~$ date; sudo apt-get install srcclr Mon Aug 22 15:08:16 PDT 2016 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: srcclr 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/61.9 MB of archives. After this operation, 128 MB disk space will be freed. (Reading database ... 144061 files and directories currently installed.) Preparing to unpack .../apt/archives/srcclr_2.5.2.deb ... Unpacking srcclr (2.5.2) over (2.5.2) ... Setting up srcclr (2.5.2) ... Processing triggers for man-db (2.7.5-1) ... pdbogen@srcclr-mbp-pbogen:~$ date; sudo apt-get install srcclr Mon Aug 22 15:08:20 PDT 2016 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: srcclr 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/61.9 MB of archives. After this operation, 128 MB disk space will be freed. (Reading database ... 144061 files and directories currently installed.) Preparing to unpack .../apt/archives/srcclr_2.5.2.deb ... Unpacking srcclr (2.5.2) over (2.5.2) ... Setting up srcclr (2.5.2) ... Processing triggers for man-db (2.7.5-1) ... My employer maintains a Debian package, `srcclr`. Our Release file is here: https://download.srcclr.com/ubuntu/stable/Release ..the corresponding Packages file is: https://download.srcclr.com/ubuntu/stable/Packages And accordingly the package itself is here: https://download.srcclr.com/ubuntu/stable/srcclr_2.5.2.deb I've spent a bit of time googling and found mentions of this happening from time to time, but no clear explanation about when/why. I'd greatly appreciate any guidance anyone can provide on how to troubleshoot this. Thanks, -- . Patrick Bogen . ... signature.asc Description: Digital signature
Re: Porter roll call for Debian Stretch
On 08/22/2016 07:12 PM, Bálint Réczey wrote: > Hi Guillem, > > 2016-08-21 14:02 GMT+02:00 Guillem Jover : >> Hi! >> >> On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote: >>> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for >>> all >>> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu. >>> >>> My assumption was that this set of architectures need the least amount of >>> additional work since they are tested already in Ubuntu, but I would be >>> happy >>> if more ports would opt in for PIE. >>> >>> I plan filing wishlist bugs against dpkg and gcc with the patches >>> after I rebuilt a >>> few packages with the defaults. >> >> TBH I think PIE should in fact be safer to enable globally than >> bindnow, because the latter changes the run-time behavior and things >> might break (perhaps even silently) when failing to load plugins >> or similar. > > Yes, in that sense enabling PIE is safer indeed. Regarding bindnow > I don't expect too many surprises either, since other distributions > already tested enabling bindnow and probably they found > most issues. > >> >> From dpkg PoV enabling both, would at least require a full-archive >> rebuild, for bindnow ideally also a full autopkgtest run (as the >> updated dpkg FAQ states now, after Lucas Nussbaum approached me some >> weeks ago mentioning he was willing to do such archive-wide rebuild). > > The patches at [2] seem to work well and since you expressed that you would > prefer changing both toolchain and dpkg, too, I would like to suggest running > the rebuild with those patches. > > I think Matthias would be OK with the patch since it is very small and brings > Debian's gcc closer to Ubuntu's. > > Lucas, could you please run the rebuild with the three patches? > > I'll attach the patches to the bug reports. For the record I have opened #835146, #835148 and #835149 against dpkg and gcc-6 with the patches. > > [2] https://people.debian.org/~rbalint/ppa/pie-bindnow/ >
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Hi All, 2016-05-28 23:16 GMT+02:00 Bálint Réczey : > Hi, > > 2016-05-18 2:21 GMT+02:00 Guillem Jover : >> On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote: >>> I'm not a fan myself for turning on hardening flags in the compiler itself, >>> but if you do that, then dpkg issues like https://bugs.debian.org/823869 >>> need to be addressed (whether all obscure build systems picking these up, or >>> not). >> >> That bug report is not relevant in its current form, as explained >> there. >> >> If the default changes in the Debian default compiler, then I'll just >> make the +pie option a no-op and change -pie to set -fno-PIE, so that >> the options are only added when they are expected. >> >> The difference with that request is that it would currently add >> -fno-PIE for most packages that do not change the default flags, >> which might break their build-systems. > > Thank you Guilllem. > > Matthias, are you OK with the resolution of #823869 and would you be > OK with using --enable-default-pie for GCC if dpkg adopts the solution > described above? For the record I have opened #835146, #835148 and #835149 against dpkg and gcc-6 with a set of proposed patches [2] which seem to work well. [2] https://people.debian.org/~rbalint/ppa/pie-bindnow/
Re: Computing Build-Depends at build time (and other updates to debian/control)?
Paul Wise wrote: > This would be incredibly useful for moving towards a world of > automatic packaging based on whatever metadata upstream is already > providing for other package management formats. > > https://summit.debconf.org/debconf14/meeting/25/debdry-debian-dont-repeat-yourself/ > http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debdry_Debian_Dont_Repeat_Yourself.webm > https://wiki.debian.org/AutomaticPackagingTools That describes the exact case that motivated me to raise this; the uniform upstream packaging metadata used throughout the entire Cargo ecosystem contains all the information needed to generate Build-Depends (and Depends) on all other necessary Cargo packages. I'd like to avoid repeating that information.
Re: Computing Build-Depends at build time (and other updates to debian/control)?
Simon Richter wrote: > On 21.08.2016 11:03, Josh Triplett wrote: > > Mechanisms like shlibdeps, dh_perl, and other substvars allow packages > > to compute their Depends at build time. This avoids hard-coding > > dependencies, simplifies upgrading the package to new versions, and > > makes transitions much easier. > > Package builds typically happen in environments where the network is > unavailable, so any information that could influence this decision must > be contained in the source package itself Absolutely agreed. However: > (in which case the maintainer can update the control file as well) I'd like to avoid including that information in the source package two or more times. See Paul Wise's reply in this thread regarding upstream metadata formats and "Don't Repeat Yourself".
Re: Repeated Upgrade of Package
On Mon, Aug 22, 2016 at 03:10:54PM -0700, pdbo...@cernu.us wrote: > On top my problem- The situation we're encountering is that apt-get (and > aptitude, fwiw) continuously want to upgrade an installed package that we > maintain, even when the version, hash, etc., is not changed. This output > demonstrates the issue: Your package doesn't match the metadata provided for it, so libapt thinks its a rebuild (without version change) and downloads the "new" version for installation. In your case at least the Installed-Size: field is missing in the Packages file (which is hence assumed to be zero), while the control file inside the package has such a field with non-zero size. Other fields which must match to the letter are e.g. Depends and Pre-Depends (a "common" mistake is e.g. having versions there which are rewritten by some tools like a 0-epoch). Not sure what tool you are using to generate an apt repository, but it seems rather non-standard given that it includes the deb file also in the Release file… using one of the many already existent solutions might be better… Best regards David Kalnischkies signature.asc Description: PGP signature
