Re: Notes on packaging PCYNLITX
Bagas Sanjaya wrote: Hello, I've filed RFP for PCYNLITX sometimes ago [1]: In PCYNLITX download page [2], it can be installed by using installation script. However, after examining install script, I noticed following: - PCYNLITX doesn't employ version numbering like any other project/packages. It would be difficult to identify which is the latest version. So I use version number 0.0~git20190606 in RFP report. I think convention is to add the git commit hash on the end of that as well, to pin down exactly which source version was used to build the package. IIRC the New Maintainer's Guide either has an example or links to another document that has one, so that your package versions sort properly. - The script install wxWidgets library from third-party repository, not from Debian. It use codelite repo (for Stretch): apt-add-repository 'deb http://repos.codelite.org/wx3.0.4/debian/ stretch libs' Your package will have to depend on the stock Debian version of this library, unless there are specific modifications in this other version that are strictly necessary. If the modified version of this library is necessary, it must also be packaged within Debian, or at least shipped in the source and binary package you're creating (and strongly justified if you do this); adding third-party repositories isn't acceptable. - Evince will be installed as runtime dependency, possibly for documentation. For non-GNOME users (KDE, XFCE, etc.) which use different readers (like Okular and Atril) this can bloat their system and become unnecessary. Unless the software itself actually uses evince internally, you don't need dependencies on anything for reading documentation. - All steps are performed using sudo. If the script is run by root user, this will be redundant, since the installation is done by root privileges. If I will packaging PCYNLITX for Debian, any suggestions, assuming that I have read New Maintainers Guideline and related Debian packaging documentation? You will have to inspect and understand the steps that installer script takes, and convert that into a proper Debian package based around either: - the upstream tarball retrieved in the first command that script runs, or: - a git commit or tag Without inspecting the tarball itself, based on the dependencies it installs it looks to me as if it just contains precompiled binary files; this would not be acceptable in Debian's main archive, or in contrib. It *may* be acceptable in non-free. Check the build process that creates that tarball from the upstream git repository; you may have to base your package entirely on the git repository rather than any of the bundled "release" files. -kgd, just a moderately experienced observer on the packaging process
Re: Bug#922643: ITP: build-alternative -- helper to build Debian package with diet libc
Dmitry Bogatov wrote: [2019-02-21 00:00] Guillem Jover On Mon, 2019-02-18 at 19:37:38 +, Dmitry Bogatov wrote: Package: wnpp Severity: wishlist Owner: Dmitry Bogatov * Package name : build-alternative Version : 0.0.1 Upstream Author : Dmitry Bogatov * Url : https://salsa.debian.org/kaction/build-alternative * Licenses : GPL-3+ Programming Lang : shell Section : devel This package provide makefile snippet, that abstract away several issues, related to building package with diet libc. . * diet libc is not supported on every Debian architecture * code to check for build profiles is repetive . Regular users do not need to install this package, it is only useful to Debian Contributors. Hmm this package name looks extremely generic for what it is described to be used for. Could you name it something else that includes either dietlibc in its name or at least libc or similar? I do not exclude, that it may include support for musl for future. I am not sure, whether overly generic name now is worse then misleading source package name in future. Reading the description and the objections, maybe a name like "alternate-libc-build-helpers"? -kgd
Re: Knowing the release names in advance
Dmitrijs Ledkovs wrote: $ man debian-distro-info Serious question - is this a real manpage? If so, which package is it in? I don't seem to have it available by default on any Debian system at hand, from etch through wheezy... Debian OS provides API to query such information. Second serious question - what is this API? I asked something along this line a number of years ago, and most of the responses could be summed up as a combination of a bewildered Why would you want/need to do *that*?!? and Your question has no useful answer because insert edge case. -kgd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e1b18e.8020...@vianet.ca
Re: RFC: OpenRC as Init System for Debian
Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, I'm curious exactly what you mean by this, since my own experience has been that rpm is more flexible than dpkg. -kgd, longtime RedHat-er torn between a distro that I get along with and a distro with at least three kitchen sinks included -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fabcd92.4060...@vianet.ca
Re: network-manager as default? No!
Josselin Mouette wrote: For a machine with an IP address assigned by DHCP, which is a very common setup even on servers, ... I have to ask: What sort of overall network setup would you be using, where server IP addresses are assigned by DHCP? I'm having trouble imagining any remotely common setup where this might be done. -kgd, no particular stake in the N-M vs ifupdown debate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da8565e.8070...@vianet.ca
Re: network-manager rant
Anssi Kolehmainen wrote: Hi all, I just updated packages (which upgraded network-manager to 0.8.1-6) and then rebooted computer. I was greeted with a five minute wait while ntpd tried to query dns which was broken since network-manager decided to start, ignore bridge mappings, do dhcp on physical port of the bridge (which of course breaks the bridge) and clearing out /etc/resolv.conf. Again. I've fixed irregular meddling with my resolv.conf on Debian and other distros by: a) Remove resolvconf, by force if necessary b) chattr +i /etc/resolv.conf (yes, I *did* find once instance where this was necessary shudder) -kgd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d2e2375.5030...@vianet.ca
Re: Syslog file paths in 'metalog'? (#423299)
Milan P. Stanic wrote: On Thu, Dec 06, 2007 at 01:11:32PM -0500, Kris Deugau wrote: In general, I would say as a sysadmin that any syslog daemon that does not allow me to configure any given log facility and priority to (at least!) an arbitrary file wherever I want it is inherently broken. What do you mean by configure any given log facility and priority to an arbitrary file? Literally and exactly that - I want to be able to tell it to put daemon.* in /var/daemonlogs/mainlog, mail.info in /var/mailbits/mail.info, mail.debug in /tmp/debuglogs/maildebug.log, and just to be perverse (and more than a little silly) auth.crit messages in /auth-crash-and-burn. Note that those are ALL fully qualified filename paths. If I really *want* -mm-dd-hh-mm-ss date info in my log filenames, I'll configure the log daemon to do so (assuming it can do so semi-automatically). I've had legitimate reason in the past to configure one of the local* facilities to put the log in my home directory. -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Syslog file paths in 'metalog'? (#423299)
Christoph Haas wrote:
Fellow Debianistas...
At work we are using syslog-ng a lot and it's very useful for a central
logging server. However I don't like the syntax because it's verbose and
typo-prone. So I was looking at metalog and seeing it orphaned I decided
to adopt it (#423299). I've started bringing the package into good shape
again. There is just an issue with the paths and files where metalog
writes syslog informaton to. The difference to the sysklogd...
sysklogd:
/var/log/mail.log
/var/log/mail.log.0
/var/log/mail.log.1.gz
/var/log/mail.log.2.gz
Mmmh. Strictly speaking, sysklogd logs mail to /var/log/mail.log, along
with duplicating (!!) much of the content to (IIRC) /var/log/messages
and /var/log/mail.{err,info,warn}. .0, .1.gz, etc are created by the
non-logrotate widget Debian uses for rotating system logs.
In general, I would say as a sysadmin that any syslog daemon that does
not allow me to configure any given log facility and priority to (at
least!) an arbitrary file wherever I want it is inherently broken.
Bonus points for log-to-pipe, extra credit for simple, useful
redirect-to-remote-system capabilites. Built-in log rotation is nice
to have but it's Yet Another Log Rotator, and IMO there are already too
many fingers in that pie.
-kgd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Lennart Sorensen wrote: For the kind of cash the enterprise vendors tend to charge, yes actually now that you ask, I think I can expect them to figure out dependancies and making proper packages. ... by making reasonable assumptions about what is on the system based on a standard install of $version of $distribution. Asking enterprise vendors to support your (customised, hacked-up, non-standard) OS install is, um, unlikely. Unless you're paying them enough for them to completely mirror your environment in the dev lab and certify their product on *your* particular combination of software. (Of course, most people running mixed-version Debian systems are unlikely to be buying enterprise software like Oracle. g) (This is drifting off from my original question: what simple test(s) for uniqueness can I use to determine which version of which distribution I'm on? FWIW, it seems that for my purposes, the contents of /etc/debian_version and the full version+release string from the base-files package are sufficiently unique.) -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
(I keep looking at what I've written, and thinking That's not quite right or I'm forgetting some critical argument or That sounds very argumentative/rude but I can't think of a better way to phrase it. I *have* gotten an interesting discussion out of this thread, however.) Santiago Vila wrote: That's the fundamental mistake I see here: We should not be telling programs what release they are running to begin with. We do not try to make packages to work under the assumption that they will run on a sarge system or an etch system. Instead, we try to make them work as far as their dependencies are met. ... which means what, exactly, if my program expects /usr/lib/apache2/suexec but the system (stock Debian sarge) only has /usr/lib/apache2/suexec2? Or vice versa for etch? (Or more accurately, I need to know in advance - in this case, at package build time - which name suexec gets so that the Apache config fragment I drop in doesn't break.) OK, so if it's one file I can munge in a solution that checks at install time or something. What about a case where there are *hundreds* of little things like this with complicated subcases? This is the simplest, most prominent example I've run into, but it's far from the only one. Most of the rest are somewhat convoluted and specific to local systems (and a few are related to how I'm building packages to avoid Debian Policy limitations that conflict with local policy), but they're very real. I'm not trying to find something that includes (or resembles) significant fractions of the hairy mess that is an autotools configure script (g), but a reference I can use to make reasonable assumptions about what should be on the system if it hasn't been hacked fifteen different directions with source installs of half the major subsystems which rely on backports and packages from experimental. (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ADV: Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Frank Lichtenheld wrote: On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote: (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. g) ? I don't see that beeing said in the thread. Could you point out that for me? Hmm. Not explicitly stated, nor really implied, but several people commented that a system may have backported packages, packages from testing/unstable/experimental, software that's installed from source and which the package manager is therefore completely unaware of - in other words, no matter what you might find in /etc/debian_version or some other nominal reference, the configuration and binaries on the system may not resemble a stock install of that release at all. Taken to the extreme, that leads me to the conclusion that Packages Are Useless. g (Taken another couple of steps, it leads to Everyone should be running Linux From Scratch.) (I don't really think so, and I think the argument about The local admin may hack the system up until it resembles Swiss cheese so why bother doing x has been beaten well beyond death in other threads I've seen recently.) Mostly just an impression I got from the trend of some of the responses. -kgd, wondering how one would go about bootstrapping LFS raw from a stack of printout and a single modern desktop machine, with no source of precompiled executables. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
The Fungi wrote: On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote: [...] On RHEL and derived distros, there's usually a file /etc/redhat-release (sometimes renamed, but usually trivially enough that it can be found with little trouble) containing both the distro code name and the version number. [...] Not to be patronizing, Don't worry about that. g but you are aware of the /etc/debian_version file, yes? No. g But now I am. It's looking more promising that any other approach, too. -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is there a way to positively, uniquely identify which Debian release a program is running on?
I've been writing custom utilities and libraries for various systems at work, and with one particular project recently it's become (more) important to know exactly which Debian release it's running on (at some stage or other between version-controlled-code and installed-binary) so that I don't try to call a missing binary or create a .deb that requires a package that doesn't actually exist in the target dist. (Apache's suexec is one particular example; it's /usr/lib/apache2/suexec2 on sarge, but /usr/lib/apache2/suexec on etch. I could solve that particular case with some hackery in one of several possible places, but it's a little harder for things like package dependencies that have to change a little between different releases or distros.) However, there doesn't seem to be any single, consistent, doesn't-change-for-the-life-of-the-release, programmatically possible (never mind *easy* just yet...) method to find out if I'm on Debian sarge, etch, lenny, or some third-party Debian-derived distribution. Nor does there seem to be any similar indicator to see if I'm on Debian 3.0, 3.1, 4.0, or whatever version list a third-party distro is up to this week. (Side note: When is the number version of a new release decided?) On RHEL and derived distros, there's usually a file /etc/redhat-release (sometimes renamed, but usually trivially enough that it can be found with little trouble) containing both the distro code name and the version number. It may change a little on point releases, but it's stable, consistent, and unique to each release. Some searching turned up a suggestion to use the glibc version as a reference... which might be OK if there weren't so much overlap between releases. :( (I checked woody, sarge, etch, and lenny. There was overlap between woody and *etch*, IIRC. Ewww.) -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release critical bug in apache2.2?
sean finney wrote: i imagine the apache maintainers will argue that it should be either (a) the webapp package or (b) the php apache module's repsonsibility to specify the additional DirectoryIndex. iirc DirectoryIndex does/can append to the list of index files, right? This is exactly what I did for a set of custom Apache2+PHP packages; it works fine. -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem of savelog
Atsuhito Kohda wrote: I found yesterday that mails were not delivered since about 6:30 in the morning so I investigated a problem and found that /var/log/exim/paniclog said /var/log/exim/mainlog had a wrong owner/permission; [snip] However I found today that the situation was worse than yesterday; not only wrong owner/permission of mainlog -rw--- 1 root adm 0 2005-02-17 06:33 mainlog but also wrong owner/permission of paniclog(?) -rw--- 1 root adm 0 2005-02-17 06:33 paniclog so paniclog told me nothing today. Ouch. I can't say I've seen that type of problem; although just about everything on any of my Debian systems logs through syslog. I suspect that savelog in /etc/cron.daily/exim didn't work correctly but I couldn't find any bug in BTS. [snip] Is there anyone who encountered the same problem or is this Alpha specific or even specific to my machine? I haven't met up with that specific problem (except where I've made nonstandard configuration changes that caused permission errors - usually with ClamAV), but I *have* very carefully made sure that logrotate is doing my log rotation instead of savelog on all my logfiles. I could never get savelog to operate correctly for my usage. -kgd -- Get your mouse off of there! You don't know where that email has been! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recent spam to this list
Julian Mehnle wrote: Kris Deugau wrote: OK, I think I've thought of a sort of a counter-example: [...] I'm sending from myfriendsdomain.com's server, but I don't have an account there. ^ I do, however, have an account [EMAIL PROTECTED] on my own server- to which I want all replies/bounces/etc to go to. Why don't you use [EMAIL PROTECTED] as the envelope-from and [EMAIL PROTECTED] as the From: header field? Replies will go to [EMAIL PROTECTED] This is OK, and proper... , while bounces will go to [EMAIL PROTECTED]. But this is bad. My friend will get a bounce for a (possibly personal) message from me to a third party, which he supposedly has no interest in seeing. About as bad as using the nonexistent [EMAIL PROTECTED] I wouldn't see the postmaster notification in either case because no email address actually associated with me personally was involved in sending my original message, except in user-generated headers that SMTP systems are, by design, supposed to ignore. If your friend's server is configured correctly, it won't send out-of-band bounces (bounces as stand-alone messages, instead of a bounce reply code in the SMTP dialog) to foreign (non-local) servers anyway (to mitigate joe jobs on innocent bystanders whose address was used as some spam's envelope-from). *shrug* If it's running any reaasonably recent Linux-based SMTP service, for the simplest case of all local users are full local accounts, for all domains accepted as local, it will generate any such rejections at SMTP time, and most others as well. It would NOT blindly relay mail from myfriendsdomain.com. For example: Case #1: I send a message to [EMAIL PROTECTED], while at this LAN party. I use an SMTP envelope address of [EMAIL PROTECTED] I mistype the destination address, so within 5-10 minutes or so, there is a postmaster notification (generated on the server hosting myfriendsdomain.com), telling me that the message couldn't be delivered because the recipient doesn't exist. OK, no problem; I can see clearly that I've mistyped something, and I can resend the message to the correct destination. No problem. Case #2: I send a message to [EMAIL PROTECTED], while at this LAN party. I use a (nonexistent!) SMTP envelope address of [EMAIL PROTECTED] I mistype the destination address, but because the SMTP return address is local, the server tries to deliver to that account. Since that doesn't exist, it bounces again to [EMAIL PROTECTED] I receive no indication that the message was *not* sucessfully (and properly) passed on to its intended destination, so three days later when talking face-to-face with [EMAIL PROTECTED], I get a little confused that he didn't get the email I sent three days earlier. Case #3: I send a message to [EMAIL PROTECTED], while at this LAN party. I use a (nonexistent!) SMTP envelope address of [EMAIL PROTECTED] I mistype the destination address, but because my first friend's address was used as the SMTP envelope sender, the bounce goes to his account. I receive no indication that the message was *not* sucessfully (and properly) passed on to its intended destination until he checks his mail- or spam folder g, so three days later when talking face-to-face with [EMAIL PROTECTED], I get a little confused that he didn't get the email I sent three days earlier. IIRC the original question was answered to the satisfaction of the person who asked it. Listing the servers allowed to send mail from your domain, as a part of your DNS, makes perfect sense to me... all you have to do is track down the IPs of those machines. g -kgd -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
Re: recent spam to this list
Julian Mehnle wrote: Andreas Metzler wrote: Julian Mehnle [EMAIL PROTECTED] wrote: It's about forging an e-mail sender's identity. By preventing the unauthorized use of domains as the sender domain of e-mails, most of the practiced cases of identity forgery are prevented. [...] If I send an e-mail over mail.nusrf.at with envelope-from [EMAIL PROTECTED] I am _not_ forging anything or making unauthorized use of domains Yes, you are. The envelope-from address is not a reply-to address, it's a sender address. If you are sending from mail.nusrf.at, you are not sending from logic.univie.ac.at. So you should not specify [EMAIL PROTECTED] as the envelope-from address, or you'd be forging it. OK, I think I've thought of a sort of a counter-example: I have a private server, and an account there. I have a friend with a private server, but I do NOT have an account on that box. (Unlikely but possible; I can think of one real-world case amongst people I know running private servers.) While at a LAN party at that friend's place, I check my mail on my server, and decide I want to reply to some of the messages. Since we're both on semi-dynamic IPs (connected 24/7, but not formally assigned static IP addresses), I haven't allowed SMTP relay from the IP my friend's server is on, because I don't really know what it is today/this week/this month. But his server allows relay mail from machines on his private network, so I use his server as a relay for my mail. I'm sending from myfriendsdomain.com's server, but I don't have an account there. I do, however, have an account [EMAIL PROTECTED] on my own server- to which I want all replies/bounces/etc to go to. I'm not sure this actually has any direct relevance to this dicussion (which I gather is about a DNS-ish way to restrict which machines can relay mail for any particular domain, according to the wishes of that domain owner), but I think it might be a useful example. -kgd -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
