supply flake graphite from China
To Whom it may concern I am Andy from TEHNGSHENG INTERNATIONAL GROUP LIMITED. We supply : Natural flake graphite,amorphous graphite if you are interest our product, i will porvide the more details information We have the big & powerful factory in China, and we cooperate with them to develop the minerals and keep long-term strategy business cooperation. We expect that our products could attract your attention. For more information, please view our website: www.tshengintl.com or view www.ec21.com search our company name Hope we can build a good business relationship in the near future. Looking forward to hearing from you soon Best Regards Andy
Bug#484553: Acknowledgement (libft-perl: depends on the unavailable perlapi-5.8.8)
i believe this is related to #478983 - defoma recommends libft-perl in lenny, as that is the message i was receiving when aptitude tried to resolve the dist-upgrade conflict. On Wed, 2008-06-04 at 20:57 +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian QA Group <[EMAIL PROTECTED]> > > If you wish to submit further information on this problem, please > send it to [EMAIL PROTECTED], as before. > > Please do not send mail to [EMAIL PROTECTED] unless you wish > to report a problem with the Bug-tracking system. > > -- andy <[EMAIL PROTECTED]> diatribes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#1003393: friendly-recovery: Friendly-recovery is not in grubmenu
Package: friendly-recovery Version: 0.2.42 Severity: important X-Debbugs-Cc: online- Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages friendly-recovery depends on: ii systemd-sysv 247.3-6 ii whiptail 0.52.21-4+b3 Versions of packages friendly-recovery recommends: ii gettext-base 0.21-4 friendly-recovery suggests no packages. -- no debconf information
Bug#1003402: friendly-recovery: Friendly-recovery dont start, Screan hangs.
Package: friendly-recovery Version: 0.2.42 Severity: important X-Debbugs-Cc: online-...@web.de Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages friendly-recovery depends on: ii systemd-sysv 247.3-6 ii whiptail 0.52.21-4+b3 Versions of packages friendly-recovery recommends: ii gettext-base 0.21-4 friendly-recovery suggests no packages. friendly-recovery: Friendly-recovery dont start, Screan hangs.
Bug#737564: dump should accomodate backups of media named by their UUID
Package: dump Version: 0.4b44-1 Severity: normal Dear Maintainer, (Hi, Bdale! We have interacted in the past in the world of Forth.) *** Please consider answering these questions, where appropriate *** * What led up to the situation? I have some disks brought over to a new server, where they will continue to be used with their current contents. * What exactly did you do (or not do) that was effective (or ineffective)? When time came for backups, I realized that /var/lib/dumpdates from their old system would be needed in order to permit incremental backups. I bought the file over, and converted the named devices in this file to their /dev/disk/by-uuid/ path. I then unmounted the disks, and attempted: /sbin/dump -2u -f /dev/disk/by-uuid/ * What was the outcome of this action? Instead of permitting me to back up from this increment, it noted that it did not have previous state, and was going to do a level 0. * What outcome did you expect instead? If a disk is named by UUID device path, and that UUID device path is correctly named in /var/lib/dumpdates, I would expect to be able to do an incremental dump. Instead, I had to edit /var/lib/dumpdates to reference the device by its /dev/sdXY pathname, mount the filesystem, and then it permitted the incremental dump. Note that this defect report is NOT trying to argue that the tool should, in general, use UUID's to detect which disks are which. I understand that this would be a very important change. But *if* the UUID disk path is present in /var/lib/dumpdates *and* in the "dump" command line (i.e., a UUID device path to an unmounted filesystem), I think it would be correct to honor the dumpdates state and permit an incremental dump. *** End of the template - remove these lines *** -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 3.4.75+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages dump depends on: ii e2fslibs 1.42.5-1.1 ii libblkid1 2.20.1-5.3 ii libc6 2.13-38 ii libcomerr21.42.5-1.1 ii libgcc1 1:4.7.2-5 ii libreadline6 6.2+dfsg-0.1 ii libselinux1 2.1.9-5 ii libtinfo5 5.9-10 ii libuuid1 2.20.1-5.3 ii tar 1.26+dfsg-0.1 dump recommends no packages. dump suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140203205512.3864.21657.report...@a20.vsta.org
Bug#714234: dump: restore #157 dump fails to restore incremental if directory was removed
--- This bug just bit me, up-to-date Wheezy. So... does nobody care that incremental backups are broken on Debian? I know, this is just a second order effect of nobody on dump.sf.net caring that their incremental backup tool only works if the backups are not incremental. But my confidence is a little shaken here Andy -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140411230358.1a3121f4...@vsta.org
Bug#706412: apps don't run in blackbox over xdmcp
Package: blackbox Version: 0.70.1-13 Severity: minor I usually use xfce over xdmcp (connecting from Slackware 14.0 to Debian Wheezy), but when I tried blackbox, no apps opened. I couldn't even open a terminal to see what the problem was. I'm right clicking on the desktop to bring up the menu, and left-clicking on what I'd like to execute. When I left-click, the menu disappears and nothing happens. I logged in locally, and didn't have the problem. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517ee7b4.4090...@gmail.com
Rolex Replica Catherine
Hello, Thank you for expressing interest in Rolex Replica watches. This opportunity to offer you our fine selection of Italian/Swiss crafted Rolex Timepieces. You can view our large selection of Rolexes (including Breitling, Tag Heuer, Cartier etc) You are guaranteed of lowest prices and highest quality each and every time you purchase from us. Please do not hesitate to visit our website at http://www.chooseyourwatch4u.com I certainly look forward to hearing from you. Thanks and Best regards, Andy Otto Sales Manager Rolex Watches Enterprises tom xa sanford tmr wa iv coralline bc cabana mpg doll xmx isaacson yp bobcat sz soap na alga ff darken uns leadsmen zmd z ail endogenous jk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#737491: eterm: Occurs on upgrade to Jessie from Wheezy
Package: eterm Version: 0.9.6-1 Followup-For: Bug #737491 Dear Maintainer, Since updating my machine from Wheezy to Jessie, Eterm now uses 100% CPU when started. I've tried starting Eterm manually with no command line arguments and it never gets as far as displaying a bash prompt. I'm not really sure how to debug this further; please let me know anything I can do to find out more information. Thanks for your help. -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages eterm depends on: ii libast20.7-7 ii libc6 2.19-18+deb8u7 ii libfreetype6 2.5.2-3+deb8u1 ii libice62:1.0.9-1+b1 ii libimlib2 1.4.6-2+deb8u2 ii libsm6 2:1.2.2-1+b1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii multiarch-support 2.19-18+deb8u7 ii zlib1g 1:1.2.8.dfsg-2+b1 eterm recommends no packages. eterm suggests no packages. -- no debconf information
Bug#770369: Bug#737491: eterm: Occurs on upgrade to Jessie from Wheezy
Hi, Thanks for your help! I think this bug is the same than bug #770369. I tried to file this as a followup to the existing bug but must have messed up with my usage of `reportbug`; sorry! This bug is close in stretch (testing). As it is expected the release stretch occurs soon, the easiest way is: 1. To wait for the release of stretch to get this problem fixed when you upgrade from Wheezy to Stretch. 2. Downgrade the Eterm package to the version in Jessie so you can use it until the upgrade to Stretch. Do you mean wheezy? Do you have a command to hand that can do that for me or is it best to fetch the .deb out of the appropriate package pool? I am trying to maintain Eterm package, but my process of learning to do it properly is getting a little long so I have not prepared a new Eterm package. I have checked the fix proposed and my local Eterm package is working in Jessie-amd64 (thanks to Charles Gorand and Arnaud Ceyroll for the fix). Andy, if you want I can send you my local package to your e-mail, so you can use it. For Santiago Vila (or other developers) I have modified the source package in Jessie by performing the fix suggested by Arnaud and Charles to the command.c file, just recompiled in my Jessie system and the new Eterm package is working again. Maybe I can try to build my own local package? Are you able to send me the patch for the Jessie package? Maybe it is worth to propose an update for Jessie so the package will be usable again for all the users. I will have some spare time after the middle of June, so I would be able to apply the fix in the correct way (I have just edited the source to test it, I have to read deeper the maint-guide to do it in the right way). After the release of Stretch I will try to fix the UTF8 problem in Eterm to finally maintain this package. Thanks for your help and for giving the time. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF
Bug#737491: eterm: Occurs on upgrade to Jessie from Wheezy
Hi, Andy, I have tested a couple of solutions and I think the easiest way for you is just to download the Eterm package for Stretch (testing) and install it in your system manually with: dpkg -i eterm_0.9.6-4_amd64.deb I have just installed the Eterm version in testing and no new packages are needed, just this one and it is working in my system. (One can use pinning in apt to install packages for several distributions, but for just one package I think it is not necessary in this case). Please, let me know if this solution is not working for you to try a more elaborate fix until Stretch is released. That works great, thanks! Thank you so much for your help; it's been really generous of you. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF
