BUG: Debian Jessie as KVM guest on GlusterFS backend
Hi, I'm having problems with installing D8 as KVM guest on GlusterFS storage backend. I run 4 different proxmox (debian based with RH kernel) nodes and got this problem on every of them. Versions: qemu-server: 3.4-6 pve-qemu-kvm: 2.2-10 glusterfs-client: 3.6.4-1 No matter what I do, I'm not even able to complete the installation process, it stops on random step: 1. on mirror select (just suddenly says, that mirror is not accessible or there is no right version of Debian located) 2. on package installation step (just says that it is not able to solve deps as some pkg was not configured, usually it is python-gtk2 or smt like that). Once I was lucky enough to install the base system, but ended up with unstable system: apache did't run due to missing modules, while they were at their places, seemed to me like corrupted. Also it seems to me, that files are getting corrupted while installed on glusterfs storage backend. I can install D8 on local storage without problems. There are no error logs on glusterfs side. Debian 7 installs and runs fine. Ubuntu 14.04 LTS installs and runs fine. Centos 6 installs an runs fine. Any ideas? This has to be solved somehow. I'm also in contact with GlusterFS users list and wrote to devel list, but was not able to solve it. I used glusterfs 3.5.4 before, was the same problem. Where should I report this issue to get it solved? -- Best regards, Roman.
Re: BUG: Debian Jessie as KVM guest on GlusterFS backend
anyone? 2015-07-14 13:37 GMT+03:00 Roman : > here is one of the errors example. its like files that debian installer > copies to the virtual disk that is located on glusterfs storage are getting > corrupted. > > 2015-07-14 12:16 GMT+03:00 Roman : > >> Hi, >> >> I'm having problems with installing D8 as KVM guest on GlusterFS storage >> backend. >> I run 4 different proxmox (debian based with RH kernel) nodes and got >> this problem on every of them. >> >> Versions: >> >> qemu-server: 3.4-6 >> pve-qemu-kvm: 2.2-10 >> glusterfs-client: 3.6.4-1 >> >> No matter what I do, I'm not even able to complete the installation >> process, it stops on random step: >> >> 1. on mirror select (just suddenly says, that mirror is not accessible or >> there is no right version of Debian located) >> 2. on package installation step (just says that it is not able to solve >> deps as some pkg was not configured, usually it is python-gtk2 or smt like >> that). >> >> Once I was lucky enough to install the base system, but ended up with >> unstable system: apache did't run due to missing modules, while they were >> at their places, seemed to me like corrupted. Also it seems to me, that >> files are getting corrupted while installed on glusterfs storage backend. >> >> I can install D8 on local storage without problems. >> >> There are no error logs on glusterfs side. >> >> Debian 7 installs and runs fine. Ubuntu 14.04 LTS installs and runs fine. >> Centos 6 installs an runs fine. >> >> Any ideas? This has to be solved somehow. I'm also in contact with >> GlusterFS users list and wrote to devel list, but was not able to solve it. >> >> I used glusterfs 3.5.4 before, was the same problem. >> >> Where should I report this issue to get it solved? >> >> -- >> Best regards, >> Roman. >> > > > > -- > Best regards, > Roman. > -- Best regards, Roman.
missing sent packets of via-rhine
hi! i'v got some troubles with the via-rhine driver resp. the via nic and hope someone can give me some hint. the problem:i'm sending some ethernet frames from kernel to the nic (with dev_queue_xmit). everything seems to be ok, /proc/net/dev lists all packets sent, but the target nic did not receive all frames. to exclude failures on the receiving station, i used different receiving stations with different nics. allways the same - missing frames. sending frames out of user mode leads to no loss, sending frames out of kernel mode with some timegap between two dev_queue_xmit calls leads to no loss. just "fast" sending of frames leads to this loss. i compiled the via-rhine driver with highest debug-level to check the problem in detail.here is the debug output of sending 10 frames, where just 6 frames were received at the destination station: eth0: VIA Rhine monitor tick, status .eth0: Transmit frame #39 queued in slot 7.eth0: Transmit frame #40 queued in slot 8.eth0: Interrupt, status 0002. Tx scavenge 7 status .collisions: 0:0 Tx scavenge 8 status .collisions: 0:0eth0: exiting interrupt, status=.eth0: Transmit frame #41 queued in slot 9.eth0: Transmit frame #42 queued in slot 10.eth0: Transmit frame #43 queued in slot 11.eth0: Transmit frame #44 queued in slot 12.eth0: Interrupt, status 0002. Tx scavenge 9 status .collisions: 0:0 Tx scavenge 10 status .collisions: 0:0 Tx scavenge 11 status 8000.eth0: Interrupt, status 0002. Tx scavenge 11 status 8000.eth0: Interrupt, status 0002. Tx scavenge 11 status .collisions: 0:0 Tx scavenge 12 status 8000.eth0: exiting interrupt, status=.eth0: Interrupt, status 0002. Tx scavenge 12 status .collisions: 0:0eth0: exiting interrupt, status=.eth0: Transmit frame #45 queued in slot 13.eth0: Transmit frame #46 queued in slot 14.eth0: Transmit frame #47 queued in slot 15.eth0: Transmit frame #48 queued in slot 0.eth0: Interrupt, status 0002. Tx scavenge 13 status .collisions: 0:0 Tx scavenge 14 status .collisions: 0:0 Tx scavenge 15 status 8000.eth0: exiting interrupt, status=.eth0: Interrupt, status 0002. Tx scavenge 15 status .collisions: 0:0 Tx scavenge 0 status .collisions: 0:0eth0: exiting interrupt, status=.eth0: VIA Rhine monitor tick, status . so as far as i can estimate this output (i do not have technical documentation of the nic) everything looks right.the status of all 10 frames was set to 0. i guess this means "frame sent"just frame 5 (frame 43 at slot 11 in the debug output) is a little bit confusing me. there is an interrupt with status 0002 (TxDone) and the next frame in the ring buffer still has the status DescOwn. ???but it seams not serious to me. does anyone got an idea why i'm losing frames? a bug in the driver, or bug of the nic? thank you and best regards, roman
Re: libc6 policy in unstable
> That's why we have the altgcc and the altdev packages. You'll still > be able to compile libc5 programs by just putting > /usr/i486-linuxlibc1/bin first in your path. Just a note to one thing where this doesn't work: Some programs use -I/usr/include/bsd on the command line to get BSD behaviour for certain stuff, e.g. signal handling. But that directory doesn't exist anymore if libc6-dev is installed. This is no problem with libc6 itself, since BSD signals are default there, but SysV semantics are default for libc5. If you now compile such a program with i486-linuxlibc1-gcc, no headers in /usr/include/bsd are found (they're in /usr/i486-linuxlibc1/include/bsd ...) and you get the wrong signal semantics. Just a note, but already happened ... :-) Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#10516: gs-aladdin: Depends on svgalib1 (>= 1.210-1) which does not allow svgalib-dummy to fulfill the dependency
I've missed the start of this discussion, but I'm the maintainer of svgalib-dummy, and the issue of dependencies came up already several times... > Are there other people that would like the dependancy change > > - Depends: svgalib1 (>= 1:1.2.10-2) > + Depends: svgalib1 (>= 1:1.2.10-2)|svgadummy This would indeed be a fix for the dependency stuff, but only for the package that adds this |svgadummy. To fix the svgalib/svgalib-dummy problems with way, every depending packages would have to be changed similarily. svgalib-dummy indeed has a "Provides: svgalib", but unfortunately this doesn't have any effect... Since svgalib is a shared lib, all packages depending on it depend on >= some version. And such versioned dependencies can't be fulfilled by a Provides: :-(( This is not only a problem for svgalib-dummy (which can't really be used as a proper substitute for svgalib due to this), but it has also other implications: We'll never be able to replace or rename a shared library package! Currently, packages that are to replace an older one (renaming is a special case of this) have fields Replaces: and Provides:. But this works only as long as no other package has a *versioned* dependency on the package to be replaced. I see this as a kind of shortcoming of the dependency checking: It should be allowed to have versioned Provides: fields also (e.g.: "Provides: svgalib1 (1:1.2.10-2)". With that, you also give the version of the other package whose functionality is provided, and some dependency (e.g. "Depends: svgalib1 (>= 1:1.2.10-1)") can be fulfilled. I don't know how difficult this would be to implement in dpkg, but it would be a win not only for svgalib-dummy, but also for the future, in case we'll need to replace a shlib package sometimes... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Orphaning dftp.
> I'd like to officially offer dftp up for adoption. I don't use it > anymore -- dselect works much better for me now that I came to terms > with it -- and so I don't really have much interest in maintaining > dftp anymore (that and the fact that I have a bunch of other things > I'm supposed to be doing). I'd volunteer for maintaining dftp, at least for a while, if nobody else does. I also have a lot of things to do and not too much time left, but I need dftp for my two machines at home, and there are some things in dftp that really should be done (re-add the .installed file, at least some kind of dependency checking). Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
svgalib-dummy again
Now that svgalib seems orphaned, allow me to come up with this topic again... But first a brief summary of the history and the problems: svgalib-dummy is a dummy replacement for svgalib, which doesn't require any configuration, doesn't spit out messages when initialized by applications, and last but not least, can be used as a substitute on architectures where the real svgalib doesn't exist. Unfortunately, it cannot be easily installed. Though it Conflicts: and Replaces: svgalib1, dpkg's current dependency mechanism doesn't allow it to be a substitute for svgalib, because that is a shared lib and so all dependencies on it are versioned dependencies (coming from the .shlibs file). I now see two solution for this problem: 1) dpkg's dependency handling could be extended so that it knows about versioned Provides:. Then svgalib-dummy could provide "svgalib1 (>= 1:1.2.10-2)" or something similar, and a dependency "svgalib1 (>= 1:1.2.10-1") could be satisfied by this. Not only that this is the most elegant way, it also solves another potential problem: The problem with versioned dependencies doesn't only hit svgalib-dummy, which wants to replace a shared lib, it will also effectively make replacements of any shlib package impossible... Just imagine we sometime want to rename a shared lib, or replace it by another, improved package. This won't be possible without rebuilding the *depending* packages, because providing a shared lib isn't possible... 2) A not-so-nice solution would be to change the .shlibs files of both, svgalib and svgalib-dummy, so that they read libvga1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1 libvgagl 1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1 This signals that either package is ok for providing libvga.so. The drawback is that all packages depending on svgalib must be rebuilt with an updated version of svgalib to get in this change. This could be handled by first announcing here that those packages should be rebuilt, and if no uploads follow in some reasonable amout of time, I could report bugs against those packages. So, what method do you prefer? Or do you have better ideas? How hard would it be to implement versioned Provides: in dpkg? Or are there other reasons not to implement it? Is solution 2) too kludgy? Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GCC cross-compilation
> Does this mean I could upload all architecture version for my > packages? If so yes, I think it's useful. But if you do that, you haven't tested whether your package is really running on another architecture... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> > dpkg's current dependency mechanism doesn't allow it to be a > > substitute for svgalib, because that is a shared lib and so all > > dependencies on it are versioned dependencies (coming from the .shlibs > > file). > > Well, more to the point: when package foo "Depends" on a particular version > of package bar, dpkg ignores all packages that provides: bar. > (It'll only look at the exact package bar, and it's version). Clear. What I meant with "because it's a shared lib" is that usually all dependencies on a shlib are versioned dependencies, because they come from the .shlibs file. > Well, it isn't the library stuff that goes wrong, it's the specific > versions that cause dpkg to ignore the Provides: packages. That's what I'm saying, isn't it? > Only if the *dpending* packages depends: on a particular version of > the shared lib package. Usually, this isn't the case (the soname of > the library is encoded in the package name, so a package could just > depends: "libfoo272", with 272 the soname of libfoo. But yes, with > the current shlibs files, they will always depend on a particular > version of the library, and it will always go wrong. Yup, that's it. AFAICR, the (>= x.y.z) there has been introduced to avoid that people use too-old shlibs at runtime, which is basically a good thing. > Well, this at least woudn't hurt, I guess. Unless anyone objects > against this, I'll add this to the svgalib1g I'll upload > tonight/tomorrow. That would be fine! Would at least fix the problem for packages that are recompiled with the new glibc version of svgalib. > They have to be rebuilt for libc6 anyway. So that's no problem. You're right here. > I strongly prefer method 1. I really think dpkg should be improved, Me too... > but as that doesn't seem to happen any time soon, I don't think > method 2 will hurt in the mean time. Ok. Any other opinions? Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> Better method: Remove the version from svgalib1g shlibs (as the > other libc6 libraries have done). The version would be needed again > if a new upstream release of svgalib with an incompatible library > arrives, as this seems far from happening this would be a perfect > solution for svgalib, IMO. Yup, removing the version solves all problems :-) Why haven't we had that idea earlier?? Nicolas, you're a genius :-) Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> If my server is gonna be a "build server", I'd *very* much prefer a > modified dpkg-dev that allows for non-root package builds. > > (in fakt so much, that I may be tempted to write it myself. You > don't need that many changes). AFAICS, the only thing needed to be done as root is the install/chown stuff, right? I see two possibilities for this: Either put in the file owner information into the tar archive directly afterwards (this can be done as a post-processing to the proper tar, and is rather easy [1]), or provide special suid versions of install/chown/... (as needed) just for the install process. These special binaries should be available only for debian/rules, and can check the paths of the files given so that debian/rules can't change owners of arbitrary files, only those under some debian/tmp dir. Ok, I see there are possibly many holes in this scheme... :-( But for the first possibility the problem is how to pass the owner information to the entity the modifies the tar archive... Roman [1]: For some other application, I've once written such a tar-post-processor that changes certain path patterns in the tar archive. It was really easy, the tar format is simple enough... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GCC cross-compilation
> Well, I personally distrust cross-compilers...at least gcc cross > compilers. I know that at least one crossover (i386->alpha) has been > known to produce broken binaries at one time, In that case, 32/64 bit stuff has been the cause... > Since you can't actually test the cross-compiled programs you > generated, you never know when you might be uploading something > _really_ broken into stable. > > Cross compilers are very good for bootstrapping new linux ports and > things like that, but I wouldn't want to upload "production > binaries" built by a cross-compiler, and would be _very_ upset to > find that I was using one. I use cross-compiling most of the time for m68k, just because the Intel machines are much faster... But I test the resulting packages on the 68k machine :-) In that case, I think there's nothing to say against cross-compiling... BTW, what really doesn't work with cross-compiling is floating point, due to deficiencies in gcc. But you can avoid problems if you use the standard installed with a cross-gcc. That one just contains an #error, so you'll be notified at compile time. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> Has anyone considered writing a svgalib replacement that simply > translates svgalib calls into X Windows calls? This would allow > those of us with cards that are unsupported under svgalib to still > use svgalib programs, though admittedly at a speed penalty. I haven't yet thought of that :-), but basically it should be possible. Just not that "simple"... I guess it's a bunch of work... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dhcpcd compile problem with libc6
> In file included from /usr/include/linux/if.h:23, > from /usr/include/linux/netdevice.h:30, > from if.c:28: > /usr/include/linux/socket.h:9: redefinition of `struct sockaddr' Seems if.c includes , which in turn goes to . With glibc you should generally prefer the headers in sys to those in linux (the linux header is included by the sys header if needed). Maybe it helps to explicitly include before netdevice.h (since there is no ). If this doesn't help, I'd say it's some inconsistency between glibc headers and Linux headers, which should be reported to the glibc maintainers. (It should be possible to include a header if there's no corresponding header.) A temporary fix could be to avoid reading with #define _LINUX_SOCKET_H. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> if you create files and directories as root, you also need to be > root, to delete them. but this is far easier, of course. You shouldn't be root, so you don't create files/dirs as root... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> I think inode->name mappings will be better than fd-> name mappings: > - we have a chance of solving the pathalogical case below > - fd->name mappings are no good, have to be (pid,fd)-> name mappings, > complicates matters: Hmm... I admit you're right here. BTW, why not generally work on (device,inode) pairs instead of filenames? The data structures would be easier to maintain inside the daemon (just numbers, no strings), we wouldn't have to watch for symlinks, and of course hard links are obviously solved. We'd also save wrapping open/close, since inside the fchown()/fchmod() wrappers you can call stat to get the inode numbers, you don't need the name anymore! Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> This will execute /bin/bash[1], and set environmen varable > "LD_PRELOAD" to a libfakeroot.so.0.0. This libfakeroot currently > overloads only chown and lstat[2]. Now, when you type in the thus > executed shell: > > $ chown root:users somefile > > this will call the wrapper "chown" function. this wrapper calls the > real chown, _and_ it sends (via SYSV IPC calls) a message to the > (still running) fakeroot "daemon". This daemon records the new fake > onerships of the file in an internal variable. Looks fine so far! BTW, I guess the daemon is also started by 'fakeroot', right? > - yes fstat and fchown will be somewhat of a problem, but I'll just > have to overlod open() etc too, and keep a list of inodes/filenames. Hmm... to be more exactly: You have to wrap open(), create(), and close(), and have to keep a table of fd -> name mappings for fchown() and fchmod(). > - I probably will go wrong for pathalogical cases like > >ln file1 file2 >chown mail:sys file2 >rm file2 >ls -al file2 > > I doubt whether these are important, and even if they are, I > guess it will be possible to get it right. Ok, it's a really pathological case, maybe we can delay a solution until we need it. I think the way to handle it would be to wrap link() and unlink() calls, too... But that could become a bit more complicated :-( > [2] Well, I've olverloaded lstat all right, but it doesn't seem to > get called don't know why yet. Why would chown() work and lstat() > not? Better also wrap stat() and fstat(), too. Maybe that's the reason. Another possibility is that the shell uses some other library function that indirectly does the stat, and that function uses _lstat or _stat instead of lstat/stat. Then you'd have to wrap those '_' versions, too. A real drawback of this: You then can't call the real functions anymore :-((, you have to write your own versions using the macros from , which isn't very clean anymore. Maybe use gdb on the shell to learn what's going on. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
Re: Why does gcc no longer link .sos with -lc by default?
> The difference seems to be that the gcc on the alpha is linking in
> -lgcc -lc -lgcc, where gcc on the i386 is just doing -lgcc twice.
>
> So which is right, and if it's the i386, since moving to gcc-2.7.2.3
> isn't an option for the alphw, does anyone know enough about specs
> files to be able to suggest what should be done about the alpha
> setup?
The difference is just in the specs, I guess. In the i386 version,
there's something like
%{!shared: ... %{profile:-lc_p} %{!profile: -lc}}
I.e., libc is only linked if -shared is not given. Basically the same
thing is done for m68k and sparc. So I guess that is what is intended.
Don't know why the -lc isn't ommited on the alpha.
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
New required base packages for Amiga, Atari, ... detection
There are now some packages for m68k that make sense only on a specific machine type. Currently we have such packages only for Atari, but others can follow easily. The packages are nvram and setsccserial, and atari-fdisk is about to be debianized. Those packages are currently Architecture: m68k, but this alone isn't sufficient, because it still allows their installation on e.g. an Amiga, where they don't make sense at all. Currently the preinst script of such packages makes some tests that the machine really is an Atari (via /proc files), but this isn't the cleanest solution. It would be much better if already dependencies could forbid installation on non-Atari machines (or whatever...). James Troup had a fine idea for this: We could introduce new required and essential packages in the base section, like base-atari, base-amiga, base-mac, and so on. (Those packages won't have any files in them for now, but maybe we have something to include in them in future.) Machine-specific packages then can depend on those base- packages. The appropriate base- package will be included in the base.tgz of the install disk set for the machine, so it will be installed automatically for new installations. For existing installations, the user has to choose the right one... (We could move the /proc based tests to their preinst, to do it only once.) Of course, the packages should be Architecture: m68k, they're useless for other architectures (that don't need distinction between Atari, Amiga, Mac, ...) All the base- packages should conflict with each other, so that only one can be installed. The best way to ensure this would be to create a new virtual package 'base-machine', that all base- packages provide and conflict with. Since policy says that introduction of essential packages and new virtual packages requires discussion on debian-devel, I now ask here if there are any objections to the above. Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New required base packages for Amiga, Atari, ... detection
> This sounds exactly the same as the i386 vs Pentium thing. It's the
> name BASE architecture but different... implementations?
Yep, sounds similar. I haven't closely followed followed the Pentium
discussion (too much traffic here...), but it's obvious that there are
some parallels.
> One solution could be creating more distributions, like binary-i586,
> binary-atari, binary-amiga, and simlink shared files from, e.g.,
> binary-i586 back to binary-i386. This complicates things a bit,
> since a i386 package has to get an entry on i586, just like an all
> package gets and entry on all the architectures, but only if a i586
> specific package isn't already there. I think it would be the same
> with the m68k stuff. The alphas won't be as easy, I think.
This is possible, but sounds a like bit too much trouble for my
problem. There are currently only two packages for m68k that need this
special treatment. Ok, the number will grow, but it never will be that
much that separate binary-{atari,amiga,..} trees really make sense.
They would consist of > 99% symlinks.
> For the "not really arch-all" part... could overrides be
> used/extended for this? Like in "the package says it's arch-all but
> it's really just arch-i386 and arch-sparc"
I think this is an extension, but don't know exactly. Guy, you know
your scripts better than me... :-) But if it wouldn't be too much
trouble to implement it, it would be worthwile.
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: New required base packages for Amiga, Atari, ... detection
> Is this any different from Intel packages that only make sense when > you have specific hardware installed? We have several of those. It's not just that you have different hardware installed, but you have a totally different kind of computer... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New required base packages for Amiga, Atari, ... detection
> As in, ISA vs. MCA vs. PCI? :-) No, as in e.g. Intel-PC vs. Sun :-) Ok, you're right that we could leave the user on his own and tell him "just don't install packages you can't make any use of", but I think we can do it better... Aren't dependencies exactly for that purpose? I.e., keep the user installing e.g. a libc6 package without having libc6? Sorry for the bit of sarcasm :-) Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dinstall and PGP
> Can someone hack dinstall to install packages which are not PGP > signed but has been copied to incoming? If the UID of the files is > the one of a developer we can know who did upload the package. No, because the upload queues also use known UIDs, but may allow everyone to upload. (BTW, the queues in Erlangen and open.hands.com require the files to be PGP-signed.) Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I'm away for a week
I'm on vacation from tomorrow till 04/20, so if something serious should be with my packages, feel free to make non-maintainer uploads. Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libfdisk problem in dinstall
> I was receiving the message "error reading sector 0" all the time, > but cfdisk handled the partitioning just fine, so I expect this is a > problem in libfdisk or dinstall somewhere. That's really strange, since the message is about a real read error. Is something special about the disk or the location of that swap partition? Can you send me the partition layout (fdisk -l)? Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: signals and atomicity
> if you implement "interruptible" system calls this way: 1. UNBLOCK
> SIGNAL 2. SYSTEM CALL 3. BLOCK SIGNAL it may happen that the signal
> handler is called just after unblocking the signal but before the
> call. this way no EINTR happens, the signal is lost and (2) is stuck
> in the system call.
>
> because of this, i have to do a siglongjmp() in the signal handler.
> now it isn't anymore possible that signals get lost. BUT ! i do not
> know the return value of the system call, if it was interrupted.
> remember, after the call , the signal is blocked again. now, if the
> call succeeded, but still before the BLOCK SIGNAL command, if now
> again a signal is received, siglongjmp jumps away, and the fact,
> that the system call succeeded is just lost.
You can solve it this way (at least I hope... :-) :
static int timeout;
static void alarm_handler(int sig) {
timeout = 1;
}
int wait_or_timeout (int *status) {
struct sigaction act;
int wait_retval;
timeout = 0;
sigaction(SIGALRM, 0, &act);
act.sa_handler = alarm_handler;
act.sa_flags &= ~SA_RESTART;
sigaction(SIGALRM, &act, 0);
alarm(1);
wait_retval = wait(status);
alarm(0);
/* ... */
}
If 'timeout' is set at the end, SIGALRM was delivered before the
alarm(0). On the other hand, wait_retval is -EINTR if and only if the
system call itself has been interrupted. So you can distinguish
between the cases "system call interrupted" and "signal arrived, but
somewhere around the syscall".
Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sedna - a native XML DBMS
Hello! I'm a member of MODIS research group at the Institute for System Programming of the Russian Academy of Sciences (http://www.ispras.ru/) We are developing a native XML DBMS Sedna. You can find more information about Sedna here: http://modis.ispras.ru/Development/sedna.htm Linux source is available here: http://modis.ispras.ru/FTPContent/sedna-0.5.9-src-linux.tar.gz I am wondering whether it's possible to include Sedna in Debian distribution. Also I would appreciate any help on building Sedna packages for Debian. Current version of packages is available here: http://modis.ispras.ru/FTPContent/tmp/sedna-deb/ -- Best regards, Roman mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#46388: NO 2.1r3 M68K CDs: trn depends
> trn: > Depends: libc6, libncurses4 (>= 4.2-3.1), inews [...] > 68k - I think this is a bug in your build daemon - it's built a > slink package against the potato libraries. Can any of you give me > access to a slink machine to fix this? cd - as requested. It's not (strictly speaking) a bug in buildd, but the package simply has been built on the wrong machine... (probably by rbuilder). However, I've already heard of this problem and have immediately rebuilt trn (3.6-9.3.2). This version depends on "libc6, libncurses4, inews", i.e. no versioned libncurses dependency. It's installed in proposed-updates. If you want to make the m68k CDs from stable only, please nudge the FTP admins to install the package now. Roman
Re: Re: defaulting to net.ipv6.bindv6only=1 for squeeze
> Done, let's see what breaks. :-) vnc4server: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560137 Marco, by making this change I assume you offer your personal help in dealing with its consequences? Please feel free to submit a fix to #560137, thanks in advance. -- With respect, Roman signature.asc Description: PGP signature
dpkg-genchanges: warning: package XYZ in control file but not in files list
Hi there ... I've got a little problem ;) In my debian package there usualy are 4 debs (3 flavours + common) been built. I've created the rules to be to choose between a minimum of 2 (standard-flavour + common) and the maximum of 4 packages. If a user wants to compile the package on his own (maybe he wants to change configure options) he is able to select the flavours he wants and he has not to build all 4 packages if he only needs 2 (time saving). Problem is now, if not all 4 packages are built, I do get a warning like: dpkg-genchanges: warning: package XYZ in control file but not in files list This is ok, cause all 4 packages are in control but only 2 or 3 are built. What should I do? Let a warning only be a warning? Dynamically change control? How that? Not make it possible to compile less packages than control mentions? Lg Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-genchanges: warning: package XYZ in control file but not in files list
Am Donnerstag, 8. März 2007 schrieb Roman Müllenschläder: > Hi there ... > > I've got a little problem ;) Sorry .. will never user reply for a new message anymore ;) Lg Roman
May one use ~rc1 within versions although older lintians are complaining?
Hi there ... I'm packaging for debian right now and wanted to now if I may use a version number like: 1.0.8~rc1-1 ? Reason is the following: I have this packages on my repository for making it available to users for testing puposes. I know that the initial release should be 1.0.8-1. So if I do updates on the package now, I can't increment the version (which is now 1.0.8-1). So my wish would be to use 1.0.8~rc1-1/2/3... until initial release which will be 1.0.8-1 then. My version of lintian is 1.23.22 and it gives error if I use this version number and I'm fearing these error prevent the package from beeing sponsored !? Lg Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Dienstag, 13. März 2007 schrieb Margarita Manterola: > On 3/13/07, Roman Müllenschläder <[EMAIL PROTECTED]> wrote: > > I'm packaging for debian right now and wanted to now if I may use a > > version number like: 1.0.8~rc1-1 ? > > If you use that number, the upstream version should be 1.0.8~rc1. Is > that the upstream number? If you want to have release candidates of > your _own_ package, you should do: 1.0.8-1~rc1 So the versions will be 1.0.8-1~rc1(2,3,4) ? > > My version of lintian is 1.23.22 and it gives error if I use this version > > number and I'm fearing these error prevent the package from beeing > > sponsored !? > > What's the error given by lintian? It gives: bad-version-number and bad-version-in-relation depends: > The versions for lintian (from packages.qa.debian.org) are: > > Stable: 1.23.8 > Testing:1.23.28 > Unstable: 1.23.28 > > So, why are you using a version that's not the one in testing, nor the > one in stable? Because my laptop, where I'm building the packages on, is running Edgy ;) Maybe I should compile lintian by hand ... tried using sources from feisty but they need to much dependencies ... LG Roman
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Dienstag, 13. März 2007 schrieb Peter Samuelson: > [Roman Müllenschläder] > > > > So, why are you using a version that's not the one in testing, nor the > > > one in stable? > > > > Because my laptop, where I'm building the packages on, is running Edgy ;) > > I know I'm stating the obvious here ... but you shouldn't try to > develop packages for Debian exclusively on Ubuntu systems. You won't > be able to test your packages. Not being able to test your packages is > generally considered a Bad Thing. (Or you at least tell your sponsor > "this package has not been tested on Debian", right?) Why is every question I'm asking here treated like me beeing a child in time, not able to do the logical? Testing a package is useless and senseless ... I know that well! SCNR Lg Roman
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Dienstag, 13. März 2007 schrieb Margarita Manterola: > On 3/13/07, sean finney <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-03-13 at 20:23 +0100, Roman Müllenschläder wrote: > > > > If you use that number, the upstream version should be 1.0.8~rc1. Is > > > > that the upstream number? If you want to have release candidates of > > > > your _own_ package, you should do: 1.0.8-1~rc1 > > > > > > So the versions will be 1.0.8-1~rc1(2,3,4) ? > > Yes. > > > i would disagree and suggest your original versioning scheme with > > 1.0.8~rc1-1. or, if upstream isn't using that particular naming scheme, > > you might want to make it clearer with > > 1.0.8~somethingthatidentifiesyou1-1 or something similar. > > > > my rationale is that if you do 1.0.8-1~rc1, you're in effect saying that > > it *is* upstream version 1.0.8, (and a debian revision << -1). but if > > you do 1.0.8~foo-1, you're saying that it's << upstream version 1.0.8. > > My suggestion was only for the case when the upstream version _IS_ > 1.0.8, and the maintainer is relasing "release candidates" of the > Debian package, not of the upstream version. That's the case! > If the release candidates are of the 1.0.8 version itself, then the > original tarball should be called foo_1.0.8~rc1.orig.tar.gz, and > lintian shouldn't complain. Now that well! The problem is that the mentioned lintian warning was fixed in .27 .. so if testing and unstable are using .28, there should be no problem with just ignoring the warnings for now and see what my _tests_ on debian will announce! Thx Roman
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Dienstag, 13. März 2007 schrieb The Fungi: > On Tue, Mar 13, 2007 at 08:23:16PM +0100, Roman Müllenschläder wrote: > [...] > > > Because my laptop, where I'm building the packages on, is running > > Edgy ;) > > [...] > > If you're developing packages for Debian, not Ubuntu, I would > suggest at a minimum that you do your builds in a Sid chroot > (pbuilder and/or UML work well for this too, depending on how > powerful your system is). I do packaging solely for Debian and yet I > *still* use a chroot to build, and usually a virtual server when > testing out the results. Second time in this thread I have to tell that I'm not baking my packages in an oven and pray they will run on debian ... This was not my question! I had a straight question and did already get the answer. Thx anyway ... Xcuse for beeing that rude, but it's the 5th mail I send to debian lists and always got arrogant answers. Is this a way for DD's to show they are different, better or what? For nearly 5 years I work with opensource and love debian! But my efforts since the last 3 month of making debian packages showed up a complete different side ... sadly! Giving me an impression of elitist. How comes? Lg Roman Btw. pls stop cc'ing me! I'm subscribed and hate deleting neddless mails!
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Mittwoch, 14. März 2007 schrieb Rene Engelhard: > Hi, > > Roman Müllenschläder wrote: > > The problem is that the mentioned lintian warning was fixed in .27 .. so > > if testing and unstable are using .28, there should be no problem with > > just ignoring the warnings for now and see what my _tests_ on debian will > > No, that's wrong. *Build* also on Debian (in a sid chrot). Then you don't > get the warning in the first place and there's nothing to ignore at all. > > > announce! > > You claim to test it on Debian but doesn't even run the lintian from > Debian? > So easiest way to use chroot (I'm using pbuilder) with linda/lintian is to make a hookdir, copy over B90linda from examples to the hookdir and run: pbuilder-sid build package.dsc --hookdir ./hookdir ? Or are there easier ways of using linda/lintian with pbuilder? Lg Roman
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Mittwoch, 14. März 2007 schrieb Gunnar Wolf: > Please set up the headers accordingly in your mail client :) What's wrong with my headers? Lg Roman
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Mittwoch, 14. März 2007 schrieb Gunnar Wolf: > Roman Müllenschläder dijo [Tue, Mar 13, 2007 at 08:43:56PM +0100]: > > > > > So, why are you using a version that's not the one in testing, nor > > > > > the one in stable? > > > > > > > > Because my laptop, where I'm building the packages on, is running > > > > Edgy ;) > > > > > > I know I'm stating the obvious here ... but you shouldn't try to > > > develop packages for Debian exclusively on Ubuntu systems. You won't > > > be able to test your packages. Not being able to test your packages is > > > generally considered a Bad Thing. (Or you at least tell your sponsor > > > "this package has not been tested on Debian", right?) > > > > Why is every question I'm asking here treated like me beeing a child in > > time, not able to do the logical? > > > > Testing a package is useless and senseless ... I know that well! > > HUH!?!? > > Ummmh... If that's how you really feel and I'm not failing to > understand some deep sarcastic remark, I invite you to keep those > packages away from Debian. > Isn't it ironic ;) Lg Roman And PLS! STOP CC'ing me!!
Re: May one use ~rc1 within versions although older lintians are complaining? (Closed)
Am Dienstag, 13. März 2007 schrieb Roman Müllenschläder: > Hi there ... > > I'm packaging for debian right now and wanted to now if I may use a version > number like: 1.0.8~rc1-1 ? > > Reason is the following: I have this packages on my repository for making > it available to users for testing puposes. I know that the initial release > should be 1.0.8-1. So if I do updates on the package now, I can't increment > the version (which is now 1.0.8-1). > > So my wish would be to use 1.0.8~rc1-1/2/3... until initial release which > will be 1.0.8-1 then. > > My version of lintian is 1.23.22 and it gives error if I use this version > number and I'm fearing these error prevent the package from beeing > sponsored !? > > Lg > Roman Ok ... thx for your answers to this! Beside building and testing my packages in a proper way (pbuilder and clean installations in vmware - because of my packgage beeing a graphical one, I decided to use a graphical system for testing, not chroot) I just mis-used lintian ;( So my question came up cause of this unproper usage, was my fault and is therfore answered. Lg Roman
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Mittwoch, 21. März 2007 schrieb Manoj Srivastava: > On Tue, 13 Mar 2007 15:56:44 -0300, Margarita Manterola <[EMAIL PROTECTED]> said: > > On 3/13/07, Roman Müllenschläder <[EMAIL PROTECTED]> wrote: > >> I'm packaging for debian right now and wanted to now if I may use a > >> version number like: 1.0.8~rc1-1 ? > > > > If you use that number, the upstream version should be 1.0.8~rc1. > > Is that the upstream number? If you want to have release candidates > > of your _own_ package, you should do: 1.0.8-1~rc1 > > Hmm? Suppose upstream version is currently 1.07 released, and > they are planning on releasing 1.08 in the future. Now they are > running through 1.08 release candidates, and so we have 1.08 rc1, > soon to be followed by 1.08 rc2. The upstream version variables, > used by them, are all at 1.08 (not 1.08 '~'. > > How do you propose the debian releases of the release > candidates be numbered? When upstream releases, upstream releases > shall have 1.08, 1.08.1 or 1.08-1, and so on. The upstream currently released is 1.0.8.2. Coming is 1.0.8.3 followed by 1.0.9, if there isn't a 1.0.8.4 ;) The devel-branch therefore is 1.0.9. So I'm only doing packages of _released_ upstreams, not of a devel-branch. As long as the upstream is not fullfilling the needs to be sponsored and uploaded, I do test-debs and provide them on my own repository, to let users use them for testing purposes. Therefore the upstream stays the same (1.0.8.2 - as long as 1.0.8.3 is not released) but the debs change to get them "perfect". Thus having 1.0.8.2-1~rcX as versions for my 'unofficial' packages. Debian release will be not until 1.0.8.3 and therefore with version 1.0.8.3-1. Until that I maybe do unofficial 1.0.8.3-1~rcX again for testing and to let debian release be 1.0.8.3-1. So ~rcX only counts for the debian package state, not upstream. Was that your question? With doing these unofficial-own-repository-releases, I hope to get the packages be tested more than I am able to do alone. Cause of 1.0.8.3-1~rcX < 1.0.8.3-1, once officially uploaded to debian, the packages get updated and debian-release version is correct ... only thing that has to be done is shrinking the changelog ;) Lg Roman
Re: May one use ~rc1 within versions although older lintians are complaining?
Am Donnerstag, 22. März 2007 schrieb Manoj Srivastava: > On Thu, 22 Mar 2007 09:37:16 +0100, Roman Müllenschläder <[EMAIL PROTECTED]> said: > > Am Mittwoch, 21. März 2007 schrieb Manoj Srivastava: > >> On Tue, 13 Mar 2007 15:56:44 -0300, Margarita Manterola > >> > >> [EMAIL PROTECTED]> said: > >> > On 3/13/07, Roman Müllenschläder <[EMAIL PROTECTED]> wrote: > >> >> I'm packaging for debian right now and wanted to now if I may > >> >> use a version number like: 1.0.8~rc1-1 ? > >> > > >> > If you use that number, the upstream version should be 1.0.8~rc1. > >> > Is that the upstream number? If you want to have release > >> > candidates of your _own_ package, you should do: 1.0.8-1~rc1 > >> > >> Hmm? Suppose upstream version is currently 1.07 released, and they > >> are planning on releasing 1.08 in the future. Now they are running > >> through 1.08 release candidates, and so we have 1.08 rc1, soon to > >> be followed by 1.08 rc2. The upstream version variables, used by > >> them, are all at 1.08 (not 1.08 '~'. > >> > >> How do you propose the debian releases of the release candidates be > >> numbered? When upstream releases, upstream releases shall have > >> 1.08, 1.08.1 or 1.08-1, and so on. > > > > The upstream currently released is 1.0.8.2. Coming is 1.0.8.3 > > followed by 1.0.9, if there isn't a 1.0.8.4 ;) > > [Bunch of irrelevant stuff snipped] > > > Was that your question? > > If you read above, nothing to do with the example you are > quoting, which is a mere red herring. The distinction between the > cases is that in my example the upstream is releasing release > candidates, and not the Debian developer. > > My contention is that if the Debian maintainer wants to ship > release candidates from upstream, then it is perfectly acceptable to > use 1.0.8~rc1-1. > > manoj Aha ... now we know ;) Lg Roman
What packagemanager is to be presupposed?
Hi there ... The different frontends (apt, dpkg, aptitude, ...) behave different in consideration of installing 'recommends'. The decision which packages should be 'suggested' and which should be 'recommended' depends on what frontend is supposed as 'standard'. What is beeing considered as 'standard'? LG Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#578215: RFP: ggaoed -- a high-performance AoE (ATA over Ethernet) target implementation
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: ggaoed Version: 1.1 Upstream Author: Gábor Gombás URL: http://code.google.com/p/ggaoed/ License: GPL v2 Description: ggaoed is an AoE (ATA over Ethernet) target implementation for Linux. It utilizes Linux kernel AIO, memory mapped sockets and other Linux features to provide the best performance. Would be great to see this as a package in Debian. -- With respect, Roman signature.asc Description: PGP signature
Bug#593411: ITP: pd-wiimote -- A puredata external for accessing the wiimote controller
Package: wnpp Severity: wishlist Owner: Roman Haefeli * Package name: pd-wiimote Version : 0.3.1 Upstream Author : Iohannes M. Zmoelnig * URL : http://puredata.info/community/projects/software/wiimote/ * License : GPLv2 Programming Lang: C Description : A puredata external for accessing the wiimote controller Adds access to the sensor data from Nintendo's wiimote controller. Also it provides an interface to control the controller's actuators such as LED 1-4 and the rumble vibrator. Furthermore, it supports some of the extensions of the wiimote, such as Nunchuk, Motion Plus, Classic Control. . Check the help-patch for more usage information. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20100817222638.12078.80200.report...@netpd.org
Bug#598388: ITP: pd-readanysf -- A Pd external for reading multiple audio file formats
Package: wnpp Severity: wishlist Owner: Roman Haefeli * Package name: pd-readanysf Version : 0.41 Upstream Author : August Black * URL : http://aug.ment.org/readanysf/ * License : GPL-2 Programming Lang: C++ Description : A Pd external for reading multiple audio file formats This Pure Data object supports reading from disk as well as from web- resources and decodes a huge variety of audio codecs. Sources with multiple channels and sampling rates different from Pd's can be played back as well. . Check the help-patch for more usage information. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20100928165325.16686.38935.report...@netpd.org
Bug#599229: ITP: pd-iemnet -- A suite of Pd externals for networking
Package: wnpp Severity: wishlist Owner: Roman Haefeli * Package name: pd-iemnet Version : 0.1 Upstream Author : Miller Puckette , Olaf Matthes , Martin Peach , IOhannes m zmoelnig * URL : http://www.puredata.info/ * License : GPL-2 Programming Lang: C Description : A suite of Pd externals for networking This Pure Data library comes with a few threaded and non-blocking objects for TCP and UDP networking. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20101005214002.23080.44271.report...@netpd.org
ITP: mconfig -- kernel configuration tool
Package: wnpp Version: N/A; reported 2001-12-23 Severity: wishlist * Package name: mconfig Version : 0.20 Upstream Author : Christoph Hellwig <[EMAIL PROTECTED]> * License : GPL Description : mconfig is a tool to configure a Linux kernel. Unlike the scripts that come with kernel source it has a grammar written in yacc and that is compiled once not for each new kernel release. It supports severals interfaces modes for different uses. A test package can be found as http://www.hodek.net/mconfig_0.20-1_i386.deb. Source and .changes also there.
Re: so long and thanks for all the fish
2014-11-08[Sat]11:38 Roman Czyborra read that 2014-11-08[Sat]10:46 Faidon Liambotis wrote <545de691.2090...@debian.org>: Extremely sad to read this, Joey. The few times we've crossed paths, I've enjoyed working with you (and on your ideas) incredibly. And of course I am -as we are all- enjoying the fruits of your efforts, on a daily basis. It's a big loss to the project. Where is Joey Hess going to? Exists a better contract than Debian's? On 11/07/14 23:04, Joey Hess wrote: It's become abundantly clear that this is no longer the project I originally joined in 1996. We've made some good things, and I wish everyone well, but I'm out. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1411081138280.12...@new.woffs.de
Re: [loongson-dev] MIPS64EL rootfs available for use and test
On Tue, 12 Nov 2013 01:57:59 +0800 YunQiang Su wrote: > Hi, folks, > > In the recent days, I figure out the mips64el rootfs and test it on > Loongson 3A platform. > It works well in general, it's time to release it. > > It can be download from: > http://mips64el.debian.net/debian/rootfs/ > > To install it, what you need to do is just unpack it to a partition > and configure kernel/bootloader/fstab by yourself. > > This is a more detailed instruction for Loongson 3A users: > http://mips64el.debian.net/debian/rootfs/README > > Know issues: > 1. MIPS64r2 ISA is required, > while we have made a agree to downgrade the requirement to > mips3 in future. Hello, Thank you very much for your work, it is nice to see Loongson is not forgotten. :) I wonder will this work on Loongson 2F? It is MIPS64 too, but is it "r2"? -- With respect, Roman signature.asc Description: PGP signature
Bug#736330: ITP: glfw3 -- portable library for OpenGL, window and input
Package: wnpp Severity: wishlist Owner: Roman Valov * Package name: glfw3 Version : 3.0.4 Upstream Author : Camilla Berglund * URL : http://www.glfw.org/ * License : Zlib Programming Lang: C Description : portable library for OpenGL, window and input GLFW is an Open Source, multi-platform library for creating windows with OpenGL contexts and managing input and events. It is easy to integrate into existing applications and does not lay claim to the main loop. -- 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/20140122111003.24043.94308.reportbug@jessie
Bug#643838: ITP: pd-flite -- speech synthesis for Pd
Package: wnpp Severity: wishlist Owner: Roman Haefeli * Package name: pd-flite Version : 0.02.2 Upstream Author : Bryan Jurish * URL : http://www.ling.uni-potsdam.de/~moocow/projects/pd/ * License : GPL-2 Programming Lang: C Description : speech synthesis for Pd The flite external contains a single Pd class which provides a high-level text-to-speech interface for English based on the 'libflite' library by Alan W Black and Kevin A. Lenzo. -- 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/20110930082542.3019.18719.reportbug@stabil
Bug#643837: ITP: pd-pdstring -- Pd-objects for string manipulation
Package: wnpp Severity: wishlist Owner: Roman Haefeli * Package name: pd-pdstring Version : 0.10.2 Upstream Author : Bryan Jurish * URL : http://www.ling.uni-potsdam.de/~moocow/projects/pd/ * License : GPL-2 Programming Lang: C Description : Pd-objects for string manipulation This is a collection of Pure Data external classes to ease the handling with strings by providing a way to convert Pd messages to lists of floats and vice versa. Support for wide character strings is provided together with the locale external. -- 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/20110930081758.2984.89596.reportbug@stabil
Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
> SOLUTION 3 > -- > Well, we can also decide that to leave the situation as it is. In this > way, however, users would not be able to install the new version of the > library without also installing libpaperg (and libc6...) That isn't the real problem, but the upgrade from an old system (e.g. bo). The libc6 version libpaperg surely conflicts with older versions of libpaper, where the libs weren't installed to /usr/lib/libc5-compat yet. So to upgrade, the user has to: - Install a new libpaper before libpaperg (due to conflict) - Install libpaperg before libpaper (due to dependency) Obviously, this is Catch-22 :-) The only remedy is to remove the old libpaper, and then to install libpaper and libpaperg. I guess apt will do something like this, and dftp can handle those cases, too. But dselect surely not :-) In any case, it's unconvenient and not obvious to the average user. Additionally, you loose your paper config in the process. > SOLUTION 1 (Suggested by Wichert) - > Create the packages: libpaper - the old libc5 library. May suggest > libpaper-bin. libpaperg - the new libc6 library. May suggest > libpaper-bin. libpaper-bin - the binaries&manpages. Depend on > libpaperg > > Here the problems are that we do not guarantee, by installing > libpaper, that the executables are present in the system. OTOH, by > making libpaper depend on libpaper-bin, the installation of libpaper > would also force the installation of libpaperg, which is what we > wanted to avoid. Yep. Such a dependency would reintroduce the problem we wanted to fix. But I think this alternative is the only one that fix the problem really, so I'd vote for it. > Moreover, one on the executables (paperconfig) is used in the > postinst of libpaper to configure the library; if the executables do > not appear in the libpaper package, it is not possible to call > paperconfig in the postinst, so a different way to initialize the > library should be used (for instance, a subset of paperconfig should > be included in the postinst). I don't know what paperconfig exactly does now, but the idea of replacing the call to it by some simple script can do the job. Additionally you should recommend libpaper-bin, in whose postinst paperconfig can be called. Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wish to orphan or kill: dbuild; Or: Is it of any actual use?
> does buildd have a package ? Not yet. James is working on it, but it's not trivial and may take some time (and James and James<2> are constantly low on spare time :-) > can it be used interactively, and not as a demon ? Yes and no :-) buildd itself is non-interactive, of course, but it uses a script sbuild for the actual unpacking and compiling, and sbuild is rather similar in purpose to dbuild, with the addition that it can also fetch source packages from different locations and that it knows about source dependencies. Roman
Re: Upload queue software?
Hi Jason! > Does anyone know where I can find the software to run a debian > upload queue? I thought it was packaged but I can't seem to find it > using the obvois searches.. It's in project/misc/debianqueued-0.8.tar.gz. It's no proper Debian package because it runs on other Unixes, too (mine runs under Solaris). Roman
Re: Uploading to pandora (nonus)
> Practical question from a porter: imagine some of my recent uploads > have rejected, because they do not follow yet the new sceme. > Allthough when the source package was uploaded, there was no new > scheme yet. Now when I build that package I have to edit > debian/control as a porter otherwise the port will not be included > until the maintainer edits debian/control? I'd edit the resulting .changes file instead (before signing). That's easier. > And when I edit it, I'll have to find out myself in which section > the package will go, ie by locating the source/i386-bin package on > the non-US server? Yes :-( Roman
Re: Upload queue software?
> > It's in project/misc/debianqueued-0.8.tar.gz. It's no proper Debian > > package because it runs on other Unixes, too (mine runs under > > Solaris). > > Hmm, why does that prevent you from packaging it? :> It doesn't really :-), but: - A Debian package plus the still necessary .tar.gz is somewhat more effort for me... - For a proper Debian package, I'd have to write some config stuff etc., for which I'm too lazy :-) So it basically comes down to laziness, yes :-) Roman
Re: Upload queue software?
> Well, it's about time I upgraded from the fairly ancient version of > this that I'm using on www.uk.debian.org, and making a package will > probably only add a minor overhead to the procedure, so if you like, > I'll look at packaging it. Sure, go ahead; I won't mind :-) Roman
Bug#1059632: ITP: sentry-native -- Sentry SDK for C, C++ and native applications
Package: wnpp Severity: wishlist Owner: Roman Ondráček X-Debbugs-Cc: debian-devel@lists.debian.org, m...@romanondracek.cz * Package name: sentry-native Version : 0.6.7 Upstream Contact: Sentry * URL : https://github.com/getsentry/sentry-native * License : MIT Programming Lang: C Description : Sentry SDK for C, C++ and native applications The Sentry Native SDK is an error and crash reporting client for native applications, optimized for C and C++. Sentry allows one to add tags, breadcrumbs and arbitrary custom context to enrich error reports. Supports Sentry 20.6.0 and later.
Bug#982341: ITP: simlib -- SIMulation LIBrary for C++
Package: wnpp Severity: wishlist Owner: Roman Ondráček X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: simlib Version : 3.07 Upstream Author : Petr Peringer * URL : https://www.fit.vutbr.cz/~peringer/SIMLIB/ * License : LGPL-2 Programming Lang: C++ Description : SIMulation LIBrary for C++ This library allows you to create models directly in C++ language using simulation abstractions and tools from the library. SIMLIB allows object-oriented description of continuous, discrete, combined, and various experimental (2D/3D vector, fuzzy) models.
Bug#995440: ITP: halide -- a language for fast, portable computation on images and tensors
It seems like the mail from reportbug didn't get sent to CC's, so i'm manually resending/forwarding it. -- Forwarded message ----- From: Roman Lebedev Date: Fri, Oct 1, 2021 at 1:15 PM Subject: Bug#995440: ITP: halide -- a language for fast, portable computation on images and tensors To: Debian Bug Tracking System Package: wnpp Severity: wishlist Owner: Roman Lebedev X-Debbugs-Cc: debian-devel@lists.debian.org, Sylvestre Ledru , David Bremner -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: halide Version : 12.0.1 Upstream Author : https://github.com/halide/Halide * URL : https://halide-lang.org/ * License : MIT/X Programming Lang: C++ Description : a language for fast, portable computation on images and tensors Halide is a programming language designed to make it easier to write high-performance image and array processing code on modern machines. Halide currently targets: * CPU architectures: X86, ARM, MIPS, Hexagon, PowerPC, RISC-V * Operating systems: Linux, Windows, macOS, Android, iOS, Qualcomm QuRT * GPU Compute APIs: CUDA, OpenCL, OpenGL Compute Shaders, Apple Metal, Microsoft Direct X 12 Rather than being a standalone programming language, Halide is embedded in C++. This means you write C++ code that builds an in-memory representation of a Halide pipeline using Halide's C++ API. You can then compile this representation to an object file, or JIT-compile it and run it in the same process. - --- I have performed initial debianization in https://salsa.debian.org/LebedevRI-guest/halide/-/tree/debian/v12.0.1 the produced DEB's are functional, as far as i can tell. While it is not a preparatory dependency for any further package, it's a bit of a chicken and egg problem. I wanted to play around with halide as far back as 2019, but back then they had a very rudimentary CMake support, and wasn't packaged anywhere. They happily improved their CMake support, so the only problem now is that it's not packaged :) Ideally i would like the package to be accepted into pkg-llvm team. I don't expect it to require too much effort to maintain. While i have been using debian for quite some time now, i'm not a debian developer, and i'm not as deeply familiar with the packaging side of things. Naturally, i don't have any upload rights. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAmFW3vkACgkQCDw+u0oW ieAmbA/8Cn8L6ZF72pa9rje9aWiqXYcUz3lNtEEn9Cf0toq0Pv9+Hh0zXO2f0001 kw5ymPTvbZ6ddnhT8i5i13hRGFhSpAl8Ol594uiRIMFp4KKK5G7/o2yD4tMLXE8E AOJ7bZnRu+AkZibRtPmgjpt1S/EjHeiAM45TL4EZPMeOaA6o8ZGZ9xT6W+AzBhYD XYYSOLwT3IS8XU1UOZRsk00TDvpru7AzUDXXdWVfGhYpL1wzv3A1XlE20+ZKVayP du6osHtT1wV8fdYjLWzw6C49Jm6bgoXGwhzSW/LsDXwTERQsFaSH+5Z2dZ6K8TEr 7LWQsD26hSlD27JPuMHJEqmJWWMJZ7TCSBWXXAojdie9N1F3W3uPARIc+1XkaqU4 IgjZEc1wK6YE7wZbnCMqL96H3q1jPWqVCxOpDJvbdpRh/UwcwKD+bJmE2N1Mi8vF gvFT0aM405JpSFCJcMsB5wD0y38iK2h/c1rZog7xCmvBiLoQnNYLLmjFTt69DL9x Ee/7v4RFoyf90NiiDuAHMVuHWxf2u8h9yB/tYF069jfOxt5x7wISDbsXBeiDZbPD I3bXv8F19eyKI7X4jWC4fMupr81QHQ5uFt93gnTKbG8ajCqgwAcSV+dySl3UQI/l CrflDkP0jp3aMo+EtbPbHFwa3AxYnLC8DQXKdUrZv+qH5pGl6Gk= =4d4i -END PGP SIGNATURE-
Bug#582851: RFP: asus-oled-driver -- Driver for Asus OLED display present in some Asus laptops.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: asus-oled-driver Version: 0.03 Upstream Author: Jakub Schmidtke URL: http://lapsus.berlios.de/asus_oled.html URL: http://developer.berlios.de/projects/lapsus/ License: GPL v2 Description: Driver for Asus OLED display present in some Asus laptops. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#591327: RFP: xul-ext-undo-closed-tabs-button -- This extension allows you to undo closed tabs via a toolbar button or the right-click context menu.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: xul-ext-undo-closed-tabs-button Version: 3.7.1 Upstream Author: supernova_00 (https://addons.mozilla.org/ru/firefox/user/5764/) URL: https://addons.mozilla.org/ru/firefox/addon/3082/ License: Mozilla Public License 1.1 Description: This extension allows you to undo closed tabs via a toolbar button or the right-click context menu. This is simple but useful plugin. Please add this plugin in Debian. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#591328: RFP: xul-ext-quickproxy -- Statusbar button to turn the proxy on and off with a single click
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: xul-ext-quickproxy Version: 2009.07.19 Upstream Author: Ozzie- URL: https://addons.mozilla.org/ru/firefox/addon/1557/ URL: http://ozzie.id.au/quickproxy/ License: Mozilla Public License 1.1 Description: QuickProxy is an extension that I’ve been working on for Firefox. Quickproxy creates a statusbar button to turn the proxy on and off with a single click. This switches Firefox between the different proxy states that you have selected, which are configured through the Firefox preferences, and the type of proxy that is turned on/off is configured through the QuickProxy preferences window. This extension will not provide a proxy server for you. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#591332: RFP: xul-ext-skipscreen -- Incredible Rapidshare and Megaupload download helper
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: xul-ext-skipscreen Version: 0.4.7amo Upstream Author: Skipscreen Team URL: https://addons.mozilla.org/ru/firefox/addon/11243/ URL: http://skipscreen.com/ License: Creative Commons BY-NC-ND Description: Incredible Rapidshare and Megaupload download helper Skips unnecessary pages on sites like Rapidshare, Megaupload, zShare, Mediafire, and more. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#591352: RFP: eclipse-epic -- Perl IDE for the Eclipse platform
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: eclipse-epic Version: 0.6.35 Upstream Author: Jan Ploski, Jochen Ruehl, Stephan Ruehl URL: http://www.epic-ide.org/ URL: https://sourceforge.net/projects/e-p-i-c/files/ License: Common Public License V1.0 Description: Perl IDE for the Eclipse platform EPIC is an open source Perl IDE (including editor and debugger) based on the Eclipse platform. Whether you are into CGI scripting or full-fledged Perl projects with hundreds of modules, EPIC is the most feature-rich and extensible free Perl IDE available today, thanks to a seamless integration with all the major features and GUI conventions of Eclipse. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#591354: RFP: eclipse-shelled -- Shell script editor for Eclipse.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: eclipse-shelled Version: 2.0.0 Upstream Author: Alexander Kurtakov, Satch URL: https://sourceforge.net/projects/shelled/ License: Eclipse Public License Description: ShellEd is a superb shell script editor for Eclipse. The great benefit of this plugin is the integration of man page information for content assist and text hover. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#591360: RFP: eclipse-subversive -- Provide Subversion (SVN) integration for Eclipse.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: eclipse-subversive Version: 0.7 Upstream Author: Subversive Team URL: http://www.eclipse.org/projects/project_summary.php?projectid=technology.subversive URL: http://www.polarion.com/products/svn/subversive.php License: Eclipse Public License Version 1.0 Description: Provide Subversion (SVN) integration for Eclipse. The Subversive plug-in enables you to work with Subversion repositories from the Eclipse workbench in almost exactly the same way that has long been possible with CVS repositories via the CVS plug-in bundled in the standard Eclipse distribution. General features of the Subversive plug-in are quite similar to those of the CVS plug-in: * Browse remote repositories (in this case, Subversion repositories) * Add a project to the repository and check out projects from the repository * Synchronize a project to see incoming and outgoing changes * Commit, update and revert changes * See resource change history * Merge changes Similarity to the CVS plug-in is Subversive's major guiding principle. The goal is to ensure that both plugins use similar concepts, semantics, and interface for similar things. At the same time, Subversive enables you to benefit from all of Subversion's features including those which differ from, or are not present in CVS. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#591902: RFP: xul-ext-firexpath -- FireXPath is a Firebug extension that adds a development tool to edit, inspect and generate XPath expressions.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: xul-ext-firexpath Version: 0.9.2 Upstream Author: Pierre Tholence URL: https://addons.mozilla.org/ru/firefox/addon/11900/ License: GPL v.3.0 Description: FireXPath is a Firebug extension that adds a development tool to edit, inspect and generate XPath expressions. With FireXPath you can: * Edit XPath expressions with auto completion (using TAB or up and down arrows). * Evaluate the expression on HTML or any XML documents. * Display the result of evaluations in a Firebug-like DOM tree. * Highlight the results directly on the document displayed by Firefox (works only with HTML documents). * Generate an XPath expression for an element by right clicking on it and selecting "Inspect XPath" located under "Inspect Element". * Define the evaluation context of an XPath expression. * Choose the document in which to evaluate the XPath expression (only applicable for HTML documents with frames or iframes). -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#592856: RFP: libcgi-session3-perl -- CGI::Session - persistent session data in CGI applications
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: libcgi-session3-perl Version: 3.95 Upstream Author: Sherzod Ruzmetov URL: http://search.cpan.org/~sherzodr/CGI-Session-3.95/ License: GPL-1+ | Artistic Description: CGI::Session - persistent session data in CGI applications CGI-Session is a Perl5 library that provides an easy, reliable and modular session management system across HTTP requests. Persistency is a key feature for such applications as shopping carts, login/authentication routines, and application that need to carry data accross HTTP requests. CGI::Session does that and many more. In Debian we have libcgi-session-perl. But it`s new 4.xx version. Modules interface not compatible with 3.xx version. But I have some old projects and need library 3.xx version. Please add this package. I don`t want make my server disposal dump of modules, installed through `cpan`. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#593339: RFP: freeorion -- FreeOrion is a free, open source, turn-based space empire and galactic conquest computer game
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: freeorion Version: 0.3.15 Upstream Author: FreeOrion Team URL: http://www.freeorion.org URL: http://sourceforge.net/projects/freeorion/files/FreeOrion/ License: GPL 2 Description: FreeOrion is a free, open source, turn-based space empire and galactic conquest computer game FreeOrion is a free, open source, turn-based space empire and galactic conquest (4X) computer game being designed and built by the FreeOrion project. FreeOrion is inspired by the tradition of the Master of Orion games, but is not a clone or remake of that series or any other game. SVN: svn co http://freeorion.svn.sourceforge.net/svnroot/freeorion/trunk freeorion Comments: http://www.freeorion.org/forum/viewtopic.php?f=9&t=1792 License: http://www.freeorion.org/index.php/FreeOrionWiki:Copyrights (Code - GPL2, Art - CC) -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#595284: ITP: xul-ext-cacheviewer -- this extenion is gui front-end of "about:cache"
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: xul-ext-cacheviewer Version: 0.6.3 Upstream Author: Tiny Benki URL: https://addons.mozilla.org/ru/firefox/addon/2489/ License: MPL-1.1 Description: This extenion is GUI Front-end of "about:cache". Allows searching and sorting memory and disk cache 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/4c7fe5e8.2030...@rambler.ru
Bug#595427: ITP: winetricks -- Quick and dirty script to download and install variousredistributable runtime libraries
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: winetricks Version: 20100822 Upstream Author: Austin English , Google: Dan Kegel URL:http://wiki.winehq.org/winetricks License: LGPL Description: Quick and dirty script to download and install variousredistributable runtime libraries -- 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/4c81585b.7080...@rambler.ru
Re: Bug#595427: ITP: winetricks -- Quick and dirty script to download and install variousredistributable runtime libraries
05.09.2010 12:11, Moritz Muehlenhoff пишет: > In gmane.linux.debian.devel.general, you wrote: >> On Fri, Sep 3, 2010 at 4:19 PM, Roman V. Nikolaev wrote: >>> Package name: winetricks >>> Version: 20100822 >>> Upstream Author: Austin English , Google: Dan >>> Kegel >>> URL:http://wiki.winehq.org/winetricks >>> License: LGPL >>> Description: Quick and dirty script to download and install >>> variousredistributable runtime libraries >> >> Do we really need a package for a single file? > > Roman, you should rather file a bug to have that script included into > the standard wine package. > > Cheers, > Moritz I wait for Debian Wine packaging Team answer. I think we have rason to make separate package. First: this script update very often. Second: this is not wine team code, but third party. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#600687: RFP: xul-ext-cacheviewer -- this extension is GUI front-end of "about:cache"
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: xul-ext-cacheviewer Version: 0.6.3 Upstream Author: Tiny BENKI URL: https://addons.mozilla.org/ru/firefox/addon/2489/?src=api License: Mozilla Public License 1.1 Description: This extenion is GUI Front-end of "about:cache". Allows searching and sorting memory and disk cache files. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#607712: RFP: libsoap-wsdl-perl -- SOAP with WSDL support
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org --- Please fill out the fields below. --- Package name: libsoap-wsdl-perl Version: 2.00.10 Upstream Author: Martin Kutter URL: http://search.cpan.org/~mkutter/SOAP-WSDL-2.00.10/ License: GPL, Artistic License Description: SOAP with WSDL support This module is used in Google API. Please add it in Debian. -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#618807: RFP: icinga-web -- host and network monitoring system - modern web interface
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: icinga-web Version: 1.3.0 Upstream Author: Icinga Team URL: http://www.icinga.org/about/icingaweb/ URL: http://sourceforge.net/projects/icinga/files/icinga-web/1.3.0/ License: GPL Description: host and network monitoring system - modern web interface Icinga is a modular monitoring framework for hosts, services, and networks, based on the Nagios project. It is designed to be easy to understand and modify to fit any need. . Features include: * monitoring of network services via ping, SMTP, POP3, HTTP, NNTP, or TCP port; * plugin interface to allow for user-developed service checks; * contact notifications when problems occur and get resolved (via email, pager, or user-defined method) * support for proactive problem resolution (handlers can be defined to be run during service or host events); * web output: current status, notifications, problem history, log file, etc. . This package provides the online portal to view Icinga monitoring results and send commands to the Icinga Core. Host and service status, history, notifications and status maps are available to keep a check on the health of your network in real-time. -- 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/4d83889d.9010...@rambler.ru
Bug#670605: RFP: libjs-jquery-jqplot -- jQuery Plotting Plugin
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-javascript-de...@lists.alioth.debian.org Package name: libjs-jquery-jqplot Version: 1.0.0b2_r1012 Upstream Author: Chris Leonello URL: http://www.jqplot.com License: GPL, MIT Description: jQuery Plotting Plugin jqPlot is a plotting and charting plugin for the jQuery Javascript framework. jqPlot produces beautiful line, bar and pie charts with many features: Numerous chart style options. Date axes with customizable formatting. Up to 9 Y axes. Rotated axis text. Automatic trend line computation. Tooltips and data point highlighting. Sensible defaults for ease of use. -- Roman V. Nikolaev mail:rshadowa...@gmail.com jabber: rsha...@jabber.org icq: 198-364-657 site:http://www.rshadow.ru -- 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/4f9a5db0.6090...@gmail.com
Bug#671180: RFP: libnginx-perl -- Nginx::Perl - full-featured perl support for nginx
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org Package name: libnginx-perl Version: 1.2.0.4 Upstream Author: Alexandr Gomoliako URL: http://search.cpan.org/~zzz/Nginx-Perl-1.2.0.4/src/http/modules/perl/Perl.pm License: same as "nginx" Debian package Description: Nginx::Perl - full-featured perl support for nginx -- Roman V. Nikolaev mail:rsha...@rambler.ru icq: 198-364-657 jabber: rsha...@jabber.org site:http://www.rshadow.ru signature.asc Description: OpenPGP digital signature
Bug#656903: RFP: desurium -- Desura is a gaming client that allows a user to one click download and install games and game modification.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: desurium Version: 2012.01.20 Upstream Author: Mark Chandler (Desura Net Pty Ltd) URL: https://github.com/lodle/Desurium URL: http://www.desura.com License: GPLv3 Description: Desurium is a gaming client that allows a user to one click download and install games and game modification. . This is open version of Desura client. -- 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/4f1c5f1b.5000...@rambler.ru
Bug#626723: RFP: rhythmbox-plugin-ror -- Remember last played song and play it as first song after rhythmbox restarts.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: rhythmbox-plugin-ror Version: unknown Upstream Author: Michal Nánási URL: http://people.ksp.sk/~mic/Projects/RhythmboxROR License: GPL3 Description: Remember last played song and play it as first song after rhythmbox restarts. -- 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/4dceba0b.6090...@rambler.ru
Bug#626724: RFP: rhythmbox-plugin-folderview -- Rhythmbox folder view plugin
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: rhythmbox-plugin-folderview Version: unknown Upstream Author: Imdiot URL: http://code.google.com/p/folderview/ URL: https://launchpad.net/~zedtux/+archive/rhythmbox-folderview License: GPL3 Description: Rhythmbox folder view plugin This plugin implement a new view as Folder view in Rhythmbox. -- 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/4dcebb78.1080...@rambler.ru
Bug#793785: RFP: libminion-perl -- Minion is a job queue for the Mojolicious real-time web framework with support for multiple backends
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: libminion-perl Version: 1.15 Upstream Author: Sebastian Riedel URL: https://metacpan.org/pod/Minion URL: https://github.com/kraih/minion License: artistic_2 Description: Minion is a job queue for the Mojolicious real-time web framework with support for multiple backends Please add package to Debian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55b63c19.3060...@rambler.ru
