Bug#1081045: RFS: pidgin-skype/20240122+gitab786a3+dfsg-3 -- Skype plugin for libpurple messengers
On 2024-09-07 at 17:58, Phil Wyett wrote: > Review... > 7. Install [No previous installs]: Issue > > Install this package on a clean system/Virtual Machine (VM) and it > installs a variety of dependencies but not the pidgin GUI. Speaking as someone who once used a similar pidgin-* plugin package: I don't believe that this is an issue. My understanding is that this is a plugin intended to be available to be used by *any* application which uses the libpurple backend, not necessarily just pidgin. If that is correct, then it would be erroneous for this to have a dependency chain which leads any single specific such application to get installed. My experience with such plugins is most prominently with purple-discord, which likewise identifies itself as a plugin for applications which use libpurple, and which cites two of them: pidgin and finch. In addition to naming those in the package description as examples of such applications, it includes an Enhances: field, and lists the packages in that field. It might make sense for other libpurple plugin packages to similarly include an Enhances: field for the endpoint applications. Then again, that would mean either inconsistency between the plugin packages in that regard, or each one needing to keep up with updating the list whenever an appropriate change is made to it in another plugin package; that might not be worth the bother. It *is* a bit inconsistent that some of the libpurple plugin packages seem to use the purple-* prefix and others the pidgin-* prefix. It would probably be good to get that sorted out, but I don't know if here would be the place to start doing it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: filename case policy inside /usr/bin ?
On 2023-01-16 at 15:04, Fab Stz wrote: > Hello, > > Is there any policy for the filename case for the executables > installed in /usr/bin ? Most are lowercase. > > The package I maintain uses mixed uppercase & lowercase. For example: > /usr/bin/FreeFileSync I'm not aware of any specific policy just offhand, and I'm certainly not an expert or an authority, but: $ apt-file search /usr/bin/ | grep [A-Z] | wc -l 2094 There appear to be *rather a lot* of files under /usr/bin/ whose names include uppercase letters... $ apt-file search /usr/bin/ | grep [A-Z] | cut -d ':' -f 1 | uniq -c | wc -l 524 ...and also rather a lot of packages which include such files. My guess is that this would be just fine. > Please, leave me in copy of your answer. In turn, please do not reply to me directly, only via the list. (Unless you specifically want to draw my attention to that specific message, and you think I won't get, or will miss noticing, the message otherwise.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: lintian errors packaging Barry's Emacs
On 2022-12-27 at 07:12, Ole Streicher wrote: > Hi Santiago, > > Santiago Vila writes: > >> If you don't have deb-src lines, they are the same as the usual deb >> lines except that they begin with deb-src. > > Just curious: why are the deb line not used by default here? As a place to look for source-package information in the absence of deb-src lines, you mean? While I have no inside knowledge on this, my inference has always been that it's to avoid downloading (and updating) and storing the index data for source packages, for that presumed large majority of people who have no need to care about source packages. I.e., the act of adding a deb-src line is the way for the sysadmin to denote "for this computer, having convenient access to Debian source packages is sufficiently important that the cost of the index data - in local storage, in network traffic, and in remote-server transmission load - is worth paying". In principle it would probably be possible to design a way of flagging that in reverse (so that deb lines would get both types of index by default, and only if a flag is set would the source-package idex data not be gotten), but just at a glance that looks like it'd be more complicated to engineer, and in any case the transition seems as if it'd be mildly horrific. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Specifying "Build Type: all" using sbuild
On 2022-06-01 at 09:54, Hilmar Preuße wrote: > Am 01.06.2022 um 13:45 teilte Andrey Rahmatullin mit: > >> On Wed, Jun 01, 2022 at 01:43:12PM +0200, Hilmar Preuße wrote: >>> Package: texlive-bin >>> Version: 2022.20220321.62855-3 >>> Source Version: 2022.20220321.62855-3 >>> Distribution: sid >>> Machine Architecture: amd64 >>> Host Architecture: amd64 >>> Build Architecture: amd64 >>> Build Type: all >>> >>> vs. >>> >>> Package: texlive-bin >>> Version: 2022.20220321.62855-3 >>> Source Version: 2022.20220321.62855-3 >>> Distribution: sid >>> Machine Architecture: amd64 >>> Host Architecture: amd64 >>> Build Architecture: amd64 >>> Build Type: any >> >> Can you please point at the "Arch type" lines? > > I'm very sorry! Looking at the build log I don't see a line containing > the string "Arch type". Please Could you go into detail? I'm not remotely an expert on any of this, but: I interpreted that question as a way of suggesting that, since there is no "Arch type" line, the "Build type" line is containing the arch-type value. In other words: that the value in the "Build type" line is what will be controlled by the --arch-* options suggested earlier in the thread. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: zekr project and new version of Debian
On 2021-12-13 at 09:17, Mohsen Pahlevanzadeh wrote:
> On 12/13/21 11:13, Andrey Rahmatullin wrote:
>
>> On Mon, Dec 13, 2021 at 08:56:30AM +0330, Mohsen Pahlevanzadeh
>> wrote:
>>
>>> https://packages.debian.org/stretch/zekr Project is a powerful
>>> and useful project in Quran. But its maintainer was released it.
>>> I contact with him, and decide to build deb for debian repo and
>>> rpm for fedora and zst for archlinux.
>>
>> Do you mean you are trying to build the same old source that was
>> removed from Debian because it depended on obsolete libs? In that
>> case it may be impossible to do that on modern Debian. Also, if you
>> want to reintroduce the package in Debian it will be impossible as
>> well, and if you are trying to build it just for yourself or for a
>> non-Debian repo then you shouldn't ask on this mailing list, which
>> is only for questions about contributions to Debian.
>
> Oh, no, I compiled from original source from sourceforge:
> https://sourceforge.net/projects/zekr/
As Andrey pointed out, if this is too old, it might not be compatible
with the libraries and library versions that are available in more
modern versions of Debian.
> I need to create a dependency list according to new version of
> dependencies.
>
> Now, libwebkitgtk-1.0-0 is removed from all repo. I want to know name
> of new version of libwebkitgtk-1.0-0
Unless I'm very much mistaken, there is no such thing.
From a naive search ('apt-cache search libwebkit | grep -i gtk'), I'd
guess that you want the libwebkit2gtk package line; in current testing,
that would mean libwebkit2gtk-4.0-dev and libwebkit2gtk-4.0-37.
However, the name change (from libwebkitgtk to libwebkit2gtk) appears to
reflect an underlying compatibility change in the upstream library.
Quoting from the changelog entry dated August 27th, 2014: "now
WebKitGTK+ only provides the new WebKit2 API.". This probably means that
it is not backwards compatible to the libwebkitgtk package line.
If zekr depends on the WebKit API, and does not support the WebKit2 API,
then it is not going to compile against this package.
In that case, if you want to compile zekr on a modern system, you're
going to need to either also compile something to provide the old WebKit
API, or update zekr to use the WebKit2 API instead.
Doing the former would either involve going back to old, unmaintained
library code (not recommended, and unlikely to make it into Debian), or
implementing a new library project to provide that API yourself
(possibly a quite major effort, and the new library would also need to
get into Debian before zekr could).
Doing the latter would mean becoming the new upstream maintainer for
zekr.
At that point, if you want to also submit a Debian source package for
the updated version of zekr and become the maintainer for that package,
it would become appropriate to discuss the subject here. Until then, any
discussion of the effort should probably happen elsewhere.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: Location for user installed plugin libraries and icons
On 2021-06-04 at 17:43, Jon Gough wrote: > On 9/5/21 5:40 pm, Andrey Rahmatullin wrote: > >> On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote: >>> I now know what path I need to follow, i.e. have a plugin manager >>> that uses the platform installation process so that the uninstall >>> process will work and the packages and objects will be tracked. >> >> If this means calling apt from a plugin manager then it's probably >> not the best idea. > > Not quite. The plugin manager needs to keep track of what it has > installed and where, then during the uninstall process it can be > called, if needed, to perform the cleanup as it would if the main > program were calling it to uninstall one or more plugins. I'm... fairly sure that the uninstall process must not touch the contents of user directories, not even indirectly by invoking an external program (such as this plugin manager) which would do so on its behalf. If I'm wrong, someone may correct me, but I would be surprised if it were that easy to bypass this constraint on package design. > In most instances the main application is installed on devices that > have only one user, i.e. phone, tablet, etc.. Even when on a multi > user device, i.e. windows, the device is still only used by one > account. How can you possibly be sure about that? (Also, if someone is installing packages on a tablet or smartphone via apt, they are very likely sufficiently expert to have some idea of how to clean up after the uninstall as needed; if there's a device in those categories which uses apt for native install mechanisms, rather than as an aftermarket extra tool, I'm not aware of it.) > If the uninstall process is run for the main application any other > account using the machine will have issues if they expect the main > application to still be there. So, in this case uninstalling plugins > during the main uninstall process would not be a major issue. The > config files/data would not be uninstalled/removed by this process. And what if the user is uninstalling, but intends to install again later (maybe even right away)? To have to re-download and reinstall the plugins could easily be a significant irritation, at the least. Personally, I would probably see the plugins as being part of the program configuration; certainly I do so with e.g. the Firefox extensions I use. I genuinely do not see what insisting on uninstalling plugins at the same time as the main program, for all user accounts, provides as a benefit. The only maybe benefit I've seen suggested is cleaning up to free disk space, and that seems to me to be so obviously heavily outweighed by the other considerations that it should clearly not be the deciding priority. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: (No Subject)
On 2021-05-21 at 07:44, Polyna-Maude Racicot-Summerside wrote: > Hi, > > On 2021-05-21 7:30 a.m., Hunter Wittenborn wrote: > >>> If you want to get makedeb into Debian, then you'll need to >>> build a Debian source package for it. >>> If on the other hand you want to get the packages created by >> makedeb into Debian, you're probably out of luck. (For awareness, the above - though quoted by Hunter Wittenborn - was actually written by me.) > The only build system in Debian is Debian's build system based on > .dsc source file. In theory, it would probably be possible to have a program which takes as input a third-party package and transforms it into a Debian source package, then builds that into a .deb using Debian's build tools. The resulting intermediate-step source package could then, theoretically, be submitted for inclusion in Debian. It would be theoretically possible for something like makedeb to be modified to use that method, rather than producing .debs directly. In practice this would be unlikely to produce an acceptable source-based build (because of the "preferred form for modification" rule), so it'd only be viable for things that would have to go into non-free because of being opaque binary blobs to begin with - and for those I'm not sure there'd be much benefit from such a tool. But I'm not willing to entirely exclude it from first concepts. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: (No Subject)
On 2021-05-21 at 05:40, Hunter Wittenborn wrote: > <mailto:mechti...@debian.org> > >> If yes, then try to build it from its source. Then it can be >> published in main > > > <mailto:deb...@polynamaude.com> > >> Why are you putting the package in non-free ? > >> What license did you put your software under ? > > makedeb is licensed under the GPL3 license. > > The goal was to be able to just distribute the binary form of the > packages, as that's all that I get/use when I build it myself (the > helper application, makepkg, handles all the source files, and the > rest is just built into a binary package with makedeb itself). So... are you trying to get makedeb into Debian, or just the packages which makedeb creates? If you want to get makedeb into Debian, then you'll need to build a Debian source package for it. Since the source is GPLv3, there's no obvious reason why it would need to go into non-free; if (as I suspect is likely) the package formats it is capable of taking as input are created by and are available containing software which is itself DFSG-compliant, there's probably also no reason why it would need to go into contrib. At that point, it would fit into main. If on the other hand you want to get the packages created by makedeb into Debian, you're probably out of luck. In order to get into Debian, a package must start out in the form which is called a Debian source package; that's the form that includes a .dsc, et cetera. From there, it must be compiled into a .deb on the build-daemon (buildd) servers, by the usual Debian package-build mechanisms which take source packages as their input. > <mailto:deb...@polynamaude.com> > >> There's rule regarding GPL software and packaging that must be >> followed... > > I was looking at the following in the Debian Policy, which was > leading me to believe it would be fine: > > "The non-free archive area contains supplemental packages intended to > work with the Debian distribution that do not comply with the DFSG or > have other problems that make their distribution problematic." > > In this case the problems would be lack of a source package. Is there > someplace else that says GPL programs have to be distributed under > source packages? That would be the fact that the people who manage the Debian archive, and I think nowadays the tooling they use to do so, will not accept anything other than a source package as input for going into that archive. If you want a reference link for it, [1] was the first thing I found; it explains the reasons behind requiring a source package well enough, and does also state that one is required for entry into the Debian archive, although it doesn't explain why for that latter. I don't find a reference link for that latter myself just offhand, but it's been discussed in these mailing lists often enough. [1] https://wiki.debian.org/Packaging/SourcePackage#Why_bother_with_source_package_if_there_is_a_binary_package_.3F -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Location for user installed plugin libraries and icons
On 2021-05-07 at 16:47, Jon Gough wrote: > On 8/5/21 12:17 am, Kris Deugau wrote: > >> Jon Gough wrote: >>> Is there a process that allows the deb to 'clean up' the >>> application when the application is uninstalled, in particular >>> any 'install' artefacts that have been installed by plugins? >> >> Not really. The Firefox package, for instance, won't clear up the >> leftover cache data, bookmarks, and other configuration from >> users' $HOME when uninstalled - including things like addons the >> user may have installed direct from the Mozilla addons site. > > Hi, So, any user installable application extension/plugin which has > executables and supporting data is left behind on the system when the > owning application is removed or updated using the system > installation process? This is accepted behaviour? Yes. In fact, it's intended and desired behavior. > Shouldn't applications clean up after themselves and not leave user > systems with junk lying around? In addition to what others have said: Just because the user uninstalled the program now, doesn't mean they don't plan to reinstall it (either from the package, or by compilation from upstream, or by some other means) later on - or, for that matter, install a fork that also knows how to use the same plugins. If the user-profile installed data is big enough for cleaning it up to be a meaningful gain, isn't it also big enough for redownloading it - to say nothing of re-applying any local configuration settings that may have been stored in it - to be a painful consideration? For example, using the Firefox reference mentioned above, I have frequently uninstalled one Firefox version and later installed another - testing whether my local configuration is compatible with an upgraded version, then reverting to the older version to continue day-to-day use while I work to update the code for the newer version. That local configuration includes quite a few Firefox extensions (i.e., plugins in another sense), including one which I maintain locally for my own use. If uninstalling the Firefox package deleted the user-profile Firefox data, that would be much more difficult (because I'd have to back up the user-profile Firefox data before uninstalling one version, and restore the backup after installing the other), and the first time I did the uninstall I'd have lost my Firefox configuration - which is sizable and extensive, and whose roots date back literally decades. I would have been furious beyond belief to have lost that data. (While I did have backups I could have reverted to, not everyone will, and even in my case they were at that point older than I'd have liked to have to use.) There are certainly trade-offs about not permitting packages to touch files in $HOME at install or uninstall time; the risk of leaving unneeded cruft behind, as you cite, is one of them. For my money, however, the risk of data loss from deleting something that the user wanted to keep is enough by itself to outweigh the possibility of cruft. The problems of not necessarily being *able* to access $HOME at package uninstall time (if, for example, some users' home directories are on a currently-not-accessible encrypted filesystem or a currently-not-mounted network share) just add more justification on top of that. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal
On 2021-04-25 at 20:45, Phil Morrell wrote: > Hi tarzeau, as promised here's the policy violation details for this > RFS. Despite the length, thank you for working on this, it seems to be a > fun collection. >> §7.4 >> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts >> Be aware that adding Conflicts is normally not the best solution when >> two packages provide the same files... >> >> Having similar functionality or performing the same tasks as another >> package is not sufficient reason to declare Breaks or Conflicts with >> that package. > > Similar functionality: > * fifteen (sgt-puzzles) > * mines (sgt-puzzles) > * sudoku (sudoku) > > It is reasonable for a user to want to have all of sgt-puzzles, > nbsdgames and kdegames (using a k prefix) installed simultaneously and > play different subsets of the games available. This also allows the user > to pick their favourite implementation where multiple exist. sgt-puzzles may potentially also be relevant here for another reason. At one point in its history, the binaries it installs were provided with no name prefix. This resulted in, for instance, /usr/games/net, which had a namespace collision with /usr/bin/net from samba-common-bin (even though the files themselves did not conflict, being under different paths). Later, the binaries were all renamed to have a 'sgt-' prefix; that turned /usr/games/net into /usr/games/sgt-net, making it unique. The prefix is short enough that tab-completion is not meaningfully interfered with in practice, at least not in my experience. I think it likely that the near-collision of the name, as well as the namespace claim of various other binaries in the package, is the reason for the addition of that prefix. The transition was a bit jarring on my end, as a user of the programs; it'd have been simpler by far if the prefix had just been there from the outset, as there is the chance to do in this case. > Given all this, I suggest you adopt a universal prefix for all the > games, perhaps "nb-"? On the other hand, it might be worth > preserving tab completion with a suffix instead, in which case no > harm with a full "-nbsdgames". I was going to suggest a 'nbsd-' prefix, for reasons of consistency with the collection name, but if 'nb-' is considered acceptable it would at least have the advantage of being faster and easier to type. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Question about lintian bad-whatis-entry warning
On 2020-12-23 at 13:04, Aaron Boxer wrote: > On Wed, Dec 23, 2020 at 11:42 AM The Wanderer > wrote: > >> On 2020-12-23 at 11:25, Aaron Boxer wrote: >> >>> Hi, >>> I have some questions about a lintian warning I am getting from my package. >>> It complains that the NAME section of the man page can't be parsed. >>> Here is how the section appears in my man page: >>> >>> NAME >>>grk_compress — compresses images to JPEG 2000 format >>> >>> Note: I generate the man page from markdown files via pandoc. >>> >>> How can I get more insight into the problem? >> >> I have no particular relevant expertise, but one thing I notice >> instantly is that that doesn't quite look like a standard hyphen. >> >> Indeed, copying it into a text file and examining it with a hex viewer >> shows that — is apparently 0x8094, whereas - is 0x2d. (Correction: that's 0xe28094, which in UTF-8 is https://www.fileformat.info/info/unicode/char/2014/index.htm.) >> It might be worth checking whether that one character is the cause of >> this. > > Unfortunately, switching to en dash does not fix the problem What's the hex value of the generated character? Again, I could be barking up a completely wrong tree. However, as I understand matters there are Unicode emdash and endash characters (U+2014 and U+2013 respectively), both of which are distinct from the ASCII hyphen (U+002D). It's not impossible that the system involved may understand the latter but not the two former. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Question about lintian bad-whatis-entry warning
On 2020-12-23 at 11:25, Aaron Boxer wrote: > Hi, > I have some questions about a lintian warning I am getting from my package. > It complains that the NAME section of the man page can't be parsed. > Here is how the section appears in my man page: > > NAME >grk_compress — compresses images to JPEG 2000 format > > Note: I generate the man page from markdown files via pandoc. > > How can I get more insight into the problem? I have no particular relevant expertise, but one thing I notice instantly is that that doesn't quite look like a standard hyphen. Indeed, copying it into a text file and examining it with a hex viewer shows that — is apparently 0x8094, whereas - is 0x2d. It might be worth checking whether that one character is the cause of this. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On 2020-09-10 at 01:45, Tobias Frost wrote: > On Wed, Sep 09, 2020 at 10:53:37PM +0200, Alec Leamas wrote: >> Hi, >> >> A new version is uploaded to mentors. Time to reset the history. Changes >> since last round: >> >> - New warning dialog for downloading binary plugin content (patch). >> - Spelling error fixed >> - Removed references to upstream bugs. I think it's a pity, the >> references linked patches in d/patches to upstream bugs. > > Well, actually, all those lines probably should be removed: > debian/changelog is intended to record changes to the packaging part > only, it is not to record changes made upstream; more generally: Only > stuff that changes files in the debian directory should be mentioned > in d/changelog. (See > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog > for some better/more accurate wording in the Policy) I'm not sure I read that section as meaning that. Could you point more specifically to the exact wording there which you understand as reflecting this rule? Regardless, I'm fairly sure there are exceptions to this in practice. For example, if a new upstream release includes a change which closes an open Debian bug report or fixes a particular CVE, a notation in the changelog recording that fact seems to be de rigueur, and in fact as I understand matters the tooling recognizes and parses notes such as "Closes: #123456" or "CVE-1000-123-1234" to auto-close the given bug report or to mark a newly-packaged version as unaffected by the given CVE. For that matter, look at the Linux kernel packages (linux-image-VERSION-ARCH, among others). They don't seem to ship a changelog.Debian.gz, but the changelog.gz which they do ship seems to be in Debian changelog form and list Debian package versions, and is reported by apt-listchanges at upgrade time; in that file, each new Debian version tends to contain a "New upstream stable update" entry, which is then followed by a kernel changelog URL and a lengthy, detailed listing of changes (apparently nearly commit-level) taken from that upstream changelog. I'm not sure this is best practice, or that it would be a good thing for other packages to be doing en masse - but it's a large-scale example of including upstream changes in debian/changelog, and it certainly doesn't seem to be an unacceptable violation if something as core as the kernel packages have been doing it for so long and are still going that way. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 12:51, Joan Moreau wrote: > An additional question : I still do not understand why, if this is a > "source" package, the source (and the Makefile) does not get included > ? > > Am I missing something ? The .deb is not a source package. A .deb is a binary package. Earlier in this thread, you were linked to https://wiki.debian.org/Packaging/SourcePackage, which should define the term "source package" in detail and with clarity. Have you read through that page? In addition to that page, I do recommend that you take the time to read through at least https://mentors.debian.net/intro-maintainers and https://www.debian.org/doc/manuals/maint-guide/index.html, at length and in detail, before trying to proceed with package creation much further. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 12:26, Joan Moreau wrote: > Ok, I tried to put a Makefile that import all needed packages > dynamically (via "git clone" mostly) Sorry - accessing the network during compilation is (at least generally) prohibited. IIRC, it both is a violation of Debian policy, and may actually not work from the build environment on the servers. You need to arrange for the relevant code to already be present prior to the start of the compilation process. > You may check > https://github.com/grosjo/tomboy-reborn/blob/master/packages/tomboy-reborn_1.0.0-1_amd64.deb That's a .deb file, which is a binary package. We need to look at the updated source package, which is used for generating the binary package. Looking at https://github.com/grosjo/tomboy-reborn, and more specifically at https://github.com/grosjo/tomboy-reborn/blob/master/packages/Makefile, I see that you're cloning two git repositories. If the software in those repositories is already packaged for Debian, you need to find out which packages it's in, add them as build-dependencies (as defined in some of the documents you've previously been linked to), and adjust your project (possibly through flags in the Makefile or appropriate setup in debian/rules) to draw on the files installed by those packages. If the software in those repositories is not already packaged for Debian, then unless an exception is allowed for, you need to get it packaged - into separate packages, not into the one you're already working on - and then do the above. If compiling your project needs the code from these repositories, how does your IDE-based build normally pick up that code? I'd expect that the same process should work for a command-line build, but I'll admit that I'm not familiar with Lazarus. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 10:54, The Wanderer wrote: > In order for this to be included in Debian, the final package build > - after all testing and tweaking to make sure things work properly - > will need to take place on the Debian build-daemon servers (AKA the > buildds), with no user interaction whatsoever. To clarify this somewhat: After all the preparatory work is done to get your package ready for inclusion, what will happen is that a copy of your source package will be uploaded to the Debian servers. Those servers will then automatically initiate the package-build process. This process will need to compile your program from source, then build the binary package (that is, the .deb file) from the result. There is not, and cannot be, any human involvement in this sequence. At most, if any part of the build fails, a human can modify the source package and upload it to be tried again. As such, anything other than a fully-automated compilation and package-building process is not going to wind up being included in Debian. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 10:31, Joan Moreau wrote: > Hi > > The lazbuild is commented because this does not work properly from > console, one shall use lazarus IDE in order to compile the sources > properly, and according to its architecture. Can the IDE be triggered to do this from the command line, so that the process can work without interaction from the user? If not, then this cannot be used to compile a program for a Debian package. The package-build process must be able to start with the uncompiled sources (with no IDE or similar already open) and end up with the compiled program, with no user interaction at all, beyond single command-line invocation which starts the whole process. This basically always requires a command-line compilation method. In order for this to be included in Debian, the final package build - after all testing and tweaking to make sure things work properly - will need to take place on the Debian build-daemon servers (AKA the buildds), with no user interaction whatsoever. I would not be surprised if those servers don't have a graphical environment available, such that a graphical IDE may not even be able to launch. I really do think that what you'll probably need to do is figure out what's going wrong with the lazbuild result and fix it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-04 at 11:28, Boyuan Yang wrote: > In your case, I do not see any build system in your source code > repository. There is a built binary file but there's no script or > instructions describing how the built binary was generated. I have > absolutely no idea how you were building the Pascal source code into > binaries. My best guess is that you are using the building function > embedded in Lazarus IDE -- which is completely unacceptable since a > working build system should be fully automated and require no > graphical IDE tool to function well. For what it's worth, there appears to exist a tool called 'lazbuild', which is apparently supposed to be able to compile a program from the command line if passed the appropriate Lazarus project file. I find two different versions of it in Debian, both in the lcl-utils-2.0 package. Also, https://forum.lazarus.freepascal.org/index.php?topic=37272.0 involves people talking about how to build a Lazarus project from the command line; they appear to have gotten it working without the use of lazbuild in at least one case, but whether that's worth the effort I don't know. If that's viable, there may not be any need to add a separate build system, although there would still be a need to add appropriate how-to-build documentation and (of course) the necessary debian/rules glue to get it to be run at package-build time. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
On 2020-06-01 at 10:35, Paul Wise wrote: > On Mon, 2020-06-01 at 14:18 +, Vasyl Gello wrote: > >> So static libs present in packages like popt are remnants of the >> past and the general practice now is to discourage shipping all >> kinds of static libraries unless it is Go/OCaml… as mentioned in >> this wiki page? > > Right. That seems like a questionable decision. If I need to compile a program to run in an environment where I can't know what libraries / library versions are going to be available, or maybe even do know for a fact that certain ones will not be available, the obvious solution is to link it statically - but if Debian doesn't ship the static libraries, how exactly am I supposed to do that in Debian? Not linking programs statically by default is certainly a good idea, as is not shipping statically-linked programs in Debian packages without specific cause to do so (as cited on that Wiki page) - but not shipping static libraries just means that someone who *does* have a legitimate reason to use static linking in a particular case will have to compile the entire library stack necessary by hand, which seems like a suboptimal solution at best. Fortunately, there still seem to be thousands of packages which do ship static libraries, even excluding all packages whose names reference go or ocaml: $ apt-file -x search '\.a$' | cut -d ':' -f 1 | sort -u | grep -v '\bgo\b' | grep -v ocaml | wc -l 5524 If this "discourage shipping static libraries" policy is in fact in place, it seems to either be de-facto ignored in practice, or new enough that there are still lots of packages which haven't been affected. In fact, I don't see anything in that StaticLinking Wiki page which indicates that static libraries should not be shipped, and the relevant section of Debian Policy to which it links [1] states that "the static library is usually provided in addition to the shared library". Can you point me to a reference for the statement that it is now general practice to discourage shipping of static libraries (as distinct from statically-linked executables) in Debian packages? [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Advice on packaging new upstream releases.
On 2020-02-16 at 10:42, Inaki Malerba wrote: > Why should I include the non-minified version? For reading purposes? > Never thought of it but makes sense. As I understand it: for editing purposes. The principle is that the source package should include the form of the source which is preferred for making modifications to that source, or to put it more briefly, the "preferred form for modification". (Some people seem to say "of" instead of "for", but that doesn't really mean anything that would make sense in the context.) Otherwise, the recipient can't modify the source with the same facility as upstream can, whether for forking purposes (including just making a local modification to the package, without reference to any non-packaged code) or to create patches for submitting upstream. In the case of minified JS, it's a rare case in which someone prefers to edit a minified form rather than the less compact and more verbose form which gets passed through a minifier at build time, and even rarer for someone who doesn't prefer that to be willing to accept patches written against the minified form. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian source search by file name
On 2019-12-28 at 14:47, Tong Sun wrote:
> Hi,
>
> Is it possible to do Debian source search by file name?
>
> I wanted to see examples of overriding
> debian-watch-does-not-check-gpg-signature in
> debian/source/lintian-overrides files, so I did:
>
> https://codesearch.debian.net/search?q=path%3Adebian%2Fsources%2Flintian-overrides
> https://codesearch.debian.net/search?q=gpg+signature+path%3Adebian%2Fsources%2Flintian-overrides
>
> But none gave results I want. Both say:
>
> . . . had no results. Please read the FAQ to make sure your syntax is correct.
>
> I think my syntax is correct, right?
Try:
https://codesearch.debian.net/search?q=gpg-signature+path%3Adebian%2Fsource%2Flintian-overrides
which works for me right now.
The only differences I see between this and your second URL above are A:
the use of the correct path ("source" instead of "sources"), and B: the
use of 'gpg-signature' instead of 'gpg signature'.
If I drop the 'gpg-signature' part from this search term, I get the same
error you got. I'm guessing that that's because there's no actual search
term for *within* the file, and the search engine isn't going to report
the entire file; if I'm right, that would be the other reason the first
URL you gave doesn't find anything, aside from the path typo.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: RFS: impacket/0.9.15-5 [ITA]
On 2018-05-25 at 09:47, Adam Borowski wrote: > On Thu, May 24, 2018 at 09:48:23PM -0300, eamanu15 wrote: >> Package: sponsorship-requests >> Severity: normal > > This should be mailed to submit@bugs.d.o, not the mailing list. It > did not get a tracking bug this way, thus those who use the BTS as > their primary view wouldn't notice it. Actually, the original mail as I received it *did* have s@b.d.o in the To: list; it just also had the mailing list's address present explicitly. How the software which normally results in a RFS bug getting passed on to this mailing list handles that situation I'm not sure. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Help to clarify an issue
On 2018-01-01 at 10:39, Mattia Rizzolo wrote: > On Mon, Jan 01, 2018 at 01:30:16PM -0200, Herbert Fortes wrote: > >> The package is orphan now and what it is seems as best can be done >> by who wants to do the job. > > So your argument is "the package is not developed anymore (?) and > was always like that, so let's not touch it too much"? I parsed his statement as meaning "Okay, since my opinion as maintainer of this package isn't being accepted, I'm declaring the package orphaned; now anyone who wants to work on it can do so". I mean, I hope I'm wrong, because orphaning would be a drastic and unfortunate outcome from this - but that's how I interpret it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Help to clarify an issue
On 2018-01-01 at 05:48, Herbert Fortes wrote: > >> Well said, I agree 100%. >> >> I consider both parties to be wrong here: >> * Jonathan went very hasty on the NMU >> * Herbert refuses a patch for a quite annoying thing, fixing which requires >> no effort on his side (as the submitter did all the work), without >> providing any rationale >> >> It's a clear bug to me: the package behaves in a different way based on >> whether an unrelated doodad (some X stuff) is installed or not. That breaks >> people's muscle memory, requiring user's effort for every single machine the >> package is installed on -- or, on every invocation, thinking "is this shell >> on a GUI machine?". And I for one ssh to my home desktop a lot. >> >> "because one does not want to press tab" is a ridiculous explanation. >> >> Thus, Herbert: could you please tell us if you have any reason to reject the >> fix, other than being annoyed with a NMU done in a wrong way? > > It seems more ridiculous to me do not want to use an alias. Adding an alias locally only fixes the problem locally, for one machine, or even one person on one machine. (And - as mentioned in the bug comments - if you're trying to share the same bashrc across multiple machines, some of which have only duc and some of which have duc-nox, a simple alias definition will not suffice; you'd need to write conditional logic to determine which alias to define.) Diverting the installed binary to a non-conflicting name and defining an alternative locally would avoid the latter problem, but it seems fragile, and again only fixes the problem for one machine. Defining an alternative in the package, or (less optimally) having both packages provide the same binary name with appropriate Conflicts:, fixes the problem for everyone who uses the package - with relatively minimal effort, and as far as I can see, zero undesirable side effects. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
On 2017-12-24 at 07:02, Albert van der Horst wrote: > Geert Stappers schreef op 2017-12-22 10:18: >> Control: owner -1 ! >>> Also, is this the real source (AKA, "preferred form for >>> modification")? Assembler is a valid language, generated >>> assembler (nor generated shell, generated C, ...) is not. Some >>> parts say about a configuration process that, as it seems to me, >>> expands variables for a particular platform. >> >> >> ; If this is a configured assembly file, it should be accompanied with >> configured >> ; documentation (texinfo, ps, html.) >> ; WITHOUT THE DOCUMENTATION: GIVE UP! GET THE REAL THING! >> ; You have a configured system, if there are NO curly brackets on the next >> line. >> ; >> ; >> ; Configuration of this particular version: >> ; 32-bits protected mode >> ; running under Linux ; with native forth I/O >> >> >> >> So yes, I have the feeling that I'm dealing with generated assembly. >> >> The .orig.tar.gz does have ci86.lina.fas >> I wonder what generated it and from what. >> >> @Albert: Would you please elaborate? > > I appreciate and understand what "prefered form of modification is". > I also understand that Debian must thread carefully here, and not > accept packages that bend the rules. This package certainly doesn't > not go against the spirit of the rules and may only superficially > seem not to obey the letter of the law. This has been discussed > already to some extent. > > There is a choice of assemblers . I've a kind of generic assembler > code, (that is not assembler code that could be assembled by any > assembler) and then an m4 script that transforms it to either fasm, > .s nasm or even tasm or masm format. > > This is *not* generated assembler. The assembler is a genuine > source. There is only a limited processing between equivalent forms, > to present a readable and modifiable source to some one inclined to > modify lina. Although I do not in any sense speak for Debian, my understanding is that the key question is: When the upstream is modifying the code, does the upstream edit the code at hand directly, or does the upstream edit something else and transform the result into the code at hand? If you write code in one form, then programmatically transform it into another form (which is compiled or run by a different tool), but never voluntarily directly edit the second form, the second form is not considered "the preferred form for modification" according to Debian's definitions. Rather, the first form is considered the "source" of the second form. > There is a one to one correspondance between a line with an > assembler instruction in lina.fas lina.s lina.asm lina.nasm and the > preconfiguration system, and they all correspond to the same binary > code. > > The base system also contains code for MS-windows and MSDOS or even > stand alone. This is removed by m4 to present a proper Linux source. > Nothing is gained by drawing all this linux foreign code into a > Debian package, merely to remove it. The more so as this system is > available and GPL-ed in its own right to be used by anybody > interested in e.g. an UEFI system booting directly into Forth. > > Likewise there is also base documentation with an m4 provision to > remove all the MS related documentation for a Linux texinfo file. I > wanted to avoid the situation with the gnu assembler where almost all > options are irrelevant for the processor one is currently working > with. > > So in short it is a matter of configuration and selection, not > generation. From what you describe, it sounds to me as if the preferred form for modification is that "generic assembler code", and people writing patches to send upstream should probably write them against that form of the code. Even if that's not strictly necessary (if, e.g., you're happy to accept patches against the processed-into-a-specific-assembly-language code and have your m4 script convert the patched form back into your generic assembler code so that you can apply the result to your repositories), as long as the form of the code which you actually edit is not the one which you ship, the one you ship is not the preferred form for modification. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Broken pbuilder process
On 2017-12-16 at 07:52, Sascha Manns wrote: > Hello list, > > currently i'm trying to use 'sudo pbuilder build foo.dsc' for checking > the package inside a chroot. > > Sadly it breaks the build with that issue: > > dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in > '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'. > dpkg-deb: error: failed to make temporary file (control member): No > such file or directory > [0;31mE: pbuilder-satisfydepends failed.[0m > > Does anyone know why it breaks? This looks like the same error as in bugs 576425, 725434, and 823651. If I'm reading those bugs correctly, if $TMPDIR and/or $TEMP in the environment where you invoke pbuilder points to a directory which does not exist within the pbuilder chroot, you get this error. Apparently the issue is most commonly caused by having libpam-tmpdir installed. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#856652: RFS: xpdf/3.0.4.real-4
On 2017-03-08 at 07:59, Svante Signell wrote: > On Wed, 2017-03-08 at 07:41 -0500, The Wanderer wrote: > >> On 2017-03-08 at 00:55, Svante Signell wrote: >>> I still don't get it. The proposed package _doesn't_ depend on >>> poppler any more. If you have problems with previous >>> xpdf+poppler versions up to 3.04-4, remove these from the archive >>> then! >> >> What about all the packages which depend on poppler and _aren't_ >> xpdf? > > I did not propose to remove all libpoppler-based packages. I meant > the xpdf versions depending on libpoppler. Then the objection that Moritz stated remains: it will still be necessary to 'fix all security issues affecting poppler/xpdf twice instead of just once', because the code will exist in the archive in two places: in the xpdf package, and in the library package. The only ways to avoid this that I can see would be to remove the libpoppler packages (and thus the packages based on them), or to demonstrate - to the satisfaction of the security team - that the two codebases are so far apart that to speak about one single security issue affecting both is not meaningful. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#856652: RFS: xpdf/3.0.4.real-4
On 2017-03-08 at 00:55, Svante Signell wrote: > On Tue, 2017-03-07 at 22:43 +0100, Moritz Muehlenhoff wrote: > >> On Tue, Mar 07, 2017 at 08:17:08AM +0100, Svante Signell wrote: >> >>> I don't see where your concerns regarding security are, please >>> explain. >> >> Your package can't enter the archive since this would require to >> fix all security issues in poppler/xpdf twice instead of just once >> in the library package. > > I still don't get it. The proposed package _doesn't_ depend on > poppler any more. If you have problems with previous xpdf+poppler > versions up to 3.04-4, remove these from the archive then! What about all the packages which depend on poppler and _aren't_ xpdf? There are enough *poppler* packages that it's not entirely trivial to come up with a list, but to pick libpoppler64 as an example: $ apt-cache rdepends libpoppler64 | grep -v poppler Reverse Depends: xpdf texworks texlive-binaries boomaga pdf2htmlex pdf2djvu libreoffice-pdfimport pdftoipe inkscape libgdcm-tools libgdal20 gambas3-gb-pdf extractpdfmark elpa-pdf-tools-server cups-filters-core-drivers cups-filters karbon and reviewing those packages with 'apt-cache show' confirms that all of these are Depends, not Recommends. Do we really want to remove all of these packages from the archive, just to be able to track xpdf upstream directly (or even to retain xpdf)? For some of them, whose PDF support isn't integral to the package's functionality, it might be possible to just rebuild without the poppler dependency (with the presumably-undesirable side effect of losing the PDF support) - but for others, such as the PDF-converter tools, that almost certainly isn't an option. For the latter, the only solution I see that doesn't involve retaining poppler in the archive would be to include a copy of the relevant code in the depending package itself - and, according to my understanding from earlier in this thread, that is exactly what libpoppler was created to avoid. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#856652: RFS: xpdf/3.0.4.real-4
On 2017-03-07 at 08:12, Svante Signell wrote: > On Tue, 2017-03-07 at 06:49 -0500, The Wanderer wrote: > >> On 2017-03-04 at 14:19, Svante Signell wrote: > ... >>> Maybe I don't understand. The version of xpdf I'm proposing is no >>> longer dependent on poppler. So why are you talking about >>> poppler? >> >> Because other packages do still depend on poppler, so we can't >> drop poppler from the repositories, which means that introducing >> the code back into the xpdf package itself will mean we have two >> (divergent) copies of that code - with all the problems that >> implies. > > Sorry, I still don't get it: - Which packages still depend on > poppler, unless via xpdf? The ones directly dependant on poppler are > not affected. Yes, they are; if a newly-discovered bug which exists in both codebases is fixed in xpdf but not in poppler, those packages will still be affected by the bug. Thus, introducing non-poppler-based xpdf back into the archive means any such bugs will have to be fixed in two places rather than in one; this is the downside which I understand to be part of the objection, and part of the reason for splitting out the poppler code into separate packages in the first place. Unless you're saying that the divergence between poppler and upstream xpdf is so extreme that talking about the same bug existing in both codebases is not meaningful - in which case this objection disappears entirely, and I apologize for the false trail. > - Which repositories containing poppler code are you talking about? The Debian repositories which contain the packages found by 'apt-cache search poppler'. (Thinking about it now, I think the term "archive" might be more usual than "repositories" for the meaning I intended.) > - Which code has to be brought back to the xpdf package, causing > problems? Isn't it enough to bump the upstream version and go on from > there, as Adam suggested? The code which is in the upstream version but which has been split out of the Debian version into the poppler packages. Reverting xpdf to the upstream codebase, rather than basing it on poppler, brings this code back in implicitly. > - I did a search for reverse dependencies for xpdf (there are no > build-rdeps) > apt-cache rdepends xpdf > > xpdf-dbgsym : obvious > libfontconfig1 : Breaks: xpdf (<= 3.03-11) > valentina : Depends: ..., xpdf, ... Did you build this list manually, or is this actual output of the above command? Because the output I get from 'apt-cache rdepends' is of a very different format, and one which might well be considered less useful. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#856652: RFS: xpdf/3.0.4.real-4
On 2017-03-04 at 14:19, Svante Signell wrote: > On Sat, 2017-03-04 at 11:49 -0700, Sean Whitton wrote: > >> Dear Svante, >> >> I agree with you that a poppler-based xpdf is not maintainable >> until and unless xpdf upstream switches to poppler. However, it is >> not clear to me why we shouldn't just remove xpdf from Debian. The >> main reason that Debian insists on using shared libraries instead >> of bundled copies of code is because it permits faster responses >> to security problems uncovered in those shared libraries. A >> security bug in poppler would now need to be fixed in xpdf's copy >> and in the main library. > > Maybe I don't understand. The version of xpdf I'm proposing is no > longer dependent on poppler. So why are you talking about poppler? Because other packages do still depend on poppler, so we can't drop poppler from the repositories, which means that introducing the code back into the xpdf package itself will mean we have two (divergent) copies of that code - with all the problems that implies. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Packaging a gui app
On 2017-02-26 at 10:47, Ghislain Vaillant wrote: > On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote: > >> I am packaging a gui that has dependencies for qt and such. How do >> I go about ensuring that X is available as well? Do I list that as >> a dependency as well. The upstream maintainers don’t call it out >> specifically but it is understood. Links to docs are always >> welcome. > > Usually, the toolkit your application depends on (here Qt), will > bring the necessary dependencies for you. So you don't need to care > about X. I recall that historically the rule was "you don't depend on having X packages installed" regardless, on the grounds that it is or was possible to connect to an X instance running on a different machine (it is called "the X server", after all) - but I don't spot that in current policy, and I do seem to remember reading discussion about repealing that rule on the grounds that doing this hasn't actually _worked_ in modern X for years if not longer. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#845018: RFS: quagga/1.1.0-1 [ITA] -- network routing daemons
On 2016-11-21 at 07:56, Vincent Bernat wrote: > ❦ 21 novembre 2016 23:39 +1100, Scott Leggett : >> I'm open to accepting patches / co-maintainership from anyone who >> wishes to test and use traditional init scripts with quagga. Given >> the longevity of bugs like #678946, I'm not optimistic of such >> patches materialising. >> >> I personally cannot test such init scripts since all my systems now >> use systemd, and I can't in good faith include code that I can't >> test and which has known bugs. (That's an interesting usage; I would have used "good conscience". I'll have to keep an eye out for this one.) >> If there is another approach you think I could take here, please >> advise... > > People who want other people to keep init scripts alive are asking > to just leave them be, even if they are buggy. That's not something I > agree with, so I am happy that you just removed them. But you could > get some opposition. My own position is roughly that init scripts should be left in place unless the maintainer sincerely believes that they are not just buggy, but so badly broken that either they provide no functionality at all, or to have the functionality which they provide is _worse_ than to not have it. In other words: do you, as the package maintainer, believe that a reasonable person would prefer having no init-system functionality for this package at all over having what these init scripts provide? I'm not going to fight on this strongly, at least (and, in any case, particularly) not for packages which I don't actively use myself, but I think that's the baseline pro-retain-unmaintained-init-scripts position. In the long run I may very well start looking at packages with unmaintained init scripts (is there any straightforward way to readily identify such?) with an eye towards improving them, but I don't anticipate having the spare capacity for that any time soon. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#833621: RFS: libgap-sage/4.8.3+ds-1 [ITP] -- GAP kernel as a C shared library
On 2016-08-09 at 04:36, Mattia Rizzolo wrote: > control: tag -1 moreinfo > control: owner -1 ! > > On Sun, Aug 07, 2016 at 02:49:38AM +0100, Jerome Benoit wrote: >> [1] https://anonscm.debian.org/cgit/debian-science/packages/libgap-sage.git > > d/*.lintian-overrides + d/*.README.Debian: > you use the word 'furnished', which really means "providing > forniture" (or "provided with forniture"), afaik. I'm positive Debian > doesn't ship forniture :D > I think you meant 'provided' there. Actually, this is valid. The first definition of "furnish" from the dict-gcide package is: 1. To supply with anything necessary, useful, or appropriate; to provide; to equip; to fit out, or fit up; to adorn; as, to furnish a family with provisions; to furnish one with arms for defense; to furnish a Cable; to furnish the mind with ideas; to furnish one with knowledge or principles; to furnish an expedition or enterprise, a room or a house. See also e.g. http://www.thefreedictionary.com/furnish for online-dictionary definitions. Although the sense related to providing furniture for a room is the more common usage nowadays, it is in fact secondary to the sense related to providing anything with "anything necessary, useful, or appropriate". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Request service reload after package install
On 2016-03-22 at 09:28, Gianfranco Costamagna wrote: > Hi, do the post* files in virtualbox-ext-pack package help? they have > some user interaction, and restart of services IIRC. Restarting services after package installation is relatively common, and can be seen in the postinst files of many packages. The one which I most often see, as a prompt with a list of services to be restarted, is libc6. However, as far as I'm aware, all of them have one flaw in common: if you install multiple packages which require restart of the same service (including, e.g., multiple architectures' versions of the same package; this happens with libc6 on a multiarch system), the service will be restarted multiple times - once per package. Giulio specifically cited having only one service restart per "session" as one of his goals. I don't know of any way to avoid or work around this multiple-restart behavior which would be clean and robust enough to be worth implementing, except for adding support for this sort of state handling to the tools which do the installation - apt and dpkg, probably in an interlocking way. Unfortunately, I don't know of a good design for this, and I infer from the fact that it's never been done that no one else has come up with one either. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#818048: RFS: osmose-emulator/0.9.96-1 [ITP] -- Sega Master System and Game Gear console emulator
On 2016-03-12 at 22:23, Carlos Donizete Froes wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "osmose-emulator" From what I've seen, every RFS mail for this package which comes through debian-mentors has an attached screenshot of the program in action - specifically, of it displaying the title screen of Phantasy Star. This latest one has two of them. Is there any reason why this attachment is included? It's not done for any other package which I know of, and so far as I recall, I have not seen an explanation presented as to why it's being done in this case. If there's a need for it, it's fine, but at a glance it doesn't seem to do anything more than unnecessarily inflate the size of the RFS mail... -- The Wanderer suspects he may regret asking The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: not installed and installed , where they store?
On 05/10/2015 at 04:53 AM, Mohsen Pahlevanzadeh wrote: > On 05/10/2015 09:14 AM, Johannes Schauer wrote: > >> Hi, >> >> Quoting Mohsen Pahlevanzadeh (2015-05-10 05:53:17) >> >>> When i use : grep ^Status: /var/lib/dpkg/status , Unfortunately , >>> i only get "Status: install ok installed" >> >> how sure are you of that? Did you just look at the first few >> hundred or did you really find all unique values? Try: >> >> grep ^Status: /var/lib/dpkg/status | sort | uniq -c >> >> cheers, josch > > It's very interseting : > / > I did : > root@debian:/home/mohsen# grep ^Status: /var/lib/dpkg/status | sort | uniq -c > 1 Status: install ok config-files > 2803 Status: install ok installed > For comparison, I get> $ grep ^Status: /var/lib/dpkg/status | sort | uniq -c 479 Status: deinstall ok config-files 2 Status: hold ok installed 3604 Status: install ok installed > But : > > /// > root@debian:/home/mohsen# dpkg -l virtualbox* > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---= > un virtualbox (no description available) > ii virtualbox-4.3 4.3.22-98236 amd64Oracle VM VirtualBox > un virtualbox-gue (no description available) > un virtualbox-ose (no description available) > Yes, this makes sense. The logic as I understand it is that 'dpkg -l' effectively starts out by assuming that everything is in status "un", and overrides that for every package which is listed in /var/lib/dpkg/status. If that weren't true, then it would be necessary for your system to keep a list of _all available packages_ in /var/lib/dpkg/status - and since packages can come from multiple sources, there is no possible way (short of being omniscient) to compile a list of all available packages, much less keep it up to date every time someone in the world makes a new package version. If you've never installed a package, or if it has been fully purged and has (or should have) no remnants remaining on the system, then it will not be included in /var/lib/dpkg/status - and 'dpkg -l' will report status "un". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Help with Java package needed
On 04/27/2015 at 10:36 AM, Andreas Tille wrote: > Hi Markus, > > On Mon, Apr 27, 2015 at 02:13:15PM +0200, Markus Koschany wrote: >> >> In the end you have to replace all embedded jar files. > > Yes, I understood this (if the package should go into main). > > BTW, formerly the file > >http://ftp-master.debian.org/users/twerner/jar-content.txt.gz > > was very helpful to seek for existing JARs in Debian but this is not > updated since 23-Oct-2014 03:51. Is there any reason for this? Any > hints how to replace the other remaining JARs? I'm not remotely a Debian-packaging expert, and am only peripherally familiar with Java, so this may be on entirely the wrong track. That said, if all you want is a list of JAR files in Debian packages, that can be obtained from apt-file -x search '\.jar$' on a system with an up-to-date apt-file index. Based on that: > goose.jar: I think I need to do my own research about this which > seems related to > https://github.com/dtenenbaum/Cereopsis > but not the same > > jsc.jar: If my investigations are correct this is obtained from here > http://www.jsc.nildram.co.uk/downloads/download.html > and has a "Free for non-commercial use." anyway. So my > attempt to get mauve into main might be irrealistic anyway. > I'll ask upstream whether this "still under construction" > library from 2005 is really needed or whether some > replacement might be possible. > > Any hint for alternatives to "Java Statistical Classes" > is more than welcome. These two don't appear to be in Debian, or at least not in current testing. > unix-0.5.jar: This seems to come from > https://github.com/cathive/dbus-java > but I'm not sure. Could anybody please confirm that this > needs to be packaged or whether I'm missing something It may or may not be the same thing, but a file with this name is available in the libunixsocket-java package. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Separate gpg signing from package building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/14/2014 12:56 AM, Paul Wise wrote: > On Mon, Jul 14, 2014 at 12:31 PM, The Wanderer wrote: >> I don't remember reading an explanation of how to do this in the >> New Maintainers' Guide or similar documentation, and I don't see an >> obvious way in the man pages I know to check first off. Is it >> possible? > > As I said in my previous mail: > > The dpkg-buildpackage manual page documents that you should pass -us > to not sign the dsc and -uc to not sign the changes file. The debuild > manual page documents that the contents of the > DEBUILD_DPKG_BUILDPACKAGE_OPTS config option are passed to > dpkg-buildpackage. That explains how to build without signing, but not how to sign after building (which you have now done). > In addition the debuild manual page mentions debsign, which can be > used to sign or re-sign .dsc/.changes files. Fair enough. That does ring a faint bell as something I'd run across before; I just hadn't bothered to re-research this before posting, as I was in "clarify what I understood the question to be" mode. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTw8S1AAoJEASpNY00KDJrvgQQAIDQGPVDW+eiT6T5oagyTMUh LCV43X1jiEJ/Pd65qsmuI3EE67D85CCORb/KpIn7gmIartF3BHCjVnJf2ADNO8Ou FkWjzkQBt0OkYS8drNL9BkOYBjX93uVHaJedUQrBdOd8NjoBu8Vw0Xf+G+nOL5L2 haYu0mVppZ+oj7A4Z71xmew8VkJc6v6SxvfpHeVZC2baqvEjDu7sKRd9XyZgsdxu qlfQ8u2Hf5iuutMT+7ov1rQMLBZr1ejke+ohuSlcBCKB3DMrLDjjoSbBg2DFBUAL I3j6HG5SlzaqaHyRQDvFZ/plqEQoViFme89Yj3vRre3O1NAkr4El4CyyU0FE4apo KeIAfT+2EartabaChoFUq1uKCYgROBNSEDuuxapmzw8FCvFcupazSt3yN46OSs7N YOmPXTfX9ioZzPQrGrIbGpdO8ijq7aYhE+fBz3TUiav8FdEqLVP+P6kn7mt8qnef 8Y+xn39BNojcBOt0+MiVG8Qs+/6Fi88qPCbMAv1lPOwbhZsPFPQrb6ph0zEqgx5Q kB83JueXYGeGKCHDECugT8/l5th9EfM20uu7KU/aT43HptrW4j+JU1sH3HY96OeG sOVsnR6DPe3xEgGQ2mSH7ys9F19pLUMshxuv4gr/OhOYb3vbHGy2yu9vmfGZedMe 9236ALL+OBVaVz2nXoAy =AOrs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c3c4b5.8040...@fastmail.fm
Re: Separate gpg signing from package building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/14/2014 12:26 AM, Paul Wise wrote: > On Mon, Jul 14, 2014 at 11:59 AM, T o n g wrote: >> Now I'm thinking, wouldn't it be nice I always build the package >> without gpg signing, and when finally I tested everything working >> fine, I sign it. Would it be possible? Detailed steps (instead of a >> mere yes) appreciated. > > The dpkg-buildpackage manual page documents that you should pass -us > to not sign the dsc and -uc to not sign the changes file. The debuild > manual page documents that the contents of the > DEBUILD_DPKG_BUILDPACKAGE_OPTS config option are passed to > dpkg-buildpackage. So you just need to put this line in ~/.devscripts > and use debuild instead of dpkg-buildpackage: > > export DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc" > > IIRC the maint-guide mentions this stuff, have you read it? I could be wrong, but I understood the question as being not how to build without signing, but how to sign after building, without having to rebuild. I.e., always build without signing, then sign as a separate step once a build has proved satisfactory. I don't remember reading an explanation of how to do this in the New Maintainers' Guide or similar documentation, and I don't see an obvious way in the man pages I know to check first off. Is it possible? - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTw10KAAoJEASpNY00KDJrfWoQAKh+nxYPl5N57dtIB9YEiK3g Hub1hKYZwHD/dxgv1Y3eqWVZP4C4gVlAlVPJaztbniCWsV9ITZJy4c9vvs46nJhU FFfd1cwVCUl/fJ6DjE8BSo5+PmxBXCWiHX8pDcrUsfDjNNBSV1fkULqQJA/aFTK9 cCo4DSPMae8RWzL9OnJqz9dnZRzOWXlfZamsmWf3aj5oPvJHLZ03+SNR9OmXdCbC aUbQpeexMiVwR5mRXpghIp7dYBa0G6LALeX2POjDFc39XtDdycizA5O9//TsxVNA eMnejO6SV0Hcl6JwdaJrZWBbK15Vt+EF23YGG1Ywmb4pvEZ/333jHP/30ySG2rZc 2f48hlpoF9qaaksFhU24OIf/7zwkGnZ4dnvTTxpuofMs+DMJB+zH7P716lfVBx4b 4gtUiBiYrlwHtOvfB3Kv143nVwZ+K269MhAIKoSIILPxTE1xWD+muS8F3bn36dik as4o7kBzhQ0OdBpCPpKdkx5LC/RUBqK15zAwPdKyfzZmn+MDtW/oA/zRYtHf39gc Z77iVLT4aXd9aPXcuAG6AhOQbl0mjNaM7AHTebHIn3zQYDLxmKdbTXML2rhHWnod OfFm2t/Ahy2POQhduQOhVSpWHS8MShZcN6c0HSTheAsYcQZUzXZtsmH64a5qdb5E pxlg1cjSSqwgH60EifU4 =5n1y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c35d0a.5000...@fastmail.fm
Bug#751048: marked as done (RFS: fizsh/1.0.6-1 (already in Debian))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/16/2014 12:42 PM, Axel Beckert wrote: > Control: reopen -1 > > Dear Bart, > > Debian Bug Tracking System wrote: >> Package fizsh has been removed from mentors. > > since when is this a reason to close RFS bug reports? > > Reopening! I believe the idea is that if the package is not (any longer) in mentors, there is nothing left to sponsor, so the RFS bug is obsolete. If something new comes along to be sponsored later on, according to my understanding of the logic, a new RFS bug should be filed. I could easily be entirely off-base about that, of course, and I agree that the phrasing in these (semi-automated?) closure messages is kind of confusing; it took me a few weeks seeing them come through the mentors list before I figured out what was probably going on. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTn6hGAAoJEASpNY00KDJrqJ8QAIT2MPWHQ+1wKCsTrROi8jEf Jk5IqDhq3nrhcFNXNkdiOFS3xcQSC8eeXRfV8Yi/WxnC/8GZ+Njst7av3DR+wtTB lxVOBaq/s6Q82KwkIpdcnJlPhPmDG6nkQiiuIPkuIprRuvzpoe3ytSr7ucA+20ua BBD8vJX8WRlVbyPvOZmsYwsaKwLMZp8rvmiDOBD5a6AVUbTmNE2eBxny3KcXNCjF BVSp4kzKPqVzeTHvJv8dgd/e+ADzXRwK8Pn2BBVknFS5snrxzYN8K6KWG6oKt/w+ Qug/G46eOwMgcSDpCf3M6EKsjs/MwqcKGzuOlu06yljq/swMcVuRRwKN6vS6uOXA U7h/QrPhvaJ5RxV4moRpA+CQWU70btGVPoplreYK9wsaCHV4ApuUioR6lXZx32w1 yJot9k8IewLJRRBUAUrb2OI19TrN/2BiluyiObBBHGhQ6B+SOrwGYBE4JTsmXaYC JjMxqeR07gSw0fxNLH5qDADRYqNvQPme0wJEf3VgH1umBGLLdwFviDC9vEpQlohD AZJ5Ef2tEAAQ6c+Hl+CljY+QOaE+7QZBzbcTHaEXNSFDJPbFVDM6EKbn/DGS/4d9 WPl+kWC+93NalkIwgI6zaSwoWTf96VlEg6kB8slEyXFf2VIHEy4rNyatTuOxWFmt +uYpkuh4eD3cmB4glYne =fNjx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539fa846.9040...@fastmail.fm
Re: What do you do when your sid development system stops working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/12/2014 09:20 AM, Jérémy Lal wrote: > Le lundi 12 mai 2014 à 08:13 -0500, Paul Elliott a écrit : >> Below is the long list of debs that were installed. do any strike >> people as suspicious? i.e. the one to check first? Thank You. > > This is the culprit: > > libllvm3.4:i386 (3.4-2, 3.4.1-1) > > you just have to downgrade it. There has to be more to the situation than that, though - because I have libllvm 3.4.2 installed (both amd64 and i386), and just yesterday not only successfully booted but replaced a hard drive in the RAID array on which several of my LVM partitions are based. Do you know under what circumstances libllvm 3.4-2 is known to be a problem? - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTcMwhAAoJEASpNY00KDJrRdgP/3L0QWGo9Wim8t3DwyWxHqcg DCuz+I0YlDI/q2Pb+ajzp4PWDUBfYoAYZD0TLEdssdJpgb8IQzy57JKszS3x5/8l B96W+g5GGnFtvc+TTJOEgS9v5XgwlLOKCaRawwzZwJ9ogUkQBAM/gmfj0ppnQlZu oHx1VNRm3rlCQI+7vRJgGomZ2yR2QIS8aiB3v3Ngh/t3spkbW6V+menLt2LPPkwQ Y5X7ehhLUiGrfqYZzTJ8cEJ7enVl+ETR+f53h4uuKIblJmgD475GNSUMVfT+khJp jTfSUxbjr901Sc9WedtJpMkjOpmaf+acpqTZzsagbsV5z73DKujc9+SeBIBUAGJJ 50xGkx9yWfEv3EltwZkOgCztJWAW04bAoYcdDHP+xTNRg5GpOCd/Sqm1tzphOOPs uA4nmh7mpMaftNAjTqwsEriO0KJQVR8WKNOmB/YE78ts7GrnTQqkhotfSRRS1DJo za2AgwXs/SDoW/hze0PLnv0VMJjezKelz/6wMnXRRszfPmrnuQWtHxz0t/E0unJI 0/ZXSd/pedrzSdPGb4U6r43xinnIGEB2XwJpMiRg/zhuVPC/Ezex6VSriAUn49sc ldKfyvlt+6w71VmFGMlX5rmNeDoGdtsfnTC2MnNXRqR/vW87COy1IVaalW2kSDE0 C8iISX5dJpOBa42dunuM =8PBG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5370cc21.1060...@fastmail.fm
Re: [help] volview: FTBFS: vtkKWWizard.cxx:162:51: error: 'Tcl_Interp' has no member named 'result'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/15/2014 04:07 PM, Andreas Tille wrote: > Hi, > > is there any kind C++ capable soul who could provide a patch for this > problem? A bit of Googling seems to indicate that this is due to building against Tcl 8.6: https://bugzilla.redhat.com/show_bug.cgi?id=902561 As a short-term thing, you can probably get it working by either adding - -DUSE_INTERP_RESULT to the CPPFLAGS at build time, or patching some appropriate internal header to include the same define - or possibly by explicitly build-depending on tcl8.5-dev, though I don't know enough about Tcl or its packaging to speak to that approach. In the long term, as the link indicates, the correct fix would involve modifying the source to avoid using internal fields from Tcl_Interp. However, that seems like the sort of thing that would be best done by upstream. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTTZZdAAoJEASpNY00KDJrFMwP/1RPRb8PkbiNmRuegI8aT63b yrt3s+iKF8fAC9XsPpYI+J5I7VlnEz97B4Rf1/vBYx2R/HBjJE7FxSAJiPUoKz0J Eqgo0evIaVKdOFFLydAPbbEz9jswyZRDtXCYwBD1gXNjTMayOvZ/X2TLmvlPTOCD BJChOuA57lIUPsXfvaacQPQeu2rqX0WOrHp9NEZMaPRU3j5w1nHKKzgkYaDgYTii gWMaWaO1WStGTw++N6pKKLeFBHTIgJ2oKr/pX7HtmQwS3TXDZFL0PGT/ixxghut5 o+0+cwRdlVTOdZIhU2c5ALFvb7Jbmq7SPkoA66HxhR5pV9Ds3Cj0dQrclpUpw2jv /HvPYw9y1Q1YLMHCjOz1xLSYf6HPSZmMLb/xmSwkdjdhorcoK/dqsmZQrlvBxpdM 0ZCBXvyxUcmPbwjz9wYqd3wO7hjdnujhlFf5Hyt0CJ+/27Iuo4Bwe5u5SOatDpuy LmKnEtp9tllqgEvwMZt+HjX44auL02TxDoX9mkfh/wXOg5t3i0G4oIDvL2lzMduT iA+OQjPtAEJcgwkiQZdm1KZicvKX/7ftOSaBlNybWXw0wLciU+cD8yXanHGc3nQ+ J8zFpPOFo18LYcCas8TnvsaNTci5pUI2vLtjGJ8DFK+4A6YU9Xn1UPBmEyrhnNyV bXwaasScwv3qGuIwdKkU =xeha -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534d965d.7030...@fastmail.fm
Bug#737208: RFS: linuxlogo/5.11-4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2014 02:46 AM, Dariusz Dwornikowski wrote: > I do not want to close old bugs. Just asking, what will happen with > bugs for older versions that e.g. are not used anywhere no more? Will > these bugs hang forever or is there a cleaning policy ? Whether to close a bug has, AFAIK, nothing to do with whether the version it was reported against is still in use. It's entirely about whether the bug exists in current packaged versions. If the bug is still valid - meaning, mostly, if the behavior described in the bug A: is in fact considered a bug and B: still exists in the current version - the bug should remain open, even if that means remaining open forever. If the behavior described in the bug no longer exists in the current version, but for some reason the bug wasn't closed when the fix was first released, then I'd imagine that the bug should be closed manually (with a comment explaining that the bug is know to be fixed as of such-and-such a version). In the specific case of the bug you tried to close (twice) in the changelog which led to this subthread discussion, the correct thing to do is not clear at a glance. This is because you gave two different explanations of why you were closing it, and the two explanations disagree with one another. One explanation was "upstream won't fix". This seems to imply that the behavior described does still exist in the current packaged version, and that upstream has refused to change it. I believe that would be handled one of two ways: * Decide that the behavior described isn't really a bug after all, and close the bug report. * Decide that the behavior is a bug, and leave the bug report open to reflect the fact that the behavior still exists in the current packaged version. The other explanation was "not relevant anymore". This seems to imply that the behavior described no longer exists in the current packaged version, but that for some reason the bug wasn't closed when the change actually occurred. I think that in that case, the correct thing to do would be to close the bug report manually (not via a changelog entry), with a comment explaining that the bug is known to have been fixed sometime before version Such-and-such. I'm not an expert on these matters, however. I hope that helps. (And that I haven't gotten anything wrong anywhere.) - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS9Y2HAAoJEASpNY00KDJr1yoP/AxDl1Xxx97kIL2QyDsoRUQ3 lhHWR2cZFmFtiUbdRpKRwzwcUj2IU2IUtphP+30y6EzI82YYXkrKJvYHEBt6kMWg tW68HYhA9lXEtPEq/QMP4tkfEhTAoDg5WaDUK2aG0TmAOq0+UK5sC+xrM24YdTxu 8BcqDki12nFH51RKzdG2lhhvkGmKPQmL6T4/jB8xCasCPWGlgu4ZGjdtDTRLbrXn FgVfIBigDmvSn9yEZrlvJiSReE3Prv8CzUi3vSg6UvNMRfQoGkj1sA8/+X++AoMW twS2Gyj0YqN3QSk/m+/LUo7Ft4DTOZCtpa4ffOHYNl9C/6VsbWO67VN/RbsWhWmM vaFPGHf98THd6gGiFAYvLGjpzUZ8bmvxhBApgx0/9l1wx1VjHRdnd6TsemAuvUVy /Wph8wpu0xvxCtE+TLRRoLDoRERpKZbvafrLPm07VcBuXr3uDWHv6ZOEY3CwI0WG bp/+/4mCE27wP6ji01BuIzqItQ4pJVaRQ4eqRW3mGcSwCU3r3Tb0om7zTrYocfxG b2xK8SWPbJzbW4GlKvSkt7nF/fxVBp4y40b71qPicx0UDK/R4fEVzmS/Otn9LXtS PLSMLa+3VXXCCDTwSEG8yuDJA+c8aA2ARh/+uR+opCdK2GVjnj3fzmShuj21FNAu +tGpbUfClzj3uG0gqDL/ =brz9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f58d87.1020...@fastmail.fm
Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/25/2014 05:24 AM, Johannes Schauer wrote: > Hi, > > Quoting The Wanderer (2014-01-22 15:14:34) > >> Do things still work fine in Debian when using ld.gold (by >> installing the binutils-gold package) rather than ld.bfd? I know >> there's an important difference in ld.gold related to --as-needed >> (or possibly to - --no-as-needed, I don't recall offhand). > > I dont think the binutils-gold package exists anymore. binutils-gold > seems to be provided by the binutils package which now seems to ship > /usr/bin/ld.gold I hadn't noticed, but you're right, it's only in stable now. (Even the stable package claims that it only installs the diversion of ld to ld.gold, so it's possible that ld.gold was always provided by binutils directly; I haven't dug into the history here.) That might mean my attempted recall was wrong, or that plans have changed since the last I heard about it. It's still probably good practice to make sure things build both ways, though. > Do you happen to know an easy, undisruptive way to test with ld.gold? That depends. The most general way I can think of would be to set up an alternatives group for ld, define ld.bfd and ld.gold as the two alternatives, and then switch back and forth in between tests; however, that's a system-wide change, which might not qualify as non-disruptive. Depending on your package's build system, there might be a configure option or an environment variable to specify what ld to use. That would be non-disruptive, since it's local rather than system-wide, but it's also not universally applicable. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS46qkAAoJEASpNY00KDJr6RMP/i2y/d+ob0fGrU1MrowLPJ48 8w25wSwOxwUWBsm8cck9qSMfB/qgF2lythw4utfPi+LUO0cj7+evTpDJjtcewwJs u4q3mE+HpzWTmkYaD9gZXiKKJiaXx/Uf8QNuob+2kIkesI4QxPNzOnqREvrf/vP/ U+0UwHTwMti80ZFzFWxasMfxNqFyii64vMoYPFx1CkUCYBXwDI8br++xsDOT8yW6 rK3kab1h9VIS+glpTbM+DZBvlVt/1XDQkb10UqK5myIvzvtc99nMunvu7lRuN6wL 7BtwYbGC5vx6y25sNpsumJKBHNyK99vyXAB7xGPuxZ5RWJwd81R5NyE3SDtQ/+OA lA7WWmuOqYxcK2Rkd9r+EEsiaKLqUnUCOvXL/wZQS8SwbuLTyD2rKgCHGendBeU4 RyATKI3gndC1LR226Su7gkx/FhRE5ZGsyx2Re9OEWt4MuVRijOwDhNM1YJX59XlA UiCbMGkfX/zG3p/l4HYuj/TIYlXxxWxXCj/IJfDvh0QAI3Gdr2jbciQYiSWTJHQ7 6MzlAnkbn3M7PJC2BKfIilVufeQmln6SOvTe7JvHD1bQbWZ512RDhAAaA7NQxB4L 2OogGzLQg7nLheVFzaWJAEULqDzuHMCXsC8iItNtUX55JrvAG7pp1sKAFWjoYeCl oA8qeUxdwVseS1C2krN+ =817s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e3aaa4.5000...@fastmail.fm
Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/22/2014 05:12 AM, Johannes Schauer wrote: > Hi, > > Quoting أحمد المحمودي (2014-01-22 10:36:11) > >> Actually what happens implicitly (at least on Ubuntu precise) is: >> $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ >> >> which causes the compilation to fail, because the -l<...> should be >> after the object files (or source files in this case). > > Ah funny, so it's a ubuntu problem. I did not observe this problem > with Debian unstable. > > After trying it out myself in a ubuntu precise and saucy chroot and > asking on #debian-mentors, the reason why this error happens only on > Ubuntu seems to be: > > https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed > https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition > > Should I contact upstream to yet again change his makefile or are > things okay as they are because everything works fine in Debian? Do things still work fine in Debian when using ld.gold (by installing the binutils-gold package) rather than ld.bfd? I know there's an important difference in ld.gold related to --as-needed (or possibly to - --no-as-needed, I don't recall offhand). I seem to recall that there are long-term plans to switch Debian over to ld.gold or to produce the same effect in ld.bfd, and that it's recommended (or at least preferred) to make sure your package builds with the gold linker; I suspect that this is the "similar change... being discussed for Debian" mentioned in the ToolchainTransition article you linked. There's no expected completion date for this AFAIK, but trying to be compliant with it isn't a bad idea; I've already got the upstream of something I haven't even packaged yet to accept a compliance patch, just based on test packaging attempts. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS39JJAAoJEASpNY00KDJrqYQP/0GBnMOtwgXJwbDIj/qskRr0 En2lnuVM76ua/xb4iYCrbmeQ3APnwJ8pqrJ2oSozuA+A1244TAiXgzf/iLFCZ+JI 2sID3uMLf8+rrXnVs0FFKNEuNHAVYLSi9TxF1Ptlpai1YFwasGU5MrEr13kthrD+ RgQ0+3HWxJ29aNo4yR90SxK8zADjjm0bggJlwI8ltGaWxKMPZsfZSs12f19lMSe+ UpIT0vISg724mlsU3i31+rUIrfnAm+AlrVzX0j5H6p5gkp6o1+IKsmi9LBQviCJh sBZ85Eq7LvZpfWpErf1FBXVRlnosuBC/P/S8XfJhTQP5owDLqOO5ot33IKb128f0 /MmoiT0xe/KjlKnqcLg0Mru90HmNkm1VY0ZKuojJfc1n/OcMg+IX8UrjGCTSnjSW bV7CpT2eYFj6ikbSNcLGBWEy+zllppWaBXIB5K+c3NJ++oc1VHN88/lKlmL36d07 BKPiMA1qoyGbdbpr9dLbCXL8QVgOS9ZblMXRimZjsYhDDM4DzZq6pMheTorfCUR3 9wzGL40K1tE4MNm/j2gfKaYTKauw1u+EI70CPX6+jFECmWqAsL0grDHvMlavZfvN JmoxhwsH6WHldkrhjih1VcglJ84AZCB/wllxsRRI0+ULt7yo4X7966y+0AFi57la 5xw2Zvg+Asg22VMaA1cy =AeaL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dfd24a.9030...@fastmail.fm
Re: possible-gpl-code-linked-with-openssl
On 10/16/2013 11:08 AM, Gert Wollny wrote: On Wed, 2013-10-16 at 10:36 -0400, The Wanderer wrote: I can see where this might not be enough to allow adding the license exception without an explicit statement from upstream, but at least to my eye, it does seem to contradict the notion that "upstream did not link against [OpenSSL]". Maybe upstream never linked the code at all or used a mock implementation that only provides the openssl interface without functionality ;) Upstream provides pre-built Win32 binaries, and the Windows build instructions are where the OpenSSL prerequisite is stated; it seems highly likely that those pre-built binaries are linked against OpenSSL. Your point in the rephrasing is taken, however. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525eade2.6030...@fastmail.fm
Re: possible-gpl-code-linked-with-openssl
On 10/16/2013 10:21 AM, Dominik George wrote: Richi Lists schrieb: Or can I add the excpetion myself, assuming since the author chose to link agains openssl, he is ok with it? Definitely not. Upstream did not link against it - you do that. The upstream README on GitHub states that "At present, vanitygen can be built on Linux, and requires the openssl and pcre libraries." The INSTALL file lists OpenSSL 1.0.0d as a prerequisite. Some of the includes in the source files explicitly and unconditionally reference headers under the openssl/ hierarchy. I can see where this might not be enough to allow adding the license exception without an explicit statement from upstream, but at least to my eye, it does seem to contradict the notion that "upstream did not link against [OpenSSL]". -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525ea451.4080...@fastmail.fm
Re: debian/rules stamp-* targets
On 09/03/2012 06:04 PM, Roger Leigh wrote: On Mon, Sep 03, 2012 at 05:30:42PM -0400, The Wanderer wrote: On 09/03/2012 02:56 PM, Igor Pashev wrote: I can also suggest to use *-stamp: such files will be removed by dh_clean automatically :-) From what I can see, the stamp-* files seem to be removed automatically as well. At least by 'debian/rules clean' from that package, which appears to simply run 'dh clean' as far as I can tell. And better, if you're using dh, it maintains its own internal stamp files so that you don't have to. Which makes it a little weird that the stamp-* targets were even there in the first place, since that particular debian/rules file has the '%: dh $@' catch-all rule, and uses dh for the other targets anyway. Oh, well. I've got it working without the deprecation warnings for now, I'll worry about cleaning it up to my obsessive standards later on. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50452a60.6060...@fastmail.fm
Re: debian/rules stamp-* targets
On 09/03/2012 02:56 PM, Igor Pashev wrote: 03.09.2012 21:53, Arno Töll пишет: Hi, On 03.09.2012 18:55, The Wanderer wrote: I have not been able to find any documentation on these stamp-* targets, although searching has revealed that they or something like them appear to be (or to have been) used in a number of other packages as well. What are they used for, and how "necessary" are they? They are entirely optional, in fact. It's a custom behavior to work around issues with pseudo-phony targets which aren't declared as such for some reason [1]. That's just one way (among many) to implement a debian/rules file. I can also suggest to use *-stamp: such files will be removed by dh_clean automatically :-) From what I can see, the stamp-* files seem to be removed automatically as well. At least by 'debian/rules clean' from that package, which appears to simply run 'dh clean' as far as I can tell. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50452182@fastmail.fm
debian/rules stamp-* targets
I'm attempting to rework the removed e16 package to sumbit it for reinclusion. The debian/rules file for the old version of this package contains the targets 'debian/stamp-build' and 'debian/stamp-install', and includes debian/builddir.mk, which contains the target 'debian/stamp-tarcopy'. These targets appear to simply run 'touch $@' after the commands which actually build the target. I have not been able to find any documentation on these stamp-* targets, although searching has revealed that they or something like them appear to be (or to have been) used in a number of other packages as well. What are they used for, and how "necessary" are they? There are deprecation warnings in the package which could be fixed either in a way which retains the stamp-build target or in a way which removes it. Which one would be more appropriate? -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5044e0e8.8080...@fastmail.fm
