Re: Developer repositories for Debian
El Dilluns, 11 de maig de 2015, a les 11:52:13, Paul Wise va escriure: > On Sun, May 10, 2015 at 11:48 PM, Leopold Palomo-Avellaneda wrote: > > people.d.o AFAIK is _only_ for DD. Anyway, if I can see it correctly it's > > only web space. > > > > My ppa propose could be also useful for Debian members. I think that new > > packages, are controller by ftp-masters, so any help to create a new > > package could be welcome. > > I think you may have misunderstood the proposal that this thread is > about. The proposal was not for a PPA system like on Launchpad where > any member of the public can register an account and immediately > upload packages. The access policy for the proposed Debian PPA system > was to be exactly the same as for the rest of the Debian archive; only > accessible by uploading Debian members (aka DDs), others need to go > through a sponsor. In that sense, it is almost exactly the same as > people.d.o or *.debian.net. > > https://lists.debian.org/87y5btehw3@gkar.ganneff.de I misunderstood the proposal but after read the complete history I agree in general. It looks like it's a very cool project. If the creation of pps could be a more open that not _only_ DD, to me is perfect. At least DM. > > One interesting thing of mentors is that the packages are checked by > > lintian, so you need some binary ... > > You definitely do not need to upload binaries to mentors. I do not understand how lintian can do a complete check without binaries. For instance is a package is empty or not, or if you have installed a binary without manpage, or the sonames are correct or not. But probably I have misunderstood something in the thread. [...] > > > I cannot understand why you have this opposition. They idea is that the > > project could offer the option to build packages for Debian. > > We already have that: > > https://buildd.debian.org/ > https://db.debian.org/machines.cgi > > I'm not sure how/if the PPA proposal will use these machines though. only for DD... > > that you could say that, then you will have a lot of packages, maybe > > without quality, and you don't want the make a relation between that > > packages and the official ones. But, this is another thing. > > Indeed. > > > Not only non-x86. I work _only_ with amd64 arch. In theory, it should not > > be necessary to have another pbuild environment for 32 bit: they are > > quite identical. However, I can say that we suffered in one bug of our > > packages because, in 32 bits, sometimes FTBFS because an strange > > combination of memory and parallel compilation. And, we were three > > persons involved in that package: two uploaders and one sponsor. > > Sounds like an "interesting" bug :) > > For building on i386 I'd just use pbuilder and or qemu. > > If people would like to be able to build/test on other arches before > uploading to Debian, there are some options already: > > Debian members can login to Debian porterboxen and run > builds/tests/etc in various chroots: > > https://db.debian.org/machines.cgi > > Debian contributors can get guest accounts on the Debian porterboxen > and do the same: > > https://dsa.debian.org/doc/guest-account/ Very interesting. Thanks for the info. > Anyone can buy or solicit donations of hardware and build/test on those. > Anyone can use the existing services (LAVA, GCC, OpenPOWER and cloud > providers). > > https://wiki.debian.org/Hardware/Wanted Thanks. Well, now just wait to see. Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: This is a digitally signed message part.
Re: Proposal: enable stateless persistant network interface names
On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart wrote: >I get the distinct feeling some people posting here consider ifup/down >"old fashioned". Granted it doesn't have a nice GUI, but from the point >of view of someone who deploys lots of similar machines a GUI of any >sort is a negative, and it has a far nicer property - it is easily >scriptable. ifupdown _is_ scriptable. For example, it doesn't know dependencies between Interfaces, which is rather common for a server jockey (consider a VLAN on a bridge which is connected to the network via a bonding device), and it doesn't handle IP addresses that come and go at run time (as it is to be expected on IPv6 networks). And, when it comes to scriptability and flexiblity, systemd-networkd is vastly superior. It was made with a server in mind. Otoh, it is much harder to debug, extend and modify than ifupdown, which has a _very_ flexible script interface. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yri9n-0006om...@swivel.zugschlus.de
Re: Blends and (astronomy) meta-packages
Hi Ole, (Please do choose a followup-to as Jonas suggested) Le 10/05/2015 13:03, Ole Streicher a écrit : > 1. Create a meta-package within python-astropy: This would concentrate the > management in this package which is maybe not the best idea (development > of affiliated packages is independent of the astropy package itself). > > 2. Create an independent meta-package. This would be probably the > easiest way. > > 3. Create it as a task of a (not yet existing) "debian-astro" tasks > package. > Concerning astropy-all, I suggest option 2. Option 1 has the defect that you must upload a new version of python-astropy each time you want to add or remove a package in astropy-all. Option 3 (a debian astro task or blend) is a good option too, but much wider than astropy. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55505c75.5000...@debian.org
Re: Developer repositories for Debian
On Mon, May 11, 2015 at 3:12 PM, Leopold Palomo-Avellaneda wrote: > At least DM. I expect DMs will have access (as the mail talks about the uploading keyring*s*). > I do not understand how lintian can do a complete check without binaries. It can't check binaries if they don't get uploaded and lintian certainly can never be considered a complete check, even if it does check the binaries. Probably the most important is build-time testing using upstream test suites. Next up is package install, upgrade and removal testing with piuparts. http://piuparts.debian.org/ Also important is as-installed package testing with DEP-8, autopkgtest and debci: http://dep.debian.net/deps/dep8/ http://packages.debian.org/sid/autopkgtest http://ci.debian.net/ There is also static analysis, fuzzing, manual review and so on: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package > [buildds] only for DD... and DMs. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6FVEK-A7QaQ4bq67koUGe0OJEdbpfwiK=+fuj_ayvk...@mail.gmail.com
Re: Proposal: enable stateless persistant network interface names
On Mon, 11 May 2015 09:29:43 +0200, Marc Haber wrote: >On Mon, 11 May 2015 10:18:18 +1000, Russell Stuart > wrote: >>I get the distinct feeling some people posting here consider ifup/down >>"old fashioned". Granted it doesn't have a nice GUI, but from the point >>of view of someone who deploys lots of similar machines a GUI of any >>sort is a negative, and it has a far nicer property - it is easily >>scriptable. > >ifupdown _is_ scriptable. Eh, it _is_ old-fashioned, I wanted to write. >For example, it doesn't know dependencies >between Interfaces, which is rather common for a server jockey >(consider a VLAN on a bridge which is connected to the network via a >bonding device), and it doesn't handle IP addresses that come and go >at run time (as it is to be expected on IPv6 networks). Greetings Ma "need more coffee" rc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yrikp-0007cn...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
Just a quick observation: a lot of the problems people have experienced with network interface naming is a combination of two things: both whatever persistence scheme is in place (or not), but also the fact they *need to know a network interface name at all*. Many times I've wanted to express "launch DHCPd on the only network device you see or are going to see" with something like ifupdown, the actual network device name is irrelevant, but I'm forced to use it because ifupdown is old-aged. (This in particularly with VMs that might be cloned or moved around a lot). I think it's important to consider the state of our networking tools and what we want to see there going forward in concert with device naming considerations, and not make decisions based on the false premise that the way we do things now is how we want to do them Tomorrow. -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511082632.ga1...@chew.redmars.org
Re: Proposal: enable stateless persistant network interface names
On Fri, May 08, 2015 at 11:03:55PM +0200, Marc Haber wrote: > On Fri, 8 May 2015 13:33:06 -0700, j...@joshtriplett.org wrote: > >There are much better alternatives for most common cases. > > For example being? ufw is quite nice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511082921.gb1...@chew.redmars.org
Re: Proposal: enable stateless persistant network interface names
On Sun, May 10, 2015 at 09:04:23PM +0200, Stephan Seitz wrote: > On Sun, May 10, 2015 at 07:09:41PM +0200, Marc Haber wrote: > >Just for the record, an unexpected interface name change hasn't > >happened in my professional career in more than ten years. > > Same here. I have never seen unexpected interface changes. I have, during my 10 year tenure as a systems administrator. > Shade and sweet water! Still on the wrong side of your signature separator... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511083432.gc1...@chew.redmars.org
Re: Developer repositories for Debian
On Sat, May 09, 2015 at 09:23:26AM +0200, Mechtilde wrote: > Hello > > Am 05.05.2015 um 23:45 schrieb Mike Hommey: > > On Sun, May 05, 2013 at 02:22:04PM +0200, Joerg Jaspert wrote: > >> Hello world, > >> > >> Now with wheezy happy and out the door, we should finally tackle a long > >> open issue. Developer repositories (AKA PPA) for Debian. > > > > Now with jessie happy and out the door, what is the status of Developer > > repositories for Debian? > > Why can't you use people.debian.org for this? I'm not interested by the hosting part, it's not a problem. The problem is building packages for multiple debian architectures. At some point I might get annoyed enough with the current state of affairs that I'll build my own fake buildd network on debian machines, now that we (DDs) can install arbitrary packages in the schroots. But then, I'm not sure other people will like that the e.g. mips and arm developer machines are spending most of their time building iceweasel. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511085255.ga8...@glandium.org
Re: Proposal: enable stateless persistant network interface names
Ben Hutchings wrote: > The NM configuration is based on MAC addresses and doesn’t care about > the interface name at all. This is the exact opposite of “handling > dynamic names ungracefully”. Well, that's assuming hardware that has a permanent MAC address. What does it do for virtual or cheap hardware that gets a different locally- assigned address at each boot or hotplug? In most situations, the default behavior (starting a DHCP connection when the first adapter is plugged on) is what you want. When you use manual configuration, the daemon’s default is to write MAC-based configuration files, but you can change them to remove the 802-3-ethernet/mac-address setting and use connection/interface-name instead. See https://developer.gnome.org/NetworkManager/unstable/ref-settings.html -- Joss -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431339406.4239.7.ca...@dsp0698014.postes.calibre.edf.fr
Re: Q: why binary-log by systemd-journald is not enabled by default?
On Sat, May 09, 2015 at 08:32:37PM +0200, Stefano Zacchiroli wrote: > And while we are at it: is the persistent journal backup-safe? or does > the binary format get in the way, implying risks to backup incomplete / > corrupted log entries? Starting from version 219, it's not, at least on btrfs. The culprit is FS_NOCOW, used intentionally for a minor speed increase. It does break all backup schemes that rely on btrfs functionality (same-disk snapshots, btrfs-send/receive). Besides breaking CoW, it also degrades behaviour for unclean shutdowns. This flag should never be set other than by the sysadmin. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511104052.ga13...@angband.pl
Re: Proposal: enable stateless persistant network interface names
* Marco d'Itri [150510 23:55]: > I see a large enough consensus about switching by default to ifnames, > and I believe that the few people who want MAC-based names for USB > interfaces can easily set NamePolicy=mac or write a custom rule. Huh? This thread seems to have lots of opinions on both sides with no consensus at all. I don't see how you can make this assertion with a straight face. ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015051923.gc18...@basil.wdw
Re: Proposal: enable stateless persistant network interface names
On Mon, 2015-05-11 at 05:53 +0200, Marco d'Itri wrote: [...] > It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on > my Allwinner-based ARM computer), which means that interfaces will get > a mac-based name like enx028909xx. [...] For ARM (and any other architecture using Device Tree) the on-board indices should be specified as aliases 'ethernet0', 'ethernet1', etc. The aliases will be listed in the uevent as OF_ALIAS_0 (or OF_ALIAS_1, etc., as a device can have multiple aliases). Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On Mon, 2015-05-11 at 12:16 +0200, Josselin Mouette wrote: > Ben Hutchings wrote: > > The NM configuration is based on MAC addresses and doesn’t care > about > > the interface name at all. This is the exact opposite of “handling > > dynamic names ungracefully”. > > Well, that's assuming hardware that has a permanent MAC address. What > does it do for virtual or cheap hardware that gets a different > locally- > assigned address at each boot or hotplug? > > In most situations, the default behavior (starting a DHCP connection > when the first adapter is plugged on) is what you want. > > When you use manual configuration, the daemon’s default is to write > MAC-based configuration files, but you can change them to remove the > 802-3-ethernet/mac-address setting and use connection/interface-name > instead. > > See https://developer.gnome.org/NetworkManager/unstable/ref-settings.html I think you missed a point: permanent and locally-assigned MAC addresses are distinguishable, so Network Manager can and should avoid matching on the basis of a locally-assigned MAC address. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Proposal: enable stateless persistant network interface names
On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote: > For example, it doesn't know dependencies between Interfaces, which is > rather common for a server jockey (consider a VLAN on a bridge which > is connected to the network via a bonding device) I haven't had to solve that example, but I have had a problem again involving bridges that sounds similar. It was solvable with ifup/down - by calling ifup in the /etc/network/interfaces pre-up. I'll grant you it's not pretty, but I've only had to do it once so I forgive aj. > [ifupdown] it doesn't handle IP addresses that come and go > at run time (as it is to be expected on IPv6 networks). Could you explain when IPv6 addresses come and go? You are talking to a IPv6 neophyte here. In the IPv4 world addresses handed out by DHCP do come and go. It's true that isn't handled by ifupdown, but that's not a problem because if you want to do something about it, you do it in the dhclient hook. It seems the right place to me. That aside, I don't see anything in "man systemd.network" that allows you to watch for IPv6 addresses coming and going, or for that matter anything else coming and going except devices. > And, when it comes to scriptability and flexiblity, systemd-networkd > is vastly superior. It was made with a server in mind. This para is the real reason I'm responding. I must be missing something, because nowhere in "man systemd.network" do I see to a way to run a script of any sort. For me the acid test is "can it do totally manual configuration", ie the equivalent of ifupdown's "manual" method. (I occasionally use manual - it's a great way of ensuring there are no surprises.) systemd.network's [Match] section combined with the sort of demonstrated by ifupdown's manual method would be a match made in heaven. But if it exists I've missed it. You could perhaps emulate it if it were possible to make a systemd.service depend on a systemd.network, but that appears to be right out of scope. As it stands, networkd looks to be one of the least scriptable networking configuration options I've seen since ... oh redhat 7.0 or so. > Otoh, it is much harder to debug, extend and modify than ifupdown, > which has a _very_ flexible script interface. Up until recently I thought the systemd mob had solved the "visibility" problem by logging everything written to stdout and stderr with journald. I was disabused of that notion just this weekend, when apache2 failed to start after an apt-get dist-upgrade. journalctl -xn helpfully told me: $ ssu journalctl -xn -- Logs begin at Mon 2015-05-11 21:16:17 AEST, end at Mon 2015-05-11 22:22:42 AEST. -- May 11 22:21:43 russell-laptop systemd[1]: apache2.service: control process exited, code=exited stat May 11 22:21:43 russell-laptop systemd[1]: Failed to start LSB: Apache2 web server. -- Subject: Unit apache2.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit apache2.service has failed. -- -- The result is failed. Which is about as useful as a hip pocket in a singlet. In the end this told me what was going on: $ _SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/apache2 start [FAIL] Starting web server: apache2 failed! [warn] The apache2 configtest failed. ... (warning). Output of config test was: apache2: Syntax error on line 141 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/mods-enabled/php5_cgi.conf: No such file or directory Action 'configtest' failed. The Apache error log may have more information. Having to troll through scripts in /var/lib/lsb in order to figure out how to disable the systemd redirect in order to see the error message the sysV init script sent to stdout is NOT an improvement. (The Apache error log was empty.) If debugging networkd stuff is harder, then ... *shudder*. signature.asc Description: This is a digitally signed message part
Bug#785007: ITP: python-toro -- Synchronization primitives for Tornado coroutines
Package: wnpp
Severity: wishlist
Owner: Kartik Mistry
* Package name: python-toro
Version : 0.8
Upstream Author : A. Jesse Jiryu Davis
* URL : http://github.com/ajdavis/toro/
* License : Apache 2.0
Programming Lang: Python
Description : Synchronization primitives for Tornado coroutines
A set of locking and synchronizing primitives analogous to those in Python’s
threading module or Gevent’s coros, for use with Tornado’s gen.engine.
Why?
- Dependency for aperitum-apy.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
signature.asc
Description: Digital signature
Re: Proposal: enable stateless persistant network interface names
On May 11, Marvin Renich wrote: > > I see a large enough consensus about switching by default to ifnames, > > and I believe that the few people who want MAC-based names for USB > > interfaces can easily set NamePolicy=mac or write a custom rule. > Huh? This thread seems to have lots of opinions on both sides with no > consensus at all. I don't see how you can make this assertion with a > straight face. I see some concerns about using firmware-derived names for USB devices, but not significant objections for the general case. Consensus does not mean that there is no disagreement at all, but that all objections have been addressed. -- ciao, Marco pgp7ZFmNSPj61.pgp Description: PGP signature
Re: Bug#761348: ftp.debian.org: need machine-readable metadata about suites & repositories
Hi! On Sat, 2014-09-13 at 15:24:58 +0800, Paul Wise wrote: > Package: ftp.debian.org > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > Various places in Debian infrastructure (QA especially) hard-code > aspects of the Debian archive (suite, code, component, arch names etc). > This is a problem because after new suites or architectures are added, > we have lots of places that need to be updated. Most of them can be > fixed (help needed), however Debian does not provide information about > which repositories are available where, which suites are provided by > them, nor any information about the relative order of those suites, nor > any information about which suites are archived. There's also another type of archive-specific data, which I think is relevant to this bug report, that currently needs to be duplicated and translated at least on each high-level package manager frontend, but other tools carry it too. That is the list of package sections and possibly their descriptions and translations (there's the priorities too, but these are more static and entrenched in implementations so probably can be ignored). There are currently hard-coding of sections in (at least): Package managers (downloaders) aptitudesection-descriptions, aptitude-defaults.LL synapticcommon/sections_trans.cc aptdaemon aptdaemon/pkcompat.py packagekit backends/apt/aptBackend.py, backends/aptcc/apt-utils.cpp hildon-application-manager (not in Debian, abandoned) Other (offline) - reportbug reportbug/debbugs.py lintian data/fields/archive-sections, checks/fields.desc libconfig-model-dpkg-perl lib/Config/Model/models/Dpkg/Control/Binary.pl, lib/Config/Model/models/Dpkg/Control/Source.pl dl10n dl10n-check dpkg-wwwsrc/dpkg configure-debian configure-debian gambas3 app/src/gambas3/install/group/debian, app/src/gambas3/install/group/ubuntu vim runtime/syntax/debcontrol.vim zsh Completion/Debian/Command/_debfoster, Completion/Debian/Command/_dak So it would be nice for every archive to provide a file with the list of sections found in it, their description and translation. Perhaps something like: ,--- (text lifted from aptitude) Section: graphics Description: Utilities to create, view, and edit graphics files Packages in the 'graphics' section include viewers for image files, image processing and manipulation software, software to interact with graphics hardware (such as video cards, scanners, and digital cameras), and programming tools for handling graphics. Description-ca: Eines per crear, visualitzar i editar fitxers gràfics Els paquets de la secció 'graphics' inclouen visualitzadors de fitxers d'imatges, programari de processament i manipulació d'imatges, programari per interaccionar amb el maquinari gràfic (targetes de vídeo, escàners i càmeres digitals), i eines de programació per gestionar gràfics. … Section: … … `--- Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511143710.ga28...@gaara.hadrons.org
Re: Q: why binary-log by systemd-journald is not enabled by default?
On Sun, May 10, 2015 at 12:56:43AM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 09 May 2015, Josh Triplett wrote: > > The on-disk persistent journal (/var/log/journal) is disabled because at > > the moment, Debian systems use syslog by default (via rsyslog), and > > enabling the persistent journal would result in two copies of log > > messages. > > > > Since the journal is capable of capturing messages sent to syslog, I'm > > hoping that at some point the systemd source package will build a binary > > package that installs /var/log/journal and Provides the > > system-log-daemon and linux-kernel-log-daemon virtual packages. (As > > well as a non-default one that provides the same virtual packages but > > doesn't provide the persistent journal directory, for systems that want > > transient in-memory logging only.) > > And I wish it would keep /var/log/dmesg (and its rotation). That thing is > really useful for user support when dealing with kernel and boot issues. > > I consider the lack of /var/log/dmesg updates in jessie under systemd to be > a relevant regression, as journal persistence is not enabled by default. Leaving aside the persistence issue (for which kern.log seems like a somewhat reasonable substitute), once we have persistent journaling enabled, journalctl's -b option should address this, by making it convenient to access the journal data from a particular boot. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511145759.GD6130@x
Bug#785015: ITP: wcsaxes -- Framework for plotting astronomical and geospatial data
Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org,debian-pyt...@lists.debian.org * Package name: WCSAxes Version : 0.3 Upstream Author : Thomas Robitaille * URL : https://github.com/astrofrog/wcsaxes * License : BSD-3-Clause Programming Lang: Python Description : Framework for plotting astronomical and geospatial data WCSAxes is a framework for making plots of Astronomical data in Matplotlib. It is affiliated with the Astropy project and is intended for inclusion in the Astropy package once stable. I am packaging this mainly as an example for a small Debian packaging tutorial/workshop for astropy affiliated packages [1]. It will maintained within the Debian Astronomy Working Group. A git repository will be created on alioth [2]. Best regards Ole [1] http://www.astropy.org/affiliated/index.html [2] https://anonscm.debian.org/cgit/debian-astro/packages/wcsaxes.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5550c934.40...@debian.org
Re: Proposal: enable stateless persistant network interface names
On Mon, 11 May 2015 22:37:40 +1000, Russell Stuart wrote: >On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote: >> For example, it doesn't know dependencies between Interfaces, which is >> rather common for a server jockey (consider a VLAN on a bridge which >> is connected to the network via a bonding device) > >I haven't had to solve that example, but I have had a problem again >involving bridges that sounds similar. It was solvable with ifup/down - >by calling ifup in the /etc/network/interfaces pre-up. I'll grant you >it's not pretty, but I've only had to do it once so I forgive aj. Of course you can do that with /e/n/i, it's just clumsy and manual. >> [ifupdown] it doesn't handle IP addresses that come and go >> at run time (as it is to be expected on IPv6 networks). > >Could you explain when IPv6 addresses come and go? You are talking to a >IPv6 neophyte here. In the IPv4 world addresses handed out by DHCP do >come and go. It's true that isn't handled by ifupdown, but that's not a >problem because if you want to do something about it, you do it in the >dhclient hook. It seems the right place to me. In IPv6, routers advertise prefixes. If a new prefix comes, end systems configured for SLAAC will allocate an IP address in this prefix and begin to use it. End systems with privacy extensions enabled will automatically allocate an (additional?) random IP address and change it after a given amount of time. IP address change happens by first configuring the new address and then deprecating, but not deconfiguring, the old IP address. A deprecated IP address is not used for new connections, but allows already existing connections to live. >That aside, I don't see anything in "man systemd.network" that allows >you to watch for IPv6 addresses coming and going, or for that matter >anything else coming and going except devices. As far as I know, this is not yet implemented, but systemd as a central daemon with dbus and other links is predestined to take care of IP address changes as well. Unfortunately, it does not yet have appropriate hooks, but I guess that it will advertise interfaces and addresses coming and going via dbus so that third party software can act on those events. I have never actually tried that and am not familiar enough with dbus to even look what's happening here. >> And, when it comes to scriptability and flexiblity, systemd-networkd >> is vastly superior. It was made with a server in mind. > >This para is the real reason I'm responding. I must be missing >something, because nowhere in "man systemd.network" do I see to a way to >run a script of any sort. For me the acid test is "can it do totally >manual configuration", ie the equivalent of ifupdown's "manual" method. It cannot do that, no. It doesn't need to. Manual configuration can still be done from a regular systemd unit or old fashioned /e/n/i. Afaik, it only acts on interface it can find configuration for, so you're free to have it ignore interfaces you want to handle manually. >(I occasionally use manual - it's a great way of ensuring there are no >surprises.) systemd.network's [Match] section combined with the sort of >demonstrated by ifupdown's manual method would be a match made in >heaven. But if it exists I've missed it. You could perhaps emulate it >if it were possible to make a systemd.service depend on a >systemd.network, but that appears to be right out of scope. As it >stands, networkd looks to be one of the least scriptable networking >configuration options I've seen since ... oh redhat 7.0 or so. the systemd people are working hard to eliminate scripts from system administration. Hence they're quite reluctant to add interfaces to plug new scripts into. This is indeed one of the biggest turn-offs with systemd for me. >> Otoh, it is much harder to debug, extend and modify than ifupdown, >> which has a _very_ flexible script interface. > >Up until recently I thought the systemd mob had solved the "visibility" >problem by logging everything written to stdout and stderr with >journald. I was disabused of that notion just this weekend, when >apache2 failed to start after an apt-get dist-upgrade. journalctl -xn >helpfully told me: > >$ ssu journalctl -xn >-- Logs begin at Mon 2015-05-11 21:16:17 AEST, end at Mon 2015-05-11 > 22:22:42 AEST. -- >May 11 22:21:43 russell-laptop systemd[1]: apache2.service: control > process exited, code=exited stat >May 11 22:21:43 russell-laptop systemd[1]: Failed to start LSB: > Apache2 web server. >-- Subject: Unit apache2.service has failed >-- Defined-By: systemd >-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >-- >-- Unit apache2.service has failed. >-- >-- The result is failed. > >Which is about as useful as a hip pocket in a singlet. In the end this >told me what was going on: > >$ _SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/apache2 star
Bug#785026: ITP: r-cran-rpostgresql -- GNU R package providing database interface and driver for PostgreSQL
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: r-cran-rpostgresql Version : 0.4 Upstream Author : Joe Conway et al. * URL : http://cran.r-project.org/web/packages/RPostgreSQL/index.html * License : GPL-2 Programming Lang: C and R Description : GNU R package providing database interface and driver for PostgreSQL This package provides a Database Interface (DBI) compliant driver for GNU R to access PostgreSQL database systems. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511170329.15402.21976.report...@kage.sury.org
Bug#785027: ITP: hedgehog -- visualisation tool for DNS
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" * Package name: hedgehog Version : 2.0.0 Upstream Author : ICANN * URL : http://dns-stats.org/ * License : Apache 2.0 Programming Lang: C++, R, Shell, Perl Description : visualisation tool for DNS Hedgehog is a visualisation tool for DNS statistics that consumes data acquired with the DSC collector (pkg:dsc-statistics-collector). The data is presented via a web interface which uses R, R-Apache, HTML5, javascript and googleViz. A long term goal is to utilise R to add statistical analysis capabilities to the front end. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511170539.15487.16265.report...@kage.sury.org
Re: Proposal: enable stateless persistant network interface names
On May 11, Ben Hutchings wrote: > For ARM (and any other architecture using Device Tree) the on-board > indices should be specified as aliases 'ethernet0', 'ethernet1', etc. Is this something that I can experiment on by patching just the device tree definition or does it happen in the driver? Do you have an example that I can look at? > The aliases will be listed in the uevent as OF_ALIAS_0 (or OF_ALIAS_1, > etc., as a device can have multiple aliases). udev does not know about this variable, so unless the index will also appear somewhere else it will not be enough. -- ciao, Marco pgpac1S8rFPbz.pgp Description: PGP signature
Re: Heads up: Upcoming dpkg-buildpackage -j precedence change
On Sun, 2015-05-10 at 19:56:49 +0200, Julien Cristau wrote: > On Sun, May 10, 2015 at 18:49:25 +0100, Wookey wrote: > > I'm happy if you change this - it seems like fixing a bug to me, but I > > will just throw in this observation from recent arm64 archive-rebuilds, > > that -j and DEB_BUILD_OPTIONS=parallel= are not exactly the same. Is > > that expected? Yes, this is expected, there was a bug report recently asking to clarify this in the man page, fixed in master and will be included in the upcoming dpkg 1.18.0 release. > dpkg-buildpackage -j is buggy. No. This is the equivalent distinction between: $ make -jN -f debian/rules build and $ DEB_BUILD_OPTIONS=parallel=N debian/rules build You might not like the behavior, and that is fine, but that does not make it buggy. (And BTW debuild also sets MAKEFLAGS.) > It sets MAKEFLAGS whether the package > supports parallel builds or not. Whereas setting DEB_BUILD_OPTIONS lets > the package know it's allowed to use more processes if it wants to / > can, but doesn't have to. Actually Makefiles that do not support parallel builds and do not declare so with .NOTPARALLEL: are buggy, because upstreams do not have any standardized opt-in way to honor a parallel build request. Regards, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511184016.ga18...@gaara.hadrons.org
Bug#785048: ITP: python-pyramid-chameleon -- Chameleon templating addon for the Pyramid web application framework
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: python-pyramid-chameleon Version : 0.3 Upstream Author : Pylons Project and Contributors, http://www.pylonsproject.org/ * URL : http://docs.pylonsproject.org/projects/pyramid-chameleon/en/latest/ * License : BSD-4-clause, with non-free docs (will be removed) Programming Lang: Python Description : Chameleon templating addon for the Pyramid web application framework Pyramid is a small, fast, down-to-earth, open source Python web development framework. It makes real-world web application development and deployment more fun, more predictable, and more productive. . pyramid_chameleon provides bindings for the Chameleon templating system, This addon was previously part of python-pyramid, but split off upstream. It's used by PET (https://pet.alioth.debian.org). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511185343.2207.66408.report...@deep-thought.43-1.org
Re: Q: why binary-log by systemd-journald is not enabled by default?
On May 09 2015, Josh Triplett wrote: > Hideki Yamane wrote: >> We've switched to systemd and I've noticed that journald feature is >> not enabled. I can easily do it as README.Debian suggested, but wonder >> why logging by journald is not enabled by default. >> >> Is there any reason? (just a curious) > > The in-memory non-persistent journal (/run/log/journal) is enabled; if > you run journalctl you can see the logs from the current boot. > > The on-disk persistent journal (/var/log/journal) is disabled because at > the moment, Debian systems use syslog by default (via rsyslog), and > enabling the persistent journal would result in two copies of log > messages. In addition, at least for me it reliably gets corrupted every few weeks (even in the absence of any system crashes). Typically journalctl --verify reports a "Invalid tail monotonic timestamp", and I have to remove the affected journal file to fix it. #764557 Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d227nef3@thinkpad.rath.org
Re: Re: httpredir.debian.org, your mirrors redirector
Hi, Joachim Breitner wrote: > will http.debian.net continue to work? Yes, there's no plan to discontinue the other host name. At some point the web site (index, demo, etc) is going to redirect to httpredir, but that's about what's planned. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caa7hughvcwngdq1o4asbxdgqrhy2ukeba186mp5cgydvug9...@mail.gmail.com
Bug#785059: ITP: python-cachecontrol -- a port of the caching algorithms in httplib2 for use with requests session object
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-cachecontrol Version : 0.11.2 Upstream Author : Eric Larson * URL : https://pypi.python.org/pypi/CacheControl * License : MIT/Expat Programming Lang: Python Description : a port of the caching algorithms in httplib2 for use with requests session object This package is a new dependency for the latest version of pip. To upgrade pip, I need to get CacheControl into Debian. I plan to maintain it as part of the DPMT. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVUSpsAAoJEBJutWOnSwa/VJAP/3A4D8w4wgL4haA25F3XNmPE B4pnRshBmpxjCbyx4EXOGrJWnBp/GIo22UkbS7zgxigQ4HgIHKbYnHW6KnmJpVPe wSFWwkbS0QKISZ3rtsRUCwvJZZY156/TOkY3lvACtToPJ9sDho319i6KKIaCCL5C +Owr4/u7eg24fpuG+HekDmYHdU7uTmGd2ghqg6btntz23eHrGJQh8kJhlKjcnGbk tX3p4VGzvIJ9ERPbz4s7OLUBVjJSnUaiZvhwerdNztYBBMXTYe661PJlOvpYrLMw 9l2QIsQ+kmPBcDKyTQ+r9Gz6Vt85fK6KgEmgT653g3C7c1bT9t0PF+y7VqE1jLJb CMLpL5LTY3Hfrb0GqDKrPiR3Wrq1hg9uHBts67AkBAcwYO+NDOLu1r9TU4dzGIUa zZXIxy/aCViOi6U0P39Rz5lZeqwCd5y0RybqgapIpeyHZZtrpGAJ8NLUBkjkITKl e7u+WwKsawLLqc0UujEYSGKrrlPVAGvkJQNxGGaZObwUC7AR3nletrAhfd97peeW VP7MvcCikMI3tAvxrQmosNeK/pVnCtzk/Pcz44EW0sGVdFVec8Y74djTSminXltX romHqVfQGnRDBm6XOxhA/4d3q68h2XVAhKvcCVM53B5UYSouSNAxT7psh9gtOXz/ 6KDAdcweO9D1EJ2mA+Hn =IT5K -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511221718.13766.62170.report...@chemistry.wooz.org
Re: Proposal: enable stateless persistant network interface names
Hello, Karsten Merker [2015-05-11 20:22 +0200]: > >From what Ben Hutchings has described in > <1431294933.2233.66.ca...@decadent.org.uk>, the race condition > could easily be avoided with the current codebase by simply not > using "eth" as the prefix, but e.g. "en". Right, that would solve one problem, but not the others. > Could you explain why the existing code does not provide stable > names in virtual machines? As long as the virtual ethernet > controller keeps the same MAC address over time (which I believe > to be the normal case), I see no reason why the existing codebase > should not provide stable names in a VM in the same way it does > on physical hardware. I'm afraid you have to ask folks more familiar with clouds about the "why", but it seems MAC addresses change all the time there as with every new instance or even boot you get a different virtual ethernet card assigned. See all the reports that we are getting about adding entries to the blacklist. > As "slot" has been shown to be not really stable for a number of > use cases (even for PCI, see above), I think that "mac" is the > only way that works for all cases. It clearly doesn't work for "all cases", like replacing network cards (in physical servers, but this is what by and large happens in clouds too), or where you have to rely on the location of cards instead of their MACs (like running the same config on a rack of servers, where what you see, wire, and configure are port locations). Anyway, I do see that we want to use MAC addresses by default for at least USB. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150512041237.gb3...@piware.de
