gnome is completely f^Mmessed up
Hi everyone,
is this only me or do I have the feeling that we are going down
the trench with Gnome?
Repeatedly:
- first login: nautilus segfaults in libnautilus-fileroller.so
after log out and log in it sometimes works
starting it manually most of the times work, but not always
- ssh/gpg agent: most of the time just is completely useless
either does not ask, or just segfaults in libglib-2.0
- plugging/unplugging power cord makes gnome-shell crash (known bug)
- ...
When I finally manage to get a running session, then out of nothing
the blue whale appear, BSOD.
Is this a joke? Are we going to release that in June/July/whenever?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
PEEBLES (pl.n.)
Small, carefully rolled pellets of skegness (q.v.)
--- Douglas Adams, The Meaning of Liff
--
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/20120608071542.ga14...@gamma.logic.tuwien.ac.at
Re: gnome is completely f^Mmessed up
On Freitag, 8. Juni 2012, Norbert Preining wrote: > Is this a joke? Are we going to release that in June/July/whenever? yeah, the plan is to release wheezy in June .oO( OMFSM. read d-d-a. use the bts and dont rant on -devel. it's useless. ) -- 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/201206080923.42187.hol...@layer-acht.org
Re: gnome is completely f^Mmessed up
On Fri, 8 Jun 2012 09:23:41 +0200 Holger Levsen wrote: > On Freitag, 8. Juni 2012, Norbert Preining wrote: > > Is this a joke? Are we going to release that in June/July/whenever? > > yeah, the plan is to release wheezy in June > s/release/freeze/ The freeze will be in June - i.e. this month. The release comes later, how much later depends on how many people spend their Debian time fixing RC bugs and how many carry on as if the freeze didn't exist. File bugs if not filed already or feed back to existing bugs then fix the bugs and we can release. I'm not using GNOME anymore, so I can't verify whether the issues you report are reproducible from this end. However, I may well play with a Wheezy install using GNOME in a VM at some point - whether that's a fair test of some of the issues you're seeing is impossible to tell in advance. If it helps clarify/fix RC bugs, I'll do what I can but there are more than enough RC bugs to go around, I may well get distracted by others which are more directly relevant to my usage. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgptqayWEPg1v.pgp Description: PGP signature
Re: gnome is completely f^Mmessed up
Hi, On Freitag, 8. Juni 2012, Neil Williams wrote: > The freeze will be in June - i.e. this month. The release comes later, > how much later depends on how many people spend their Debian time > fixing RC bugs and how many carry on as if the freeze didn't exist. > > File bugs if not filed already or feed back to existing bugs then fix > the bugs and we can release. right, I was being sarcastic :-D Thanks for being serious. 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/201206080950.34077.hol...@layer-acht.org
Re: future of python-pipeline package
Hi Jakub, On Dienstag, 22. Mai 2012, Jakub Wilk wrote: > * Dmitry Nezhevenko , 2012-05-16, 11:57: > >I'm trying to package a ReviewBoard package that depends on > >django-pipeline module. Unfortunately there is already another package > >named python-pipeline in debian that uses same python module name > >(pipeline). This another package is orphaned for a year: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620067 > > > >I've asked it's upstream and author is going to rename it to something > > > >else: > > http://code.google.com/p/python-pipeline/issues/detail?id=1 but it seems this issue is stalled. > >apt-cache rdepends shows nothing for current python-pipeline. Also > > > >popcon shows only 48 installation without information about usage: > > http://qa.debian.org/popcon.php?package=python-pipeline > > > >So I'm asking how to deal with it? django-pipeline looks like more > >popular according to project github page and bugtracker. > > > >Holger suggests to ask here and thinks that it's better to remove > >orphaned pipeline package. > > How would the removal help? well, with the following request from yours, not much: > With my upstream and ex-maintainer hats on, I'm fine with removing > python-pipeline from unstable. However, I object to another package > taking over the module name. So the current situation is, that a package which is orphaned, has a low popcon score, no reverse depends and which the upstream maintainer is fine being removed from Debian, blocks another package, which is a depends for reviewboard (see reviewboard.org), which is a rather useful package, which now probably will not make it into wheezy because of this. I think this is a pretty sad situation. Frankly I wonder if it's reasonable to listen to your objections or not. You clearly stated you don't care about python-pipeline in Debian (sid), so I'm not sure you have any grounds blocking django-pipeline to enter. Comments, suggestions, ideas? 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/201206080956.58444.hol...@layer-acht.org
Re: gnome is completely f^Mmessed up
Hi
On Fr, 08 Jun 2012, Holger Levsen wrote:
> yeah, the plan is to release wheezy in June
Thanks for the wise words.
On Fr, 08 Jun 2012, Neil Williams wrote:
> File bugs if not filed already or feed back to existing bugs then fix
> the bugs and we can release.
Done already on several occasions. Added one for the keyring.
> I'm not using GNOME anymore, so I can't verify whether the issues you
Soon neither do I. Unfortunately it is probably another 10 releases
away from reaching a halfway stable state, comparable to gnome2.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCROGGS (n.)
The stout pubic hairs which protrude from your helping of moussaka in
a cheap Greek restaurant.
--- Douglas Adams, The Meaning of Liff
--
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/20120608080356.ga16...@gamma.logic.tuwien.ac.at
Re: this bug .. bugs me
On Wed, Jun 06, 2012 at 08:16:26PM +0200, Steven Post wrote: > Reading this I assume ia32-libs will be removed from Debian (with which > I completely agree btw), what about packages outside of Debian that > currently depend upon ia32-libs? To name a certain package: skype. Its > AMD64 package from the official website depends on it. You can use http://archive.canonical.com/pool/partner/s/skype/skype-bin_2.2.0.35-0precise3_i386.deb -- WBR, wRAR signature.asc Description: Digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
[Serge] > Well, nobody named the benefits yet. [Wouter Verhelst] > - You could mount your mail spool there, and make things go blazingly > fast [1] [...] > - There's no danger of a symlink attack or similar with things like > tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the > system, and /tmp is clean again, no matter what was there before. This > is more than just a convenience. I've happily been using tmpfs on /tmp/ for probably ten years now, and can list some more benefits: - It allow diskless setups like LTSP to work the same way the default installation in Debian work. They use read-only NFS-mounted file systems and a writable tmpfs mounted on /tmp/. - It reduces the number of disk writes on a laptop, allowing it to spin down the disk a bit longer. -- Happy hacking, Petter Reinholdtsen -- 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/2fltxymku23@login2.uio.no
Re: Processed: reassign 676001 to busybox
[Adding debian-devel@ to the Cc list] Short story (and it is short): the bug has been filed against initramfs-tools initially, it is about how /proc and /sys filesystem should be handled in initramfs when switching to new root. Original reporter included a trivial patch for initramfs that does re-mounting of these filesystems. Max reassigned it to busybox without giving any reasonings or comments whatsoever. I explained that it is none of switch_root business, in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676001#24 , and asked to not reassign bugs without giving a word of explanation. After a few days of inactivity I reassigned this bug back to initramfs, per my explanation. Now max reassigned it back. On 08.06.2012 14:49, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > >> reassign 676001 busybox > Bug #676001 [initramfs-tools] initramfs-tools: busybox's switch_root doesn't > handle /proc or /sys moving > Bug reassigned from package 'initramfs-tools' to 'busybox'. Wonderful. I asked you nicely a) to stop reassigning without explanation, and b) to provide some comments about why do you think it is a busybox isue, at the same time providing my reasoning why it is not. After you failed to provide any comments, I reassigned it back to initramfs-tools. And you, 2nd time in a row, does the same: reassigning it back to bysubox (where, as I described before, it does not belong to), and gives neither explanation nor any comments/answers to my reasoning. So I've no other "solution" but to tag this as wontfix in busybox, because I think it is not where it should be fixed, as per my previous explanation. Mind you, this "solution" does not help users at all. /mjt -- 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/4fd1db0e.6040...@msgid.tls.msk.ru
Re: Processed: reassign 676001 to busybox
On 08.06.2012 14:59, Michael Tokarev wrote: [] > Wonderful. > > I asked you nicely a) to stop reassigning without explanation, > and b) to provide some comments about why do you think it is > a busybox isue, at the same time providing my reasoning why > it is not. Ok. This was premature. Somehow I received this "reassigning" message quite a bit before the comments you actually added when doing it the second time. So yes, there are some comments now, I stand corrected. I'll address these in #676001. Thanks. /mjt -- 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/4fd1dc19.7020...@msgid.tls.msk.ru
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Petter Reinholdtsen writes: > I've happily been using tmpfs on /tmp/ for probably ten years now, and > can list some more benefits: > > - It allow diskless setups like LTSP to work the same way the default >installation in Debian work. They use read-only NFS-mounted file >systems and a writable tmpfs mounted on /tmp/. > > - It reduces the number of disk writes on a laptop, allowing it to >spin down the disk a bit longer. I'd like to add another one: - a tmpfs is always easy to grow without requiring any special preparations. Just add more swap. The swap could be on different disks, and could even be files hosted on other file systems. Any file system will run out of space given the broken applications mentioned in this thread. tmpfs is the only one which will allow all systems to dynamically add more space, only limited by the available disks. That's why tmpfs should be the default for both new and old systems, unless the administrator has explicitly made a more limited choice. Bjørn -- 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/87lijyqd2l@nemi.mork.no
Re: Processed: reassign 676001 to busybox
On Fri, Jun 08, 2012 at 02:59:26PM +0400, Michael Tokarev wrote: > [Adding debian-devel@ to the Cc list] > > Short story (and it is short): the bug has been filed > against initramfs-tools initially, it is about how > /proc and /sys filesystem should be handled in initramfs > when switching to new root. Original reporter included > a trivial patch for initramfs that does re-mounting of > these filesystems. Max reassigned it to busybox without > giving any reasonings or comments whatsoever. I explained > that it is none of switch_root business, in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676001#24 , > and asked to not reassign bugs without giving a word of > explanation. After a few days of inactivity I reassigned > this bug back to initramfs, per my explanation. Now max > reassigned it back. no, no, you get the story wrong. The bug on initramfs-tools side is fixed^Wworked-around. I reassigned the *cloned* bug to busybox to have it properly fixed there. please get an ice cream and keep cool. No need to make a drama out of a simple single bug. happy hacking -- maks -- 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/20120608112824.gg8...@vostochny.stro.at
Bug#676628: ITP: python-yubico -- Python code for talking to Yubico YubiKeys
Package: wnpp Severity: wishlist Owner: Fredrik Thulin * Package name: python-yubico Version : 1.1.0 Upstream Author : Fredrik Thulin * URL : https://github.com/Yubico/python-yubico * License : BSD-2-clause Programming Lang: Python Description : Python code for talking to Yubico YubiKeys The YubiKey is a hardware authentication token. This is a Python package for interacting with YubiKeys. Typical use is to detect, configure (personalize) or issue challenge-responses to YubiKeys. -- 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/20120608112713.6248.30781.report...@debian.lan
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 08, 2012 at 01:04:50PM +0200, Bjørn Mork wrote: - a tmpfs is always easy to grow without requiring any special preparations. Just add more swap. The swap could be on different disks, and could even be files hosted on other file systems. Yes, of course, now I’m not only wasting RAM for tmpfs but disk space for swap files? Any file system will run out of space given the broken applications mentioned in this thread. tmpfs is the only one which will allow all tmpfs will run out of space much ealier than your 2TB disk. systems to dynamically add more space, only limited by the available disks. That's why tmpfs should be the default for both new and old ROTFL, yes, of course. I can get my tmpfs bigger than my disk to back it up. Sorry, this is ridiculous. If I have enough disks available I can grow my tmp partition (or my root partition with tmp) with LVM without problems as well. Both things are nothing a standard desktop user can do by its own, but the standard desktop user will certainly have more disk space than RAM, so I’m glad this tmpfs for tmp crap is off by default. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Bug#676630: ITP: ruby-kyotocabinet -- Kyoto Cabinet is an efficient database library like GDBM and NDBM.
Package: wnpp Severity: wishlist Owner: Shawn Landden * Package name: ruby-kyotocabinet Version : 1.32 Upstream Author : Mikio Hirabayashi * URL : http://fallabs.com/kyotocabinet/ * License : GPL-3+ Programming Lang: C++ Description : Kyoto Cabinet is an efficient database library like GDBM and NDBM. Kyoto Cabinet is a library of routines for managing a database. The database is a simple data file containing records, each is a pair of a key and a value. Every key and value is serial bytes with variable length. Both binary data and character string can be used as a key and a value. Each key must be unique within a database. There is neither concept of data tables nor data types. Records are organized in hash table or B+ tree. Kyoto Cabinet runs very fast. For example, elapsed time to store one million records is 0.9 seconds for hash database, and 1.1 seconds for B+ tree database. Moreover, the size of database is very small. For example, overhead for a record is 16 bytes for hash database, and 4 bytes for B+ tree database. Furthermore, scalability of Kyoto Cabinet is great. The database size can be up to 8EB (9.22e18 bytes). -- 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/20120608114557.15671.11457.report...@plug.jengr.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
[Bjørn Mork] > I'd like to add another one: > > - a tmpfs is always easy to grow without requiring any special > preparations. Just add more swap. The swap could be on different > disks, and could even be files hosted on other file systems. This sound very similar to what I am doing already with LVM and online file system growing. A simple 'lvresize' and 'ext2resize' (or just debian-edu-fsautoresize for those of us with that tool available) later the full file systems have more free space again. :) Did I misunderstand you? > Any file system will run out of space given the broken applications > mentioned in this thread. tmpfs is the only one which will allow > all systems to dynamically add more space, only limited by the > available disks. That's why tmpfs should be the default for both new > and old systems, unless the administrator has explicitly made a more > limited choice. While I agree that tmpfs should be the default, I suspect this argument isn't solid enough to make it worth it. There are luckily other arguments too. :) -- Happy hacking Petter Reinholdtsen -- 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/2flobouko0q@login2.uio.no
Re: gnome is completely f^Mmessed up
Norbert Preining wrote: is this only me or do I have the feeling that we are going down the trench with Gnome? Repeatedly: - first login: nautilus segfaults in libnautilus-fileroller.so after log out and log in it sometimes works starting it manually most of the times work, but not always - ssh/gpg agent: most of the time just is completely useless either does not ask, or just segfaults in libglib-2.0 - plugging/unplugging power cord makes gnome-shell crash (known bug) - ... When I finally manage to get a running session, then out of nothing the blue whale appear, BSOD. Is this a joke? Are we going to release that in June/July/whenever? i use gnome too, and for me its working very stable, and gnome3 is way better than gnome2. -- Florian Reitmeir E-Mail: flor...@reitmeir.org Tel: +43 650 2661660 -- 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/4fd1ef6f.9050...@reitmeir.org
Re: gnome is completely f^Mmessed up
Florian Reitmeir writes: >> Is this a joke? Are we going to release that in June/July/whenever? > i use gnome too, and for me its working very stable, and gnome3 is way > better than gnome2. I installed wheezy to my old laptop a few months ago and was very happy with gnome too. Maybe the breakage is recent or there's something special in your installation. -- 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/844nqmf01b@sauna.l.org
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
2012/6/8 Petter Reinholdtsen wrote: > [Wouter Verhelst] >> - You could mount your mail spool there, and make things go blazingly >> fast [1] You could, but this is not related to /tmp. >> - There's no danger of a symlink attack or similar with things like >> tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the >> system, and /tmp is clean again, no matter what was there before. This >> is more than just a convenience. This works for many years. /tmp on disk is also cleaned on reboot. > - It allow diskless setups like LTSP to work the same way the default > installation in Debian work. They use read-only NFS-mounted file > systems and a writable tmpfs mounted on /tmp/. But `mount --bind /tmp /home/tmp` or /tmp->/var/tmp also allows read-only NFS root. And it's even better, because it gives you more free RAM, which is usually very important for LTSP stations. > - It reduces the number of disk writes on a laptop, allowing it to > spin down the disk a bit longer. It does not, because /tmp is mostly unused by default. On the contrary vm.laptop_mode=1 do it much better than tmpfs. :) > There are luckily other arguments too. :) I start thinking that "if you use /tmp on tmpfs you're doing something wrong" or rather "if you use /tmp on tmpfs you've missed a better option". :) -- Serge -- 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/CAOVenEpvyJG4q_qsehDutb+C1rYvM6SY1fKrsMbKiL9jiv=z...@mail.gmail.com
Bug#676658: ITP: chemfp -- Cheminformatics fingerprints file formats and tools
Package: wnpp Severity: wishlist Owner: Debichem Team * Package name: chemfp Version : 1.0 Upstream Author : Andrew Dalke * URL : http://code.google.com/p/chem-fingerprints/ * License : MIT Programming Lang: C/Python Description : Cheminformatics fingerprints file formats and tools Chem-fingerprints is a set of formats and related tools for the storage, exchange, and search of cheminformatics fingerprint data sets. . It translates fingerprints from the OpenBabel and RDKIT and cheminformatics packages (as well as the proprietary OEChem package) into the binary FPS format. . Besides python modules, it provides the following tools: . * sdf2fps - Extract fingerprint data from SD tags * ob2fps - Use OpenBabel to generate fingerprints from structures * rdkit2fps - Use RDKit to generate fingerprints from structures * oe2fps - Use OEChem/OEGraphSim to generate fingerprints from structures * simsearch - Do threshold or k-nearest neighbor Tanimoto similarity searches between two FPS files -- 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/20120608153943.ga22...@nighthawk.chemicalconnection.dyndns.org
Re: gnome is completely f^Mmessed up
Il 08/06/2012 09:15, Norbert Preining ha scritto: Hi everyone, is this only me or do I have the feeling that we are going down the trench with Gnome? Repeatedly: - first login: nautilus segfaults in libnautilus-fileroller.so after log out and log in it sometimes works starting it manually most of the times work, but not always - ssh/gpg agent: most of the time just is completely useless either does not ask, or just segfaults in libglib-2.0 - plugging/unplugging power cord makes gnome-shell crash (known bug) - ... When I finally manage to get a running session, then out of nothing the blue whale appear, BSOD. Is this a joke? Are we going to release that in June/July/whenever? Best wishes Norbert I'm having problems with gnome3 too but as I'm using sid I expect to have some. If they persist I'm going to fill bugs report, in the meanwhile I'm using awesome on my main machine, too (awesome is the window manager of choice for my netbook) I think you'd better to fill bug reports, without them anyone can fix problems they don't experience on their systems. Bye Stefano -- Stefano Canepa aka sc: s...@linux.it - http://www.stefanocanepa.it Three great virtues of a programmer: laziness, impatience and hubris. Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall) -- 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/4fd2236b.2050...@linux.it
Re: Processed: reassign 676001 to busybox
On 08.06.2012 15:28, maximilian attems wrote:
> On Fri, Jun 08, 2012 at 02:59:26PM +0400, Michael Tokarev wrote:
>> [Adding debian-devel@ to the Cc list]
>>
>> Short story (and it is short): the bug has been filed
>> against initramfs-tools initially, it is about how
>> /proc and /sys filesystem should be handled in initramfs
>> when switching to new root. Original reporter included
>> a trivial patch for initramfs that does re-mounting of
>> these filesystems. Max reassigned it to busybox without
>> giving any reasonings or comments whatsoever. I explained
>> that it is none of switch_root business, in
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676001#24 ,
>> and asked to not reassign bugs without giving a word of
>> explanation. After a few days of inactivity I reassigned
>> this bug back to initramfs, per my explanation. Now max
>> reassigned it back.
>
> no, no, you get the story wrong.
>
> The bug on initramfs-tools side is fixed^Wworked-around.
> I reassigned the *cloned* bug to busybox to have it properly
> fixed there.
Aha. This makes MUCH more sense now. Somehow I thought you
reassigned just the original bugreport to busybox.
> please get an ice cream and keep cool.
> No need to make a drama out of a simple single bug.
Without the above explanation ("cloned"), it looked to me
like completely wrong thing to do from your side, and
indeed, I become very upset seeing a reassign again without
explanations/comments (these were somehow received later,
after I already sent the "hot" email out). That's exactly
what I talked about on the initial reassignment -- lack of
any comments. Now when you explained and I actually looked
at the bug history and noticed the clone operation (#660297),
things become real again.
And no, I can't get an ice cream. I've a flu currently with
body temperature being 38.6°C, so I guess an ice cream may do
more harm than good.
And in this context, I can buy the argument about busybox not
implementing switch_root functionality from util-linux.
Thank you for explaining things, and I'm sorry for being
upset for nothing.
/mjt
--
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/4fd22cc7.6050...@msgid.tls.msk.ru
Bug#676666: ITP: libtest-xpath-perl -- test XML and HTML content and structure with XPath expressions
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libtest-xpath-perl Version : 0.16 Upstream Author : David E. Wheeler * URL : http://search.cpan.org/dist/Test-XPath/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : test XML and HTML content and structure with XPath expressions Test::XPath lets you use the power of XPath expressions to validate the structure of your XML and HTML documents. -- 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/20120608164658.24445.57544.report...@auryn.jones.dk
Bug#676667: ITP: fmcs -- Find Maximum Common Substructure
Package: wnpp Severity: wishlist Owner: Debichem Team * Package name: fmcs Version : 1.0 Upstream Author : Andrew Dalke * URL : https://bitbucket.org/dalke/fmcs/overview * License : BSD Programming Lang: Python Description : Find Maximum Common Substructure Fcms finds the maximum common substructure (MCS) of a group (or cluster) of chemical structures and report the result as a SMARTS string. . More specifically, the MCS found is a common edge subgraph, and not a common induced subgraph. Only connected MCSes are found. -- 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/20120608165125.ga30...@nighthawk.chemicalconnection.dyndns.org
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Petter Reinholdtsen writes: > [Bjørn Mork] >> I'd like to add another one: >> >> - a tmpfs is always easy to grow without requiring any special >> preparations. Just add more swap. The swap could be on different >> disks, and could even be files hosted on other file systems. > > This sound very similar to what I am doing already with LVM and online > file system growing. A simple 'lvresize' and 'ext2resize' (or just > debian-edu-fsautoresize for those of us with that tool available) > later the full file systems have more free space again. :) > > Did I misunderstand you? No, but those require LVM and available raw disk space. Swap can always be added without any such preparation. Bjørn -- 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/87d359qyxb@nemi.mork.no
debian-devel@lists.debian.org
Package: wnpp Severity: wishlist Owner: "Marco M. F. De Santis" * Package name: hoteldruid Version : 2.0.0 Upstream Author : Marco M. F. De Santis * URL : http://www.hoteldruid.com/ * License : AGPLv3 Programming Lang: PHP Description : web based property management system for hotels, hostels and b&bs HotelDruid is designed to manage hotel rooms, bed and breakfast apartments or any kind of daily rental. Reservations can be assigned to rooms automatically with user defined rules. Website pages to display and check availability can be created. Includes point of sale and statistics reports. Multi-user with groups and privileges system. Supports printing, saving and emailing of documents and invoices. By default uses Sqlite database as backend, with possibility to migrate to Mysql or Postgresql. -- 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/20120608214732.30221.79420.report...@digitaldruid.net
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: > Does this mean M-A:same packages should be prevented from being > binNMUed, but only source upload can be accepted? You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO at most important, not serious. Possibly we could allow one last sourceful upload when the transitions all settled, but it would again increase the review load on the release team. IMHO it's on the "if it works, fine, if not, sorry about that" part of the list, given that it was finalized so late, with that critical piece missing. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, Jun 9, 2012 at 6:17 AM, Philipp Kern wrote: > On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: >> Does this mean M-A:same packages should be prevented from being >> binNMUed, but only source upload can be accepted? > > You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO > at most important, not serious. Possibly we could allow one last sourceful > upload when the transitions all settled, but it would again increase the > review > load on the release team. > OK, I get your point, and I never meant not to binNMU is a reasonable idea. The reason for RC severity is just to prevent the version from migrating to testing before I've sorted out the M-A mess as much as possible on my side - for example #671902. Also, there is no important user-sensible changes (package maintainers and users) in this version, but mostly improvements to maintainability. > IMHO it's on the "if it works, fine, if not, sorry about that" part of the > list, given that it was finalized so late, with that critical piece missing. > Sure, I'll get the final version into archive before freeze, regardless whether there are remaining odd bits of M-A as long as they aren't affecting normal users. -- Regards, Aron Xu -- 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/CAMr=8w4f6buu_jvruta8d9d1m0tcnmkonub3qsh4f4v-mlv...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, 09 Jun 2012, Philipp Kern wrote: > On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: > > Does this mean M-A:same packages should be prevented from being > > binNMUed, but only source upload can be accepted? > > You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO Indeed, we cannot. But there has never been a need to, anyway. We'd just have to teach the tool to binNMU all arches when the target package would need it due to multiarch. Release team requests a binNMU of a package for some arch, the tool notices it has to do them all because of multi-arch constraints, and replicates the request for all other arches. This is even listed in Ubuntu's MultiarchSpec wiki package... -- "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/20120609003040.ga13...@khazad-dum.debian.net
Bug#676712: ITP: python-pyo -- Python module written in C to help digital signal processing script creation.
Package: wnpp Severity: wishlist Owner: Tiago Bortoletto Vaz * Package name: python-pyo Version : 0.6.1 Upstream Author : Olivier Bélanger * URL : http://code.google.com/p/pyo/ * License : GPLv3 Programming Lang: C, Python Description : Python module written in C to help digital signal processing script creation. pyo is a Python module containing classes for a wide variety of audio signal processing types. With pyo, user will be able to include signal processing chains directly in Python scripts or projects, and to manipulate them in real time through the interpreter. Tools in pyo module offer primitives, like mathematical operations on audio signal, basic signal processing (filters, delays, synthesis generators, etc.), but also complex algorithms to create sound granulation and others creative audio manipulations. . pyo supports OSC protocol (Open Sound Control), to ease communications between softwares, and MIDI protocol, for generating sound events and controlling process parameters. . pyo allows creation of sophisticated signal processing chains with all the benefits of a mature, and wildly used, general programming language. -- 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/20120609002846.31330.45010.reportbug@x61
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, Jun 9, 2012 at 8:30 AM, Henrique de Moraes Holschuh
wrote:
> On Sat, 09 Jun 2012, Philipp Kern wrote:
>> On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
>> > Does this mean M-A:same packages should be prevented from being
>> > binNMUed, but only source upload can be accepted?
>>
>> You cannot deprive the Release Team of this tool. Also multiarch bugs are
>> IMHO
>
> Indeed, we cannot. But there has never been a need to, anyway.
>
> We'd just have to teach the tool to binNMU all arches when the target
> package would need it due to multiarch. Release team requests a binNMU of a
> package for some arch, the tool notices it has to do them all because of
> multi-arch constraints, and replicates the request for all other arches.
>
> This is even listed in Ubuntu's MultiarchSpec wiki package...
>
>
Yes, but things are a little bit different here. I did request binNMUs
of all archs, but unfortunately buildds of every architecture
generates a unique changelog entry saying the NMU is done by "${arch}
architecture buildd admin", and you already know what would happen, :)
--
Regards,
Aron Xu
--
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/CAMr=8w6LoQHqjaBXb-V0z_-_4K=ZbE7MEVA8Yp9SZQ½rr...@mail.gmail.com
