Re: non package names in by_inst file of popcon
On Sat, Sep 3, 2016 at 10:47 PM, Paul Wise wrote: > On Sun, Sep 4, 2016 at 10:18 AM, kamaraju kusumanchi wrote: > >> where the second field is not a valid package name. Can someone please >> tell me if this is expected or if I should inform someone of the >> problem? > > Bug #833695 was already filed about this issue. > Thanks for the pointer, Paul. -- Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog
Re: freeradius needs a new maintainer
On 03/09/16 14:48, Thomas Pierson wrote: Hi, I'm also interested because I use freeradius at work and on some other non-profit projects too. I already maintain some packages in Debian as a DM only but I don't have a lot of experience. So Martin, Vito, please tell me if you need more help and how do you plan to work on this? I'm much in the same boat as you Thomas. I used to maintain a few packages in Debian, but they've been superseded, so there was no need for them anymore. My experience would hence be a bit outdated. I use freeradius extensively for work and some non-profit projects. Seans suggestion to maybe maintain this in the collab git repository is a good idea. It makes sense, to have more than one maintainer working on this, so that we keep it updated more frequently and it doesn't end again, like it did right now. /M
Re: freeradius needs a new maintainer
Hi, I'm also interested because I use freeradius at work so if you want I'm happy to help. Il 04/Set/2016 12:57, "Martin List-Petersen" ha scritto: > On 03/09/16 14:48, Thomas Pierson wrote: > >> Hi, >> >> I'm also interested because I use freeradius at work and on some other >> non-profit projects too. >> I already maintain some packages in Debian as a DM only but I don't have >> a lot of experience. >> >> So Martin, Vito, please tell me if you need more help and how do you >> plan to work on this? >> >> > I'm much in the same boat as you Thomas. I used to maintain a few packages > in Debian, but they've been superseded, so there was no need for them > anymore. My experience would hence be a bit outdated. > > I use freeradius extensively for work and some non-profit projects. > > Seans suggestion to maybe maintain this in the collab git repository is a > good idea. It makes sense, to have more than one maintainer working on > this, so that we keep it updated more frequently and it doesn't end again, > like it did right now. > > /M > >
Subjects and threads
Adam D. Barratt: > I'm sure I'm not the only one irritated by this, Then you should be looking at the Debian software that drives https://lists.debian.org/ , which seriously mucks up subject processing, and not at us poor users who are long-suffering under it. Debian software gets References: wrong, too; which is in fact the way that one recognizes replies. See RFC 2822 §3.6.5, which points out that Re: is not what you think it is and describes just some of the processing that Debian software is not doing (Try subjects with reserved punctuation characters for even more fun!), and RFC 2822 §3.6.4, which talks about replies and the References: header. * https://jdebp.eu./Proposals/gnksoa-mua.html#ProperThreading If you had directed your irritation to the bug area for the Debian software rather than at the poor Debian software end-users, you would have found that several bugs about some of these very things were filed years ago, and remain unfixed to this day. As a Debian Developer, you could probably fix these bugs.
Re: Subjects and threads
On Sun, Sep 04, 2016 at 12:59:47PM +0100, Jonathan de Boyne Pollard wrote: > If you had directed your irritation to the bug area for the Debian software > rather than at the poor Debian software end-users, you would have found that > several bugs about some of these very things were filed years ago, and > remain unfixed to this day. As a Debian Developer, you could probably fix > these bugs. this list is for the development of Debian by people interested in doing so. Please take your rants elsewhere. Thanks. -- cheers, Holger signature.asc Description: Digital signature
Re: Subjects and threads
On Sun, 2016-09-04 at 12:59 +0100, Jonathan de Boyne Pollard wrote: > Adam D. Barratt: > > > I'm sure I'm not the only one irritated by this, > > Then you should be looking at the Debian software that drives > https://lists.debian.org/ , which seriously mucks up subject processing, Strangely, it doesn't seem to do that for anyone else that I've ever noticed. > and not at us poor users who are long-suffering under it. Debian > software gets References: wrong, too; which is in fact the way that one > recognizes replies. Your messages have the References correct, so they thread properly. However, if the message(s) being replied to have already been deleted from the folder, there is usually no visual indication that a new message is a reply other than 'Re:'. > See RFC 2822 §3.6.5, which points out that Re: is not what you think it is Mailing lists have conventions to make them easier for people to read, that go beyond requirements of any standard. You are not following convention and you have not given any reason for this. > and describes just some of the processing that > Debian software is not doing (Try subjects with reserved punctuation > characters for even more fun!), and RFC 2822 §3.6.4, which talks about > replies and the References: header. > > * https://jdebp.eu./Proposals/gnksoa-mua.html#ProperThreading [...] This URL still doesn't work. Maybe fix that before you start lecturing about standards? So you've decided to invent and follow your own 'standard'. Great. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Subjects and threads
On 2016-09-04 at 07:59, Jonathan de Boyne Pollard wrote: > Adam D. Barratt: > >> I'm sure I'm not the only one irritated by this, > > Then you should be looking at the Debian software that drives > https://lists.debian.org/ , which seriously mucks up subject > processing, and not at us poor users who are long-suffering under it. > Debian software gets References: wrong, too; which is in fact the way > that one recognizes replies. Counterpoint: I see messages threaded hierarchically under one another, as is correct, with no issues, on all Debian mailing lists to which I subscribe. Checking a few messages randomly (from this thread, including at least two of your own) shows that the References: header is populated, and that the Message-ID(s) with which it is populated refer to the parent message in the thread and/or to the grandparent, exactly as would seem to be appropriate. IOW, the evidence immediately available to me seems to indicate that your claim is not correct. Moreover, even if the mailing list software did/does get this wrong, that would not be an excuse for dropping the Re: from the Subject line. That flag is not only (and, indeed, properly not at all) for use by the mail client; it is also to provide information to the person who reads the mail, as it provides a better indication that "this mail is a reply" than is otherwise available at a glance. (Certainly the mail-reader cannot be expected to check References: headers manually every time they look at the list of available messages.) To arbitrarily drop that additional flag would require more reason than "just because". -- 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: Porter roll call for Debian Stretch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 17 Aug 2016 22:05:06 +0200 ni...@thykier.net wrote: > Like last release, we are doing a roll call for porters of all release > architectures. If you are an active porter behind one of the [release > architectures] for the entire lifetime of Debian Stretch (est. end of > 2020), please respond with a signed email containing the following > before Friday, the 9th of September: > Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Stretch release (est. end of 2020): For armel, I - submit device-tree patch to upstream (linux kernel), and backport to debian kernel to get more devices supported - support new device for d-i and flash-kernel package - test most packages on this architecture - run Debian stable / testing / unstable system on port that I use regularly - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues I am a DM. Altough I enabled -fPIE/-pie for most of my maintaining packages, I'm not sure / I don't have enough knowledge whether it's able to be applied to all packages. Since all other ARM porters seem agree on this, I believe it definitely deserves a try to enable this hardening on stretch. Cheers, - -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXzEFiAAoJEKR4aw2nAzSoAekP/j4eNf0jKvmArPlPbhA7XkBk /5u9Un4qOHBNcSMAU5YVLHkpnT1CX/C08W+/ctGbB9AnnRwyn8X0uailjedZ13jK oZYW/kUSwWiPmOkRTeNgFepzuKL+TNsAGgjHOY4ZbzYKC+h9C0UNWwyA77L3GUep 3HA9eTrtxMAAvJPNN4AhOjMeCI3qXIZ+wLKjhT+u/OUETWly8MolBw8PUjjwW6yy Va7ciRMQf8KL149+Pa/tYFaENoAOV6//3M2QkJyaGbfxJp3xiFFcrlw+kw6J4RyH vNIewz78nZwN88Y7JWa2EdBVcJr0897REXpDPXK/OpzlWw0R0xqB86jtmHfc+rQJ IiNGt5Uc4Y3mD04O6AEDDJFJnEQ/QLi8OR8/TuxHiBJ6JTv0m67KsJVgdFqeRnlz wJqcIQAzTF1iixVXjreVqW6P/+pGNHDbh9APfUz+UV97sZ4tD2BV1K1Rgk7cPDCn zcpVhkQRy5PzLmK315vb8h9juFDDS/18yzmXwGMnmIhv4+8GBJIQLm5gvk9NuEbw V/hBC42+fqX6RzGCoV3M8V+A6aLSpG/BcIAQOx8ewVfzMHIFSJmYParCHKXdiX+z WB8UBt2xCHuzg98jxU80UwR492X9WvKeb6xA8dKqOW22XzsLxaQTe+SLSaGQ7er2 cpuhCpYFDKj/TL6UE2f9 =Vckg -END PGP SIGNATURE-
Mass bug filing: use and misuse of dbus-launch (dbus-x11)
Simon McVittie: This can already work. If you put XDG_RUNTIME_DIR in user programs' environment, and arrange for your favourite service manager to make a dbus-daemon (or something else that speaks the same protocol) listen on $XDG_RUNTIME_DIR/bus before any user process would try to connect to it, then modern versions of at least libdbus, GDBus and sd-bus will connect to it by default with no additional effort on your part. This client-side code path does not depend on systemd, does not depend on libsystemd (except obviously sd-bus which is part of libsystemd), and is compiled in for all supported Unix platforms. That's the problem. No the whole unix:runtime=yes mechanism is not. As I said, this is something that you and Joe Marcus Clarke and whomever else have to sort out with each other. I'm unfortunately stuck in the middle, here. Please do whatever it is that you need to do with each other to make your program understand address=systemd: and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not do so. Simon McVittie: Meanwhile, if you want the relevant integration files (your favourite service manager's equivalent of systemd units) to be part of dbus (the reference implementation of D-Bus), please propose tested patches; if they follow the "user session" model[1], they could eventually go in dbus-user-session.deb, with its dependencies changed from the current systemd-sysv to "systemd-sysv | your-service-manager". Kudos for being the first project to offer integration, ever. (-: Yes, down the road it would be marvellous if people included service bundles in their own projects. Yes, I'd like to see the day when the number of service bundles in the nosh-bundles package actually starts going down, because people are taking on shipping their own service bundles for their own services, instead of going up. So yes, eventually you'll be taken up on that offer I hope. But one step at a time. Simon McVittie: As for what I would like, I'd like you (where that's plural, including Joe Marcus Clarke or whomever else) to please make either address=systemd: or address=unix:runtime=yes work in your program on FreeBSD/PC-BSD/OpenBSD. To the best of my knowledge, the listenable address "unix:runtime=yes" (as in "dbus-daemon --address=unix:runtime=yes") does work on generic Unix, and should interoperate fine with the XDG_RUNTIME_DIR/bus fallback used by clients with no DBUS_SESSION_BUS_ADDRESS. It is compiled and tested whenever DBUS_UNIX is defined (i.e. everything except Windows), and I haven't seen bug reports about that test failing. There you go, then. New knowledge. (-: It doesn't work with your program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is the porter for FreeBSD, according to the port information, and Antoine Jacoutot the porter for OpenBSD. This is why I am saying that it's something that you (plural, remember) need to sort out amongst yourselves. We users stuck in the middle cannot use address=systemd: and address=unix:runtime=yes with your program on these systems. As I said, it's something that I had to fix in November 2015, to stop trying to use address=systemd: on FreeBSD/TrueOS because it turned out that it didn't actually work. I thought that address=unix:runtime=yes might, but that did not either. Simon McVittie: I am *not* going to go looking for patches on display at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "beware of the leopard"; Luckily, you didn't need to. The page that I hyperlinked before pointed directly to Pierre-Yves Ritschard's and Cameron T. Norman's actual code, even down to positioning the window around the first lines of the functions. Now if one *did* want to follow the Debian way of having mention of these things buried down in the depths, in a bug report from years ago, then this is a truly excellent example of the genre that one could enjoy. One should begin with Cameron T. Norman's post here, roughly one thousand eight hundred messages down, in a bug report from 3 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1859 (-: Simon McVittie: To be brutally honest, there is a fairly low limit to how much benefit I can create by giving new things to PC-BSD users, [...] That's not the right way to look at it. You yourself have just said several times that this is stuff that is supposed to be on "supported Unix platforms". This isn't giving new things to anyone. This is making existing things, that you yourself think are existing, work. I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD (now rebranded as TrueOS Desktop a few days ago -- I just got through changing a whole load of preset file and -run package names.) is the BSD that comes in the box with the desktop environments and with all of the desktop programs that use Desktop Bus. Yes, people can and do run
Mass bug filing: use and misuse of dbus-launch (dbus-x11)
XDG Base Directory Specification:
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message
Simon McVittie:
Are you saying that if XDG_RUNTIME_DIR is not set, D-Bus client
libraries should choose some arbitrary other directory that is
conjectured to have the same properties that the XDG_RUNTIME_DIR spec
guarantees, look for a ./bus socket in *that* directory [...]?
Simon McVittie:
Using the same concrete value for the name of the XDG_RUNTIME_DIR that
systemd does (/run/user/$numeric_uid) seems advisable, [...]
These two fit together, you know.
You think that a good "replacement directory" is /run/user/$EUID .
Alright. Then when your program is told address=unix:runtime=yes and
there's no XDG_RUNTIME_DIR, please make it fall back to using the
directory that you think is the advisable directory to use. (-:
At the moment, as far as I can see, when there's no XDG_RUNTIME_DIR
there's no fallback per the XDG specification at all. We all know that
XDG_RUNTIME_DIR has been a thorn in people's sides for years, where
there is a mismatch between the owner of the runtime directory and the
process' effective user. The irony is that you and your program would
get quite sensible behaviour without it, were you to make
address=unix:runtime=yes actually do the thing that you are here saying
is advisable. In the cases where address=unix:runtime=yes is used, and
when they are all doing what you say is advisable, your servers set up
their sockets in {/var,}/run/user/$UID/dbus_blah and your clients go
looking for those sockets in the same place, picking the right one for
the process' effective UID and rendezvousing in the right place.
And the people who still want XDG_RUNTIME_DIR still get to have it, and
all of its do-we-or-do-we-not-follow-euid-changes-maybe-sometimes joy
that the world has come to know and love.
This as well as having made address=unix:runtime=yes actually work in
the first place, of course. (-:
Bug#836703: ITP: gnome-autoar -- Archives integration support for GNOME
Package: wnpp Severity: wishlist Owner: Michael Biebl * Package name: gnome-autoar Version : 0.1.1 Upstream Author : Ting-Wei Lan * URL : https://git.gnome.org/browse/gnome-autoar/ * License : LGPL-2.1+ Programming Lang: C Description : Archives integration support for GNOME GNOME Autoar is a library to integrate compressed files management within GNOME applications. It's a new dependency in GNOME 3.22 and will be maintained by maintained by the pkg-gnome-maintainers team.
Re: Introducing default-mysql-* metapackages
Folks, could you elaborate a bit more why you are forcing all Build-RDeps to change B-D to default-libmysqlclient-dev instead of just changing the semantics of libmysqlclient-dev? I understand the default-mysql-client and default-mysql-server, but I don't understand the change from libmysqlclient-dev to default-libmysqlclient-dev. We have a couple of similar cases that doesn't require that much work (f.e. libjpeg-dev) and renaming the original libmysqlclient-dev to libmysqlclient-oracle-dev and adding Provides: libmysqlclient-dev to libmariadbclient-dev would achieve the same thing and require a substantially less work on the other people side. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba všeho druhu On Sun, Sep 4, 2016, at 09:14, Otto Kekäläinen wrote: > Hello maintainers of packages that depend in MySQL/MariaDB! > > TL;DR; > > Please update packages that depend on MySQL or MariaDB as follows: > > BEFORE: Build-Depends: libmysqlclient-dev > AFTER: Build-Depends: default-libmysqlclient-dev > > BEFORE: Depends: mysql-server | virtual-mysql-server > OR Depends: mariadb-server | virtual-mysql-server > AFTER: Depends: default-mysql-server | virtual-mysql-server > > BEFORE: Depends: mysql-client | virtual-mysql-client > OR Depends: mariadb-client | virtual-mariadb-client > AFTER: Depends: default-mysql-client | virtual-mysql-client > > > Details follow: > > The release team decided earlier in the spring that MariaDB should be > made the default MySQL variant in Debian. The release team also wished > to have a facility that allows easy switching of the default. > > Therefore we have introduced the following metapackages > from the mysql-defaults source package: > - default-mysql-server > - default-mysql-server-core > - default-mysql-client > - default-mysql-client-core > - default-libmysqlclient-dev > > All maintainers of packages that currently depend directly on > mysql-server, mariadb-server, or any of the other packages in these > series, shall update the dependencies in their packages to point to > default-mysql-* instead. > > Installing the metapackage default-mysql-server will pull in > mariadb-server-10.0. Users who had mysql-server-5.6 will have it > removed and replaced by the MariaDB equivalent on upgrade. Note that > once you have switched to MariaDB, it might not possible to convert > your in-place database files back to MySQL automatically, since Oracle > does not maintain tools to convert possible MariaDB features present > in the binary format. Please back up your data first if you wish to > switch or experiment. Manual dump/import is the most reliable way to > import data from one installation to another. > > A virtual package scheme virtual-mysql-* already exists since 2013, > and will continue to exist. All MySQL variants in Debian (and outside > in 3rd party repositories too) have Provides for these virtual-mysql-* > packages. Maintainers can must use "Depends: default-mysql-server | > virtual-mysql-server" if their package can be satisfied by any MySQL > variant (Oracle, MariaDB, Percona, mysql-wsrep). > > The first dependency should be default-mysql-*, which is a > metapackage, that in turn depends on exactly one option, which for now > is MariaDB. > > If a maintainer knows that his/her package only works with one > variant, then the package can depend directly on that package and not > use the default-mysql-* (matches one) or virtual-mysql-* (matches any) > schemes. Please get in touch if this applies to you. At the moment > there should be no such packages, but in the future cases like this > can arise when MySQL and MariaDB develop diverging feature sets. > > Packages built against default-mysqlclient-dev and link using > "-lmysqlclient" will end up with a shared library dependency on either > libmysqlclient.so.X or libmariadbclient.so.X depending on the default > defined by the release team at build time. These will be provided by > the libmysqlclient18 (soon to be libmysqlclient20) and > libmariadbclient18 packages, which will be co-installable. Packages > which require particular functionality available from only one of the > forks may Build-Depend directly on libmysqlclient-dev or > libmariadbclient-dev and then link using "-lmysqlclient" or > "-lmariadbclient" respectively. Again, please get in touch if this > applies to you. > > Users that want to rebuild packages against a different variant of > lib*client-dev for experimenting and testing locally should prefer > using a locally modified default-libmysqlclient-dev over modifying > each client application source package individually. > > The default-mysql-* metapackages have been available in experimental > since July, and since also in unstable and testing, and we are > confident there are no regressio
