Bug#71527: [random1]
[random1] go to http://www.giww.org/jump.php?url=111 His odd shaped gun sleeps. Mine odd shaped computer looks around. Our hairy white computer is on fire or a green ipaq looks around. Any fancy beautiful shining expensive stupid stupid gun lies. Mine red ipaq smells. His small purple forg is angry. Her daughters red house calculates while our golden beautiful expensive magazine looks around. His slopy bicycle calculates. Her little odd shaped boat is on fire. His brothers hairy mouse prepare for fight. Mine bluish baby is on fire. Herdaughters small silver omprella show its value or maybe his brothers purple camera arrives. The silver soft soft tall golden soda falls. Our round-shaped carpetfidgeting as soon as their hairy caw arrives the time that the little red book sleeps. Any round laptop adheres. Her daughters bluish soft house makes sound. The golden sony spit and still any given purplelaptop makes sound while anyfancy silver hairy expensive small small boots run. Our chi ldren white exam book is angry. His brothers noisy underwares stinks. Any slopy glove lies or a white printer sleeps. Any given white well-crafted boat prepare for fight. A tall odd shaped pensil smells or our children round-shaped bra fidgeting. Their purple mp3 player smells at the place that our children fancy soda stands-still. The smart white tv show its value. Our children noisy sport shoes stares. His brothers shining sofa arrives. Their white baby prepare for fight. Their smart forg lies. Her tall exam book show its value. Whose slopy slopy baby calms-down. His white shining printer stinks. Her daughters white smart gun adheres and still whose fancy slopy bicycle snores while our white dog smells.
Bug#294308: xfce4-battery-plugin: does not display -- error on startup
Package: xfce4-battery-plugin Version: 0.2.0-4 Severity: important After adding the battery plugin to the panel, a space for it is displayed but nothing shows in the space. Looking in .xsession-errors, the following error is logged when the battery monitor tries to startup: (xfce4-session:2911): Gtk-CRITICAL **: file gtkwidget.c: line 1911 (gtk_widget_destroy): assertion `GTK_IS_WIDGET (widget)' failed -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages xfce4-battery-plugin depends on: ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libglib2.0-0 2.6.1-3 The GLib library of C routines ii libgtk2.0-0 2.4.14-2The GTK+ graphical user interface ii libice6 4.3.0.dfsg.1-10 Inter-Client Exchange library ii libpango1.0-01.6.0-3 Layout and rendering of internatio ii libsm6 4.3.0.dfsg.1-10 X Window System Session Management ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii libxfce4util-1 4.0.6-1 Utility functions library for Xfce ii libxfcegui4-14.0.6-1 Basic GUI C functions for Xfce4 ii libxml2 2.6.11-5GNOME XML library ii xfce4-panel 4.0.6-1 The Xfce4 desktop environment pane ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410771: Re: Bug#410771: emacs-snapshot: error "Lisp nesting exceeds `max-lisp-eval-depth'"
Control: tags -1 moreinfo
Control: retitle -1 emacspeak loops infinite on specific directory
Hi Tim,
Sorry for taking so long to respond to this bug, but the package
emacspeak was orphaned and just got a new maintainer.
On 24-02-07 12:04, Romain Francoise wrote:
> I believe that this is a bug in emacspeak, not in Emacs.
>
> It's apparently looping endlessly when encountering this particular
> remote directory setup, as shown by the following sequence in the
> trace:
>
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
>
> I'm therefore reassigning this report to emacspeak. Feel free to
> reassign back if this turns out to be a bug in Emacs.
It has been a long time since you reported this issue. Before I dive
into it, could you please let me know if you can still reproduce this issue?
Paul
signature.asc
Description: OpenPGP digital signature
Bug#719757: openmotif: please package the man-pages separately so that they can be installed along with Lesstif
Control: reassign -1 motif On 15-08-13 01:56, G.raud wrote: > Having the OpenMotif manual pages in a separate package libmotif-doc instead > of > inside libmotif-dev would allow this new package not to conflict with any > Lesstif > packages; thus it would be possible to have some Motif manual pages installed > along > with Lesstif. Motif is now licensed with LGPL so it is finally free. We moved it to the main archive and we try to remove Lesstif2 before we release Jessie, making this bug moot. However, depending on the size of the documentation, it might still be worth it. I can't recall if we didn't look into this when we did the motif overhaul, so reassigning to motif to not forget about this. Paul signature.asc Description: OpenPGP digital signature
Re: [cluster3] please rebuild and possibly move to main
On 10-09-13 19:21, Thorsten Alteholz wrote: > thanks alot for your info. Unfortunately the motif license is not the > only hurdle to put cluster3 into main. Clear. > Anyway, if I understand you right, I just have to reupload the package > to get everything straight with the motif update (so no need to change > any dependencies)? Yes, but if you don't have other changes that you want to upload for, this stuff does not warrant an upload just for itself. Everything *should* just work if you don't do anything. Paul signature.asc Description: OpenPGP digital signature
Bug#1072302: src:gnome-shell-mailnag: fails to migrate to testing for too long: versioned dependency not yet in unstable
Source: gnome-shell-mailnag Version: 40.0-5 Severity: serious Control: close -1 40.0-7 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gnome-shell-mailnag has been trying to migrate for 46 days [2]. Hence, I am filing this bug. The version in unstable depends on a version of gnome-shell that's not even in unstable. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gnome-shell-mailnag OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary
Source: transaction Version: 3.0.0-1 Severity: serious Control: close -1 4.0-1 X-Debugs-CC: alexandre.deti...@gmail.com Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:transaction has been trying to migrate for 40 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=transaction OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary
Hi, On 15-06-2024 11:38 p.m., Colin Watson wrote: This was fixed by transaction 4.0-2, and it looks like either you cancelled your upload or it was automatically dropped from the DELAYED queue. I cancelled my upload once I spotted 4.0-2. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1016828: poc-streamer: flaky autopkgtest: regularly times out on i386
Source: poc-streamer Version: 0.4.2-5 Severity: serious User: debian...@lists.debian.org Usertags: flaky timeout Dear maintainer(s), I looked at the results of the autopkgtest of you package because it was showing up on our "slow" page [1]. I noticed that there were several runs that took 8:21 (our timeout time per test times 3), while successful runs more in the order of a minute. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. On top of that, when a test just hangs that's not good for our infrastructure. I'll put your package on our reject_list for i386. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [1] https://ci.debian.net/status/slow/ OpenPGP_signature Description: OpenPGP digital signature
Bug#1018739: src:libowfat: fails to migrate to testing for too long: FTBFS
Source: libowfat Version: 0.30-4 Severity: serious Control: close -1 0.32-3 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1014120 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:libowfat has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package fails to build from source, as reported in bug #1014120. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=libowfat OpenPGP_signature Description: OpenPGP digital signature
Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1
On Tue, 2022-08-30 at 22:59 +0200, Thomas Uhle wrote: > I have prepared a patch for changing the order in which the libraries > are built and to fix linking. Thanks for the patch, please consider sending it upstream too, even though upstream doesn't appear to be very active. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1
On Wed, 2022-08-31 at 17:10 +0200, Thomas Uhle wrote: > Now I have attached the patch to upstream's bug ticket as requested > after recovering my Sourceforge account. Anyway, I don't have hope > that there is going to happen much. Yet it would be good if Debian's > libdbus-c++-* packages could be updated at least. Thanks for that. For the record, I'm not involved in the package and the bug report was only a drive-by bug for an unimportant issue, so I don't have any intention to work on this myself. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#889114: libdbus-c++-{ecore,glib}-1.so: undefined symbols: need -ldbus-c++-1
On Thu, 2022-09-01 at 10:29 +0800, Paul Wise wrote: > Thanks for that. For the record, I'm not involved in the package and > the bug report was only a drive-by bug for an unimportant issue, > so I don't have any intention to work on this myself. PS: I just noticed the package is orphaned, so anyone, including yourself, can update the package fixing any issues. Please read the following links and you will get an idea of how to get this issue fixed in Debian. There are active sponsors who accept updates to orphaned packages, so you shouldn't have any problem getting yours accepted. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmus-vs-qa-uploads https://mentors.debian.net/intro-maintainers/ https://mentors.debian.net/sponsors/rfs-howto/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#567680: Please add resize option "set longest side to ..."
On Sat, 30 Jan 2010 18:45:12 +0100 Siegfried Gevatter wrote: > From: Ernst > https://bugs.launchpad.net/ubuntu/+source/nautilus-image-converter/+bug/493322 > > nautilus-image-converter is a great addon for nautilus, thanks for this one! > Today, I wanted to resize some images. Some are rotated. If I set the > new size to 800x600, all images (which originally are 1600x1200) are > resized to 800x600 (as expected). However, all 1200x1600 images (= > rotated) are converted to 600x450. I would expect the longest side > would be resized to 800, so the resulting image would be 600x800. nautilus-image-converter 0.4.0-2 has been reintroduced into Debian unstable. Please try it and see if the issue has been fixed. If the issue has been fixed, please let us know on this bug. If the issue has not been fixed, please search the upstream bug database to see if the issue is already reported and if it is not reported, then report a new issue upstream. Please let us know about any new or existing upstream bugs you file or find. https://gitlab.gnome.org/coreyberla/nautilus-image-converter/-/issues -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#638985: nautilus-image-converter does not convert/mogrify
On Tue, 23 Aug 2011 16:20:56 +0200 B. Wech wrote: > at LMDE (Linux Mint Debian Testing Edition) nautilus-image-converter starts as > expected but if I tryed to run a conversion I got the following message: > > " '00023.jpg' cannot be rotated. Check whether you have permission to write to > this folder." > > So it seems there is a permission problem but I don't know why... nautilus-image-converter 0.4.0-2 has been reintroduced into Debian unstable. Please try it and see if the issue has been fixed. If the issue has been fixed, please let us know on this bug. If the issue has not been fixed, please search the upstream bug database to see if the issue is already reported and if it is not reported, then report a new issue upstream. Please let us know about any new or existing upstream bugs you file or find. https://gitlab.gnome.org/coreyberla/nautilus-image-converter/-/issues -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1022175: tup: FTBFS on riscv64
On Fri, 2022-10-21 at 12:46 +, JunYuan Tan wrote: > There is a merged upstream patch [1] that fixes this issue for riscv64. I think this is the wrong approach, since it means that every new arch that comes along needs to add a string for itself and the list of strings grows longer and longer even though tup doesn't actually do anything differently on arches except x86_64, other than pass along the architecture string to the Tupfiles it runs. If there is a standard define for the current architecture string defined by GCC/clang, then the code should use that, so that the right architecture string will be present by default on all distros. If there is not, then debian/rules should pass $(DEB_HOST_GNU_TYPE) to the CONFIG_TUP_ARCH field in the tup.config file in dh_auto_configure. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1023804: git-remote-hg: autopkgtest needs update for new version of git: transport 'file' not allowed
Source: git-remote-hg Version: 1.0.3.2~ds-2 Severity: serious X-Debbugs-CC: g...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:git Dear maintainer(s), With a recent upload of git the autopkgtest of git-remote-hg fails in testing when that autopkgtest is run with the binary packages of git from unstable. It passes when run with only packages from testing. In tabular form: passfail gitfrom testing1:2.38.1-1 git-remote-hg from testing1.0.3.2~ds-2 all others from testingfrom testing I copied some of the output at the bottom of this report. This is due to """ * Addresses the security issue CVE-2022-39253: cloning an attacker-controlled local repository could store arbitrary files in the ".git" directory of the destination repository. """ This has a nice write up: https://vielmetti.typepad.com/logbook/2022/10/git-security-fixes-lead-to-fatal-transport-file-not-allowed-error-in-ci-systems-cve-2022-39253.html Currently this regression is blocking the migration of git to testing [1]. Of course, git shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in git was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from git should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=git https://ci.debian.net/data/autopkgtest/testing/amd64/g/git-remote-hg/28079228/log.gz Initialized empty Git repository in /tmp/autopkgtest-lxc.4ir0bv3l/downtmp/build.jzc/src/test/trash directory.main-push/tmp/sub/.git/ [master (root-commit) be983cd] init Author: A U Thor 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 empty Initialized empty Git repository in /tmp/autopkgtest-lxc.4ir0bv3l/downtmp/build.jzc/src/test/trash directory.main-push/tmp/gitrepo/.git/ Cloning into '/tmp/autopkgtest-lxc.4ir0bv3l/downtmp/build.jzc/src/test/trash directory.main-push/tmp/gitrepo/sub'... fatal: transport 'file' not allowed fatal: clone of '/tmp/autopkgtest-lxc.4ir0bv3l/downtmp/build.jzc/src/test/trash directory.main-push/tmp/sub' into submodule path '/tmp/autopkgtest-lxc.4ir0bv3l/downtmp/build.jzc/src/test/trash directory.main-push/tmp/gitrepo/sub' failed not ok 52 - push with submodule OpenPGP_signature Description: OpenPGP digital signature
Bug#1023805: guilt: autopkgtest needs update for new version of git: git log --decorate slightly different output
Source: guilt
Version: 0.36-2
Severity: serious
X-Debbugs-CC: g...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:git
Dear maintainer(s),
With a recent upload of git the autopkgtest of guilt fails in testing
when that autopkgtest is run with the binary packages of git from
unstable. It passes when run with only packages from testing. In tabular
form:
passfail
gitfrom testing1:2.38.1-1
guilt from testing0.36-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of git to testing
[1]. Of course, git shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in git was
intended and your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from git should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=git
https://ci.debian.net/data/autopkgtest/testing/amd64/g/guilt/28079229/log.gz
034: --- t-034.out 2022-11-09 20:14:59.570042679 +
+++ /tmp/guilt.log.218772022-11-09 20:15:20.238478229 +
@@ -307,133 +307,133 @@
Applying patch..can-have-embedded-single-slashes.patch
Patch applied.
% git log --decorate
-commit 434e07cacdd8e7eb4723e67cb2d100b3a4121a3a (HEAD -> guilt/master,
refs/patches/master/can-have-embedded-single-slashes.patch)
+commit 434e07cacdd8e7eb4723e67cb2d100b3a4121a3a (HEAD -> guilt/master)
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Can/have/embedded/single/slashes
-commit 7c3ffa4f940c862e9f11f5d4a5ae421f7a8d3141
(refs/patches/master/backslash-is-forbidden.patch)
+commit 7c3ffa4f940c862e9f11f5d4a5ae421f7a8d3141
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Backslash\is\forbidden.
-commit ea46f435d4d8f3c5349dce1aabc1a39fbf7ef803
(refs/patches/master/x.patch)
+commit ea46f435d4d8f3c5349dce1aabc1a39fbf7ef803
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
@
-commit a275ed5d7f10ea88c986852ee95a7d5a61663b5f
(refs/patches/master/cannot@have@the@sequence@at-brace.patch)
+commit a275ed5d7f10ea88c986852ee95a7d5a61663b5f
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Cannot@{have@{the@{sequence@{at-brace.
-commit f091fee39457e64ebd35410c1cf95e6613816a54
(refs/patches/master/cannot_end_in_.patch)
+commit f091fee39457e64ebd35410c1cf95e6613816a54
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Cannot end in ..
-commit 025672497aff5c910c8ff86aaedc662f14c2f4ad
(refs/patches/master/cannot-end-in-slash-.patch)
+commit 025672497aff5c910c8ff86aaedc662f14c2f4ad
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Cannot/end/in/slash/
-commit f13e243c7c56f39422567a431bccceec8b789596
(refs/patches/master/multiple-slashes--are--forbidden.patch)
+commit f13e243c7c56f39422567a431bccceec8b789596
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Multiple/slashes//are//forbidden.
-commit edef5e925083d445f71c170d3293fac9619bc7a2
(refs/patches/master/openbracketisforbidden.patch)
+commit edef5e925083d445f71c170d3293fac9619bc7a2
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Open[bracket[is[forbidden.
-commit 1626a11d979a1e9e775c766484172212277153df
(refs/patches/master/asterisk-is-forbidden.patch)
+commit 1626a11d979a1e9e775c766484172212277153df
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Asterisk*is*forbidden.
-commit 74df14ab3a0ec9a0382998fbf167ebb1b0a36c6a
(refs/patches/master/question-mark-is-forbidden.patch)
+commit 74df14ab3a0ec9a0382998fbf167ebb1b0a36c6a
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Question-mark?is?forbidden.
-commit ec46429125abdb0c5ac2b46cc399bdcd7cfc73fd
(refs/patches/master/crisalsoforbidden.patch)
+commit ec46429125abdb0c5ac2b46cc399bdcd7cfc73fd
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
CR
is
also
forbidden.
-commit 01524f9921af2a041cc88c068f76baa39e436cb2
(refs/patches/master/ctrlisforbidden.patch)
+commit 01524f9921af2a041cc88c068f76baa39e436cb2
Author: Author Name
Date: Mon Jan 1 00:00:00 2007 +
Ctrlisforbidden.
-commit 9fc9677b61880f9159838e89f714893e0a2fcafb
(refs/patches/master/delisforbidden.patch)
+commit 9fc9677b61880f9159838e89f714893e0a2fcafb
Author: Author Name
Bug#984149: Fwd: Bug#984149: genparse: Fix ftbfs: Use "std=c++14" flag to build
Forwarding a response that went to the wrong place.
--
bye,
pabs
https://wiki.debian.org/PaulWise
--- Begin Message ---
Source: genparse
Version: 0.9.2-1
Followup-For: Bug #984149
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear Maintainer,
This patch will make this package build with C++14 standard, as this package
doesn`t install any header files in /usr/include, so this patch should be OK.
I tried build on amd64/riscv64 and both succeed with this patch.
Thanks,
Yifan Xu
--- rules 2016-11-10 20:18:01.0 +0800
+++ genparse-0.9.2/debian/rules 2022-11-15 17:59:38.254170492 +0800
@@ -4,6 +4,7 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
+export DEB_CPPFLAGS_MAINT_APPEND = -std=c++14
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
RM = \
Description: fix ftbfs: use std=c++14 flag to build
.
genparse (0.9.2-2) unstable; urgency=medium
.
* Add -std=c++14 flag
Author: Yifan Xu
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Bug-Debian: https://bugs.debian.org/984149
Last-Update: 2022-11-15
--- genparse-0.9.2.orig/tests/misc/test-lib.sh
+++ genparse-0.9.2/tests/misc/test-lib.sh
@@ -27,7 +27,7 @@ error_() { echo "$0: $@" 1>&2; exit 1; }
framework_failure() { error_ 'failure in testing framework'; }
CFLAGS=-I.
-CXXFLAGS=-I.
+CXXFLAGS="-std=c++14 -I."
GNULIB_CPPFLAGS=-I$srcdir/../../gnulib/lib
GNULIB_LDFLAGS="-L../../gnulib/lib -lgnu"
--- End Message ---
signature.asc
Description: This is a digitally signed message part
Bug#1024209: genparse: Fix ftbfs: Use "std=c++14" flag to build
close 1024209 tags 984149 + patch user debian-ri...@lists.debian.org usertags 1024209 - riscv64 thanks On Wed, 2022-11-16 at 11:58 +0800, Yifan Xu wrote: > To: Debian Bug Tracking System > Followup-For: Bug #984149 Please submit followups for existing bug reports to the existing bugs instead of submitting new bug reports containing the followups. I have forwarded your mail to bug #984149 just now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984149#16 > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: debian-ri...@lists.debian.org This bug isn't riscv64-specific so you should not add the riscv64 usertags and should not CC the debian-riscv mailing list. > Dear Maintainer, I note that this package is orphaned so it doesn't have a maintainer. https://tracker.debian.org/pkg/genparse I also note that the upstream of this package isn't very active: https://sourceforge.net/p/genparse/ > This patch will make this package build with C++14 standard, as this package > doesn`t install any header files in /usr/include, so this patch should be OK. When submitting patches to the BTS, it is a good idea to mark the bug as having a patch using the patch tag. Add this to the pseudo-headers: Control: tags -1 + patch https://www.debian.org/Bugs/Reporting#control https://www.debian.org/Bugs/server-control#tag https://www.debian.org/Bugs/Developer#tags The patch to debian/rules seems like it should have been made to the upstream build system so both patches could be sent upstream instead. In addition both patches are workarounds not proper fixes, since they switch the package to an older version of C++ instead of fixing it to work with the current version of C++. Since this package is orphaned in Debian, unmaintained upstream, nothing in Debian seems to depend on it and fails to build with current versions of its build dependencies, perhaps it should be just removed from Debian instead of fixing it? If you agree, please file a removal: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removing-packages -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1025021: python-bayespy: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Source: python-bayespy Version: 0.5.22-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of python-bayespy fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 python-bayespy from testing0.5.22-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-bayespy/28728880/log.gz == ERROR: test suite for '/usr/lib/python3/dist-packages/bayespy/tests/__init__.py'> -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/suite.py", line 209, in run self.setUp() File "/usr/lib/python3/dist-packages/nose/suite.py", line 292, in setUp self.setupContext(ancestor) File "/usr/lib/python3/dist-packages/nose/suite.py", line 315, in setupContext try_run(context, names) File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run inspect.getargspec(func) ^^ AttributeError: module 'inspect' has no attribute 'getargspec' -- Ran 127 tests in 26.429s FAILED (errors=1) autopkgtest [23:02:54]: test upstream-unittest OpenPGP_signature Description: OpenPGP digital signature
Bug#1025197: zope.exceptions: (autopkgtest) needs update for python3.11: 'DummyTB' object has no attribute 'tb_lasti'
Source: zope.exceptions
Version: 4.5-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
zope.exceptions fails in testing when that autopkgtest is run with the
binary packages of python3-defaults from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
zope.exceptionsfrom testing4.5-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/z/zope.exceptions/28796455/log.gz
=== FAILURES
===
TextExceptionFormatterTests.test_formatException_recursion_in_tb_stack
self =
testMethod=test_formatException_recursion_in_tb_stack>
def test_formatException_recursion_in_tb_stack(self):
import traceback
fmt = self._makeOne()
err = ValueError('testing')
tb_recurse = DummyTB()
tb_recurse.tb_lineno = 27
r_f = tb_recurse.tb_frame = DummyFrame()
r_f.f_lineno = 27
r_f.f_locals['__exception_formatter__'] = 1
tb = DummyTB()
tb.tb_frame = DummyFrame()
tb.tb_next = tb_recurse
lines = fmt.formatException(ValueError, err, tb)
/usr/lib/python3/dist-packages/zope/exceptions/tests/test_exceptionformatter.py:347:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/zope/exceptions/exceptionformatter.py:186:
in formatException
result.extend(traceback.format_tb(tb))
/usr/lib/python3.11/traceback.py:59: in format_tb
return extract_tb(tb, limit=limit).format()
/usr/lib/python3.11/traceback.py:74: in extract_tb
return StackSummary._extract_from_extended_frame_gen(
/usr/lib/python3.11/traceback.py:416: in _extract_from_extended_frame_gen
for f, (lineno, end_lineno, colno, end_colno) in frame_gen:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
tb = 0x7fea63c25110>
def _walk_tb_with_full_positions(tb):
# Internal version of walk_tb that yields full code positions
including
# end line and column information.
while tb is not None:
positions = _get_code_position(tb.tb_frame.f_code, tb.tb_lasti)
E AttributeError: 'DummyTB' object has no attribute 'tb_lasti'
/usr/lib/python3.11/traceback.py:353: AttributeError
=== warnings summary
===
../../../../usr/lib/python3/dist-packages/zope/exceptions/tests/test_exceptionformatter.py:869
/usr/lib/python3/dist-packages/zope/exceptions/tests/test_exceptionformatter.py:869:
PytestCollectionWarning: cannot collect test class
'TestingTracebackSupplement' because it has a __init__ constructor
(from: tests/test_exceptionformatter.py)
class TestingTracebackSupplement(object):
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info
FAILED
tests/test_exceptionformatter.py::TextExceptionFormatterTests::test_formatException_recursion_in_tb_stack
=== 1 failed, 79 passed, 1 warning in 0.18s
autopkgtest [01:18:35]: test upstream-unittest
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1025021: python-bayespy: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Control: reassign -1 python3-nose Control: tags -1 ftbfs patch pending upstream Control: tags -1 - bookworm sid Control: merge 1024235 -1 Control: affects -1 src:python-bayespy Hi Håvard, On 01-12-2022 19:16, Håvard F. Aasen wrote: File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run inspect.getargspec(func) ^^ AttributeError: module 'inspect' has no attribute 'getargspec' This looks to be an error with nose, not python-bayespy. See bug #1024235 [1] Indeed, reassigning (and merging hopefully). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1028625: src:x-loader: fails to migrate to testing for too long: FTBFS
Source: x-loader Version: 1.5.1+git20110715+fca7cd2-2 Severity: serious Control: close -1 1.5.1+git20110715+fca7cd2-3 X-Debbugs-CC: Marcos Talau Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1026364 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:x-loader has been trying to migrate for 61 days [2]. Hence, I am filing this bug. The package failed to build from source, which was reported in bug 1026364. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=x-loader OpenPGP_signature Description: OpenPGP digital signature
Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs
Hi, [Release Team here] On Thu, 2 Mar 2023 18:42:56 +0100 Bastian Germann wrote: On Thu, 2 Mar 2023 05:10:41 +0100 Guilhem Moulin wrote: > Ah no my bad, the changelog entry is probably incorrect and the > cryptsetup-initramfs breakage is caused by the recent libargon2 upload > indeed, but AFAICT not by anything particular in the upload. I am sorry for having caused that issue, Daniel. Thanks for investigating, Guilhem. The changelog entry is correct because it fixes a formerly made change. 0~20171227-0.1 intended to compile only udeb without threads: "Build udeb without a dependency on pthreads" But it unintentionally compiled the .deb executable with the .a compiled without threads. The additional "make clean" fixes accidentally picking up the wrong .a. Do I understand correctly that: 1) argon2 in testing isn't affected 2) this bug isn't solved yet, despite the closure? 3) the issue for cryptsetup is worked around in cryptsetup libargon2-1 is linked by more packages. Are they all OK without this unintentional change unfixed? Why is the unintentional change not reverted or fixed? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs
Hi all, On 15-03-2023 23:28, Guilhem Moulin wrote: On Wed, 15 Mar 2023 at 22:43:31 +0100, Bastian Germann wrote: Am 15.03.23 um 22:39 schrieb Paul Gevers: Do I understand correctly that: 1) argon2 in testing isn't affected 2) this bug isn't solved yet, despite the closure? 3) the issue for cryptsetup is worked around in cryptsetup libargon2-1 is linked by more packages. Are they all OK without this unintentional change unfixed? Why is the unintentional change not reverted or fixed? There is no unintentional change. Yes there is, namely the fact that libargon2-1 no longer links against libpthread, which in turn caused a major regression in cryptsetup-initramfs (mitigated in src:cryptsetup 2:2.6.1-2). Unlike what I initially claimed in #1014110's msg#20 that change can't be reverted or fixed in src:argon2 since it's caused by building with a newer libc; a binNMU would therefore have caused the same regression, I'm not 100% sure I parse that sentence as you intended, so let me ask explicitly: if we binNMU (now or in the future) src:argon2 version 0~20171227-0.3 in bookworm, would it also loose its linking to libpthread? That would be a time bomb (not only in the archive, but also for downstreams and other users that do rebuilds). I *think* you're saying that despite libc's version, that is *not* the case. If packages are waiting for argon2 then I would prefer an unblock of both argon2 and cryptsetup at the same time. That wouldn't solve the ordering (but I spotted a new upload of src:argon2 fixing that). More importantly, argon2 >>0~20190702-0.1 should not be allowed in bookworm before cryptsetup >=2:2.6.1-2, as doing so would make systems using cryptsetup-initramfs (such an those using “encrypted LVM” layout from d-i) unbootable. cryptsetup can transition before argon2 though, and I do intend to file an unblock request for it given -3 mitigates #1028250. Bastien, since argon2 and cryptsetup likely won't enter testing at the same time (which is was I hoped to do with that bug clone dance, but that failed for the reasons you described) you might want to upload a new version with ‘Breaks: cryptsetup-initramfs (<<2:2.6.1-2)’. If you want something newer than 0~20171227-0.3 in bookworm, that is. (As far as cryptsetup is concerned it's fine to ship bookworm with argon2=0~20171227-0.3 and cryptsetup=2:2.6.1-3.) For the record, with my current understanding I prefer the scenario of keeping the versions of argon2 and cryptsetup in bookworm as they are. Feel free to convince the Release Team of the opposite in an unblock request. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs
Hi Guilhem, On 16-03-2023 14:31, Guilhem Moulin wrote: cryptsetup can only migrate when argon2 migrates, I see that in the excuse page now but don't understand the reason why, It took me a while and the help of colleagues, but it's libcryptsetup12-udeb that has: Depends: libargon2-1-udeb (>= 0~20190702) While writing this up and discussing with others, I realized that the error is coming from one of glibc's binaries. It has been stated that the issue started with with a change there, but is that change done on purpose, or a bug? I.e. is one of glibc's binaries missing a dependency? It was intentional, see the article https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread . Unfortunately that change broke initramfs-tools' fix for https://bugs.debian.org/950254 which we (src:cryptsetup maintainers) relied on for cryptsetup-initramfs. Until last week src:argon2 had never been rebuilt with the newer glibc, so it's just unfortunate that we missed that at the time. I'm very happy that we found this well before the release, even thought it's late in the freeze. I wonder if other packages are affected. Another fix would be to change initramfs-tools' inclusion logic for LIBGCC_S_SO. (I don't know if autodetection is still doable, otherwise it could still copy the library unconditionally at the expense of a larger initramfs image.) Can you elaborate and/or can you discuss with the initramfs-tools maintainers? I lack the background of how this all works and interconnects, so you'll need to explain everything or come with a proposal that the stakeholders (you and other involved maintainers) agree with. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs
Hi, [@aurel32, glibc question at the bottom] On 16-03-2023 11:57, Bastian Germann wrote: Am 16.03.23 um 09:13 schrieb Paul Gevers: I'm not 100% sure I parse that sentence as you intended, so let me ask explicitly: if we binNMU (now or in the future) src:argon2 version 0~20171227-0.3 in bookworm, would it also loose its linking to libpthread? That would be a time bomb (not only in the archive, but also for downstreams and other users that do rebuilds). I *think* you're saying that despite libc's version, that is *not* the case. Time bomb confirmed. Thanks. That changes things. For the record, with my current understanding I prefer the scenario of keeping the versions of argon2 and cryptsetup in bookworm as they are. Feel free to convince the Release Team of the opposite in an unblock request. cryptsetup will need to migrate to mitigate the time bomb. Ack. As I already mentioned on this or some related bug, I would find it nice for #1014110 to be fixed in bookworm (threaded argon2 executable) but I do not insist on it. cryptsetup can only migrate when argon2 migrates, which leaves me two options: letting argon2 in as it is now in unstable or going for cryptsetup via t-p-u. Both sub-optimal, because argon2 has changes that weren't even meeting the freeze policy rules at the time of the upload. While writing this up and discussing with others, I realized that the error is coming from one of glibc's binaries. It has been stated that the issue started with with a change there, but is that change done on purpose, or a bug? I.e. is one of glibc's binaries missing a dependency? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1032235: Bug#1014110: libargon2 0~20190702-0.1 no longer links against libpthread which breaks cryptsetup-initramfs
Control: tags -1 d-i Hi Bastian, Guilhem, On 16-03-2023 13:44, Paul Gevers wrote: cryptsetup will need to migrate to mitigate the time bomb. Ack. As I already mentioned on this or some related bug, I would find it nice for #1014110 to be fixed in bookworm (threaded argon2 executable) but I do not insist on it. cryptsetup can only migrate when argon2 migrates, which leaves me two options: letting argon2 in as it is now in unstable or going for cryptsetup via t-p-u. Both sub-optimal, because argon2 has changes that weren't even meeting the freeze policy rules at the time of the upload. So, after thinking about it a couple of days, what I want is at least cryptsetup in bookworm. Guilhem, can you please upload the version in unstable to testing-proposed-updates with an appropriate version? Bastian, if you really want that threaded bug fixed, please prepare a targeted fix based on the version currently in bookworm and revert all other changes. We can then review the targeted fix. But I'll not unblock the version of argon2 as it's currently is in unstable. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1033512: zc.buildout: autopkgtest fails: cannot open /usr/share/python3-zope.testing/test_helper
Source: zc.buildout Version: 2.13.2-4 Severity: serious Tags: bookworm-ignore User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), Your package has an autopkgtest, great. However, it fails. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/amd64/z/zc.buildout/32140722/log.gz autopkgtest [06:23:21]: test all: [--- /tmp/autopkgtest-lxc.4d5588j5/downtmp/build.MKN/src/debian/tests/all: 2: .: cannot open /usr/share/python3-zope.testing/test_helper: No such file autopkgtest [06:23:22]: test all: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#1033514: xchain: autopkgtest fails: xvfb-run: command not found
Source: xchain Version: 1.0.1-10 Severity: serious Tags: bookworm-ignore User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), Your package has an autopkgtest, great. However, it fails. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/amd64/x/xchain/32146659/log.gz autopkgtest [11:18:09]: test command1: [--- bash: line 1: xvfb-run: command not found autopkgtest [11:18:09]: test command1: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#1036249: closure-compiler: #1036159
Hi Markus, On 25-05-2023 23:47, Markus Koschany wrote: Since I could not find a targeted fix I decided to remove the dependency on rhino 1.7.14 and embedded rhino 1.7.7.2 instead, the last version that worked well for closure-compiler. I have rebuilt all reverse-dependencies and this would resolve the problem. As you tested all reverse-dependencies, let's do this. Again, awfully late, but I don't see a better way out. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1050066: adequate: autopkgtest fails on !amd64
Source: adequate Version: 0.15.7 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), Your package has an autopkgtest, great. However, it fails on all architectures but amd64. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/arm64/a/adequate/36619533/log.gz 65s check adequate-testpkg-symbol-size-mismatch ... FAIL 65s -adequate-testpkg-symbol-size-mismatch: symbol-size-mismatch /usr/bin/adequate-test-symsize => this_symbol_size_varies OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1051413: src:gpsim-doc: fails to migrate to testing for too long: FTBFS
Source: gpsim-doc Version: 0.22.0-2.2 Severity: serious Control: close -1 0.22.0-3 X-Debbugs-CC: b...@debian.org Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:gpsim-doc has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build from source. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=gpsim-doc OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058627: src:zope.proxy: fails to migrate to testing for too long: autopkgtest regression
Source: zope.proxy Version: 4.5.0-1 Severity: serious Control: close -1 5.1-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:zope.proxy has been trying to migrate for 36 days [2]. Hence, I am filing this bug. The version in unstable triggers autopkgtest failures in zope.security (albeit that seems fixed with the version of zope.security in unstable). However, it also fails its own autopkgtest. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=zope.proxy OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061175: src:pyocd: fails to migrate to testing for too long: triggers autopkgtest issues in valinor
Source: pyocd Version: 0.13.1+dfsg-3 Severity: serious Control: close -1 0.36.0-1 X-Debbugs-CC: Alexandre Detiste Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pyocd has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable causes issues in the autopkgtest of valinor which suggest issues with pyocd: The 'pylink-square<2.0,>=1.0' distribution was not found and is required by pyocd If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pyocd OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061456: src:pmacct: fails to migrate to testing for too long: Build-Depends not available on s390x
Source: pmacct Version: 1.7.7-1 Severity: serious Control: close -1 1.7.8-1 X-Debbugs-CC: Boyuan Yang Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:pmacct has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable has a new Build-Depends that's not available on s390x. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=pmacct OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#585323: [patch] fix exceptions in pythoncard 0.8.2
Severity: normal
tag 585323 +patch
kthxbye
Patch attached. Needs testing.
The issue looks like it's enough reachable code to become an issue for
pythoncard.
--
All programmers are playwrights, and all computers are lousy actors.
#define sizeof(x) rand()
:wq
Description: Migrate old string exceptions to real Exceptions
Author: Paul Tagliamonte
Last-Update: 2012-02-1
With python 2.7, we can see the following behavior:
>>> raise "foo"
Traceback (most recent call last):
File "", line 1, in
TypeError: exceptions must be old-style classes or derived from BaseException, not str
>>> raise Exception("foo")
raceback (most recent call last):
File "", line 1, in
Exception: foo
>>> raise Exception, "Foo"
Traceback (most recent call last):
File "", line 1, in
Exception: Foo
>>>
As a result, patching the source to remove cases of throwing a str
(which was valid in old versions of Python) is needed.
--- a/components/gauge.py 2012-02-01 11:23:08.930201770 -0500
+++ b/components/gauge.py 2012-02-01 11:23:54.874199316 -0500
@@ -51,13 +51,13 @@ class Gauge(widget.Widget, wx.Gauge):
elif aString == 'vertical' :
return wx.GA_VERTICAL
else :
-raise 'invalid Gauge.layout value: ', aString
+raise Exception('invalid Gauge.layout value: %s' % aString)
def _getLayout( self ) :
return self._layout
def _setLayout( self, aString ) :
-raise AttributeError, "layout attribute is read-only"
+raise AttributeError( "layout attribute is read-only" )
layout = property(_getLayout, _setLayout)
max = property(wx.Gauge.GetRange, wx.Gauge.SetRange)
--- a/components/multicolumnlist.py 2012-02-01 11:23:08.930201770 -0500
+++ b/components/multicolumnlist.py 2012-02-01 11:26:00.386192615 -0500
@@ -292,7 +292,7 @@ class MultiColumnList(widget.Widget, wx.
if isinstance(aList, ListType) or isinstance(aList, TupleType) or isinstance(aList, StringTypes):
pass
else:
-raise 'invalid MultiColumnList.SetHeading value: ', aList
+raise Exception( 'invalid MultiColumnList.SetHeading value: %s' % aList )
self.ClearAll()
self.itemDataMap = {}
@@ -343,9 +343,11 @@ class MultiColumnList(widget.Widget, wx.
self.InsertColumn(i, aList[i][0], width=wx.LIST_AUTOSIZE)
self._autoresize = 1
else:
-raise 'invalid MultiColumnList.SetHeading value: ', aList
+raise Exception( 'invalid MultiColumnList.SetHeading value: %s' %
+aList )
else:
-raise 'invalid MultiColumnList.SetHeading value: ', aList
+raise Exception( 'invalid MultiColumnList.SetHeading value: %s' %
+aList )
if numcols == 1:
self.SetColumnWidth(0, self.GetBestVirtualSize()[0])
--- a/components/radiogroup.py 2012-02-01 11:23:08.930201770 -0500
+++ b/components/radiogroup.py 2012-02-01 11:26:24.234191342 -0500
@@ -68,7 +68,7 @@ class RadioGroup(widget.Widget, wx.Radio
elif aString == 'horizontal':
return wx.RA_SPECIFY_ROWS
else:
-raise 'invalid RadioGroup.layout value: ', aString
+raise Exception( 'invalid RadioGroup.layout value: %s' % aString )
def _getItems(self):
return self._labels
--- a/components/slider.py 2012-02-01 11:23:08.930201770 -0500
+++ b/components/slider.py 2012-02-01 11:26:57.802189549 -0500
@@ -67,7 +67,7 @@ class Slider(widget.Widget, wx.Slider):
elif aString == 'vertical' :
return wx.SL_VERTICAL
else :
-raise 'invalid Slider.layout value: ', aString
+raise Exception('invalid Slider.layout value: %s' % aString )
def __getLabels(self, aBoolean):
if aBoolean:
--- a/components/staticline.py 2012-02-01 11:23:08.930201770 -0500
+++ b/components/staticline.py 2012-02-01 11:27:46.726186937 -0500
@@ -49,13 +49,13 @@ class StaticLine(widget.Widget, wx.Stati
elif aString == 'vertical' :
return wx.LI_VERTICAL
else :
-raise 'invalid StaticLine.layout value: ', aString
+raise Exception( 'invalid StaticLine.layout value: %s' % aString )
#def _setHelpText( self, aString ) :
#pass
def _setLayout( self, aString ) :
-raise AttributeError, "layout attribute is read-only"
+raise AttributeError( "layout attribute is read-only" )
def _getLayout( self ) :
return self._layout
--- a/components/statictext.py 2012-02-01 11:23:08.930201770 -0500
+++ b/components/s
Bug#664715: kerneloops: default submission site dead, should not be shipped in wheezy
Package: kerneloops-daemon Severity: serious Tags: wheezy sid X-Debbugs-CC: debian-ker...@lists.debian.org The default submission site for kerneloops-daemon is dead and does not appear to be coming back any time soon, despite recentish interest: https://lkml.org/lkml/2011/6/1/436 https://lkml.org/lkml/2012/2/14/360 Either the package should be removed or the default submission site should be replaced with one run by the Debian kernel team so that the package does something useful by default. Fedora have removed the package since abrt provides similar services (but Fedora-specific): http://pkgs.fedoraproject.org/gitweb/?p=kerneloops.git;a=blob;f=dead.package -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#667418: patch
tags 667418 + patch
thanks
Patch attached. Just missing a header.
Description: Fix FTBFS with gcc-4.7
Small header include change. This is borderlinde cosmetic, but still needed
to prevent the FTBFS.
Author: Paul Tagliamonte
Origin: vendor
Bug-Debian: http://bugs.debian.org/667418
Last-Update: 2012-04-13
--- wvstreams-4.6.1.orig/utils/wvuid.cc
+++ wvstreams-4.6.1/utils/wvuid.cc
@@ -33,6 +33,7 @@ wvuid_t wvgetuid()
#else // not WIN32
+#include
WvString wv_username_from_uid(wvuid_t uid)
{
signature.asc
Description: Digital signature
Bug#667313: patch attached
tags 667313 + patch thanks Howdy, Maintainer, Please find a patch attached to solve this issue. Thanks so much, -- Paul --- a/src/ConnectDialog.cpp 2012-04-17 23:00:27.387792765 -0400 +++ b/src/ConnectDialog.cpp 2012-04-17 23:00:33.751792427 -0400 @@ -21,6 +21,7 @@ using namespace openmsx; #include #include #include +#include #endif signature.asc Description: Digital signature
Bug#667313: patch attached
Just saw the mail from Manuel Bilderbeek, his suggestion is much better then my patch :) Thanks, -- Paul signature.asc Description: Digital signature
Bug#689896: lastfmsubmitd is maintained by Debian QA group
Hi Zigo, As lastfmsubmitd is maintained by the Debian QA group, I will just go ahead and upload a new version of lastfmsubmitd with your patch applied. I will request an unblock after the upload. Paul signature.asc Description: OpenPGP digital signature
Bug#652814: lastfmsubmitd: Should we change permissions of /var/log/lastfmsubmitd?
Package: lastfmsubmitd Version: 1.0.6-3 Followup-For: Bug #652814 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The last reporter added the "su" part to logrotate. I am not comfortable with that. I don't understand why /var/log/lastfmsubmitd should be writable by the whole "spool" group. I think that was a mistake by the original maintainer. As I don't know lastfmsubmitd, I like to give others the possibility to add comments. Paul - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lastfmsubmitd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.46 ii python 2.7.3~rc2-1 ii python-support 1.0.15 lastfmsubmitd recommends no packages. Versions of packages lastfmsubmitd suggests: pn ears -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlB+oBUACgkQHNUte6r+CGo0wQCeM5Vtyer1L5K6lNSnlcFaMQqV 4PAAn3eGtN3hD2xJtAB4rwbH0+bzSlhc =EvOG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121017120957.8328.35254.report...@wollumbin.marsaxlokk.homelinux.org
Bug#690765: lastfmsubmitd: please delete log files on purge
Package: lastfmsubmitd Version: 1.0.6-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Policy 10.8 says: Log files should be removed when the package is purged (but not when it is only removed). This should be done by the postrm script when it is called with the argument purge (see Details of removal and/or configuration purging, Section 6.8). Please do that. - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlB+ogUACgkQHNUte6r+CGooLwCdGgstqPf2NlGd7nqFq5LvE862 yk0An0J3B6ksQjaCG3ojbiAOuAv4x47I =c90s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121017121817.8265.34301.report...@wollumbin.marsaxlokk.homelinux.org
Bug#687597: openslp-dfsg: touch bug CVE-2012-4428
Package: openslp-dfsg Followup-For: Bug #687597 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As far as I can tell, no solution known yet, on 17 October 2012, 15:28 +0200. While going through Debian QA group owned RC bugs, I touched on this bug. http://security-tracker.debian.org/tracker/CVE-2012-4428 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlB+s40ACgkQHNUte6r+CGp99gCfb8V0OkWyTOTq68wZjuK50O/b 9tMAn2wLN1mGAPXS2YM36VgtU2hd0wVV =selz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121017133301.9608.69018.report...@wollumbin.marsaxlokk.homelinux.org
Bug#692342: update information on several apt-move bugs
retitle 639770 apt-move: fails to open fifo-file and hangs
tags 639770 + unreproducible
retitle 398297 apt-move: wrong version selected if containing tilde '~'
merge 398297 539524
retitle 692342 apt-move uses obsolete implicit split functionality
tags 692342 + pending, patch
thanks
Seems this bug (692342) depends on the version of perl. According to the
proposed patch in bug 398297 [1], the implicit use of split has been
removed in version 5.12.
I am preparing an upload for this bug with the attached patch.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398297#20
Description: The use of implicit split call has been removed from perl
in version 5.12 as it had been deprecated for 15 years
Author: Paul Gevers
Bug-Debian: http://bugs.debian.org/692342
Forwarded: no
--- a/move3
+++ b/move3
@@ -42,7 +42,7 @@
}
while (<>) {
- split;
+ @_=split;
if ($_[0] eq "D") {
if (fileno(MKDIR) == undef) {
signature.asc
Description: OpenPGP digital signature
Bug#691393: work in progress
tag -1 +pending thanks Hi, We are working on it. See [1] and bug 695130 [2]. Paul [1] http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git [2] http://bugs.debian.org/bug=695130 signature.asc Description: OpenPGP digital signature
pre-approval of rename openmotif -> motif for main archive
Hi ftp-master(s), Maybe you have seen on debian-devel [1] that (open)motif is now released under a DSFG-free license and that we are working on getting [2] it in shape for debian/main. Actually, my intention is that it fully replaces lesstif2 (which is starting to look slightly bit-rotten) in jessie. My questions now are: - Do you agree with the renaming of the source package from openmotif to motif (upstream renamed it's project as well, we think we should follow as the widget set is well known under the name motif). Binary packages are not renamed. - I could not find the proper documentation of what to take care of, in case of a source rename, other than properly migrating the bugs in the BTS. Are there more issues involved? - If you judge the licensing to be in order, as I have, is uploading the new source (to experimental at this stage of freeze) the right thing to do to get it into main (after changing the d/control entry of course)? Kind regards Paul [1] https://lists.debian.org/debian-devel/2012/12/msg00369.html [2] http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git signature.asc Description: OpenPGP digital signature
Please review package description of (open)motif
Hi all,
[Please keep cc in the loop.]
Currently, Graham and I are working on getting (open)motif [1] in shape
for inclusion in main. While I was going through the package I was
unhappy with the current description of the binary packages. I have
already extended the description of motif-clients, but I would like a
review of all descriptions.
I hope you can help.
Paul
[1] http://packages.qa.debian.org/o/openmotif.html
Source: motif
Section: devel
Priority: optional
Build-Depends: byacc,
debhelper (>= 9),
dh-autoreconf,
dh-exec,
flex,
libsm-dev,
libx11-dev,
libxaw7-dev,
libxext-dev,
libxft-dev,
libxmu-dev,
libxt-dev,
xbitmaps
Maintainer: Graham Inggs
Uploaders: Paul Gevers
Standards-Version: 3.9.4
Homepage: http://motif.ics.com/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git
Vcs-Git: git://anonscm.debian.org/collab-maint/motif.git
Package: libmotif4
Architecture: any
Section: libs
Multi-Arch: same
Depends: ${misc:Depends}, ${shlibs:Depends}
Pre-Depends: ${misc:Pre-Depends}, x11-common (>= 1:7.0.0)
Conflicts: libmotif3
Replaces: libmotif3
Provides: libmotif3
Description: Motif - shared libraries
This package includes all files you need to run Motif
applications which are linked against Motif, which
are the shared libraries for the most part.
Package: libmotif4-dbg
Architecture: any
Depends: libmotif4 (= ${binary:Version}), ${misc:Depends}
Section: debug
Priority: extra
Conflicts: lesstif2-dbg
Description: Motif - shared libraries debugging symbols
This package includes all files you need to run Motif
applications which are linked against Motif, which
are the shared libraries for the most part.
.
This package contains the debugging symbols.
Package: libmotif-dev
Architecture: any
Section: libdevel
Depends: libmotif4 (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
Conflicts: lesstif-bin, lesstif-dev, lesstif-doc, lesstif2-dev
Description: Motif - development files
Everything you need to build Motif applications with
Motif. This includes header files, static libraries,
the manual pages for the Motif API and uil (user interface
language compiler)
Package: motif-clients
Architecture: any
Section: x11
Depends: menu, ${misc:Depends}, ${shlibs:Depends}
Pre-Depends: x11-common (>= 1:7.0.0)
Conflicts: lesstif-bin
Description: Motif window manager and virtual key bindings configure client
Motif is the industry standard toolkit for *NIX systems. This package
contains the Motif window manager, which has clear but classical appearance,
and xmbind, which is used to configure virtual key bindings for motif.
signature.asc
Description: OpenPGP digital signature
Re: Please review package description of (open)motif
Hi Justin and the rest, On 19-01-13 15:00, Justin B Rye wrote: > Paul Gevers wrote: >> [Please keep cc in the loop.] >> Package: motif-clients > > What does this package name mean, anyway? Is the idea that it's a set > of executables that have a client relationship towards Motif, whatever > that means, or are they just Motif-based tools that happen (obviously) > to be graphical, and therefore (obviously) count as X11 clients? > > Either way, it seems an odd way of looking at things. Why would a > user search for and then install this package? If the point of the > exercise is to get a Motif-flavoured X environment, wouldn't it make > more sense to call the package simply "mwm - Motif Window Manager"? Oh, that seems very sensible to me as well. As the original creator of the openmotif source package is not active in Debian anymore, we can not ask. So I propose to rename (including creation of a proper transitional package). > It's a more general MWM configurator. And > since we've already mentioned MWM we could just say: > > Description: Motif window manager and setup tool > > But why do we even need to care about xmbind? Most packages that > contain window managers also contain one or two other trivial helper > binaries; but they put the focus in the packagename and synopsis on > the thing that users might actually want to install. So again I'm > back to wondering why this isn't "Description: Motif Window Manager" > (but again that's not in my patch). Agreeing with your argument, I would go for Description: Motif Window Manager >> Motif is the industry standard toolkit for *NIX systems. This package > > Surely the standard toolkit for *NIX systems is something more like > coreutils? Or if we're talking "graphical" it would be X... should we > perhaps call it "the standard GUI component toolkit for *NIX"? > > We could also insert a linebreak to get a paragraph that could fit > neatly at the start of each package description in the set as a > boilerplate intro. Good. >> contains the Motif window manager, which has clear but classical appearance, > > "(It) has clear appearance" sounds like it's missing an article. > > (Classical? Now I'm imagining a Roman mosaic tiled window manager.) Sorry, I am not a native speaker. I try to say that it looks a dated (already a decade). Would that be a better word than? >> and xmbind, which is used to configure virtual key bindings for motif. > > Since we're not pressed for space here I'll suggest expanding this to > "virtual key/mouse-bindings". Sure. Maybe we should even focus less on xmbind. Make the first part about MWM end with a full stop and mention it more as an auxiliary tool: This package contains the Motif window manager, which has a clear but classical appearance. It is accompanied by xmbind, which is used to configure virtual key/mouse-bindings for Motif. > (So "OpenMotif" is the old non-free version and now it's gone LGPL > it's called plain "Motif"? Okay, confusing.) Yes. Indeed. Motif has been used in the past for the group of software implementations of motif: the paid variant, the free (but not dsfg-free) version openmotif and lesstif, which was the only really free implementation of motif. >> Source: motif >> Section: devel > > (Wait, why is the source package's Section set to something not used > by any of the binary packages?) Shoot. I hadn't seen that. Good point. Let me figure out where it should go. I think it really should go into x11. > This has a bit more content to it, but the sentence-fragment about > building Motif apps with Motif has got to go! Oh, and it's not true > that this package provides all of build-essential. How about: > > Description: Motif - development files >Motif is the industry standard GUI component toolkit for *NIX. >. >This package provides everything needed for developing Motif >applications, including header files, static libraries, the API >manual pages, and uil, the user interface language compiler. Nice. Paul Source: motif Section: x11 Priority: optional Build-Depends: byacc, debhelper (>= 9), dh-autoreconf, dh-exec, flex, libsm-dev, libx11-dev, libxaw7-dev, libxext-dev, libxft-dev, libxmu-dev, libxt-dev, xbitmaps Maintainer: Graham Inggs Uploaders: Paul Gevers Standards-Version: 3.9.4 Homepage: http://motif.ics.com/ Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git Vcs-Git: git://anonscm.
Bug#524149: Hey! Lets fix this for Wheezy
BLT needs fixing RIGHT NO. No more delay. If the maintainer of this package is not a blt user, I can understand that this does not seem like a big thing. But, speaking bluntly, blt is an old piece of software that is barely (if at all maintained) by its original author. Nevertheless, we are heavily dependent upon it in our research. All the other distributions except Debian have patched this thing. Lets step forward. please. In the Swarm Simulation System, we use blt to draw graphs as simulations run. This was awesome in tcktk <= 8.4. Blt DOES NOT WORK AT ALL with tcltk8.5. I first ran into this problem when I was an Ubuntu user. Here's the bug report about it there. https://bugs.launchpad.net/ubuntu/+source/blt/+bug/359857 It seems obvious to me this should have been done in Debian in 2010. If Ubuntu did it, why not Debian. For details on the fix, please skip down to: https://bugs.launchpad.net/ubuntu/+source/blt/+bug/359857/comments/9 I did not write the fix. The Fedora blt maintainers wrote two patches for blt in 2010. Since then, I have been applying those patches to blt packaging on my Ubuntu and Debian. They work fine. So, to the package maintainer, please consider installing these patches to blt http://pj.freefaculty.org/Ubuntu/10.04/amd64/blt/blt2.4z-tk8.5.6-patch http://pj.freefaculty.org/Ubuntu/10.04/amd64/blt/blt2.4z-zoomstack.patch I just re-compiled blt on Debian Wheezy beta 4. It doesn't run as compiled, but it does run as patched. Please let me know what is holding us back on this. pj -- Paul E. Johnson email: paulj...@ku.edu http://pj.freefaculty.org Assoc. Director Professor, Political ScienceCtr for Research Methods& Data Analysis 1541 Lilac Lane, Rm 504 1425 Jayhawk Blvd. University of KansasWatson Library, Rm. 470 Lawrence, Kansas 66045-3129 Lawrence, Kansas 66045-7555 Ph: (785) 864-3523 Ph: (785) 864-3353 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50fcc517.6070...@ku.edu
Re: First motif commits
On 21-01-13 20:54, Graham Inggs wrote: > If you want. Do you want to start a new thread there? Just continue. > I still have the source code for every Debian package that depends on > libmotif-dev and lesstif2-dev on my PC, so I ran 'grep -i > XmPrintPopupPDM -l -r *' for each of the six missing symbols you listed > previously and did not find a single match. > Good news is we can't break anything in Debian if we hack PrintS.c, bad > news is we don't have any applications with which to test. Fully ack. > Ok, let's try 3 and see where that takes us. I'm not keen on 2 because > there are still proprietary applications being used that need libXm.so.3 > and libXm.so.4. Yes, but it is still easy for system administrators to add the symlinks themselves, if they feel comfortable with it. > I've just come across this: > http://bugs.motifzone.net/long_list.cgi?buglist=1545 > https://bugzilla.redhat.com/show_bug.cgi?id=229409 > > It seems Red Hat deprecated Xprint in 2007, it may be that the > "official" Motif libraries are built without Xprint support. Yes, I understand. Debian also removed xprint from the repository. But the glue layer libxp is still there to PREVENT problems. This means that you don't have printing support anyway, but that things don't just break. > Maybe we have to drop the XmPrint functions in order to be binary > compatible? Nope, ADDITIONAL symbols is never a problem. Please read the policy chapter 8 [1] for some background if you didn't already, especially 8.6.2. [1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > What do you think of releasing another openmotif 2.3.3 package including > the three patches from Ubuntu? > http://changelogs.ubuntu.com/changelogs/pool/multiverse/o/openmotif/openmotif_2.3.3-6ubuntu1/changelog No need. I think we will be uploading shortly, and then these changes will be gone anyway. Unless you fear that it might still take a long time. I don't think these patches warrant a release-freeze [2]. As it is, we are still waiting for an unblock of 2.3.3-7 anyway ... uhm, oops, I still have to file that one I see. [2] http://release.debian.org/wheezy/freeze_policy.html > If you are in agreement, is there anything I can do to assist? So unless you can convince me otherwise, I don't think we should do this. > In particular, I'd like the libmotif3 and display manager entries. I do > not know why Ubuntu needs the bin-utils-gold patch, and Debian doesn't > (Debian doesn't need it in 2.3.4 because this patch is against a demo). Unfortunately, "liking" is not on the list of freeze exceptions. I think Debian would also need the bin-utils-gold patch if it were using the gold linker. I believe Ubuntu actively tests for that. Actually, I hope Logan Rosen checked my patch in 2.3.3-6 as I think it is flawed. That is why I uploaded 2.3.3-7. Paul signature.asc Description: OpenPGP digital signature
Bug#698661: unblock: openmotif/2.3.3-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please unblock package openmotif
Openmotif 2.3.3-7 is an update to 2.3.3-5 to allow two release goals:
- - code hardening
- - multi-arch
and a fix for policy violation 6.8:
- - openmotif leaves files behind after purge.
debdiff is attached.
unblock openmotif/2.3.3-7
- -- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJQ/avbAAoJEJxcmesFvXUKXeIH/0X3UNM2B5thrwhWB96itng9
f6/ZHtzGc6lfaCO2DbsEuWU7fLHipumecc9R/oeEFwAoMsVtz96tbn0eVGzJiIEw
5/gOmSDmXopO/aRgop2ycbWyrMXRMpA7VvHRaUPc1o5/PA7dD9vRYiIqs8AWq+Wu
Nvx/ru9sS/tEgh3XQ0rTij3MFlCr71Zy7rJUKasP7hnMT8M4uoSv1hwytKd/bTMs
O539WEG2YCzz0V7roM9tpZkMUHXR4WqYDUcYSvckU/+lFYzWfTSBzzxjcnxO6b2t
FdF+NVXvn4w4DWHmPN2frA8qkkyieTHAarurMg0V/3JoFP3xBgTlCu8z/vT7Mtk=
=CIpm
-END PGP SIGNATURE-
diff -u openmotif-2.3.3/debian/changelog openmotif-2.3.3/debian/changelog
--- openmotif-2.3.3/debian/changelog
+++ openmotif-2.3.3/debian/changelog
@@ -1,3 +1,31 @@
+openmotif (2.3.3-7) unstable; urgency=low
+
+ * QA upload.
+ * Improve 0005-sprintf-error-message-hardening-format-security.patch to use
+strcpy i.s.o. sprintf and properly format string.
+
+ -- Paul Gevers Sat, 05 Jan 2013 21:36:38 +0100
+
+openmotif (2.3.3-6) unstable; urgency=low
+
+ * QA upload.
+- Set maintainer to QA group
+ * Allow multiarch (Closes: #673690)
+- Multi-Arch: same for libmotif4
+- Add Pre-Depends: multiarch-support
+- d/*.files use wild-card
+- d/rules export DEB_HOST_MULTIARCH and use it for configure with --libdir
+- Add patch to NOT move /usr/lib/X11 files (thanks Sergio Gelato)
+ * Enable hardening
+- Build-Depend on dpkg-dev (>=1.6.1)
+- d/rules: move declaration of CFLAGS earlier
+- Add patch to prevent "format not a string literal and no format arguments"
+- Add patch to prevent a case of "format '%d' expects argument of type
+ 'int', but argument 5 has type 'size_t'"
+ * Remove update-menu created configuration files on purge (Closes: #656169)
+
+ -- Paul Gevers Tue, 25 Dec 2012 09:04:47 +0100
+
openmotif (2.3.3-5) unstable; urgency=low
* Fix hopefully the build problems on mips*
reverted:
--- openmotif-2.3.3/debian/motif-clients.postrm.off
+++ openmotif-2.3.3.orig/debian/motif-clients.postrm.off
@@ -1,3 +0,0 @@
-#!/bin/sh
-test -x /usr/bin/update-menus && /usr/bin/update-menus
-#DEBHELPER#
diff -u openmotif-2.3.3/debian/libmotif-dev.files openmotif-2.3.3/debian/libmotif-dev.files
--- openmotif-2.3.3/debian/libmotif-dev.files
+++ openmotif-2.3.3/debian/libmotif-dev.files
@@ -1,7 +1,7 @@
-/usr/lib/libMrm.a
-/usr/lib/libUil.a
-/usr/lib/libXm.a
-/usr/lib/lib*.so
+/usr/lib/*/libMrm.a
+/usr/lib/*/libUil.a
+/usr/lib/*/libXm.a
+/usr/lib/*/lib*.so
/usr/include/Xm
/usr/include/Mrm
/usr/include/uil
diff -u openmotif-2.3.3/debian/rules openmotif-2.3.3/debian/rules
--- openmotif-2.3.3/debian/rules
+++ openmotif-2.3.3/debian/rules
@@ -10,10 +10,16 @@
include /usr/share/quilt/quilt.make
+# Enable hardening options
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+CFLAGS += -fno-strict-aliasing -D_FILE_OFFSET_BITS=64
+
# From /usr/share/doc/autotools-dev/README.Debian.gz
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
export DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
+export DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
confflags += $(DEB_HOST_GNU_TYPE)
@@ -22,18 +28,18 @@
endif
ifeq '$(DEB_HOST_ARCH_CPU)' 'mips'
-CFLAGS_NEW =-mplt
+CFLAGS +=-mplt
endif
ifeq '$(DEB_HOST_ARCH_CPU)' 'mipsel'
-CFLAGS_NEW =-mplt
+CFLAGS +=-mplt
endif
build: build-stamp
build-stamp: $(QUILT_STAMPFN)
dh_testdir
- CFLAGS="-g -O2 -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 $(CFLAGS_NEW)" ./configure --prefix=/usr --mandir=/usr/share/man --build=$(DEB_HOST_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
+ ./configure --prefix=/usr --mandir=/usr/share/man --build=$(DEB_HOST_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
make;
touch build-stamp
diff -u openmotif-2.3.3/debian/libmotif4.files openmotif-2.3.3/debian/libmotif4.files
--- openmotif-2.3.3/debian/libmotif4.files
+++ openmotif-2.3.3/debian/libmotif4.files
@@ -1,3 +1,3 @@
-/usr/lib/lib*.so.*
+
Bug#524149: Have built propoed fixes, need to get a mentor, signed keys, etc, before fix can be finalized
OK, I did the work to turn this into a quilted package. In case anybody wants to try it out, I uploaded the debs, and the whole build folder actually, http://pj.freefaculty.org/Debian/wheezy/amd64/blt-2.4z-quilted/ In there, find a README, which explains the origin of the patches. pj -- Paul E. Johnson email: paulj...@ku.edu http://pj.freefaculty.org Assoc. Director Professor, Political ScienceCtr for Research Methods& Data Analysis 1541 Lilac Lane, Rm 504 1425 Jayhawk Blvd. University of KansasWatson Library, Rm. 470 Lawrence, Kansas 66045-3129 Lawrence, Kansas 66045-7555 Ph: (785) 864-3523 Ph: (785) 864-3353 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50fdfe0e.2060...@ku.edu
Re: Bug#698661: unblock: openmotif/2.3.3-7
On 22-01-13 15:21, Niels Thykier wrote: >> Openmotif 2.3.3-7 is an update to 2.3.3-5 to allow two release goals: >> - code hardening > > This does not appear to close a bug and therefore, I presume, is there > for not on the "target list" for Wheezy? If it is not on this list, > then I would prefer to defer this for Jessie. If it is on that list, I > would be willing to accept it[1]. Hmm. I see you just updated the release goals [2]. I was follow the requirements there to hardening [3]. So, until today this was a release goal: "This goal is to update as many packages as possible to use security hardening build flags via dpkg-buildflags." Of course, if it is now unacceptable, I will remove it ASAP. Regarding your [1], where can I actually find this list? Not that I think openmotif is on it, but anyway. >> - multi-arch > > "Multi-arch: same" conversions have not been acceptable since the start > of the freeze. So unfortunately, I cannot accept this change either. I must have missed this, I really thought it was still part of the solution. Anyways. >> and a fix for policy violation 6.8: >> - openmotif leaves files behind after purge. > > I would very much appreciate this change. Ok. Paul > [1] Mind you, we are stricting our Freeze Policy atm. Since your > request preceeds that official change to the policy, I am willing to > accept the hardening change if it is on the target list. [2] http://wiki.debian.org/ReleaseGoals/ [3] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags signature.asc Description: OpenPGP digital signature
Re: Bug#698661: unblock: openmotif/2.3.3-7
tags 698661 -moreinfo retitle 698661 unblock: openmotif/2.3.3-8 reopen 673690 thanks On 22-01-13 15:21, Niels Thykier wrote: > Can you please re-upload openmotif with the M-A (and possibly the > hardening) changes reverted. Done. Debdiff attached, very simple now. Paul diff -u openmotif-2.3.3/debian/changelog openmotif-2.3.3/debian/changelog --- openmotif-2.3.3/debian/changelog +++ openmotif-2.3.3/debian/changelog @@ -1,3 +1,39 @@ +openmotif (2.3.3-8) unstable; urgency=low + + * QA upload. + * Reverting multiarch and hardening changes since 2.3.3-5 on request of +release-team (see bug #698661) to allow for transition to Wheezy. + + -- Paul Gevers Tue, 22 Jan 2013 20:52:01 +0100 + +openmotif (2.3.3-7) unstable; urgency=low + + * QA upload. + * Improve 0005-sprintf-error-message-hardening-format-security.patch to use +strcpy i.s.o. sprintf and properly format string. + + -- Paul Gevers Sat, 05 Jan 2013 21:36:38 +0100 + +openmotif (2.3.3-6) unstable; urgency=low + + * QA upload. +- Set maintainer to QA group + * Allow multiarch (Closes: #673690) +- Multi-Arch: same for libmotif4 +- Add Pre-Depends: multiarch-support +- d/*.files use wild-card +- d/rules export DEB_HOST_MULTIARCH and use it for configure with --libdir +- Add patch to NOT move /usr/lib/X11 files (thanks Sergio Gelato) + * Enable hardening +- Build-Depend on dpkg-dev (>=1.6.1) +- d/rules: move declaration of CFLAGS earlier +- Add patch to prevent "format not a string literal and no format arguments" +- Add patch to prevent a case of "format '%d' expects argument of type + 'int', but argument 5 has type 'size_t'" + * Remove update-menu created configuration files on purge (Closes: #656169) + + -- Paul Gevers Tue, 25 Dec 2012 09:04:47 +0100 + openmotif (2.3.3-5) unstable; urgency=low * Fix hopefully the build problems on mips* diff -u openmotif-2.3.3/debian/control openmotif-2.3.3/debian/control --- openmotif-2.3.3/debian/control +++ openmotif-2.3.3/debian/control @@ -3,7 +3,7 @@ Priority: extra Build-Depends: debhelper (>= 6.0.7), libxaw7-dev, byacc, flex, libsm-dev, libx11-dev, libxext-dev, libxmu-dev, libxp-dev, libxt-dev, xbitmaps, libxft-dev, autotools-dev, quilt -Maintainer: Stefan Bauer +Maintainer: Debian QA Group Standards-Version: 3.9.1.0 Homepage: http://www.motifzone.net/ XS-Autobuild: yes only in patch2: unchanged: --- openmotif-2.3.3.orig/debian/motif-clients.postrm +++ openmotif-2.3.3/debian/motif-clients.postrm @@ -0,0 +1,8 @@ +#!/bin/sh +set -e + +# Remove configuration files created by update-menus +if [ "$1" = "purge" ] ; then +rm -rf /etc/X11/mwm +fi +#DEBHELPER# signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 31-01-13 21:11, Graham Inggs wrote: > Actually, it looks like we should ditch libmotif4 and name the separate > packages libXm4, libUil4 and libMrm4. Agree. > On 31 January 2013 21:41, Graham Inggs <mailto:gra...@nerve.org.za>> wrote: > > I've had a look at incorporating > d/patches/05-multiarch-specialcase-libdir-X11.patch into > configure.ac <http://configure.ac> as a build option, and was > thinking that perhaps now is the time to move these platform > independent files, as Sergio suggested, from /usr/lib/X11/bindings > to /usr/share/X11/bindings and into a separate package > motif-common'. I think I agree. > Also, /usr/lib/X11/system.mwmrc can be relocated to > /usr/share/X11, but remain in package mwm. Have to investigate, but I assume for know you know what you are proposing. > At the same time we could split the three shared libraries; > libXm.so.*, libUil.so.* and libMrm.so.* into separate packages. > What do you think of the names libmotif4, libmotifuil4 and > libmotifmrm4? I know the name of the last one is redundant (mrm is > Motif Resource Manager), but it is consistent with the others. See above. > If we are in agreement with the above I'll start working on it. > > I'm warming to the idea of releasing motif to experimental without > printing support, without the missing XmPrint* exports, and without > bumping the soname. > As I wrote previously, I don't believe this will break anything in > Debian. Should we start getting bug reports of broken applications, > at least we'll have a test case for option 3 (Maintain ABI > compatibility, but return failures from xprint methods). Although indeed not allowed, I see your point. Maybe we can justify it by the move to main? Hmm, I guess not, but indeed I believe it doesn't work now anyway as the xprint support is removed etc. Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 01-02-13 08:31, Paul Gevers wrote: > On 31-01-13 21:11, Graham Inggs wrote: >> Actually, it looks like we should ditch libmotif4 and name the separate >> packages libXm4, libUil4 and libMrm4. > > Agree. Not perfect yet, but I did some of the work on the split (bed time now though). Pushed to the repo. >> I've had a look at incorporating >> d/patches/05-multiarch-specialcase-libdir-X11.patch into >> configure.ac <http://configure.ac> as a build option, and was >> thinking that perhaps now is the time to move these platform >> independent files, as Sergio suggested, from /usr/lib/X11/bindings >> to /usr/share/X11/bindings and into a separate package >> motif-common'. Does this also count for the bitmaps? (Not implemented by me yet). >> Also, /usr/lib/X11/system.mwmrc can be relocated to >> /usr/share/X11, but remain in package mwm. > > Have to investigate, but I assume for know you know what you are proposing. Not yet looked into, but if you think this is reasonable (it sounds like it), please show how you want to do it. Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 04-02-13 22:41, Graham Inggs wrote: > On 3 February 2013 23:34, Paul Gevers <mailto:elb...@debian.org>> wrote: > > > Not perfect yet, but I did some of the work on the split (bed time now > though). Pushed to the repo. > > > Ah, I actually did this on Thursday and Friday last week, although I > went as far as making a libmotif-common as well. But you forgot to push... Lets agree that we either tell the other that we are working on something, or just push (soon). > I did split the bitmaps off into libmotif-common, but left them located > at /usr/include/X11/bitmaps. > I thought of moving these to /usr/share/X11/bitmaps, but > /usr/include/X11/bitmaps seems to be used by other X packages as well. I have to check the location, but it sounds good. > This location is checked by mwm for a system menu if one does not exist > in the user's home directory. > Shall I push my proposed changes to git or would it be better to attach > a diff here for discussion? > (this is why I didn't push my proposed split for libmotif as well) No, lets use git for that. Reverting is not difficult if you make small git commits (please never put everything together in one big commit, but split commits in logical segments. Especially, it could be just me, but I like to put the commit with combined changelog changes always separately from everything else). Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 05-02-13 19:06, Graham Inggs wrote: > I thought I had made it clear I was going to work on splitting > libmotif4, but no harm done. Sorry, slight misunderstanding. I thought it was your proposal. As I had time and hadn't seen any progress, I decided to try some of that work. Maybe the symbols still need a slight update by the way. > Again I have study commitments until the end of this week, but when I > get the chance, I will compare the splits and push any additions I > have. I think that if we have the split of -common, it is time to upload the package to experimental, to see if the ftp-masters can let the new package into main. We can then also start to ask dependent package to try out building against motif instead of lesstif2. Paul PS, I don't think I will have any time next week. I hope the week after we can do the upload. signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 07-02-13 07:03, Graham Inggs wrote: > On 6 February 2013 22:07, Paul Gevers <mailto:elb...@debian.org>> wrote: > >> I think that if we have the split of -common, it is time to upload >> the package to experimental, to see if the ftp-masters can let the >> new package into main. We can then also start to ask dependent >> package to try out building against motif instead of lesstif2. > > > The only other thing I can think of is splitting libmotif-dev into > libxm4-dev, libmrm4-dev, libuil4-dev Don't you think this is a little overkill? Not that I have a strong objection, but do we really need so many packages? Hmm, looking at e.g. libav, I guess it is not strange. > and a new package for uil (the actual UIL compiler executable and its > man pages) and then leaving the common bits in libmotif-dev. What do > you think? So all in all, seems reasonable. Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 16-02-13 17:19, Graham Inggs wrote: > Stefano agreed with you about multiple -dev packages being overkill. I > did go ahead though, with splitting uil into its own package and marking > it multiarch: foreign, it could be used for multiarch cross-compiling. Ok, fine. > I decided to rename your fix_lintian_reported_manpage_typos.patch and > while updating the series file I noticed that > 06-cast-size_t-to-int.patch hadn't been in since January 13, so I > replaced it. Do you really care for the numbers in front? I usually find them annoying, especially in the future, when some patches might get dropped because they are fixed and others not, do you then rename again? This tends to make reading history more difficult. But if you want to, I don't care enough to make a bigger point out of this than these lines. > I don't have any further changes planned, so I await your comments. I am finishing the symbols files and have two more patches fixing a typo and fixing hyphen use in the manpages. I am checking your latest changes and if all right, I will upload today. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. 10e3e364ae46c34cbb88cba0aecab1e053bca5fa
Hi Graham,
On 16-02-13 23:30, Graham Inggs wrote:
> The following commit has been merged in the master branch:
> commit 10e3e364ae46c34cbb88cba0aecab1e053bca5fa
> Author: Graham Inggs
> Date: Sun Feb 17 00:24:02 2013 +0200
>
> Mark transitional package libmotif4 Architecture: any, Multi-Arch: same
> for upgrades
>
> diff --git a/debian/control b/debian/control
> index 449690d..f586438 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -141,9 +141,10 @@ Description: Motif Window Manager (transitional package)
> mwm. It can safely be removed.
>
> Package: libmotif4
> -Architecture: all
> +Architecture: any
> Section: oldlibs
> Priority: extra
> +Multi-Arch: same
> Depends: libmrm4, libuil4, libxm4, ${misc:Depends}, ${shlibs:Depends}
> Provides: libmotif3
> Description: Motif - shared libraries (transitional package)
As libmotif4 is a virtual (empty) package, why did you change the
architecture from all to any? I don't think this makes sense.
(Of course you should not set Multi-Arch same on Arch all. See
https://wiki.ubuntu.com/MultiarchSpec#Binary_package_control_fields)
Paul
signature.asc
Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. 4751c883f4b27e8e34c0da1e195555ff71740fa1
On 16-02-13 13:28, Graham Inggs wrote:
> The following commit has been merged in the master branch:
> commit 4751c883f4b27e8e34c0da1e19ff71740fa1
> Author: Graham Inggs
> Date: Sat Feb 16 14:27:33 2013 +0200
>
> Split non-libs from libxm4 into libmotif-common
>
> diff --git a/debian/control b/debian/control
> index 387fc9e..6d37889 100644
> --- a/debian/control
> +++ b/debian/control
> Package: libmrm4
> Architecture: any
> Section: libs
> Multi-Arch: same
> Depends: ${misc:Depends}, ${shlibs:Depends}
> Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
> -Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> Description: Motif - shared resource management library
> Motif is the industry standard GUI component toolkit for *NIX.
Why did you remove the Breaks/Replaces? libmrm4 contains files that used
to be in libmotif3/libmotif4, so I believe they are needed to prevent
co-installation.
> @@ -41,8 +56,6 @@ Section: libs
> Multi-Arch: same
> Depends: ${misc:Depends}, ${shlibs:Depends}
> Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
> -Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> Description: Motif - shared user interface library
> Motif is the industry standard GUI component toolkit for *NIX.
Idem.
> @@ -53,10 +66,8 @@ Package: libxm4
> Architecture: any
> Section: libs
> Multi-Arch: same
> -Depends: ${misc:Depends}, ${shlibs:Depends}
> +Depends: libmotif-common (= ${source:Version}), ${misc:Depends},
> ${shlibs:Depends}
> Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
> -Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> Description: Motif - shared Xm library
> Motif is the industry standard GUI component toolkit for *NIX.
Idem.
Paul
signature.asc
Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. 4751c883f4b27e8e34c0da1e195555ff71740fa1
On 17-02-13 09:20, Paul Gevers wrote: > Why did you remove the Breaks/Replaces? libmrm4 contains files that used > to be in libmotif3/libmotif4, so I believe they are needed to prevent > co-installation. Hmm, I think I understand. As you removed all common files, these packages should not contain any conflicting files anymore. I am checking this after building if this is true. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. 4751c883f4b27e8e34c0da1e195555ff71740fa1
On 17-02-13 09:39, Paul Gevers wrote: > On 17-02-13 09:20, Paul Gevers wrote: >> Why did you remove the Breaks/Replaces? libmrm4 contains files that used >> to be in libmotif3/libmotif4, so I believe they are needed to prevent >> co-installation. > > Hmm, I think I understand. As you removed all common files, these > packages should not contain any conflicting files anymore. > > I am checking this after building if this is true. > > Paul > Gee, I must be a fool this morning. You already placed them back in your last commit. Sorry for the noise. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42
On 17-02-13 18:33, Graham Inggs wrote:
> The following commit has been merged in the master branch:
> commit dbe3bee6ec58bdaa141c94c66e85205408dc7d42
> Author: Graham Inggs
> Date: Sun Feb 17 19:32:23 2013 +0200
>
> Make the Multi-Arch: same package libxm4 Provides: libmotif3/4 instead of
> libmotif-common
>
> diff --git a/debian/control b/debian/control
> index 7a732b9..2b6c16f 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -32,7 +32,6 @@ Recommends: libmrm4 (= ${binary:Version}),
> libxm4 (= ${binary:Version})
> Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Provides: libmotif3, libmotif4
> Description: Motif - common files
> Motif is the industry standard GUI component toolkit for *NIX.
> .
> @@ -74,6 +73,7 @@ Depends: libmotif-common (= ${source:Version}),
> Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
> Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> +Provides: libmotif3, libmotif4
> Description: Motif - X/Motif shared library
> Motif is the industry standard GUI component toolkit for *NIX.
Hmm, now I see that you have TWO packages that provide libmotif3 (and
libmotif4). I don't think this is correct. Only libmotif4 should provide
libmotif3, don't you agree? And libmotif4 automatically provides
libmotif4. A package could depend on libmotif4, not because of libxm4,
but because of libuil4 or libmrm4. It needs libmotif4 to pull in libuil4
or libmrm4 to work.
I was about to upload the package, but am waiting for your response now.
Paul
signature.asc
Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. 10e3e364ae46c34cbb88cba0aecab1e053bca5fa
On 17-02-13 18:26, Graham Inggs wrote: > Hi Paul > > Why don't you think this is the proper solution? See below. > Previously, there were multiple libmotif4 packages, True. > it makes sense that there should be a transitional package for each > one. I think transitional packages don't have any architecture dependent files so they always should be architecture all. Your use case is a valid one though, that is why I don't know the proper solution. (I won't mind uploading with your version, but appreciate the search for a better one.) > I'll revert to mailing the list after this mail. Sending this to the list again. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42
On 17-02-13 19:16, Graham Inggs wrote: > Ah, I didn't notice that the transitional libmotif4 provided libmotif3. > I have removed that, because it is a transitional package it can be > uninstalled after the transition, but we still need to show that our > libxm4 (and libmrm4 and libuil4 and libmotif-common together) still > provide libmotif3 because of the lib*.so.3 symlinks. > > Regarding the moving of the Provides from the Multi-Arch: foreign > libmotif-common to the Multi-Arch same libxm4, I thought of a scenario > where some could have, for example, only the x86_64 version of libmotif4 > installed, they then upgrade to our new package which now provides > libmotif4 in a Multi-Arch: foreign package. > They then install an old package depending on libmotif:i386. The > installation would proceed without pulling in the i386 libxm4. etc. My proposal is different: libmotif4: provides libmotif3 (I added in the description that it can only be removed if no packages depend on libmotif3) and is indeed multi-arch same. All other packages CAN NEVER provide libmotif3 as for each package it will always be incomplete, and thus no other package can provide full libmotif3 support on it's own. An other option is to ALSO provide a virtual libmotif3 package (very similar to libmotif4). I don't fully understand the difference between Multi-arch foreign and allowed. Maybe a possible solution lies in the understanding. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42
On 17-02-13 20:35, Paul Gevers wrote: > On 17-02-13 19:16, Graham Inggs wrote: >> Ah, I didn't notice that the transitional libmotif4 provided libmotif3. >> I have removed that, because it is a transitional package it can be >> uninstalled after the transition, but we still need to show that our >> libxm4 (and libmrm4 and libuil4 and libmotif-common together) still >> provide libmotif3 because of the lib*.so.3 symlinks. >> >> Regarding the moving of the Provides from the Multi-Arch: foreign >> libmotif-common to the Multi-Arch same libxm4, I thought of a scenario >> where some could have, for example, only the x86_64 version of libmotif4 >> installed, they then upgrade to our new package which now provides >> libmotif4 in a Multi-Arch: foreign package. >> They then install an old package depending on libmotif:i386. The >> installation would proceed without pulling in the i386 libxm4. etc. > > My proposal is different: > libmotif4: provides libmotif3 (I added in the description that it can > only be removed if no packages depend on libmotif3) and is indeed > multi-arch same. > > All other packages CAN NEVER provide libmotif3 as for each package it > will always be incomplete, and thus no other package can provide full > libmotif3 support on it's own. To be perfectly clear, I think ONLY libmotif4 could ever provide libmotif3. The alternative is a libmotif3 package. This is independent of our final choice of multi-arch for each package. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42
On 17-02-13 21:13, Graham Inggs wrote:
> but libmrm4
> and libuil4 both depend on libxm4,
I had completely missed that. You are right, they do. But this can not
be seen from the control file, it is added by ${misc:Depends},
${shlibs:Depends}.
> which depends on libmotif-common and
> libxm4 recommends the others (for new installations), so it's a fairly
> safe bet that if you have libxm4 you'll have everything that provides
> libmotif3 and libmotif4.
> It's not perfect, but I do not know of a better solution.
I finally see what you were hinting at. The missing piece was above. But
indeed, because you can not guarantee that all three will be installed
if somebody installs a package that requires libmotif3/libmotif4, I
don't think this is the right solution. Providing a virtual package
(lets not call it transitional then) is I think better.
> An other option is to ALSO provide a virtual libmotif3 package (very
> similar to libmotif4).
>
> I thought of this, but libmotif3 was dropped from Debian around 2010, so
> I think by now everyone has found another solution; i.e. make their own
> symlinks, or if they are Ubuntu users, upgrade to Precise.
If this is true, why do you care about providing libmotif3 at all? Just
asking.
>> To be perfectly clear, I think ONLY libmotif4 could ever provide
>> libmotif3. The alternative is a libmotif3 package. This is independent
>> of our final choice of multi-arch for each package.
>
> I disagree, what about new installations? Surely somebody who types
> 'sudo apt-get install libxm4' will have end up with all the requirements
> to install packages that depend on libmotif3 and libmotif4?
No. If he/she absolutely needs libmrm4 or libuil4 to run his/her foo-bin
package, he should get it no matter what. So libmotif3/libmotif4 should
absolutely pull that in or fail. Therefore, a virtual libmotif4 package
that provides libmotif3. I propose we remove the sentence "...can safely
be removed..." This problem will go away soon, as packages will depend
on the proper library directly in the future.
> One sure way to solve this is to make libxm4 depend on libmrm4 and
> libuil4, but I don't like circular dependencies.
No, me neither.
Paul
signature.asc
Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42
On 17-02-13 21:54, Graham Inggs wrote: > I finally see what you were hinting at. The missing piece was above. But > indeed, because you can not guarantee that all three will be installed > if somebody installs a package that requires libmotif3/libmotif4, I > don't think this is the right solution. Providing a virtual package > (lets not call it transitional then) is I think better. > > > I am open suggestions. But (on Ubuntu at least) if you install a > package, all recommended packages are pulled in as well. In Debian as well, by default. But people are allowed to override this behavior, also on Ubuntu. The policy [1] is clear however: Recommends This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. So, if you want to be sure that a package that DEPENDS on libmotif3/4 has its dependency fulfilled, we need a package that provides ALL dependencies, i.e. an (empty) libmotif4/3 package. > I want compatibility with commercial packages that need libXm.so.3. > Seeing that we provide these symlinks, we may as well advertise that we > provide libmotif3 compatibility. I thought so. Sure, no problem. > No. If he/she absolutely needs libmrm4 or libuil4 to run his/her foo-bin > package, he should get it no matter what. So libmotif3/libmotif4 should > absolutely pull that in or fail. Therefore, a virtual libmotif4 package > that provides libmotif3. I propose we remove the sentence "...can safely > be removed..." This problem will go away soon, as packages will depend > on the proper library directly in the future. > > As above, when installing a package, all recommended packages are pull > in as well. In most cases, but not guaranteed, also not on Ubuntu. Paul [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42
On 18-02-13 07:47, Graham Inggs wrote: > I propose that the 'Provides: libmotif3, libmotif4' line be removed from > d/control altogether: This sounds good. Will upload tonight. Paul signature.asc Description: OpenPGP digital signature
Motif 2.3.4-1 uploaded to Debian
On 18-02-13 08:23, Paul Gevers wrote: > On 18-02-13 07:47, Graham Inggs wrote: >> I propose that the 'Provides: libmotif3, libmotif4' line be removed from >> d/control altogether: > > This sounds good. Will upload tonight. The package is waiting in NEW for approval: http://ftp-master.debian.org/new.html Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 24-02-13 07:43, Graham Inggs wrote: > Recent changes (19 February) > > Hi, I just wanted to clear up a few things regarding the recent changes > I committed. Good. I probably would have asked about 2 specifically. 1. FTBFS on Ubuntu Raring: > I'd like to rename (sorry) the patch and come up with a better > description once I fully understand what changed in Raring. Good. > I think the following page holds the answer: > http://wiki.debian.org/ToolChain/DSOLinking I already had a look at that page when I was creating the symbols. Indeed a lot of good info there. > 2. Build Motif with JPG and PNG support: > After being able to build motif on Raring, I noticed there were > additional symbols. I found that my test machine had libjpeg8-dev and > libpng12-dev installed and this caused motif to build with additional > support for these image types. I believe we should build motif with JPG > and PNG support, and found that motif is built this way in Red Hat [2]. Do you know what this additional support means? In principle I don't object, but I like to understand. > I have not made any changes yet to the symbols files. Please do. > 3. Fix buffer overrun in lib/Xm/FontS.c: > I was looking at the upstream git [1] and found the only change since > the 2.3.4 release was this buffer overrun fix committed on 31 October > 2012. I figured we should include it. How did you see with what code they released 2.3.4? I could not (easily) deduce this from upstream GIT repository. > If you agree on the above changes, I will write up a changelog > describing them. Yes, please. Additionally, I was wondering if you/we find it worth while to ask the current maintainer of upstream what he things of co-maintainers? I expect there are still quite some upstream bugs which are worth fixing, although they are not reported against Debian. Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 25-02-13 09:38, Graham Inggs wrote: > It seems other distributions, e.g. Fedora are also switching to DSO > linking [2]. > It's probably worth combining my patch along with Ubuntu's > 0003_fix_ftbfs_binutils-gold.patch [3] and pushing it upstream. Sounds good. >> Additionally, I was wondering if you/we find it worth while to ask the >> current maintainer of upstream what he things of co-maintainers? I >> expect there are still quite some upstream bugs which are worth >> fixing, although they are not reported against Debian. > > No harm in asking. I am a bit concerned that there hasn't been any > upstream activity for a couple of months now. I am not surprised. As I believe this is a company effort, I think somebody got time to work on release a 2.3.4 version with the new licensing. After that of course he got a new assignment. That is exactly why I think it might be interesting to have community support as well. > What do you think of providing a motif-sdk-examples package? > I was thinking we could provide a compressed archive of the source code > in /usr/share/doc/ or somewhere that users could extract to their home > directories and then build the examples there. I did have a brief look > for similar packages in Debian, but didn't find any. Maybe this is just > redundant, as the examples are already available in the source package. Indeed. I think the examples in the source package are good for now as any user can install a source package (not just root). Maybe mentioning something along those lines in a README file somewhere in one of our packages does not hurt though. I.e. that example code is available. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-12-g64986ea
On 08-03-13 18:47, Graham Inggs wrote: > Clean debian/system.mwmrc-menu after installing Graham, I prefer to do this by adding that file to a file called debian/clean. That way you don't have to override dh_clean. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-10-g5f4f0e2
On 08-03-13 12:48, Graham Inggs wrote: > +++ b/debian/mwm.install > -/etc/X11/mwm/system.mwmrc-menu > +debian/system.mwmrc-menu /etc/X11/mwm > +++ b/debian/rules > - cp -a clients/mwm/system.mwmrc debian/tmp/etc/X11/mwm/system.mwmrc-menu > + cp clients/mwm/system.mwmrc debian/system.mwmrc-menu Hi Graham, Can you please elaborate why you find this nicer? You didn't need the clean up before, and now you do. So, why? Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-10-g5f4f0e2
On 08-03-13 12:48, Graham Inggs wrote: > Include custom Unity Greeter badge for MWM > diff --git a/debian/custom_mwm_badge.png b/debian/custom_mwm_badge.png > new file mode 100644 > index 000..cfc1703 > Binary files /dev/null and b/debian/custom_mwm_badge.png differ Where did you get this file? What is the copyright? Is this file created as png or is it actually created in a program and does that program store the file in a different format so that you can edit it? In the later case, we also need that source and preferable build the png from that source. Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 03/13/13 09:46, Graham Inggs wrote: > I've cleaned up some things, added copyright info for > custom_mwm_badge.png and updated the changelog. Good. Are you sure you own the complete copyright of that file? I.e. didn't somebody else have the original copyright? > Maybe ac_find_xft.m4 should be totally reworked, and we should probably > consult upstream before doing that. Sure, although by now I think you nearly know as much about the motif code as the current upstream maintainer. I think he was just paid for a while to work on it. > Is there any harm in leaving the build-depends on libfreetype6-dev and > libxrender-dev in place for now? I saw you dropped them in the mean time. Fine. However, from your story I understand that motif needs to link to libxft. If you want to be sure it is linked, please DON'T assume it is pulled in via your depends, but explicitely depend on it. In general, a depends of your package may cease to depend on the library (maybe it is optional, or a replacement is found) and you get strange FTBFS or worse in a case like this, your package builds different than you intend. > We could create a motif-demos package and copy the demos directory to > /usr/share/doc/motif-demos, similar to what is done in gtk2.0-examples > and gtk-3-examples. > What do you think? Sounds ok, but I thought originally you created your patch to save on build time. Do you now think it is worth it to distribute the demos? Oh, wait, you only mean the source code here. Than I think I like the "examples" better as name then demos, but I let it up to you. Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
On 03/14/13 07:29, Graham Inggs wrote: > After asking that question I tried to do more reading up symbols, but > I found the information very vague, especially about (optional) > symbols. Out of interest, why are there so many other (optional) > symbols? How did you determine they were optional? There are several *.elist files in the package. All symbols that are exported, but are marked private in those lists, I marked as optional. They should not have be in the symbols file, but unfortunately they are exported anyways. By the way, these elist files seem not to be up-to-date, although the header clearly says it is absolutely necessary :(. > I guess Canonical might have the copyright on the white circle > image, I'll check in the sources of unity-greeter. Ok. > I'm not sure about the four squares, I based that on the look of the > icon for Xterm that is displayed in MWM [1]. If you draw them yourselves, than it is all right. No need to look further for that. > Shall I email upstream now and see if they are interested in support > from the community? Good idea. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-31-g912bcbf
Hi Graham, On 17-03-13 09:16, Graham Inggs wrote: > The following commit has been merged in the master branch: > commit 0450ba5184ed53ecf6330e0accdd727509a75d48 > +Comment: Created in GIMP using /usr/share/unity-greeter/unknown_badge.png, > + from Ubuntu's unity-greeter package (copyright 2012 Canonical Ltd and > + released under GPL-3), as a template. As per: > https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034800.html If this is true, we do have an (small) issue. You can not just relicense this file without permission of the copyright owner. So, you have no choice other than state the license of this file as GPL-3 or ask Canonical to relicense. I don't think it is a problem to have the icon licensed under GPL-3, although most of motif is less strict licensed under LGPL, etc, as it is not part of the binary (library) so packages linking to it don't have any problem. By the way, you really should add Canonical to the copyright holders list as well. Paul signature.asc Description: OpenPGP digital signature
Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-31-g912bcbf
Hi Graham, Maybe I was unclear. See what I mean below. On 17-03-13 10:54, Graham Inggs wrote: > I understood that this was OK since the new license was 2+. > Or is the problem more about changing from GPL to LGPL? The latter. > By the way, you really should add Canonical to the copyright holders > list as well. > Which list is that The one in d/copyright. Please see below. (Don't forget to add the GPL3 required text to the file.) (And are you sure it is not GPL3 or later?) Files: debian/custom_mwm_badge.png Copyright: 2012 Canonical Ltd 2013 Graham Inggs License: GPL-3 Comment: Created in GIMP using /usr/share/unity-greeter/unknown_badge.png, from Ubuntu's unity-greeter package, as a template. As per: https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034800.html Paul signature.asc Description: OpenPGP digital signature
Re: First motif commits
[Seems like the mail servers of Debian were out yesterday, sending again] Hi Graham, I have some questions in return. On 24-03-13 08:40, Graham Inggs wrote: > You wrote that you wouldn't upload 2.3.4-2 until 2.3.4-1 had been reviewed. > Is it possible to re-upload our current effort as 2.3.4-1 (with the > appropriate changes to the changelog and libxm4.symbols)? > It may then be possible to get Ubuntu to sync motif from Debian's NEW > queue and still make it into Raring (final beta freeze is March 28 [1]). Are you sure? I believe the NEW queue is ONLY accessible to the ftp-masters, as uploads might contain non-distributable material, and the task of the ftp-masters is exactly to prevent that entering Debian. So if that is possible, you are talking to an ftp-master, right? Then we could just make an Ubuntu version of the package instead. Furthermore, the feature freeze has already past for a long time, so usually Ubuntu does not allow such large changes. Who are you communicating with about this effort, please include me in the communication. Last point, I think if we would do this, I would just upload a -2 version. But I think it would put us back on the agenda. What I think is that the ftp-masters are reluctant to look at it, but as it gets closer to the old side of the list, it will get attention. > Is there anything that needs to be done in wnpp bug #695130 [2]? No. All information (I think) is in the bug report and it will be automatically closed by our upload (my first entry in the changelog for 2.3.4-1). Paul > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695130 signature.asc Description: OpenPGP digital signature
Fwd: Re: First commits in git repository on Alioth [ Was: Re: openmotif is now LGPL, retirement of lesstif in jessie?]
[Mail servers were out yesterday, forwarding to the list] Original Message Subject: Re: First commits in git repository on Alioth [ Was: Re: openmotif is now LGPL, retirement of lesstif in jessie?] Date: Sun, 24 Mar 2013 08:38:17 +0100 From: Paul Gevers To: BERTRAND Joël CC: openmo...@packages.debian.org Hi Joël, Thanks for your (late) response. On 23-03-13 23:13, BERTRAND Joël wrote: > Sorry for the delay. I just discover your mail on my spam box. I can > help you to offer a openmotif package. How can I start ? We are working hard to get (open)motif in full shape. Our work [6] is on Alioth. If you want to contribute, please follow my proposal as described in my e-mail to you on 27 Dec 2012 (see below), skipping the first item (I now own that bug). A new motif package is already waiting in the NEW queue [7] for a month. Paul [6] http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git [7] http://ftp-master.debian.org/new/motif_2.3.4-1.html On 27-12-12 17:37, Paul Gevers wrote: > Hi Graham and Joël, > > I moved this discussion off-list from devel, and hope you don't object. > > On 26-12-12 01:06, Graham Inggs wrote: >> I would be happy to join a team effort. > > Joël, as you can see, you have now two co-maintainers if you want. If > you don't object, my proposal is the following: > > - Joël: you own and retitle bug 695130 appropriately. > - I assume you both don't have upload rights, so I will have to do that > part, during the Wheezy freeze, we only target experimental. > - I create a git repository on Alioth [1]. I hope you like git, but if > not we can agree on an other VCS. > - I can import as much of the history of openmotif as I can find [2]. > - You both make to register on alioth [3] and become member of the > collab-maint project [4]. Please let me know your alioth registration > name, so I can send the mail as described on [1]. > - We should agree on the name of the source package. Graham prefers > motif i.s.o. openmotif :) > - Please make sure you both are subscribed to the PTS [5] for the > package openmotif for the moment, and possibly to motif after upload. > > Joël, to not let the enthusiasm of Graham die, I propose that we wait > for a week for your response, and in case of no response, I will start > with the proposal above, but will wait with uploading a new package. > > Paul > > [1] http://wiki.debian.org/Alioth/PackagingProject > [2] http://snapshot.debian.org/package/openmotif/ > [3] https://alioth.debian.org/account/register.php > [4] https://alioth.debian.org/projects/collab-maint/ > [5] http://packages.qa.debian.org/o/openmotif.html (left bottom) > signature.asc Description: OpenPGP digital signature
Bug#704724: openbox-session(1) refers to autostart.sh files
Package: openbox Version: 3.5.0-6 Severity: minor A 3.5.0 openbox package told me that : The config file previously called autostart.sh is now just called : autostart. You should rename yours to remove the .sh from the end : of the name but the openbox-session(1) man page says : On log in, openbox-session will run the ~/.config/openbox/autostart.sh : script if it exists, and will run the system-wide script /etc/xdg/open‐ : box/autostart.sh otherwise. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405004451.ga28...@lightlink.com
Fwd: Motif
Hi all, I am sorry to read it, but it seems we won't have motif in experimental before the release of Wheezy. If we want to get the package in Ubuntu Raring, it needs to go on it's own. Graham, do you still want to do that? Paul Original Message Subject: Motif Date: Sat, 6 Apr 2013 00:59:59 +0200 From: Luca Falavigna To: Paul Gevers Hi! I saw on the IRC logs you pinged me, but unfortunately I wasn't online, so I'm writing you by mail :) There's a nasty bug in dak, which prevents accepting a package if components are already available in a different section, as happened with motif, which shares libmotif-dev and libmotif4 with openmotif package. The workaround for this bug would require removing openmotif from unstable, and immediately upload motiv. This is not advisable right now because that would also trigger an automatic removal from Wheezy for openmotif because it has no reverse (build-)dependencies. The best solution at this point would be the following, IMO: 1) Upload motif in Ubuntu (with 0ubuntu1 as revision) 2) Have the override entries for motif deleted 3) Reupload motif in NEW 4) Wait for Wheezy to be released (very soon!) 5) Remove openmotif and immediately accept motif I'll take care of 2) myself, and I'm going to inform you about the time you can reupload motif again. Cheers, Luca signature.asc Description: OpenPGP digital signature
Re: Motif
Hi, On 06-04-13 14:30, Graham Inggs wrote: > I think it is very late now to try and get motif into Raring with it not > being in Debian. Get it, and thought so. > Paul: when you re-upload motif in NEW, will you go straight to 2.3.4-2, > or upload 2.3.4-1 again? > (or just to mix things up, upload 2.3.4-2 as 2.3.4-1 since 2.3.4-1 was > never released?). I consider 2.3.4-1 released in the sense that it is tagged as such in our git repository. So I think I go for 2.3.4-2, but of course that might still depend on the state of 2.3.4-2 at that time. (I think it is nice and shiny now). Paul signature.asc Description: OpenPGP digital signature
Re: Motif
Hi Luca, On 06-04-13 00:59, Luca Falavigna wrote: > There's a nasty bug in dak, which prevents accepting a package if > components are already available in a different section, as happened > with motif, which shares libmotif-dev and libmotif4 with openmotif > package. > > The workaround for this bug would require removing openmotif from > unstable, and immediately upload motiv. This is not advisable right > now because that would also trigger an automatic removal from Wheezy > for openmotif because it has no reverse (build-)dependencies. > > The best solution at this point would be the following, IMO: > 1) Upload motif in Ubuntu (with 0ubuntu1 as revision) > 2) Have the override entries for motif deleted > 3) Reupload motif in NEW > 4) Wait for Wheezy to be released (very soon!) > 5) Remove openmotif and immediately accept motif > > I'll take care of 2) myself, and I'm going to inform you about the > time you can reupload motif again. As the release of wheezy has happened this weekend. Is it now a good time to follow up on the actions above? We are eager to work on the transition of all the lesstif2 depending packages to motif, so that we can release Jessie without lesstif2 (which I will try to make a release goal). Paul signature.asc Description: OpenPGP digital signature
lesstif2 to motif transition
Hi release team, I like to get your opinion and advise on the following. Motif has been released with a free license last year, and I would like to move it from non-free (called openmotif) to Debian main. Its former free replacement lesstif2 is unsupported upstream and should be retired (in Debian), as its goal has been reached: a free motif. Openmotif (which we want to rename to motif) is currently in non-free and due to a bug in dak it needs to be removed from unstable to let it into main, which makes it less suitable to test this in experimental (as it would leave unstable without (open-)motif). Motif and lesstif2 build the same libraries, albeit with different sonames, so the libraries can coexist. The -dev packages and auxiliary packages cannot coexist as file names are shared (lesstif2 was meant as drop in (binary compatible) replacement). According to policy (2.5) no two packages may be in the section optional or higher if they conflict, and packages can not depend on a package of a lower priority. So strictly speaking motif could not take over unless we can ignore this rule of policy during the transition. We have not started talking to the maintainers of packages depending on lesstif2 (other than a message to d-devel [1]), as I wanted to have the way clear before that. Graham Inggs has tested building all the reverse dependencies [2], though. So my question basically is, what would be the most appropriate order to do things? My proposal would be (with your approval) to just get motif into unstable/main and start converting the dependencies with the help of their maintainers (the libraries can coexist). Because the -dev package name has to change all build dependencies would have to get a source-full update. I would have liked to stage everything in experimental, but due to this (quoted from ftp-master) nasty dak bug, that would leave unstable (non-free) without (open-)motif. Paul [1] https://lists.debian.org/debian-devel/2012/12/msg00369.html [2] https://launchpad.net/~ginggs/+archive/motif signature.asc Description: OpenPGP digital signature
Re: lesstif2 to motif transition
Hi Graham, On 06-05-13 23:01, Paul Gevers wrote: > My proposal would be (with your approval) to just get motif into > unstable/main and start converting the dependencies with the help of > their maintainers (the libraries can coexist). Because the -dev package > name has to change all build dependencies would have to get a > source-full update. I would have liked to stage everything in > experimental, but due to this (quoted from ftp-master) nasty dak bug, > that would leave unstable (non-free) without (open-)motif. I was thinking, how well did it go with your building of all reverse dependencies, and how well would it work if lesstif2-dev would be a transitional package that depends on libmotif-dev? If that would work at all, I think that is a good alternative to my proposal above. Paul signature.asc Description: OpenPGP digital signature
Re: lesstif2 to motif transition
On 07-05-13 07:55, Graham Inggs wrote: > I think the testing went very well. As we suspected, most packages only > required changing the build-depends on lesstif2-dev to libmotif-dev. > There were a few that required the addition of libxt-dev and one or two > that required libxext-dev and libxp-dev (although we should try to > remove that dependency). Can you please document that, I mean which ones? It would be great if you would reply to the e-mail I sent yesterday to the release team with full details, so that the team knows when they make a decision. And I think (unsure now) that these missing dependencies are actual bugs in those packages, so they should get filed and fixed anyway. > Cernlib depends on libpacklib-lesstif1-dev and libpawlib-lesstif3-dev > from paw and pcb depends on its own pcb-lesstif, these packages should > probably be renamed. I would leave renaming to the maintainers of those packages. We can let them know but this is not a necessary action. Did you actually try to RUN any of the compiled packages? > Do -dev packages normally get transitional packages? I can't think of a > situation where that would be useful. Normally not I guess, but the situation here is strange. Usually you don't move from one package to the next as a drop in replacement. Usually, you would need work as well due to different api and stuff. > Ideally we need all of the packages that depend on lesstif2 to be > rebuilt against libmotif. Sure, but we are talking about a transition plan where the state of the archive remains as stable as obtainable. If needed breakage is allowed, but only when we can not come up with a solution were this don't happen. And I was hoping that lesstif2-dev being empty and depending on libmotif would achieve this. > When a user upgrades they will then get > libmotif which conflicts with lesstif2 and it will be removed. > If a user was developing with lesstif2-dev it would be removed due to > the conflict above, but they would not have been able to continue > building against libmotif-dev without making changes anyway. Why not? Aren't the headers the same? If not, how can WE replace lesstif2 with libmotif? Anyway, the users that build are not the only ones we need to care about. Also the current packages between libmotif upload and full rebuild need a proper archive. We should plan this properly. Paul signature.asc Description: OpenPGP digital signature
Re: lesstif2 to motif transition
Hi RT, On 06-05-13 23:01, Paul Gevers wrote: > So my question basically is, what would be the most appropriate order to > do things? > > My proposal would be (with your approval) to just get motif into > unstable/main and start converting the dependencies with the help of > their maintainers (the libraries can coexist). Because the -dev package > name has to change all build dependencies would have to get a > source-full update. I would have liked to stage everything in > experimental, but due to this (quoted from ftp-master) nasty dak bug, > that would leave unstable (non-free) without (open-)motif. Having thought about this again today, how about the following proposal: - Upload the latest packaging of motif to non-free to get the new packaging and rename of the source past the NEW queue. - Ask and help the current maintainers of reverse dependencies to try out building their packages in experimental with libmotif-dev in non-free. Yes, the policy does not allow this, but as ftp-master agrees that we move the package to main, I expect this could be acceptable, if at all possible. - When all packages are lined up, remove motif from non-free into main and start the transition in unstable. Do you think this works and do you find this acceptable? An alternative that I could come up with, but maybe it is an insane idea, is that I update the lesstif2 package to make the lesstif2-dev package a transitional package that depends on libmotif-dev. I believe only the packages that need the additional build dependencies (e-mail from Graham) would not be helped by this temporary solution, but that can be fixed in advance. So than we could upload motif and lesstif2 to unstable after your approval and start converting the packages to properly build-depend on libmotif-dev. Do you prefer that I file a proper transition bug for this issue now? Please advice on what you find acceptable. I propose that we start to inform the reverse dependent package maintainers about our intent to replace lesstif2 with motif when we have agreed on the proposed attack path from your point of view. Paul signature.asc Description: OpenPGP digital signature
proposal for the reverse depending buggy packages [Was: Re: lesstif2 to motif transition]
Hi Graham, Before we file bugs again the packages below I like to discuss the phrasing. Do you agree with the following? """ Hi Maintainer, Your package build depends on libxt-dev/XXX but does not declare this relation in the debian/control file. This is currently no problem as this is pulled in by the lesstif2-dev package that you do depend on. In the near future we like to replace lesstif2 in Debian with the relicensed (open-)motif package. Lesstif2 was originally created as an free alternative for motif, but in the mean time became unmaintained and buggy. Motif itself is now free and got its latest maintenance release last year. To ease the transition that will happen some time soon, we will follow up on this, please explicitly build-depend on libxt-dev/XXX Kind regards, Paul & Graham. """ On 07-05-13 21:01, Graham Inggs wrote: > The following packages required an additional build-depends on libxt-dev: > > ferret-vis > mesa-glw > sqsh > tcm > xabacus > xpdf > xsol > > The following packages required additional build-depends as indicated below: > > gridengine - libxft-dev, libxp-dev > hotswap - libxtdev, libxext-dev, libxp-dev > mgdiff - libxt-dev, libxext-dev > xawtv - libxp-dev > xtel - libxpd-dev signature.asc Description: OpenPGP digital signature
Re: proposal for the reverse depending buggy packages [Was: Re: lesstif2 to motif transition]
Ok, I think I will file the bugs, hopefully tomorrow morning. Else it might jump over the weekend. I'd like to use proper usertags (just in case you want to do it). Paul On 07-05-13 22:08, Graham Inggs wrote: > I agree with the message. I can suggest some minor grammatical changes > though. > > On 7 May 2013 21:56, Paul Gevers <mailto:elb...@debian.org>> wrote: > > > This is currently no problem as > this is pulled in by the lesstif2-dev package that you do depend on. > > > I would say "This is current not a problem as" > > > Lesstif2 was originally created as an > free alternative for motif, but in the mean time became unmaintained and > > > meantime - one word > > > To ease the transition that will happen some time soon, we will follow > > > sometime - one word > > ...and then some of my own typos: > > > hotswap - libxtdev, libxext-dev, libxp-dev > > > hotswap - libxt-dev, libxext-dev, libxp-dev > > > > xtel - libxpd-dev > > > xtel - libxp-dev > signature.asc Description: OpenPGP digital signature
Bug#707211: [ferret-vis] please build-depend on libxt-dev
Source: ferret-vis User: openmo...@packages.debian.org Usertags: lesstif2motif Version: 6.6.2-1.1 Severity: normal X-Debbugs-CC: openmo...@packages.debian.org Hi Maintainer, Your package build depends on libxt-dev but does not declare this relation in the debian/control file. This is currently not a problem as this is pulled in by the lesstif2-dev package that you do depend on. In the near future we like to replace lesstif2 in Debian with the relicensed (open-)motif package. Lesstif2 was originally created as an free alternative for motif, but in the meantime became unmaintained and buggy. Motif itself is now free and got its latest maintenance release last year. To ease the transition that will happen sometime soon, we will follow up on this, please explicitly build-depend on libxt-dev, as we don't intend to include the depends on libxt-dev in libmotif-dev. Kind regards, Paul & Graham. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: OpenPGP digital signature
Seems like the bug was not forwarded, oh well
Seems like the bug was not forwarded, oh well The first example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707211 I go now. Paul signature.asc Description: OpenPGP digital signature
Bug#707260: chrony initscript uses netstat but lacks a dependency on net-tools, results in failure to go online
Package: chrony Version: 1.26-3 On a system debootstrapped with minbase I installed chrony and noticed it doesn't go online on boot. The reason is that its initscript is using netstat (which was not installed) to determine presence of a default route. This particular wheezy system was installed from http://archive.raspbian.org/raspbian with --arch=armhf but afaict the bug is present in upstream Debian packaging too. HTH :) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508162005.gl2...@home.lan
Bug#707621: [hotswap] please build-depend on libxt-dev, libxext-dev, libxp-dev
Source: hotswap User: openmo...@packages.debian.org Usertags: lesstif2motif Version: 0.4.0-12 Severity: normal X-Debbugs-CC: openmo...@packages.debian.org Hi Maintainer, Your package build depends on libxt-dev, libxext-dev and libxp-dev but does not declare this relation in the debian/control file. This is currently not a problem as this is pulled in by the lesstif2-dev package that you do depend on. In the near future we like to replace lesstif2 in Debian with the relicensed (open-)motif package. Lesstif2 was originally created as an free alternative for motif, but in the meantime became unmaintained and buggy. Motif itself is now free and got its latest maintenance release last year. To ease the transition that will happen sometime soon, we will follow up on this, please explicitly build-depend on libxt-dev, libxext-dev, and libxp-dev, as we don't intend to include these depends in libmotif-dev. Kind regards, Paul & Graham. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: OpenPGP digital signature
