[01:38] <skiquel> starcraft-ntbk: :-) nice name
[01:38] <skiquel> you play sc?
[01:40] <starcraft-ntbk> skiquel: Hello
[01:40] <starcraft-ntbk> new doc member?
[01:41] <starcraft-ntbk> skiquel: as for SC, not so much anymore. I'm too busy for ga.
[01:52] <skiquel> starcraft-ntbk: I don't know if I'm a "member" yet, but I'm trying to contribute :)
[01:54] <starcraft-ntbk> skiquel: ah ha, well I been here a while, need some help?
[01:57] <starcraft-ntbk> skiquel: people some times have trouble finding info and documentation on getting started, you know where to get info on markup and system documenttion? The Doc team home yes?
[02:04] <skiquel> starcraft-ntbk: I've seen the page yeah :-) just being prudent, i don't want to make a new page on something like xmonad or weechat and get it deleted first thing
[02:10] <starcraft-ntbk> skiquel: try first time round then editting see the tags section. Don't need to make new pages.
[08:24] <cyberpandekoko1> wah?
[16:57] <missaugustina> Hey everyone! I'm going to be giving a talk in a few minutes on the Documentation process.
[16:58] <missaugustina> Phil Bull will follow with info on Mallard!
[16:58] <Pendulum> missaugustina: yay! I thought I'd seen a mention last week and then it hadn't been mentioned since so I wasn't sure if it was actually happening :)
[17:00] <missaugustina> Alright it's 1700 UTC, I believe
[17:00] <missaugustina> Here in the USA West Coast Pacific Time it's 9am, so if my time conversion is correct it's time to get started!
[17:01] <Pendulum> It is :)
[17:01] <missaugustina> Excellent.
[17:01] <missaugustina> I will present my information and take q&a at the end.
[17:01] <missaugustina> Please hold all questions until that time. Or, feel free to msg me directly and I'll get to your question when I'm done.
[17:01] <missaugustina> The purpose of this session is to review the steps contributors should take when preparing documentation.
[17:02] <missaugustina> By taking preliminary steps to plan and structure documentation before any writing begins, the documentation will be more effective, better organized, and ultimately, more useful.
[17:02] <missaugustina> This session will follow this agenda:
[17:02] <missaugustina> 1. Overview
[17:02] <missaugustina> 2. Define the Goal of the Document
[17:02] <missaugustina> 3. Define Use Cases
[17:02] <missaugustina> 4. Define the Audience
[17:03] <missaugustina> 5. Research Common Issues and Questions
[17:03] <missaugustina> 6. Propose an Outline
[17:03] <missaugustina> 7. Submit to Doc Team
[17:03] <missaugustina> 8. 8. When to Begin Writing
[17:03] <missaugustina> ==Overview==
[17:03] <missaugustina> The reason I proposed this session is that many new contributors seem to face similar challenges when preparing new documentation.
[17:04] <missaugustina> I also felt it might be helpful for veteran documentation team members looking to improve their writing.
[17:04] <missaugustina> This preparation process is not only important to focus your writing, but also clarifies your task to the rest of the team.
[17:04] <missaugustina> For instance, if you are writing documentation for novice users of an application, providing that information up front will ensure you get relevant questions and feedback.
[17:04] <missaugustina> Not communicating the scope of your documentation up front may produce feedback that isn't relevant to your task and can create a frustrating experience for the team.
[17:04] <missaugustina> Remember that when you contribute to Ubuntu Documentation, you're not working in isolation. You are part of a team!
[17:05] <missaugustina> The methods discussed in this session do not need to be performed in any particular order.  You can use one or two of these methods, or all of them if you like. Ultimately it depends on what is useful for your documentation.
[17:05] <missaugustina> If something is helpful, then use it. If it's tedious, confusing, and doesn't add anything to the quality of your documentation, then don't use it.
[17:05] <missaugustina> ==Define the Goal of the Document==
[17:05] <missaugustina> Prior to writing any documentation, you should think about who you are writing the document for and what purpose it serves.
[17:06] <missaugustina> Software Engineering and Usability both provide processes that we can borrow from for writing documentation.
[17:06] <missaugustina> Software Engineering defines an Objective during the planning phase of an application. Engineers need to clearly understand the purpose of what they are developing.
[17:06] <missaugustina> In Documentation, we can also define an Objective or Goal for our document.
[17:07] <missaugustina> Defining a goal gives you a reference point when writing your documentation.
[17:07] <missaugustina> When considering whether to include something or when determining how to word or structure something, ask yourself how it fits with the goal you've defined for your documentation.
[17:07] <missaugustina> Defining a goal also clarifies the scope and direction of your documentation for the rest of the team.
[17:07] <missaugustina> For example, the goal of documentation for the Make A USB Startup Disk application is: "Instruct a novice user to make a bootable USB drive (LiveUSB)."
[17:07] <missaugustina> The goal of documentation for the Ubuntu Packaging Guide is "Provide a comprehensive reference of packaging tools and methods for novice users, expert users, and developers"
[17:08] <missaugustina> Your goal should be very general and describe the scope of your documentation in terms of the bigger picture.
[17:08] <missaugustina> ==Define Use Cases==
[17:08] <missaugustina> In Software Engineering, prior to developing an application, developers define use cases to outline the different functions their application will serve.
[17:08] <missaugustina> A use case is a task for which someone will use the software.
[17:09] <missaugustina> To define a list of use cases, ask yourself, what will someone want to do with this software?
[17:09] <missaugustina> You can create a list of use cases by playing around with the application, working with the developer or development team, or by reviewing existing documentation.
[17:09] <missaugustina> Use cases can be as simple as "Edit database record" or as complex as "Authenticate login details".
[17:09] <missaugustina> The wording isn't as important as identifying the task.
[17:10] <missaugustina> You can get as granular as you like when defining use cases. Make sure the use cases you define are in line with the goal you've specified.
[17:10] <missaugustina> ==Define the Audience==
[17:10] <missaugustina> Usability Experts typically define generic user profiles to clarify what types of people will be using a software application.
[17:10] <missaugustina> A persona is a fictional profile meant to represent a typical set of users for the application.
[17:11] <missaugustina> This profile can be as detailed or as general as you like.
[17:11] <missaugustina> The point of a persona is to clarify your user audience and to provide a tool for you to put yourself in your readers' shoes.
[17:11] <missaugustina> By understanding the circumstances under which your reader will be accessing your documentation, you can provide more effective documentation that provides an overall positive experience for the end-user.
[17:12] <missaugustina> Think about how many times you've used documentation and felt frustrated because you couldn't find the answer to your question!
[17:12] <missaugustina> When preparing to write documentation, think about who will be using the application you are documenting.
[17:12] <missaugustina> What is their general computer skill level? Novice? Intermediate? Advanced?
[17:12] <missaugustina> What is their experience level with Ubuntu? Novice? Intermediate? Advanced?
[17:13] <missaugustina> Note that a user can be an advanced computer user but a novice to Ubuntu. Documentation for specialized networking applications might target this audience.
[17:13] <missaugustina> Typically you want to cater your documentation to the lowest skill level you've defined for your audience.
[17:13] <missaugustina> You can create special sections on specific topics for advanced users.
[17:13] <missaugustina> Think about why someone would be using this application. User forums are great for getting this information.
[17:13] <missaugustina> What kind of application is this?
[17:14] <missaugustina> Is it a general desktop application or is it a specialized application for developers?
[17:14] <missaugustina> These are just some questions to get you started when you begin thinking about your audience.
[17:14] <missaugustina> Here is an example of personas I defined for the Ubuntu Packaging Guide.
[17:15] <missaugustina> https://wiki.ubuntu.com/AugustinaBlair/PackagingGuidePersonas
[17:15] <missaugustina> You can find more information about Personas on Usability.gov, a website focused on usability run by the U.S. Government.
[17:15] <missaugustina> http://www.usability.gov/methods/analyze_current/personas.html
[17:15] <missaugustina> Note that you don't have to have both use cases and personas defined for every document you write.
[17:15] <missaugustina> Some documents are general enough that focusing on tasks only is more appropriate.
[17:15] <missaugustina> An example of this is the Make USB Startup disk documentation.
[17:16] <missaugustina> It makes more sense for a document like this to focus on Use Cases and less on user profiles. The application is straightforward and regardless of the end-user's level of expertise, they will use the same information to perform the same tasks.
[17:16] <missaugustina> Other documents should cater more towards the types of users, especially if the tasks are widely varied.
[17:16] <missaugustina> An example of this is the Ubuntu Packaging Guide.
[17:16] <missaugustina> This is a very complicated document that covers a lot of different tasks.
[17:17] <missaugustina> It makes more sense to define Personas and then define document sections to target those personas and what information they will need to perform typical tasks for their user profile.
[17:17] <missaugustina> ==Research Common Issues and Questions==
[17:18] <missaugustina> Use the Ubuntu Forums to find out where current users have questions!
[17:18] <missaugustina> http://www.ubuntuforums.org
[17:18] <missaugustina> The forums are a great place to survey the landscape of what documentation is needed before writing a single word.
[17:18] <missaugustina> Here are some questions to get you started:
[17:18] <missaugustina> 1. What are people using the application for?
[17:19] <missaugustina> 2. Where are people experiencing the most confusion when using the application?
[17:19] <missaugustina> 3. What are the most common questions about the application?
[17:19] <missaugustina> 4. What are the skill levels (as far as you can tell) of the most vocal users?
[17:19] <missaugustina> 5. What information would answer most of the questions on the forums?
[17:20] <missaugustina> A good example of this is minimum requirements for an installation.
[17:20] <missaugustina> Your goal in this research is to ensure your documentation answers the most common questions end-users have.
[17:20] <missaugustina> Users should be able to reply to common questions with a link to a section in your documentation.
[17:20] <missaugustina> ==Propose an Outline==
[17:21] <missaugustina> This is the most essential method discussed in this session!
[17:21] <missaugustina> If you don't use anything else I've discussed today, please use an Outline when creating your documentation.
[17:21] <missaugustina> Outlines allow you to organize content without getting weighed down by details.
[17:21] <missaugustina> Outlines are much easier for others to review than pages of text.
[17:21] <missaugustina> It is easier to see if something is missing in an outline.
[17:21] <missaugustina> It is also easier to rearrange items in an outline and see how they flow.
[17:21] <skiquel> man
[17:22] <skiquel> interesting.
[17:22] <missaugustina> Remember that most users will not read your documentation from beginning to end.
[17:22] <missaugustina> They will pick out the titles of sections that are most relevant to whatever they have questions about.
[17:22] <missaugustina> This is why understanding your audience and tasks is so important.
[17:23] <missaugustina> When you know what information users are likely to need to look up quickly, it's easier to create sections that meet those needs.
[17:23] <missaugustina> The sections your documentation needs to contain will vary depending on the purpose of your documentation.
[17:23] <missaugustina> Generally, your documentation should contain an introductory section that explains what the application is in one or two sentences.
[17:23] <missaugustina> Your documentation should also contain an FAQ or troubleshooting section for addressing common problems.
[17:23] <missaugustina> Finally, your documentation should contain a link either to the project page for the application or to the Ubuntu forums for users who want more information than what is covered by the scope of your documentation.
[17:24] <missaugustina> If your topic is very complicated, your documentation should be grouped into sub-sections intended to address the different users.
[17:24] <missaugustina> For instance, the Packaging Guide contains a Basic section for new users and Advanced sections for users who have advanced or specific needs.
[17:24] <missaugustina> Remember to keep the documentation structure simple and easy to follow.
[17:25] <missaugustina> Again, readers will not read your document from beginning to end.
[17:25] <missaugustina> Make sure you clearly define sections to help readers who are looking for specific answers.
[17:25] <missaugustina> ==Submit to Doc Team==
[17:25] <missaugustina> I highly recommend you submit your documentation outline to the Doc  team before you write a single word.
[17:26] <missaugustina> There is nothing worse than spending a lot of time on a section the team decides shouldn't be included in the final document.
[17:26] <missaugustina> Typically the folks reviewing your submission have a good understanding of how the documentation fits together as a whole.
[17:26] <missaugustina> Some topics in your outline might be better addressed in a section of the wiki whereas some are best suited for the system documentation.
[17:27] <missaugustina> The easiest way to submit your documentation is to create a sub-page in your own wiki name space on the Ubuntu wiki.
[17:27] <missaugustina> Then email the link to the mailing list and request a review.
[17:27] <missaugustina> For instance, my wiki space is https://wiki.ubuntu.com/AugustinaBlair
[17:27] <missaugustina> I typically post drafts under my namespace as follows: AugustinaBlair/MyDraftDocument
[17:28] <missaugustina> Wikis make it easy for team members to make changes and leave comments.
[17:28] <missaugustina> If you don't like the changes, you can roll them back.
[17:28] <missaugustina> The wiki is also web-based making it easier for folks on the team to access it wherever they are without downloading anything.
[17:28] <missaugustina> Thus, you are more likely to get more useful feedback!
[17:29] <missaugustina> ==When to Begin Writing==
[17:29] <missaugustina> Once you've gotten the ok on your outline from the team, you can start filling it out.
[17:29] <missaugustina> With all the previous research you've done, it should be really easy to fill in the remaining content!
[17:29] <missaugustina> That's all I have for discussing the pre-writing process.
[17:30] <missaugustina> A discussion on the actual writing itself is best saved for another session, but I'll leave you with some tips after the Q&A
[17:30] <missaugustina> ==Q&A==
[17:30] <missaugustina> If anyone has any questions, comments, etc, feel free!
[17:31] <missaugustina> I will leave this open for the next 15 minutes or so then end with some writing tips.
[17:31] <anthropologist> missaugustina: how long do you typically spend on the preparation and over what time period do you go expect to go through including getting feedback?
[17:31] <missaugustina> Well, it depends on the complexity of the topic.
[17:31] <missaugustina> I recommend spending at least a week on preparation.
[17:32] <missaugustina> Sometimes you need to walk away from something and come back to it after a 24 hour period so that you see it with fresh eyes.
[17:32] <missaugustina> You are more likely to see something you missed.
[17:32] <Pendulum> missaugustina: when you say "submit to the documentation team" does that mean link here or is there something more formal?
[17:32] <missaugustina> Once you submit your outline to the ubuntu-doc mailing list, expect it to take anywhere from a few days to a week.
[17:32] <missaugustina> I generally recommend waiting a week before proceeding.
[17:33] <missaugustina> Submitting documentation to the team is pretty informal.
[17:33] <missaugustina> I set up my wiki page under my namespace and send a link to the mailing list specifically requesting a review
[17:33] <missaugustina> I typically wait 1 week before moving forward so that everyone gets a chance to look at it.
[17:34] <missaugustina> You can also post the link here in the IRC channel.
[17:34] <missaugustina> You should always send it to the mailing list no matter what you do. Not everyone on the team gets on the IRC channel.
[17:35] <missaugustina> There isn't any written rule or formality that says you have to use the wiki for your submissions.
[17:35] <missaugustina> I have been using it and found it to be really helpful, so I'm just recommending that method.
[17:36] <missaugustina> Oh, I meant to post examples of the things I had been talking about:
[17:36] <missaugustina> https://wiki.ubuntu.com/AugustinaBlair/MakeUsbStartupDraft
[17:36] <anthropologist> missaugustina: I found the wiki easy when adding to your document
[17:37] <missaugustina> https://wiki.ubuntu.com/AugustinaBlair/PackagingGuidePersonas
[17:37] <missaugustina> The wiki is great.
[17:37] <missaugustina> You can subscribe to it so you get email updates when someone edits your work.
[17:37] <missaugustina> Since it's a wiki, people are less shy about editing it and adding suggestions.
[17:38] <missaugustina> When I was working on the Make USB documentation the team was helpful with adding items to my outline I had overlooked.
[17:39] <missaugustina> I know people also use Google documents.
[17:39] <missaugustina> Google docs doesn't have a version tracking system and it's hard to see who edited what and when.
[17:42] <missaugustina> Alright well if no one has anymore questions about anything I've discussed I'll end my session with some writing tips.
[17:43] <missaugustina> If you're viewing this session via the irc logs after the fact (or you're just really late getting into the room) feel free to email questions to the list or to me directly.
[17:43] <missaugustina> https://wiki.ubuntu.com/AugustinaBlair
[17:43] <missaugustina> My contact information is on my personal wiki page.
[17:43] <missaugustina> ==Writing Tips==
[17:44] <missaugustina> Disclaimer: These are not "official" Ubuntu Doc Project guidelines, just suggestions for writing better documentation.
[17:44] <missaugustina> Feel free to disregard any of the writing tips I suggest in the name of clarity
[17:44] <missaugustina>  The goal of any documentation is to benefit the reader so in any situation where these suggestions detract from that, go with what's best for the reader!
[17:44] <missaugustina> 1. Avoid future tense
[17:44] <missaugustina> Ubuntu documentation is translated into a lot of languages and future tense is one of the most ambiguous to translate.
[17:45] <missaugustina> 2. Avoid the passive voice
[17:45] <missaugustina> Not only is it annoying for translators but the passive voice also obscures clarity.
[17:45] <missaugustina> Examples:
[17:45] <missaugustina> Passive: The files are created in the home directory.
[17:45] <missaugustina> Active: Application x creates the files in the home directory.
[17:45] <missaugustina> Which one do you think is more useful to the reader?
[17:46] <missaugustina> 3. Avoid extra words like "can" and "should".
[17:46] <missaugustina> Examples:
[17:46] <missaugustina> Don't: You can click on the button to open a new window.
[17:46] <missaugustina> Do: Click on the button to open a new window.
[17:46] <missaugustina> Don't: You should see the new window open on your screen.
[17:47] <missaugustina> Do: When the new window opens, perform some task.
[17:47] <missaugustina> 4. Use the imperative voice. Use simple sentences.
[17:47] <missaugustina> The imperative voice is the "command tense" in English.
[17:48] <missaugustina> Examples:
[17:48] <missaugustina> Close the window. Click the button. Do this. Don't do this.
[17:48] <missaugustina> I know this makes the writing sound boring, but it's a lot more useful than lengthy complicated sentences with "personality".
[17:48] <missaugustina> Readers aren't looking at documentation because they want to be entertained ;)
[17:49] <missaugustina> 5. Final Tip! Don't take criticism personally.
[17:49] <missaugustina> Also, only consider the criticism that is relevant to your document.
[17:49] <missaugustina> Experienced team members will likely offer developmental advice or wording advice with usability in mind.
[17:49] <missaugustina> Less experienced members are likely to dwell on spelling, word choice, or grammar suggestions.
[17:50] <missaugustina> Consider the feedback that is most relevant to the stage you are at :)
[17:50] <missaugustina> While you may take pride in your writing, consider that this isn't really *your* writing, it belongs to the community!
[17:51] <missaugustina> If you are disturbed by any feedback you get from anyone on the team, you should definitely discuss it with them privately.
[17:51] <missaugustina> More than likely it's just the result of the limitations of text-only communication, and not anything personal ;)
[17:51] <missaugustina> Ultimately, the best way to avoid confusion and to ensure quality feedback is to clarify the intent of your writing by using the methods I've discussed.
[17:52] <missaugustina> Feel free to offer any questions or comments :)
[17:52] <missaugustina> Phil Bull will be starting his talk in about 10 minutes I believe :)
[17:52] <philbull> missaugustina: I'll probably leave it until 18:30pm UTC
[17:53] <philbull> unless people are really keen to get started at 18:00?
[17:53] <missaugustina> OK! I pretty much finished and had some writing tips in the event there weren't too many questions.
[17:53] <missaugustina> So I'm done, unless anyone has further questions or comments regarding anything I've discussed.
[17:54] <cdrive9999> Thanks Augustina, that was very helpful
[17:54] <anthropologist> philbull: I think you advertised 16:30 UTC so probably best to wait in case others turn up - much as I'd like to get back to bed for a bit (5am here)
[17:55] <anthropologist> thanks missaugustina
[17:55] <philbull> OK, I'll start at 18:30 UTC
[17:55] <philbull> if anyone can't wait until then, I've put the session online already:
[17:55] <anthropologist> yeah, 18:30.  see - I'm not thinking yet
[17:55] <philbull> https://wiki.ubuntu.com/Philbull/MallardIntro
[17:56] <philbull> If you're staying around, you might want to download and extract the following:
[17:56] <philbull> https://wiki.ubuntu.com/Philbull?action=AttachFile&do=get&target=mallard.tar.gz
[17:57] <philbull> it's full of examples that I'm going to run through
[18:05] <missaugustina> https://wiki.ubuntu.com/AugustinaBlair/HowToWritingProcess
[18:05] <missaugustina> The notes from my session are here. Thanks everyone!
[18:31] <philbull> Hi guys
[18:31] <philbull> I'm just about ready to start my session
[18:31] <philbull> Is everyone ready?
[18:32] <philbull> *** 1. Introduction ***
[18:32] <philbull> Welcome to this extra OpenWeek session from the Documentation Team.
[18:32] <philbull> I'm Phil Bull, and I'm going to be talking about writing documentation in an XML format.
[18:32] <philbull> The topic is "Mallard from scratch: Writing XML documentation for the GNOME desktop".
[18:32] <philbull> This session is aimed at people who have never written XML before, but would like to get involved with writing system documentation.
[18:33] <philbull> See https://wiki.ubuntu.com/DocumentationTeam for more information on contributing.
[18:33] <philbull> We'll be concentrating on Mallard. This is a new format which has specifically been developed for the GNOME Documentation project.
[18:33] <philbull> We're hoping that it will be pretty useful for other open source projects too!
[18:33] <philbull> I'm going to go through the material pretty quickly. I'll stop a couple of times during the session for questions, and I'll make the transcript available online.
[18:34] <philbull> There is also a tarball containing example files and a few exercises available from here:
[18:34] <philbull> https://wiki.ubuntu.com/Philbull?action=AttachFile&do=get&target=mallard.tar.gz
[18:34] <philbull> My Internet connection is acting up at the moment too, so if I get disconnected you can find a copy of the session here:
[18:34] <philbull> https://wiki.ubuntu.com/Philbull/MallardIntro
[18:35] <philbull> OK, let's begin!
[18:35] <philbull> *** 2. XML basics ***
[18:35] <philbull> I'll be introducing some basic XML concepts in this section.
[18:36] <philbull> *** 2.1 What is XML, why do we use it? ***
[18:36] <philbull> XML stands for "eXtensible Markup Language".
[18:36] <philbull> Markup languages are often used to give information on how parts of a text document should be displayed.
[18:36] <philbull> For example, HTML is an example of a markup language. With HTML, you can mark-up the text to tell the computer to display it in bold, or change the colour of it, for example.
[18:38] <philbull> So, markup languages let us add formatting and structure to a text document.
[18:38] <philbull> We want our documentation to have formatting and structure, so that's why we're interested in using a markup language.
[18:39] <philbull> But which markup language? For documentation, we're usually more interested in the structure than the formatting. The important thing is the content; a designer can format the document afterwards.
[18:39] <philbull> We also want to organise and link topics together easily (and automatically, if possible). Translation and outputting the document in multiple formats (such as HTML and PDF) are also desirable.
[18:39] <philbull> HTML isn't great for these things, so most technical writers use XML formats like DocBook and DITA. We're using Mallard, which is an XML markup language.
[18:39] <philbull> It provides a set of XML "elements" which let us define the structure and formatting of some text.
[18:39] <philbull> Once we've added these elements to the text, we can open the file in a viewer which understands the Mallard XML format. The end result is a help file, which your users can view and navigate on their computer screen.
[18:40] <philbull> See here for more information on what XML is: http://en.wikipedia.org/wiki/XML
[18:40] <philbull> *** 2.2. What is an element? ***
[18:41] <philbull> Elements are the building blocks of XML documents.
[18:41] <philbull> Here is an example of an element:
Hello, World!</p>
[18:42] <philbull> The "<p>" is the start tag, and denotes the start of an element. The bit between the angle brackets (a "p" in this example) tells you what *type* of content the element contains.
[18:42] <philbull> Here, <p> means that the element contains a paragraph of text. Another example, <link>, means that the element contains a link. There are lots of different elements that you can use.
[18:43] <philbull> The "</p>" is the end tag, and tells you when the content has finished. It is identical to the start tag, except for the forward slash.
[18:43] <philbull> The bit in between the start and end tags is the "content". It can be all sorts of things, such as text, a link or a filename to an image.
[18:43] <philbull> Whitespace (like spaces and new-lines) don't matter much in XML. You can have your start and end tags on different lines to the content, and the element will still be valid. For example, this:

[18:43] <philbull> Hello, World!

[18:43] <philbull> is exactly equivalent to the example I gave above.
[18:44] <philbull> Whitespace, no matter how much of it you have, is usually displayed as just a single space. This:

[18:44] <philbull> Hello,
[18:44] <philbull>        World!

[18:44] <philbull> should be displayed as:
[18:44] <philbull> Hello, World!
[18:45] <philbull> Some elements don't have any content. These elements don't have a start and an end tag; instead, they have a combined tag, which looks like this:
[18:45] <philbull> <example />
[18:45] <philbull> Note the forward slash at the end of the tag here.
[18:45] <philbull> We'll see lots of examples of different elements soon.
[18:45] <philbull> *** 2.3. Elements can contain other elements ***
[18:46] <philbull> Some elements can contain other elements!
[18:46] <philbull> This allows us to *nest* content, which is very important for structuring your document.
[18:46] <philbull> An obvious example is that you might have a paragraph, <p>, inside a section, <section>.
[18:46] <philbull> There are lots of other reasons why you might want to put one element inside another, though; for example, if you have some bold text in a paragraph, or if your section has a title.
[18:47] <philbull> *** 2.4. Only certain elements are allowed in other elements ***
[18:47] <philbull> XML is a very strict markup. HTML tends to be very forgiving if you put the wrong element in the wrong place, or miss an end tag.
[18:47] <philbull> Not so with Mallard.  By insisting that everyone follows a strict standard, you ensure consistency and compatibility.
[18:48] <philbull> This means that you will sometimes need to refer to the Mallard specification to see what is allowed. It's not difficult once you're used to it, though.
[18:49] <philbull> (I'll jam an appendix in at the end of this session, if anyone's interested in how to read the spec)
[18:49] <philbull> An important example of the strictness of the standard is that only certain elements are allowed in a given element. This makes sure that the structure of the document makes sense.
[18:49] <philbull> For example, the <table> element cannot contain a <page>.
[18:50] <philbull> Some elements have compulsory elements too.
[18:50] <philbull> For example, the <section> element *must* contain a <title> element.
[18:50] <philbull> *** 2.5. Elements can have attributes ***
[18:51] <philbull> As well as content (the stuff in between the start and end tags), elements can have attributes.
[18:51] <philbull> Attributes give extra information about an element.
[18:51] <philbull> They are used for lots of things, such as identifying specific elements, defining the URLs of links and providing alternative text.
[18:52] <philbull> Here is an example of an attribute:
[18:52] <philbull> <section id="introduction"><title>Welcome!</title></section>
[18:52] <philbull> The name of the attribute is "id" and the value of it is "introduction".
[18:53] <philbull> Each element can have several attributes, but it can't have more than one attribute with the same name.
[18:53] <philbull> Some attributes are compulsory, or expect a value with a certain format. We'll see more examples of attributes soon.
[18:53] <philbull> *** 2.6. Examples ***
[18:53] <philbull> Has everyone downloaded the tarball of examples that I linked to earlier?
[18:54] <philbull> Here's the link again if you missed it: https://wiki.ubuntu.com/Philbull?action=AttachFile&do=get&target=mallard.tar.gz
[18:54] <anthropologist> philbull: looking at it now
[18:54] <philbull> awesome
[18:54] <philbull> Open the file Example-bad.page and see if you can identify what is wrong with the document.
[18:54] <philbull> It might take you a little while
[18:54] <philbull> Once you've had a go at correcting it, compare it with Example-good.page to see how you've done.
[18:55] <philbull> You can see a screenshot of how that page looks here:
[18:55] <philbull> https://wiki.ubuntu.com/Philbull?action=AttachFile&do=get&target=Example-Good.png
[18:55] <philbull> We'll take a break now for questions, and so that you can take a look at the examples
[18:55] <philbull> (BTW, let me know if I'm going too fast/slow/boring)
[18:58] <philbull> I'll start going again in a couple of minutes, if there are no questions
[18:58] <ZachK_> meeting?
[18:59] <philbull> ZachK_: yes, we're just in the middle of an OpenWeek session
[18:59] <ZachK_> philbull: ok..mind if i sit in?
[18:59] <philbull> Of course not, welcome!
[18:59] <ZachK_> philbull: i'm on the Ubuntu Doc Contributors page on LP..
[18:59] <philbull> You can find a transcript here: https://wiki.ubuntu.com/Philbull/MallardIntro
[18:59] <anthropologist> philbull: what application do you use to read mallard?  any xml reader or something specific to mallard?
[19:00] <philbull> anthropologist: to edit Mallard, I use a normal text editor, like gedit
[19:00] <ZachK_> SO WHAT!!!!!
[19:00] <ZachK_> =-O
[19:00] <philbull> To view Mallard, you can only use Yelp at the moment
[19:01] <philbull> I'll be going into that later
[19:01] <philbull> ZachK_: are you OK?
[19:01] <ZachK_> philbull: ah...why wouldn't i be
[19:02] <philbull> sorry, just going back through the logs
[19:02] <philbull> OK, any more questions, guys?
[19:02] <ZachK_> philbull: ah........i'm confused
[19:03] <philbull> I might have missed some messages, my Internet connection is acting up
[19:03] <philbull> (feel free to resend if you think I missed something)
[19:04] <anthropologist> I don't think you missed anything phil.  ZachK_ seemed to say SO WHAT!!!! to nothing
[19:04] <ZachK_> anthropologist: exactly....
[19:04] <ZachK_> i'm the odd one......
[19:05] <anthropologist> ZachK_: were you having 2 conversations at once?
[19:05] <philbull> OK, I'll wait a couple more minutes before I start again
[19:05] <ZachK_> anthropologist: ah no.....
[19:06] <philbull> *** 3. A simple Mallard document ***
[19:06] <philbull> Let's write a simple Mallard document for ourselves.
[19:06] <philbull> Go to the "first" directory in the "mallard" folder and open the file index.page in a text editor.
[19:07] <philbull> Everyone ready?
[19:07] <anthropologist> ready
[19:09] <philbull> I'll wait a couple of mins for IRC to sort itself out
[19:12] <philbull> ok, i'll have to carry on
[19:12] <philbull> *** 3.1. The page element ***
[19:12] <philbull> At the top of the file you will see a page element with three attributes.
[19:12] <philbull> The xmlns describes what type of XML document we are using.
[19:12] <philbull> The type gives the type of page, which can be either "guide" or "topic". We'll discuss these more later.
[19:12] <philbull> The id is required, and is a unique identifier for this page in the document (more on that later, too).
[19:12] <philbull> For now, leave it as "index".
[19:13] <philbull> *** 3.2. The info section ***
[19:13] <philbull> The info section provides information about the document, such as its version and who wrote it.
[19:14] <philbull> You can put lots of different types of information in this section, but we're normally only interested in a couple of things.
[19:14] <philbull> So, let's make this document our own. Change the revision date to todays date, and bump the version up to "1.1".
[19:15] <philbull> Change the name and email address of the author too.
[19:15] <philbull> This document is your copyright, so lets add some copyright information.
[19:15] <philbull> Somewhere in between the <info> start and end tags, add a <copyright> element, with two elements inside it, <year> and <name>. Add appropriate content.
[19:15] <philbull> Don't forget to add an end tag for <copyright> too!
[19:16] <philbull> *** 3.3. The title and description ***
[19:17] <philbull> After the info section has been completed, we can start writing the document itself.
[19:17] <philbull> Every document needs a title, so let's add a <title> element after the info end tag "</info>".
[19:17] <philbull> Titles should be short but descriptive. Avoid unnecessary words!
[19:18] <philbull> In Mallard, we also give slightly longer descriptions of pages to supplement the title. The description should elaborate on the title, but not repeat it.
[19:18] <philbull> It's also a good place to use synonyms of the key words in the title, to help people searching for certain terms to find the right article.
[19:19] <philbull> Here's an example:
[19:19] <philbull> Title: Change the color of highlighted text
[19:19] <philbull> Description: Change the background color of text which has been selected with the mouse.
[19:19] <philbull> Use the <desc> element to add a description. This element belongs inside the <info> section, not outside it like the <title> element.
[19:19] <philbull> *** 3.4. A section ***
[19:20] <philbull> Sections are used to structure longer pages.
[19:20] <philbull> Mallard is designed for "topic-based" help; each page in a Mallard document should cover one topic and nothing more.
[19:20] <philbull> It's not like writing a book, where sections flow from one to the next. Each page should stand on its own, although of course you can link to other topics.
[19:20] <philbull> As such, you shouldn't need to use sections all of the time, since your topics should be reasonably concise.
[19:20] <philbull> I've found that many of the topics that I've written aren't long enough to be split into sections.
[19:21] <philbull> Anyway, you'll need them for longer pages.
[19:21] <philbull> You can add a section just by using the <section> element, anywhere below <title>. You can add as many sections as you like to a document.
[19:21] <philbull> Remember to give each section its own <title>, which must be in between the start and end tags of the <section> element.
[19:22] <philbull> *** 3.5. A section with some paragraphs ***
[19:22] <philbull> There's not much point having an empty section, so let's add some paragraphs of text.
[19:22] <philbull> This is as easy as adding <p> elements into the section.
[19:22] <philbull> You can add as many <p> elements as you like.
[19:23] <philbull> *** 3.6. A paragraph with italic text ***
[19:24] <philbull> All of the elements that we've used so far have been "block" elements or non-displaying elements.
[19:24] <philbull> Block elements, such as tables and lists, occupy a paragraph of their own. They can be thought of as the building blocks of a page.
[19:24] <philbull> Non-displaying elements, like most of the elements in the <info> section, aren't displayed on the page itself. They might be displayed on an "About this document" page, though.
[19:24] <philbull> Another type of element is an "inline" element. Inline elements are used to markup parts of a string of text, but necessarily the whole string.
[19:24] <philbull> They are used for adding links, making text bold and so on.
[19:24] <philbull> Here's an example of making text italic:
Some of the text here is <em>italic</em>, but none is bold.</p>
[19:24] <philbull> The <em> (emphasis) element is used to make text italic.
[19:25] <philbull> You can't make text bold at the moment, because Shaun McCance (the author of Mallard) hates bold fonts.
[19:25] <philbull> *** 3.7. The end of the document ***
[19:25] <philbull> The end of the document is simply the page end tag, </page>.
[19:26] <philbull> To summarise, we have:
[19:26] <philbull> The page start tag, <page>
[19:26] <philbull> The <info> section.
[19:26] <philbull> The <title>.
[19:26] <philbull> The contents of the page, which might be <section>s, <p>s, or other block elements.
[19:26] <philbull> Maybe some inline elements inside the block elements.
[19:26] <philbull> The page end tag, </page>.
[19:27] <philbull> Compare your document with index.page in the "example1" folder. Are all of the tags in the right places?
[19:27] <philbull> *** 3.8. Displaying the document in Yelp ***
[19:27] <philbull> What good is the document if we can't display it?
[19:27] <philbull> At the moment, the only help viewer which has been modified to work properly with Mallard documents is Yelp, the GNOME help viewer.
[19:28] <philbull> You can convert Mallard docs to HTML, though.
[19:28] <philbull> To view Mallard docs, you need the versions of gnome-doc-utils and yelp which are included with Ubuntu 9.10. If you don't have 9.10, you can compile them from source yourself.
[19:28] <philbull> That's left as an exercise for the reader, though...
[19:28] <philbull> To open your Mallard document in Yelp:
[19:28] <philbull> Open a Terminal and change to the directory that your index.page is in, e.g.
[19:28] <philbull> cd /home/phil/mallard/first
[19:29] <philbull> Then, type the following and hit return:
[19:29] <philbull> yelp $PWD
[19:29] <philbull> Yelp looks for a .page document in the current directory which has the ID "index".
[19:29] <philbull> If your document is valid Mallard XML, you should now see something like this:
[19:29] <philbull> https://wiki.ubuntu.com/Philbull?action=AttachFile&do=get&target=example1.png
[19:29] <philbull> If not, look at any messages which might have appeared in the terminal. These might give you some idea of what is wrong with the document.
[19:29] <philbull> OK, I'll stop again for questions.
[19:29] <philbull> Is anyone having problems?
[19:31] <anthropologist> all good
[19:32] <philbull> ok, I'll start again
[19:32] <philbull> *** 4. Other Mallard elements ***
[19:32] <philbull> (I'll go through this one quickly, just for reference)
[19:33] <philbull> There are lots of useful elements that you can use in Mallard. I'm going to briefly go through a few of the more common ones.
[19:33] <philbull> You can find some examples in the "elements" folder.
[19:33] <philbull> *** 4.1. Lists ***
[19:33] <philbull> There are several different types of list. For a full listing of them:  http://www.gnome.org/~shaunm/mallard/mal_block.html#lists
[19:33] <philbull> The most important one is probably <steps>. This is used for procedural instructions, like the steps in a how-to.
[19:33] <philbull> You start the list with the <steps> start tag, and then put in as many steps as you like using the <item> element.
[19:33] <philbull> Each <item> element *must* contain one or more block elements, usually a single paragraph, <p>.
[19:33] <philbull> You can put other block elements in there, like an image or even another list!
[19:34] <philbull> It's best to keep lists simple, though. Complicated lists are difficult to read.
[19:34] <philbull> I've put lots of examples in the "elements" folder.
[19:34] <philbull> One last thing to note is that lots of people forget that you need to put a block element in the <item> element. This is right:
A list item.</p></item>
[19:34] <philbull> This is wrong:
A list item.</item>
[19:34] <philbull> *** 4.2. Links ***
[19:34] <philbull> Mallard has some interesting linking features, but we're going to concentrate on simple inline linking for now.
[19:34] <philbull> These links are displayed like hyperlinks on webpages; the content of the <link> element is clickable.
[19:34] <philbull> The <link> must have a "xref" or "href" attribute. These give the address which is opened when the link is clicked.
[19:34] <philbull> If you want to link to a webpage, use the href attribute. For example:
Visit the <link href="http://www.ubuntu.com">Ubuntu</link> website for more info.</p>
[19:35] <philbull> You can also link to a different section on a page, or a different page in a document. Use the xref attribute for this:
See the <link xref="intro#overview">introduction</link> for a brief overview.</p>
[19:35] <philbull> The "intro" part is the ID of the page that you want to link to (remember the ID attribute of the <page> element?)
[19:35] <philbull> The "overview" part is the ID of a section in the intro page. The "#" separates the two.
[19:35] <philbull> If you want to link to a section in the same document as the link, just miss out the bit before the "#":
The final section of this introduction is an <link xref="#overview">overview</link>.</p>
[19:35] <philbull> In this case, you would have a section start tag that looks like:
[19:35] <philbull> <section id="overview">
[19:35] <philbull> *** 4.3. GUI elements ***
[19:35] <philbull> When you refer to part of a graphical user interface in some instructions, use the <gui> element.
[19:36] <philbull> This is most commonly used for buttons and labels.
[19:36] <philbull> Here's an example:
Click <gui>Save</gui> and then close the document</p>
[19:36] <philbull> *** 4.4. GUI menus ***
[19:36] <philbull> When you refer to a list of buttons in a user interface with <gui>, like in a menu, use the <guiseq> element to group them together.
[19:36] <philbull> In Yelp, this results in the buttons being displayed with nice arrows in between them. For example, this:
Click <guiseq><gui>System</gui><gui>Help and Support</gui></guiseq> to get more help.</p>
[19:36] <philbull> will be displayed something like this:
[19:36] <philbull> Click System -> Help and Support to get more help.
[19:36] <philbull> *** 4.5. Summary of others ***
[19:37] <philbull> There are lots of other useful elements.
[19:37] <philbull> Take a look at the spec for more information:
[19:37] <philbull> http://www.gnome.org/~shaunm/mallard/spec.html
[19:37] <philbull> OK, thanks for staying with me so far, guys.
[19:37] <philbull> This is the last section now...
[19:38] <philbull> *** 5. Multi-page documents ***
[19:38] <philbull> One of the strengths of Mallard is the ease with which you can organise information.
[19:38] <philbull> This is done by putting each topic on a separate page, and then linking the topics together into a document.
[19:39] <philbull> *** 5.1. Structuring a document ***
[19:39] <philbull> The main aim of structuring a document is to put information where your readers are expecting to find it.
[19:39] <philbull> This means that they can get the information that they want quickly, and solve their problem with the minimum of fuss. The best help files are often the ones that users spend the least time reading.
[19:39] <philbull> Normally, this means that you will want to split information into self-contained topics. Each topic is displayed on a page of its own.
[19:39] <philbull> You also need some way of navigating between these pages, or grouping them together when they are about similar things.
[19:39] <philbull> To help you with this, there are three types of page in Mallard.
[19:40] <skiquel> and you people should learn to show respect.
[19:40] <skiquel> jk
[19:40] <skiquel> also wrong channel, sorry :-)
[19:40] <philbull> *** 5.2. The "index" page ***
[19:40] <philbull> The index page is the "first" page in the document. When a user clicks Help -> Contents, this is probably what they will see.
[19:40] <philbull> The purpose of this page is to provide a starting point for people to go looking for the information that they need.
[19:41] <philbull> As such, the index page will normally just be full of links.
[19:41] <philbull> You won't have to put these links in by yourself, though! Mallard pages can automatically link themselves in to the index page.
[19:41] <philbull> The index page has the <page> element with attributes "id" with value "index" and "type" with value "guide".
[19:41] <philbull> When you try to open a document in Yelp (see section 3.8), it will look for a .page file with the ID "index".
[19:42] <philbull> *** 5.3. Guide pages ***
[19:42] <philbull> The index page is a "guide" page. You can have other guide pages too, though.
[19:42] <philbull> A guide page is one which collects together links to similar topics, sort of like displaying the contents of just one chapter of a book (rather than the whole table of contents).
[19:42] <philbull> As with the index page, other pages (including other guides) can automatically link themselves into a guide page.
[19:42] <philbull> Guide page <page> elements can have almost any ID that you like, but must have type="guide".
[19:42] <philbull> See http://www.gnome.org/~shaunm/mallard/mal_page.html#guide
[19:43] <philbull> *** 5.4. Topic pages ***
[19:43] <philbull> Topic pages are where you provide instructions or explain concepts. They are where the user reads the information they are looking for.
[19:43] <philbull> Most of your pages will be topic pages.
[19:43] <philbull> Topic pages can link themselves into guide pages, as mentioned before.
[19:43] <philbull> Topic pages have <page> with type="topic".
[19:43] <philbull> See http://www.gnome.org/~shaunm/mallard/mal_page.html#topic
[19:44] <philbull> *** 5.5. What are reciprocal links? ***
[19:44] <philbull> Reciprocal links are a pretty cool feature of Mallard.
[19:44] <philbull> If you link to topic A from topic B, then topic A will automatically have a link to B added at the bottom of the page.
[19:44] <philbull> This is useful because it helps the reader to navigate between topics, and makes it easy to extend a document by simply plugging pages into it, without needing to modify any of the other pages.
[19:44] <philbull> *** 5.6. Linking a page into a guide ***
[19:44] <philbull> To link a topic page into a guide, you need to add a <link> element into the <info> section of that topic page.
[19:44] <philbull> You *don't* need to put a link element into the guide page.
[19:44] <philbull> This <link> element is similar to the inline <link> element. This time, however, it can go anywhere inside the <info> element.
[19:45] <philbull> Now, it's a single "combined" tag, rather than an element with a start and end tag and some content:
[19:45] <philbull> <link type="guide" xref="index#behavior"/>
[19:45] <philbull> The "type" tells Mallard how to link the topic into the guide ("guide" just means to include it as a normal link).
[19:45] <philbull> The "xref" is similar to the xref in section 4.2, but it tells you where the link will *appear*, not where it is linking to.
[19:45] <philbull> In this example, the link will appear in a section with id="behavior" in the index page.
[19:46] <philbull> *** 5.7. Linking guides to other guides ***
[19:46] <philbull> Guides are linked in to other guides just as topics are linked into guides.
[19:46] <philbull> Just use the <link> element in the <info> section, as above.
[19:47] <philbull> *** 6. Where next? ***
[19:47] <philbull> OK, that's the end guys!
[19:47] <philbull> If you're interested in working with Mallard, get in touch!
[19:48] <philbull> philbull AT gmail DOT com
[19:48] <anthropologist> thanks phil
[19:48] <philbull> If you missed any of the session, it's all here:
[19:48] <philbull> https://wiki.ubuntu.com/Philbull/MallardIntro
[19:48] <philbull> anthropologist: that's OK, I hope it was useful
[19:48] <philbull> Does anyone have any questions?
[19:50] <anthropologist> nothing from me.  I'll probably have some if/when I try using it.  I notice that the mallard guide isn't complete yet.
[19:50] <philbull> that's true
[19:51] <philbull> We'll hopefully have it completed in the next month or two
[19:51] <philbull> It would be very useful for newcomers!
[19:51] <philbull> I'll try to spend some time on it over the next month or so
[19:52] <philbull> OK guys, last chance for questions...
[19:55] <philbull> Thanks everyone who turned up.
[19:55] <philbull> Let me know if you have questions


[12:19] <sitter> whatever should I do with muon and libqapt? since I raised the topic on the mailing list there've been 9 new bug reports of which one was triaged by someone who doesn't even use a debian distro and merge requests are also just sitting there
[13:10] <BluesKaj> Hi all


[14:39] <nagyz> is there a way to tell maas not to use the server's IP as a DNS server when deploying new nodes? :/
[14:51] <nagyz> ok, opened a bug...
[14:51] <mup> Bug #1539924 opened: dns forwarders are not set properly <MAAS:New> <https://launchpad.net/bugs/1539924>


[04:45] <AskUbuntu> Installing Landscape and launch the OpenStack Autopilot | http://askubuntu.com/q/589618
[08:31] <jamespage> dosaboy, do you have capacity to look at bug 1423153 ?
[08:31] <mup> Bug #1423153: /var/lib/mysql/mysql.passwd no longer exist <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1423153>
[09:23] <dosaboy> jamespage: sure
[10:48] <Murali> Hi Jamespage
[10:48] <jamespage> hey Murali
[10:49] <Murali> when we are deploying juju charm install hook failed
[10:50] <Murali> we dont add code to exit or return for failure and install is keep-on retrying
[10:51] <Murali> http://paste.ubuntu.com/10405985/
[10:51] <Murali> for that charm we removed the unit and service
[10:51] <Murali> after when we try deploy new charm we getting the above error
[10:56] <jamespage> Murali, that's just a log message related to the serial execution of hooks within a container
[10:56] <Murali> its not allowing to install new charms
[10:56] <jamespage> hmm
[10:57] <Murali> is there a way release that
[10:57] <jamespage> it would indicate that a hook is still running - check the process listing for the server
[10:57] <jamespage> something might be blocking
[10:58] <Murali> we destroyed that machine it self
[10:58] <jamespage> Murali, midonet-cassandra/0 specifically is still running its install hook
[11:02] <jamespage> Murali, juju enforces serial hook execution within a container, so if something is running a hook, nothing else can
[11:02] <jamespage> which would block any futher service deployments
[11:02] <jamespage> Murali, see if you can reproduce and check to see if the midonet-cassandra charm is blocking in its install hook
[11:02] <Murali> how to get out of it Jamespage
[11:03] <jamespage> Murali, workout what's wrong with the hook
[11:03] <jamespage> Murali, its probably still doing something
[11:06] <Murali> that service is not shown in juju status
[11:07] <Murali> on the previously existing logs for the unit, it had an error with dpkg lock and was retrying every 10 secs..
[11:08] <Murali> i did a resolved unit, followed by remove unit and remove service ... everything went on clean and relevant cass service was removed from juju status ..now when i try to deploy some other charm I get this error
[11:09] <jamespage> Murali, recyle the machine
[11:09] <jamespage> Murali, juju terminate-machine
[11:09] <jamespage> and then redeploy
[11:10] <Murali> Is there any hack to remove the lock .. i have some other services running on that node :( ... if there is no way, i shall do the terminate machine
[11:16] <jamespage> not that I know of
[11:17] <Murali> Ok, Thanks James.. I will do the terminate option ..
[11:20] <Murali> @Jamespage : Is there a difference between terminate-machine and destroy-machine ??
[11:21] <jamespage> I don't think so
[11:21] <Murali> Ok
[14:59] <AskUbuntu> Container lxc has two IP: One of them is bridge's. When connect with juju, connects to bridge's | http://askubuntu.com/q/589819
[17:01] <marcoceppi> o/ apuimedo
[17:02] <apuimedo> marcoceppi: ;-)
[17:07] <jshieh> hey folks, I have a Ubuntu 14.04 installed on a Power system (console-only) want to check out how my charm might look via the gui
[17:08] <jshieh> Any recommendations on desktop/vnc packages that are easy to install?
[17:10] <lazyPower> jshieh: are you on a posix host that you can run sshuttle?
[17:10] <lazyPower> jshieh: it may be easier to sshuttle into the machine (duct-tape vpn style) and pull up the GUI that way
[17:11] <jshieh> ummm, unsure about that.  I typically use vncserver / vncviewer to get to systems.
[17:11] <jshieh> my "viewer" client is a mac
[17:11] <apuimedo> jshieh: you can run sshuttle on the mac
[17:11] <jshieh> and my "host" is Ubuntu LE on Power 8 vm
[17:11] <apuimedo> iirc
[17:12] <lazyPower> jshieh: are you > mavericks?
[17:12] <jshieh> yes
[17:12] <lazyPower> i know it works fine on lion, i *think* it works on mavericks, but you're completely abandoned on yosemite
[17:12] <lazyPower> it dumps core
[17:12] <jshieh> yup, staying on mavericks for a while.
[17:12] <lazyPower> ok, might want to give that a go then
[17:12] <lazyPower> if it fails, its a simple brew uninstall
[17:12] <jshieh> Did some googling and pulled down lots of stuff, but maybe too much stuff
[17:13] <lazyPower> aisrael: does sshuttle work on mavericks? or is my memory of this completly kapoot?
[17:14] <jshieh> I've pulled down and installed x11vnc and tightvncserver
[17:14] <lazyPower> jshieh: well you can give that a go - if you wan tot install X on the host its a reasonable path forward
[17:14] <apuimedo> isn't it possible to start the mac's x server and then use X forwarding?
[17:15] <jshieh> hmmm, a thought.
[17:15] <jshieh> I already spent the 15 minutes pulling down the gnome desktop!
[17:15] <jshieh> ha-ha
[17:23] <jrwren> jshieh: you have the juju-gui deployed? can you curl it and see content? If you can, I'd ssh -L someport:ip:portthatyoucurled thatserver  to use ssh port forwarding.
[17:57] <aisrael> lazyPower: It works on Mavericks, but not on Yosemite going forward
[17:59] <lazyPower> ah, thats what i thought. thanks for confirming
[20:11] <sebas5384> jcastro: ping
[20:16] <jcastro> sebas5384, pong!
[20:16] <sebas5384> hey jcastro !
[20:17] <sebas5384> just wanted to say that the event was awesome and juju got a lot of attention
[20:18] <sebas5384> but i'm gonna reply your email to better explaining of how was it :)
[20:18] <jcastro> yeah
[20:18] <jcastro> good to know it went well!
[20:18] <sebas5384> yes! a lot of open mouthes
[20:19] <sebas5384> *mouthed
[20:19] <jcastro> did the hackfest on the charm itself bear fruit?
[20:23] <sebas5384> jcastro: not much
[20:24] <sebas5384> because of the internet
[20:25] <sebas5384> there were like 60 people in a big place under a hotel
[20:25]  * jcastro nods
[20:25] <sebas5384> so we tried to download everything we need
[20:26] <sebas5384> but the process of testing and developing in the charm was too slow
[20:27] <sebas5384> so the guys wanted to know more about how juju actually works and the charm of course
[20:27] <sebas5384> we get some starts(at github) and some promises of people that want to contribute
[20:29] <jcastro> it would be awesome to know which parts were slow
[20:30] <sebas5384> jcastro: well, everyone use vagrant
[20:30] <jcastro> you don't have to tell me now
[20:31] <jcastro> but like in the email
[20:31] <sebas5384> jcastro: sure :)
[20:32] <jcastro> so we can fix the easy ones.
[21:05] <lazyPower> sebas5384: o/
[21:05] <sebas5384> ping lazyPower !
[21:05] <sebas5384> hey!
[21:06] <sebas5384> I briefly sow the video of your last talk about juju
[21:06] <ahasenack> hazmat: ping, around?
[21:06] <sebas5384> lazyPower: really cool man! congrats :)
[21:06] <lazyPower> nice :D glad you enjoyed it
[21:07] <lazyPower> sent you some info in a PM, more details to come about that soon
[21:49] <hazmat> ahasenack: yes
[21:49] <hazmat> ahasenack: what's up?
[21:49] <ahasenack> hazmat: you bumped pythoh-jujuclient's version in setup.py to 0.5.0,
[21:49] <ahasenack> hazmat: but that number is lower than what was there before
[21:49] <ahasenack> 0.18.5 or even 0.19.0
[21:50] <hazmat> ahasenack: doh... ouch.. math is rough
[21:50] <ahasenack> :)
[21:50] <hazmat> ahasenack: i'll fix that, thanks
[21:50] <ahasenack> hazmat: cool
[21:53] <dpb1> hazmat: btw, I committed a fix in lp:python-jujuclient.  wasn't sure how the syncing was going with the github branch.
[21:54] <dpb1> hazmat: hi btw. :)
[21:54] <hazmat> dpb1: greetings.. saw the review comments, thanks
[21:54] <hazmat> dpb1: functional tests are flakey for you? if you could file a bug with errors that would be useful.. there's generally so little logic there, ie return self._rpc that i'm loathe to mock
[21:55] <dpb1> hazmat: haha, as I speak I'm bootstrapping an ec2 to test.  I was against maas before.
[21:57] <hazmat> dpb1: re git sync.. its a bit of a dance to get a working copy.. you have to stitch them together ie. two checkouts, move .bzr or .git to the other, and then commit and push to both.
[21:57] <dpb1> hazmat: gross
[21:57] <hazmat> no worries about it though
[21:58] <hazmat> dpb1: yeah.. if you know a better way i'm all ears
[21:58] <hazmat> dpb1: hope was then killing the bzr and setting up lp mirror
[21:58] <dpb1> hazmat: so, next time, I'll do that and submit a MP/pull request
[21:58] <hazmat> like marcoceppi did with amulet
[21:58] <hazmat> dpb1: sounds good
[22:02] <lazyPower> hazmat: http://github.com/chuckbutler/git-vendor/
[22:02] <lazyPower> hazmat: works for me, but i'm tracking history in 1 repository as opposed to 2
[22:27] <aisrael> Anyone had luck running the tests for charm-tools? It's throwing a `ln: failed to create hard link ‘bin/test’ => ‘scripts/test’: Operation not permitted` on me
[22:34] <lazyPower> aisrael: i haven't run them recently, are you doing this in a vm or on your osx host?
[22:34] <aisrael> lazyPower: in a vm
[22:34] <lazyPower> hmm, interesting error response
[22:38] <kwmonroe> hey hazmat, once upon a time, you mentioned a hosting provider that did wonky architectures.. not site-ox.  do you remember their name?  one-up or up-yours or something like that?
[22:43] <whit> to answer my earlier question, python jujuclient does not seem to run on python3
[22:43] <whit> hazmat, does HEAD support 3?
[22:44]  * whit saw six installed, but gets syntax errors on 3.4
[23:21] <hazmat> kwmonroe: there's a few . one for power one for arm
[23:21] <hazmat> the power one was  a subsidiary of ovh
[23:21] <hazmat> whit it should
[23:22] <hazmat> whit the release version that supports is fubar'd due to bad version math, i'll update with a newer release so it pulls down the right one (ie. 0.5  < 0.18 oops)


[10:38] <crogers> Hey folks, anyone else having this problem with nautilus in ubuntu 17.10:
[10:38] <crogers> https://www.dropbox.com/s/pvywye6alea76j4/nautilus_undo_history_bug.movie.mp4?dl=1
[10:38] <crogers> It seems ctrl+z undo tries to undo the last file opperation rather than the last text edit.
[10:38] <crogers> nautilus devs have fixed this behoaviour previously, so it's probably an Ubuntu patch that's causing the problem.
[10:40] <rbasak> Have you filed a bug?
[10:41] <rbasak> And are you sure that the upstream fix is included in the version shipped in 17.10?
[10:42] <rbasak> probably an Ubuntu patch that's causing the problem> seems like a pretty unsubstantiated claim to me.
[10:45] <crogers> rbasak: https://gitlab.gnome.org/GNOME/nautilus/commit/bf6b1e2c2f0cd3d882f99029af79a3439bdacec1
[10:45] <crogers> there's the patch that was released.
[10:45] <crogers> nautilus devs can not reproduce the bug.
[10:46] <crogers> I'm trying to determine where to post the bug report.
[10:48] <crogers> If this bug is only showing up in Ubuntu 17.10 build of nautilus, and Ubuntu patches nautilus then what other conclusion should I draw? :)
[10:50] <rbasak> It's not a reasonable conclusion to draw unless you have found that the same area of code is being patched.
[10:53] <rbasak> FWIW, it looks like that commit is included in Artful.
[10:57] <crogers> rbasak: You're saying that some other patch could not affect the behaviour of this code?
[10:58] <rbasak> Nope. I'm saying that more commonly there are other interactions that cause "can't reproduce upstream" type bugs, such as different dependency versions, so jumping to the conclusion of "it's because Ubuntu patched" is premature - especially for those unfamiliar with the code.
[11:01] <crogers> rbasak: that's just the info I got from the nautilus devs. I guess you can argue with them about code specifics.
[11:01] <crogers> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1729264
[11:02] <crogers> there's your bug report. Please let me know if I can help in any way.
[11:02] <crogers> Feel free to rename it if you don't like the title. :)
[11:03] <rbasak> Done. Your claim is unsubstantiated and unconfirmed and does not belong in the bug title.
[11:03] <rbasak> Thank you for filing the bug.
[11:03] <crogers> rbasak: no problem. :)
[11:04] <crogers> happy to help.
[11:04] <rbasak> Otherwise we might as well rename *all* bugs that cannot be reproduced in the same version upstream. That would be pointless :)
[11:05] <crogers> rbasak: Thanks for the feedback. It will help me produce better bug titles in the future.
[11:06] <rbasak> crogers: you're welcome. It's best to focus on exactly what behaviour is wrong. Feel free to speculate, but please keep that in the details and make it clear what is fact vs. what is speculation.
[11:07] <crogers> rbasak: Noted. Again, just passing on what nautilus devs told me. I'm not qualified to draw proper conclusions. I'm just happy if I can get enough information for a useful bug report. :)
[11:07] <rbasak> I'm sorry I can't spare the time to debug this further. Hopefully someone from the desktop team can do it.
[11:07] <rbasak> But a bug report is definitely the first step :)
[11:08] <crogers> rbalint: no problem. It's not a major issue for me, just a minor annoyance.
[11:08] <crogers> er oops
[11:09] <crogers> rbasak: ^
[11:09] <crogers> rbalint: Sorry for the noise.
[11:11] <crogers> Thanks everyone for making ubuntu better!
[12:26] <andreas> hi, does anybody know if the systemd network-online.target includes wireless networks that only come up after a user logs in on a desktop?
[13:03] <LaurenceLumi> I do #pull-lp-source imagemagick zesty
[13:04] <LaurenceLumi> but get this warning:
[13:04] <LaurenceLumi> gpgv: Signature made Mon Jul 31 13:52:14 2017 BST using RSA key ID A744BE93
[13:04] <LaurenceLumi> gpgv: Can't check signature: public key not found
[13:04] <LaurenceLumi> what do I need to verify the key
[13:11] <slashd> LaurenceLumi, try this "sudo gpg --keyserver keyserver.ubuntu.com --recv-keys A744BE93"
[13:11] <slashd> and retry
[13:19] <LaurenceLumi> no joy, if I run sudo gpg --fingerprint I can see it was added
[13:32] <LocutusOfBorg> sudo? LaurenceLumi you don't need it, maybe you are adding to the root keyring, not to the current user one?
[13:42] <LaurenceLumi> I think the files in ~/.gnupg ended up being owned by root, if fixed that,
[13:42] <LaurenceLumi> gpg --fingerprint shows:
[13:42] <LaurenceLumi> pub   4096R/A744BE93 2014-06-16 [revoked: 2016-08-16]
[13:42] <LaurenceLumi>       Key fingerprint = 2445 F8BC A621 74B9 2DFF  04E3 F021 0224 A744 BE93
[13:42] <LaurenceLumi> uid                  Marc Deslauriers<EMAIL_ADDRESS>[13:42] <LaurenceLumi> pub   4096R/A744BE93 2010-09-30
[13:42] <LaurenceLumi>       Key fingerprint = 50C4 A0DD CF31 E452 CEB1  9B51 6569 D855 A744 BE93
[13:42] <LaurenceLumi> uid                  Marc Deslauriers<EMAIL_ADDRESS>[13:43] <LaurenceLumi> uid                  Marc Deslauriers<EMAIL_ADDRESS>[13:43] <LaurenceLumi> uid                  Marc Deslauriers<EMAIL_ADDRESS>[13:43] <LaurenceLumi> uid                  Marc Deslauriers<EMAIL_ADDRESS>[13:43] <LaurenceLumi> uid                  Marc Deslauriers<EMAIL_ADDRESS>[13:43] <LaurenceLumi> sub   4096R/37AD7647 2010-09-30
[13:45] <LaurenceLumi> Am I getting the error becuase the key is revoked?
[13:50] <mdeslaur> LaurenceLumi: that's not my key
[13:50] <mdeslaur> LaurenceLumi: my key has fingerprint 50C4 A0DD CF31 E452 CEB1  9B51 6569 D855 A744 BE93
[13:50] <mdeslaur> you imported two keys with a short id collisio
[13:50] <mdeslaur> short id collision
[13:51] <mdeslaur> LaurenceLumi: you probably need to remove the revoked one from your keyring
[13:51] <LaurenceLumi> Ok, how do I delete, and import them correctly
[13:51] <LaurenceLumi> much appreciate the help
[13:51] <Faux> That's incredibly unlucky.
[13:52] <cjwatson> That's not unlucky - somebody generated collisions for the whole strong set in bulk, essentially as an argument that everyone needs to stop using short 32-bit key IDs
[13:52] <cjwatson> gpg --delete-key 2445F8BCA62174B92DFF04E3F0210224A744BE93 to delete the collided one, and then you have the correct one already
[13:53] <cjwatson> slashd: please don't recommend that anyone uses 32-bit key IDs for anything
[13:55] <LaurenceLumi> Ok, I just deleted both, just for fun...
[13:55] <LaurenceLumi> how do import it correctly
[13:55] <cjwatson> you already did
[13:55] <LaurenceLumi> orginally i did
[13:55] <LaurenceLumi> gpg --keyserver keyserver.ubuntu.com --recv-keys A744BE93
[13:55] <cjwatson> oh, you deleted it, "just for fun"
[13:56] <LaurenceLumi> well just learning...
[13:56] <LaurenceLumi> trying to figure how to do things properly, i.e. how do get the correct on in first go
[13:56] <cjwatson> what I recommend is that you put "keyid-format long" in ~/.gnupg/gpg.conf (or ~/.gnupg/options if that file exists)
[13:58] <LaurenceLumi> Ok, I think I am getting it,
[13:58] <cjwatson> (testing)
[13:58] <cjwatson> sigh, that still doesn't cause gpgv to output the long key ID.  Not helpful, gpgv!
[13:59] <cjwatson> I mean, you don't actually have to verify this, since it's already been verified by virtue of being in Launchpad and otherwise you have to figure out whether the key it was signed by is one authorised to upload to Ubuntu
[14:00] <cjwatson> since you don't have a trust path to the key in question, there isn't much value in you independently verifying it
[14:01] <cjwatson> but to get the key in a safer way, the simplest way I can find is to run "gpg --verify imagemagick_<IP_ADDRESS>+dfsg-3ubuntu1.2.dsc" which says "using RSA key 6569D855A744BE93", and then you can run "gpg --keyserver keyserver.ubuntu.com --recv-keys 6569D855A744BE93"
[14:01] <cjwatson> (slashd shouldn't have recommended "sudo gpg" here - it's just gpg)
[14:02] <cjwatson> after having done that you can then run "gpg --verify imagemagick_<IP_ADDRESS>+dfsg-3ubuntu1.2.dsc" again
[14:03] <cjwatson> gpg's UI is fairly nasty though, and I do recommend thinking about whether verifying the signature in fact buys you anything meaningful in this particular case.  Obviously you do need to do it if you've acquired a package in a way that could have been man-in-the-middled
[14:04] <slashd> cjwatson, noted
[14:06] <tacocat> is there anything I have to do to resync a package that had a source rename in Debian?
[14:09] <LaurenceLumi> cjwatson thanks, I went through those steps thoroughly I can verify the package with "gpg --verify imagemagick_<IP_ADDRESS>+dfsg-3ubuntu1.2.dsc" but why does
[14:10] <LaurenceLumi> pull-lp-source imagemagick zesty still throught an error
[14:10] <LaurenceLumi> gpgv: Can't check signature: public key not found
[14:11] <LaurenceLumi> is that becauase This key is not certified with a trusted signature!
[14:11] <LaurenceLumi> ?
[14:18] <cjwatson> gpgv uses a separate keyring, apparently
[14:18] <cjwatson> ~/.gnupg/trustedkeys.gpg
[14:18] <cjwatson> honestly I wouldn't worry about it if you've separately verified the package
[14:22] <LaurenceLumi> OK, now I get thanks
[14:47] <jbicha> bdmurray: What is "Install updates" in ubiquity supposed to do?
[14:48] <jbicha> because I just installed Ubuntu GNOME 17.04, rebooted, ran sudo apt update, and apt list --upgradable and I am surprised that there are lots of security updates in that list
[14:50] <jbicha> my interpretation of the ubiquity wording was that it should install all updates, security or not; but maybe it's not even doing either?
[14:56] <bdmurray> jbicha: I'm not positive - cyphermox or xnox may know.
[14:58] <xnox> jbicha, that tick box, downloads updates in the background whilst the system is installing / configuring.
[14:58] <jbicha> ahem
[14:58] <xnox> jbicha, expectation is that a system after such an install, is booted without network, but should have loads of debs in /var/lib/archive
[14:59] <xnox> jbicha, but it all depends on how slow/fast install is, cause i think on ssd the install will finish before that option can do anything useful.
[14:59] <bdmurray> So installing is misleading?
[14:59] <xnox> bdmurray, possibly became obsolete due to much faster hardware these days - all laptops circa 5-10 years are ssd now?
[14:59] <jbicha> oh I guess I was misreading the actual wording: https://github.com/googlei18n/noto-fonts
[15:00] <cjwatson> It used to be titled "Download updates while installing".  Is it not still?
[15:00] <jbicha> https://www.linuxtechi.com/ubuntu-17-10-installation-guide-screenshots/
[15:00] <jbicha> obviously not noto
[15:01] <bdmurray> cjwatson: It is worded that way
[15:01] <jbicha> that seems surprising that "download updates" may only download a few updates
[15:01] <jbicha> it confused me that "download updates" and "install third-party software" are on the same page. I expected it to install updates
[15:02] <jbicha> I don't understand how it's useful to just download .debs without installing them
[15:03] <jbicha> and I don't understand your hypothetical example where the installer has networking but there isn't networking a few minutes later upon reboot
[15:03] <bdmurray> jbicha: its useful in the way it says "saves time after installation"
[15:03] <jbicha> it doesn't really save time if it's not going to bother installing them
[15:05] <jbicha> since we install other packages (language packs, optional mp3 support), why don't we install at least security updates too so it's fairly secure "out of the box"?
[15:05] <xnox> jbicha, it saves a lot of time when using e.g. 16.04.0 but there are a lot of things to upgrade post install.
[15:05] <xnox> jbicha, the 3rd party stuff is actually installed, i.e. nvidia
[15:07] <jbicha> would it be better if I open a bug or start a list discussion? I don't think the question we ask during the install is worth asking
[15:08] <jbicha> we don't need permission to download security updates by default and IMO we don't even need permission to install them by default either
[15:09] <mdeslaur> hrm, I'm not sure how well installing security updates would work during the installer, since it's not the real system
[15:10] <jbicha> the same way as installing and uninstalling language packs?
[15:10] <mdeslaur> those don't really have complex maintainer scripts
[15:10] <cjwatson> those are super-specialised
[15:10] <cjwatson> I mean seriously, the installer in fact relies on how simple they are
[15:11] <cjwatson> it can "uninstall" them by ignoring all their files while copying the system and then doing a bit of tidy-up at the end
[15:11] <cjwatson> which makes a serious speed difference for some images
[15:12] <jbicha> am I wrong in thinking that ubuntu-restricted-addons shouldn't be an especially simple set of packages to install either?
[15:15] <LaurenceLumi> question everything I do inside pbuilder login is thrown away while I exit correct?
[15:16] <cjwatson> jbicha: I think that's basically dropping files in place and doesn't tend to e.g. involve maintainer scripts that interact with services
[15:17] <cjwatson> jbicha: anyway IMO the question should be between downloading updates or not doing so, not between installing them or not; there's a general principle that we need to get out of the installer ASAP and let the user do useful work
[15:17] <cjwatson> LaurenceLumi: yep, as the documentation says
[15:18] <LaurenceLumi> That's what I thought but when I read this https://wiki.ubuntu.com/PbuilderHowto#dpkg_setting
[15:18] <LaurenceLumi> it sort of suggests otherwise :-)
[15:19] <LaurenceLumi> or have I mindunderstood what the guide is saying
[15:20] <jbicha> cjwatson: ok, do we even need to bother asking for permission to download updates in the background? since that's done by default after install anyway
[15:20] <tarzeau> https://launchpad.net/~gagarin/+maintained-packages why is there not the Aa and Bb stuff listed?
[15:22] <cjwatson> LaurenceLumi: should perhaps recommend --save-after-login to make it permanent
[15:22] <cjwatson> jbicha: yeah, I'm not sure
[15:23] <cjwatson> tarzeau: I think that only lists the initial upload target, not wherever the packages in question may have been copied to since then
[15:24] <tarzeau> cjwatson: and it's not just it doesn't bother about uploaders, but only maintainers (teams mainly for my pkgs)?
[15:24] <LaurenceLumi> haha so I could just excepted all the defaults, just did a pbuilder create, then logged in with --save-after-login and made my changes manually and carried on?
[15:24] <jbicha> thanks, I'll file a bug about the download question
[15:24] <tarzeau> cjwatson: because it still seems to list packages that i'm maintainer  (not team maintained in debian), and not those (team maintained) as described above
[15:25] <tarzeau> and somehow this changed, some months ago (thus breaking kinda the karma counter)
[15:25] <tarzeau> where would the debian team pages on lp be? to check?
[15:27] <cjwatson> tarzeau: I'm pretty certain none of that has changed for years
[15:27] <cjwatson> Debian teams aren't necessarily represented on LP at all, although you can search by email address on https://launchpad.net/people
[15:28] <cjwatson> karma is pretty arbitrary and not every possible action is guaranteed to be credited there
[15:30] <cjwatson> LaurenceLumi: there are often a few different possible ways to set things up, yes
[15:30] <TJ-> jbicha: cjwatson re:Download question. I prefer it there and usually don't enable it. The reason being I want the network's package proxy/mirror to be configured to prevent un-necessary external network activtiy.
[15:31] <LaurenceLumi> I would suggest my why is probably the beginners way, but I get it now
[15:31] <TJ-> jbicha: if there's an easy to see/set option to add the proxy address though :)
[15:31] <jbicha> TJ-: at a minimum, I think we'd want to enable the download option by default
[15:32] <TJ-> jbicha: as long as I still have the control to disable it :)
[15:32] <jbicha> I think it's funny that for as many times as I've installed Ubuntu, I didn't really read that page carefully enough
[15:33] <TJ-> jbicha: when doing repeated VM-based testing it's a pain having it always want to pull in additional packages
[15:42] <andreas> hi, does anybody know if the systemd network-online.target includes wireless networks that only come up after a user logs in on a desktop? I'd say no, but wanted to check
[15:42] <Faux> Probably depends on whether you're on networkmangler or not.
[15:43] <Faux> I believe most machines wait for network online before starting a login manager, due to most services being poorly written.
[15:43] <andreas> the wifi would be managed by network-manager, yes
[15:44] <nacc> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ ?
[15:46] <nacc> andreas: NM-wait-online.service appears to be before network-online.target
[15:46] <nacc> andreas: *but* it sounds like the user has configure that wireless network to onnly be available for their user?
[15:47] <LaurenceLumi> I am getting loads of ln: failed to create hard link '/var/cache/pbuilder/build/17130/var/cache/apt/archives/libustr-1.0-1_1.0.4-5_amd64.deb': File exists from a pbuilder create, what't the cause and can I ingore these?
[15:49] <Faux> My artful laptop seems to have delayed network-online.target for the wifi to come up, but it hasn't delayed the DM starting.
[15:50]  * Faux sighs at postfix not starting until the wifi is up; why would that even be a thing.
[15:50] <rbasak> There's a bug on that I think.
[15:51] <rbasak> I don't see it as particularly important (personally) though I think others were making progress in the bug. Why is postfix running on a system where the connectivity is wifi a thing?
[15:51] <Faux> So I get mail from cron?
[15:51] <rbasak> You don't need postfix for that.
[15:52] <Faux> The actual answer is because all my machines is configured the same, although I thought it was necessary for local mail delivery like that.
[15:52] <rbasak> You need a working sendmail. It doens't have to be postfix (as I suppose the name implies :-)
[15:53] <rbasak> But also, cron jobs that matter on a machine with limited connectivity?
[15:53] <Faux> Debian #854475 explains that postfix is configured to be After=network*.target just in case a user has changed the configuration, which is an argument I'm not a big fan of.
[15:53] <Faux> Things run in cron jobs. I need to work out what went wrong. Until everything is running as a systemd timer, this involves digging through mail as well as journald.
[15:53] <rbasak> Ultimately defaults cannot work for people with weird configurations in the general case. By definition.
[15:54] <rbasak> It's override-able. You should override it.
[15:54] <Faux> I could. But, as it doesn't block the DM (for me), it's not a big issue. I have overriden whatever it was that was causing it to block the DM.
[15:55] <andreas> nacc: thanks for that link, reading
[15:58] <andreas> looks like pulling in network-online is even frowned upon for server software
[16:03] <nacc> Faux: i used to have to restart postfix all the time, whenever i would go to the office, or go home, etc. It was dumb, but postfix felt dumber for not being able to handle the network changing.
[16:27] <Faux> Junk.
[16:28] <nacc> Faux: it's possible that has improved since then
[16:29] <Faux> The bug is pretty recent. Although iirc the C changes are trivial.
[16:50] <LaurenceLumi> following one of the guides on pinning, I do #apt-get -b source debhelper
[16:50] <LaurenceLumi> it compiles, but how do I correctly install it?
[16:51] <nacc> LaurenceLumi: what are you actually trying to do?
[16:51] <LaurenceLumi> follow this guide https://help.ubuntu.com/community/PinningHowto#Recommended_alternative_to_pinning
[16:53] <LaurenceLumi> actually I am trying to built imagemagick from zesty source on xenial, but I am trying to follow some of the basic guides which a full of little errors
[16:54] <LaurenceLumi> I did #apt-get -b source debhelper which created to packages debhelper_10.2.2ubuntu1_all.deb  dh-systemd_10.2.2ubuntu1_all.deb
[16:55] <Faux> My experience is that trying to backport anything deb/dpkg related ends in sadness; it's probably not a good idea.
[16:56] <LaurenceLumi> doing #apt-get -b source -t zesty debhelper as suggested by the guide did not work at all
[16:57] <LaurenceLumi> I can create packages, both using pbuilder and following the guide here https://help.ubuntu.com/community/PinningHowto#Recommended_alternative_to_pinning
[16:57] <LaurenceLumi> so I have lots of packages, but I am not sure how to install them probably. Not keen on destroying my machine,
[17:02] <nacc> LaurenceLumi: whey can't you use debhelper in x-b?
[17:03] <LaurenceLumi> what is x-b?
[17:03] <nacc> LaurenceLumi: xenial-backports
[17:05] <LaurenceLumi> I could, it as example to when following the guide, if I guide worked for debhelper I coudld tackle imagemagick
[17:05] <LaurenceLumi> ^I choose it as an example
[17:06] <nacc> LaurenceLumi: why not just use a ppa for this?
[17:07] <nacc> LaurenceLumi: do you need some feature from the zesty imagemagick?
[17:07] <LaurenceLumi> yes
[17:08] <LaurenceLumi> yes connected-components functionality
[17:08] <nacc> LaurenceLumi: why not just run zesty or artful in a VM?
[17:09] <LaurenceLumi> I grabbed the source and compiled it, but I thought I should learn how do learn some of ubuntu,
[17:09] <LaurenceLumi> so I am working my way through some of the suggested ways of doing things
[17:11] <LaurenceLumi> so far I have setup pbuilder, and sucessfull build imagemagick_<IP_ADDRESS>+dfsg-3ubuntu1.2.dsc which gave me loads a deb files
[17:11] <nacc> LaurenceLumi: ok, so istall those debs
[17:12] <LaurenceLumi> but I am not sure how to install them, and wasn't in a hurry until I understood what was going on
[17:12] <nacc> LaurenceLumi: you don't know how to install debs?
[17:12] <LaurenceLumi> no
[17:13] <LaurenceLumi> I am guessing it dpkg -i package name, but I don't understand how the depenedecy bit works
[17:13] <LaurenceLumi> hence trying to follow guides
[17:14] <nacc> LaurenceLumi: fwiw, you probably wanted to properly adjust the versionning of that
[17:14] <nacc> LaurenceLumi: dpkg doesn't do dependency resolution itself
[17:15] <nacc> LaurenceLumi: you'll need to isntall all the packages at the same time, or use somethign like gdebi
[17:17] <jbicha> sudo apt install ./foo.deb to install foo is useful too (the ./ is important)
[17:17] <LaurenceLumi> Ok I get it now
[17:17] <nacc> jbicha: ah thanks, i forgot apt can do that
[17:18] <LaurenceLumi> Ok so the guide I linked before is missing that step...
[17:18] <nacc> LaurenceLumi: i feel like any guide that is about *building* packages, assumes you know what to do with packages
[17:19] <LaurenceLumi> just feedback, from a newbe
[17:19] <LaurenceLumi> one more question, what about the previous version of ImagaMagick I installed
[17:19] <nacc> LaurenceLumi: IMO, a newbie probably should not be tryig to do this backport :)
[17:19] <nacc> LaurenceLumi: at least not on their machine
[17:20] <nacc> use a PPA or somethig
[17:20] <nacc> LaurenceLumi: what about it?
[17:21] <LaurenceLumi> actually before I go on, so as a newbie, how should I be using a PPA?
[17:22] <nacc> LaurenceLumi: the backportpackage tool
[17:26] <LaurenceLumi> OK, wish I found that before I started :-)
[17:26] <nacc> LaurenceLumi: yeah :)
[17:26] <LaurenceLumi> Ok back to hypothetical question, because I think I will investigate the backportpackage
[17:28] <LaurenceLumi> apt install ./foo.deb ./bar.deb ./foofoo.deb, what about previous versions of foo bar and foofoo?
[17:28] <LaurenceLumi> i.e. should I purge the previous release before attempting a manual install with deb packages
[17:29] <nacc> LaurenceLumi: do you purge previous versions when you upgrade normally?
[17:31] <LaurenceLumi> no, but I am not using packages directly
[17:33] <nacc> LaurenceLumi: in general it should be fine. If it is a very large jump, it's possible some upgrade paths have been dropped in the new packaging.
[17:36] <LaurenceLumi> Just looking backportpackage, am I right the big difference is that will load the *.deb that get build into a PPA so that apt-get will see them as normal packages to upgrade and everything works as expected, plus I can let other know about my PPA?
[17:37] <LaurenceLumi> as compared to using pbuilder to build the debs?
[17:38] <nacc> LaurenceLumi: it builds it in the PPA
[17:38] <nacc> LaurenceLumi: nothing runs on your system at all
[17:38] <nacc> LaurenceLumi: i believe it also will do the versioning correctly
[17:39] <cjwatson> (note that PPA response times aren't going to be great just now as we have a lot of stuff going on in our build farm)
[17:40] <nacc> cjwatson: yeah :)
[17:40] <nacc> was goingn to mention that next
[17:41] <LaurenceLumi> that's fine, will 100x faster, than the time I already spent, but at least I did learn something
[17:41] <LaurenceLumi> maybe
[17:41] <nacc> LaurenceLumi: yeah :)
[17:41] <nacc> LaurenceLumi: in your case, it doesn't seem like you really needed to learn quite as much about source packages, yhou just wanted to do a backport
[17:42] <LaurenceLumi> how do I make suggestions regarding guides, both the pinning and backports page don't mention the backportpackage
[17:42] <nacc> LaurenceLumi: and you ca configure your ppa (before doing the backportpackage) to have xenial-backports as a dependency, so that it can build with a newer debhelper, e.g., on xenial
[17:43] <LaurenceLumi> thanks nacc, I will do that
[17:44] <nacc> LaurenceLumi: which pages are you referringn to?
[17:46] <LaurenceLumi> this https://help.ubuntu.com/community/PinningHowto one and this https://wiki.ubuntu.com/UbuntuBackports
[17:46] <nacc> LaurenceLumi: the latter is a wiki page
[17:46] <LaurenceLumi> but actually the second does have
[17:46] <nacc> and i think the first is too
[17:46] <nacc> and the first shouldn't mention backportpackage, it's onnly about pinninng
[17:48] <LaurenceLumi> but the pinning actually has an alrtenative method i.e. build from source
[17:48] <LaurenceLumi> but I guess it is there,
[17:48] <nacc> ugh, that's dumb
[17:48] <nacc> I absolutely do not thing building a deb from source is a "recommended alternative to pinning"!
[17:49] <nacc> *think
[17:49] <LaurenceLumi> I agree!
[17:49] <nacc> jbicha: maybe i'm wrong, though, thoughts?
[17:49] <LaurenceLumi> I think that is what actually started me of whole pbuilder thing
[17:50] <LaurenceLumi> when I probably wanted was backportpackage
[17:50] <nacc> LaurenceLumi: yeah, i can imagine that
[17:50] <jbicha> uh, there's different levels of recommendations. Ordinary users shouldn't need to build any packages, especially not low-level ones like imagemagick
[17:51] <jbicha> but yeah, backportpackage is a lot easier than settings up a build environment
[17:52] <nacc> jbicha: i meant specifically the pinning page recommending that users build packages from source as an alternative to pinnning (and citing libc6 as a (good?) example of such a package!)
[17:53] <jbicha> uh, I think backportpackage is better than a recommendation to pin packages from a totally different Ubuntu release, yes
[17:54] <jbicha> pinning may be useful where you only want one package from a large ppa
[17:54] <nacc> right
[17:54] <LaurenceLumi> is there a way to follow throught with that suggestion, i.e. who do I email/ping?
[17:54] <nacc> i think the pinning community page shouldn't mention source packages at all
[17:56] <jbicha> if you're going to work on it, you should kill or heavily edit the Pinning Methods section where it encourages people to pick and choose Ubuntu releases to install packages from
[17:56] <jbicha> that's why there's that whole libc6/backports warning
[17:57] <nacc> jbicha: yeah, it just seems like ... bad advice :)
[17:57] <nacc> LaurenceLumi: it's a wiki page, so you just need to login and have rights
[18:29] <infinity> nacc: Gah.  Wow.  That page's suggestion that "pinning libc6 doesn't work, so try backporting!" is amazingly irresponsible.
[18:29] <infinity> And also shows that whoever wrote it doesn't grasp pinning.
[18:29] <infinity> Cause if you pin *all* of glibc's binaries, it works great.
[18:30] <infinity> Of course pinning one binary from a source package will end in tears.
[18:36] <sarnold> is -that- how we get so many bug reports from folks trying to install different versions of a package in both i386 and amd64 flavours?
[19:36] <nacc> infinity: yeah, it's terrible!
[19:36] <nacc> sarnold: i'm starting to think it's at least part of it
[19:42] <sarnold> nacc: it'd be nicest if the tools could recognize that step before taking it :)
[19:47] <infinity> sarnold: Some sort of Ubuntu Clippy that pops up and says "It looks like you're trying to do something stupid"?
[19:48] <infinity> "Would you like me to turn off all your bug reporting tools?"
[19:48] <nacc> heh
[23:02] <sarnold> infinity: haha :) I love turning off the bug reports rather than not installing the update.. hehe
[23:03] <infinity> sarnold: As to your original comment, the biggest source of arch/version skew appears to be people who install arch_X from a repo, disable said repo, then wonder why things are broken.
[23:03] <infinity> sarnold: When that's a PPA, I can sort of (but not overly) sympathise, but I see it a LOT with people who install from -updates, then disable -updates and file a bug report next time something breaks.
[23:03] <infinity> Like, wat?
[23:03] <sarnold> infinity: ohhh, that'd be hard to spot without magic version numbers..
[23:04] <sarnold> oof. with -updates disabled???
[23:04] <infinity> sarnold: Yep, see it a lot more than seems reasonable.  You'll see something complaining about "can't install foo because depends foo-common=1, but foo-common=1.1 is installed".
[23:05] <infinity> sarnold: Which means they got 1.1 from -updates, then disabled updates, then whee.
[23:05] <infinity> sarnold: And that, apparently, is our bug, not theirs.
[23:05] <infinity> I really want to be able to change a package task to a person.
[23:06] <sarnold> infinity: thanks for pointing it out, I like to be able to help folks along when I can, and this one ought to be cheap enough to spot
[23:14] <infinity> sarnold: It tends to confuse users more than it should probably because apt spells the above "is installed" as "is to be installed".
[23:14] <infinity> sarnold: Since it's reporting the final state it's trying to achieve, not the current state.
[23:14] <sarnold> infinity: hrm. did I know this? I'm .. curious :)
[23:15] <sarnold> infinity: of course there's loads of errors our users report that I have never seen before because users make great testers :)