Search Results: "Osamu Aoki"

4 August 2020

Osamu Aoki: exim4 configuration for Desktop (better gmail support)

Since gmail rewrites "From:" address now (2020) and keep changing access limitation, it is wise not to use it as smarthost any more. (If you need to access multiple gmail addresses from mutt etc, use esmtp etc.)

For most of our Desktop PC running with stock exim4 and mutt, I think sending out mail is becoming a bit rough since using random smarthost causes lots of trouble due to the measures taken to prevent spams.

As mentioned in Exim4 user FAQ , /etc/hosts should have FQDN with external DNS resolvable domain name listed instead of localdomain to get the correct EHLO/HELO line. That's the first step.

The stock configuration of exim4 only allows you to use single smarthost for all your mails. I use one address for my personal use which is checked by my smartphone too. The other account is for subscribing to the mailing list. So I needed to tweak ...

Usually, mutt is smart enough to set the From address since my .muttrc has

# Set default for From: for replyes for alternates.
set reverse_name

So how can I teach exim4 to send mails depending on the mail accounts listed in the From header.

For my gmail accounts, each mail should be sent to the account specific SMTP connection matching your From header to get all the modern SPAM protection data in right state. DKIM, SPF, DMARC... (Besides, they overwrite From: header anyway if you use wrong connection.)

For my mails, mails should be sent from my shell account on so it is very unlikely to be blocked. Sometimes, I wasn't sure some of these mails sent through my ISP's smarthost are really getting to the intended person.

To these ends, I have created small patches to the /etc/exim4/conf.d files and reported it to Debian BTS: #869480 Support multiple smarthosts (gmail support). These patches are for the source package.

To use my configuration tweak idea, you have easier route no matter which exim version you are using. Please copy and read pertinent edited files from my github site to your installed /etc/exim4/conf.d files and get the benefits.
If you really wish to keep envelope address etc. to match From: header, please rewite agressively using the From: header using eddited rewrite/31_exim4-config_rewriting as follows:

*@+local_domains "$ lookup $ local_part lsearch /etc/email-addresses \
$value fail " f
# identical rewriting rule for /etc/mailname
*@ETC_MAILNAME "$ lookup $ local_part lsearch /etc/email-addresses \
$value fail " f
* "$h_from:" Frs

So far its working fine for me but if you find bug, let me know.


28 May 2017

Russ Allbery: Debian Policy

Today, about a month later than I had intended due to having three consecutive work weeks that mostly drained me of energy, I finally uploaded Debian Policy to Debian experimental. This went to experimental rather than unstable for two reasons: I expect there to be a few more point-release changes to packaging and formatting uploaded to experimental before uploading to unstable for the start of the buster development cycle. (I've indeed already noticed about six minor bugs, including the missing release date in the upgrading checklist....) Due to the DocBook conversion, and the resources rightly devoted to the stretch release instead, it may be a bit before the new Policy version shows up properly in all the places it's published. As you might expect from it having been more than a year since the previous release, there were a lot of accumulated changes. I posted the full upgrading-checklist entries to debian-devel-announce, or of course you can install the debian-policy package from experimental and review them in /usr/share/doc/debian-policy/upgrading-checklist.txt.gz.

16 August 2015

Russ Allbery: git-pbuilder 1.35

Today is the day for minor software releases. It's amazing how much more free time I have when I'm not unpacking boxes. Osamu Aoki submitted a bug report a while back asing for --update, --create, and --login to be supported as options to git-pbuilder, in addition to the versions without leading hyphens, since pbuilder and cowbuilder require the hyphens and people are used to typing them. I've finally merged his patch and released git-pbuilder 1.35 with that change. It will probably show up in git-buildpackage shortly. (Still need to rewrite this script in Python one of these days so that it can be properly and fully merged with git-buildpackage.) You can get the latest version of git-pbuilder from my scripts page.

Lunar: Reproducible builds: week 16 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Valentin Lorentz sent a patch for ispell to initialize memory structures before dumping their content. In our experimental repository, qt4-x11 has been rebased on the latest version (Dhole), as was doxygen (akira). Packages fixed The following packages became reproducible due to changes in their build dependencies: backup-manager, cheese, coinor-csdp, coinor-dylp, ebook-speaker, freefem, indent, libjbcrypt-java, qtquick1-opensource-src, ruby-coffee-script, ruby-distribution, schroot, twittering-mode. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues but not all of them: Patches submitted which have not made their way to the archive yet: akira found another embedded code copy of texi2html in maxima. Work on testing several architectures has continued. (Mattia/h01ger) Package reviews 29 reviews have been removed, 187 added and 34 updated this week. 172 new FTBFS reports were filled, 137 solely by Chris West (Faux). josch spent time investigating the issue with fonts in PDF files. Chris Lamb documented the issue affecting documentation generated by ocamldoc. Misc. Lunar presented a general Reproducible builds HOWTO talk at the Chaos Communication Camp 2015 in Germany on August 13th. Recordings are already available, as well as slides and script. h01ger and Lunar also used CCCamp15 as an opportunity to have discussions with members of several different projects about reproducible builds. Good news should be coming soon.

16 July 2015

Osamu Aoki: debmake and debamke-doc and debian-handbook

While updating the maintainer's guide, I had faced with several issues to update it as it is, since it was based on the dh-make package and does not play nice with new features such as multi-arch etc. Also. the lack of capability to create a decent copyright information template was my concern.

I have created the debmake tool to address shortcomings of dh-make. It was good attempt for Jessie, but it has not so nice bug on parsing copyright. So I decided to drop it for Jessie.

The current testing repository has the updated debmake command. With the -k option, you can check if the your debian/copyright is covering all the files properly in source or not.

Since I got this updated package, I rewrote the maintainer's guide from scratch. Now it is available in the debmake-doc package. You can see all the packaging cases including autotools, cmake, and libraries. If I made a mistake, let me know. As you may noticed, debian-doc related web pages are now generated from the latest uploaded packages mostly. debmake-doc is no exception.
"Guide for Debian Maintainers"

By using debmake as the template generation tool, the document can be made shorter and there are many practical examples. More over, all the source code examples can be found in the source tree. Try:

$ apt-get source debmake-doc
$ sudo apt-get install devscripts build-essentials
$ sudo apt-get build-dep debmake-doc
$ cd debmake-doc*
$ make

You get the simulated log of building all the details of the packaging examples in this way.

With upcoming uploads, I should fix some CSS for the better cell phone compatibility but this is in good shape from the PC browsers.

Oh, not last ... NOW debian-handbook is on our server and its mirrors.

I think this is the most comprehensive work on Debian system and deserves to be presented in our web pages prominently. Kudos for people who wrote this fine manual.

(I think outdated reference to old TLDP pages should be mostly dropped in our page.)

Please note web pages on has been modified to make the language based content negotiation. So you should see the page based on your browser settings.


5 January 2015

Raphaël Hertzog: My Free Software Activities for December 2014

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 20 hours on Debian LTS. I did the following tasks: Not in the paid hours, but still related to Debian LTS, I kindly asked Linux Weekly News to cover Debian LTS in their security page and this is now live. You will see DLA on the usual security page and there s also a dedicated page tracking this: I modified the LTS wiki page to have a dedicated Funding sub-page. This avoids having a direct link to Freexian s offer on the main LTS page (which surprised a few persons) and allows to give some more background information and makes it possible for other persons/companies to also get listed in the same way (since there s no exclusive relationship between Debian and Freexian here!). And I also answered some questions of Nguyen Cong (a new LTS contributor, employed by Toshiba with explicit permission to contribute to LTS during work hours! \o/), on IRC, on (again) and on the mailing list! It s great to see the LTS project expanding beyond current members of the Debian project. Distro Tracker I want to give again some more priority to Distro Tracker at least to complete the transition from the old PTS to this new service last month has been a bit better than November but not by much. I reviewed a patch in #771604 (about displaying long descriptions), I merged another patch in #757443 (fixing bad markup which rendered the page unusable with Konqueror), I fixed #760382 where package gone through NEW would never lose their version in NEW. Kali related contributions I m not covering my Kali work here but only some things which got contributed upstream (or to Debian). First I ensured that we could build the Kali ISO with live-build 4.x in jessie. This resulted in multiple patches merged to the Debian live project (1 2 3 4). I also submitted a patch for a regression in the handling of conditionals in package lists, it got dropped and has been fixed differently instead. I also filed #772651 to report a problem in how live-build decided of the variant of the live-config package to install. Kali has forked the sysvinit package to be able to disable the services by default and I was investigating how to port this feature in the new systemd world. It turns out systemd has such a feature natively: it s called Preset files. Unfortunately it s not usable in Debian because Debian does not call systemctl preset during package installation. I filed bug #772555 to get this fixed (in Stretch, it s too late for Jessie :-(). Saltstack I m using salt to automate some administration task in Kali, at home and at work. I discovered recently that the project tries to collect Salt Formulas : those are ready to use instructions for as many services as possibles. I started using this for some simple services and quickly felt the need to extend salt-formula , the set of states used to configure salt with salt. I submitted 5 pull requests (#73 and #74 to configure salt in standalone mode, #75 to enable the upstream package repositories, #76 to automatically download and enable the desired salt formulas, #77 for some bugfixes) and they have all been merged in less than 24 hours (that s the kind of thing that motivates you to contribute again in the future!). I also submitted a bug fix for samba-formula and a bug report in salt itself (#19180). BTW I have some salt states to setup schroot and sbuild. I will try to package those as proper salt formulas in the future Misc stuff Mailing list governance. In Debian, we often complain about meta-discussion on mailing lists (i.e. discussions about how we discuss together) and at the same time we need to have that kind of discussions from time to time. So I suggested to host those discussions in a new mailing list and to get this new list setup, our rules require to have other people interested in having this list. The idea had some support when we discussed it on debian-private, so I relaunched it on debian-project while filing the official request in the BTS: #772645. Unfortunately, I only got one second. So if you re interested in pursuing this idea, speak up now Sponsorship. I sponsored another Galette plugin this month: galette-plugin-fullcard. Thanks to Fran ois-R gis Vuillemin for his work. Publican. Following one of my bug report against Publican and with the help of the upstream author, we identified the problem and I submitted a patch. Thanks See you next month for a new summary of my activities.

One comment Liked this article? Click here. My blog is Flattr-enabled.

18 July 2014

Osamu Aoki: Debian does not boot ...Crucial/Micron RealSSD m4/C400/P400

Today, my PC did not boot as usual to Debian. BIOS could not find my /dev/sda and was looking for the netboot image. I restarted my PC and got into the BIOS boot setting menu. Hmmm.... my first SDD (/dev/sda) was missing. My second HDD (/dev/sdb) was there. But I did not put the Grub boot-loader there. No wonder it did not boot.

I have a 32GB USB3 stick with the full Debian system. It is not a live CD image USB stick but a HDD formatted and encrypted system. Though it is not the fastest system, it is very light and usable. I plugged it in and powered it up. It booted OK but /dev/sda was still missing. While it booted, I saw "ata1: COMRESET failed (errorno=-16)" . So this ata1 SSD cannot be accessed from BIOS nor Linux. Sigh ...

Looking around the web under the USB stick system, I saw some people were talking that the loose serial ATA cable sometimes causes this message. Since my PC is a laptop, It has no flexible cable but has an on-board connector inside for the SSD.

Hoping my problem is just a bad connection problem, I crack opened the back panel of my PC. The SSD looked fine. I unplugged it from the connector and reinserted back into the connector. After repeating this several times to be sure, I closed the back panel and booted.

It boots as expected into Debian. Looks like everything is fine.
SMART Error Log Version: 1
No Errors Logged

If you have any boot problem like mine, please reinsert your SSD to the connector like I did before you panic.

Good luck.


PS: This Crucial/Micron RealSSD m4/C400/P400 M4-CT256M4SSD2 previously had a problem. A firmware bug made it read-only. The firmware updates fixed my Debian system on this SSD. I could fix this without Win*** OS since the firmware update was on a bootable disk image file.

2 July 2014

Osamu Aoki: debmake -- checking source against DEP-5 copyright

It has been already more than a year after my initial uploading of the debmake package which offers semi-automatic generation of the DEP-5 copyright file.

One recent feature addition is the "debmake -k" command which audits debian/copyright contents against the latest source. If, for example, the upstream changed the license from GPL-2.0+ to 3,0+, this command will tell you this change. (In the debian/copyright, the more specific entry should be listed after the generic entry since parser uses the last definition as the valid one.)

I admit that this package had some regressions in some previous versions. It is now a stable tool to help making multiarch aware Debian packages of any types. If you had negative experiences, please try this again.

Let me quote from its documentation for the features. (Also available in the package.)
The debmake command is intended to replace functions offered historically by deb-make and dh_make commands. Its features include:
  • use of dh syntax under the new debhelper (> 9.0) package
    • extensive check of copyright for DEP-5 (debian/copyright)
    • substvar supports for binary packages (debian/control)
    • support of compiler hardening options (debian/rules)
  • keep pre-existing Debian package configuration files untouched
    • automatic generation of the missing template packaging files
    • easy verification of the debian/copyright file against the current source. (-k option)
  • easy packaging command line UI supporting
    • non-stop execution with clean results
    • direct operation on the tarball archive
    • direct operation on the source tree from VCS
    • the multiarch Debian package
    • the multi binary Debian package
    • the non-native Debian packages from the VCS snapshot
    • seamless work with debuild, pdebuild, etc.
I wrote this debmake command because there was no easy command like "python bdist_deb" to create the Debian binary package. Now "debmake -d -s -b":python" -i debuild" does the job for me.
This documentation comes with detailed packaging examples, too.

13 May 2013

Hideki Yamane: 100th Tokyo Debian meeting & "Wheezy" release party

We are please to report that we held "100th, Tokyo Area Debian Meeting"... yes, 100th!!! (since 2005), 11th May in Shibuya, Tokyo

Discussed about "stable" releasing,

lectured "" by Yasuhiro Araki
and "modern packaging" by Osamu Aoki.

Also, Ubuntu folks showed "Ubuntu phone" and it looks good and interesting (however, it's on the development stage, yet).
Then, party!!! :-) happy to release "Wheezy"

I hope we'll hold "Jessie" in early 2015.

23 October 2006

Wouter Verhelst: Rock migration finished

This weekend, I started modifying the way I use disk space on rock, my home desktop and server. rock used to be a PentiumIII running at 650Mhz, until I received an SMP box from Osamu Aoki when he moved back to Japan and couldn't take it with him. So rock is now a dual Celeron 433Mhz, and the machine that originally served as my desktop went on to replace pop, my parent's box. A little while later, rock's hard disk died, and I was left with a single 13G hard disk (or so I thought). At that point, I used the sarge installer to install rock on an LVM system, so that I could easily enlarge the volumes in the installation later on, without having to start copying files for no good reason. When I later on bought a second-hand 80G hard disk to add to the LVM system, I found that there were in fact two more hard disks inside rock, which simply hadn't been connected to the IDE controllers; one was 20G large, the other 40G. So I added them all, and enlarged all the volumes that could use some extra space. A while later, I started worrying. What if one of the disks would die? Reading the documentation, I found that I would lose all the LVM volumes that were on the dead disk, even if only partially. Obviously there's also an option to get LVM to mount partial volumes to get at the data that's still available, but it didn't sound too hopeful. In short, I became convinced that what I was doing wasn't all that sure for my data. Obviously I have backups of the important stuff, but avoiding failure is always preferable over having to use recovery procedures, even if they're good recovery procedures. So I decided that I would migrate to a setup that would use at least some redundancy; that way, I could stop worrying as much. And since I had four disks, there should've been a way to do that. I started partitioning, and found that I had overlooked a second 40G hard disk that rock was using; so rather than creating a RAID5 array on top of two 33G partitions (on the 40G and 80G disks) and one RAID0 array or something similar (combining the 13G and 20G disks), I decided to create a 40G RAID5 array composed of two 40G disks and one 40G partition on an 80G disk. All other disk space (the other 40G on the 80G disk, and the 20G and 13G disks) would be combined into an LVM volume group for less important data (such as the squid cache and other large parts of /var, swap space, and a bunch of digitized CD's of which I still have the originals). Also, the RAID5 array wouldn't just be one large volume or so; instead, I created another LVM volume group in the RAID array. Theoretically I could of course combine everything in one volume group and use pvmove and/or the right options on lvcreate to force important volumes on the RAID array, but then having separate volume groups for RAID/no RAID would force me to think carefully before managing volumes, which is never a bad idea. So on Friday I started moving data. This would involve running pvmove on a particular physical volume until all data would be removed from it; then run vgreduce -a <vgname> to remove the physical volume from it; use the just-freed drive to create new partitions on it to hold the live data; copy the live data over; and start doing pvmove again. Rinse, repeat, until all data is copied over and/or you've freed enough disks to create the RAID array. Luckily one can create a RAID array in degraded mode, or the procedure would've involved updating my backups, verifying them, wiping the hard disks, and reinstalling. As it is, I could get away with creating partitions that were just large enough to hold all data, and hoping people wouldn't try creating more data. I started working on this on Friday, and am just now, over 48 hours later, finishing up. It should've been possible to do all this in far less time; but rather than explaining what went wrong, let me just say, for the record, that I hate hardware. And that I should plan better. Anyway. The last stumbling block was the fact that the system simply wouldn't boot from the new root device. The reason was fairly obvious; the initrd was generated when mdadm was not installed yet, so had to be regenerated. But after calling yaird with the right options, it still wouldn't work. It took me a while to figure it out; but eventually, I found that yaird will read your /etc/fstab to find out about your root device; that it will see how it can get at that root device (where it's smart enough to know about md devices and LVM devices etc); and that it will then add the right software to the initrd based on that. Sure enough, my temporary root device that I had put outside of any LVM thing on /dev/hdb3 did have /dev/hdb3 as its root partition. So yaird didn't think mdadm was necessary. Heh. Quick edit fixed that. So now I have my important data on an LVM system on RAID5, and my less important data still on LVM. Me happy.