Re: ifupdown's changed hook handling breaks other packages.
Le samedi 16 juin 2012 à 19:38 +0200, Andrew Shadura a écrit : > Also, it's network-manager who tries to be a replacement somehow > compatible with ifupdown, not vice versa, so NM maintainers should take > care of their package to do things are they're supposed to be done in > a compatible way. NM is not compatible with ifupdown and does not try to be. This is *precisely* why the /e/n/i lines are commented out by nm.postinst. It sounds to me that you have broken this behavior on purpose, where you could instead have added an interface to make disabling an interface more convenient than sed hackery (as mandated by policy). -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1340004205.4245.695.camel@pi0307572
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Mon, 18 Jun 2012 09:23:25 +0200 Josselin Mouette wrote: > Le samedi 16 juin 2012 à 19:38 +0200, Andrew Shadura a écrit : > > Also, it's network-manager who tries to be a replacement somehow > > compatible with ifupdown, not vice versa, so NM maintainers should > > take care of their package to do things are they're supposed to be > > done in a compatible way. > NM is not compatible with ifupdown and does not try to be. > This is *precisely* why the /e/n/i lines are commented out by > nm.postinst. When I say 'compatible' I don't mean NM supports everything ifupdown does (which it certainly doesn't and doesn't try to), I mean it is compatible in that it at least doesn't break ifupdown. > It sounds to me that you have broken this behavior on purpose, where > you could instead have added an interface to make disabling an > interface more convenient than sed hackery (as mandated by policy). No. Also I'd like to remind you that this sed hackery has already been done by NM maintainers without much discussions on how to make it better. -- WBR, Andrew signature.asc Description: PGP signature
Re: ifupdown's changed hook handling breaks other packages.
On Mon, Jun 18, 2012 at 09:36:48AM +0200, Andrew Shadura wrote:
> > It sounds to me that you have broken this behavior on purpose, where
> > you could instead have added an interface to make disabling an
> > interface more convenient than sed hackery (as mandated by policy).
>
> No. Also I'd like to remind you that this sed hackery has already been
> done by NM maintainers without much discussions on how to make it
> better.
Let's stop the mutual accusation part of this thread.
To avoid similar issues to arise again in the future, I wonder, would it
be feasible to implement something like Joss mentioned, i.e. some sort
of ifupdown blessed mechanism to enable/disable interfaces? The need of
doing so exists, NM is an example of that. Enabling people to do so
without _having_ to rely on text file fiddling would be an improvement
over the status quo.
(Arguably, this part of the discussion {c,s}ould be moved to the BTS.)
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
ifupdown should provide a way to disable interfaces configuration
Package: ifupdown Hello, On Mon, 18 Jun 2012 09:53:49 +0200 Stefano Zacchiroli wrote: > Let's stop the mutual accusation part of this thread. > To avoid similar issues to arise again in the future, I wonder, would > it be feasible to implement something like Joss mentioned, i.e. some > sort of ifupdown blessed mechanism to enable/disable interfaces? The > need of doing so exists, NM is an example of that. Enabling people to > do so without _having_ to rely on text file fiddling would be an > improvement over the status quo. I guess that can be done. The question is what exactly would be cool to have: just ability to black-list some interfaces, or ability to skip calling ifup/ifdown at boot time at all? Or, probably, both? -- WBR, Andrew signature.asc Description: PGP signature
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Mon, 18 Jun 2012 09:53:49 +0200 Stefano Zacchiroli wrote: > Let's stop the mutual accusation part of this thread. P.S. Didn't mean to make anybody upset; I was a little bit tired back then, and I'm sorry that affected the way of me communicating with people. -- WBR, Andrew signature.asc Description: PGP signature
Announce: script to automatically restart services after update of dependencies
I want to announce restart-services here [1][2]. It's a script that tries to restart all services that have had their dependency packages updated. This is primarily useful when security-relevant libraries get security releases. It's using checkrestart from the debian-goodies package to do most of its work. Together with the unattended-upgrades package it is saving me a lot of system maintenance time, thus I am announcing it here in the hope that it will save others a lot of time as well. Thanks, *t [1] http://sourcepole.ch/2012/6/7/automatically-restarting-services-after-upgrades-on-debian-and-ubuntu [2] https://github.com/tpo/debian-goodies -- 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/7f19c94095a8d9d9467cfbd176b45...@mail.sp-metanet
Re: Bug#677474: Substvars for Build-Depends in the .dsc file
On Sun, Jun 17, 2012 at 01:39:05PM +0200, Goswin von Brederlow wrote: > I think that the sources-subvars target must function without any > Build-Depends-(Indep) installed because otherwise: Just as an aside, we now have Build-Depends-Arch in addition to Build-Depends-Indep. This means that Build-Depends can be restricted to the common subset needed for packing sources but not those needed for arch-all or arch-any building. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120618121014.ge30...@codelibre.net
Re: Announce: script to automatically restart services after update of dependencies
On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote: > I want to announce restart-services here [1][2]. It's a script > that tries to restart all services that have had their > dependency packages updated. This is primarily useful when > security-relevant libraries get security releases. > > It's using checkrestart from the debian-goodies package to do > most of its work. > > Together with the unattended-upgrades package it is saving me > a lot of system maintenance time, thus I am announcing it here > in the hope that it will save others a lot of time as well. Sounds useful, maybe put it in the debian-goodies package? Also, please blacklist gdm3 and dbus since restarting them currently kills GNOME sessions (and probably other user desktop sessions started by gdm3). -- bye, pabs http://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: http://lists.debian.org/caktje6fyp5bvtv+ar0xbihvhcajhuooi3em8ce4wuaw1v1p...@mail.gmail.com
Re: Announce: script to automatically restart services after update of dependencies
On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote: > On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote: > > > I want to announce restart-services here [1][2]. It's a script > > that tries to restart all services that have had their > > dependency packages updated. This is primarily useful when > > security-relevant libraries get security releases. > > > > It's using checkrestart from the debian-goodies package to do > > most of its work. > > > > Together with the unattended-upgrades package it is saving me > > a lot of system maintenance time, thus I am announcing it here > > in the hope that it will save others a lot of time as well. > > Sounds useful, maybe put it in the debian-goodies package? What, yet another feature reserved for those in the know? Surely we should be doing this by default. Ben. > Also, please blacklist gdm3 and dbus since restarting them currently > kills GNOME sessions (and probably other user desktop sessions started > by gdm3). -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
new sections: education & metapackages
Hi, /usr/share/doc/debian-policy/upgrading-checklist.txt.gz reads: 2.1. Version 3.9.3.0 2.4 New archive sections _education_, _introspection_, and _metapackages_ added. And now I wonder under which section to move the debian-edu* packages to: "education" for all but those build from "debian-edu", which belong under meta-packages? Or are they all metapackages as their purpose is to setup an education distro and since they dont contain educational software themselves? cheers, Holger -- 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/201206181543.48305.hol...@layer-acht.org
Re: Bug#677942: ITP: xz-java -- Java library with a complete implementation of XZ data compression
On Sun, Jun 17, 2012 at 06:10:30PM -0430, Miguel Landaeta wrote: > * Package name: xz-java > Description : Java library with a complete implementation of XZ data > compression > > XZ for Java aims to be a complete implementation of XZ data compression > in pure Java. Do you happen to have such a pure implementation in a language likely to be present on minimal ancient systems? I'm afraid the only remotely sane one found there is Perl (and as mirabilos said in a private conversation, some BSDs lack even that). -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. signature.asc Description: Digital signature
Re: Bug#677942: ITP: xz-java -- Java library with a complete implementation of XZ data compression
On Mon, Jun 18, 2012 at 9:32 AM, Adam Borowski wrote: > Do you happen to have such a pure implementation in a language likely to > be present on minimal ancient systems? I'm afraid the only remotely sane > one found there is Perl (and as mirabilos said in a private conversation, > some BSDs lack even that). There is a decompressor designed for embedded systems: http://tukaani.org/xz/embedded.html -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche -- 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/cahuk4kyonolrs7bkoeyyej9h4wmbou5dfd9dq7ddykf1ndd...@mail.gmail.com
Bug#678003: ITP: credns -- DNS(SEC) verification proxy
Package: wnpp Severity: wishlist Owner: "Ondřej Surý" [Note: DNSSEX has been recently renamed to credns.] * Package name: credns Version : 0.2.10 Upstream Author : NLNet Labs * URL : http://www.nlnetlabs.nl/projects/dnssexy/ * License : BSD Programming Lang: C Description : DNS(SEC) verification proxy Credns is a software program aimed at fortifying DNSSEC by performing validation in the DNS notify/transfer-chain. Currently credns is a fork of the NSD3 that has been extended with the possibility to asses zones (received or updated by AXFR or IXFR) by running an external verifier. Only zones that are deemed correct by the verifier will be notified to (public) slave servers and offered for transfer. . Credns allows to specify an external validator which is called just after a zone is received by transfer, but just before the zone will be served (and delivered via transfer). -- 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/20120618142424.24994.70168.reportbug@localhost6.localdomain6
Malloc and security
Hiya Just a quick question, which malloc, is there anyway that this function (used in C) could allocate memory into already allocated memory, such as the stack - or code space! Jamie -- 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/4fdf8ecf.4030...@jatos.co.uk
Malloc and security
Hiya Just a quick question, which malloc, is there anyway that this function (used in C) could allocate memory into already allocated memory, such as the stack - or code space! Jamie -- 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/4fdf8b8e.2020...@jatos.co.uk
Re: Malloc and security
On Mon, Jun 18, 2012 at 09:25:51PM +0100, Jamie White wrote: > Hiya > > Just a quick question, which malloc, is there anyway that this > function (used in C) could allocate memory into already allocated > memory, such as the stack - or code space! Assuming that the program uses memory correctly, no. But if the program has a bug that causes it to write to unallocated memory, it could corrupt the memory allocator's state so that malloc later returns memory that has already been allocated. This isn't really on-topic for debian-devel, as it's a general C language/library question. Perhaps you should send further questions to the comp.lang.c newsgroup, unless they're specific to development of the Debian distribution. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120618203815.gm2...@decadent.org.uk
Re: Malloc and security
On Mon, Jun 18, 2012 at 09:25:51PM +0100, Jamie White wrote: > Just a quick question, which malloc, is there anyway that this > function (used in C) could allocate memory into already allocated > memory, such as the stack - or code space! The debian-devel mailing list is meant for development _of_ Debian, not _with_ Debian. In other words, we use this list for discussing how to make Debian itself better. Your question seems to be better suited for the other category. For that, I do not know of suitable mailing lists, but the Usenet newsgroup comp.lang.c would do; also the website http://stackoverflow.com/ may be helpful. (The short answer is: It's not a problem in malloc, it's a problem in your code, and you probably have a pointer problem or your code uses memory that has already been freed.) Happy hacking. -- All my predictions will turn out to be false signature.asc Description: Digital signature
Re: Malloc and security
On 18/06/12 21:11, Jamie White wrote: > Hiya > > Just a quick question, which malloc, is there anyway that this function > (used in C) could allocate memory into already allocated memory, such as > the stack - or code space! > > Jamie > > Cross posting offtopic email to two mailing lists (ubuntu-devel and debian-devel) is not nice. If you want quicker response times IRC would have been more appropriate. -- Regards, Dmitrijs. -- 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/4fdf9254.5080...@debian.org
Re: Malloc and security
On 18/06/12 21:25, Jamie White wrote: > Hiya > > Just a quick question, which malloc, is there anyway that this function > (used in C) could allocate memory into already allocated memory, such as > the stack - or code space! > > Jamie > > sorry, not to two mailing lists. to the same one twice in a very short space of time. Could have been a user / mail client error. -- Regards, Dmitrijs. -- 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/4fdf92ae.3080...@debian.org
Re: Malloc and security
In fact I didn't send it to both, I resent twice, a mistake as I thought the first email hadn't sent properly. Jamir Sent from my BlackBerry® smartphone on O2 -Original Message- From: Dmitrijs Ledkovs Sender: Dmitrijs Ledkovs Date: Mon, 18 Jun 2012 21:40:52 To: Cc: Subject: Re: Malloc and security On 18/06/12 21:11, Jamie White wrote: > Hiya > > Just a quick question, which malloc, is there anyway that this function > (used in C) could allocate memory into already allocated memory, such as > the stack - or code space! > > Jamie > > Cross posting offtopic email to two mailing lists (ubuntu-devel and debian-devel) is not nice. If you want quicker response times IRC would have been more appropriate. -- Regards, Dmitrijs. -- 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/4fdf9254.5080...@debian.org
Re: Malloc and security
Aaah, any packages that need maintaining? Has there been swearing before? I assume to private email addys. Jamie On 18/06/2012 22:12, Dmitrijs Ledkovs wrote: I totally understand top posting from mobiles. Well, debian has improved, there was no swearing this time around, I don't think. Thick skin is good, please maintain a few packages. Regards, Dmitrijs. On 18/06/12 22:00, Jamie White wrote: Oh thats flaming? Just seems like just friendly requests not todo stuff. Certainly, had faaa worse said to me! I'm thick skinned :P Btw, please excuse top loading, BB doesn't allow base loading! Keeping same flow now though. Jamie On 18/06/2012 21:52, Dmitrijs Ledkovs wrote: anyway... You have been flamed to death by now =))) Welcome to friendly debian development. Smile, it gets worse (tm) =) feel free to him me up if you need advice or a sponsor. On 18/06/12 21:48, ja...@jatos.co.uk wrote: Okies, I ignore the second email I sent, I'll just send this one to you as not to clutter the list. Yeah, like I say, an error in thinking first one hadn't gone, apologies for that. Jamie --Original Message-- From: Dmitrijs Ledkovs Sender: Dmitrijs Ledkovs To: ja...@jatos.co.uk Subject: Re: Malloc and security Sent: 18 Jun 2012 21:45 sent an apology to the debian-devel. There are two identical emails to debian-devel ~10mins apart or so. On 18/06/12 21:44, ja...@jatos.co.uk wrote: I am not quite sure how it ended on Ubuntu devel, I didn't send it there... Sent from my BlackBerry® smartphone on O2 -Original Message- From: Dmitrijs Ledkovs Sender: Dmitrijs Ledkovs Date: Mon, 18 Jun 2012 21:40:52 To: Cc: Subject: Re: Malloc and security On 18/06/12 21:11, Jamie White wrote: Hiya Just a quick question, which malloc, is there anyway that this function (used in C) could allocate memory into already allocated memory, such as the stack - or code space! Jamie Cross posting offtopic email to two mailing lists (ubuntu-devel and debian-devel) is not nice. If you want quicker response times IRC would have been more appropriate. -- 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/4fdf9a88.7080...@jatos.co.uk
Re: Announce: script to automatically restart services after update of dependencies
On Mon, 18 Jun 2012 14:10:46 +0100, Ben Hutchings wrote: > On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote: >> On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote: >> >> > I want to announce restart-services here [1][2]. It's a script >> > that tries to restart all services that have had their >> > dependency packages updated. This is primarily useful when >> > security-relevant libraries get security releases. >> > >> > It's using checkrestart from the debian-goodies package to do >> > most of its work. >> > >> > Together with the unattended-upgrades package it is saving me >> > a lot of system maintenance time, thus I am announcing it here >> > in the hope that it will save others a lot of time as well. >> >> Sounds useful, maybe put it in the debian-goodies package? I've proposed this to Javier [3] and it's been quite well received :-) > What, yet another feature reserved for those in the know? Surely we > should be doing this by default. I agree. Could you suggest a way forward? Currently I'm aiming for debian-goodies, however maybe unattended-upgrades would be a better fit. However I think really it should go into apt-level inftrastructure. ? >> Also, please blacklist gdm3 and dbus since restarting them currently >> kills GNOME sessions (and probably other user desktop sessions started >> by gdm3). Noted. I'll discuss this with Javier. PS: Sorry Ben for also replying in private to you. I'll have to get used to mailing lists (and my web mail client) again :-o [3] http://bugs.debian.org/676509 -- 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/dd2dff74094493356b2da0485cc34...@mail.sp-metanet
Re: Summary: Moving /tmp to tmpfs makes it useless
On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote: > 2012/6/10 Wouter Verhelst wrote: > > >> A lot of people (including you) said that tmpfs makes things faster. But > >> there were no examples of popular use-cases becoming faster because > >> of /tmp on tmpfs, so I had nothing to quote. > > > > You're not even trying. > > > > if tmpfs is faster than (say) ext4, then anything which uses /tmp will > > obviously speed up. > > That's not true. Only applications, that are limited by /tmp speed will > become faster then. Do you know such applications? Any application which performs I/O anywhere has a chance of being limited by it. If you write to /tmp on disk and someone or something calls "sync" at precisely the wrong moment, you're stuck, and your performance suffers. Not so with tmpfs. I'm not saying the speedup will be extreme, but it will be there, and (cumulated over loads of programs using /tmp) it will be significant enough to be noticeable. > > Can I provide a use case where this will matter? Not necessarily. But > > then, can you provide a use case where this will *not* matter? Really? > > Yes. Everything. Oh, interesting. You have the data to back that claim up? > Every popular /tmp usage that most users expect to work > is limited either by CPU (gcc compiling) I don't think compiling C code has been CPU bound since before I was born (and I was born in the late 70s, so that's quite a while). C++ is a different matter, but still. > or by network speed (browser or flash temporaries), or is just too > fast already (bash heredoc). You make it sound as if those three are the only uses of /tmp. That's just not true. Here are some other real-world uses of /tmp, which are (or can be) I/O bound and where the size is significant enough that it makes a difference: - The nbd test suite stores fairly large files in $TMPDIR on which it then runs nbd-server (yes, maybe that's cheating since I maintain nbd; still, it's been that way for quite some time now, certainly since before tmpfs was the default). - Any data transformation or filtering which needs to be done in multiple passes over a file would use a temporary file for intermediate results, which it then reads in again for the next pass. Multi-pass video transcoding is an example of this, and which (depending on the codecs used and the hardware on which it runs) could certainly be I/O bound. - using mc on a tar.gz which was compressed with --fast I could probably go on if I really wanted to, but that's fairly boring. The point is that neither you nor I can reasonably be expected to list all possible uses of /tmp; and that RAM is faster than disk, so that when you access a tmpfs you're going to be somewhat faster than when you access a disk-backed filesystem, at least until you start swapping (if not longer). Now whether that advantage outweighs the disadvantages you've outlined is something we can talk about. However, whether RAM is faster than disk isn't; and the fact that avoiding disk access will result in speedups, no matter how small, isn't up for discussion either. [...] > >> Nobody could provide examples or numbers of how much /tmp on tmpfs > >> reduces amount of writes, and tests showed that tmpfs+swap may even > >> increase amount of writes (hence not always good for SSD), > > > > True, but then swapping to an SSD is the "best" idea since "640kB is > > enough for everyone" :-) > > Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea > to use tmpfs without swap, since it would be too small and may even > trigger OOM killer. When is it good to use tmpfs then? ;) I never used tmpfs on a system with swap, and I've not often seen the OOM killer start doing its job. My current machine has 4GiB of RAM, which seems to be more than enough. The only exception was when I was trying to run one VM too many, which then tried to eat up 110% of my RAM, but that wasn't a good idea in any case. [...] > >> tmpfs does not have 5% overflow safety, > > > > Because it doesn't need it. > > The 5% overflow safety exists for two reasons: > > - to avoid excessive fragmentation (which is not relevant for tmpfs) > > - to allow you to clean up when the filesystem does fill up. > > You missed one more reason. When user fills the entire /tmp on disk, it > does not break system services, since root can still use those 5%. Most system services do not run as root, so that's not a real advantage. However, even if they did, your statement is still wrong: > User cannot break the system filling /tmp on disk. But he can do that > if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of > failure for servers. No, that's not true. The real danger in filling up /tmp is not that other processes can't write temporary files anymore (causing a minority of processes to hang or die; those who just happen to need temporary storage at that point in time), but that no process can write any file anymore (causing a significant majori
Bug#678059: ITA: tilp2 -- Texas Instruments hand-helds <-> PC communication program for X
Package: wnpp Severity: wishlist Owner: Albert Huang * Package name: tilp2 Version : 1.1.2 Upstream Author : Lionel Debroux * URL : http://lpg.ticalc.org/prj_tilp/ * License : GPL Programming Lang: C Description : Texas Instruments hand-helds <-> PC communication program for X TiLP2 is a Texas Instruments hand-helds <-> PC communication program for Linux. It is able to use any type of link cable (Gray/Black/Silver/Direct Link) with any calculator. See http://lpg.ticalc.org/. With TiLP, you can transfer files from your PC to your Texas Instruments calculator, and vice-versa. You can also make a screen dump, send/receive data, backup/restore contents, install FLASH applications or upgrade OS. -- 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/20120618213919.6747.4541.reportbug@ubuntu
Re: Why is irqbalance package so out of date?
On Sat, 16 Jun 2012 01:53:02 +0100 Ben Hutchings wrote: > On Fri, 2012-06-15 at 08:54 -0700, Stephen Hemminger wrote: > > Irqbalance project has moved to http://code.google.com/p/irqbalance/ > > The current Debian package is back at 0.56 (over 2yrs old) > > and upstream is now at version 1.0.3 > > As someone else pointed out, it would help if the maintainers got their > act together and made irqbalance.org point to this. It's not as if > they're unassociated with the owner of that domain. > > Aside from that, Anibal might appreciate a co-maintainer, and I know you > were wanting to get more involved in Debian development. :-) I will be happy to get involved; upstream irqbalance is on my list of things that are broken and needs to be fixed. Will try and get a hold of past contributors to figure out what is happening. I know there was talk of fixing it and integrating Holger's irqd logic. signature.asc Description: PGP signature
Re: Summary: Moving /tmp to tmpfs makes it useless
Wouter Verhelst wrote: > I don't think compiling C code has been CPU bound since before I was > born (and I was born in the late 70s, so that's quite a while). C++ is a > different matter, but still. Bullshit. GCC uses a lot of CPU unless you compile without optimization, and is surprisingly slow even if you do (nowhere near linear disk access speed). -- 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/1340068942.23020.5.camel@glyph.nonexistent.invalid
Re: Why is irqbalance package so out of date?
On Mon, 18 Jun 2012, Stephen Hemminger wrote: > I will be happy to get involved; upstream irqbalance is on my list > of things that are broken and needs to be fixed. Will try and get a hold Could you elaborate on this? > of past contributors to figure out what is happening. I know there was > talk of fixing it and integrating Holger's irqd logic. Don't cache topology and sibling relationship also play a role on maximum PPS throughput NIC interrupt routing when assigning interrupts to proper multiqueue NICs? Especially when Intel DCA is enabled? Although trying to route the packet while it is still cache-hot might as well be a pipe dream... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120619025617.gc6...@khazad-dum.debian.net
Re: DEP-8 extension proposal: Add source package header
Hello Ian, Ian Jackson [2012-06-15 17:18 +0100]: > > I saw that coming: There would be little dispute about adding a > > header, but lots of difficulty to find a good name. :-) Perhaps we > > should think about an actual name for DEP-8 first (similar to what we > > had with DEP-5 -> "copyright 1.0 format"), and then use an > > abbreviation of that for the XS-Testsuite: value? > > Is there some reason why we can't use "autopkgtest" ? It's a pretty > boring name really and I don't mind it being reused for both spec and > implementation. That's a thing we do quite often anyway. Eg "dpkg" :-) FTR, I think "autopkgtest" as a spec name is just fine. It conveys what the standard is about rather well in a really short name. 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: http://lists.debian.org/20120619052042.gb3...@piware.de
