Bug#778888: ITP: libnet-interface-perl -- manipulates host network interfaces
Package: wnpp Owner: Christopher Hoskin Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libnet-interface-perl Version : 1.012 Upstream Author : Michael Robinton * URL : https://metacpan.org/release/Net-Interface * License : Artistic or GPL-2+ Programming Lang: Perl Description : manipulates host network interfaces Net::Interface is a module that allows access to the host network interfaces in a manner similar to ifconfig(8). Version 1.00 is a complete re-write and includes support for IPV6 as well as the traditional IPV4. Both read and write access to network device attributes including the creation of new logical and physical interfaces is available where supported by the OS and this module. NOTE: if your OS is not supported, please feel free to contribute new capabilities, patches, etc see: Net::Interface::Developer ANOTHER NOTE: Many of the operations of Net::Interface, particularly those that set interface values require privileged access to OS resources. Wherever possible, Net::Interface will simply fail softly when there are not adequate privileges to perform the requested operation or where the operation is not supported. -- 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/E1YP6UD-0006fl-6v@TX100-S3P
Re: Hosting offers for Debian development
On Wed, 2015-02-18 at 19:33 +0100, Mehdi Dogguy wrote: > If someone is working on some new project/service for Debian and wants > to be hosted on a DSA-managed machine, what are the criteria that > should be met to be accepted? There isn't really a written set of criteria that need to be met, please come talk to us about your planned service. Nevertheless, here's a random list of things that came to mind: In general, if this is a service that can run on standard x86 systems, we prefer to run it on existing virtualisation infrastructure instead of getting dedicated special hardware. Sometimes that is not an option due to resource requirements (e.g. snapshot) or when introducing a new port. Such instances will need to be discussed on a per-case basis. For services that need other types of hardware, we need to be able to acquire and host that hardware. We like stable hardware that can be bought (or donated) that survives reboots and doesn't fall over all the time. Our hosting providers generally like rack-mountable hardware. There will be no root access, except in exceptional circumstances. Assume your service isn't one of those exceptional circumstances. We strongly discourage use of PHP and MySQL. The latter is mainly because we only have the surrounding infrastructure (backups etc) for PostgreSQL, but also because we don't want to run different database management systems, just like we don't run different types of webservers; we run Apache. We plan to shut down services without active admins until there is someone to adopt them. We ask service admins to contribute and help maintain a meta-package for the debian.org set of metapackages: https://anonscm.debian.org/cgit/mirror/debian.org.git The only packages that will be installed are those from Debian stable and backports, with pretty much no exceptions. Around release time various machines get upgraded to the upcoming stable release. Please have a good understanding of the resource requirements of your service and be able to describe these. How much disk space will you need, how much RAM, how many cores? Realise server-grade disk-space is limited and not cheap. We like it when user-facing services have a geographically distributed multi-machine architecture. We will generally setup SSL for HTTP based services, redirecting from HTTP to HTTPS. Web services/sites should avoid referencing resources from outside their domain. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: conflicts between Debian's and upstream's Debian package
On Fri, 20 Feb 2015 22:15:41 +0100 Marc Haber wrote: > On Fri, 20 Feb 2015 09:04:56 +0100, Harald Dunkel > wrote: > >Problem: The Debian maintainer messed up the version numbers > >and had to introduce a "1:" for his foo package. Now upstream's > >package always appears to be out of date, forcing me to override > >apt-get. > > That is unfortunately a situation that our tools don't handle well. > You could try pinning down Debian's version of that package in > apt_preferences(5). This works a lot better if upstream provide a repository (with identifying details unique to that repository) as the pin can work in both directions, withstanding changes in the versions due to epochs etc. Standalone .deb files "lobbed over the wall" from upstream are the most common source of the reasons why upstream packages have such a bad name, even if a .dsc is provided. Signing an upstream repository can be a mixed blessing - downloading an .asc file from the same website isn't the best way to trust the packages from that website but is the typical way these things get done. If someone goes to the length of packaging a keyring package, it's much better to simply package the software instead and use the archive keyring with all the mirrors, buildds and PTS etc. > >If upstream's Debian package of a tool is "not good enough" > >for Debian for some reason, wouldn't it be reasonable to avoid > >a naming conflict on creating the Debian package? > Unfortunately, most upstreams make Debian packages unsuitable for > inclusion in Debian proper. That's however unavoidable, since nearly > no upstream can invest the time needed to provide really good packages > for all major distributions out there. Agreed, upstream's .deb file is almost never "good enough" for direct inclusion into Debian or "simple" inclusion via a clean rebuild & signing. The times it does work (for Debian packages at least) are when there is a DD on the upstream team... Keeping up with Policy, packaging practice and other requirements within the distro is not something anyone should expect upstream to do without someone on the team being a member of that distro. A .deb file is not a simple archive, it is trivially easy to make a "bad" .deb which ignores Policy and breaks your system completely. It is in everyone's interest that the Debian package has the same name as the source package released by upstream - unless there is a different package, from a different upstream, already in the archive with that name or the upstream uses a inappropriate or overly generic name. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp3cRkviula1.pgp Description: OpenPGP digital signature
Re: conflicts between Debian's and upstream's Debian package
On Fri, 20 Feb 2015 19:31:49 +0100 Adam Borowski wrote: > On Fri, Feb 20, 2015 at 05:53:27PM +, Simon McVittie wrote: > > If the Debian packages are not as good as the upstream ones, such > > that you end up having to use the upstream ones for some reason, > > then that also seems like a bug. If you can help the Debian > > maintainer to fix that bug (e.g. by getting newer upstream versions > > into experimental, or by fixing deficiencies of the packaging that > > are done better upstream, or whatever), problem also solved. > > There's only one experimental, the upstream can have more branches. If the will is there, packages which would be suitable for experimental (with a rebuild/re-signing) can be pushed to an upstream repo - yes, you lose the benefits of mirrors and buildds etc. but it can work and it's not an excuse for making "bad" packages or packages which fail to inter-operate with the versions already in Debian. > During Debian freeze, an upstream may offer for example: > * the newest release > * upcoming beta branch > * trunk > > Another reason is that the latter two will often have nightly builds. > You can't expect a Debian maintainer to make uploads to experimental > daily, while it's easy for an upstream script to do that. .. and the upstream script can just as easily put the package into a suitable repository which is easy to use with apt-pinning. There aren't many users who will upgrade the same package every day either, so it's not as if the lack of mirrors is going to be much of a problem. Echoing Simon's response - in all reasonable cases, there are steps that upstream and Debian can take so that their packages use the same package names and work nicely with together - that includes working with the Debian versions of the same upstream. The technical issues can be fixed with bug reports. It's only if there is a particularly toxic social relationship between Debian and upstream that a package could warrant being renamed to actively conflict with the name used upstream. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpjRknN5WFj9.pgp Description: OpenPGP digital signature
Re: Hosting offers for Debian development
On Sat, Feb 21, 2015 at 06:52:20PM +0800, Paul Wise wrote: > On Wed, 2015-02-18 at 19:33 +0100, Mehdi Dogguy wrote: > > > If someone is working on some new project/service for Debian and wants > > to be hosted on a DSA-managed machine, what are the criteria that > > should be met to be accepted? > > There isn't really a written set of criteria that need to be met, please > come talk to us about your planned service. > > Nevertheless, here's a random list of things that came to mind: > > [snip] > Thank you for the reply. I've added a link to your mail on: https://wiki.debian.org/ServicesHosting Cheers. -- Mehdi Dogguy -- 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/20150221131124.gb12...@dogguy.org
Re: conflicts between Debian's and upstream's Debian package
El vie, 20 de feb 2015 a las 12:04 , Harald Dunkel escribió: Hi folks, I would like to use upstream's Debian/Ubuntu packages for a certain tool 'foo'. Its closer to what I need, and I don't have migrate between both versions before asking the mailing list for help or for reporting/fixing problems. Problem: The Debian maintainer messed up the version numbers and had to introduce a "1:" for his foo package. Now upstream's package always appears to be out of date, forcing me to override apt-get. Not the cleanest option, but can upstream just introduce the 1: as well? Cheers, -- Cameron Norman
Bug#778924: ITP: linssid -- graphical wireless scanner
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho * Package name: linssid Version : 2.7 Upstream Author : Warren Severin * URL : https://sf.net/projects/linssid * License : GPL-3 Programming Lang: C++ Description : graphical wireless scanner LinSSID displays locally receivable 802.11 wireless attach points and ad hoc networks. . A table is displayed with various parameters such as MAC address, channel, and signal strength. Graphs are also displayed with signal strength by channel and signal strength over time. . LinSSID is graphically and functionally similar to inSSIDer (for Microsoft Windows) and Wifi Analyzer (for Android). . LinSSID can be used to measure the local perfomance or to search for an interference free channel to be set in a wireless router (access point). The wireless established link won't be affected by these operations because LinSSID needn't set the monitor mode in network interface. -- 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/20150221205232.14531.37668.report...@canopus.eriberto.pro.br
Bug#778933: ITP: python-pyelftools -- pure-python library for parsing ELF and DWARF
Package: wnpp Severity: wishlist Owner: Tomasz Buchert * Package name: python-pyelftools Version : 0.23-1 Upstream Author : 2015 Eli Bendersky * URL : https://github.com/eliben/pyelftools * License : Public Domain Programming Lang: Python Description : pure-python2 library for parsing ELF and DWARF pyelftools is a pure-Python library for parsing and analyzing ELF files and DWARF debugging information. It can be used to query information about compiled binaries and libraries from your Python code. This package is required for a newer versions of pax-utils [1]. However, it is interesting on its own - it provides Python 2 & 3 compatible library to parse ELF files and reimplementation of readelf from binutils. I can maintain it myself (I already maintain pax-utils). I've already did the preliminary packaging [2]. The source package builds 3 binary packages: Python2 library, Python3 library and pyreadelf which depends on Python3 library. Cheers, Tomasz [1] https://tracker.debian.org/pkg/pax-utils [2] http://anonscm.debian.org/cgit/collab-maint/python-pyelftools.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/20150221214722.3647.89467.reportbug@noether
jessie for x32
Hi folks!
Here's some news about the x32 port. I'm trying a different approach:
instead of using only packages uploaded by their {,non-}maintainers, as on
ftp.debian-ports.org which tracks unstable, I'm using a separate repository
on ftp.debian-x32.org that includes packages with porting patches applied.
That is, 54 sourceful uploads that unblock further 1427 source packages.
The cool stuff includes fully-working debian-installer, and more.
I hereby invite you to http://debian-x32.org to take a look. Unlike most
ports, you do own a machine that can run this natively...
As for a server, pretty much everything is in place (lacking nodejs and the
haskell world). Too bad, desktoppy things are in a worse shape: while XFCE,
Mate, LXDE, most of KDE and so on do work, blocker problems include:
* no Iceweasel (nor Chromium): xptcall needs porting
* sound problems (kernel-side ioctls): needs -m64/:amd64 pulseaudio or jack
* no libreoffice: java toolchain has JNI issues
The above three make an x32 desktop currently not really usable.
But, if these problems can be fixed, I contemplate making an unofficial
jessie-x32 release, with security support (via rebuilds of s.d.o).
So guys, please install, test, enjoy, report problems.
And, it would be great if someone could help me with porting iceweasel. I
kind of ran out of clue there: after a number of solved issues (patches in
#775321), the xptcall reflection piece requires better knowledge of assembly
than I possess. The part that needs porting is a few pages of asm, and is
well-documented (subdir: xpcom/reflect/xptcall).
I don't have any real clue about JNI as well. On the other hand, ghc looks
like something that needs just more tuits and reading about bootstrapping it
(no per-arch porting required). Nodejs depends on libv8 which needs full
code generation for every arch, thus no luck. Most other stuff... needs
tuits. I'll try to port what I can, a mail can bring a package that's
interesting to you to the front of the queue.
And where the missing stuff is secondary to the purpose of a machine,
there's multiarch...
Meow!
--
// 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.
signature.asc
Description: Digital signature
Re: Should we mark #388141 as jessie-ignore?
On Wed, 18 Feb 2015 08:19:34 +0800 Paul Wise wrote: > On Tue, Feb 17, 2015 at 6:12 PM, Riley Baird wrote: > > > Kind of, but it's only for that one article. Is there something similar > > that lists all edits to the wiki itself like that? If not, I could make > > one by downloading the revision histories for all pages on the wiki and > > then parsing them, but this might place strain on the server (and would > > be much more difficult). > > Isn't #388141 solely about the website? > > There is #385797 about the wiki content. Good point. I really should have noticed that. In any case, as ridiculous as it sounds, I've been trying to get CVS to show me the offending commits over the last couple of days, and I haven't worked out how to do it. So, I think that I'll leave this bug (at least for now), and go work on some other Debian-related activity. Thanks for your help everyone. pgpW5PigcIgKN.pgp Description: PGP signature
