Re: virtualbox-guest-utils as time server.
Hi Jörg, Not related to your question, but: On Mon, Oct 09, 2017 at 08:56:25PM +0200, Jörg Frings-Fürst wrote: > Hello, > > today I update my system I got the following messages: > > [quote] > $ sudo apt-get dist-upgrade > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen Fertig > Paketaktualisierung (Upgrade) wird berechnet... Fertig > Die folgenden Pakete wurden automatisch installiert und werden nicht If you're going to use localisation (which is fine, I do too), then if you're trying to ask for help, please get into the habit of reproducing the bug under LC_ALL=C: LC_ALL=C sudo apt-get dist-upgrade this will disable translations for the duration of that particular command, and makes it more likely that people who do not speak your language can understand what you're talking about (of course, if you're trying to report a bug related to the translation, that's another matter ;-) Thanks, -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: virtualbox-guest-utils as time server.
On Sat, Oct 14, 2017 at 10:52:04AM +0200, Wouter Verhelst wrote: > If you're going to use localisation (which is fine, I do too), then if > you're trying to ask for help, please get into the habit of reproducing > the bug under LC_ALL=C: Unfortunately that doesn't help when you are reporting something about e.g. an apt transaction which already happened and so cannot be reproduced. -- WBR, wRAR signature.asc Description: PGP signature
Re: Mandates explicit -std=c++XY for c++ projects
On Tue, Oct 10, 2017 at 09:26:07AM -0400, Michael Stone wrote: > On Tue, Oct 10, 2017 at 02:16:36PM +0100, Dimitri John Ledkov wrote: > > On 10 October 2017 at 14:07, Gert Wollny wrote: > > > I think nobody would object if you set the flag to -std=c++98 for a > > > certain package, especially if upstream is dead or unwilling to move to > > > a newer standard, but I wouldn't want to see it as the default. > > > > > > > We, as a distribution, are better than that. Please provide URLs to > > FTBFS with c++11 bug report that is of concern for you, and I will try > > to look into it to fix the FTBFS with a distro patch. > > I would hope that debian wouldn't fork a package specifically to change the > c++ standards version over upstream objections. That sounds like a long term > maintainence nightmare in itself. Actually, in most cases that I've seen, upstream cares more about *also* supporting older standards (for the benefit of users using older distributions whose default compiler doesn't yet support the newer standard) than they care about the default standard in use. I think this question originated from a desire to manage C++ ABIs better. It's true that introducing a new C++ compiler which defaults to a different ABI will cause issues if not handled properly. However, we already have plenty of tooling in place to manage ABI differences, and I don't think this adds much. Currently, when the default C++ compiler changes ABI, what's needed is a coordinated transition where every C++ library package is updated in turn. Adding a default C++ ABI at the package level does not change that, and therefore I don't think we need to introduce it. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: virtualbox-guest-utils as time server.
On Sat, Oct 14, 2017 at 01:54:33PM +0500, Andrey Rahmatullin wrote: > On Sat, Oct 14, 2017 at 10:52:04AM +0200, Wouter Verhelst wrote: > > If you're going to use localisation (which is fine, I do too), then if > > you're trying to ask for help, please get into the habit of reproducing > > the bug under LC_ALL=C: > Unfortunately that doesn't help when you are reporting something about > e.g. an apt transaction which already happened and so cannot be > reproduced. In that case, even an imperfect translation back to the original (with the translated strings also in the mail) is better than "just" the translated strings. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#878513: ITP: libqtdbusmock -- Library for mocking DBus interactions using Qt
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: libqtdbusmock Version : 0.7 Upstream Author : Pete Woods (https://launchpad.net/~pete-woods) * URL : https://launchpad.net/libqtdbusmock * License : LGPL-3 Programming Lang: C++ Description : Library for mocking DBus interactions using Qt A simple library for mocking DBus services with a Qt API. . The software is relevant for unit testing DBus services based on Qt API. . The package will be maintained under the umbrella of the pkg-aytana-devel team.
Re: virtualbox-guest-utils as time server.
On Sat, Oct 14, 2017 at 10:52:04AM +0200, Wouter Verhelst wrote: > Hi Jörg, > > Not related to your question, but: > > On Mon, Oct 09, 2017 at 08:56:25PM +0200, Jörg Frings-Fürst wrote: > > Paketlisten werden gelesen... Fertig > > Abhängigkeitsbaum wird aufgebaut. > > Statusinformationen werden eingelesen Fertig > > Paketaktualisierung (Upgrade) wird berechnet... Fertig > > Die folgenden Pakete wurden automatisch installiert und werden nicht > > If you're going to use localisation (which is fine, I do too), then if > you're trying to ask for help, please get into the habit of reproducing > the bug under LC_ALL=C: > > LC_ALL=C sudo apt-get dist-upgrade Please use C.UTF-8 instead. The "C" locale is inappropriate in any case a non closed-class string may be outputted. Not sure if apt itself can print any metadata on a dist-upgrade (such as short desc: 185 packages, long desc: 489, maintainer's name: 2786), but maint scripts of programs being installed can. Ancient locales are damage and need to die. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
[BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
Bumping this as my mail to ftpmaster went unanswered. Could someone please remind me who to ask about the NEW Queue? It is causing me a FTBFS as I need this Build-Depends for an existing package which itself has reasonably wide-spread (for an R package) reverse dependencies. On 12 October 2017 at 06:39, Dirk Eddelbuettel wrote: | | Hi guys, | | Package r-cran-readstata13 is now a required build-dependency of another | package we had in Debian for a decade. So I prepared r-cran-readstata13 five | weeks ago, and followed up with a revision a week ago (adding README.source). | | Could you tell why the package is still in NEW and what is holding it back | from migrating to unstable? Without any information it is somewhat hard to | achieve progress here... And as a build-dependency, not providing it leaves | me no choice but to remove another set of packages from Debian as I can no | longer update the other package. Anyone who can help? The passive-aggressive "we won't work on your package, and won't tell you why" is a wee bit annoying. Dirk | | Thanks, Dirk | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#878577: ITP: r-cran-guerry -- maps, data and methods related to Guerry moral statistics
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-guerry Version : 1.6-1 Upstream Author : Michael Friendly, Stephane Dray * URL : https://cran.r-project.org/package=Guerry * License : GPL Programming Lang: GNU R Description : maps, data and methods related to Guerry moral statistics This package comprises maps of France in 1830, multivariate data from A.-M. Guerry and others, and statistical and graphic methods related to Guerry's "Moral Statistics of France". The goal is to facilitate the exploration and development of statistical and graphic methods for multivariate data in a geo-spatial context of historical interest. Remark: This package enables autopkgtest r-cran-adegraphics and will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/r-cran-guerry.git
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On Sat, Oct 14, 2017 at 12:59:10PM -0500, Dirk Eddelbuettel wrote: > > Bumping this as my mail to ftpmaster went unanswered. > > Could someone please remind me who to ask about the NEW Queue? > [...] > > The passive-aggressive "we won't work on your package, and won't tell you > why" is a wee bit annoying. So you decide to annoy all the subscribers to two lists that have nothing to do with your problem? NEW takes time. Always has, always will. If your package hasn't made it out of NEW, then don't upload other packages that depend on it. Spend your time on something else. It will eventually get processed. There's nothing passive aggressive about what's happening. It's just how things work when you have volunteers doing stuff that requires a chunk of dedicated time to focus. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On 14 October 2017 at 14:47, James McCoy wrote:
| On Sat, Oct 14, 2017 at 12:59:10PM -0500, Dirk Eddelbuettel wrote:
| >
| > Bumping this as my mail to ftpmaster went unanswered.
| >
| > Could someone please remind me who to ask about the NEW Queue?
| > [...]
| >
| > The passive-aggressive "we won't work on your package, and won't tell you
| > why" is a wee bit annoying.
|
| So you decide to annoy all the subscribers to two lists that have
| nothing to do with your problem?
|
| NEW takes time. Always has, always will. If your package hasn't made
| it out of NEW, then don't upload other packages that depend on it.
| Spend your time on something else.
|
| It will eventually get processed. There's nothing passive aggressive
| about what's happening. It's just how things work when you have
| volunteers doing stuff that requires a chunk of dedicated time to focus.
Thank you so much for a content-free and entirely useless message. Note that
I emailed here only after raised a voice because it was five + one week.
Now, in the last six months alone I must have had three or four packages in
NEW, and they never take more than two or three weeks. But then there are
exceptions : another related package (r-cran-aer, not mine) has been sitting
there for six months. It is impossible for me to tell "why". And you did
not help AT ALL with the more germane issue of us ("developers") being
entirely unable to get feedback of WHY a package HANGS when it does.
Which sucks. And is a FTBFS for my package.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
Dirk Eddelbuettel wrote: > The passive-aggressive "we won't work on your package, and won't tell you > why" is a wee bit annoying. This is an uncharitable interpretation of the situation. There is no deliberate witholding of information from you or any other maintainer; I — and the rest of the FTP team — are simply busy people. Anyway, I've processed your package. Please fix the missing attributions to (at least) Thomas Lumley on your next upload and, if possible, think carefully about making emotional requests on -devel in future. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On Sat, 2017-10-14 at 12:59 -0500, Dirk Eddelbuettel wrote: > Bumping this as my mail to ftpmaster went unanswered. > > Could someone please remind me who to ask about the NEW Queue? It is > causing > me a FTBFS as I need this Build-Depends for an existing package which > itself > has reasonably wide-spread (for an R package) reverse dependencies. > If it's in the NEW queue, the only people who can do anything about it are by definition the FTP Team. Regards, Adam
MBF: please drop transitional dummy package foo (if they were part of two releases or more)
Hi, I'm doing an small mass bug filing against obsolete transitional packages which are at least marked "dummy transitional" since the jessie release, though many of them existed already in wheezy. I think it's rather undoubtful those are normal bugs we want to get rid off. According to a script of mine there are 102 such packages without bugs filed left (see dd-list below) and 71 such bugs I have already filed. Plus there are 33 packages which were transitional dummy packages in jessie and stretch and are gone from sid! (My script ignores iceweasel*, icedove*, thunderbird* lightning* and multiarch-support as those are… special.) This is an example bug: (though the 2nd paragraph is rather exceptional.) On Sat, Oct 14, 2017 at 02:31:45PM +0200, Holger Levsen wrote: > Package: ttf-liberation > Version: 1.07.4-1 > Severity: normal > user: qa.debian@packages.debian.org > usertags: transitional > tags: pending > > Please drop transitional package ttf-liberation for Buster, > as it has been released with wheezy, jessie and stretch already. > > I'm on it and will upload in a week, to give gazebo7 a chance to update its > dependencies and not become broken in sid. The changes for fonts-liberation > are already prepared in my local git repo and will be pushed once I know this > bug number. (This is #878536.) I'm currently undecided whether I think it's useful to file wishlist bugs against transitional dummy packages which only are that since stretch. What do you think? Probably it's more useful to file wishlist bugs against packages depending on those… or should those be normal severity? -- cheers, Holger Adam Conrad glibc (U) Alan Baghumian fonts-liberation (U) Alex Pennace raspell (U) Alexander Wirt iproute2 monitoring-plugins (U) Alexandre Quessy lunch (U) Andreas Henriksson pygobject (U) Andreas Metzler libgcrypt20 (U) libtasn1-6 (U) luminance-hdr (U) Andrew Kelley node-on-finished (U) Andrew Shadura libixp Apollon Oikonomopoulos ganeti (U) Arjan Oosting pidgin-extprefs Arnaud Fontaine python-mechanize (U) Aurelien Jarno glibc (U) Bastiaan Franciscus van den Dikkenberg pgtop Bastian Blank parted (U) Brian Sutherland python-mechanize (U) Christian Kastner libcgroup Christian Perrier fonts-liberation (U) Clint Adams glibc (U) Colin Watson openssh (U) parted (U) Cédric Boutillier highlight.js (U) raspell (U) ruby-color (U) Dafydd Harries telepathy-rakia (U) Daniel Lintott libtime-parsedate-perl (U) Daniel Schepler knavalbattle (U) Daniel Silverstone netsurf (U) Debian Accessibility Team pyatspi Debian Electronics Team iverilog Debian Fonts Task Force fonts-liberation Debian Games Team mupen64plus Debian Ganeti Team ganeti Debian GIS Project hdf5 Debian GNOME Maintainers pygobject rarian Debian GnuTLS Maintainers libgcrypt20 libtasn1-6 Debian Islamic Maintainers monajat Debian Java Maintainers jfugue zookeeper Debian Javascript Maintainers highlight.js node-on-finished Debian Mono Group mono Debian Nagios Maintainer Group monitoring-plugins Debian Network Simulators Team tclcl Debian OCaml Maintainers gd4o mingw-ocaml Debian OpenSSH Maintainers openssh Debian Perl Group lemonldap-ng libtest-yaml-meta-perl libtime-parsedate-perl Debian PhotoTools Maintainers luminance-hdr Debian QA Group gadmintools-meta Debian Ruby Extras Maintainers raspell ruby-color Debian Security Tools Packaging Team samdump2 Debian Tasktools Packaging Team task Debian Telepathy maintainers telepathy-rakia Debian VDR Team vdr-plugin-svdrposd Debian Xfce Maintainers xfce4-screenshooter Debian/Kubuntu Qt/KDE Maintainers jovie kcron kde-baseapps kde-runtime kdeartwork knavalbattle kremotecontrol Debian/Ubuntu Zope Team python-mechanize Debichem Team mpqc Devid Antonio Filoni sushi Dmitry Smirnov ifenslave (U) Emilio Pozuelo Monfort pygobject (U) Enrico Tassi lua-bitop Eric Dorland libgcrypt20 (U) libtasn1-6 (U) Eshat Cakar jovie (U) kcron (U) kde-baseapps (U) kde-runtime (U) kdeartwork (U) knavalbattle (U) kremotecontrol (U) Eugeniy Meshcheryakov fonts-liberation (U) Fabian Greffrath fonts-liberation (U) Fabio Tranchitella python-mechanize (U) Fadi Al-katout (cutout) monajat (U) Fathi Boudra kcron (U) kde-baseapps (U) kde-runtime (U) kdeartwork (U) knavalbattle (U) kremotecontrol (U) Florian Schlichting libtest-yaml-meta-perl (U) Francesco Namuri virtualbricks Francesco Paolo Lovergine hdf5 (U) Francisco Manuel Garcia Claramonte trac-privateticketsplugin Francois Marier txlibravatar Frederic Peters rarian (U) Gennaro Oliva slurm-llnl George Kiagiadakis knavalbattle (U)
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On Sat, Oct 14, 2017 at 09:59:49PM +0100, Chris Lamb wrote: > Dirk Eddelbuettel wrote: > > > The passive-aggressive "we won't work on your package, and won't tell you > > why" is a wee bit annoying. > > This is an uncharitable interpretation of the situation. There is no > deliberate witholding of information from you or any other maintainer; > I — and the rest of the FTP team — are simply busy people. > > Anyway, I've processed your package. Please fix the missing attributions > to (at least) Thomas Lumley on your next upload and, if possible, think > carefully about making emotional requests on -devel in future. > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- > > -- http://fam-tille.de
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On 14 October 2017 at 21:59, Chris Lamb wrote:
| Dirk Eddelbuettel wrote:
|
| > The passive-aggressive "we won't work on your package, and won't tell you
| > why" is a wee bit annoying.
|
| This is an uncharitable interpretation of the situation. There is no
| deliberate witholding of information from you or any other maintainer;
| I — and the rest of the FTP team — are simply busy people.
Ok, let me rephrase. "At times in the past" there were delays simply do you
ftpmasters now expecting (in the case of R packages) debian/README.source to
explain the (data, binary, but for R also always already documented) .rda
files.
It would be so much simpler if "we" could just read the output, if any, that
is holding things back. The new package tracker is great and shows a lot,
but in order _for us to help you_ we need to know what you want us to change.
| Anyway, I've processed your package. Please fix the missing attributions
Thank you!
| to (at least) Thomas Lumley on your next upload and, if possible, think
He is not listed in DESCRIPTION:
Authors@R: c(
person("Jan Marvin", "Garbuszus",
email = "jan.garbus...@ruhr-uni-bochum.de", role = c("aut")),
person("Sebastian", "Jeworutzki",
email="sebastian.jeworut...@ruhr-uni-bochum.de", role = c("aut", "cre")),
person("R Core Team", role="cph"),
person("Magnus Thor", "Torfason", role="ctb"),
person("Luke M.", "Olson", role="ctb"),
person("Giovanni", "Righi", role="ctb")
)
though "R Core" is, and for many years they (ie R Core) assume copyright
jointly.
Where would you want me to make the attribution? debian/copyright?
| carefully about making emotional requests on -devel in future.
I will try. And where please should I send requests to ftpmaster ?
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On 14 October 2017 at 22:00, Adam D. Barratt wrote: | On Sat, 2017-10-14 at 12:59 -0500, Dirk Eddelbuettel wrote: | > Bumping this as my mail to ftpmaster went unanswered. | > | > Could someone please remind me who to ask about the NEW Queue? It is | > causing | > me a FTBFS as I need this Build-Depends for an existing package which | > itself | > has reasonably wide-spread (for an R package) reverse dependencies. | > | | If it's in the NEW queue, the only people who can do anything about it | are by definition the FTP Team. Thanks for confirming. My email went unanswered which is why I came here. I will try ftpmasters in the future, should the need arise. Thanks for all all of you do. We could not do this without you. It is appreciated. Dirk, back to packaging though probably tomorrow -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
[Sorry for pressing send to quick in my last posting] On Sat, Oct 14, 2017 at 09:59:49PM +0100, Chris Lamb wrote: > > The passive-aggressive "we won't work on your package, and won't tell you > > why" is a wee bit annoying. > > This is an uncharitable interpretation of the situation. There is no > deliberate witholding of information from you or any other maintainer; > I — and the rest of the FTP team — are simply busy people. > > Anyway, I've processed your package. Please fix the missing attributions > to (at least) Thomas Lumley on your next upload and, Thanks a lot for dealing with this issue that way. I assume that the wording that was choosen is not really motivating for volunteers. > if possible, think > carefully about making emotional requests on -devel in future. We several times observed that Dirk violates our Code of Conduct[1] in a non acceptable way - not sure how honest he will take your comment. I'd like to come back to the point Dirk intended to make. At first thanks a lot for processing lots of packages very quickly when developers explain good reasons for fast processing. In most cases I'm perfectly happy with the communication with ftpmaster when asking for helping with some packages. But there are rare cases when there is no communication between ftpmaster which is blocking development. I'd like to refer to an unanswered mail from April this year[2] where I tried to simplify the options to answer as much as possible. We as developers need some advise how to prepare packages to enable you easily accepting packages like r-cran-aer. I think we should use this debian-devel list for some communication between developers and ftpmaster to smoothen the process of new processing. Thanks again for your ftpmaster work Andreas. [1] https://www.debian.org/code_of_conduct [2] https://lists.debian.org/debian-devel/2017/04/msg00144.html -- http://fam-tille.de
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
[Drpopping -release from CC, they are busy enough] Dirk, > [Thomas Lumley] is not listed in DESCRIPTION He has a copyright attribution in R/read.R IIRC but there may be other instances and other copyright holders. You would make the reference(s) in debian/copyright like any other package. > > carefully about making emotional requests on -devel in future. > > I will try. And where please should I send requests to ftpmaster ? This sort of question is neither helpful nor productive I'm afraid. There is no secret contact channel that you seem to be implying; there just the simply the one that is read and processed by incredibly busy people. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
