useless trivia, oldest opened bug in Debian
The oldest opened bug in Debian turns 10 years old in approximately 40 days. Bug #725 is on the twm package, submitted by Ian Jackson on Sunday the 2nd of April, 1995. Currently owned by the X-Strike Force, it is tagged normal, upstream, it was last updated Sat, 26 Jan 2002 when some kind soul updated Ian's email address for the bug. Ian Jackson wins with the 2nd and 3rd place bugs: #825: trn 825 798575581 forwarded [EMAIL PROTECTED] normal #957: dpkg 957 802533782 open [EMAIL PROTECTED] wishlist Followed, in fourth place, by the classic dselect bug #1555 which apparantly isn't a bug, according to the author, "This isn't exactly a bug report" and details something that we've all said at some time or another, "... still find the keybindings to be awkward. Since this is probably just a matter of personal taste, could dselect be modified to get its keybindings from a config file (e.g., /etc/dpkg/keybindings)???" micah signature.asc Description: Digital signature
Re: Regarding the NEW queue (Was: Re: NEW queue backing up again -- ftpmasters, any explanation or comment?)
On 2006-03-13, Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > Nobody mailed ftpmaster@ about the size of the NEW queue. -devel isn't > a contact address for ftp-master, at least speaking for myself, > mailinglists have a much lower priority than things like ftpmaster mail, > and when backlogged with mail, I tend to skip parts too, if it's too > high-traffic at times. > >> Is there a reason why the question should be made in private? > > It seems as if only problems and annoyances end up on mailinglists, and > *not* to [EMAIL PROTECTED] The don't specifically need to be made private, but > I don't think it'd be too much to ask for questions to ftpmaster to be > mailed to the our published contact address? How would you feel if > people complained about lacking piuparts updates on -devel, stating it's > unaccepteable and the maintainer should've been recruiting a > co-maintainer, without that person ever having contacted you? > > That's, roughly, what happens with ftp-master often. We do our best to > answer all inquiries, but are not perfect. However, of those issues > coming to some mailinglist, more often than not there's not even an > attempt to mail ftp-master first, or at all. It's a kind of > self-reenforcing loop if people don't think mailing helps, but then not > even try, and mail -devel instead, making people think even more that > mailing ftpmaster@ is futile. > > I agree transparency and openness are good things. I just disagree with > the implication that mailing -devel _instead_ of ftpmaster@ is a > good way to address an issue with ftpmaster. In the interests of transparancy, openness, keeping people from emailing debian-devel instead of [EMAIL PROTECTED] why not make the published contact address for ftpmaster be a publically viewable archive? It doesn't have to be a list that everyone can subscribe to and give their individual nit-pick comments about everything that is sent there, just make the email viewable. Some people email -devel because they think maybe their email to ftpmaster@ was never received, if they can verify it has been by themselves, this would be a good thing. My guess is that people dont think that mailing ftpmaster@ helps because it feels like a blackhole. If the darkness was illuminated then people could see that ftpmaster@ does try really hard to respond to things, and that your message that you sent there did arrive... Perhaps there is a concern about privacy for some reason, but I am sure issues involving privacy can be handled with care outside of a public archived list. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is SZALAY Attila MIA?
Is SZALAY Attila <[EMAIL PROTECTED]> MIA? His last upload was over three months ago (Feb 10th, 2005) and does not respond to his emails. I've tried contacting him via his debian email address with no success (first message sent April 13th, CC'd co-maintainer <[EMAIL PROTECTED]> who responded; sent a reminder message May 11th, and now it has been over a week since I sent that, with no response). Looking at the BTS, it doesn't seem as if he is responding to bug reports, there are many old bugs that have patches which fix the bugs and there were a number of wishlist bugs for upgrading to various versions as new versions came and went. Although there is nothing wrong with only maintaining 3 packages, none of them are maintained by himself (all are co-maintained) and zorp has a FTBFS that has a patch to fix and I'm wondering if it ever will be I've been cleaning up the BTS for syslog-ng there were multiple bugs for an upgrade to a new version, I've merged all those together. One I closed because the bug was requesting the version that was uploaded in January. I did an NMU to fix a security bug which resolved 3 different long-standing bugs reporting the same issue, the oldest being 168 days old. I would like to take the syslog-ng package and give it the attention that it deserves, but I did not wish to be rude. I have tried to contact the maintainer to offer my help for over a month with a reminder ping email, so I am now sending this message here as the MIA procedure suggests. At what point would it be appropriate to begin to actively maintain syslog-ng? Thanks, Micah signature.asc Description: Digital signature
Re: Is SZALAY Attila MIA?
On Wed, 18 May 2005, Jeroen van Wolffelaar wrote: > On Wed, May 18, 2005 at 12:19:50PM -0500, Micah Anderson wrote: > > At what point would it be appropriate to begin to actively maintain > > syslog-ng? > > It's been 'only' a few months since nothing has been heard -- I've added > your hint now to the MIA database for later followup, and will orphan > when no reaction is forthcoming after a number of pings, so that you can > take over. Thanks, as I have mentioned a couple times to both the maintainer and the co-maintainer, I would be happy to give syslog-ng the attention it deserves, so when orphan time comes, let me know so I can do some work on it. So that I might have an idea for planning my work-load, what time frame are you talking about? > > For sarge, this is all just not relevant anyway, so there is no great > hurry, and for urgent stuff one can NMU. I'd typically suggest to just > be a bit patient after making sure QA/MIA knows about it (I now know), > to prevent cases of premature hijacking. No, it is not important now for sarge, although I would have preferred to get the more stable version into sarge before the freeze. I have performed a NMU on syslog-ng to fix a security bug already. I sent this message because I did not want to prematurely hijack. It is my understanding that the process is to attempt to contact the maintainer a couple times, then if no response, contact debian-devel to see if anyone else knows. This is why I am here. > Thanks for noticing and taking care for now of syslog-ng! No problem, I noticed because I make heavy use of syslog-ng and there are many bugs that I think can be easily fixed. Micah signature.asc Description: Digital signature
Re: [debian-devel] Is SZALAY Attila MIA?
It is common for developers to be buried in other work, I know, I often get this way, it is understandable. However, it has now been several months and as section 3.4 of the Developers Reference says: its important "... to let the others know that you're unavailable." So, I think it is appropriate to follow the procedure by sending a mail to [EMAIL PROTECTED] with "[VAC] " prepended to the subject of your message and state the period of time when you will be [unavailable]. If overworked and people are offering to help, it might be worthwhile to take the offer! Micah On Wed, 18 May 2005, Magosányi Árpád wrote: > Hi! > > He is just overworked a bit, just like me. > Trying to do something soon. > > Sorry. > > -- > GNU GPL: csak tiszta forrásból signature.asc Description: Digital signature
depending on shared libbfd from binutils-dev
The package description for binutils-dev says the following: >Description: The GNU binary utilities (BFD development files) This > package includes header files and static libraries necessary to build > programs which use the GNU BFD library, which is part of binutils. > Note that building Debian packages which depend on the shared libbfd > is Not Allowed. I see this in the binutils-dev package description, however I dont see it anywhere else, not in the policy, not in lintian/linda checks, not on any mailing lists I see a couple of people on debian-devel asking (a couple years ago) what the deal is with this, but no informative responses. Does anyone know *why* this is and why this isn't documented somewhere more visible? Thanks, micah signature.asc Description: Digital signature
Re: idea for project machines
On 2006-03-30, Bastian Blank <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 27, 2006 at 03:28:42PM +0530, Ganesan Rajagopal wrote: >> How about providing this access only in a Xen guest? > > We have vserver enabled kernels for some arches in the archive. In fact all arches that we support (except for parisc/hppa until the dietlibc-dev syscall fix is uploaded with the patch I submitted last night: #351875). However, I am curious how people are proposing to use something like vservers for this purpose. Probably the best thing would be to allow individual developers to "check out" new vservers. You would have the option of picking a woody, sarge, etch, or sid vserver, and a period of time that the vserver would stay around, after which it would be scheduled for removal. If you had a vserver guest "checked out" on a system, you could "renew" it, thus extending the time it will exist. A simple email can be sent warning you of your vserver's pending removal a few days before, and then after it has been removed. Space may be a problem if too many vservers are "checked out" at one time[1], so there would be some simple limits placed on disks (and other resources) per verserver, and developers would not be able to "check out" a vserver if a certain disk ceiling was currently in affect. I imagine that this would be tremendously useful to developers as it provides you with root access to an environment on an architecture to develop and resolve packaging issues without having to wait on the admin of the machine to install a package you need. micah 1. space issues can be mitigated if the host is running etch because the vhashify vserver ability to "unify" guests to save disk space by performing link inversion immutability operations. The libbeecrypt6 problems were not fixed before sarge released, so this is currently not possible on a sarge system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#544338: ITP: tahoe-lfs -- A secure distributed filesystem
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: tahoe-lfs Version : 1.5.0 Upstream Author : Allmydata, INC * URL : http://allmydata.org * License : GPLv2 or later Programming Lang: Python Description : A secure distributed filesystem Tahoe, the Least Authority File System, is a distributed filesystem that features high reliability, strong security properties, and a fine-grained sharing model. Files are encrypted, signed, erasure-coded, then distributed over multiple servers, such that any (configurable) subset of the servers will be sufficient to recover the data. The default 3-of-10 configuration tolerates up to 7 server failures before data becomes unrecoverable. . Tahoe offers "provider-independent security": the confidentiality and integrity of your data do not depend upon the behavior of the servers. The use of erasure-coding means that reliability and availability depend only upon a subset of the servers. . Tahoe files are accessed through a RESTful web API, a human-oriented web server interface, and CLI tools. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hot to build i386 on amd64 using pbuilder?
On Thu, 17 Jan 2008 16:01:42 +0100, Adam Borowski wrote: > On Thu, Jan 17, 2008 at 01:28:03PM +, Anton Piatek wrote: >> I have noticed another error in the logs, there are permission errors >> on /dev/null >> Logging into the chroot reveals /dev/null is 644, not 666 as I would >> expect. >> >> How can I fix the permissions of /dev/null under the chroot? >> >> Are my problems likely to be cause by the fact that my machine is >> running as a vserver? > > Yes, on vserver root is not really root. You can't mknod, mess with > device files, mount filesystems, mess with network, etc. Even some of > the restrictions which have already been fixed on newer versions are by > default (proper paranoia) masked away with machine capabilities. > > Both pbuilder and piuparts fail extremely badly, even though one would > expect them to have support for virtualization. But unless one of us > bothers enough to fix it, the support won't be there. > Because I am a "raving vserver zealot" I will point out that if you don't mind compromising the host's security inside the vserver, you can add the CAP_MKNOD capability to this vserver, which will enable the ability to make device nodes via mknod and likely will cause pbuilder and piuparts work as advertised. If you add this capability the vserver, you are giving the root access to make random devices inside the vserver, which effectively compromises the entire security isolation point of the vserver model. If you can create the /dev/hda device node and start poking around outside of the security context, then you are asking for trouble. But if its your own box, and you are fine with that, then all you need to do is: echo "CAP_MKNOD" > /etc/vservers//bcapabilities and then restart your vserver. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#572029: ITP: pppd-sql -- pppd-sql provides a MySQL or PostgreSQL backend for CHAP/PAP pppd authentication
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: pppd-sql Version : 0.8.0 Upstream Author : Maik Broemme * URL : https://babelize.org/pppd-sql.php * License : GPLv3 Programming Lang: C Description : pppd-sql provides a MySQL or PostgreSQL backend for CHAP/PAP pppd authentication pppd-sql is a plugin for the Point-to-Point server (pppd) that adds an authentication backend using a MySQL or PostgreSQL database for the Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). It supports MS-CHAPv1 and MS-CHAPv2 too. The IPCP negotiation after authentication handshake is also supported. pppd-sql supports a flexible configuration scheme, has concurrent connection handling for single users across multiple tunnel servers, and comes with easy and handy documentation -- 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/20100301045548.10395.29084.report...@lillypad.riseup.net
Bug#572555: ITP: libcompass-ruby -- Compass is a SASS-based stylesheet authoring tool
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libcompass-ruby Version : 0.10.0.pre8 Upstream Author : Chris Eppstein * URL : http://wiki.github.com/chriseppstein/compass/ * License : Public Domain Programming Lang: Ruby Description : Compass is a SASS-based stylesheet authoring tool Compass is a stylesheet authoring tool that uses the Sass stylesheet language to make your stylesheets smaller and your web site easier to maintain. Compass provides ports of the best of breed css frameworks that you can use without forcing you to use their presentational class names. It’s a new way of thinking about stylesheets. -- 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/20100304205426.3194.64645.report...@lillypad.riseup.net
Bug#572586: ITP: libruby-fssm -- keeps track via inotify the state paths and fires events when state changes
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libruby-fssm Version : 0.1.3 Upstream Author : Travis Tilley * URL : http://github.com/ttilley/fssm * License : MIT Programming Lang: Ruby Description : keeps track via inotify the state paths and fires events when state changes The File System State Monitor keeps track of the state of any number of paths and will fire events when said state changes (create/update/delete). FSSM supports using Inotify on GNU/Linux. -- 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/20100304224533.6592.26814.report...@lillypad.riseup.net
Bug#572597: ITP: libffi-ruby -- ruby extension for loading dynamic libraries, binding functions, and calling those functions from ruby code
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libffi-ruby Version : 0.6.2 Upstream Author : Wayne Meissner * URL : http://wiki.github.com/ffi/ffi * License : MIT Programming Lang: Ruby, C Description : ruby extension for loading dynamic libraries, binding functions, and calling those functions from ruby code Ruby-FFI is a ruby extension for programmatically loading dynamic libraries, binding functions within them, and calling those functions from Ruby code. Moreover, a Ruby-FFI extension works without changes on Ruby and JRuby. Discover why should you write your next extension using Ruby-FFI here[http://wiki.github.com/ffi/ffi/why-use-ffi]. -- 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/20100305033920.1823.83828.report...@lillypad.riseup.net
Bug#572694: ITP: librb-inotify-ruby -- simple linux kernel inotify wrapper for monitoring file and directory changes
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: librb-inotify-ruby Version : 0.7.0 Upstream Author : Nathan Weizenbaum * URL : http://github.com/nex3/rb-inotify * License : MIT Programming Lang: Ruby Description : simple linux kernel inotify wrapper for monitoring file and directory changes This is a simple ruby wrapper over the inotify Linux kernel subsystem for monitoring changes to files and directories. It uses the FFI gem to avoid having to compile a C extension. -- 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/20100305183710.21118.47640.report...@lillypad.riseup.net
Bug#573874: ITP: compass-susy-plugin -- Susy is a elastic grid framework for Compass
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: compass-susy-plugin Version : 0.6.3 Upstream Author : Eric Meyer * URL : http://www.oddbird.net/susy/ * License : MIT Programming Lang: Ruby Description : Susy is a elastic grid framework for Compass Susy is a semantic CSS framework, entirely native to Compass. Susy is an elastic grid system that will never activate the side-scroll bar. With Susy you can build quick, custom grids that respond to the needs of the user without giving up design integrity. Susy sets your width on the outer element (container), adds a max-width of 100% and builds the rest of your grid in percentages. The philosophy and technique are based on Natalie Downe's "CSS Systems" - which introduces difficult math in the service of beautiful structure. Using simple mixins, columns can be created, suffixed, prefixed, and nested easily - and always in flexible percentages. -- 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/20100314163403.20393.2100.report...@algae.riseup.net
Re: Invite to join the Release Team
Clint Adams writes: > [Adding and M-F-T-ing -project] > > On Sun, Mar 14, 2010 at 10:04:58AM +0100, Marc 'HE' Brockschmidt wrote: >> I want to point out that Luk's mail was not in any way discussed in the >> release team. I think it is horrible. >> >> I welcome everyone to critize the release team. I would prefer help, of >> course, but on the other hand, I do understand that people can see a >> problem, but don't have the time to fix. It would be nice if such >> criticism would be sent directly to the release team, and bluntly >> point out what the problem is, as that makes it easier to work on the >> issue. > > Okay, so when there is a mysterious release team meeting in Cambridge, > and there is no discussion or planning of it on debian-release, or > #debian-release, or anywhere else public that I can see, and there is > zero evidence that it was planned or happened on official channels, > and at least two of the participants (or whom I assume were participants) > tell me that transparency is either completely unimportant or > low-priority, and the DPL-2IC team seems to favor the opposite of > transparency, how is one supposed to know about this meeting in > time to complain about it? How and why should one complain to the > release team directly? > > Were you there? Were Debian funds spend on this endeavor? What > happened there? Most importantly, why is it all so secretive? Did I miss a response to these questions? I'm interested to know the answer to at least two of them. micah -- 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/877hot58v2@pond.riseup.net
Re: Xen support on Squeeze
"Nikita V. Youshchenko" writes: >> We have had to carry that patch without any upstream support (or sharing >> with Novell, which eventually released SLES 11 with 2.6.27). As a >> result, the xen-flavour kernels for lenny are very buggy, particularly >> for domains with multiple vCPUs (though that *may* be fixed now). > > Unfortunately it is not fixed. > > We here once migrated to xen and now rely on it, and that gives lots of > frustration. For any loaded domain we still have to run etch kernel, > because lenny kernel constantly crashes after several days of heavy load. > Dom0's run lenny kernel - and with a fix for #542250 they don't crash, but > those are almost unloaded. I was having problems with multiple vCPUs also, under moderate load I would regularly get crashes. I reported my findings in #504805. I swapped out machines, didn't work. When the fix for the xen_spin_wait() came out, I eagerly switched to that, but it didn't fix my problem. I even tried my hardest to switch to the latest upstream Xen kernel to see if that would fix things, but it was way too unstable and I couldn't get it to work at all. Eventually I stumbled on a way to keep my machines from restarting, its not a great solution, but it stops me from having to deal with the failure on a daily basis. I think that anyone else who is having this problem can do this and it will work. Obviously this is not the right solution, but it works until we can get a fix. First I made sure this was set: /etc/xen/xend-config.sxp: (dom0-cpus 0) Then I pinned individual physical CPUs to specific domU's, once pinned, the problem stops. What does that mean? Well, Xen does this wacky thing where it creates virtual CPUs (VCPUs), each domU has one of them by default (but you can have more), and then it moves physical CPUs between those VCPUs depending on need. So lets say you have four CPUs, and a domU. That domU has one VCPU by default. That VCPU could actually have the physical CPU 0, 1, 2, 3 all servicing it to provide that VCPU, even at the same time. I found somewhere that this can be a performance hit, because it needs to figure out how to deal with this and switch contexts. I also read that it could cause some instability (!), so pinning the physical CPUs so they don't move around seemed to solve this. The pinning does not stick across reboots, so it has to be done again if the system is rebooted, and it isn't really possible to set this in a startup script, at least I don't think so. So how do you do this? If you look at 'xm vcpu-list' (which annoyingly isn't listed in 'xm help') you will see the CPU column populated with a random CPU, depending on scheduling, and then the CPU Affinity column all say 'any cpu'. This means that any physical CPU could travel between them, and would, depending on the scheduling. Once you pin things, then the individual domU's are set to have specific CPU affinities, so the CPUs don't 'travel' between them, and magically the crash stops. So an example: r...@shoveler:~# xm vcpu-list NameID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 1 -b- 283688.8 any cpu Domain-0 0 1 1 --- 39666.3 any cpu Domain-0 0 2 1 r-- 49224.4 any cpu Domain-0 0 3 1 -b- 75591.1 any cpu kite 1 0 3 -b- 71411.8 any cpu murrelet 2 0 0 -b- 47.2 any cpu test 3 0 0 r-- 342182.3 any cpu So we want to fix that final column using 'xm vcpu-pin' (also a command not listed in 'xm help'): Usage: xm vcpu-pin Set which CPUs a VCPU can use. r...@shoveler:~# xm vcpu-pin 0 0 0 r...@shoveler:~# xm vcpu-pin 0 1 0 r...@shoveler:~# xm vcpu-pin 0 2 0 r...@shoveler:~# xm vcpu-pin 0 3 0 r...@shoveler:~# xm vcpu-pin 1 0 1 r...@shoveler:~# xm vcpu-pin 2 0 2 r...@shoveler:~# xm vcpu-pin 3 0 3 r...@shoveler:~# xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 1 -b- 283700.3 0 Domain-0 0 1 1 r-- 39669.6 0 Domain-0 0 2 1 -b- 49227.4 0 Domain-0 0 3 1 -b- 75596.2 0 kite 1 0 3 -b- 71415.3 1 murrelet 2 0 0 -b- 472237.8 2 test 3 0 0 r-- 342182.3 3 And voila, no more crashes... :P micah -- 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/87d3yj7yh3@pond.riseup.net
Re: Xen support on Squeeze
On 2010-04-06, micah anderson wrote: > On Thu, Apr 01, 2010 at 03:40:40PM -0400, Micah Anderson wrote: > > "Nikita V. Youshchenko" writes: > > > > >> We have had to carry that patch without any upstream support (or sharing > > >> with Novell, which eventually released SLES 11 with 2.6.27). As a > > >> result, the xen-flavour kernels for lenny are very buggy, particularly > > >> for domains with multiple vCPUs (though that *may* be fixed now). > > > > > > Unfortunately it is not fixed. > > > > > > We here once migrated to xen and now rely on it, and that gives lots of > > > frustration. For any loaded domain we still have to run etch kernel, > > > because lenny kernel constantly crashes after several days of heavy load. > > > Dom0's run lenny kernel - and with a fix for #542250 they don't crash, > > > but > > > those are almost unloaded. > > > > I was having problems with multiple vCPUs also, under moderate load I > > would regularly get crashes. I reported my findings in #504805. I > > swapped out machines, didn't work. When the fix for the xen_spin_wait() > > came out, I eagerly switched to that, but it didn't fix my problem. I > > even tried my hardest to switch to the latest upstream Xen kernel to see > > if that would fix things, but it was way too unstable and I couldn't get > > it to work at all. > > > > What do you exactly mean with the 'upstream Xen kernel' ? The latest xen-kernel, not from Debian. There are a number of them, the Novell/OpenSuse forward-port of the old-style xenlinux patches, and the pvops dom0 git tree. The pvops one was the one I was trying to get working since the other versions of the kernel aren't receiving any attention and all dev is happening in the pvops. > > Eventually I stumbled on a way to keep my machines from restarting, its > > not a great solution, but it stops me from having to deal with the > > failure on a daily basis. I think that anyone else who is having this > > problem can do this and it will work. Obviously this is not the right > > solution, but it works until we can get a fix. > > > > First I made sure this was set: > > > > /etc/xen/xend-config.sxp: (dom0-cpus 0) > > > > Then I pinned individual physical CPUs to specific domU's, once pinned, > > the problem stops. > > > > vcpu pinning is not required for a properly working kernel.. It shouldn't be, I agree... but it seems like it is required to keep the kernel from a daily panic. m pgpEf1qHpKVOJ.pgp Description: PGP signature
Re: Xen support on Squeeze
> Novell is actively developing their SLES11 2.6.27 kernel-xen, > and upcoming SLES11 SP1 will have 2.6.32 kernel-xen. I did not know that. > > > vcpu pinning is not required for a properly working kernel.. > > > > It shouldn't be, I agree... but it seems like it is required to keep the > > kernel from a daily panic. > > > > Does this happen with other kernels aswell? I thought the bug only happens > with the lenny 2.6.26-2-xen kernels. As I said before, I was not able to get any other kernel to work properly. micah pgphRV44BFW0Y.pgp Description: PGP signature
Re: [OT] Re: Open then gates
Christoph Anton Mitterer writes: > On Sat, 2010-05-15 at 21:01 +0800, Paul Wise wrote: >> You might be interested in monkeysphere > ...and in RFC 5081 > > I haven't had a detailed look on monkeyspehre so far, but it seemed at a > first glance, that it does not use standardised technology, does it? Can you clarify what you mean by "standardised technology"? I work on the monkeysphere project, and from my point of view, I'd have to disagree with you, but I may not understand what you mean. micah -- 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/87zkzz5fvo@pond.riseup.net
Re: [OT] Re: Open then gates
Christoph Anton Mitterer writes: > On Sat, 2010-05-15 at 21:01 +0800, Paul Wise wrote: >> You might be interested in monkeysphere > ...and in RFC 5081 > I haven't had a detailed look on monkeyspehre so > far, but it seemed at a first glance, that it does not use > standardised technology, does it? Can you clarify what you mean by "standardised technology"? I work on the monkeysphere project, and from my point of view, I'd have to disagree with you, but I may not understand what you mean. micah -- 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/87vdan5fp3@pond.riseup.net
Re: [OT] Re: Open then gates
On Mon, 17 May 2010 08:25:50 +, Christoph Anton Mitterer wrote: > On Mon, 17 May 2010 00:12:56 -0400, Micah Anderson > wrote: > > Can you clarify what you mean by "standardised technology"? I work on > > the monkeysphere project, and from my point of view, I'd have to > > disagree with you, but I may not understand what you mean. > What I mean was simply something that is standardised e.g. by IETF. > > I mean using OpenPGP with SSL is already standardised now by that RFC, and > IIRC gnutls is already supporting it... RFC 5081 is still quite a while off from widespread adoption. When it is more widely adopted, we will be in a much better situation, until then the monkeysphere is operating as an interim translation step (keeping the on-the-wire protocol the same). We've been closely involved in GnuTLS development, one of the monkeysphere developers has commit rights to the GnuTLS development project, and is part of the IETF TLS working group. For a while we had to provide our own version of GnuTLS because functionality that we needed for key translation was available in GnuTLS: enabling it to read authentication subkeys emitted by GnuPG under certain circumstances. The only modification needed simply enables the library to parse a GNU extension to the String-to-key (S2K) mechanism as laid out in RFC 4880. Fortunately, the patch that monkeysphere developer Daniel Kahn Gillmor provided to GnuTLS was accepted in version 2.6, so its supported natively now. > But as I wrote initially, I haven't had a closer look on it, so please > don't feel offended, or that I intended to make monkeysphere down. > Everything which gives us the chance to go away from X.509-PKI is a good > thing :) No offense taken, I suggest you take a closer look and give it a try, and if you are intrigued you should consider helping the project! micah pgpZ42IlxAejk.pgp Description: PGP signature
Re: enable/disable flags in /etc/default
Tollef Fog Heen writes: > - install configuration using puppet/chef/cfengine/etc Speaking of, the the changes that were made in Debian Squeeze to update-rc.d to accommodate for dependency-based booting broke puppet’s functionality to enable/disable services properly (#573551). Its not clear the right way to do fix this bug at the moment, input would be appreciated. micah pgpexF3LFlaNG.pgp Description: PGP signature
Re: enable/disable flags in /etc/default
Raphael Geissert writes: > That means: > # mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2 > # insserv # this bit is not documented, it seems Is using insserv directly really the right interface? Correct me if I am wrong, but if you decided to opt-out of dependency-based initscripts, wont insserv be useless? Also insserv is Priority: optional, so we can't count on that being on every system. micah pgpsoOg6wYZn0.pgp Description: PGP signature
Bug#522636: ITP: libpacket-ruby -- ruby library for Event driven network programming
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libpacket-ruby Version : 0.1.15 Upstream Author : Hemant Kumar * URL : http://packet.googlecode.com/ * License : MIT Programming Lang: Ruby Description : ruby library for Event driven network programming Packet is a pure ruby library for writing network applications in Ruby. It follows Evented Model of network programming and implements almost all the features provided by EventMachine. It also provides real easy to user UNIX workers for concurrent programming. Source code is here: http://github.com/gnufied/packet -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522637: ITP: libbackgroundrb-ruby -- BackgrounDRb is a job server and scheduler for moving long-running tasks into the background
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libbackgroundrb-ruby Version : 1.2 Upstream Author : Hement Kumar * URL : http://backgroundrb.rubyforge.org/ * License : MIT Programming Lang: Ruby Description : BackgrounDRb is a job server and scheduler for moving long-running tasks into the background BackgrounDRb is a Ruby job server and scheduler. Its main intent is to be used with Ruby on Rails applications for offloading long-running tasks. Since a Rails application blocks while serving a request it is best to move long-running tasks off into a background process that is divorced from http request/response cycle. The source can be found here: git clone git://github.com/gnufied/backgroundrb.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
This discussion has happened before, many times. Some folks spent some time on a wiki page describing the different MTAs, would be worth reviewing for some background and comparison: http://wiki.debian.org/DefaultMTA Some people clearly want postfix as the default MTA in Debian (I do), and some people dont want the default to change from Exim. There are some people who want something else, but so far that something else has not be technically satisfactory. I think our problem is, how do we go about making this decision? Micah -- #debian-devel: 09:35 < Zugschlus> the exim maintainers absolutely demand that postfix be default MTA for lenny 09:35 < Zugschlus> have the postfixites feel the pain they deserve 09:36 < Zugschlus> let the LOUD people have the work they want 09:44 < Zugschlus> realist: I fully admit that postfix is vastly superior over exim 09:45 < Zugschlus> end of discussion -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
Manoj Srivastava writes: >> On Sat, May 09, 2009 at 10:22:40PM -0500, Manoj Srivastava wrote: > Given that, I would say that churning the installation by making > a supermajority of sites change their MTA seems like a non-starter to > me. I do not see how changing the default MTA for future Debian installs will cause churn for people. If people are happy with continuing on with their currently installed Exim4 packages, they will continue to be happy with that, and should not be forced to change MTAs. Debian deciding to change MTAs affects new installs, and it signals a choice that this is the MTA that we would like to support as our default. I'm not sure why other distributions have decided to choose Postfix as their default, but if I were to take a guess I would think that it is because it is easier for new users to setup. But perhaps that is a subjective assessment based on my own experiences. micah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debconf-discuss] GPG keysigning?
* martin f krafft [2009-06-25 04:21-0400]: > > The government IDs are relevant because when we're collaborating > > on an OS where there's minimal code review of the work done by > > maintainers and a well-chosen malicious package could cause > > millions or billions of dollars in damage to our users, we[1] want > > to be able to hold someone accountable in the real world. Not an > > "identity", but a physical person that we can prosecute and send > > to jail. > > I challenged this and have not heard anything else. How exactly do > you think Debian would sue me, assuming I am in Switzerland, or > let's say Russia, Korea, or Senegal? > I think asking a handful of non-lawyers for the exact technical details about how the Debian project would go about suing you is not a particularly interesting question. You can sit back and watch a bunch of amateur-pseudo legal scholars try and provide you with some rationale and then a few days later point out that nobody knows what they are talking about because they aren't lawyers. I would argue that your question wasn't answered because it isn't the right question, it misses the point. But to entertain you... Switzerland its relatively easy due to the Mutual Legal Assistance Treaty (MLAT)[0] that has been signed by most European, and American countries. In some place like North Korea or Senegal, things are a little different. Probably what the Debian project would do is to revoke your access, which is based on your OpenPGP key, and then issue a Free Software Fatwah (FFF) on your ass and a lot of geeks are going to have a good time chasing you down. The world is big, but we have friends in a lot of places. micah 0. http://en.wikipedia.org/wiki/Mutual_Legal_Assistance_Treaty note, the US Government list of signatories is currently a 404, but interestingly is running debian: http://travel.state.gov/law/info/judicial/judicial_690.html signature.asc Description: Digital signature
Bug#710464: ITP: python-scrypt -- Python bindings for the scrypt key derivation function library
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: python-scrypt Version : 0.5.3 Upstream Author : Magnus Hallin * URL : http://bitbucket.org/mhallin/py-scrypt * License : BSD Programming Lang: Python Description : Python bindings for the scrypt key derivation function library This is a set of Python bindings for the scrypt key derivation function. . Scrypt is useful when encrypting password as it is possible to specify a minimum amount of time to use when encrypting and decrypting. If, for example, a password takes 0.05 seconds to verify, a user won't notice the slight delay when signing in, but doing a brute force search of several billion passwords will take a considerable amount of time. This is in contrast to more traditional hash functions such as MD5 or the SHA family which can be implemented extremely fast on cheap hardware. -- 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/20130531015921.29433.70885.report...@muck.riseup.net
Bug#713913: ITP: libscrypt -- scrypt shared library.
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libscrypt Version : stable1 Upstream Author : Joshua Small * URL : http://www.lolware.net/libscrypt.html * License : Upstream still deciding Programming Lang: C Description : scrypt shared library. Scrypt shared library, implementing the reference implementation of the scrypt binary. -- 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/20130623200838.29179.13209.report...@muck.riseup.net
Bug#720577: ITP: python-qt4reactor -- Provides support for Twisted to be driven by the Qt mainloop
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: python-qt4reactor Version : 1.0 Upstream Author : Michael Terry * URL : https://github.com/ghtdak/qtreactor * License : Expat Programming Lang: Python Description : Twisted Qt4 integration This package provides support for Twisted to be driven by the Qt mainloop -- 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/20130823125630.23442.68432.report...@muck.riseup.net
Re: Bug#605090: Linux 3.2 in wheezy
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez wrote: > On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote: > > On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote: > > > (adding few CC:s to keep track on the bug) > > > > > > On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: > > > > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: > > > > > On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: [...] > > > Now, I still think having a hardened Debian kernel inside the > > > distribution is helpful > > [...] > > > > I agree and I would like to see hardening of *all* our configurations, > > where the performance cost is not too much. That's going to protect all > > our users rather than just people who seek out a special paranoid > > configuration. Would you agree that there are some small hardening things that can be done that don't impact performance that much? In particular the privilege boundries mentioned earlier does not seem to introduce any particular performance cost worth worrying about. > So I think it's perfectly clear that nor Debian nor Grsecurity are > really interested in Debian shipping a Grsecurity kernel. Well, I don't think its fair to say "Debian" is not interested in shipping a Grsecurity kernel. I think its more accurate to say that the current configuration of the Debian kernel team doesn't find the time to deal with it... but I'm not sure that speaks for all of Debian. > I find that sad, because I do think there are users of both which would > benefit from that, and not only people who seek out a special paranoid > configuration. I agree. On some machines, I would gladly trade perfomance for a hardened kernel where that is more important and it is unfortunate that the attempt to appeal to all possible configurations at the same time results in a kernel that doesn't allow for specialized configurations that people want/need. > Anyway, I'll keep updating the current setup for interested people, but > without any interest from either party, that definitely looks like a > dead end. What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. micah pgpxXROPKfhj5.pgp Description: PGP signature
Re: lack of replacement for linux-vserver
Bernd Zeimetz writes: > On 01/31/2012 10:37 PM, Ben Hutchings wrote: > [...] >> If anyone wishes to volunteer to maintain VServer in Debian - you are >> very welcome, but please start by addressing the bugs filed against >> them in squeeze and reviewing the existing conflicts. If you can >> prove yourself by doing that, then you may convince me and the rest of >> the kernel team that you can maintain it in wheezy as well. >> Otherwise, no chance. >> >> The above all applies to OpenVZ as well, and what I've suggested to is >> that the interested developers maintain an APT repository of kernel >> packages for Debian using whichever version the OpenVZ project is >> prepared to support. Maybe the Linux-VServer project can do that too. > > I've tried to convince the linux-vserver developers on various ocassions > on irc to work together with a person of their choice from Debian to > maintain the patch for stable releases. But they are not willing to > support Debian as they neither use Debian nor have any interest in > supporting the Debian kernel. Hmm, I do not agree on that representation of upstream's position. On the contrary, they are happy to not only port the Linux-Vserver patches to work with the Debian kernel's set of patches, but also keeping those kernels up-to-date, as long as they are working with someone in Debian who can do the 'debian-specific' work. Neither of the two active upstream developers use Debian as a host, so they would not be people who use the kernel or have any vested interest in it. Their position is that if someone inside Debian steps up to do the 'debian-specific' work, they have no problem working with that person with both an initial port to the Debian kernel, or keeping those kernels up-to-date. -- -- 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/87ehudjj6j@algae.riseup.net
Bug#707620: ITP: python-dirspec -- Python User Folders Specification Library
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: python-dirspec Version : 4.2.0 Upstream Author : Canonical Ltd. * URL : https://launchpad.net/dirspec * License : LGPL-3 Programming Lang: Python Description : Python User Folders Specification Library A library for handling the XDG Base Directory specification, and the XDG User Directories for music, videos, etc… -- 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/20130509155316.12651.46511.report...@muck.riseup.net
Bug#707625: ITP: u1db -- Ubuntu One structured data storage - Python API
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: u1db Version : 0.1.4 Upstream Author : Canonical Ltd * URL : https://launchpad.net/u1db * License : LGPL-3 Programming Lang: Python, C Description : Ubuntu One structured data storage - Python API U1DB is a database API for synchronised databases of JSON documents. It’s simple to use in applications, and allows apps to store documents and synchronise them between machines and devices. U1DB itself is not a database: instead, it’s an API which can be backed by any database for storage. This means that you can use U1DB on different platforms, from different languages, and backed on to different databases, and sync between all of them. It's built to sync with your own servers or with Ubuntu One. -- 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/20130509183819.15506.65409.report...@muck.riseup.net
Bug#919935: ITP: golang-github-protonmail-go-autostart -- A Go library to run a command after login
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: golang-github-protonmail-go-autostart Version : 0.0~git20181114.c527205-1 Upstream Author : * URL : https://github.com/ProtonMail/go-autostart * License : MIT Programming Lang: Go Description : A Go library to run a command after login A Go library to run a command after login. This is a dependency for the package riseupvpn that is also being packaged.
Bug#919937: ITP: riseup-vpn -- Minimal, easy to use vpn client
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: riseup-vpn Version : 0.18.12 Upstream Author : LEAP Encryption Access Project * URL : https://0xacab.org/leap/bitmask-vpn * License : GPLv3 Programming Lang: Go Description : Minimal, easy to use VPN client A minimalistic implementation, written in golang, of Bitmask VPN. The only User Interface is a small systray icon. This provides simple setup for VPN service through Riseup. -- micah
Bug#919943: ITP: golang-github-getlantern-systray -- a cross platfrom Go library to place an icon and menu in the notification area
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: golang-github-getlantern-systray Version : 0.0~git20181206.eaad711-1 Upstream Author : Lantern * URL : https://github.com/getlantern/systray * License : Apache-2.0 Programming Lang: Go Description : a cross platfrom Go library to place an icon and menu in the notification area Package systray is a cross platfrom Go library to place an icon and menu in the notification area. . This is a dependency for the riseup-vpn ITP (#919937)
