Bug#960617: popularity-contest: popcon fails to send data if USETOR=maybe and tor is not running
Nevermind, it was only coincidence, I guess I installed tor and updated systemd at the same time, and ran into #840376. So my issue is not about USETOR afterall.
Bug#931401: syncthing: incorrect warning please upgrade to v0.14.14 or newer
Hello, I also have this issue. It prevents me from syncing symlinks. :/ It seems that d/rules is trying to inject a clever version string, and it fails for some reason. Cheers, Ben
Bug#939789: faketime: Fails to parse "strict" timestamps with error message "Success"(!)
Control: severity -1 minor Thanks Hello Wolfgang, thanks for your quick response! With your calls, you should not use the '-f' parameter. Without '-f', the timestamp is passed on to date/gdate for parsing, which yields the following for me on Debian Buster x86_64: That changes the behavior: Without '-f', the called program will see time passing. In my case the call goes to a build process which takes several seconds, and the timestamp that I want to influence is taken at the very end of it. So without the '-f', the "fake clock" would show a non-deterministic, and most likely different, time. That's exactly the thing that I want to avoid. https://github.com/wolfcw/libfaketime Thanks! I hoped that it could parse the absolute timestamp anyway, but 4b) is clear enough. Oh well. I hope that helps a bit. It does indeed, thank you. Like I already mentioned, in my case git's `iso` makes faketime happy, and makes me brush up my knowledge on bash. I also agree that "Success" isn't much of a useful error message here. In this case, it's created by a call to the standard perror() system call, which should be considered to be replaced with something more meaningful. I'll put that on the todo list. :-) However, more useful error messages are printed by the wrapper when '-f' is not used. Sounds good. So in summary: - The parsing is "as intended". - git and faketime have different about "strict ISO date formats". - The bug is actually only the `: Success` part of the output. Therefore, the bug is only minor. Also, I have a manual workaround anyway. Cheers, Ben Wiederhake
Bug#912379: /usr/bin/pip3: TypeError on "list --outdated": uses different Version implementations
Control: found -1 18.1-4 Thanks Hello, still happens. This is strictly necessary for the recommended "upgrade-all" method [1]. Pip currently has no other way to do this [2], and this feature is blocked by other issues [3], so "list --outdated" will continue to be of interest for a long time. Cheers, Ben [1] https://stackoverflow.com/q/2720014/3070326 [2] https://github.com/pypa/pip/issues/4551 [3] https://github.com/pypa/pip/issues/988
Bug#865013: network-manager-gnome: Consistent segfault when connecting to WPA2 network
Control: found -1 1.8.10-2 Heyaloha, it seems like this is going to take a while to update. Meanwhile, I sent in a patch [1], and it got "applied, with a small change" [2]. You may want to do the following: apt-get source network-manager-applet sudo apt-get build-dep network-manager-applet fakeroot ./debian/rules binary sudo dpkg -i ../libnma0*.deb Plus minus a few 'cd'. Cheers, Ben [1] https://bugzilla.gnome.org/show_bug.cgi?id=785674#c5 [2] https://git.gnome.org/browse/network-manager-applet/commit/?id=a37483c1a364ef3cc1cfa29e7ad51ca108d75674
Bug#883965: nm-connection-editor crashes when opening a connection
Heyaloha, is it possible that this is a duplicate of #865013? - Both crash Consistently when clicking "modify" - Both crash in src/libnma/nma-cert-chooser-button.c due to this line: g_critical (…, error->message); (it used to be line 95, currently it's line 98) Note that I sent in a patch [1], and it got "applied, with a small change" [2]. You may want to do the following: apt-get source network-manager-applet sudo apt-get build-dep network-manager-applet fakeroot ./debian/rules binary sudo dpkg -i ../libnma0*.deb Plus minus a few 'cd'. Cheers, Ben [1] https://bugzilla.gnome.org/show_bug.cgi?id=785674#c5 [2] https://git.gnome.org/browse/network-manager-applet/commit/?id=a37483c1a364ef3cc1cfa29e7ad51ca108d75674
Bug#855955: aisleriot: Variants "Westhaven" and "Diamond-Mine" interfere: crash with wrong-number-of-args
Control: found -1 1:3.22.4-3 Thanks Hello, still happens. It looks like it's not necessary to complete the game. I don't know why I didn't paste it the first time, but here's a Scheme backtrace. -- 8< -- Variation: westhaven Scheme error: (#f Wrong number of arguments to ~A (#(card-suit card-rank slot)>) #f) Scheme tag: wrong-number-of-args Backtrace: In ice-9/boot-9.scm: 160: 8 [catch #t # ...] In unknown file: ?: 7 [apply-smob/1 #] In ice-9/boot-9.scm: 160: 6 [catch #t # ...] In unknown file: ?: 5 [apply-smob/1 #] In westhaven.scm: 304: 4 [get-hint] 271: 3 [tableau-to-tableau? 6 15] In diamond-mine.scm: 278: 2 [find-card 6 (9 2 #t)] In ice-9/boot-9.scm: 105: 1 [#(thrown-k . args)> wrong-number-of-args ...] In unknown file: ?: 0 [apply-smob/1 # wrong-number-of-args ...] Deck State: Slot 0 (0 10 #f) ,(0 11 #f) ,(1 1 #f) ,(3 1 #f) ,(3 9 #f) ,(3 6 #f) ,(1 4 #f) ,(2 1 #f) ,(0 1 #f) ,(1 13 #f) ,(3 8 #f) ,(1 9 #f) ,(0 7 #f) ,(1 10 #f) Slot 1 (Empty) Slot 2 (Empty) Slot 3 (Empty) Slot 4 (Empty) Slot 5 (Empty) Slot 6 (0 2 #f) ,(2 9 #t) Slot 7 (3 5 #f) ,(3 11 #t) Slot 8 (0 13 #f) ,(1 12 #t) Slot 9 (1 7 #f) ,(2 6 #t) Slot 10 (2 3 #f) ,(3 7 #t) Slot 11 (0 6 #f) ,(2 12 #t) Slot 12 (1 11 #f) ,(2 4 #t) Slot 13 (1 8 #f) ,(0 4 #t) Slot 14 (0 9 #f) ,(2 7 #t) Slot 15 (2 2 #f) ,(3 10 #t) -- >8 -- Cheers, Ben
Bug#892077: rakarrack: Segfaults after jackd upgrade
Hello, my best guess is that in Looper.C:63, the access of the field `Ppreset` reads uninitialized memory. Manual workaround: Add `Ppreset = 0;` at the top and hope that this value makes any sense. Works for me. Cheers, Ben Wiederhake
Bug#892079: rakarrack: Cannot compile due to -Werror=format-security
control: close -1 thanks Hello, I'm sorry, apparently this is already fixed in the actual current version. It appears that the git repo is older than whatever apt-get source serves. Cheers, Ben Wiederhake
Bug#882121: The fix is even more misleading
Control: reopen Thanks Hello, as far as I can see, this has been fixed to the following: ### # Magic system request Key # 0=disable, 1=enable all, >1 bitmask of sysrq functions # Debian kernels have this set to 438 which is the OR of: # 64 = enable signalling of processes # 128 = allow reboot/poweroff # 256 = allow nicing of all RT tasks # # See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html # for what other values do #kernel.sysrq=438 This is even more misleading, as 438 is *not* 64 | 128 | 256: $ echo $((64 | 128 | 256)) 448 I assume you meant to write 448 instead of 438 everywhere? Cheers, Ben Wiederhake
Bug#857553: [Pkg-xfce-devel] Bug#857553: xfce4-settings: "Disable Touchpad" duration is broken / rounded
Here's the behavior of `xinput --watch-props` with the right device ID. Actually I think it might make sense to look at that *when you change the settings*. I did, see previous mails: xinput only sees the "Synaptics Off" property changing. xinput does *not* see anything related to "disable for time", so xinput is "too far down the chain". Looking into the dialog's main.c, line 1998 appears to refer to the key '/DisableTouchpadDuration', which `xfconf-query -m -c pointers` verifies. What is stored there? The correct values or the rounded ones? With the dialog set to 0.9: $ xfconf-query -c pointers -p /DisableTouchpadDuration 0,90 $ LC_ALL=C xfconf-query -c pointers -p /DisableTouchpadDuration 0.90 And after setting it to 1.1: $ xfconf-query -c pointers -p /DisableTouchpadDuration 1,10 $ LC_ALL=C xfconf-query -c pointers -p /DisableTouchpadDuration 1.10 I'm in a locale where decimals get printed by a comma, not a dot. Is it possible that whoever reads from xfconf gets the "comma" format? Where should I look next? I'm currently reading xfconf's source to find the next step. No, xfconf is not the right direction. Try to configure your touchpad using only the xinput commands, keep Xfce outside of the equation. Yes, but which piece of software comes between xfconf and xinput? (I tried these, but didn't get an answer to that question: lsof on xfconfd; lsof on xfsettings; xinput with various arguments; xfconf-query) Cheers, Ben
Bug#857553: [Pkg-xfce-devel] Bug#857553: xfce4-settings: "Disable Touchpad" duration is broken / rounded
Hello, thanks for your quick response and pointers! For the current settings and the rounding, can you check what ends up in the input layer? You can use the xinput command to look into that. I don't use a touchpad so I can't really give more details. Here's the behavior of `xinput --watch-props` with the right device ID. - With 0.9 s, nothing gets logged when I type or when I touch the touchpad. - With 1.1 s and a single keypress, it immediately says "Property 'Synaptics Off' changed: Synaptics off (283): 1", and after roughly 1 second it says "Property 'Synaptics Off' changed: Synaptics off (283): 0" - With 1.1 s and several keypresses, it seems to correctly wait for 1.1 seconds after keyboard activity ceased. So it looks as if there's something "above" Synaptics responsible for the "disable for certain time" logic, and *that* logic has an issue. Looking into the dialog's main.c, line 1998 appears to refer to the key '/DisableTouchpadDuration', which `xfconf-query -m -c pointers` verifies. So the problem is indeed somewhere between xfconf (inclusive) and xinput (exclusive). Where should I look next? I'm currently reading xfconf's source to find the next step. Cheers, Ben
Bug#857553: xfce4-settings: "Disable Touchpad" duration is broken / rounded
I forgot to mention:
- This is not related to #728844 for two reasons: (1) the slider *does*
work, it's just inappropriately rounded. (2) Different slider ("Disable
Touchpad" duration, not "Pointer Acceleration")
- This is not related to #851802 either.
There is no other bug related to touchpads.
Cheers,
Ben
Bug#855955: aisleriot: Variants "Westhaven" and "Diamond-Mine" interfere: crash with wrong-number-of-args
Reported upstream as https://bugzilla.gnome.org/show_bug.cgi?id=779149
Bug#809623: RFS: telegram-purple/1.2.5
Hello, sorry for the long wait, real life happened. Also, note the version bump in the subject from 1.2.3 to 1.2.5. Seems like it, true, but sadly is necessary. The package is in version control, and unless we provide pre-bundled origtars somewhere (which won't happen), this has to build the origtar by invoking "make dist" in the source tree. why you cant provide pre-bundled origtars? I know some project that does exactly the same. We now bundle the origtar, and listen for it in d/watch Now this is getting absurd: the whole point of dh get-orig-source is to >support people for who "git pull" is too complicated. But suddenly I can assume that git is installed, although git is not pulled by build-essential? Resolved. Long explanation: Back then, I (wanted to) implement dh get-orig-source by: - git clone-ing the repository - git checkout the required version - recreate origtar from that ... which is error-prone and unnecessarily complex. Starting with 1.2.5, the orig-tar is part of the release, so we can just use uupdate. Now I come with a question. You want to maintain the package only in Debian? or in all linux distro around the globe? I would like to see this work helping all Debian-derivatives. A month ago, before I went inactive for a month, (long before Ubuntu's DebianImportFreeze), I hoped that telegram-purple would make it into Debian unstable and therefore into Ubuntu 2016-04. Well, that didn't work. Also, see below. As it turns out, pushing 1.2.5 into Debian right now would be a bad idea. you are doing the repack work as Debian work, this means that other linux derivatives won't ever gain from the work, and they will need to do it again. Thanks to the published origtar, this should become a bit easier in the future. Pushing the tarball (complete and reduced) upstream, will save a lot of work for everybody and simplify a lot the Debian packaging (just a simple watch file, with no repack at all). Signed :) Due to Telegram cranking out unexpected features that break everything, we won't push 1.2.5 into Debian anyway, so that's why I don't bother with another RFS yet. Regards, Ben
Bug#809623: RFS: telegram-purple/1.2.3-1
Hello,
They generate the orig tarball.
The watchfile is to check for the newest version.
These are unrelated things.
no. they are completely related things.
uscan downloads the tarball from the watch file, and if the uscan downloaded
tarball doesn't fit your needs
you have to call the repack script directly from the watch file.
with a get-orig-source target
https://wiki.debian.org/onlyjob/get-orig-source
Oh, wow. This will take a bit time until I grasp everything well enough
to publish something with this :P
Most prominently, I don't like the "everythingisoneline" approach of the
watchfile. I guess someone has already suggested changing it to the
"usual" YAML-based approach?
this is my virtualbox watch file
version=3
opts=downloadurlmangle=s/^/http:/,dversionmangle=s/-dfsg\d*$//,uversionmangle=s/-.*//
\
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VirtualBox-([\d\.\-]+).tar.bz2
\
debian /bin/sh debian/get-orig-source.sh
I... I believe I understand this. However, testing this will be a pain,
and automatic testing probably impossible.
Is there some kind of established "best practice" for testing these? Or
is the best practice just to "run by hand until it works, then wait
until it breaks for DEHS"?
I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they
will be dropped in the next version, in favor of relatively clean
chaining of git-archive and tar --concatenate.
(Obviously not part of the build process, so no need to put any of that
into Build-Depends.)
sure, even better, maybe if you integrate with watch file.
I can do that, sure. Can you tell me who profits from this, though? It's
a bit demoralizing to have to write and test things like these if noone
will ever profit from this.
I understand that d/watch is needed by DEHS to monitor how outdated the
Debian repository is, in some sense. So I wrote a d/watch for that, and
made sure it works and will continue to work.
I also understand that some maintainers prefer working with uscan to
fetch and integrate the newest upstream version. But that doesn't apply
here, as the preferred mode of updating is doing a "git pull".
My script would probably do the following thing:
- delete the file fetched by uscan, since it's utterly incomplete
- use the upstream version to clone (as in git-clone) the repository
- ./configure && make dist || (echo "Too old upstream version; doesn't
support orig tarballs yet."; exit 1)
- delete all temporary files
Ugh.
And all that so that someone can say "dh get-orig-source".
So, who does this? (And can I assume git to be installed? I don't like
having such a big b-d ...)
BTW submodules should in my opinion be considered as different sources, and
packaged
separately.
Otherwise you will have a mess of files with no common history, difficult to
track and fix
(specially for security issues)
Already extensively documented in d/README.source
In short, the reason is: tgl ("the" submodule) is way too unstable and
volatile to ever be packaged separately.
There is only one other program that might enter the Debian repository
(tg-cli, I don't see any RFP or ITP for it) will never be used together
with telegram-purple, and will most definitely never use a compatible
version of tgl.
Currently, we assume that the builder eventually invokes ./configure
with whatever arguments he pleases and the usual semantics. This
approach does not need anything explicit in d/rules.
autoreconf is only called when we change configure.ac, in which case the
new configure-script will be put into git. At no point, there's a need
for the "user" (here: builder) to call auto{,re}conf.
Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?
exactly, but you need to call autoreconf each time you configure the script.
it might sound silly to you, but in case a new architecture is added in Debian
(e.g. recent ppc64el and arm64), your scripts will be outdated,
None of our scripts assume any architecture or have a list of all of
them. What part of which script would become "outdated"? What would change?
BTW the version should always be a -1 revision, until the -1 reaches debian
(specifically new queue)
Hmm, but this makes it easier for me to track which versions there were.
But okay, I'll push the next version as 1.2.4-1 if you wish.
you don't have to bump the debian revision, this will make harder for a sponsor
to track it, and
useless for Debian users (they won't find the intermediate releases)
Huh? I'm confused. I make sure that all versions have a different
number, and go increasing as per dpkg --compare-versions. Why is it
*harder* to track progress?
I mean, sure, I can change my behavior regarding that, I just think it's
a good idea if I also know the reason for it :P
Regards,
Ben
Bug#809623: RFS: telegram-purple/1.2.3-1
Control: tags -1 - moreinfo
Hello,
thanks for taking a look at this package :D
I'm not sure if anybody picked up the work for this bug, but lets do
another review:
- -please drop commented default stuff from rules file
- -please merge changelog in one single entry
(also "mentors" is not a target series)
These (and only these; see below) are already fixed in 1.2.4-2, which
was uploaded 8 days ago [1]
I guess I did something wrong if you haven't seen that, even though I
thought it should be done this way. Can you tell me what I should do
differently next time?
- -please drop rawtar and genorigtar.sh, they seem useless with the
current watch file.
They generate the orig tarball.
The watchfile is to check for the newest version.
These are unrelated things.
As already documented in d/README.source, the orig-tarball can't be
gathered from the obvious sources:
- Github (definitely)
- pristine-tar (definitely)
- git-buildpackage (afaik)
They all fail for the same reason: missing support for submodules within
submodules. (Or gbp simply requires more setup than I thought.)
I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they
will be dropped in the next version, in favor of relatively clean
chaining of git-archive and tar --concatenate.
(Obviously not part of the build process, so no need to put any of that
into Build-Depends.)
- -please use autoreconf and b-d on dh-autoreconf if possible
I'm not entirely sure what you mean by this.
Currently, we assume that the builder eventually invokes ./configure
with whatever arguments he pleases and the usual semantics. This
approach does not need anything explicit in d/rules.
autoreconf is only called when we change configure.ac, in which case the
new configure-script will be put into git. At no point, there's a need
for the "user" (here: builder) to call auto{,re}conf.
Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?
On a side note: 1.2.4 isn't going to make it anyway. Apparently, it's
horribly unstable on Windows.
Regards,
Ben Wiederhake
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809623#79
Bug#808574: wrap-and-sort: option to not modify any files
Control: tag -1 + patch
Hello,
I'd like to suggest a patch for this, please find them enclosed.
The patches base on the currently unreleased ed9350e, or
"v2.15.10-2-ged9350e" as git describe puts it.
In fact, these are two patches, one of which "cleans up" a specific
aspect so that the second patch can implement the desired feature
(--dry-run).
I'd like to submit even more patches, outside the scope of this bug,
e.g. for #788998, and the leaking fds, and maybe #701646, and maybe
adding a test for w-a-s, and ...
How does this work? Submitting patches to a bug doesn't scale well.
Regards,
Ben
>From ba69efde72720cb8727aa3221de9829b76f43c8b Mon Sep 17 00:00:00 2001
From: Ben Wiederhake
Date: Wed, 6 Jan 2016 00:02:31 +0100
Subject: [PATCH 1/2] wrap-and-sort: Pass options dict for brevity
---
scripts/wrap-and-sort | 40 +---
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/scripts/wrap-and-sort b/scripts/wrap-and-sort
index 98a4bb5..15c8bb0 100755
--- a/scripts/wrap-and-sort
+++ b/scripts/wrap-and-sort
@@ -64,34 +64,30 @@ SUPPORTED_FILES = (
class WrapAndSortControl(Control):
-def __init__(self, filename, max_line_length):
+def __init__(self, filename, options):
super().__init__(filename)
-self.max_line_length = max_line_length
+self.opts = options
-def wrap_and_sort(self, wrap_always, short_indent, sort_paragraphs,
- keep_first, trailing_comma):
+def wrap_and_sort(self):
for paragraph in self.paragraphs:
for field in CONTROL_LIST_FIELDS:
if field in paragraph:
-self._wrap_field(paragraph, field, wrap_always,
- short_indent, trailing_comma)
+self._wrap_field(paragraph, field, True)
if "Uploaders" in paragraph:
-self._wrap_field(paragraph, "Uploaders", wrap_always,
- short_indent, trailing_comma, False)
+self._wrap_field(paragraph, "Uploaders", False)
if "Architecture" in paragraph:
archs = set(paragraph["Architecture"].split())
# Sort, with wildcard entries (such as linux-any) first:
archs = sorted(archs, key=lambda x: ("any" not in x, x))
paragraph["Architecture"] = " ".join(archs)
-if sort_paragraphs:
-first = self.paragraphs[:1 + int(keep_first)]
-sortable = self.paragraphs[1 + int(keep_first):]
+if self.opts.sort_binary_packages:
+first = self.paragraphs[:1 + int(self.opts.keep_first)]
+sortable = self.paragraphs[1 + int(self.opts.keep_first):]
key = lambda x: x.get("Package")
self.paragraphs = first + sorted(sortable, key=key)
-def _wrap_field(self, control, entry, wrap_always, short_indent,
-trailing_comma, sort=True):
+def _wrap_field(self, control, entry, sort):
# An empty element is not explicitly disallowed by Policy but known to
# break QA tools, so remove any
packages = list(filter(None, [x.strip() for x in control[entry].split(",")]))
@@ -105,20 +101,20 @@ class WrapAndSortControl(Control):
packages = sort_list(packages)
length = len(entry) + sum([2 + len(package) for package in packages])
-if wrap_always or length > self.max_line_length:
+if self.opts.wrap_always or length > self.opts.max_line_length:
indentation = " "
-if not short_indent:
-indentation *= len(entry) + 2
+if not self.opts.short_indent:
+indentation *= len(entry) + len(": ")
packages_with_indention = [indentation + x for x in packages]
packages_with_indention = ",\n".join(packages_with_indention)
-if trailing_comma:
+if self.opts.trailing_comma:
packages_with_indention += ','
-if short_indent:
+if self.opts.short_indent:
control[entry] = "\n" + packages_with_indention
else:
control[entry] = packages_with_indention.strip()
else:
-control[entry] = ", ".join(packages).strip()
+control[entry] = ", ".join(packages)
class Install(object):
@@ -168,12 +164,10 @@ def wrap_and_sort(options):
for control_file in control_files:
if options.verbose:
print(control_file)
-control = WrapAndSortControl(control_file, options.max_line_length)
+control = WrapAndSortControl(control_file, options)
if options.cleanup:
control.strip_trailing_spaces()
-control.wrap_and_sort(options.wrap_always, options.short_indent,
- options.sort_binary_packages, options.keep_first,
- options.trailing_comma)
+
Bug#809623: RFS: telegram-purple/1.2.3-1
* d/README.source - In upstream README.md you tell Debian Maintainers to use the genorigtar.sh. Looking at Policy §4.14, I think README.source should also instruct to do that. * Paul Wise already wondered if libtgl should be separately packaged. The related Debian Policy bit is §4.13 [3] [Follow-up Mail] * Please install the appdata file. You can do this with dh_install(1) by creating a file called debian/install with this line in it: telegram-purple.metainfo.xml usr/share/appdata or by making the upstream build system install the file. Here's my initial attempt at writing a README.source that covers all topics (displaying the content does not require you to clone or do anything, works even without JavaScript) : https://github.com/BenWiederhake/telegram-purple/tree/debian-develop/debian#readme Is this an acceptable way to write up all rationales? The other fixes are "in the pipeline" (mostly already done in git), but the next upload to mentors may take another day or three. I'll post some of the things discovered by check-all-the-things (e.g. a new error from cppcheck, spelling mistakes in debug messages, etc.) as pull requests to the respective repositories. However, none of them need immediate attention or can be considered a bug. (The cppcheck-thing looks pretty concerning, but I understand enough of the code to verify that the uninitialized values are never read, so it's good enough, considering the PR I'll make against tgl.) Regards, Ben
Bug#809623: RFS: telegram-purple/1.2.3-1
Telegram-purple is a generic purple-plugin,
[...] including "pidgin" into the name would be highly misleading.
Other libpurple backends are named pidgin-* (like pidgin-openfetion,
pidgin-skype and pidgin-librvp) and I don't see any libpurple backends
with other names. Perhaps these packages should be renamed though.
Consistency for the sake of consistency is not always a good thing. And
since this "consistency" can be confusing, I'm going to wilfully break it.
Furthermore, renaming the plugin to "pidgin-telegram" has several
disadvantages: All error messages would need to be adapted, paths would
need updating, including the translation strings, and users are probably
expecting the name to be "telegram-purple" (at least initially).
Where should I write this down? d/control maybe? Or as a "wontfix"-bug
against the package (as soon as it exists in the BTS)?
As a comment in debian/control or README.Debian. I wouldn't bother
filing a wontfix bug yourself.
Will do so in the next upload.
It reports a lot of things, mostly false positives or related to the
underlying libtgl. However, at least codespell (the very first to be run,
and I was sure I already did that) yields a few things.
I'd be interested to know if those are false positives in the tools it
runs or caused by it.
Again, I haven't really had the time to go through it, but here's an
overview:
- flawfinder yields too many results to be practical (~ 2460 lines).
This is mostly due to libtgl being written in a style that uses static
arrays for everything, including parsing and output.
- The output of "POFileSpell" seems to depend on the local dictionaries.
It seems to flag every word in every language I don't speak. (~ 1640 lines)
- i18nspector and Transifex (the service we use for our translation)
heavily disagree about how a po-file should look like, and how Russion
plurals work(?!).
- include-what-you-use Is completely useless: It doesn't recognize
, although it is installed and appears in the reference:
http://en.cppreference.com/w/c/header
It also recommends to do a lot of silly things, such as including
struct declarations in .c files. (~ 2820 lines)
- The following check complains loudly about plurals:
"find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt
--check --check-compatibility --check-accelerators
--output-file=/dev/null {} \;"
I'm not sure what to do with that information. We want correct plural
support, so this won't change.
- "suspicious-source" works like a charm. It runs in a fraction of a
second, and outputs only a single line: "./tg-server.tglpub"
That's absolutely correct! I like that program. (I'm not complaining,
I'm admiring the program. The file ./tg-server.tglpub is clearly
documented in the README.md, including a link to a side-project with the
sole purpose of reproducibly generating this single file for public
sources.)
- The "Please add some upstream metadata" warning triggers. Since this
is not a scientific project, and there won't be any doi-references, I'm
going to ignore the warning. However, I'm going to use this to ask: Why
is that a warning? Why not include it in the build scripts of the
deb-science packaging team instead?
- The problem of bashisms relates to the program checkbashism, like
incompatibilities between make-implementations to checkgmakeism, a
program I'd like to see being written. I made up the name. I have no
idea how to do that. So far, we did it by trial and error, and change
something whenever a user complains. AFAIK, by now we only support
gmake, due to the use of "ifdef", which should be ".ifdef" in bsd-make:
https://github.com/majn/telegram-purple/issues/137#issuecomment-167970054
Sorry for the wall of text, but you *did* ask for it :P
I wonder if libtgl should be packaged separately so that all the
Telegram clients could use it?
We previously thought about this, and came to the result: No.
So far, ABI-compatibility was broken between every other commit to
libtgl, and it is under development. The last "stable" release is quite
a long time ago and heavily outdated. No other program (*including*
tg-cli) can be expected to use the same version of libtgl alongside
telegram-purple.
Packaging tl-parser or the intermediate "generate" program is also a bad
idea: One *could* do that, but it's only useful for libtgl. So there is
a significant lack of users.
Note that tl-parser is relatively stable, especially the output format.
So if anyone disagrees with me in the amount of users, I'm happy to
package tl-parser for you.
BTW, Telegram has a pretty terrible reputation amongst cryptographers,
personally I would switch to OTR or Signal/TextSecure if you can.
I know, and I agree. I support Telegram for other reasons.
But this isn't about which one is better. Telegram *does* have non-zero
Debian users that are using pidgin. Note there are enough people already
using the Fedora package, the Adium bundle (distributed by Matt
Bug#809623: RFS: telegram-purple/1.2.3-1
Hello, >> * Package name: telegram-purple This should probably be named pidgin-telegram in line with the other pidgin/libpurple plugins we have in the archive already. Oh, I forgot to include the rationale for sticking with the name. Telegram-purple is a generic purple-plugin, and also works well with Adium, Finch, and well enough with certain libppurple-using frontends such as telepathy-haze and Spectrum. So including "pidgin" into the name would be highly misleading. Where should I write this down? d/control maybe? Or as a "wontfix"-bug against the package (as soon as it exists in the BTS)? The package is (of course) lintian clean and passes several other tests. In case you want to check more things, you can run check-all-the-things from Debian experimental. Oh! I never checked experimental, that's why I didn't find it XD It reports a lot of things, mostly false positives or related to the underlying libtgl. However, at least codespell (the very first to be run, and I was sure I already did that) yields a few things. I'm going to work through the 8K likes it spits out over the next days. Regards, Ben Wiederhake
Bug#800771: ITP: telegram-purple -- Adds support for Telegram to libpurple
Since there's somewhere a guideline saying that we should sometimes post updates: - Debianisation is technically complete, see https://mentors.debian.net/package/telegram-purple Still the same: technically complete. This is not the obstacle. - Translation is coming along nicely, but we still desparately need Russion and Brazilian translators: https://www.transifex.com/telegram-purple-developers/telegram-purple/ Translations are mainly complete, at least the major ones. - Our development branches aren't merged yet, and there are one or two things we want to fix before pushing into Debian. I consider 1.2.2 too incomplete to be packaged for Debian, that's why I skip this version. I plan to RFS as soon as we reach 1.2.3. This is NOT a call for help, just a "report". Cheers, Ben Wiederhake
Bug#800771: ITP: telegram-purple -- Adds support for Telegram to libpurple
Control: owner -1 ! Since there's somewhere a guideline saying that we should sometimes post updates: - Debianisation is technically complete, see https://mentors.debian.net/package/telegram-purple (However, we will change roles, so that I can soon start the sponsoring process.) - Translation is coming along nicely, but we still desparately need Russion and Brazilian translators: https://www.transifex.com/telegram-purple-developers/telegram-purple/ - Our development branches aren't merged yet, and there are one or two things we want to fix before pushing into Debian. This is NOT a call for help, just a "report". ... unless you're a translator. In that case, this IS a call for help ;-) Cheers, Ben Wiederhake
Bug#801633: lintian: False positive of syntax-error-in-dep5-copyright with documentation example
Control: close -1 Hello, thanks for the swift response! I suggest you contacting debian-mentors@ to ask for help if you're not sure this is an actual lintian bug. Thanks, I'll do that the next time. Sorry for bothering you. Furthermore, ITPs are meant to be sent out *before* starting to work > on the package, [...] I am aware of this, and have not violated that rule. However, #800771 simply has nothing to do with this bug, so I didn't link to it. The issue here is that you missed a column ':' between "Copyright" and the data. Thanks, that was my mistake. Please, confirm us this is the issue, so we can close this bug (or close it yourself, if that's the case). Confirmed and closed. Cheers, Ben Wiederhake
